おい、要件を言葉にしろ - じゃあ、おうちで学べる

はじめに

察しの良いチームが、いちばん危ない。

書かなくても通じてきた、その通じ方が、AIには渡らない。書かれていない常識は、書かれていないというだけの理由で、消える。

要件定義は、長く「面倒だが避けて通れない上流工程」と呼ばれてきました。きちんと書こうとすると時間がかかる。書かなくても、チームが察しで埋めてくれる。だから雑にやっても、なんとかなった。たぶん、それが間違っていたわけではないのだと思います。書かない知恵で、私たちはずっと回してきた。

それが、AIで開発するようになって、通じなくなりつつある気がします。AIには「察し」がありません。書かれていないことは、想像で埋められる。その想像は、私たちのチームの常識とはたぶん一致しない。一致するときもあるかもしれませんが、一致しなかったときの代償が大きすぎる。

それも、信じられない速度で起きます。

人間のチームでは、要件の曖昧さは3週間後に気づくコストでした。コードレビュー、結合テスト、QA、本番、と段階的に発覚する。各段階に「察しで埋める」防波堤があったから、致命傷にはならなかった。AIで開発すると、要件1つにつき機能が3時間で実装され、3時間後にはレビューが始まる。違っていれば3時間が消える。書き直す。また3時間。3週間が3時間に圧縮されるのが速さの恩恵だが、同じ理屈で、同じバグも3時間で量産される呪いでもある。

差し引きでプラスにしたいなら、要件の精度を上げるしかないのかもしれません。コードを書く時間ではなく、コードを書かない時間の質で勝負するしかない。私がAI時代になって初めて要件をまともに考え始めたのは、たぶんこの転換点に立ち会っているからです。

ここで腰を据えるために、私は問いを2つに分けて考えるようにしています。「正しいものは何か」と「それを正しく作るには何が要るか」は、別の問いだということです。AIは2つ目の問いの効率を桁で上げます。1つ目の問いには、ほぼ何も貢献しません。1つ目の問いに人間が答えていなければ、AIは2つ目を高速で間違える。コードを書かない時間の質、というのは、結局この1つ目の問いに費やす時間の質のことです。

このシリーズは3部構成です。第1部は、要件とは何か、どうやって発見し、どうやって言葉にするか。第2部は、言葉になった要件をどう実装の現場で動くものにするか。第3部は、動き始めた要件を、時間の中でどう生かし続けるか。

3部に分けたのは、要件が3つの違う死に方をするからです。第1部で扱うのは、書かれずに死ぬ要件。第2部で扱うのは、書かれたまま動かず読まれずに死ぬ要件。第3部で扱うのは、書かれて動いていたのに時間に殺される要件。同じ「要件が機能しない」という結末でも、原因と処方が違う。3つを順に積み上げないと、AI時代の現場で要件は生き残れない、というのが私の現在地です。AI時代の現場で、私が掴みかけている輪郭を3部に分けて書いていきます。掴みきれていないところは、掴みきれていないと書くつもりです。

このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。

AIは要件の欠落を可視化する装置になった

要件の曖昧さが事故を起こすのは、AI時代に始まった話ではありません。ずっと前から、要件不足は罪でした。それでもチームが動いていたのは、人間が察しで埋めていたからです。

人間のチームには、暗黙知という保険がありました。仕様書に書いていなくても「うちのプロダクトでは在庫切れは検索結果に出さない」のような共通理解。長く一緒にいれば全員が知っていて、新人にも自然に伝わる空気。これが要件文書の欠落を長年補ってきた力です。チームは、語れる以上のことを知っている。AIには、この「語られていない知」が一切渡りません。

AIに渡せるのは、明示的に書かれた言葉だけです。コード、ドキュメント、コメント、CLAUDE.md、プロンプトに書かれた指示。それ以外は存在しないのと同じだ。古参エンジニアが体に染み込ませた「常識」も、毎週の朝会で更新される暗黙の合意も、AIには届きません。

そしてAIには、人間と決定的に違う性質があります。埋め方が予測できないことです。

人間の新人なら、要件が曖昧だと「これってこういうことですか」と聞いてくれる。聞いてくれない場合でも、社内の他のコードやドキュメントを参考にする。同僚に「これ前どうしたっけ」と確認する。空白を埋めるとき、チームの平均値に寄せようとする力が働きます。

AIは寄せません。学習データの中で最も頻度が高いパターンに寄せる。それは「世界の平均値」であって、あなたのチームの平均値ではない。だから世間では普通だが自社では絶対にやらない実装、というのが日常的に出てきます。

具体的に考えてみます。例えば、こんな要件文があったとする。

ユーザーが商品を検索できる。

これを人間のチームに渡すと、おそらく当たり前のように在庫切れを除外した実装が出てきます。誰も「在庫がある商品だけ」とは書いていないのに、です。なぜか。チームの常識が「うちは在庫切れを売らない」だからです。書かれていない2文字を、全員が暗黙で補っている。

同じ要件文をAIに渡すと、無在庫の商品を含む検索結果が返ってきます。AIにとって「商品を検索する」は、世界の平均値で言えば「在庫の有無を問わず該当する商品を返す」ことだからです。たった「ある」の2文字が抜けているだけで、出力が分岐する。

ここまで見て、AIが「悪い」と感じるかもしれません。私はそう思っていません。AIは正直だ。

書かれた要件しか実行しない。書かれていない要件は推測で埋める。これは機械として当たり前の振る舞いです。問題は、人間がこれまで「書かなくても伝わる」と思って書かなかった部分が、AI時代になって全て露出したということです。

つまり、AIは要件不足を作っているのではありません。昔からあった要件不足を、可視化しているだけです。

そして、可視化のスピードが速い。3週間が3時間に圧縮される。同じバグも3時間で量産される。これが速さの罠で、要件の曖昧さが致命的になる構造的な理由です。

要件をまともに書く、というのは、AI時代にはやらなければ事故る必須の規律です。気合いの問題ではなく、構造の問題として、書かないと走れない。

ここで、私が現場で繰り返し使っている捉え方を1つ書いておきます。AIは、入社初日のとても優秀なジュニア開発者のようなものだ、という見方です。

入社初日のジュニアは、コードを書く能力は高い。でも、プロジェクトの背景、業務の暗黙ルール、ステークホルダーの恐れ、過去の失敗から学んだ防御的な書き方、これらを何も知りません。だから、放っておくと、構文的には正しいが業務的には間違ったコードを返してきます。

ベテランがその新人を成功させる方法は、はっきりしています。毎日のように仕事の文脈を共有することです。「うちはこういう設計を選ぶ」「過去にこういう事故があった」「このユーザーはこう動く傾向がある」。これを口頭で、コードで、レビューで、繰り返し伝える。文脈が積み上がれば、新人は徐々に、ベテランと同じ判断ができるようになる。

AIに対しても、同じです。AIは「あなたが与えた情報以外、このプロジェクトについて何も知らない」と考えるくらいでちょうどいい。要件文、CLAUDE.md、skill、テスト、コードの命名、PRのテンプレート。これらすべてが、AIに対する文脈共有の手段です。書いていない文脈は、AIには届きません。

新人を育てる労力を、AIに対しても惜しまない。これが、AIから受け取れる成果の上限を決めます。労力を惜しめば、AIの上限も低くなる。要件を言葉にする規律は、ジュニアを育てる規律と地続きです。

「集める」から「引き出す」へ、要件とは何か

要件について考え直したとき、最初に捨てたのは「要件を集める」という言い方でした。

「要件を集める」と言うと、要件はどこかに転がっていることになる。ステークホルダーの頭の中に整然と並んでいて、ヒアリングという容器を持っていけば移し替えられる、というイメージです。これは嘘だ。

要件は転がっていません。ステークホルダーは要件を持っていない。彼らが持っているのは、問題と願望と恐れだけだ。

依頼者が「商品を検索できるようにしてほしい」と言うとき、その人の頭の中にあるのは3つの感情です。「在庫切れの商品を売って、また顧客から怒られたくない」という恐れ。「もっと売上を上げたい」という願望。「検索が遅くて離脱されている気がする」という観察。これは要件ではない。要件の原料です。

原料から要件を作るのは、依頼者ではない。エンジニア側、要件を引き出す側の仕事です。

そして、引き出された要件は最初から正解ではありません。要件は仮説として書かれ、検証によって精度が上がるもの、と捉えるようになりました。完璧な要件を1度で書こうとすると詰まる。粗い仮説で出して、動くもので試して、ズレが出たら直す。正しいものは、最初から手元にあるのではなく、繰り返しの中で形になっていく。要件発見が「採取」でなく「探索」だと考える理由は、ここにあります。

ここで「引き出す」をもう一段噛み砕いて考えてみます。要件発見の比喩として「漁る」という動詞があります。網を引いて、水中の見えない対象をしつこく探る。漁船が網を投じるように、ワークショップ、インタビュー、プロトタイプ、シナリオ、ビジネスイベント分析、観察、と様々な「漁具」を使う。ステークホルダー自身が意識していない潜在的なニーズを引き上げる、という営みです。

この比喩が刺さるのは、ステークホルダーへのヒアリングを過信しないからです。「ヒアリング = 採取」だと思っていると、聞いて出てきた言葉が要件だと錯覚する。実際には、聞いて出てきた言葉は氷山の一角で、本当に必要なものは水中に沈んでいます。「漁る」という動詞は、その水中に手を突っ込む覚悟を含んでいる。

要件発見でもう1つ役に立つのが、症状と原因がズレるという見方です。

