はじめに

今年の 2023年5月に Next.js の v13.4 がリリースされ App Router が Stable になり Vercel 推奨の実装方式となりました。さらに10月 Next Conf にて、 Next.js v14 がリリースされ App Router を代表する新機能である Server Actions が Stable になりました。

App Router はこれからのWeb開発の未来を担うフレームワークになっていくことが予想されており注目度の高い技術です。一方、これまでの Pages Router からの変更点の多さ、機能の興味深さ、設計の複雑さ、動作の不安定さなども含め、さまざまな要因でいまでもたくさん議論になっています。

今後どこかのタイミングで App Router へ対応する必要があることは明らかなものの、技術の不安定さが気になる上に、ある程度規模の大きい組織になると事業側に「なぜ案件開発の工数を投げ打ってでも App Router にすべきなのか？」を説明する責任が出てくる方もいることと思います。

この記事では、 Next js v14 で開発チームがこれからどのように事業的な貢献をしていくことができるか について自分なりに考察したいと思います。

Next.js v14 の新機能

Next.js そのものや v14 でのアップデート内容、 App Router について、また Server Components や Server Actions については、この記事では詳しく触れません。プログレッシブエンハンスメントと Intercepting Routes (と Parallel Routes) についてだけ後述する本題の内容のために少し触れます。

プログレッシブエンハンスメント

Next.js で期待されている一つの特徴がプログレッシブエンハンスメントです。これは Next.js 特有の機能ではなく、Remix や Svelte などの他のフレームワークでも意識されている機能です。これはつまり特殊な機能の一つが追加されているわけではなく、これからの Web アプリのスタンダードな機能の一つになっていくと言えます。

例えばフォームの送信機能でいえば、

JavaScript が動作する環境では、 JavaScript を利用してリアルタイムなバリデーションなどリッチな機能を提供しながらのデータ送信を行うことができ、
JavaScript が動作しない環境でも、クラシカルな Form HTML タグによるデータ送信を行うことができます。

もっと身近な例で言えば next/link を使いリンクタグを配置していると、

JavaScript が動作する環境では、画面描画が CSR でリンク遷移が行われる
JavaScript が動作しない環境でも、ただの a タグとして動作しハードナビゲーションにはなるがリンク遷移が行われる

ことになります。もし JavaScript が動作しない環境ではリンク遷移が行えないとしたら、サービスとして致命的ですよね。これもプログレッシブエンハンスメントの一種と言えると思います。

ここでいう「JavaScript が動作しない環境」は、ブラウザの設定などで JavaScript を有効にしていないユーザーのことだけではなく、 必要な JavaScript ファイルがダウンロードされて利用できるようになるまでの間のような JavaScript がまだ有効になっていないユーザー のことも含めています。むしろプログレッシブエンハンスメントが語られる背景はこちらのユーザー体験を向上させることが目的にされていることの方が多いと思います*1。

最近一部界隈ではアクセシビリティが注目されることが増えてきましたが、僕個人的には プログレッシブエンハンスメントもアクセシビリティの一種 として捉えて良いものだと思っています。

特に大規模サービスでは、ユーザーの絶対数が多い分、ギガが足りなかったり低速なネットワーク品質を使ったりしているユーザーたちをも救うことはとても重要な役割があり、これはサービスにとってとても大事なアプローチになると思っています。

Intercepting Routes

Next v14 の特徴といえる機能の一つに Intercepting Routes という機能があります。一覧画面から詳細画面への遷移というよくあるユースケースで、詳細画面への直接遷移とは異なるUXを提供するものです。*2 これはもはや実際の動きを見た方が早いので、公式から辿れるサンプルに参照し、一覧からの詳細画面への遷移と直接遷移での詳細画面表示を比較してもらうと分かりやすいと思います。サンプルコードは、こちらです。

またよりリッチで実際にサービスとして活用されている例でいえば、直接 Intercepting Routes のような UX が提供されている Web 版の Instagram もイメージしやすいと思います。 PC版のブラウザでアクセスしていただき、一覧画面から詳細画面に遷移したり、リロードしたりしてもらえるとどういう機能かわかると思います。 Instagram の場合は、モーダル上で詳細画面→別の詳細画面への遷移も可能なので、より UX のリッチさが伝わることと思います。

このように同じ詳細画面を示す URL に対して、

一覧画面から詳細画面への遷移時はモーダルによる表示
詳細画面への直接遷移 (他のサイトからの流入や URL 入力による遷移 etc.) は、ページ全体での表示

