Next.js に App Router という新しいルーティングの仕組みが入りました。
サーバーコンポーネントを中心とした、かなり大きな設計変更です。
受託案件で今すぐ採用すべきかを検討しました。
何が変わるのか
従来（Pages Router）は「ページ単位でサーバー処理を書く」構成でした。
新しい方式では、コンポーネント単位でサーバー実行かクライアント実行かを分ける
考え方になります。
従来: ページ全体のデータ取得を1か所で書く
新方式: 各コンポーネントが必要なデータを自分で取りに行く
データ取得がコンポーネントに閉じるので、共通レイアウトの再描画を避けられる
といった利点があります。
受託で採用するかの判断基準
技術的な優劣ではなく、次の3点で判断しています。
1. 情報が十分にあるか
新しい仕組みは、詰まったときに検索しても答えが出てきません。
自分で仕様を読んで解決できる範囲を超えると、見積もりが崩れます。
2. エコシステムが追いついているか
認証、フォーム、UIライブラリなどが新方式に対応していないと、
「ライブラリを使えないので自作する」が発生します。ここが一番の地雷です。
3. 引き継げるか
納品後に別の開発者が触る可能性がある場合、
その時点で一般的な書き方を選んでおくほうが親切です。
現時点での判断
- 自社サービス … 試す。壊れても自分で直せる
- 受託の新規案件 … 従来方式を選ぶ。安定してから移行する
- 既存案件の移行 … やらない。移行コストに見合う利点が無い
新しい仕組みは「安定してから乗る」で、実務上ほぼ損をしません。
先行して得られるのは経験であって、納品物の品質ではないからです。
ただし触っておく
採用しないことと、触らないことは別です。
自社サービスや検証用のプロジェクトで手を動かしておくと、
採用可能になった瞬間に判断できます。
「安定してから」と言い続けて、結局3年遅れるのが最悪のパターンです。
まとめ
| 判断軸 | 質問 |
|---|---|
| 情報量 | 詰まったとき自力で抜けられるか |
| エコシステム | 使いたいライブラリが対応しているか |
| 引き継ぎ | 3年後の開発者が読めるか |
受託では「壊れたときに直せるか」が採用可否のほぼすべてです。
新しさは、自社サービスで先に払っておきます。