ステークホルダーが「これが問題です」と挙げてくる場所は、問題が表に出ている場所であって、問題が発生している場所ではない、ということがしばしば起きます。「ヘルプデスクへの問い合わせが多い」という症状の原因が、実は「画面のラベルが分かりにくい」だったり、「マニュアルが古い」だったり、「最初のオンボーディングが不十分」だったりします。症状をそのまま要件にすると、原因に届かない実装が出てくる。

しかも厄介なことに、不便は毎日触っているうちに姿を消します。手が覚えてしまえば、操作は意識から落ちる。落ちたものは「困っていない」として記憶される。だから現場でヒアリングすると、最も摩耗の激しい場所が、最も語られない場所になりがちです。症状の不在は、原因の不在ではない。語られない場所こそ、観察者が手で触り直す場所だと、私は決めています。

私は要件のヒアリングをするとき、出てきた「これが問題」を、まず症状として仮置きします。症状の場所では止めず、隣の領域、上流の領域、一見無関係に見える領域まで含めて、もう一度なぜを問い直す。3つも遡れば、最初の場所と全然違うところに原因が出てくる、ということが現場で繰り返し起きます。

要件発見の経験則として、「なぜ」を繰り返し問い直すことが重要だと言われるのは、この構造から来ています。1回目のなぜで出てくるのは、たいてい次の症状です。本当の原因まで届くには、もう少し奥に進む必要がある、というのが現場の感覚です。

「集める」という言い方を捨て、「引き出す」あるいは「漁る」を採用することは、単なる言葉遣いの変更ではありません。要件発見の難度に対する敬意です。難しいからこそ、技術が要る。

要件には階層がある

要件発見をやっていてすぐに気づくのは、全部を1つの粒度で書こうとすると破綻することです。経営層と話している内容と、エンドユーザーと話している内容と、エンジニアと話している内容は、明らかに違う層にある。これを混ぜて書くと、誰にとっても読みにくい文書ができ上がります。

私は3層で整理しています。

層	内容	例	言葉の主
ビジネス要件	組織が達成したい便益	在庫切れによる顧客離れを減らす	経営の言葉
ユーザー要件	ユーザーが達成したいタスク	在庫がある商品だけを検索できる	利用者の言葉
機能要件	システムが示す振る舞い	検索結果に在庫>0のフィルタを適用する	実装の言葉

この3層に加えて、もう1つ独立した分類があります。非機能要件、または品質属性です。性能、可用性、セキュリティ、保守性、ユーザビリティ。「何をするか」ではなく「どれだけうまくやるか」を規定するものです。

3層 × 機能/非機能のマトリクスで、要件文を書くべき場所が決まります。混ざっていると、誰も全体を理解できない。相手と層を合わせて話すこと、機能と非機能を分けて書くこと。これが要件を扱う基本動作です。

良い要件と悪い要件を分ける6つの特性

要件の良し悪しを判定する基準として、私が拠り所にしている特性が6つあります。完全性には、やることが全部書かれているだけでなく、意図的にやらないと決めたことも書かれていることを含めています。やらない領域を書き残さないと、AIや次の担当者が「未着手の隙間」と解釈して埋めにきます。

完全性：開発者が実装に必要な情報を全部含んでいる
正確性：ステークホルダーのニーズを正しく反映し、上位要件と矛盾しない
実現可能性：技術的・予算的に達成可能である
必要性：ビジネス価値があり、規制や標準に対応している
優先順位付け：他の要件との重要度の差が明確である
検証可能性：テストやレビューで実装の適合性を判断できる

このうちで一番重要なのは、最後の検証可能性だと考えています。私が一番滑るのもここです。書いている最中は完璧に検証可能だと思っているのに、後から読み直すと「ユーザーが満足する」のような主観が混じっている。気づかないと、ときどき滑り抜けます。だから、6つの順番ではなく、検証可能性だけを二度読み返すというルールを自分に課しています。

検証可能でない要件は、実装が完了したかどうかを判定できません。判定できない要件は、合意しようがない。合意できない要件は、後で必ず揉める。検証できなければ要件ではない、というのが要件工学の中でも特に強い主張で、私はこれに完全に同意しています。さらに言うなら、判定できる要件は機械に判定させるのが筋です。型で表せるなら型に、テストで書けるならテストに、CIで回せるならCIに落とす。人間が目視で確認するのは最終手段です。

「使いやすい検索」は要件ではありません。それは願望です。「在庫がある商品だけを、3クリック以内、1秒以内で表示できる」は要件です。後者は、できた／できなかったが判定できる。

私は要件を書くとき、必ず自分に問います。「これ、後で『できた』『できなかった』が判定できる文になっているか」。判定できないなら、それはまだ要件になっていません。願望を実装に渡してはいけない。

ただし、検証可能性が一発で書ききれない領域があるのは正直に認めます。探索段階のUX、感情的価値、新規ドメインの初期仮説。こうした領域では、最初から数値で検証条件を書くのは無理があります。私のやり方は、検証可能性の代わりに観察可能性を置くことです。「ユーザーが満足する」は観察できないが、「離脱率」「再訪率」「特定操作の所要時間」は観察できる。観察可能な代理指標を置いて、実際のデータが集まってから検証可能な要件に書き直す。最初から検証可能になれない領域では、観察→検証の順で2段階に分けて書く。これも要件工学の伝統に含まれている発想です。

そしてもう1つ、要件文へ併記しているのが、根拠です。「なぜこの要件が必要か」を1〜2行で添える。「在庫切れ商品を含めない」という要件であれば「在庫切れの商品を購入しようとしたユーザーが落胆して離脱する事例が多発した」と根拠を書く。

根拠を残しておくと、半年後・1年後にこの要件を見直すときに、判断材料が残ります。在庫切れでも「再入荷予定あり」と表示できるようになったとき、「この要件は再考できる」と即座に分かる。根拠がなければ、なぜそう決めたかが思い出せず、「現状維持」しか選べなくなる。要件は描写と適合基準と根拠の3点セットで初めて、時間の中で生き続けられます。

悪い要件は「悪い言葉」で書かれる

検証不能な要件は、決まったパターンの言葉で書かれます。これらの言葉が現れたらその要件は壊れていると判断していい、というリストがあります。

悪い言葉	何が悪いか	どう直すか
「ユーザーフレンドリー」「使いやすい」	主観的、検証不能	具体的なユーザビリティ基準を数値化する
「高速」「迅速」「軽快」	速さの基準が無い	許容できる最長時間を明記する
「最善を尽くす」「できるだけ」	ゴールが無い	達成すべき水準を定義する
「〜などを含む」	リストが閉じていない	完全な一覧、または「以下に限定」と明記
「直感的」「見やすい」	何が直感かは人による	操作回数、視認時間、エラー率で測る
「適切な」「妥当な」	何が適切かが不明	適切性の基準を明示する
「効率的」	効率の指標が無い	何を最大化/最小化するかを書く
「柔軟」「拡張可能」	何にどう拡張するかが不明	想定する変更パターンを列挙する

これらの言葉は、書く側にとっては書きやすい。読む側にとっても「いい感じだな」と思える。だからプロジェクトの初期によく出てきます。落とし穴は、書き手と読み手で違う絵を見ているのに、両方が「合意できた」と錯覚することです。

「使いやすい検索」を見て、書き手は「3クリックで結果が見える」を想像し、読み手は「Googleのような瞬時の検索」を想像している。両者は別物です。実装した瞬間に「思ってたのと違う」となる。

これらの言葉が要件に出てきたら、そこが対話の起点です。「『高速』というのは、何秒以内のことですか」と聞き返す。聞き返しの結果として「3秒以内」という数字が出てくる。これでようやく、要件になります。

私が一番何度も書いてしまった悪い言葉は「直感的」です。デザイナーから上がってきた要件文を、そのまま要件として渡してしまう癖があった。「直感的なUI」を実装してくれ、とAIに頼んで、出てきた画面を見て「これは違う」と差し戻す。差し戻された側のAIには判断材料がない。3回目の差し戻しのとき、AIに「直感的とは何ですか」と聞き返された。返事に詰まって、画面の前で5秒固まった。デザイナーの意図を、私はこの5秒のあいだ、自分の言葉に翻訳できていなかった。AIが正直なのではない。私が、人間相手だから曖昧で許されていただけだ。8語のリストは頭にある。あるが、自分が書く側に回ると、ない。

段階で書いて、願望と現実を分ける

非機能要件で特に難しいのが、「どこまでやれば十分か」が一意に決まらないことです。応答時間が0.1秒のほうが速い、それは分かる。でも、0.1秒でなければならないか1秒で十分かは、ビジネスの判断です。

これに対する道具立てとして、要件を段階で書くという発想があります。同じ要件を、複数のレベルで併記する。

最低限（Must）：これが達成できなければ、機能として成立しない
目標（Goal）：通常はここまで達成したい
意欲的目標（Stretch）：余裕があれば、ここまで届かせたい
願い（Wish）：理想を言えばここまで行きたい

応答時間で言えば「最低限3秒、目標1秒、意欲的0.5秒、願いは0.1秒」と書く。こうすると、実装側も「どこまで頑張る必要があるか」が分かる。トレードオフの会話ができる。「目標を達成するのにこの工数がかかる、最低限なら半分で済む」のような議論になる。段階を書いたら、それぞれの閾値は監視ツールに渡して機械が常時測るようにします。人間が四半期ごとに見直す運用は、たいてい止まる。閾値を機械に握らせると、超えた瞬間に通知が来る。判定を人手から外せるかどうかが、段階記述が生きるかの分かれ目だと思っています。

