SDD(仕様駆動開発)ではなぜUI仕様を最初に書いてはいけないのか
SDD(仕様駆動開発)で最も失敗しやすいのが「最初にUI仕様を書く」ことです。
直感的には正しそうに見えます。画面が決まれば開発しやすいからです。
しかし実務では、UI仕様から始めたプロジェクトほど手戻りが増えます。
理由は単純で、UIはシステムの本質ではなく「表現」だからです。
仕様駆動開発が扱うべき対象は画面ではありません。振る舞いです。
UIは仕様ではなく実装の一部
ログイン機能を例にします。
UI中心で仕様を作ると、次のような内容になります。
- ID入力欄を配置
- パスワード欄を配置
- ログインボタンを配置
- エラー文言を表示
これは仕様のように見えますが、実際には画面設計です。
この段階では、システムが何をするかは定義されていません。
例えば次の問いに答えられません。
- 何回失敗したらロックするのか
- セッションはいつ切れるのか
- 多重ログインは許可するのか
- パスワード変更後の既存セッションはどうなるか
UIをいくら精密に書いても、これらは決まりません。
つまりUI仕様だけではバグを防げないのです。
なぜUIから始めると手戻りが起きるのか
ソフトウェアには依存関係があります。
本来の順序は次です。
| 順序 | 内容 |
| 1 | 振る舞い（ビジネスルール） |
| 2 | アプリケーションロジック |
| 3 | UI |
しかしUIから始めると逆転します。
これを設計の逆流と呼びます。
典型例を挙げます。
最初に画面を設計します。
その後、次のような要件が判明します。
- 管理者と一般ユーザーで権限が違う
- 承認フローが必要
- 入力途中保存が必要
するとUIが成立しなくなります。
結果として画面を作り直します。
これが大きな手戻りです。
問題はUIが悪いのではありません。
UIは最終成果物なので、依存先が多すぎるのです。
UI中心開発で発生する典型的な不具合
「ボタンはあるが動作が決まっていない」
UIから始めると、まず画面が完成します。
しかし、押したときの挙動が曖昧になります。
- 保存ボタンはどのタイミングで成功か
- エラーはどこまで入力させるか
- 自動保存は必要か
これらは画面からは決まりません。
その結果、実装段階で議論が始まります。
「例外処理が後付けになる」
UIは正常系を前提に作られます。
ユーザーが期待通り操作する前提です。
しかし実際のシステムの難しさは例外系にあります。
- ネットワーク切断
- 二重送信
- セッション切れ
- 権限不足
UI後付けで例外対応すると、画面が破綻します。
エラーメッセージだらけのUIになります。
「APIと画面の仕様がズレる」
バックエンドはデータ整合性を重視します。
フロントエンドは操作性を重視します。
UI先行では、APIが後から作られます。
このときズレが発生します。
例：
- UIは即時保存
- APIはトランザクション単位
結果として無理な実装（疑似保存、暫定データ）が増えます。
これが技術的負債になります。
SDD(仕様駆動開発)で最初に書くべきもの
UIではなく「ユースケースの振る舞い」です。
具体的には受け入れ基準です。
例：ユーザー登録
- メールアドレスが重複している場合は登録できない
- 確認URLの有効期限は24時間
- URL使用後は再登録不可
この段階では画面は存在しません。
しかし、システムの挙動は完全に定義されています。
この状態で初めてUIを設計します。
すると画面の意味が明確になります。
- なぜエラーメッセージが必要か
- なぜ確認画面が必要か
- なぜ再送ボタンが必要か
UIは結果として導かれます。
UIを後にすると何が良いのか
画面議論が減る
UI先行では、会議がこうなります。
- ボタンの位置
- 色
- 余白
しかし振る舞いが先に決まると、議論はこう変わります。
- ユーザーはここで迷うか
- 操作は最小か
- 誤操作を防げるか
本質的なUXの議論になります。
API設計が安定する
振る舞いが定義されているため、APIの責務が明確になります。
結果としてフロントとバックの衝突が減ります。
テストが書ける
UI仕様からはテストを書けません。
振る舞い仕様からは書けます。
テスト可能性が上がると、品質が安定します。
注意点：UIを軽視するわけではない
UIを後にするのは、重要でないからではありません。
重要だから最後に決めます。
UIはユーザーとの接点です。
そのため、最も影響範囲が大きい部分です。
ビジネスルールが固まっていない状態でUIを確定すると、変更コストが最大になります。
まとめ
SDD(仕様駆動開発)では、画面を設計する前に振る舞いを設計します。
UIは仕様の出発点ではなく到達点です。
UIから始める開発は分かりやすく感じます。
しかしそれは設計を後回しにしているだけです。
最初に書くべきなのは画面ではありません。
「このシステムはどの条件で、どう振る舞うか」です。
その1機能の受け入れ基準を書いてから画面を描いてみてください。
UIの迷いが驚くほど減ります。
画面設計が難しいのは、デザインの問題ではなく仕様の問題であることに気づくはずです。
