- フロントエンド主導開発は可能。ただし条件を満たさないと破綻する
- フロントエンド主導開発とは何を指すのか
- 成立しないケース
- 成立する条件
- SDDとの関係
- 注意点 ― 最も多い失敗
- まとめ ― 主導するのは画面ではなく“契約”
フロントエンド主導開発は可能。ただし条件を満たさないと破綻する
SDD（仕様駆動開発）を実践していると、よく議論になるテーマがあります。
「フロントエンド主導で開発しても成立するのか」という問題です。
近年の開発では、画面の複雑さがサーバ側より大きくなることも珍しくありません。
そのため、フロントエンドから仕様を固めていく進め方を選ぶチームも増えています。
結論から言うと、フロントエンド主導開発は成立します。
ただし、それは「UIから仕様を決める」という意味ではありません。
成立するかどうかの分岐点は、
フロントエンドが“表示層”なのか“振る舞い層”なのかです。
ここを誤ると、開発の後半でAPIとUIが衝突し始めます。
フロントエンド主導開発とは何を指すのか
ここでいうフロントエンド主導開発とは、次の状態を指します。
- 画面実装を先行する
- APIは後から接続する
- モックサーバで開発する
- UIの挙動を先に確定させる
一見するとUI駆動開発と同じに見えます。
しかしSDDで成立するフロントエンド主導開発は、UI中心ではありません。
中心にあるのは「振る舞い」です。
つまり、画面を作るのではなく、クライアントの仕様を先に確定させる開発です。
成立しないケース
まず破綻するパターンを整理します。
- デザインカンプを仕様とする
- APIレスポンスを後で考える
- 画面の都合でデータ構造を決める
- サーバがUIに従う
この場合、次が起きます。
- APIが肥大化する
- エンドポイントが画面単位になる
- 同じロジックが複数箇所に実装される
- バリデーションが分裂する
これはフロントエンド主導ではなく「UI依存開発」です。
SDDとは両立しません。
成立する条件
成立するフロントエンド主導開発には明確な条件があります。
1. クライアントの状態モデルが存在する**
画面単位ではなく、状態単位で設計されていることが必要です。
例：注文画面
×
画面A、画面B、画面C
○
カート状態、支払い状態、確定状態
フロントエンドが状態遷移を持つと、仕様を表現できます。
2. API契約が先に定義される**
実装より先に契約を決めます。
- リクエスト構造
- レスポンス構造
- エラー形式
これをモックサーバで固定します。
サーバはこの契約に従って実装します。
ここで重要なのは、APIを「画面のため」に設計しないことです。
ユースケースのために設計します。
3. ビジネスルールの責務分離**
フロントエンドでやってはいけない処理があります。
- 課金計算
- 在庫確定
- 権限判定
- 永続状態の確定
これをUIで持つと、サーバと整合が崩れます。
フロントエンドは「入力の整形」と「状態表示」を担当します。
ドメインルールはサーバが担当します。
SDDとの関係
SDDでは仕様は「実行可能」である必要があります。
フロントエンド主導開発で仕様を表現する方法は、コンポーネントの振る舞いテストです。
例：
- 未ログイン時は購入ボタン無効
- 決済中は再送不可
- エラー時は再試行表示
これをテストとして書きます。
これがクライアント仕様になります。
次にAPI契約テストを書きます。
そしてサーバ実装を行います。
この順序であれば、フロントエンド主導でもSDDになります。
注意点 ― 最も多い失敗
最も多い問題は「二重の仕様」です。
フロントエンドとバックエンドの両方で、同じルールを実装してしまう状態です。
- フロント：入力制限
- サーバ：バリデーション
一見安全ですが、変更時に必ずズレます。
結果として不具合が発生します。
対策は明確です。
真のルールは必ずサーバに置き、フロントは補助に限定することです。
まとめ ― 主導するのは画面ではなく“契約”
フロントエンド主導開発が成立するかどうかは、
どちらが先にコードを書くかでは決まりません。
どちらが仕様を持つかで決まります。
画面が仕様を持つと破綻します。
契約が仕様を持つと安定します。
フロントエンド主導とは、UI優先ではありません。
クライアント仕様を先に定義し、それを契約としてサーバに接続する開発です。
この形を取れたとき、フロントエンド主導開発はSDDと矛盾せず、むしろ高速に回り始めます。