段階で書く効用は、もう1つあります。完璧主義を避けられる。すべての要件を「願い」のレベルで書こうとすると、達成不可能な仕様書ができ上がる。「最低限」と「目標」を分けておけば、現実的に出荷可能なラインが見えてくる。

ここには、意思決定の本質的な戦略があります。私たちは多くの場面で、最適解ではなく十分な水準を選んで動いてきました。最適化を諦めて満足化に切り替える。これは不確実性の中で動く現場の合理的な判断です。すべての要件で最適を狙えば、どれも完成しない。最低限と目標と願いを分けて書くことで、満たすべき水準と追求してもいい水準を、明示的に区別できる。

要件工学の経験則として「完璧な要件は得られない」「目標は十分に良い要件を、許容できるリスク水準で構築すること」という言葉があります。これも、段階で書くことと地続きの考え方です。

要件をどう書き出すかの規律

ここまでで、要件とは何か、何が良くて何が悪いか、を整理してきました。次は、要件をどう書き出すかの規律に踏み込みます。

要件発見の理屈は綺麗に整理できても、現場ではそう綺麗に進まない。見積もりは外れる、要件は曖昧なまま走る、それでも何とか回ってきた——という現実があります。AIで開発する時代に、その現実が新しい形で問われ始めました。要件を発見した後、何を優先し、どんな粒度で、どんな言葉で書き出すか。その作業の規律を、まとめておきます。

早く見つけるほど安い、見積もりは確率分布である

要件の品質を真剣に考えるべき経済的な理由として、欠陥が遅く見つかるほど修正コストは桁で跳ね上がるという構造があります。

要件の段階で見つかれば、要件文を直すだけ。設計の段階で見つかれば、設計と要件を直す。実装の段階で見つかれば、コードと設計と要件を直す。運用の段階で見つかれば、それに加えて、本番のデータの整合性、顧客への謝罪、ロールバックの段取り、再発防止策の整備、まで全部が乗ってきます。同じ欠陥でも、見つかった瞬間が後ろに行くほど、巻き込まれる範囲が増える。

実装の労力がAIで小さくなっても、運用後に発覚した欠陥の被害範囲は変わりません。むしろ実装が速くなったぶん、本番までの距離が短くなる。要件で見つけることの相対的な価値は、AI時代のほうがむしろ上がっている。

ここに、見積もりの世界からもう1つの示唆を持ち込みたいです。「要件が固まらないと見積もりも固まらない」という関係です。

プロジェクト初期の見積もり誤差は、信じられないほど大きい。「短く済むかもしれないし、何倍にも伸びるかもしれない」という幅で出てくることが普通です。要件が固まり、設計が詰まり、実装が進むにつれて、この幅は段階的に縮まっていきます。要件を固める作業は、見積もりの幅を縮める作業でもある、という関係です。

逆に、要件が曖昧なまま走ると、見積もりの幅は狭まりません。プロジェクトが進めば自動的に確実になる、というのは幻想です。要件を明確に決め、設計を詰め、意思決定を重ねることでのみ、不確実性は減る。AI時代になって実装が速くなっても、この構造は変わらない。要件を曖昧にしたまま速く実装するのは、広い不確実性のまま速く走ることであり、たいてい広い範囲のどこかで事故が待っています。私の場合は、ちょうど真ん中で待っていました。要件が固まらないうちに「3か月でできます」と返したことがある。実装はAIで速かった。3か月後、動いてはいたが、業務が回っていなかった。速く作ることと、正しいものに着地することは、別の問題だと気づくのに、もう3か月かかった。

そして、もう1つ重要な区別があります。見積もりとコミットメントとターゲットは別物だ、ということです。

見積もりは予測です。「これだけのスコープなら、たぶんこのくらいの工数で終わる」。客観的な分析の結果。ターゲットは目標です。「展示会までに出したい」「四半期末までに終わらせたい」。ビジネスの希望。コミットメントは約束です。「この日までに、これを出すと約束する」。組織への宣言。

この3つを混ぜて議論すると、対話が必ず壊れます。経営が「3か月でやってほしい」（ターゲット）と言ったとき、エンジニアが「7か月かかります」（見積もり）と返すと、両者の言葉は噛み合いません。両方とも正しい。ただ、別のことを言っているだけです。

ターゲットと見積もりがズレているとき、それはプロジェクトが失敗するかもしれない貴重な信号です。選べる道は4つしかありません。スコープを削る、予算を増やす、目標を調整する、やめる。ズレを早期に検出するのが、要件発見の役割でもあります。要件を曖昧にしたままプロジェクトを走らせると、このズレが見えないまま終盤まで進み、最後の3つの選択肢（予算増・目標調整・中止）すら手遅れになります。

要件の検討に時間をかけるのは、開発を遅らせる行為ではありません。全体としては開発を加速させる投資であり、同時に、組織の意思決定を健全に保つための情報収集でもある。

適当だった見積もりと要件、それでも動いてきた現場

ここで一度、自分たちが立ってきた現場を、敬意を持って振り返っておきたいです。

事実として、要件や見積もりは、現場で長く適当に扱われてきました。「適当」は、いい加減という意味ではない。正確には決められないものを、正確に決めずに動かしてきた、という意味です。現場の怠慢ではなく、不確実性を扱うための知恵の選択でした。

見積もり誤差はプロジェクト初期に大きく、要件が固まるにつれて段階的に狭まる。初期段階で正確な数字を出すのは物理的に不可能ですが、それでも数字は要求される。エンジニアの自己申告は楽観に出やすい。「ほぼ確実」と思っていた見積もりが半分も当たらないことは珍しくない。個人の怠慢ではなく、視界の構造と認知の自然な特性です。

それでも回ってきたのは、先人たちが多層のバッファで楽観の数字を吸収する仕組みを暗黙に組み上げてきたからです。ベテランが若手の見積もりを肌感で割り引く。プロジェクトマネージャが長めの納期で発注する。最終的に機能を一部削って出す。これは欠陥ではなく、不確実性を組織と個人で吸収する高度な調整でした。

要件のほうも同じ構造でした。「ユーザーが商品を検索できる」のような検証不能に見える要件文が普通に承認されてきた。それでも回ったのは、現場のエンジニアと依頼者の間で、書類の外側にある共通の業務理解が動いていたからです。ドキュメントの不完全さは、組織の暗黙知が補っていた。これは怠慢の選択ではなく、知恵の選択です。

ところが、AI時代になって、この補正の経路が急速に脆くなることに気づき始めました。AIは要件文の通りに実装します。書かれていない常識は補完しない。ベテランが暗黙で補正していた差分は、コードに直接漏れ出します。「3か月で」と指示されれば3か月分のスコープに合わせるが、本当に3か月で終わるかの判断はしない。人間の楽観的な数字が、補正されないまま実行に流れる。

これは先人たちの知恵が無効になった話ではありません。前提が変わっただけです。ドキュメントの外側で動いていた補正を、ドキュメントの中（コード、型、テスト、CLAUDE.md、skill）に移していく必要が出てきた。

私の現在の方針は、先人たちが暗黙でやっていたことを、明示的に書き直すことです。単一の数字ではなく分布で書く。検証可能な要件文に書き直す。漏れていた活動を見積もりに含める。AIへ渡す前、自分の頭の中で行ってきた補正を1つ書き出しておく。これは暗黙の補正系を明示の補正系へ翻訳する作業であって、ゼロから始めるのではない。既にある知恵を、新しい器に注ぎ直しているだけです。

機能の優先順位を多面的に見る

要件を引き出して書き出すと、すぐに次の問題が来ます。全部を一度に作れないのだから、何から作るかを決めなければなりません。ここで言う優先順位は「どの機能から作るか」の話です。非機能要件の優先順位は性質が違うので、別の規律として第2部で扱います。

優先順位付けは、現場でしばしば「重要度」の一軸でやられます。最重要、重要、普通、低い。これは判断としては乱暴で、揃って「最重要」の要件が10個並ぶ、という状況に陥りがちです。

私が現場で使っているのは、複数の軸で見直す方法です。少なくとも次の5つの軸で、それぞれ要件を点数化します。

期待される収益・効果：その要件が実装されたとき、ビジネスにどれだけの便益をもたらすか。売上、コスト削減、満足度向上、いずれかで測れる。

ビジネスリスク：実装しなかった場合の損失。法令対応、セキュリティ、信頼失墜、競合への遅れ。実装しないこと自体がリスクになる要件は、優先度が高い。

実装リスク：実装しようとしたときの不確実性。技術的に難しい、未経験のドメイン、依存関係が多い、これは実装リスクが高い。早期に試して情報を得たい要件は、リスクが高くても優先度を上げる場合がある。

データと依存の前提条件：他の要件が先に動いていないと、この要件は意味をなさない、という関係。前提となる要件が完成していないなら、後段の要件をどれだけ高優先度にしても、待たされる。

ステークホルダーの可視性：実装したことが、誰の目にどう映るか。営業の前で見せる場面、顧客の最初の体験になる場面、社内のキックオフで紹介される場面。こういう「見られる場面」がある要件は、心理的な意味で優先度が高い。

5軸で点数化して合算すると、単一軸では見えなかった順序が出てきます。期待される収益は中くらいだが、依存関係の起点になっているからまず作る、というような判断ができる。順序は単一の数字ではなく、複数の軸の合議で決まる、というのが私の現在地です。

そして、優先順位はプロジェクトの初期に固定しないことが大事です。しばらく走った後に状況が変わる。新しい情報が入る。市場が動く。優先順位の根拠そのものが、時間とともに見直しの対象になります。要件の発見が反復的なら、優先順位の判断も反復的です。今日の最優先が、しばらく経っても最優先である保証はない。

