第1章なぜ今このメソッドか
実装は速くなった。なのに不安が消えない
AIコーディングの普及で、実装のスピードは目に見えて上がりました。それなのに、大規模SIの現場では品質への不安が消えません。レビューは減らせません。むしろ「AIが書いたコード」を人が全量確認する分、負荷が上がったという声すらあります。なぜでしょうか。
問題は実装側ではなく、仕様側にあります。
SIはWHYを残してこなかった
SIの文書体系を振り返ると、要件定義書はWHAT（何を作るか）を、設計書はHOW（どう作るか）を書いてきました。しかしWHY（なぜそう決めたか）は、会議室の記憶と担当者の頭の中に置き去りにされてきました。人間のチームなら、それでもなんとかなりました。分からなければ隣の席に聞けたからです。
「あの人に聞けば分かる」——これが属人化であり、「仕様有識者」という言葉で整理されてきた問題の正体です。
WHYのない仕様をそのまま渡されたAIは、空白を自分の推測で埋めます——悪気なく、それらしく、速く。これを本メソッドではAI補完と呼びます。そして、それらしく埋められた推測は、気づかれないまま下流工程に流れていきます。
失敗はこう起きる
例1：WHYが書かれていなかった
仕様書に「送料無料の閾値は、変更可能とする」とだけ書かれていたとします。AIは「変更可能」を素直に解釈し、定数ファイルに値を切り出して実装します。技術的には正しい実装です。
しかし発注側が考えていたのは、別のことでした。キャンペーンによって送料を無料にするケースがある——期間を区切って閾値を下げる、対象商品を絞って無料にする。そうした売り方を、業務部門がその都度打ちたかったのです。つまり要るのは、業務部門が自分で切り替えられる仕組みでした。管理画面も、誰が切り替えてよいかの権限も、いつ・誰が・何を変えたかの履歴も要ります。定数ファイルの書き換えは、そのどれでもありません——キャンペーンのたびにリリースを伴い、開発側の手が必要になります。この食い違いが発覚したのは本番2週間前でした。
AIは間違えていません。仕様が「変更可能」のWHY（誰が・何のために変更するのか）を持っていなかったことが問題です。逆に言えば——「変更可能とする」と書いた時点で、その理由を書こうとしていれば、手が止まったはずです。誰が変えるのか。何のために変えるのか。そして、何をもって「変更可能になった」と言えるのか——定数を外に出せば済むのか、業務部門が自分で切り替えられて初めてそう言えるのか。書けません。その、書けなかった箇所が、本番2週間前に発覚した箇所です。
例2：責任の範囲が書かれていなかった
もう1本、別の形の失敗を見てみます。外部設計書に「受注登録画面は、受注データを登録し、在庫引当を行う」と書かれていました。AIは素直に実装します——在庫があれば引き当て、なければ受注を「予約受付」状態に変えるコードです。
レビューで指摘が入ります。「在庫がないときに予約受付へ回すかどうかは業務ルールの話です。画面が判断してよいことではありません」。書いた側の言い分も筋は通っています——「在庫引当を行う」と書いてあったから、在庫がないときの処理も書いた、というわけです。
ここでもAIは、書かれていないことを埋めただけです。この設計書には受注登録画面がどこまでの責任を持つか——可否の判断をしてよいのか、詳細なロジックは誰が持つのか、例外時の業務判断は誰の責務か——が書かれていませんでした。例1がWHYの欠落なら、こちらは責任の範囲の欠落です。この2つと、例1がもうひとつ開けていた「何をもって実現されたと言えるのか」の空白は、後で見る【広げる】の4つのレンズの「業務との整合」「境界・責任範囲」「検証可能性」に、そのまま対応しています（9章）。
なお、例2が外部設計で表に出たこと自体も、ひとつの信号です。在庫がないときにどうするかは業務ルールであり、本来は要件定義の側で、主体の責務として決まっているはずのものでした。後の工程で上流の決定が動くことは、それ自体が観測の材料になります（7章）。
どちらの例も、分かりやすくするために単純にしてあります。実際の食い違いはもっと小さく、いくつもの記述に散らばって現れます。そのほうが、かえって見逃されます。
問題は「やり直し」ではなく、「発覚の遅れ」である
どちらの例でも、書かれていない箇所は同じ道をたどります。
やり直すこと自体が悪いのではありません。叩き台の段階で「それは違う」と出れば、直すのは記述の書き換えで済みます。設計レビューで出ても、まだ間に合います。問題は、同じ食い違いが遅く出ることのほうです。遅れるほど、やり直す範囲は設計から実装・テストへ広がります。それでも納期は動きません。例1が痛いのは、管理画面を作り足したからではなく、それが本番2週間前に分かったからです。
では、なぜ本番間際まで気づかれないのか。理由はAIの側ではなく、人の側にあります。
もっともらしい仕様は、疑われずに通る
AI補完が下流まで流れてしまうのは、書き手やレビュアーが不注意だからではありません。AIの出力には、人の判断を鈍らせる性質があります。
- 自信のある口調は、正しさと読み違えられる（権威バイアス）。AIは根拠の薄い箇所も同じ調子で書きます。断定の強さと確からしさは比例しません。
- 見たいものだけが目に入る（確証バイアス）。「この業務はシンプルだ」という先入観があると、正常系だけを確認して例外・差戻し・取消を見落とします。【広げる】の4つのレンズに「正常系偏重」が要るのは、このためです。
- 自動で出てきたものは、検証を省きたくなる（自動化バイアス）。AIが「問題なし」と言った成果物を、人が読まずに次へ送ってしまいます。
一般的な仕様は、たいていもっともらしく見えます。そこにこの3つが重なると、「書かれていなかった箇所」は疑問として立ち上がらないまま次工程へ渡ります。作業はAIによって速くなりますが、人の認知の速度は上がりません。この差が、発覚を遅らせます。
「要件定義が甘かっただけだ」と読まないでほしい
同じあいまいさを人間の開発者に渡したら、たいていは手が止まります——「変更可能って、誰が変えるんですか」。あいまいさが、質問という形で表面化するわけです。AIも問い返すことはあります。しかし問い返さずに埋めてしまう場合がある——そして埋めた結果は整合的に見えます。定数ファイルへの切り出しはコードとして正しく、レビューでも指摘されにくいのです。
つまりAIが変えたのは、あいまいさの発生量ではありません。あいまいさが表面化する確度とタイミングです。人間なら着手時に出たはずの問いが、本番2週間前まで出てこないことがあります。上流で問いを立て切ることの価値が跳ね上がったのは、このためです。
禁止ではなく、舵取り
ではAIに推測を禁止すればよいのでしょうか。それは不可能です。仕様のすべてを書き切ることはできず、AI補完はゼロにできません。本メソッドの立場は、禁止ではなく舵取りです——決定の理由（WHY）を残すこと。この記録は一般に ADR（Architecture Decision Record）と呼ばれます（本メソッドでの語義はアーキテクチャに限りません。規律の詳細は6章）。
その効きは二段になっています。一次の効きは、検出です。 WHYを残す作業は、残した記録がAIに効くより先に、書く側に効きます。決定の理由を書こうとすると、書けない箇所が出てきます——それが空白の在処です。埋まれば仕様に穴は残らず、埋まらなければ「未決」として明示されます。どちらにせよ、AIが推測で埋める場面は来ません。記録は、空白の検出装置でもあります。
二次の効きが、舵取りです。それでも書き切れなかった空白に対しては、残されたWHYが、許される補完の方向を絞り込みます。決定理由の記録が「AIの暴走を防ぐ手綱」と呼べるのはこの段のことであり、手綱が要るのは、穴を塞ぎ切れなかったところだけです。
ただ、記録を残すだけでは足りません。AIは速く進み、出てきたものは、うまくいっているように見えます。だからこそ、意図的に立ち止まる機会を作ることが大切です。その置き方は3章で扱います。
シフトレフト——ただし理想論ではなく
品質活動はV字の左へ寄せます（シフトレフト）。上流で決まっていることが多いほど、AI補完の余地は減ります。ただし本メソッドは「上流で全部決まる」とは考えません。あいまいさは段階的に解消される——これは従来のSIと同じ前提です。だからこそ「決まったこと」と「まだ決まっていないこと」の区別が生命線になります（2章）。
ここで、本書の立場をひとつ明らかにしておきます。
シフトレフトを理由に、上流で要件を全部出すことを発注者に迫りません。「シフトレフトだから要件を全部出してください」は拡大解釈です。上流で決め切れないのは発注者の怠慢ではなく、業務そのものが持つ性質です——動かしてみないと分からないことは、必ず残ります。
日本のSIの現実：文書は2つの条件を同時に満たす必要がある
世に出ている仕様駆動開発（SDD）の解説の多くは、仕様を段階的に精緻化し、反復のたびに調整していく前提で書かれています。その前提の背後には契約の形がある——出来高払いの契約なら、仕様が固まり切っていなくても次の反復で調整できるからです。
一方、日本の大規模SIには、固定価格・納期固定で進む従来型のプロジェクトが、いまも多く残っています。本書は、どの契約の形が望ましいかを論じません。ただ、従来型のプロジェクトである限り、「要件定義書に書かれた機能が動くこと」が完成の定義になり、仕様を変えるには契約の変更が要ります——つまり仕様の境界が契約に直結しています。この条件のもとでは要件定義・外部設計という工程を省略できませんし、そこで作る文書は業務部門・経営層が承認する公式文書＝検収の対象になります。
したがってSI文書は、次の2つを同時に満たさなければなりません。
- ① 業務部門が承認できる——業務の言葉で書かれ、システムに詳しくない人が「これで間違いない」と判断できる
- ② AIが実装できる——推測の余地が残らない精度で書かれている
この2つは、放っておくとぶつかります。分かりやすく書けば精度が落ち、精度を上げれば業務部門が読めなくなります。本メソッドはこれを、文書の文体で解こうとはしません。決定と、その理由と、辿れる網を文書に添えることで、同じ文書が2つの読者に応えられる状態を作ります。②を担うのはこの後に並べる機構そのものであり、①を誰が担うかも含めて、その状態を次章で定義します。
なお、この前提は永久ではありません。アジャイル開発のように、開発全体を準委任で進める形へ寄せていく動きもあり、そのためのモデル契約も公開されています（付録_出典）。契約の形が変われば、本書が引き受けている制約の一部は不要になります。そのときは、変化を前提にした方法へ移ればよいのです。本メソッドは、いまの現実に向けて設計された道具です。メソッド自身も育てるものであることは、14章の最後で述べます。