という二種類の異なる UX を提供することが簡易的に実装できる技術になっています。

事業的貢献への考察

プログレッシブな仕様検討への進化

これらの新しい要素が提供するものはユーザーへの更なる Web 体験の向上に他なりませんが、その一方でこれらの技術の登場によって要件定義もプログレッシブな形で定義する必要が出てきました。

これまでの仕様は「アプリが使える状態になったとき」をトリガーにした、0か1かの仕様になっていることがほとんどだと思います。

しかし、プログレッシブエンハンスメントや Intercepting Routes の登場により、JavaScript が利用できない期間や、次の画面に遷移するときまで、ユーザーへの体験価値をプログレッシブに向上させることができるようになってきています。

つまり、 仕様自体も0か1かではなく、状況に応じた仕様の定義が必要になる と考えています。

企画ディレクターにとっても 「これまでリーチできなかったユーザー体験の向上ができること」 は魅力に感じてもらえると思います。

もちろん Next.js v14 App Router でなくても工数をかければこれらの機能を実装することはできます。ただ App Router を導入してこれらの技術装着を容易にしておくことで、将来進化し続ける当たり前品質に追いついていくための礎になります。企画ディレクターに Web とプロダクトの進化について理解してもらうことで、導入に少しでも理解を示してもらえるのではないかと考えています。

エンジニアの事業的貢献

この新しい時代の流れに対して僕が思う一番重要なことは、 企画ディレクター側から提案される開発への要求とは直接的に紐づかない ということです。

例えば、JavaScript が動作するまでの期間にフォームのサブミットができないことや一覧画面から詳細画面への遷移時に画面遷移の UX が悪いという課題は、よほど Web 開発に積極的な企画ディレクターではない限り、解決すべき要求として提示されることは滅多にないと思います。*3

つまり 開発側からこれらを新しい機能仕様を提案する 必要があります。

企画ディレクターがユーザーに対してやりたいと思っている要求から実際の仕様に落とし込む要件までの間にエンジニアが入り込むことで、ユーザー体験として一番いい形を要件定義できるようになるはずだと思っています。

エンジニアが企画ディレクターの仕事を奪うのではなく、お互いに得意な領域でサポートし合いながら、エンジニアが要件検討から実装までよりシームレスに関わっていくことが必要になっていくと思っています。

これが上手くいけば、

企画ディレクター側としては、自分たちでは考えが及ばない範囲に対して、これまで以上のユーザー体験の向上にリーチすることができる
開発側としては、自分たちの目指したい技術選定を要件検討とセットで提案することでチームとして納得感を持って導入できる

となるのが理想です。*4

あともう一点補足するとしたら、我々エンジニアに求められるのは、より複雑になっていく仕様に対して 「そこまで大きな追加工数がかからない」という技術力 がこれまでに増して必要になりますね^^

企画・開発ともに、 「ユーザーに対して素晴らしい体験を享受してもらうこと」 を共通の目標として掲げた上で、それぞれが貢献できることをお互いに実施することで、自分たちの採りうる最大限の要件を作り出すことが今後より一層必要になると思っています。

おわりに

この記事では Next.js の App Router の登場に対してどういう事業的貢献ができるか考察しました。

プログレッシブエンハンスメント
Intercepting Routes

これらの技術に焦点をあてて、これからは仕様そのものもプログレッシブになっていくことと、事業側である企画ディレクターの要件検討に開発が入り込む必要性について書きました。なかなか開発から要件を取り込むことは難しい障壁がたくさんありますが少しずつ実施しつつ、将来的には自分のプロダクトに App Router を導入していければと思っています。

*1:ちなみにこのような JavaScript が利用できない期間を TTI (Time To Interactive) と呼んだりします。さまざまな JS / Web フレームワーク（例えば React ）で、フレームワークのための JavaScript のダウンロードやハイドレーションに時間がかかってしまうことで TTI が問題視されることがあり、プログレッシブエンハンスメントのような機能がフィーチャーされている認識です。

*2:実際にはParallel routesとの組み合わせによる実現になりますが、簡単のため説明を省いています。

*3:もちろん少し遠い未来にこれらの機能が当たり前になっていくことで、企画ディレクター側から「なになにのサイトと同じように実装してください」という要求が来ることはあるかもしれません。しかし、現時点でプログレッシブエンハンスメントと Intercepting Routes はそこまでメジャーな機能とは言えない状況です。

*4:理想の形にするのが簡単ではないことは身をもって体感中です