点数をつけるのは誰か

5軸で点数化する、と書きました。それで決まると書きました。書いてから、自分で立ち止まります。点数をつけるのは誰か。

私が一度やった失敗を書いておきます。期待される収益、ビジネスリスク、実装リスク、依存の前提、可視性。5軸を表にして、要件30本に点数を振りました。表は綺麗にできあがった。順序も明確に出た。会議で表を見せました。営業の責任者が、自分の案件の点数を見て、黙りました。次の週、別の営業の責任者から、点数の根拠を問う長文のメールが届きました。

表は嘘をつかない。表を作った私が、嘘をついていた。期待される収益の点数を、私は自分の感覚で振った。実装リスクの点数も、私が振った。依存関係の点数も、私が振った。営業の現場感、経営の戦略意図、現場の温度。これらは表のセルの中で1つの数字に圧縮されていた。圧縮した私の解釈が、組織の判断として走りそうになっていた。

5軸そのものは正しい。たぶん。問題は、軸の重みと、各セルの点数を、誰がどんな根拠で決めるかでした。点数をつける人が変われば順序が変わる。重みを1.5倍にする軸を変えれば順序が変わる。点数は客観的に見えますが、点数の生成プロセスは政治と認知のバイアスでできている。表の見た目に騙されると、合意していないものを合意したことにできる。

今は、点数を1人で振らないようにしています。少なくとも収益は営業と、実装リスクはエンジニアと、依存は設計者と、可視性は経営と、それぞれの一次情報を持つ人と一緒に振る。点数の根拠を1〜2行のメモで残す。重みを変えると順序がどう動くかを、表で並べて見せる。順序を1つに固定して持っていかない。点数化は意思決定を置き換えない。意思決定の対話の入り口に過ぎない、というのが今の私の現在地です。

5軸は道具です。道具は使い手の手癖を映します。道具を綺麗に使えば判断が綺麗になる、というのは幻想で、道具を使う前と使った後に、人間の側で考え続ける時間が要る。点数を見て楽になりかけたら、自分が何を圧縮したかを思い出すようにしています。

要件はビジネスイベント単位で分けて書く

優先順位を決めたとして、その要件をどの粒度で分けて書くか、という問題が次に来ます。私が現場で使っているのは、ビジネスイベント単位で要件を分割する考え方です。

ビジネスイベントとは、業務の流れの中で「外から何かが起きる」瞬間です。「顧客が商品を注文した」「在庫が補充された」「支払いが完了した」「キャンセル要求が届いた」。それぞれが、システムが応答すべき独立したトリガーです。

機能ごと、画面ごと、ユーザーロールごとに要件を分ける流派もありますが、ビジネスイベントで分けると、いくつかの利点があります。

1つ目は、要件の独立性が保たれることです。1つのビジネスイベントに対する応答は、システムの内部設計から切り離して記述できます。「注文が入ったとき、在庫を確保し、決済を予約し、配送伝票を発行する」のような、業務として完結した単位で書ける。これは内部実装が変わっても陳腐化しません。

2つ目は、ステークホルダーの専門家が特定しやすいことです。「商品検索機能」だと、誰がオーナーか曖昧になります。「在庫補充イベント」なら、倉庫担当の責任者が明確に決まる。要件発見の対話相手を選びやすくなります。

3つ目は、増分開発と相性がいいことです。1つのビジネスイベントの応答を、独立して実装してリリースできる。複数のイベントが互いに干渉しないように設計しておけば、ビジネスイベントごとに優先順位を付けて、価値の高い順から実装していけます。

要件をビジネスイベント単位で書く規律は、システムの内部設計と要件を切り離すための装置でもあります。実装の言葉で要件を書くと、内部設計が変わるたびに要件が陳腐化します。ビジネスイベントの言葉で書くと、業務が変わらない限り要件は生き続けます。AI時代に実装はAIに任せ、合格基準だけは人間が握るという構えを取るとき、この粒度設計が効いてきます。

「在庫の2文字」を要件文に書く

具体例で締めくくります。AIに渡す要件文として、悪い書き方と良い書き方を並べてみます。

悪い要件文。

商品検索APIを実装する。GET /api/products?q={query} を提供し、
products テーブルから LIKE 検索でマッチする商品を返す。
レスポンスは JSON 形式で、id, name, price, stock を含める。
ユーザーフレンドリーに、なるべく高速に。

良い要件文。

ユーザーは、購入可能な商品を名前の一部で検索できる。
- 在庫がない商品は結果に含まれない
- 検索文字が商品名の一部に含まれていれば該当する
- 結果は1ページに最大20件、関連度順
- 該当0件の場合は「見つかりませんでした」と表示する
- 検索開始から結果表示まで、最低限3秒、目標1秒、意欲的0.5秒、願い0.1秒

悪い例は実装を書いています。LIKE検索やJSONレスポンスは、エンジニアの判断であって、依頼者が決めることではない。さらに「ユーザーフレンドリー」「なるべく高速」という、悪い言葉が入っている。これでは、できたかどうか判定できない。

良い例は、依頼者と合意できる粒度で、検証可能な条件だけを書いています。在庫がない商品を含めない。20件。関連度順。0件時の文言。応答時間の段階。すべて「できた／できなかった」を判定できる。実装はAIが選んでよい。LIKE検索でも、転置インデックスでも、ベクトル検索でもいい。実装はAIに任せ、合格基準だけは人間が握る。

ただし、決済・個人情報・人命や安全に関わる領域では、合格基準だけ握れば十分、とは言えません。実装の選択そのものが脅威モデルや規制適合に直結するため、実装手段にも人間のレビューを残す判断が要ります。検証可能性の議論は、ここでは「合格基準を握る」だけでなく「許容できる実装手段を限定する」まで踏み込むのが安全側の倒し方です。

そして大事なのは、悪い例には「在庫の2文字」が無いことです。良い例の「在庫がない商品は結果に含まれない」は、過剰に詳しい指定に見えるかもしれない。でもこの1行が無いだけで、AIは無在庫商品を含む実装を返してきます。書かれていない常識は、AIには届かない。

要件の独立性は、AI時代の資産価値そのものだと考えています。問題領域の言葉で、検証可能な形で適切な層に置かれ、悪い言葉を避けて書かれた要件は、AIに渡せば何度でも実装し直せる。要件が腐らない限り、コードは流動的でいい。これが、AI時代の要件の形です。

「やらないこと」と「想定していないこと」を明記する

「在庫の2文字」を書くこと、つまりやることを明示するのが要件の半分だとすれば、もう半分はやらないことと想定していないことを明示することだと考えるようになりました。AI時代になって増えた書き仕事は、この後ろの半分です。

人間相手の要件文では、書かれていない部分は「常識」「現状維持」「特に指示なし」と解釈されました。先輩や同僚は、書かれていない領域を察しで埋めてくれた。AI相手の要件文では、書かれていない部分は世界の平均値で埋められます。世界の平均値の中には、「あえてやらない」「この場合は対応しない」「この属性は分岐させない」のような負の指定は含まれません。肯定形だけで要件を書くと、AIは黙って「世界の平均が要求してくる挙動」を実装してきます。

実例を1つ。「ユーザーが商品をカートに入れる」という要件を書いて、「ログインしていないユーザーの扱い」を書かなかったことがあります。AIは未ログインでもカートに入れられる実装を返してきた。私たちのプロダクトでは、未ログインのカート操作は明示的にやらない設計だった。書かなかった。だから消えた。「ログインしていないユーザーは、カートに入れられない」と1行書いていれば、3時間が消えずに済んだ。在庫の2文字と同じ構造の事故が、今度は「やらない」の側で起きていました。

もう一段先があります。「想定していないこと」も想定していないと明記する必要が出てきた、ということです。「年齢層は問わない、地域による分岐は想定していない、1リクエストあたり100万件を超えるデータは現バージョンの対象外」。書かなければ、AIはありそうな分岐を勝手に想定して実装します。良かれと思って入れた条件分岐が、要件にない複雑さを実装に持ち込む。想定していないことを想定していないと書く——これは、人間相手なら過剰だった書き方です。AI相手だと、ちょうどいい温度になります。

正直に言うと、私もまだ慣れていません。要件文に「やる」を書くのは自然ですが、「やらない」を書くのは不自然な感覚が抜けない。書きながら「これ、書かなくても分かるだろ」と思ってしまう。相手は分からない。AIは「分かるだろ」を学習していない。頭で知っていても、手が止まる。書く側の常識が、書かれない領域を作る。AIはその領域に世界の平均を流し込む。書く側が自分の常識を疑わない限り、書き漏らしは止まりません。

「やる」「やらない」「想定していない」の3つを揃えて、初めて1つの要件は閉じます。閉じていない要件は、AIにとって世界の平均で埋めていい余白です。要件文を読み返すとき、私は最近、「ここで書かれていないことを、AIは何で埋めるか」を一度ずつ自問するようにしています。3つのうちどれかが抜けていたら、抜けたところに平均が流れ込む。流れ込んだ平均は、たいてい、こちらの常識と一致しません。

問題空間を見る前に、解空間に飛ばない

要件を引き出すという話の続きですが、もう一段だけ手前の話をしておきたいです。観察の話です。

良い要件文を書く前に、もっと前段でやるべきことがあります。何を解こうとしているのかを見極めることです。要件工学の中でも特に強い区別が、問題空間と解空間を分けるという考え方です。問題空間は「ユーザーが達成したいジョブ、満たしたいニーズ、抱えている制約」の世界。解空間は「それに対して何をどう作るか」の世界。両者は地続きに見えますが、混ぜると要件が壊れます。

