UI駆動型SDDの特徴と危険性を解説

仕様駆動開発 SDD 設計 テスト アーキテクチャ

UI駆動型SDDは「最も分かりやすいが、最も壊れやすい仕様」になりやすい

SDD（仕様駆動開発）に取り組み始めたチームが、最初に選びがちな方法があります。
それが「UI駆動型SDD」です。

つまり、画面から仕様を決めていく開発です。

ワイヤーフレーム、デザインカンプ、モック画面、Figmaの遷移図などを中心にして
「この画面でこのボタンを押したらこう動く」
という形で仕様を確定させていくアプローチです。

直感的ですし、非エンジニアとも共有しやすい。
一見すると理想的なSDDに見えます。

しかし実際の現場では、最も事故が起きやすいSDDの形でもあります。
理由は単純で、UIは仕様の“結果”であって“本体”ではないからです。

この違いを理解しないままUIを仕様の中心に据えると、開発が進むほど仕様が崩壊します。

この記事では、UI駆動型SDDの特徴と、なぜ危険になりやすいのかを具体的に解説します。

UI駆動型SDDとは何か

UI駆動型SDDとは、画面を起点に仕様を確定させる仕様駆動開発です。

典型的には次の流れになります。

  • 画面モックを作る
  • 遷移図を作る
  • ボタン操作を決める
  • APIを後から決める
  • 内部ロジックを実装する

この時、仕様はどこに書かれるかというと「画面」です。
つまり、画面が仕様書になります。

ここが重要なポイントです。

SDDは本来「実行可能な仕様」を中心にします。
ところがUI駆動型SDDでは、仕様が“観察可能な挙動”ではなく“見た目の構造”に依存します。

この瞬間、仕様はテスト不能なものになります。

なぜUIは仕様として扱いやすいのか

理由は3つあります。

  • 誰でも理解できる
  • レビューしやすい
  • 合意形成が早い

特にビジネスサイドとのコミュニケーションでは非常に強力です。
会議で画面を見せれば、その場で意思決定できます。

ここまではメリットです。
問題は開発が始まってから起きます。

UI駆動型SDDの最大の問題 ― 仕様の「因果」が逆転する

本来の仕様の因果関係は次の順序です。

業務ルール → ドメイン仕様 → API仕様 → UI

しかしUI駆動型SDDでは、これが逆転します。

UI → API → ロジック → 業務ルール（後付け）

つまり、業務ルールが後から決まります。

ここで起きるのが「仕様が揺れる」という現象です。

具体例：会員登録画面

たとえば会員登録画面を先に作ったとします。

入力項目：

  • メールアドレス
  • パスワード
  • 名前
  • 電話番号

この時点では自然に見えます。
しかし後から業務ルールが入ります。

「電話番号は任意」
「海外ユーザー対応」
「メール認証必須」
「同一メール重複禁止」

この瞬間、UIが仕様を表していない状態になります。
そして次の問題が起きます。

  • APIが変わる
  • DBが変わる
  • バリデーションが変わる
  • テストが壊れる

つまり、UI中心の仕様はドメイン変更に耐えません。

UI駆動型SDDが壊れる技術的理由

理由は「UIは状態遷移を持たない」からです。

正確に言うと、UIは状態遷移を“表現する”だけで、定義しません。

SDDで重要なのは次です。

「どの状態からどの状態へ遷移できるか」

ところがUI仕様書に書かれるのは：

  • ボタンがある
  • 画面がある
  • 入力欄がある

これは状態ではありません。
単なる表示です。

このため、次のような不具合が発生します。

  • 押してはいけないボタンが押せる
  • 遷移できないはずの画面に遷移する
  • 並行操作で破綻する

これは実装ミスではなく、仕様欠陥です。

UI駆動型SDDの典型的な失敗パターン

現場で非常に多いパターンがあります。

1. 「確認画面」問題

入力 → 確認 → 完了

このフローをUIから設計すると、次が未定義になります。

  • 確認画面で戻った場合の状態
  • 多重送信
  • 二重登録
  • 同時編集

UIには「見えていない状態」が存在します。
しかし仕様はそれを扱わなければいけません。

2. APIがUI専用になる

UIを先に作るとAPIはこうなります。

/createUserFromForm
/updateProfileFromScreen

これはドメインAPIではなく画面APIです。
結果として：

  • 再利用不能
  • テスト不能
  • モバイル対応不能

になります。

3. E2Eテストが仕様書になる

UI駆動型SDDでは、最終的にE2Eテストが仕様の代替になります。
しかしE2Eは確認手段であって仕様ではありません。

E2Eが壊れるたびに仕様が揺れます。

UI駆動型SDDのリスク

最も大きなリスクは「開発後半で仕様が決まる」ことです。

つまり、実装してから仕様が明確になります。

この時に起きるのが次です。

  • 大量の手戻り
  • 仕様書の書き直し
  • テストの全面修正
  • スケジュール破綻

そして厄介なのは、誰も失敗に気づかないことです。
画面は動いているからです。

動くUIは安心感を生みます。
しかしそれは仕様が正しい証拠ではありません。

UI駆動型SDDが向くケース

すべてが悪いわけではありません。
次の条件では有効です。

  • 業務ルールが極めて単純
  • CRUD中心
  • 単一ユーザー操作
  • 状態遷移が少ない

管理画面などは典型例です。

逆に、次は危険です。

  • 予約
  • 決済
  • 在庫
  • 承認フロー
  • 並行操作があるシステム

これらは状態遷移が本体です。
UIから設計するとほぼ確実に破綻します。

UI駆動型SDDを使うなら何を補うべきか

対策はシンプルです。
UIの前に「状態」を仕様にします。

必要なのは画面仕様書ではありません。
状態遷移仕様です。

最低限、次を定義します。

  • エンティティの状態
  • 許可される遷移
  • 禁止される操作
  • 同時操作時の挙動

UIはその“表示”にすぎません。

つまり順序を戻します。

状態 → 振る舞い → API → UI

これだけで、UI駆動型SDDの危険性は大幅に減ります。

まとめ ― UIは仕様ではなく「観測装置」

UI駆動型SDDが失敗する理由は難しくありません。
UIを仕様だと思ってしまうことです。

UIは仕様を確認するための観測装置です。
仕様そのものではありません。

画面が完成しても、仕様が完成したとは限りません。
むしろ、仕様が曖昧なままでも画面は作れてしまいます。

SDDで重要なのは、ユーザーが何を「見るか」ではなく、
システムがどの状態に「なれるか」です。

もしUIから仕様を書き始めているなら、一度だけ順序を逆にしてみてください。
画面を描く前に「このデータはいつ変更できるのか」を書く。

それだけで、UIは突然わかりやすくなります。
そして開発も、驚くほど壊れにくくなります。