00:04
8月4日、木曜日ですね。地獄浅草城もありました。
本日の東京は、なかなか雷雨になるらしいですね。ちょっと僕が雨男で、ちょうど楽しみなことが今日実はあるんで。
はい、早速雨を降らしてしまった感がありますが。はい、おはようございます。ユメミのけいすくんの桑原です。
では本日も朝活を始めていきたいかなと思います。
はい、ということで、本日は、タイトルはありますけども、
「デュアルトラックアジャイルって結局何なの?」という記事と、
「THE MANY DEFINITIONS OF SERVER-SIDE RENDERING」ですね。はい、という2つの記事を読んでいきますと。
前者の方は日本語の記事で、ずっとToDoに入れていたんですけども、これは絶対読むという、マストというものをつけていたので、
他の記事を読み切ってきたので、大体基本これを読んでいこうかなと思います。
残り時間が余ったら、後者の方ですね。こちらは英語の記事なんですけども、タイトルのとおりですね。
いろんな方々がサーバーサイドレンダリングというものを言語化というか定義をしていますので、
それの定義っていうのを見ていこうかというところが後者にありますけど、
もしかしたら後者の記事間に合わないというか、今日時間いっぱいで前者の方が収まらない気がちょっとしているので、
もしかしたら読めないかもしれないですけど、その時はご了承くださいというところです。
で、早速入っていきたいと思いますが、ケイさんですね、おはようございます。
ご参加いただきありがとうございます。今日もだらだらとタイトルの記事を読んでいきたいと思います。
では、いきましょう。デュアルテックアジャイルって結局何なの?というところです。
今回の記事は川口さんという方がですね、川金さん、ちゃんかわさんとかっていうふうに名乗ったりしているそうですね。
Atama Plusという会社のAI教育のスタートアップのスクラムアプリをされている方だそうです。
一応ご自身と会社の紹介についてのスライドとかリンク、ノートとかも貼ってますので、その辺を見てくださいということでした。
じゃあいきましょう。皆さん、デュアルトラックアジャイルという言葉をご存知でしょうかと。
デュアルトラックアジャイルとは、事前に最小コストで最大のリスクを潰しながら価値あるプロダクトを作っていくための開発プラクティスでありますと。
Atama Plusでは、創業当初からこのデュアルテック、デュアルトラックアジャイルっていうのを実践しようと取り組みまして、たくさんの失敗と成功を重ねてきましたと。
ディスカバリーバックログとデリバリーバックログを分けてプロセス化してしまったことによるミニウォーターフォールかなど、いろんな失敗とかもやってきましたと。
今年の初めにその弊社のデザイナーも、Atama Plusのデュアルトラックアジャイルの取り組みを紹介していましたと。
その別のノート記事のリンクも貼ってますので、興味ある方は見てみてください。
今回はプロダクトのスクラムマスターの視点から、私がデュアルトラックアジャイルを実践する中でも何らかのことをお伝えしたいと思いますということでした。
はい、じゃあ行きましょう。
一つ目ですね、まず今回お伝えしたいことですけども、今回のノートではデュアルトラックアジャイルとはなんとなく知っているけど、実践にあたって何がポイントになるの?みたいな疑問を持ちの方向けに、
僕ですね、方向けにですね、失礼。
そういう疑問を持ちの方向けに書きをお伝えできればと思います。
書きっていうのは2つですね。
03:00
デュアルトラックアジャイルを実践するにはマインドセットとプラクティスを理解することが最も重要でありますと。
もう一つはデュアルトラックアジャイルはスクラムのようなプロセスフレームワークではないんですよってところですね。
はい、この2つを理解してくださいと思いました。
はい、一応、Atom1プラスのデュアルトラックアジャイルの失敗と成功はまた改めてノートに書く予定ですというところでした。
また、デュアルトラックアジャイルの詳細に興味ある方は、ユーザーストーリーマッピングとかLinuxとかInspiredみたいな本がお勧めですので、その辺も見てみてください。
はい、それではまたリンクも貼られてますので、今日読み終わったらこの記事Twitterで流しますので、その記事の中からリンクをたどってください。
はい、続いてですね、デュアルトラックアジャイルを実践するにはマインドセットとプラクティスを理解することが最も重要であるというところの説明です。
そもそもデュアルトラックアジャイルというのは、事前に最小コストで最大のリスクを潰しながら価値あるプロダクトを作っていくというための開発プラクティスですと。
デュアルトラックという通り、ディスカバリートラックとデリバリートラックという2つのトラックがありますと。
前者のディスカバリートラックですけど、ディスカバリーとは最小コストで最大の学びを得るということですね。
というふうに定義して、そのために行うトラックだというのがディスカバリートラックです。
もう1個後者の方のデリバリートラックですね。
デリバリーとは一定の規模ですね。
ユーザーにプロダクトを当てるための一定の規模ですね。
で学びを得るために行うトラックだというふうに言います。
そのためのトラックでデリバリートラックというふうに言ったりするんですね。
繰り返しますけどディスカバリートラックというのは最小コストで最大の学びを得るために行うトラック。
デリバリートラックっていうのは一定の規模で学びを得るために行うトラックというところですね。
この2つを動かしていくと、デュアルトラックというところですね。
この2つのトラックにはそれぞれのマインドセットのプラクティスを理解することが重要ですと、
特にディスカバリーでは、デリバリーする際の 最大のリスク、すなわち検証すべき仮説を
絞って小さく検証することを目的する一方、 デリバリーでは商用レベルの品質で
一定の規模のユーザーにプロダクトを当てて、 検証することを目的としています。
ちょっと目的やっぱり違う感じですね。
またその際に用いるプラクティスもやっぱり異なりますと。
特にデリバリーに関しては、スクラムの 出荷可能なプロダクトをイテレティブ
かつインクリメントに作ることをベースにしていますが、 ディスカバリーにおいては、
仮説に対して解像度を上げていく方法が多岐に 当たりますと言ってますね、はい。
なるほどな。
デリベティブかつインクリメンタルに作ることを ベースにしているのがデリバリーですと。
で、ディスカバリーは仮説に対して解像度を 上げていくっていうところですね、はい。
もうちょっといきましょう。
プロダクトディスカバリーで検証する仮説と その手法の一例ですね。
先ほどの紹介した書籍の一つ、 インスパイヤードっていう書籍ですけど、
それの著者であるマーティ・カガン氏が 語っていますが、
06:01
ディスカバリートラックでは 4つのリスクに対応しますと。
1つ、ビジネス的な価値があるかどうか。 われわれのビジネスに貢献するか。
2つ目、顧客ですね。 お金を出す人にとって価値があるかどうか。
3つ目、ユーザーですね。 実際にサービスを使う人にとって価値があるかどうか。
で、最後4つ目ですけど、 実現可能性があるかっていうところですね。
この4つに対して、4つのリスクに ディスカバリートラックでは対応していくってところですね。
上記のリスクを検証する方法には、 例えばユーザーストーリーマッピングとか、
リーンキャンバスとか、プロトタイピングとか、 ユーザーインタビュー、ペルソナの作成など、
さまざまなプラクティスが存在しますと。
それぞれの検証方法の引き出しを持って、 必要に応じて発動することが大切になります。
また、ディスカバリーでは マインドセットがすごく重要になりますと。
誰も必要としていないのに無駄なコストをかけて、
商品レベルで作り込んでしまう前に、 重要なリスクから検証し、
間違っていることに早く気づこうとすることが 最も大切ですと言ってますね。
続いて、デュアルドラッグアジャイルっていうのは、 デザインプロセスから実装プロセスではないんだよってところを言ってますね。
よくデュアルドラッグアジャイルっていうのは、 デザインプロセスと実装プロセスを組み合わせたものと取れられることもありますが、
実はそれは大きな勘違いですよというふうに言ってます。
デザインができたし、ワイヤフレーム完成したから 次実装に行きましょうというような流れではないということですね。
前述の通り、ディスカバリーっていうのは、 さまざまな仮説に対して検証するプロセスであり、
デザインをするプロセスではありませんと。
よくあるのはユーザーにとって価値があるか というところに注目をしてディスカバリーをしすぎた結果、
UXデザイナーがデザインのワイヤフレームを作り込む プロセスになってしまうケースがあります。
上記の場合、例えば技術的な実現可能性のリスクが 最も高いにもかかわらず、
UXデザイナーが詳細なワイヤフレームを作成して デリバリーした際にこんなの作れないよという問題が起きてしまいます。
ユーザーにとって価値があるかを 最小コストで検証するのであれば、
ラフなワイヤフレームで十分です。
どういう目的でワイヤフレームを描くのかを 理解していることがとても大切です。
これは本当によくありがちですよね。
デザイナーさんが出してきたワイヤフレームとか デザインが実現可能性が全然ないじゃん。
もしくはできるかもしれないけど、 労力とか時間がめちゃめちゃかかるので、
今回のビジネスの予算とか期限をオーバーしますね みたいな話とかも全然ありますからね。
で、また戻りますね。
リーンUXという書籍の著者である ジェフ・ゴセルフ氏ですかね。
という方もおっしゃっているように、
俯瞰すると商用レベルでのプロダクトの価値を ユーザーに検証する意味で、
最終的にはデリバリー自体も 最もディスカバリーの一種になりますと。
最も大きなか。
最終的にはデリバリー自体も 大きなディスカバリーの一種になりますと。
毎回仮説は変わっていきますし、 仮説に対する解像度というのも変わりますと。
ディスカバリーからデリバリーだと、 ただ単にプロセスを分けるんじゃなくて、
プロダクトオーナーを中心にチーム全体との 仮説に対してどう検証するのかの共通理解を持って、
09:04
それを最も効率的に検証する不審で 取り組むことが大切になりますと。
つまりディスカバリーとデリバリーが 2つの考え方であって、
デザインプロセス、実装プロセスという 2つのプロセスではないんだよというところが重要ですと。
というところですね。
そういうプロセスも必要ではあると思うので、
その2つの考え方と1つのプロセスが一緒になるとか 混合するというのはちょっと危険だなというところですね。
そうですね、ディスカバリーとデリバリーという 2つのトラックという考え方をしたことがなかったので、
これプロダクトでプロジェクトに導入するのが 面白そうだと思いました。
そもそも僕がデュアルトラックアジャイルというのを やったことがまだないので、
これはまあまあ気になったというので 今回記事を読んでいるんですけど、
割とマインドセットとか考え方の話なんですね。
OK、まずそのまま続けていきたいと思います。
なぜデュアルトラックアジャイルというのが 難しいのかというところですね。
ここまでデュアルトラックアジャイルは プロセスフレームワークではなくて
マインドセットが大切であること、
そしてそれを実践するためのプラクティスが あることというのを説明してきましたと。
ではなぜデュアルトラックアジャイルの 実践は難しいのでしょうかと。
それはプロダクトオーナーを含めたチームメンバー全員が
上記のマインドセット及びプラクティスを理解した上で
行う高度な開発戦術だからだというふうに言っています。
私がデュアルトラックアジャイルの実践が難しいと 考える点は主に2つありますと。
1点目はですね、プロダクトディスカバリの方法を 過度にプロセス化できないというふうに言っています。
以前スクラムは方法論もしくはプラクティス みたいな記事をノートで書きましたと。
そのリンクも記事内に貼っています。
スクラムはスプリントをこなすことで 学習が促進されるプロセスフレームワークになっています。
そうですね。
醸成していくことが大切ですからね。
一方プロダクトディスカバリというのは 都度状況に応じて検証方法を考え
前日のユーザーストーリーマッピングなどの プラクティスを選択しながら取り組む必要があります。
したがってデュアルトラックアジャイルを 一連のプロセスに落とそうとすると
失敗する可能性が高いと個人的に考えています。
なるほどね。
日々日々その都度変わるので、 確かにそうかもしれないですね。
プロセスでやろうとするとプロセスが いきなり破綻するので
よくありそうな感じがしましたね。
プロダクトオーナーをはじめ、 チームメンバーと相談しながら
仮説に応じてどう検証していくかの プラクティスを試しつつ
自分たちの成功パターンをたくさん作っていくことが やっぱり重要ですよと言っています。
そして成功パターンができてくると
プロセス化、仕組み化だったり 組織化したくなりますけども
その時に組織の自己組織化が阻害されることのないように
組織論の観点を意識することもとても重要ですと。
確かに成功パターンができたら速攻でそれを
プロセス化、仕組み化してどんどん組織に 組み込んでいくっていうのは
確かにやりますけども
その時にその自己組織化っていうのがやっぱり 組織の大事な観点の一つなので
その組織論の観点っていうのは確かに
意識しないと本末戦闘というか目的と あれが変わってくるなって感じはしましたね。
12:00
例えば、プロダクトディスカバリーを 少数のメンバーで実施してうまくいったために
スクラムチームとは別に プロダクトディスカバリーチームを作ってしまうので
これこそやっぱ目的変わってきますね。
このように組織として別チームを作って プロダクトディスカバリーを仕組み化してしまうと
デリバリーチームとディスカバリーチームに 分かれてしまって
デュアルトラックアジャイルのアンチパターンである ミニウォーターフォークが起きてしまいます。
多分このフィッシャーの方が冒頭で おっしゃられてましたけど
同じことを多分やられたんだと思います。
この会社さんでですね。
ミニウォーターフォール化したら 意味ないよね、結局は。
デュアルじゃなくて単純に2つのチームが 別々で動いているだけに過ぎないので。
一定程度のプロセス化していくことも もちろん必要ではあるんですが
スクラムの範囲を超えて 新たに権限の責任を作ってしまうと
チームからプロダクトディスカバリーの マインドセットがなくなり
プロセスが形外化し自己組織化というのが 阻害される可能性があるので
とても重意が必要になりますと言ってました。
これは本当に経験から出てくることだと思うので 重いなという感じですね。
以上1つ目ですね。
プロダクトディスカバリーの方法は過度に プロセス化できないというのが1つ目の
落とし穴というか、難しい点ですね。
2つ目の難しい点ですけど
ディスカバリーとデリバリーのバランスが 非常に重要であるというところが
難しい点だと言っています。
アジャイル開発というのはリスクの最適化というのを 行っていく開発手法になります。
デュアルトラックアジャイルでは プロダクトオーナーが
ある仮説に対してどのくらいディスカバリーに投資をし
どのタイミングでデリバリーするかという 最終的な判断の鍵を握ります。
この投資タイミングは
チームの状況、事業外境なども踏まえて
リスクを最適化しなければいけません。 さらにここに正解はありません。
プロダクトオーナーはチームと協力して
常にバランスを考え続ける必要があります。
プロダクトオーナーはビジネス側の
視点やタイミングを踏まえた上で
デリバリーすることを決めなければいけません。
これは確かにすごく難しいです。
プロダクトオーナーに全部責任が行くわけでは
もちろんないと思いますが、最終的な判断の鍵を握るのが
プロダクトオーナーです。
これは確かに難しいです。
答えは多分ないです。
ビジネスによってタイミングはマチマチだと思います。
ここは経験則になる気がします。
もちろんある程度の判断があると思いますが。
これは難しいです。
リアルトラックアジャイルはスクラムのような
プロセスフレームワークではありません。
常述の通り、リアルトラックアジャイルは高度な開発戦術であり
銀の弾丸ではありません。また、スクラムのような
プロセスフレームワークでもないと考えています。
私にとってはドイツのプロサッカーチームである
バイエル・ミュンヘンの戦術のようなイメージです。
この当時のお話なので今は違うかもしれません。
そんなイメージがあります。
いきなりプロセスを導入したからといってうまくいくものではないです。
参考としてサッカー漫画の青足という漫画が
共有されています。僕は青足という漫画を知りません。
15:02
ここに戦術的なお話が
多分入ってくると思います。
もし興味ある方はこの漫画を読んでみてください。
デュアルトラックアジャイルとはスクラムを通して
自己組織化された組織を作りつつ、またデュアルトラックアジャイルの
マインドセットとプラクティスを試しながら最も良い開発方法を
探し続けるものではないでしょうかと言っています。
まとめに入りますね。今回はデュアルトラックアジャイルを
実践する上でのポイントについて書きました。
デュアルトラックアジャイルを実践するにはマインドセットとプラクティスを
デュアルトラックアジャイルはスクラムのようなプロセスフレーマークではないという
二言に尽きるというところですね。
次回は頭プラスがデュアルトラックアジャイルとなりながら
どういう失敗と成功を繰り返してきたかというのを書く予定です。
私たちのデュアルトラックアジャイルもまだまだ試行錯誤中ですけど
その中で私たちなりの成功パターンを増やしていきたいと思います。
1年後に続きの記事が出ていたそうです。
デュアルトラックアジャイルを実践するコツというところがあります。
時間的にまだそんなにかかっていないので
読めるかな?実践するコツのところですね。
最初の方は冒頭おさらいをガッとしてますね。
プロダクトチームで仮説検証と価値の提供ですね。
いわゆるディスカバリとデリバリを分担するのではなくて
両輪で、そのためのプロダクトマネジメント考え方であり
プラクティスの集合体がデュアルトラックアジャイルですよ
みたいなところを喋ってますけども。
ちょっと喋れそうですが、
デュアルトラックアジャイルは
ちょっと喋れそうなんで、いきますかね。
一応後半の操作は
Many definitions of server-side renderingも
気にはなるんですけどもね。
いきますか。
やめます、これは。
多分皆さんの方で読んでいただいたらいいと思いますし
今記事さらさら読んだんですけど、この中に割と図が
ちょいちょい入ってきてて、この図が割とイメージしやすかったりもしますし
多分、ディスカバリーとデリバリーの言葉が
今初めて聞いた方にとっては頭がごっちゃーってなってる可能性は
全然あると思うので
デュアルトラックアジャイルってそもそも初めて聞くみたいな方も
いらっしゃることを鑑みすると、一旦ここで止めとけ。
皆さんの方で読んで咀嚼いただくのがいいと思いますので
記事は後ほどツイッターで
共有しますのでそこからリンクをたどってみてください。
結構面白いプロセスだったので
考え方とかマインセットとかあったので
いきなりこれをガンと導入できるかというともちろんそうではないですし
やっぱり難しいことも十分
本記事で語られてますので、それをどうしていくかというと
要素だけを取り入れるとか、まずはスクラムをやってみようとか
いろんな次のネクストラクションがあると思うんですけど
その参考になるなと思いましたというところで
後で皆さんの方で読んでみてくださいということですね。
後半はThe Many Definitions of Server-side Renderingで
サーバーサイドレンダリングについて定義しています。
言語化してますよというところを紹介している記事があるので
その辺を読んでいこうかなと思いました。
18:01
じゃあ行きましょう。
サーバーサイドレンダリングですね。
冒頭とか説明とか何もなしでいきなりフレームワークって入ってますね。
フレームワークって何でしょうかと。
What is Framework Even? って書いてますね。
このブログ記事のスタートは堅実だ。
から語られてますね。
JavaScriptのフレームワークって何だというところですね。
混乱させてそして救いますと。
Confuse them. Rescue them.
何ていうんですかね。
自業自得というか何ていうか。
これが相当リーダーシップのやり方だそうです。
View.jsとかPreactとかSvelte、Lit
もしくはSolid.jsなどのJavaScriptのコンポーネントフレームワークですね。
とかLibraryとかっていうのがあるんですけど、
それらはほぼ確実に聞いたことがあると思います。
これはNext.js、Next.js、Gatsby、Remix、Astro、SvelteKitなどの
JavaScriptのアプリケーションフレームワークと
混同しないようにしましょうと言ってます。
さて、じゃあBeatはどこに住んでるんですかというふうな問いですね。
Beatな。
アプリケーションフレームワークは通常1つまたはそれ以上
HiAstroっていうふうに書いてますけども
コンポーネントフレームワークを使用します。
さて、フレームワークの素晴らしい世界で時間を過ごす人々は
おそらくサーバーサイドレンダリング、しばしばSSRと略されます
という用語に遭遇したことがあるでしょう。
しかしSSRはコンポーネントフレームワークとアプリケーションフレームワークの
文脈で異なる定義がされていることをよく知らないかもしれません
というふうに言ってます。
これが冒頭だったんですね。
最初のほうの会話帳はよくわからなかったですね。
今の冒頭から入っていきましょう。
コンポーネントフレームワーク、SSRですね。
いろんな方々の定義がずっと語られてますけども
まずはRIT LABOSのSSRですね。
RITです。
RITテンプレートとコンポーネントをサーバーサイドでレンダリングするためのパッケージ
っていうのがこのRIT LABOSのSSRだと言ってます。
RITに関しては完全に自分たちのスコープの中の話をされてますね。
RITのテンプレートってあるんですけど
そのRITテンプレートとそのコンポーネントっていうのは
サーバーサイドでレンダリングするためのパッケージですよ
っていうふうに定義してます。
続いてSvelteDocsからSvelteの定義ですね。
SvelteのほうではSSRコードを生成する際に
ヘッド要素にマーカーを追加し
ハイドレーションがどれを置き換えるべきかというのが分かるようにします。
SSRの場合、Svelteっていうのは
サーバーサイドレンダリングに適したレンダーメソッドを持つオブジェクトを生成します
定義っていうよりもどういうことをやってますかっていうのを説明してますね。
なるほど。
ヘッド要素にマーカーを追加して
ハイドレーションがどれを置き換えるべきかっていうのを明示的に分かるようにしてるんですね。
そういうことを裏でやってる感じですね。
SSRの場合、Svelteはサーバーサイドレンダリングに適した
レンダーメソッドを持つオブジェクトっていうのを作ってます。
21:00
あんまりSvelteのコードを読んだことないですけど
これちょっと気になりましたね。
続いてVueですね。
Vueサーバーサイドレンダリングガイドっていう記事。
ブログから引用されてますと。
Vueの方はですね。
しかし同じコンポーネントをサーバー上で
HTMLストリングにレンダリングし、ブラウザに直接送信し
最終的に静的なワークアップをクライアント上で
完全にインタラクティブなアプリにハイドレートすることも可能になります。
っていうのがVueの記事です。
同じコンポーネントをサーバー上で
HTMLストリングにレンダリングし、直接送信し
最終的に静的なワークアップをクライアント上でできる。
いわゆるハイドレートすることも一応Vueではできますよという風に言ってます。
続いてPreactですね。
ReactじゃなくてPreactなんだ。
サーバーサイドレンダリングDocsのところからの引用です。
サーバーサイドレンダリングはアプリケーションを
HTML文字列にレンダリングし、クライアントに送信することで
コード時間を改善することができるというような書き方をしてます。
VueとPreactのドキュメントは結構似てるなって感じですね。
Svelteに関しては何かやってることを説明してて、
Litは自分たちのものをとにかくHTMLとして
出すことができるためのパッケージですよという話をしてましたね。
コンポーネントフレームワークでは
SSRをコンポーネントの静的なレンダリングと定義しています。
コンポーネントを与えればレンダリングされたHTMLが変えれます
というところがコンポーネントフレームワークの定義だという風に言ってますね。
この辺はまあまあそうでしょうねって感じはありますけど。
今のがコンポーネントフレームワークSSRで、
それはLitとかSvelteとかVueとかPreactだそうですね。
続いてアプリケーションフレームワークですね。
これは後者に出てきたNextだったりSvelteキットだったりみたいなところですね。
この辺はアプリケーションフレームワークと言ってて、
VueとかPreactとかその原点的なものの方を
コンポーネントフレームワークって今回は定義しているそうですね。
じゃあアプリケーションフレームワークの方の定義から見ていきましょう。
まず一つ目はNext.jsサーバーサイドレンダリングっていう記事からの引用ですね。
サーバーサイドレンダリングっていうのは、
ブラウザーでレンダリングする代わりにサーバーにウェブページを表示することで
貢献するアプリケーション能力の一つだと言ってます。
サーバーサイドは完全にレンダリングされたページをクライアントに送信します。
クライアントのJavaScriptバンドルが引き続き
Vue.jsアプリがハイドレードすることを受け取りますと言ってますね。
さてここまではいい感じです。
コンポーネントフレームワークの定義と合致しているようですね。
ここまでは言わずいいですよという感じですね。
続いて同じ記事から続きの記述があるんですけど、
ただNode.jsのサーバーが必要になりますと。
ウェブページをレンダリングするためにはJavaScriptの環境が必要です。
Vueアプリケーションを実行するために
Node.jsサーバーを設定する必要がありますというのが
24:00
そのNuxtのサーバーサイドレンダリングの記事だそうです。
ここでちょっとだけ待ってくださいと。
マークアップをサーバーサイドでレンダリングするために
ビルドサーバーを使用することはできないのでしょうかと。
コンポーネントフレームワークの定義では
Node.jsのリクエストごとのサーバーについて言及されていません。
言うまでもなくサーバーは多くの場合
リクエストごとに実行されますけどね。
また言うまでもなくサーバーというのは
静的ビルドよりもコストがかかることも多いんですよ
というふうに言ってますと。
この辺について言及が今のところないね
というところをお話しされていました。
続いていきましょう。
続いてですけども、
Next.jsサーバーサイドレンダリングDocsですね。
ところをいきましょう。
Next.jsはどういうふうに書いてるかというと
SSRまたはダイナミックレンダリングと呼ばれたりする
ものになりますと。
Nextではプリレンダリングという概念もありますから
そこと明示的に言葉を分けてますね。
SSRまたはダイナミックレンダリングと呼ばれます。
サーバーサイドレンダリングを使用するページでは
リクエストごとにページのHTMLが作られます
というのがNextの記述ですと。
もう一つの定義は
ランタイムサーバーがリクエストごとに
HTMLを生成する必要があるというふうに
定義をしてますというところですね。
ランタイムごとにというところですね。
これが重要だという話にしてます。
また続いていきましょう。
続いてはGatsbyですね。
GatsbyのユーザーサーバーサイドレンダリングDocsですね。
SSRというのはGatsbyのレンダリングオプションの一つで
ユーザーがページにアクセスしたときに
取得するデータを使って
ページを事前にレンダリングすることができます。
SSRよりもスタティックサイドジェネレーションですね。
SSGのほうです。
SSGやディファードスタティックジェネレーション
DSGを使用することが推奨されていますけれども
SSRを必要とするケースももちろんあるかもしれませんね
というふうに言っています。
あんまりSSR、好意的じゃないですね。
よりも現代フロント側のほうは
SSGとかDSGのほうがいいんじゃないの
というふうに推奨されていますと言ってますね。
それもそれでわからなくはないんですけどね。
静的にできるんだったら
それに越したことはもちろんないですからね。
またですね、
Another Server Side
Server Based Definition from Gatsbyですね。
Gatsbyからのもう一つ別の
サーバー側の観点からの提供をしていますと。
SSRを有効にすると
以下のことが可能になりますと。
アプリのログイン状態のセッションを実装するとか
フェッチで動的に呼び出されて
APIからデータをレンダリングするとか
アダプターを使用して
サイトをホストにデプロイするとかですね。
みたいなこともできたりしますと。
はい。
以上の中その後はですね
なんだ
Astroですね。
Astroのサーバーサーベル連絡に関するドキュメントも
ありますよと言ってますね。
失礼。
今のがAstroの定義なんですね。
SSRを有効にすると
アプリのログイン状態のセッションを実装したり
フェッチで動的に呼び出されたAPIから
データをレンダリングしたり
アダプターを使用して
サイトをホストにデプロイするとかが
できたりするようになりますよってですね。
これがAstroのサーバーサーベル連絡に関する
27:01
ドキュメントでしたということです。
Astroのドキュメントには明示されていませんけど
これら間違いなくランタイムサーバーの
機能だという風に言ってますね。
とりあえずリクエストごとの
ランタイムサーバーが必要になるというところが
SSRのもう一つのポイントだというところですね。
そりゃそうでしょうねって感じです。
そのためにはノードJSサーバーが
必要なのも分かりますと。
続いてGISTですね。
The GISTってところですけど
GISTからもいくつかありそうなので
その辺をピックアップしているって感じですね。
アプリケーションフレームワークでは
SSGの代わりとしてSSRを定義することが
最も多いらしいです。
ランタイムサーバーというのはリクエストに応じて
コンポーネントをレンダリングするために使われます。
コンポーネントフレームワークというのは
SSRコンポーネント定義から静的なHTMLを
生成することとして定義しています。
彼らはこれがビルド時に起こるべきか
あるいはリクエスト時に起こるべきかについて
何の優先順位も提供しないということですね。
言われてみれば確かにそうですね。
なんとなく先に
ビルド時に起きるかリクエスト時に起きるかは
確かに状況によるかもしれない。
一つの用語と二つの文脈
二つの定義
一つの用語とのSSRですと
文脈というのもありまして二つの定義もあります。
この違いを理解して
異なるコンテキストを生き生きする時に
心に留めることが重要ですと言っています。
私の直感では
アプリケーションフレームワークの定義が勝つ
という風に思っています。
いわゆるネクストとかナクストみたいな
アプリケーションフレームワークの定義の方が勝つという風に
優先だよという風に思っています。
コンポーネントフレームワークの定義をコンポーネントSSR
ということに今していますと
明示的に言葉を挙げているんですね。
またSSRというのは無料ではない。
これらのSSRフレームワークというのは
クリエイターが利益を得るために存在しています
という風に言っています。
それは確かにそうかもしれないですね。
開発者が必要なものだと
するというのは確かにそうかもしれないですね。
この過剰な定義がもたらす
最悪の結果はコンポーネントフレームワークの
SSRはnode.jsサーバーが必要とする
と人々が誤解することでしょう。
私の考え方ですね。
もちろんそんなことはないんですよと。
私は技術用語の曖昧さが利益のために
利用されるのを見たくありません。
ただ静的ビルドを使えばnode.jsサーバーや
サーバーレスカンスアダプターみたいな
あるいは不要な、そしてよりコストのかかる
代替品なしでコンポーネントSSR
プリレンダリングマークアップとも呼ばれますけど
っていうのを実装できるというのは
知っておいてもいいんじゃないのという話をしていました。
ところですね。
決してnode.jsサーバーが
必要だという風に
言うことはないんだよというところも言ってますね。
いろんなことに定義を書いてますけど
その辺の誤解とか解釈がないように
まずはその一つの定義、二つの文脈と
二つの定義ですね。
みたいな言葉の理解と
どうやったら実現できるかというのを
ちゃんと理解しておいて、サーバー制度で
なるべく向き合うのがいいんじゃないかというところでした。
というところで
本記事は終了になりますね。
ちょっと、なんていうか
ハイコンテキストな記事だったというか
冒頭の方の説明とかもちょっと分かりづらかったので
もうちょっと解説があった方が嬉しかったなというのは
ありますけど、一応こういう記事だったなというところでした。
30:00
一応定義としては
確かに途中に出てきた
リクエストの方を優先するのか
それともビルドの時のキックを優先するのか
というところの話は
確かにここは深掘りする余地はあるなという風に思いました。
あとは定義についてですね。
SSRの定義について
いわゆるコンポーネントフレームワークの定義と
アプリケーションフレームワークの定義が
若干違っていて
本記事の方の中では
アプリケーションフレームワークですね。
いわゆるネクストとかナクストの定義の方を
優先するという風に言ってました。
リアクトだったりビルドだったりスベルトだったり
いうようなコンポーネントフレームワークの定義よりは
そっちの方が優先で
大事というか重要
重きがあるんだろうなというのを感じはしました。
もちろんサーバー側の方も
扱うフレームワークなのでというのは
なんとなく読んでて思いましたけどね。
というところでした。
難しい記事だったり曖昧な記事だったり
気はしますけど
一応そういう観点を意識して
今後も実装していくというのは確かに大事な話かなと
思いましたね。
じゃあ本日時間も過ぎましたので
今日はここで以上にしたいかなと思います。
また明日何を読むかは
悩ましいんですけど
また記事見作ろうと読んでいこうかなと思います。
最後のところだけ
補足じゃないんですけど
リアクトがですね
サーバー
サーバーレンダリング
コンポーネントをサーバーサイトでレンダリングするみたいな
機能があるじゃないですか
だいぶ前に読んだんですけど
リアクトの公式ドキュメントでもあるので
その辺見てみてください。
いわゆるページ単位じゃなくて
コンポーネント単位でサーバーサイトでレンダリングをして
グラウザの方でハイドレイとして
HTMLとしてレンダリングするみたいな技術を
リアクトの方で
随時検討して
実装しているそうなんですよね。
その辺もちろんNEXTとも連携してやってますし
他のコンポーネントとかの
フレームワークとかどうなるかちょっとわからないですけど
っていう概念があるので
その
本当に名前忘れましたね。
サーバーコンポーネントっていう名前が一応あるんですけど
これが出たときにまた
フロントエンドの今言った
コンポーネントフレームワークとアプリケーションフレームワークの
サーバーサイトレンダリングに関する
また新たな観点というか
考え方というのが生まれる気がするので
これ多分時間の問題と思います。
今すでに実装を始めているので
今後起きると思うので
頭の片隅に届いていいと思いましたね。
どこまでそのアプリケーションフレームワーク
じゃなくてコンポーネントフレームワークか
リアクトとかの方でできるようにするのか
っていうのは別の観点がありますけど
そこが僕はちょっと
興味というか期待をしている感じですね。
そうすると問題は
アプリケーションフレームワークですね。
NEXT.jsとの住み分けとかどうするのか
という別の議論が出てくると思うので
それはまず出てきてからですね
どうして出してくるのかというのは
まずの意味かもしれないなと思いました。
というところです。
じゃあ本日は以上にしたいかなと思います。
あと恐怖、除いてあと1日ですね。
頑張っていけたらなと思います。
ではでは、以上にしたいと思います。
お疲れ様でした。