混ぜるとどうなるか。「商品検索画面が欲しい」という言葉が、要件として入ってきたとします。これは解空間の話です。問題空間ではありません。問題空間にあるのは「ユーザーは買いたい商品を素早く見つけたい」「無駄な操作で離脱させたくない」「在庫切れ商品をクリックさせて落胆させたくない」といったニーズです。「検索画面」は、それらのニーズに対する1つの解にすぎない。

問題空間に立ち戻らないまま要件を書くと、最初に出てきた解の延長で要件が硬直します。本当に必要だったのは検索画面ではなくレコメンド機能だったかもしれない。あるいは検索画面だったとしても、フィルタ・並び順・在庫フラグの扱いは、ニーズから逆算しないと決まらない。良い要件は、解空間で書かれていても、問題空間に根を持っている必要があります。

本質的な難しさと、付随する難しさ

問題空間と解空間を分けると、もう1つ便利な区別が見えてきます。本質的な複雑さと付随的な複雑さの区別です。

本質的な複雑さは、解こうとしている問題そのものが持つ複雑さです。「在庫管理を、複数倉庫、複数チャネル、リアルタイム、誤差を許さない、で動かす」。これは、業務領域が持つ本来の難しさです。どんな技術を使っても、消えません。

付随的な複雑さは、その問題を実装するときに、たまたま発生する複雑さです。フレームワークの癖、ライブラリのバージョン差、デプロイ環境の制約、ボイラープレートのコード。これは、業務とは関係なく、ツールチェーンや実装手段に由来します。

AIが得意なのは、付随的な複雑さの処理です。フレームワークのお作法に沿ってコードを書く、似たパターンの繰り返しを生成する、ライブラリの呼び出しを正しく組み立てる。これは、AIで桁違いに速くなりました。

逆に、AIが本当の意味で代替できないのは、本質的な複雑さの理解です。業務領域を深く知る、ステークホルダーの矛盾を解きほぐす、過去の失敗から学ぶ、未来の変化を予測する。これは、ドメインの中で時間をかけて積み上げてきた知の蓄積で、文章で書き出せる範囲を大きく超えています。

要件発見の仕事は、この本質的な複雑さに人間が向き合うことです。付随的な複雑さから解放されたぶん、空いた認知を本質の解明に投入する。これが、要件発見がAI時代に重みを増す理由です。

ここを混同すると、危険なことが起きます。AIに本質的な複雑さまで丸投げしようとすると、AIは推測で埋めてしまいます。AIが返してくる「なんとなく整合的に見える要件」が、実は業務とまったく合っていない、ということが起きる。本質的な複雑さは、人間が引き受ける領域だ、という線引きが要件発見の出発点です。

人は製品ではなく「片付けたいジョブ」を雇う

問題空間を覗き込むときに、私が拠り所にしている見方があります。人は製品を買うのではなく、自分のジョブを片付けるために製品を雇う、という見方です。

ジョブとは、その人が達成しようとしているタスク、目標、目的です。回避したい問題や、解消したい不快も含みます。重要なのは、ジョブは製品の外側、ユーザーの生活の文脈の中に存在するということです。プロダクトの機能はジョブを片付ける手段にすぎません。

例として、社内の業務システムを考えます。「経費精算システム」を雇った担当者のジョブは、「経費精算をすること」ではありません。本当のジョブは「月末の作業を最短で終えて、本来の業務に戻る」だったり、「経理から差し戻されない正確なドキュメントを出して、自分の評価を傷つけない」だったりします。ジョブは仕事の合間で発生する、割り込みコストとしての処理だ、というのが利用者の見方です。

ジョブが見えると、要件が変わります。「経費精算システム」の要件として「画面遷移をシンプルにする」は表層的です。本当に効くのは「領収書の写真を1枚撮ったら、ほとんどの精算が完了している状態」のような、ジョブの完了に直結する要件です。ジョブを把握していないと、機能を足すたびに「使いやすくなった」と言いながら、ジョブの片付けは遅くなる、という現象が起きます。

ジョブには種類があります。機能的なジョブは、達成したいタスクの実体です。「経費精算を完了する」「リモートで授業を進行する」。感情的なジョブは、ジョブを片付けるときに感じたい気分です。「不安なくミスなく終えたい」「自分が遅れていないと感じたい」。社会的なジョブは、他者からどう見られたいかです。「真面目に処理する人だと評価されたい」「同僚に迷惑をかけたくない」。

3種類は同時に存在します。機能だけを満たしても、感情と社会の側で違和感が残ると、ユーザーはその製品を「雇い続けて」くれません。要件が機能ジョブに偏ると、見落とされたジョブの分だけ、満足度が下がる。

ジョブを軸に要件発見をすると、ユーザー属性ベースの議論から、ジョブベースの議論に変わります。「30代女性の検索行動」を分析するのではなく、「忙しい平日の夜に、明日の朝までに必要なものを買い切るジョブ」を分析する。前者は属性に紐づいた解釈で、後者は文脈に紐づいた行動です。AIに渡す要件文を書くときも、属性ではなくジョブから書くほうが、出てくる実装の精度が上がります。

ジョブから書くという見方は、AI時代になって相性が良くなったと感じています。AIは平均的な属性データから平均的な解を返してきます。ジョブで切り直すと、属性をまたいで通用する問題の核が見えてきて、AIの出力もそこに焦点を合わせられる。

言葉の境界が、そのままドメインの境界になる

問題空間を観察するときに、私が一番気をつけているのが言葉の選び方です。

ドメインで使われる言葉を、そのまま要件に持ち込む。エンジニア同士の符丁に翻訳しない。「ユーザー」と書きたくなる場面で、ドメインに「購入者」「会員」「ゲスト」の区別があるなら、その区別を保ったまま要件に書く。言葉を統一する規律が、ドメインの輪郭を要件文へ乗せる手段になります。

これは古い話のようで、AI時代になって威力が増しました。AIは渡された言葉から世界を再構成します。要件文の言葉とコードの命名、それにデータベースのカラム名がズレていると、AIには「このユーザーとあの会員の関係」が解釈できません。一致して書いてあれば、解釈の揺れがなくなる。言葉の統一が、AIへのコンテキストの密度を上げる。

そしてこの言葉は、コンテキストの境界と一致します。同じ「セッション」という単語でも、認証ドメイン・UI・分析ドメインでは別の概念です。一見同じ言葉でも、文脈が違えば意味が違う。混ぜれば、要件とコードが壊れる。

だから要件には、どの文脈で使っている言葉なのかを必ず明示します。文脈ごとに異なるモデルを許す、という設計の規律が、要件の精度を底上げします。文脈の境界が引かれていない要件文は、AI時代にあっという間に破綻する。

観察の難しさ、言わないこと、言えないこと、見ないと分からないこと

「観察」と言うと、ヒアリングを丁寧にやることだと誤解されがちです。違います。観察とは聞かなくても分かる事実を見つけにいく営みです。そして、観察は思っているより難しい。

ユーザーは多くのことを言いません。一番頻度が高いのは「不便すぎて、もう不便だと思っていない」というパターンです。毎日同じ操作を長年やっていると、その不便は風景の一部になります。聞いても「特に困ってない」と返ってくる。困っていないのではなく、困っていることに気づかなくなっているだけです。観察者がその不便を発見するためには、別のドメインや別のユーザー体験と比較する視点が要ります。

ユーザーは多くのことを言えません。何かが不便だと感じていても、それを言葉にする語彙を持っていない場合があります。「なんかイライラする」「使ってると疲れる」「終わった後にぐったりする」。こうした感情の手前にある、もっと具体的な原因を本人が特定できないまま、漠然とした不満だけが語られます。これを聞いて「イライラする」を要件に書いても、何も解けません。観察者が、その感情の発火点を現場で目撃する必要があります。

そして、ユーザーは見ないと分からないことを持っています。画面の前で実際に何を見ているのか。どこで手が止まるのか。何度操作をやり直すのか。本人に聞いても、ほとんどが思い出せません。「自然にやっている」からです。自然にやっている操作の中にこそ、設計上の摩擦が埋まっています。これは現場で観察するしかない。

業務システムなら、観察対象は画面操作だけではありません。現場で人が紙に書き出している項目、Excelで作っている裏マスタ、メモ帳に書かれた手順書、付箋に書かれた値、ホワイトボードに残った計算式、口頭で引き継がれている例外処理。これは正式な業務として記録されないことが多いですが、本当の要件はそこに眠っています。正規の文書には載らない運用の機微を、観察で拾う。これが言葉になっていない要件の発見です。

観察にはもう1つ、根本的な難しさがあります。観察者バイアスです。観察する側は、すでに自分の解釈の枠を持っています。「ここが不便なはずだ」「こう改善すれば効くはずだ」という仮説を持ったまま現場に行くと、仮説に合う事実だけが目に入ります。仮説に合わない事実、自分が予想していなかった現象は、観察したのに気づかない、ということが起きます。

私が現場で気をつけているのは、仮説を持って現場に行くが、現場では仮説を一旦置くことです。先入観のまま観察すると、確証バイアスで歪みます。先入観を完全に消すのは無理ですが、現場で起きている現象を、自分の仮説で解釈する前に、まず記述するように動きます。「ユーザーは経費精算で困っている」と解釈する前に、「画面が出てから入力開始までしばらく目線が上下に動いている」と記述する。記述してから解釈する順序が、観察を健全に保ちます。

