要件定義から設計に渡す前に決める3つの境界
# 要件定義から設計に渡す前に決める3つの境界
要件定義が終わって、いよいよ設計に入る。そう見えた瞬間に、AIはたいてい勝手に前へ進もうとする。
画面の遷移も、APIの形も、エラー時の挙動も、それっぽく埋めてくれる。便利だ。だが、ここで境界がないと、後で直す場所が広がる。
要件 箱から設計箱へ渡す前に必要なのは、情報を増やすことではない。むしろ、AIが補完してよい範囲と、補完してはいけない範囲を分けることだ。
1. 入力の境界を先に閉じる
設計がぶれるプロジェクトは、たいてい入力が曖昧だ。
「申請を登録できるようにしたい」とだけ書かれていても、何を入力とみなすかが決まっていない。AIは空欄を埋める。だが、その空欄を埋める責任は本来、人間側にある。
要件箱では、少なくとも次を閉じたい。
- 誰が使うのか
- 何を入力とするのか
- 何を自動計算するのか
- 何は入力させないのか
ここが曖昧だと、設計箱で「画面に項目を足すだけ」の雑な解決になりやすい。
たとえば「申請日時は入力不要、システムで自動付与」と決めておけば、設計の時点で迷わない。逆に、入力として残してしまうと、後で整合性が崩れる。
AIに要件を渡すときは、情報を盛るより、まず入力の穴を塞ぐ。それだけで設計の精度が変わる。
2. 判断の境界を先に決める
次に必要なのは、何をAIに任せて、何を人間に 残すかだ。
設計は「こう動くべきだ」を決める作業だが、その一部は自動で決めるべきではない。特に次の3つは、人間の判断が要る。
- 優先順位が変わる条件
- 例外を許す条件
- 仕様変更を止める条件
たとえば、同じ「承認フロー」でも、
- 金額が閾値を超えたら再承認
- 申請者が退職済みなら取消
- 締切を過ぎたら自動却下
このあたりは、AIに候補を出させるのはいい。だが、最終的に採用する判断は人間が持つべきだ。
ここを曖昧にすると、設計書は整って見えるが、責任の線が消える。設計が強そうに見えて、実は決まっていない。
OpenAIの agent evals の発想でいうなら、判断基準がないまま出力を増やしても意味がない。判断の境界を先に決めておく方が、レビューは速い。
3. 停止条件の境界を明文化する
最後に大事なのが、どこで止めるかだ。
AIは止めるのが苦手だ。だから、止める場所を設計に入れておかないと、どこまでも前に 進もうとする。
設計箱には、次のような停止条件を明示したい。
- 権限外の操作はここで止める
- 外部送信の直前は人間承認に戻す
- 例外が2つ以上重なったら自動処理しない
- 未確定の要件が残るなら実装に渡さない
これを入れると、設計書はただの説明書ではなくなる。AIにとってのブレーキになる。
MCPの Resources と Tools の分離も、考え方は同じだ。読むための文脈と、動かすための手段は別物だ。設計も同じで、決めることと止めることは分けた方がいい。
設計箱があると、手戻りは局所化する
入力・判断・停止条件が分かれていると、AIの失敗は大きく崩れにくい。
たとえば、要件の解釈が少しずれても、入力境界が閉じていれば修正は小さい。判断条件の抜けがあっても、停止条件が入っていれば事故になりにくい。設計の失敗を一気に全体へ波及させないための仕組みになる。
逆に境界がないと、AIは「それっぽく」埋める。人間は「まあ、これでよさそう」と受けてしまう。後で修正すると、画面もAPIもテストも全部ずれる。
ここで効くのは、AIの能力を上げることではない。AIが勝手に進めないように、設計側で線を引くことだ。
明日からやるなら、この3行だけでいい
大げさなテンプレートは要らない。
まずは要件書の先頭に、次の3行を足す。
- 入力として確定しているもの
- 人間が判断するもの
- 自動処理を止める条件
この3行があるだけで、設計に入ったときの迷いがかなり減る。AIも余計な補完をしにくくなる。
要件定義から設計へ渡すとは、情報を増やすことではない。判断を先に閉じ、止める線を先に引くことだ。
ひとつだけ具体例を出す
たとえば「申請フローを作る」という要件があったとする。ここでAIが最初にやりがちなのは、画面項目を増やすことだ。承認者コメント欄、下書き保存、差戻し、再申請、履歴一覧。どれも正しそうに見える。
だが、実務では全部必要とは限らない。むしろ先に決めるべきなのは、次のような線だ。
- 申請者が編集できるのは「申請中」だけ
- 「承認待ち」以降は編集不可
- 差戻し時は再申請扱い
- 外部連携は承認後だけ
この線を引いてから設計すれば、UIの項目数は自然に決まる。AIに項目を増やさせる前に、ルールを閉じる。順番が逆だと、設計はすぐ膨らむ。
レビューで見るべきは「穴」だけ
設計書のレビューでは、きれいな文章かどうかは本質ではない。見るべきは、穴が残っていないかだ。
よくある穴は次の3つ。
- 例外時に誰が止めるかが書かれていない
- 入力の前提が抜けている
- 実装に渡す条件が曖昧なままになっている
この3つを見つけるために、設計レビューは「賛成/反対」を議論する場ではなく、「まだ決まっていないものを露出させる場」にした方がいい。
AIにレビューさせる場合も同じだ。良いレビューは赤入れの量ではなく、未決事項の露出量で決まる。
もし設計が重くなりすぎたら
設計箱の境界を引こうとすると、今度は「書くことが多すぎる」という問題が出る。そこでもう一段、削れる。
- 画面 遷移は1本の図で足りるか
- エラーは3パターンだけで足りるか
- 人間承認は1箇所だけで足りるか
設計は足し算ではない。要件から漏らすものを減らしつつ、実装に渡す線を揃える作業だ。書く量を増やすより、判断を減らす方が効く。
まとめると
要件定義の次に必要なのは、設計の見た目を整えることではない。
入力の境界を閉じる。判断の境界を決める。停止条件の境界を明文化する。この3つがそろうと、AIは勝手に飛ばなくなる。
設計は、AIを自由にするためではなく、AIが暴れないようにするためにある。
