仕様駆動開発（SDD）とフロントエンドの相性

背景

「仕様さえ渡せばAIが実装できる」という期待が開発現場で高まっている。こうした文脈で注目されるアプローチを、本稿では仕様駆動開発（SDD）と呼ぶ。仕様を先に定義し、それを基準に実装・検証を進める開発スタイルである。

SDDでは仕様の品質が成果物の品質を直接左右する。AI活用開発ではプロンプトが事実上の仕様となるため、この性質がより先鋭になる。人間同士で暗黙に共有される前提は、AIとの間では同等には共有されない。

フロントエンドでは仕様の完全化が構造的に難しい

SDDの前提は「正確な仕様」だが、フロントエンドではこの前提を満たすことが難しい。

仕様が言語化しにくい

フロントエンドの要件の中心はUI・インタラクション・UXであり、言語だけで仕様化しにくい。ステークホルダーから挙がる要件は、しばしば次のようになる。

• 「使いやすくして」
• 「自然な動きで」
• 「直感的に」

こうした要件は仕様に落とし込みにくい。実際に動くものを見てはじめて「意図と違う」と判断されることも多く、事前の言語化だけでは仕様が完結しない。

デザインへの依存が強く変更も多い

フロントエンドの仕様はデザインに強く依存する。デザイン自体が繰り返し更新されるため、仕様の確定がデザインの確定を前提とする構造になりやすく、仕様が安定しない。

仕様で網羅しきれない変数が多い

UIの状態遷移は組み合わせが多く、全パターンを仕様で網羅することは現実的でない。「ドラッグ中にホバーした要素」「フォーカス遷移中にモーダルが開いた状態」のように、仕様に記述されていない組み合わせが実装段階で頻繁に現れる。ブラウザやデバイスなど実行環境の差異もあり、仕様の完全性だけでは吸収しきれない。

デザインシステムは一部を仕様化しやすくする

デザインシステムが整備されていれば、仕様化できる範囲は広がる。AIへの指示でも「Buttonコンポーネントのprimary variant」のように、構造化された語彙で仕様を伝えられる。

ただし解決できるのは構成要素レベルの仕様化に限られる。コンポーネントの組み合わせや文脈に応じたパターン選択は、デザインシステムがあっても仕様化しにくい。

詳細化による補完にも上限がある

仕様の曖昧さを詳細化で埋める方向の対処もあるが、AIが処理できるコンテキスト量には上限がある。長大な仕様では中間部分の情報が抜け落ちる「Lost in the Middle」、入力の長さに応じて応答品質が劣化する「Context Rot」といった現象が報告されている。状態遷移やバリエーションが多いフロントエンドでは、詳細化と処理性能が両立しにくい。

ウォーターフォールと組み合わせると不整合が伝播する

SDDの仕様は、生きたドキュメントとして更新し続ける運用もあれば、最初に確定させて固定する運用もある。ウォーターフォールと組み合わせると後者になり、仕様の誤りは実動作を経るまで発覚しにくい。SDDはその固定された仕様を忠実に実装する。加えて、フロントエンドでは前述の通り仕様の完全化自体が難しい。

この3つの条件が重なると、次の因果関係が生じる。

曖昧な要件
　↓（言語化ロス）
不完全な仕様
　↓（ウォーターフォールで固定）
検証・修正なく実装へ
　↓（SDDで忠実に実行）
「仕様通り」だが「意図と異なるもの」が完成

たとえば次のような問題が起きる。

• 「仕様書に書いてあった」と「ユーザーが期待していた」が乖離したままリリースに至る
• 状態遷移の考慮漏れが仕様・実装・テストの各工程に伝播する
• デザイン変更による仕様修正が実装完了後に発生する

アジャイルであればイテレーションで仕様を修正できるため、この問題は軽減される。ただし、フロントエンド固有の仕様化の難しさが消えるわけではない。

SDDが機能するのはフロントエンドの周辺領域に限られる

SDDが適用しやすい領域はフロントエンドにも存在するが、その範囲は狭い。

◯がついた領域はいずれもフロントエンド作業の周辺部分であり、レイアウト・インタラクション・状態管理・UXといった中心的な作業には適用しにくい。

問うべきは「仕様への責任を誰が負うか」

問題の中心は手法ではなく、仕様に対して誰がどのように責任を持つかにある。仕様を書いたかどうかより、その内容を検証し承認したかどうかが重要である。フロントエンドでは仕様の言語化が難しいため、承認があっても妥当性の検証が不十分になりやすい。SDDとの相性の悪さの根本はここにある。

結論

SDDは仕様の品質に成果物が直結する手法であり、フロントエンドは仕様の完全化が構造的に難しい領域である。ウォーターフォールと組み合わせると、仕様の誤りが修正されないまま後続工程に伝播しやすくなる。

フロントエンドへSDDを持ち込む際は、「仕様を書いたか」ではなく「仕様に責任を持てるか」が重要である。仕様の完全化に依存せず、型システム・テスト・Visual Regression Testing・CI/CDといった決定論的な検証と組み合わせることで、仕様で網羅できない部分の品質を担保できる。ただしこれらの検証基盤の構築には相応の投資が必要であり、基盤が未整備のままSDDを先行させると、検証は結局人間の目視に依存する。