集合的な観察の手段もあります。複数の関係者を集めて、業務の流れを時系列でマップしていくワークショップは、個人の観察では届かないドメインの輪郭を浮き上がらせます。経理が「ここで差し戻しが頻発している」と書き、現場が「私はここで諦めて手書きに戻している」と書き、システム担当が「このデータがここで重複している」と書く。それぞれの視点が交差する場所に、本当の問題があります。部屋の中に、必要な知識が揃っている——これがワークショップ形式の本当の価値です。別々にインタビューすると断片を繋ぐ作業が膨大になりますが、1つの部屋に全員を集めれば、繋ぐ作業をその場で終わらせられる。

観察の最後の難しさは、解空間に飛びたくなる衝動です。困っている現場を見ると、すぐに「これを実装すれば解決する」というアイデアが浮かびます。これはたいてい早すぎる合図で、観察を続けると最初のアイデアでは届かない別の問題が見えてきます。観察は、面倒くさくなるまで続けるくらいでちょうどいい。

AIには、この観察ができません。マルチモーダルが進んだとはいえ、現場の身体的な観察を人間と同じ重みで意味づける段階にはまだ至っていない。視線の動きや付箋の落書き、口頭の例外処理は、AIに渡せる形で残らない。観察してテキスト化することは、AI時代に価値が上がる仕事です。観察の生データはノイズが多くAIに直接渡しても整理がつかないので、解釈し、構造化し、要件として書き直す。観察 → 記述 → 解釈 → 要件の変換パイプラインの最初の3ステップは、当面、人間の領域です。

プロトタイプは観察の道具になる

要件発見の最後に、もう1つ書いておきたい技法があります。プロトタイプを早く作って、観察の道具に使うことです。

従来、プロトタイプは「実装の前段、要件が固まった後で作るもの」と位置づけられていました。AIで開発が速くなった今、この順序は逆転できます。要件を厳密に固める前に、AIで荒いプロトタイプを作り、それをユーザーに触らせて反応を観察する。触るプロトタイプは、聞くインタビューより遥かに多くの情報を引き出します。

文章の要件文を見せて「これでいいですか」と聞くと、ステークホルダーは自分が想像できる範囲でしか答えません。動くプロトタイプを触らせると、想像できなかった反応、想定外の操作、言葉になっていなかった違和感が浮き上がります。「これは違う」「ここでつまずく」「こういう使い方をしたい」。ステークホルダー自身が気づいていなかった要件が、触ることで初めて言葉になります。

AIで実装が速くなったぶん、この観察ループを1日に何度でも回せるようになりました。要件を固めてからプロトタイプを作るのではなく、プロトタイプを作りながら要件を固めていく、という順序です。

ただし、プロトタイプはあくまで観察の道具です。プロトタイプそのものを完成品の方向に育てると、不要な機能が積み重なって、本来の要件から外れていきます。観察が終わったらプロトタイプは捨てるくらいの覚悟が要ります。残すのは、観察から得られた要件文のほうです。プロトタイプは要件の出発点ではなく、要件発見の触媒だ、というのが私の現在地です。

コアドメインを見つけて、戦略的に投資する

観察と言語化を通じて見えてくるのは、ドメインの中に重みの違う領域があるということです。すべての領域に同じ熱量を注ぐ必要はありません。

ドメインの中身は、おおまかに3種類に分かれます。コアは、組織を競合と差別化する、独自の価値を生む領域。支援は、業務に必要だが差別化要因ではない領域。汎用は、業界共通の標準的な機能で、外部の既製品で十分な領域。

要件の重さは、この分類で大きく変わります。コアでは、独自の概念を共通言語で精緻に定義し、検証可能な要件を厚く書く。支援では、業界の標準パターンに合わせる。汎用では、SaaSや外部APIに任せて、要件文は最小限。コアに労力を集中するのが、要件投資の正しい配分です。

そしてここに時間軸の罠があります。今日のコアが、しばらく経った後もコアである保証はない。技術が進化し、コモディティ化が進むと、かつてのコアが汎用に降格します。要件の重みは、ドメインの進化段階に合わせて、定期的に見直す必要がある。書かれた要件をそのまま守っていると、いつの間にか「もう汎用なのに過剰な独自要件を維持している」という状態になります。

要件は静的でない。ドメインの進化に追随する動的な資産だと考えています。

チームの境界とドメインの境界を一致させる

もう1つ、観察すると見えてくるのは、チームの境界が要件の境界に影響することです。1つのドメインを2つのチームで分けて持つと、要件の議論が必ず歪みます。逆に、複数のドメインを1つのチームで持つと、認知負荷で詰まる。

この問題は古くから議論されてきました。システムの構造は、組織の構造を反映する。要件をきれいに書こうとしても、組織の境界がきれいでなければ、要件もきれいになりません。

実務的には、チームの境界とドメインの境界を意図的に揃えるのが効きます。1つのチームが1つのコンテキストを持つ。コンテキスト間の依存はAPI契約として明示する。チームが要件のオーナーシップを持てるなら、要件の質は自然に上がります。所属が曖昧な要件は、誰にも本気で守られません。

私自身、これを軽く見て足を取られたことがあります。1つのコンテキスト——たとえば在庫——を、倉庫管理チームと販売管理チームに二分して持たせていた時期がありました。要件文は何度書き直しても、両チームで「在庫」の意味が微妙にズレる。倉庫の在庫は物理的な棚卸の数で、販売の在庫は引当済みを差し引いた残数だった。同じ単語に違う定義が宿っていた。要件を綺麗に書こうとして3回書き直しましたが、3回とも片方のチームから「これは違う」と返ってきた。書き手の問題ではありません。1つの言葉に2つの所有者がいる構造を、要件文の側から修正することはできなかった。組織の線を引き直して初めて、要件文は1度で通りました。要件発見より前に、組織の線を見ているか。私はこの順序を、いま、自分への問いとして残しています。

これも観察の話に戻ってきます。組織を観察し、認知負荷を観察し、チーム間の依存関係を観察する。観察した結果としてチームを再編する判断は、要件定義の前段にあります。要件は組織の影であり、影だけを直そうとしても本体は動かない。

観察の結果として、ようやく要件が言葉になる。言葉になった要件だけが、はじめて実装に渡せる対象です。観察 → 言語化 → 実装、というのが私の中の順番です。

揺らぎと固執に、あなたの仕事が残る

要件を言葉にする話を、もう一段角度を変えて続けます。観察を通じて自分たちのコンテキストの個別性を発見できたとして、それをAIから守るためには何が必要か、という話です。

AIで開発する組織を観察していて、ここ数ヶ月、似た現象に何度も気づきました。みんなの出力が、だんだん同じになっていく。

同じツール、同じ答え

同じモデル、同じハーネス、同じプロンプトを使えば、出てくるコードはほとんど同じです。同じ最適解。同じパターン。同じ命名。同じテストの書き方。同じエラー処理。同じ命名規則。これは効率としては素晴らしい。チーム間で書き方がブレなくなり、レビューが軽くなる。でも、組織のレベルで見ると、危ない。

組織Aと組織Bが同じツールを使い、同じ最適解を採用すれば、両者の差は消えます。プロダクトの設計判断、UIの細部、エラー処理の癖、エッジケースの扱い、データの持ち方、APIの命名、ログの書き方。全部、AIの平均値に収束します。少し前なら「このコードを見たらAさんが書いたと分かる」「このAPIの設計は明らかにB社の流儀だ」と感じられたものが、消えていく。癖には、それなりの意味があったはずだ。少なくとも、誰が書いたかが伝わる程度には。

これは個人の生産性の問題ではなく、組織の生産性の天井がどこに引かれるかの問題です。

AIの最適解は「世界の平均値」

AIは過去の大量のデータから「もっとも一般的に正解とされてきたもの」を返してきます。それは「世界の平均値」です。あなたのプロダクトの個性は、世界の平均値の中には無い。

これは責めるべきAIの欠陥ではなく、AIの定義そのものです。学習データの中で多数派だった解が「最適」として返ってくる。少数派だった解は、たとえあなたの組織にとって正しい判断であっても、AIの評価では下位に沈む。

要件文をAIに渡して実装させると、出てくるコードは「業界標準」に寄ります。要件の余白をAIが埋めるとき、その埋め方は世界の平均で決まる。書いていない部分は、世界に同質化される。これは要件の欠落の話と地続きです。書かれていない部分は、AIが想像で埋める。AIの想像は、世界の平均値に向かう。

ここから出口は2つしかありません。書かない部分を残して同質化を受け入れるか、書く範囲を増やして自分たちの個性を保つか。

揺らぎとは、AIの評価が低い選択を意図的に取ること

差別化を生むのは、AIの評価では低い選択を、意図的に取ることです。

これは多くの場面で起きます。AIが「この実装パターンが標準です」と提示してきたとき、自分たちの文脈ではあえて違う選択を取る。ユーザー体験の細部で、業界の常識から外れた判断を貫く。エラーメッセージの言い回しで、世間の標準的なトーンではなく、自分たちのブランドの声を維持する。データモデルで、業界の典型から少しズレた構造を保つ。一つひとつは小さな選択ですが、積み重ねると、それがプロダクトの個性になります。

AIの最適解との距離を、どこまで許容するか。この線引きの中に、個性の源があります。距離をゼロにすると、誰のプロダクトでもなくなる。距離が大きすぎると、効率を捨てる。意図的に距離を選ぶ判断が、AI時代の差別化です。

