ワイヤーフレームは仕様になるのか SDDの判断基準

ワイヤーフレームは仕様ではないが、仕様を壊す力を持っている

SDD（仕様駆動開発）を導入したプロジェクトで、最も扱いに迷う成果物があります。
それがワイヤーフレームです。

レイアウト、入力欄、ボタン配置、画面遷移。
一目で全体像が分かり、関係者全員が同じ絵を見ながら話せるため、開発初期では非常に重宝されます。

そして、ほぼ必ず起きるのが次の判断です。

「このワイヤーフレームを仕様として扱いましょう」

ここが分岐点になります。
結論として、ワイヤーフレームは仕様として扱うべきではありません。
ただし、捨てるべきでもありません。

ワイヤーフレームは仕様の代替ではなく、仕様の“仮説”です。
この扱いを間違えると、開発の後半で仕様衝突が起きます。

なぜワイヤーフレームは仕様に見えるのか

ワイヤーフレームには、仕様らしい要素が揃っています。

• 入力項目が定義されている
• 操作手順がある
• 遷移が書かれている
• エラー表示が想像できる

レビューもしやすく、合意も取りやすいです。
特に非エンジニアからすると、文章仕様書よりはるかに理解しやすい資料です。

しかし、ワイヤーフレームが表しているのは「見える振る舞い」です。
ソフトウェアの仕様の本体は「見えない制約」です。

この違いが問題になります。

ワイヤーフレームが表現できないもの

ワイヤーフレームではほとんど扱われない内容があります。

• 同時更新時の整合性
• 操作順序制約
• トランザクション境界
• データ確定タイミング
• 権限の差異
• 例外時の優先順位

これらはUIに直接現れないため、ワイヤーフレームに書かれません。
しかし実装で最も重要なのはここです。

例：承認フロー

ワイヤーフレームでは次のように見えます。

申請画面 → 承認画面 → 完了

とても明快です。
しかし仕様として必要なのは次です。

• 承認中の再編集可否
• 差し戻し時の状態
• 承認者変更時の扱い
• 同時承認の競合
• 取り消しの可否

これらは画面では判断できません。
つまりワイヤーフレームは「流れ」を示しますが、「条件」を定義しません。

ワイヤーフレームを仕様にすると何が起きるか

典型的な現象があります。

開発初期：
「仕様は固まった」

開発中盤：
「想定外のケースが出た」

開発後半：
「仕様変更が多い」

実際には仕様変更ではありません。
初めて仕様が書かれているだけです。

ワイヤーフレーム中心のプロジェクトでは、仕様議論が実装中に発生します。
これが手戻りの原因になります。

SDDにおける正しい位置づけ

SDDでは、仕様は実行可能である必要があります。
つまりテストで検証できることが仕様です。

ワイヤーフレームはテストできません。
そのため、仕様の一次情報にはなりません。

では何に使うのか。
用途は明確です。

• ユースケースの抽出
• 状態遷移の発見
• 用語の統一

ワイヤーフレームを見ながら、次を洗い出します。

• この操作はいつ許可されるか
• どの状態で表示されるか
• 何が禁止されるか

これをテストとして書きます。
これがSDDの仕様です。

実務での扱い方

有効な進め方は次です。

1. ワイヤーフレームを作る
2. 画面を見ながら振る舞いを言語化する
3. 状態遷移に分解する
4. テストとして定義する
5. UIを実装する

順序が重要です。
ワイヤーフレーム → UI実装
にすると仕様漏れが起きます。

ワイヤーフレーム → 状態仕様 → 実装
にすると安定します。

よくある誤解

「ワイヤーフレームが詳細なら問題ない」

詳細さは解決になりません。
情報の種類が違うからです。

どれだけ精密なレイアウトでも、
「在庫0なら購入不可」
は表現できません。

仕様の核心はレイアウトではありません。
制約です。

注意点 ― ワイヤーフレームの心理的影響

ワイヤーフレームには強い効果があります。
人は「見えるもの」を完成に近いと感じます。

これにより、次の誤解が生まれます。

• 実装は簡単
• 仕様は固まった
• 残りはコーディングだけ

この認識のまま進むと、実装段階で設計が始まります。
そしてスケジュールが崩れます。

まとめ ― ワイヤーフレームは仕様ではなく「質問集」

ワイヤーフレームの価値は、答えではありません。
問いを生むことです。

「このボタンはいつ押せるのか」
「この画面はどの状態で表示されるのか」
「戻ると何が起きるのか」

これらを定義したとき、初めて仕様になります。

ワイヤーフレームは完成図です。
しかしSDDで必要なのは、完成図の前にあるルールです。

もしワイヤーフレームレビューが静かに終わるなら注意が必要です。
良いレビューとは、質問が増えるレビューです。

ワイヤーフレームは仕様書ではありません。
仕様を書くための最良の出発点です。