私はこの「意図的な距離取り」を、揺らぎと呼んでいます。揺らぎは弱さではない。戦略です。世界の平均値からの偏差を、自分たちのコアに対してだけ、意図的に確保する。汎用領域では平均に寄せていい。コアでは揺らぐ。揺らぎどころを選ぶことが、要件設計の中心的な仕事になっています。

平均値に乗ることは、楽です。誰にも責められない。基準を世界が用意してくれる。問題は、その楽さの中で、自分たちが何を選んだのかを説明できなくなることです。揺らぎは、説明責任を自分の側に引き寄せる行為でもある。世界の標準で良かったものを、あえて違える。違えた理由を、自分の言葉で言える状態にしておく。それができないなら、揺らぐべきではないとも思っています。

AIの「自信」を割り引く

実務的に注意したいのが、AIが提示する評価や予測を、人間の感覚で割り引く必要があることです。

AIは、自分の出力に対して妙に自信があります。「ほぼ確実に正しい」「最適です」「業界のベストプラクティスです」と返してくる。実際には、その自信が成立する前提条件は脆い。一手間違えると一気に崩れる構造になっているのに、AIは平然と「最適」と表現します。

これは、AIに不安や恐怖や慎重さがないからです。人間の経験者なら「自信ありそうに見えるが、ちょっと怪しいから半分くらいに見ておこう」と肌感覚で割り引ける。AIにはこの調整がない。出してきた評価は、額面通りには信用できない。

これも、自分の話として書いておきます。あるリファクタリング案をAIに評価させたとき、「ほぼ確実に安全」と返ってきました。私はその「ほぼ確実」を1.0として受け取った。テストを通し、レビューも通し、本番に出した。3日後、特定の条件で副作用が漏れる問題が見つかりました。冷や汗より先に、自分への苛立ちが来た。AIは「ほぼ確実」と書いたのであって「絶対」とは書いていない。差を読まなかったのは私だ。今は、AIが「ほぼ確実」と書いたら0.7として読み、「最適」と書いたら0.5として読むようにしています。割引率に根拠はありません。あくまで私個人の現場感で、領域・モデル・タスクごとに調整が必要な数字です。決済や医療のような事故が許されない領域では、これより厳しく見るべきだとも思っています。たぶん、これも甘い。それでも額面で受け取るよりは事故が減りました。AIの自信は割り引ける。割り引いた後の数字に、自分が責任を持てるか——そちらのほうが、私には難しい問いです。

評価値を時系列で見ると、もっと厄介な性質に気づきます。同じ問題でも、コンテキストやプロンプトを少し変えると、AIの評価がガラッと変わる。さっきまで「最適」だったものが、しばらくして「微妙」になる。これに翻弄されないためには、個別の評価値ではなく、全体のトレンドを見る必要があります。短期の数字ではなく、中期の方針で動く。これも人間の役割です。

議論はAIが切り捨てた領域に踏み込む

「会議で議論した結論が、AIにあっという間に別案を出されて崩れる」という体験は、AI時代になって増えました。これに対して「議論は無駄だったのか」と感じる場面も出てきますが、私はそう思いません。人間の議論には、AIが切り捨てた領域に踏み込む価値があるからです。

AIは評価値が低い選択肢を早期に枝刈りします。でも、その低評価の選択肢の中に、自分たちの組織にとっての宝が眠っていることがある。違和感のある手、生理的に取りたくない手、業界では誰もやらない手。これはAIの最適解探索からは漏れる。人間が議論しないと出てきません。

議論の役割が変わった、と整理しています。「正解を探す場」から、「AIが切り捨てた領域に踏み込む場」へ。AIが効率よく平均値を出してくる時代だからこそ、平均から外れる視点を出せる議論の場に意味が出てきます。

固執とは、時系列の中で同じ自分であり続けること

差別化の話と並んで、もう1つAI時代に効くのが一貫性です。

その瞬間ごとにAIの最適解を取り続けると、長い目で見ると一貫性のない選択の連続になります。それぞれの瞬間では最適解だったかもしれませんが、しばらく経って振り返ると、何を目指していたのか分からない軌跡になっている。ユーザー、チーム、組織は、一貫性に信頼を置きます。「あのプロダクトはこういう判断をする」という予測可能性が、信用の土台です。

私が守ろうとしているのは、過去から現在の選択を振り返り、首尾一貫しているかを点検する習慣です。新しいAIの推奨が来たとき、過去の判断と整合するかを問う。整合しないなら、推奨を取らないか、過去の判断を意識的に上書きする。判断と判断の間に、人間が筋を通す。この「時系列での一貫性を貫く」ことを、固執と呼んでいます。固執は頑固さではなく、自分が何者であるかを忘れない技術です。

揺らぎと固執は同じものの裏表

揺らぎと固執は、矛盾しているように見えるかもしれません。揺らぎは平均から外れろと言い、固執は変わるなと言う。ただ、矛盾していません。

揺らぎは横軸の話です。同じ時刻に、世界の平均値や業界の標準解と、自分たちの選択がどれだけ離れているか。揺らぎが大きいほど、他者との違いが生まれる。

固執は縦軸の話です。時間軸の中で、過去の自分と今の自分の判断がどれだけ整合しているか。固執が強いほど、自分が同じ自分であり続ける。

横で揺れ、縦で固まる。横軸の揺らぎが個性を作り、縦軸の固執が信頼を作る。両方を保つのが、AI時代に組織が生き残る条件だと考えています。

そして、要件を言葉にする作業は、まさにこの揺らぎと固執を明文化する作業です。「うちはここで揺れる」「うちはここでは絶対に動かない」。それを要件文として書き残しておくと、AIが平均値を持ち込んできたときに、跳ね返せる。書いていなければ、跳ね返せない。AIに浸食される。

要件文は、機能のリストではなく、組織のスタイルの宣言でもある。書いていないことは、AIによって世界の平均値で埋められる。書いてあることだけが、自分たちの個性として残る。

具体例として、エラーメッセージのトーン

具体的に1つ書きます。最近、エラーメッセージのトーンで揉めました。AIが提示したのは「申し訳ございません。エラーが発生しました。サポートにお問い合わせください」という業界標準の言い回しです。私たちのプロダクトのトーンは、もっと素朴で、丁寧すぎないものでした。

私はAIの推奨を捨てて、「うまくいきませんでした。少し時間を置いてもう一度ためしてみてください」に書き直しました。AIの評価では低い選択です。情報量も少なく、サポート誘導も入っていない。だが、これがプロダクトの声でした。

そして、これを揺らぎとして残すには、固執が要ります。しばらくして、別のエンジニアがAIに別のエラーメッセージを書かせて、業界標準のトーンが混ざる。気づかなければ、プロダクトのトーンは少しずつ平均値に戻っていきます。だから、「うちのエラーメッセージはこういうトーンで書く」を要件として書き残す。プロンプトに、skillに、レビュー観点に、CIの自動チェックに。書いて残し続けることで、揺らぎが固執になります。

声を統一する規律は、AIから来ません。自分たちの中からしか来ない。

あなたの仕事は揺らぎと固執にある

AIが平均値を提示する時代に、人間の仕事はどこに残るか。

私の答えは、揺らぎを生むことと、固執を貫くことです。

揺らぎを生む — 他者と違う選択を、意図的に取る。AIが提示する標準解との距離を、どこに、どれだけ確保するかを判断する。これは「何で勝負するか」を知っている人にしかできない。

固執を貫く — 過去の自分と同じ選択を、繰り返し取る。AIの推奨が変わっても、自分たちの方針が一貫しているかを問う。これは「自分たちが何者か」を知っている人にしかできない。

どちらも、自動化されない判断です。要件を言葉にすることは、この揺らぎと固執をコードやテスト、チームの規律へ埋め込む作業です。書いていないことは、AIに飲み込まれる。書いていることだけが、自分たちの形として残る。

ただし、これは差別化を取りに行く立場での話です。コモディティ領域や追随戦略を選ぶ組織では、AIの最適解に沿うほうが合理的なはずです。距離を取る判断は、自分が何で勝負しているかを知っている人だけのものだ。コアでは揺らぐ。汎用では揃える。この線を引く判断そのものが、要件設計の最初の仕事になります。

媒体と重みと道具を変えて、要件の表現形を変える

ここまでの規律は要件発見の中身の話でした。引き出す。漁る。症状と原因のズレを疑う。階層・6つの特性・悪い言葉・段階記述・揺らぎと固執。最後に、その中身をどこに、どう置くかの話をしておきたいです。

私の現在の方針は、要件をドキュメントだけに置かないことです。ドキュメントは補助で、コード・型・テスト・スキーマに分散して焼き込む。動くものに刻まれた要件だけが、毎日読まれ、毎日検証され、変更されたら壊れて気づけます。

その移し方を、媒体・重み・道具の3つの転換で整理します。

媒体を、ドキュメントからコードへ

要件をドキュメントだけで保つのは、AI時代にはコストが合わなくなりました。

長いドキュメントはコンテキストを圧迫して精度を下げる。更新が手仕事に依存し、腐る速度がAIの実装速度に追いつかない。

だから、要件の表現形をドキュメントから、コード・型・テスト・スキーマに分散させる。要件発見の規律を捨てるのではなく、実行可能な場所に置き直す話です。

要件の本質	実行可能な表現形
検証可能性	受け入れテスト・プロパティテスト
完全性	型での全数表現（網羅的enum、Option型）
一貫性	不変条件を型で強制
トレーサビリティ	コミットメッセージ・PR・コメントへのリンク
階層（ビジネス/ユーザー/機能）	プロジェクト全体ドキュメント・領域skill・テストの3層構成
適合基準	テスト関数の本体
段階（Must/Goal/Stretch）	SLO定義・性能テストの閾値
用語の統一	型名・関数名・glossary

右の列は左の列の代替ではありません。左の列を、AIが読める形で実体化したものです。ドキュメントの中だけでなく、実行可能な場所に翻訳する。翻訳された要件は、毎回実行され、毎回検証され、変更されたら壊れて気づけます。生きた要件になります。

具体的にどうやって実装に落とすかは、後の節と第3部で書きます。

重みを、検証の網羅性に置く

要件の網羅性に投資する、というのは、書き漏れがあると手戻りが大きいので最初に厚く書く、という発想です。これは「実装した後で見つかる欠陥のほうが、桁違いに高くつく」という経済構造の上で、ずっと正しい。

ただし、ドキュメントの網羅性をいくら厚くしても、ドキュメントは読まれなければ意味がない。AIに渡すコンテキストが膨らみすぎると、肝心の要件が埋もれて読まれない。これが、ドキュメントの網羅性に投資することの限界です。

代わりに私が投資しているのは、検証の網羅性です。テストで全部表現する。型で全部縛る。lintで全部弾く。表現する場所が変わるだけで、網羅性そのものは捨てません。

この移し替えは、要件発見の伝統と矛盾しません。要件発見は最初から「検証可能性」を最重要属性として挙げてきました。検証の網羅性に重みを移すというのは、その主張をより純粋に実行する方向です。

「シリアルかアジャイルか」は二項対立ではない

要件発見の議論には、長く「ウォーターフォールかアジャイル」「シリアルか反復」という対立がありました。AI時代の現場でやっていて、この対立は本質ではないと感じるようになりました。

私の運用は、両方を並走させる形になっています。問題空間の理解。ステークホルダーの合意。コアドメインの境界設定。これは反復的にしか深まりません。一方、決めた合意点については文書化し、テストに変換し、コードに焼き込む。これは直線的な作業です。前者は反復で動き、後者は直線で動く。

突発的な変化が来たら、優先順位を組み替え、活動を切り替える。十分な確信が要る判断は、急がずに足場を固める。急ぐ場面と急がない場面を、見分けて使い分ける規律が、要件発見の中心にあります。

「ゆっくり考え、素早く動く」という言い方を、私はよく使います。考えるところでは時間をかけ、動くところでは止まらない。AIが動く速度を上げてくれた今、考える速度を意図的に落とすのが、人間の仕事のひとつです。

道具を、段階記述から型まで広げる

要件を書く道具立ては多様です。

ユースケース、ユーザーストーリー、ビジネスイベント表、決定表、状態遷移図、データフロー図、ERD、段階記述法。これは要件発見の伝統的な道具です。

それに加えて、AIが読める要件として効くのが、型システム、プロパティベーステスト、契約テスト、状態機械の型表現、ドメインモデル中心設計、エージェント向けのコンテキスト記述ファイル。これは実行可能な要件として機能します。

両者の関係は排他的でありません。併用するのが現実的です。ユースケースで全体の流れを示す。決定表で分岐を明示する。段階記述で非機能要件の幅を書く。そしてそれを型とテストに翻訳する。文書とコードを行き来しながら、要件の解像度を上げる。

道具が増えた、と書いてはみたものの、全部を同じ重さで使う必要はありません。私が最近、現場で道具の使い分けを変えたところを書いておきます。

第一に、自動生成できるものは自動生成させる。詳細な状態遷移図やAPIの型定義、依存関係グラフのような、コードが正であるべきものは、人間の手で書かない。テストや型から図を生成し、生成されたものを読む。手で図を維持しようとすると、コードの変化に図の更新が追いつかず、細部が腐っていく。生成された図は、コードが変わるたびに自動で追従します。

第二に、手で残すのは「変わらない骨格」だけにする。データフロー図のような、ドメインの大枠を示す図がそれです。コンポーネント名や具体的なAPI名まで書き込むと半年で陳腐化しますが、「どの境界をデータが越えるか」という骨格だけを残した図は、コードが何度入れ替わっても通用します。詳細は生成、骨格は手書き。手で書く層を間違えなければ、図は生き残ります。

そして第三に、判定可能な制約は型と受け入れテストに置く。型は壊れたら壊れたと言ってくれる。テストは要件の合格基準そのものを実行可能な形で残してくれる。

詳細な振る舞いはテストに、変わらない骨格は手書きの図に、自動追従する詳細は生成された図に、判定可能な制約は型に。生きた要件の総量は、書いた道具の数ではなく、毎日実行される要件の数で決まる——これが、道具を選ぶ私の今の基準です。多様な道具を持ち込むのは、網羅性のためではなく、それぞれの道具に合った寿命の要件を載せるためだと、最近は思うようになりました。

要件はソフトウェアだけの問題ではない

もう1つ、要件発見が思い出させてくれる視点があります。要件を満たす手段は、ソフトウェアだけではないということです。

私たちはエンジニアなので、要件と聞くと「コードを書く」を反射的に思い浮かべます。でも、業務プロセスの変更、運用ルールの整備、人の配置の変更、紙の業務フォーマットの再設計、これらも要件を満たす手段です。ときには、ソフトウェアを書かないほうが、要件の達成として正解、ということもある。

AIが速くコードを書ける時代になって、この視点は再び重要になりました。「速く書ける」と「書くべき」は別問題です。書かずに済む要件達成があるなら、それを選ぶ判断は、今後も人間に残ります。要件発見の段階でソフトウェア以外の解決策も同列に並べる規律を持つことが、AIに引きずられないための大事な歯止めです。

3つの問いに答え直す

第一部の問いに答えておきます。

要件定義とは何か。ステークホルダーが本当に必要としているものを発見し、検証可能な形で言語化する営みです。誰でも書ける作業ではなく、業務領域への深い理解、言葉を扱う技術、合意形成のスキルを要する専門性のある仕事です。

良い要件・悪い要件とは何か。良い要件は、完全で正確で実現可能、必要で、優先順位がついていて、検証可能です。悪い要件は、このどれかが欠けています。多くの場合、悪い言葉（「ユーザーフレンドリー」「高速」「最善を尽くす」）に依存していて、書き手と読み手で違う絵が見えています。

AI時代に何を変えるか。要件発見の中身は変えません。引き出し方、観察、ジョブ、階層、6つの特性、段階記述、悪い言葉のリスト。これはそのまま使う。変えるのは表現する場所です。ドキュメントだけに置かず、コード・型・テスト・スキーマに分散して焼き込む。ドキュメントは補助。動くものが本体。置き場所を変えるだけで、要件は腐らずに動き続ける。

おわりに

察しの良さは、もう保険にならないのかもしれない。

書かないことが知恵だった時代から、書かないことが事故になる時代へ、少しずつ移ってきた気がします。すべてが移ったとは思いません。それでも、私の現場では、移ってしまった部分のほうが大きい。

AIには察しがありません。書かれていない要件は、AIが世界の平均値で勝手に埋める。それは、私たちのチームの常識とはたぶん一致しない。たまに一致するかもしれませんが、それを期待値に置けるほどの精度ではない、というのが今の私の見方です。

「在庫がある商品だけを検索する」と書かなかった要件文には、無在庫の商品まで返す実装が返ってくる。たった2文字の有無で、3週間が消える。人間のチームでは察しで補われていた2文字が、AI時代には書き漏らせない2文字になる。これが、要件を言葉にすることの重さなのだと思っています。

私が現場で大事にしている姿勢は、新しい技術ではありません。引き出すという姿勢。症状をそのまま要件にしない姿勢。3層に分けて書く規律。6つの特性、悪い言葉のリスト、段階で書く技術。早く見つけるほど安いという経済感覚。ジョブから書く視点。観察の難しさへの謙虚さ。コアドメインへの集中。組織と要件の境界の整合。どれも、要件工学が長く積み重ねてきたものに、私なりの言葉を足しただけです。知識として持っていれば足りるとは思っていません。毎回の現場で確認するものとして使っています。

そして、AIに飲み込まれず生き残るうえで必要なのが、揺らぎと固執だと考えています。揺らぎは、AIの最適解との距離を意図的に確保する判断。固執は、過去の自分との一貫性を貫く判断。揺らぎが個性を作り、固執が信頼を作る。たぶん、その関係は当面崩れません。この2つを要件文として明文化し、コードやテスト、チームの規律に埋め込むのが、AI時代の要件設計の中心的な仕事だと、今のところ思っています。

書く対象は変わりました。コードを書く時間は減り、コードの源泉を書く時間が増えた。要件、構造、規律。これらを書くスキルは、コードを書くスキルと同じくらい、たぶんそれ以上に、これからの差を決める気がしています。

この見立てが、しばらく経った後にも同じ言葉で通用する自信は、正直ありません。AIエージェントの能力が伸びれば、「察しがない」「世界の平均値で埋める」と書いた性質の一部は、姿を変えるはずです。それでも、要件を自分の言葉で言語化する責任は、誰がコードを書く時代でも残るのではないかと思っています。媒体や道具は変わっても、自分が何を作ろうとしているかを、自分で言葉にできること。これだけは、AI時代になっても、その先の時代になっても、ずっと人間に残る規律なのだと思います。

おい、要件を言葉にしろ。コードを書く前に。それも、AIが読める言葉で、しかも自分たちの言葉で。

第2部「おい、要件を動くものにしろ」では、言葉になった要件を実装の現場でどう動くものに変えるかを書きます。仕様駆動開発の整理、AIが書いたコードを信頼できない構造的な理由、要件をシステム全体に分散させる方法、レビューの認知負荷をアーキテクチャで減らす設計について、順番に。