https://syu-m-5151.hatenablog.com/entry/2025/12/27/140231

——「何を作るべきか」を選び、腹を括ることの価値

この記事の核心：AIがコードを書く時代になっても、「何を作るべきか」を選び、腹を括り、うまくいかなければ別の手を打つのは人間の仕事だ。なぜなら、痛みのない決断は決断ではなく計算だから。本稿では、要件定義を「合意形成」として捉え直し、2025年のAIエージェント元年に人間が担うべき役割を考える。

はじめに

AIがコードを書く時代になりました。「ファイル監視ツールを作って」と指示すると、動くコードが出てきます。それだけではありません。2025年現在、AIエージェントはファイルを読み、テストを実行し、エラーを修正し、プルリクエストまで作成できます。

便利になった分、私たちの仕事は減るのでしょうか。「作る」作業は確かに減ります。しかし「何を作らせるか」「どこで人間が介入するか」を決める仕事は増えます。AIが「作る」を担うからこそ、「選ぶ」の重みが増すのです。

では、どうやって「選ぶ」力を身につければいいのか。

生成AIが登場したからといって、明日から全く新しい働き方ができるわけではありません。人間や組織はそう簡単に変われない。それなら、既存の知見を基盤にして、そこにAIをどう組み込むかを考える方が現実的です。

私自身の失敗談を話します。数年前、私は1週間かけて「完璧な」検索機能を実装しました。クエリのパフォーマンスは最適化済み。インデックスも完璧。リリース当日、私は誇らしげにデプロイボタンを押しました。1ヶ月後、アクセスログを見て愕然としました。検索機能の利用率は、私を含めて全体の10%以下でした。ユーザーが本当に求めていたのは「探す手間を減らすこと」であり、検索機能ではなかった。仕様通りに作った。でも、本当に必要なものを作れていなかったのです。

AIがコード生成を10倍速くしても、要件が間違っていれば、間違ったコードを10倍速く作るだけです。「何を作るべきか」を決める力——これこそが、AI時代に価値を増すものだと私は考えています。

この記事では、IPAの『ユーザのための要件定義ガイド第2版』を参照しながら、要件定義の本質について考えます。古いガイドを持ち出すのは、そこに「人間同士の合意形成」という、AIには代替できない知見が詰まっているからです。

「決める」とは何か。それは、不確実性の中で責任を引き受けることです。正解が分からないまま「これでいく」と宣言し、うまくいかなければ自分で軌道修正する。その覚悟を持つこと。AIにはこれができません。だから、痛みのない決断は、決断ではなく計算なのです。

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

IPAの「ユーザのための要件定義ガイド」

本稿で参照するのは、IPA（独立行政法人情報処理推進機構）が公開している『ユーザのための要件定義ガイド第2版』です。無料でダウンロード可能です。

www.ipa.go.jp

このガイドには「128の勘どころ」として、要件定義を成功に導くための具体的なノウハウが体系化されています。数十年にわたる失敗と成功の蓄積であり、「人間同士の合意形成」という、AIには代替できない知見が詰まっています。

10倍速い失敗を防ぐ防波堤

なぜ今、要件定義なのか

AIの進化により、エンジニアの仕事は「作る人」から「選ぶ人」へとシフトしています。AIは問いを立て、コードを書き、選択肢を提示できます。しかし、AIは「どれを選ぶか」を最後に決めることはできません。決断とは不確実性と責任を引き受ける行為だからです。

そしてAIが「作る」を高速化すればするほど、最初の「選ぶ」の重みは増します。

IPAのガイドによれば、システム開発の失敗理由の50%以上が要件定義の問題にあり、その主因は「要求仕様の決定漏れ」や「開発規模の増大」だといいます。AIがこのスピードを10倍にするとどうなるか。要件が間違っていれば、間違ったシステムを10倍の速さで、10倍の量、生成してしまうのです。

今や要件定義は単なる設計図ではなく、「作らないものを決めるための防波堤」となりました。

「効率化」から「価値創出」へ

ITシステムの役割は、事務効率化から、新たなビジネス価値の創出へと拡大しています。これは要件定義の難易度を根本的に変えます。

効率化が目的なら、要件定義は比較的シンプルでした。ユーザーに「何を自動化したいですか」と聞けばよかった。答えは明確で、私の仕事は書記に近かった。しかし今、ユーザーに「AIで何がしたいですか」と聞くと、返ってくる答えは「何かすごいこと」である。要件定義の難易度は、質問への回答の曖昧さに比例して上がる。

しかし価値創出が目的なら、まだ存在しない業務の要件を定義しなければなりません。「AIを使って何か新しいことをしたい」と言われても、ユーザー自身が何を求めているか分かりません。過去のデータを分析して「こういう傾向があります」とAIが教えてくれても、それをどうビジネスに活かすかを決めるのは人間や組織です。

AIは過去のデータから「これまでの効率化」を計算するのは得意です。しかし、未来の「競争優位性」をどう定義するかという意志は持ち合わせていません。

要件定義とはニーズを「意志」へ変換すること

IPAガイドが示す定義

要件定義とは、単なる「やりたいことリスト」の作成ではありません。私は要件定義を「ステークホルダのニーズを、実現可能な形に変換し、合意を取り付けるプロセス」だと捉えています。IPAのガイドも同様の定義をしています。

ここで重要なのは「変換」という言葉です。ユーザーは「使いやすくしてほしい」と言います。しかし「使いやすい」とは何でしょうか。レスポンスが速いこと、操作が少ないこと、画面がシンプルなこと。この曖昧な言葉を、「検索結果を1秒以内に表示する」「3クリック以内で目的の画面に到達する」といった具体的な要件に変換します。これが要件定義です。

AIは膨大なデータを「計算」して最適な出力を提案できます。しかし「使いやすい」の意味を問い詰め、対立する意見を調整し、合意を取り付けるのは人間固有の作業です。そこには痛みが伴います。

「要求」と「要件」の決定的な違い

私たちは「要求」と「要件」を混同しがちです。しかし、この2つは決定的に異なります。

要求 (Requirement): ステークホルダの心にある「～したい」という生のニーズ
要件 (Specification): 要求を文書化・仕様化し、ステークホルダと合意したもの

決定的な違いは「合意」の有無です。なぜこれが重要なのか。私の経験から言えば、合意のないシステムは必ず「聞いてない」という言葉で殺されます。

ただし、合意があればいいというわけではありません。合意にも濃淡があります。「ハンコを押してもらった」から「腹から納得してもらった」まで。私は合意を3つのレベルで捉えています。

表面的な合意: 会議で「いいですね」と言われた。議事録にも残っている。しかし、実際に使う段になって「こういう意味じゃなかった」と言われる。
理解の合意: 相手が要件の意味を理解している。しかし、それが自分の業務にどう影響するかは考えていない。
コミットメントの合意: 相手が「この要件で自分の仕事が変わる」ことを理解し、その変化を受け入れている。

要件定義で目指すべきは3番目です。1番目の合意は「ハンコを押させた」に過ぎません。2番目は「説明した」に過ぎません。3番目だけが「合意した」と言えます。

AIは1番目の合意を効率化できます。議事録を自動生成し、確認依頼を送り、承認を得る。しかし、相手の腹の中にある「本当はこうしたい」を引き出し、対立する利害を調整し、「これでいく」と握り合うプロセスを経て「要件」へと昇華させることはできません。この「コミットメントの合意」こそが、責任を引き受ける人間だけの領域です。

「今と同じ」という甘えの排除

コミットメントの合意とは、変化を受け入れることです。しかし、人は変化を避けたがる。その典型が「今と同じ」という要件定義です。

「今と同じ」は要件定義ではありません。AIは「現行踏襲」を最も簡単に計算しますが、それはビジネスの進化を止める要件定義の放棄に他なりません。

なぜ人は「今と同じ」を選ぶのか。私の経験では、3つのパターンがあります。

責任回避型: 「今と同じ」と言っておけば、何か問題が起きても「前からそうだった」と言い訳できる。新しいことを提案すると、その責任を負わなければならない。
思考停止型: 「今と同じ」は考えなくていい。現状を分析し、あるべき姿を構想し、そのギャップを埋める——この知的作業を放棄できる。
合意回避型: 新しい要件を定義すると、関係者との合意形成が必要になる。「今と同じ」なら、誰も反対しない（ように見える）。

どのパターンも、本質は同じです。痛みを避けている。しかし、痛みを先送りにしても、痛みは消えません。むしろ、システム稼働後に「使えない」という形で、より大きな痛みとなって返ってきます。

現状（As-Is）からあるべき姿（To-Be）への差分を定義し、変化に伴う痛みを受け入れることこそが要件定義の本質です。

要件定義とは「責任」の契約である

発注者の責任という冷徹な事実

これは冷徹な事実ですが、要件定義は発注者の責任です。

要件定義とは「使える」業務システムを定義することです。動くシステムではなく、使えるシステム。この違いは大きい。私が冒頭で作った検索機能は「動く」システムでした。しかし「使える」システムではなかった。AIがどれだけ「効率的な設計」を提示しても、それが現場の業務を壊したり、利益を生まなかったりしたとき、AIは責任を取れません。

要件定義とは、「このシステムでビジネスを勝たせる」とオーナーが腹を括る行為であり、説明責任（Accountability）を伴う意思決定なのです。

アプリケーションオーナー制度

私が有効だと感じているのは、「アプリケーションオーナー制度」という考え方です。システムをIT部門の「資産」にせず、利益を回収する責任を持つ「ビジネス側」の持ち物とします。

なぜこれが重要なのか。オーナーが不在のプロジェクトで何が起きるか、私は何度も見てきました。

「誰に聞けばいいか分からない」問題: 要件の詳細を詰めようとすると、「それは〇〇部に聞いて」「いや、うちじゃない」とたらい回しにされる。最終決定権者がいない。
「みんなで決めた」問題: 会議で合意したはずの要件が、後から「私は賛成したけど本当は反対だった」と覆される。全員が責任を分散しているので、誰も責任を取らない。
「IT部門が決めて」問題: 業務のことを一番知っているはずの現場の人たちが、技術的な判断をIT部門に丸投げする。IT部門は業務を知らないので、動くが使えないシステムができる。

オーナー制度は、この3つの症状への処方箋です。

オーナーシップ: 「このシステムは自分のもの」という認識を持つ。自分の仕事を具体化するための、自分自身の仕事である。
最終責任: 要件の詳細が固まるまで対話を繰り返し、「これでいく」と言う権限と責任を持つ。

なぜ「痛みを伴う」のか

選択には痛みが伴います。

選択: どの課題を解決し、どの要望を切り捨てるか
妥協: 予算と納期の制約の中で、何を「諦める」か

限られた工期やコストの中で「やらないこと」を決める優先順位付けは、最も苦しい決断です。この痛みを引き受けることこそが、要件定義の本質です。AIがどれだけ効率的にコードを書いても、そのシステムが利益を生まなかったときの「痛み」を肩代わりしてはくれません。

WhyからWhatへ繋ぐリザルトチェーン

要件の階層構造

「Why」を問わずに「What（機能）」をAIに作らせることは、目的地を決めずにアクセルを全開にすることと同じです。

私は要件を3つの階層で捉えるようにしています。IPAのガイドでも同様の分類がなされています。

階層	IPAの定義	問い	内容
Why / Who	利害関係者の要求 (BR)	なぜ、誰のために	利用者が「何を成し遂げたいか」というビジネス目標
What	システム要求 (SR)	何を作るか	目標達成のためにシステムが「どう振る舞うべきか」
How well	ソフトウェア要求 (SRS)	どれだけうまく	プログラムが満たすべき具体的な仕様（機能・性能など）

要件定義とは、この3つのレベルを垂直統合する行為と言えます。

冒頭で触れた私の失敗——「検索機能」を作ったが「探す手間を減らす」ことを理解していなかった——は、まさに利害関係者の要求（Why）を無視して、いきなりシステム要求（What）に飛びついた結果でした。

なぜ人はWhyを飛ばすのか。私なりに分類すると、3つの理由があります。

Whatの方が具体的で安心する: 「検索機能を作る」は明確だ。進捗も測れる。一方「探す手間を減らす」は曖昧だ。何をもって達成とするのか、分かりにくい。人は曖昧さを嫌う。
Whyを問うと「分からない」が露呈する: なぜこの機能は必要か。誰のためか。本当に必要か。この問いに答えられない人は多い。答えられないと恥ずかしいので、問わないことにする。
Whyは政治的に危険: 「なぜこの機能が必要なのか」を突き詰めると、「実は必要ない」という結論に至ることがある。すると、その機能を要望した人の面子を潰すことになる。面倒を避けるために、Whyを問わない。

いずれも、本質は同じです。Whyを問うことは、不確実性と向き合うことです。不確実性は不快です。だから避ける。しかし、避けた不確実性は消えません。プロジェクトの最後に「これじゃない」という形で顕在化します。

リザルトチェーンで因果関係を証明する

私が有効だと感じているのは「リザルトチェーン」という考え方です。獲得したい「最終ビジネス成果（Why）」と、それを実現するための「具体的機能（What）」を鎖のようにつなぎ、因果関係を証明します。

IT施策: 具体的機能（AIが生成するもの）
中間成果: その機能が業務に与える好影響
最終ビジネス成果: 売上向上、コスト削減などの経営目標

このチェーンを設計し、その妥当性に判をつくことこそが要件定義の核心です。AIが生成した機能リストの先に、どのようなビジネス上の「果実」があるのかを論理的に証明するのは、人間に残された高度な知能活動です。

開発コストの大半は「手戻り」に消えている

ソフトウェア要求工学の古典『Software Requirements 3』によれば、開発における手戻りはコスト全体の30〜50%を消費します。そのうち70〜85%が要件の間違いに起因するといいます（Karl Wiegers & Joy Beatty, 2013）。

つまり、開発チームが残業している夜の大半は、「最初に何を作るか間違えた」ことへの贖罪なのです。AIはこの贖罪の時間を短くしてくれません。間違いをより速く積み上げるだけです。

AIにできること、できないこと

2025年のAIは、多くのことができます。まずその能力を正確に把握しておくことが重要です。過小評価すれば使いこなせず、過大評価すれば失敗します。

AIは問いを立てることもできる

AIは問いを立てられます。

「このプロジェクトで考慮すべき観点は何か」と聞けば、AIは網羅的なリストを返してくれます。ユーザー体験、セキュリティ、スケーラビリティ、コスト、保守性——私が思いつかなかった観点まで提示してくれることもあります。

問いを立てる能力において、AIはすでに人間を補完できるレベルに達しています。

要件定義の各フェーズでAIを活用する

では、具体的にどう活用するか。私が実践している方法を紹介します。

フェーズ1：要求の洗い出し

ステークホルダへのヒアリング前に、AIに「このプロジェクトで聞くべき質問リスト」を生成させます。「ECサイトのリニューアルプロジェクトで、業務部門に確認すべき観点を20個挙げて」と指示すると、私が見落としていた観点が出てくることがあります。

ヒアリング後には、議事録をAIに読ませ、「この議事録から抽出できる要求を一覧化して」と指示します。人間が手作業で整理するより速く、抜け漏れも減ります。

フェーズ2：要件の具体化

曖昧な要求を具体的な要件に変換する作業でも、AIは役立ちます。「『使いやすいシステム』という要求を、測定可能な要件に分解して」と指示すると、「レスポンス時間」「操作ステップ数」「エラー率」といった具体的な指標に落とし込んでくれます。

しかし、ここで出てきた指標が「このプロジェクトにとって適切か」を判断するのは人間です。AIが提案した「レスポンス時間1秒以内」が、本当にこのシステムに必要かどうか。それはビジネスの文脈を理解している人間が決めます。

フェーズ3：影響分析

「この要件を実装した場合、既存システムにどんな影響があるか」という分析も、AIに補助させられます。システム構成図やデータフロー図をAIに読ませ、「この変更による影響範囲を洗い出して」と指示する。網羅性の担保にAIを使い、最終的な判断は人間が行います。

フェーズ4：ドキュメント生成

要件定義書のドラフト作成は、AIが得意な領域です。「以下の要件リストを、IPAのガイドラインに沿った形式でドキュメント化して」と指示すれば、体裁の整った文書が出てきます。人間は、その内容の正確性と、ステークホルダに伝わる表現かどうかをレビューします。

しかしAIは「選べない」

問題は、その先です。

AIは10個の選択肢を提示できます。それぞれのメリット・デメリットを分析できます。トレードオフを可視化できます。しかし、「どれを選ぶか」を決めることはできません。

「パフォーマンスを優先すべきか、開発速度を優先すべきか」——AIはこの問いに対して、両方の観点から分析を提供してくれます。しかし「我々はパフォーマンスを選ぶ」と宣言できません。

なぜか。AIは責任を引き受けられないからです。

「何でも作れる時代」に、なぜ私たちは作れないのか。その問いと向き合った記事を書いています。

syu-m-5151.hatenablog.com

腹を括るとは何か

では、「責任を引き受ける」とは具体的にどういうことでしょうか。私はこれを「腹を括る」という言葉で捉えています。

「腹を括る」とは、不完全な情報の中で、それでも決断を下すことです。

すべての情報が揃うことはありません。すべてのリスクを排除できません。それでも、「我々はこれでいく」と決める。その決断には、必ず「もし間違っていたら」という不安がつきまといます。

AIにはこの不安がありません。午前3時に目が覚めて「あの選択は本当に正しかったのか」と天井を見つめることもない。胃が痛くなることもない。だから、決断できません。決断とは、胃を痛めることの引き受けなのかもしれません。

AIは確率を計算できます（厳密には「計算」ではなくパターン認識ですが、ここでは便宜上こう呼びます）。リスクを列挙できます。しかし、「このリスクを取る」と決断できません。決断とは、不確実性を引き受けることであり、責任を引き受けることだからです。

「腹を括った」と言える条件

では、腹を括ったと言える判断には、どんな条件が必要でしょうか。私なりに整理してみます。

第一に、代替案を知っていること。「これしかない」と思い込んでいる状態は、腹を括ったとは言えません。A案、B案、C案があり、それぞれのリスクとリターンを理解した上で「A案でいく」と決める。選択肢を知らずに選んだものは、選択ではありません。

第二に、失敗したときのシナリオを想定していること。「これでうまくいく」と楽観しているだけでは、腹を括ったとは言えません。「もし失敗したら、こうなる」「そのとき、こう対応する」という覚悟があるかどうか。最悪のケースを直視した上で、それでも進む決断が「腹を括る」です。

第三に、自分の名前で決めること。「みんなで決めた」「上が言ったから」という言い方ができる決断は、腹を括っていません。「私が決めた。責任は私にある」と言えるかどうか。決定権者が明確であること。

エンジニアとしてプロジェクトに参加するとき、私は自分に問いかけます。「この技術選定は、自分の名前で決めたか」「このアーキテクチャは、自分の名前で提案したか」。アーキテクトは技術的な意思決定者です。「チームで検討した結果」という言い方をしがちですが、最後に「私がこの設計を推奨する」と言えるかどうか。それが腹を括るということです。

うまくいかないときに次の手を打つ

AIが生成したコードにバグがあったとき、どうするか。

エンジニアなら答えは明確です。原因を調べて、修正して、再デプロイする。うまくいかなければ別のアプローチを試す。それでもダメなら、いったん切り戻して仕切り直す。この「次の手を打つ」判断は、今のところ人間がやるしかありません。

選択の本質は、うまくいかなかったときに次の手を打つことにあります。AIが選択しても、その後の軌道修正——関係者との再調整、代替案の実行、撤退の判断——をするのは、今のところ人間しかいません。

合意形成と対立する「正しさ」の調整

なぜ合意が難しいのか

合意形成が難しいのは、なぜでしょうか。

単純に「意見が違う」だけではありません。もっと根深い問題があります。それは、関係者がそれぞれ異なるナラティブ（物語）——世界を解釈するための枠組み——を生きていることです。経営者は「コスト削減こそ正義」という物語を生きている。エンジニアは「技術的負債は悪」という物語を生きている。現場は「今の仕事を楽にしたい」という物語を生きている。三者が同じ会議室に座っているが、実は三つの異なる言語を話しています。

どれも正しい。どれも間違っていません。だが、同時に全てを満たすことはできません。

問題は、人は自分のナラティブの外に出られないことです。経営者から見れば、エンジニアは「コストを無視した理想論者」に見えます。エンジニアから見れば、経営者は「技術負債を無視した短期思考」に見えます。お互いが、相手を「間違っている」と感じている。

しかし実際には、どちらも間違っていません。違う物語を生きているだけです。これを認めることが、合意形成の第一歩になります。

では、どうすれば認められるのか。私の経験では、「こう言えばうまくいく」という魔法の言葉はありません。テクニックの問題ではないのです。大切なのは、相手の物語を理解しようとする姿勢で議論を続けること。その姿勢を持ち続けることでしか、ナラティブの壁は越えられません。

私自身、エンジニアとしてこれを学びました。技術的に正しいことと、プロジェクトにとって正しいことは、同じではありません。たとえば「マイクロサービス化すべきだ」という技術的に正しい主張が、今のチームのスキルや予算を考えると現実的ではないことがあります。相手の立場——チームの現状、予算の制約、経営の優先順位——を理解しようとして初めて、現実的な落とし所が見えてきます。アーキテクトの仕事は、技術的な正しさを追求することではなく、プロジェクトの文脈の中で最適解を見つけることです。

主観を可視化する

ナラティブの衝突を解消するには、まず「見える化」が必要です。言葉で議論していると、同じ言葉に違う意味を込めていることに気づきません。

私がよく使うのは、ホワイトボードに関係者の立場と関心事を図示する方法です。IPAのガイドでは「リッチピクチャ」と呼んでいます。言葉では表現しづらい関係性を一枚の絵で表現し、「あなたはこう見えているんですね」と確認する。これだけで誤解が減ります。

合意形成を加速させるテクニック

私の経験で有効だったテクニックをいくつか挙げます。IPAのガイドでも同様の手法が推奨されています。

当事者意識（オーナーシップ）の醸成

単なるヒアリングではなく、ワークショップなどを通じて関係者が議論し、相互理解を深めるプロセスを持ちます。自分たちが決めたという意識がなければ、稼働後の不満につながります。

相手の視点に合わせた資料の準備

成果物をそのまま見せるのではなく、説明相手の関心事に合わせた資料を用意します。

経営層向け: 「ビフォーアフター図（B/A図）」を用い、何が変わって何が良くなるのか、投資対効果を端的に伝える
現場のリーダー向け: 新しい業務プロセスがどうなるか、業務フローを用いて具体的な変化を説明する

「声の大きい人」のコントロール

特定の意見に流されないよう、客観的な評価指標（優先順位の基準）を盾にし、ファシリテーターが議論を統制します。

エスカレーションパスの確立

現場で合意できない対立については、上位層による意思決定機関（ステアリングコミッティ）へ迅速にエスカレーションし、プロジェクトを停滞させない仕組みを事前に作っておきます。

合意形成でAIを活用する

合意形成という人間臭い作業でも、AIは補助的な役割を果たせます。

相手の立場を理解するための困難打ち。会議の前に、AIに「経営者の視点から、このシステム投資をどう評価するか」と聞いてみます。自分とは違うナラティブを疑似体験できます。「この提案を受けた営業部長は、どんな懸念を持つか」とAIに聞くことで、想定問答を準備できます。

議論の整理と論点の抽出。会議が紛糾したとき、議事録をAIに読ませて「この議論の論点を整理して」と指示すると、感情的になっている参加者には見えなくなった構造が見えてきます。「経営層はコストを重視、現場は使いやすさを重視、エンジニアは保守性を重視」という対立構造を可視化できます。

説明資料の自動生成。相手に合わせた資料の準備にも、AIは使えます。「この技術仕様を、経営層向けにROIの観点で説明する資料に変換して」と指示すれば、一次ドラフトが生成されます。ゼロから書くより効率的です。

合意の言語化。合意に至ったとき、その内容を正確に文書化することにもAIは役立ちます。「この会議で合意された内容を、後から『言った言わない』にならないように文書化して」と指示すれば、曖昧さを排除した合意文書のドラフトが得られます。

しかし、AIが補助できるのは合意形成の準備と記録です。相手の感情を読み取り、対立を調整し、「これでいきましょう」と握り合うプロセス自体は、人間同士の対話でしかできません。AIは通訳であり、ファシリテーターではありません。

対話の本質と、対話を阻む構造的な問題については、以下の記事でより詳しく論じています。

syu-m-5151.hatenablog.com

優先順位付けという最もクリエイティブな「棄却」

「全部やる」の誘惑

「全部やる」と言った瞬間、会議室は平和になります。誰も傷つかない。誰も責められない。しかし3ヶ月後、プロジェクトは炎上する。「全部やる」は、将来の自分への借金です。利子は複利で増えます。

問題は個人の心理だけではありません。組織の構造が、選択を妨げていることがあります。

まず、インセンティブの問題があります。営業部長は営業の数字で評価される。開発部長は開発の成果で評価される。全社最適より部門最適が優先される構造になっています。

次に、権限の曖昧さがあります。誰が「やらない」と決める権限を持っているのか。多くの組織で、これが不明確です。だから、誰も決めない。決めなければ、責任を問われません。

「全部やる」は、個人の弱さであると同時に、構造の帰結でもあります。

客観的な6つの判断基準

AIはあらゆる可能性を提示しますが、リソース（工期・コスト・人）は有限です。何かを選ぶことは、何かを諦めること。この優先順位付けこそが、最もクリエイティブで苦しい決断の場です。

優先順位を「なんとなく」で決めると、声の大きい人の意見が通ってしまいます。私は以下の6つの指標で多角的に評価するようにしています。IPAのガイドでも同様の基準が示されています。

有効性: 目的や目標にどれだけ貢献するか（達成効果）
必要性: 法制度対応、内部統制、社会的責任などの観点で不可欠か
緊急性: 期限が明確で、急を要するか
費用: 実現や運用にどれだけのコストがかかるか
実現性: 技術的・人的に本当に実現可能か
新たな問題: その要求を実現することで、別の問題が発生しないか

MoSCoW分析という「捨てる」ための枠組み

すべてを「必須」とせず、MoSCoW分析を用いて、勇気を持って「要求を捨てる」ことが必要です。

M (Must): これがないと目的を達成できない必須の要求
S (Should): 必須ではないが、重要な推奨要求
C (Could): あれば良いレベルの要求
W (Won't): 今回は見送る、または不要な要求

柔軟で変化に強いシステムを作るには、要求を抑え込み、シンプルでスリムな状態を維持する「捨てる勇気」が必要です。AIが「What（何を作るか）」の選択肢を無限に生成するからこそ、人間はこの枠組みを駆使して価値あるものだけを選ぶ必要があります。

優先順位付けでAIを活用する

ここでもAIは強力な補助ツールになります。

比較分析の自動化。100個の要求がリストアップされたとき、それぞれを6つの指標で評価するのは膨大な作業です。AIに「この要求リストを、有効性・必要性・緊急性・費用・実現性・新たな問題の6軸で評価して」と指示すれば、一次評価を自動化できます。

トレードオフの可視化。「要求Aを優先すると、要求Bにどんな影響があるか」という依存関係の分析も、AIに補助させられます。複雑に絡み合った要求間の関係を整理し、「これを選ぶと、あれが犠牲になる」という構造を可視化できます。

過去事例の参照。類似プロジェクトでどんな優先順位付けがなされたか。過去の要件定義書をAIへ渡し、傾向を分析させることもできます。「過去5年間のプロジェクトで、結局Won't判定となった要求の特徴は何か」といった分析が可能です。

しかし、最終的な優先順位を決めるのは人間です。AIは「この要求は有効性が高い」と分析できます。だが「有効性が高いから採用する」とは決断できません。有効性が高くても、今のチームには実現できない。費用が低くても、ビジネス的な価値がない。こうした判断は、プロジェクトの文脈を理解している人間にしかできません。

「何をやらないか」を決めることの本質と、戦略的思考については、以下の記事でより詳しく論じています。

syu-m-5151.hatenablog.com

検証と妥当性確認という「正しさ」を問う2つの視点

要件を選び、優先順位を付けた。では、その選択は正しかったのか。要件定義には、選んだ後に「正しさ」を確認する作業があります。ここで重要なのは、「正しさ」には2つの意味があるということです。

Verification と Validation

AI時代のエンジニアの価値は、計算機的な「検証（Verification）」から、人間的な「妥当性確認（Validation）」へと移っています。

検証 (Verification): 記述された要件が、要求を抜け漏れなく満たしているかという「計算的」チェック。これはAIでも補助可能である。
妥当性確認 (Validation): その要求自体が、本当にビジネス目的を達成できるものかという「意志」の確認。

後者は「納得」という感情の着地点を見つける泥臭い人間活動（合意形成）であり、これが欠けた要件定義は、2025年においても失敗を運命づけられています。

AIは「正しく作る」ことを補助できます。しかし「正しいものを作っているか」を問い続けるのは人間の仕事です。

検証フェーズでAIを活用する

Verification（検証）は、AIが最も力を発揮できる領域です。

要件の整合性チェック。「この要件定義書の中で、矛盾している記述はないか」とAIに分析させます。「画面Aでは『即時反映』と書いてあるが、画面Bでは『バッチ処理』と書いてある。これは矛盾ではないか」といった指摘が得られます。人間の目では見落としがちな不整合を、AIは網羅的にチェックできます。

抜け漏れの検出。「この要件定義書で、考慮されていない観点はないか」とAIに問いかけます。「エラー時の挙動が定義されていない」「権限管理について記述がない」といった抜け漏れを指摘してくれます。

テストケースの自動生成。「この要件から、テストケースを生成して」と指示すれば、要件を満たしているかどうかを確認するためのテストシナリオが自動生成されます。

一方で、Validation（妥当性確認）は人間の仕事です。「この要件が本当にビジネス目的を達成できるか」は、ビジネスの文脈を理解している人間にしか判断できません。AIは「要件が論理的に整合している」ことは確認できますが、「この要件でユーザーが幸せになるか」は判断できません。

非機能要求と経営リスクを引き受ける覚悟

性能、セキュリティ、可用性といった「非機能要求」は、もはやエンジニアのこだわりではなく、経営そのものです。

IPAの「非機能要求グレード」を活用し、可用性、セキュリティ、運用・保守性などの各項目について、ビジネスの特性に合わせた「レベル」を決定します。

可用性: 「24時間365日止まらない」という要求には膨大なコストがかかる
セキュリティ: 利便性を損なう可能性があっても守るべき情報の範囲を合意する

AIは「コストとリスクのバランス表」を出すことはできます。しかし、万が一の事態に「私が責任を取る」と宣言し、トレードオフに決着をつけることはできません。

システムの事情を人間に寄せる

ここまで、要件定義の「決める」「合意する」「選ぶ」という側面について書いてきました。ここからは、もう1つの重要な側面——伝える——について書きます。

エンジニアの本当の仕事

私は長い間、エンジニアの仕事は「技術的に優れたシステムを作ること」だと思っていました。パフォーマンスを最適化し、スケーラブルに設計し、セキュリティを担保する。それが専門家としての価値だと。

しかし今は違う考えを持っています。

エンジニアの本当の仕事は、システムの事情を人間に寄せることです。

システムには事情があります。データベースには制約がある。ネットワークには遅延がある。メモリには限界がある。これらの「システムの都合」をそのままユーザーに押し付けると、使いにくいシステムができあがります。

「処理中はお待ちください」という画面を見せるのは簡単です。しかし、バックグラウンドで処理を行い、完了したら通知するという設計にすれば、ユーザーは待たなくていい。

もう少し例を挙げます。

「入力エラーです」→「電話番号は090-1234-5678の形式で入力してください」
「データがありません」→「〇〇で検索してみてください」または「似たデータはこちら」
「権限がありません」→「管理者の〇〇さんに申請してください」（申請リンク付き）

パターンは同じです。エラーの原因を伝えるのではなく、次のアクションを伝える。これが「システムの事情を人間に寄せる」ということです。

AIがこの橋渡しを加速する

ここに生成AIが加わることで、「システムの事情を人間に寄せる」作業は劇的に変わります。

エラーメッセージの設計を例に考えます。従来、エンジニアは「このエラーが出たら、どう説明するか」を一つひとつ考えていました。しかし今は、「このエラーコードのリストを、エンドユーザー向けの説明文へ変換して」とAIに指示できます。数百のエラーメッセージを、一貫したトーンで、人間に寄せた表現へ変換できるのです。

ドキュメント生成も同様です。APIの仕様書をAIへ渡し、「エンジニアではない人が読んでも分かる説明を書いて」と指示する。技術的な正確さを保ちつつ、ビジネス側に伝わる表現へ変換できます。

アーキテクトとしての視点から言えば、AIは「翻訳作業の自動化」を可能にします。システムの事情を人間に寄せる作業は、これまで経験と勘に頼っていました。しかし今は、AIにパターンを学習させ、大量の翻訳を一貫した品質で行えます。

しかし、注意が必要です。AIが生成した「人間に寄せた表現」が、本当にユーザーに伝わるかは別問題です。AIは「分かりやすそうな文章」を生成できますが、ユーザーが実際に理解するかは検証しなければ分かりません。エンジニアの仕事は、AIが生成した翻訳を検証し、改善のサイクルを回すことに移行します。

要件定義はその橋渡し

要件定義は、ビジネスの世界とシステムの世界を橋渡しする行為です——と言うのは簡単です。問題は、同じ言葉でも意味が違うことにあります。

例えば「リアルタイム」という言葉。エンジニアが「リアルタイム」と聞くと、脳内では即座にWebSocketの設計が始まる。ポーリング間隔は100ミリ秒か、いや50ミリ秒か。一方、ビジネス側の「リアルタイム」とは何か。聞いてみると「1分以内」だったりする。エンジニアは100ミリ秒の世界で戦っていたが、相手は60秒の世界にいた。600倍のズレです。この認識の溝を埋めないまま開発を進めると、3ヶ月後に「なんでこんなに重いんですか」と言われる。過剰品質もまた罪なのです。

橋渡しとは、この言葉の翻訳作業のことです。「リアルタイムとは、具体的にどのくらいの頻度で更新されればいいですか」と聞く。「1時間に1回で十分」と返ってくるでしょう。その瞬間、要件の解像度が上がります。

「技術的にはできません」で終わらせるのは簡単です。しかし、「技術的には難しいですが、こういう代替案ならできます」と提案できるかどうか。それがプロフェッショナルとアマチュアの違いです。

「要件定義」という言葉のズレ

業界・組織によって指す行為が違う

ここで立ち止まりたいです。あなたの職場での「要件定義」と、私が語っている「要件定義」は、同じものでしょうか。

正直に告白すると、この言葉ほど組織や文脈によって意味が異なるものはありません。

SIerでは、要件定義は「顧客の要望を文書化すること」を指すことが多いです。RFP（提案依頼書）を受け取り、要件定義書を作成し、顧客の承認を得る。

事業会社では、要件定義は「何を作るかを決めること」を指すことが多いです。文書化より意思決定が重視されます。

スタートアップでは、要件定義という言葉自体はあまり使われません。「仮説を立てて検証する」「ユーザーの声を聞いて方向転換する」——こうした活動は要件定義に相当しますが、そう呼ばれることは少ないです。

ズレを防ぐために

1つのアプローチは、最初に「要件定義」の意味を擦り合わせることです。プロジェクトの冒頭で、「このプロジェクトにおいて要件定義とは何を指すか」を明示的に合意する。面倒ですが、後のズレを防げます。

私がこの記事で「要件定義とは合意形成であり、責任の引き受けである」と定義したのも、そうした擦り合わせの試みです。

生成AI時代にエンジニアはどう向き合うか

生成AIの登場によって、「要件定義」という言葉のズレはより複雑になります。

「AIに要件定義させる」という幻想。クライアントから「AIに要件定義させればいいのでは」と言われることが増えました。しかし、ここには根本的な誤解があります。AIは「要件をドキュメント化すること」はできます。だが「要件を決めること」はできません。なぜなら、要件を決めるとは責任を引き受けることだからです。

エンジニアとして、私はこの問いにこう答えます。「AIは要件定義の作業を効率化します。しかし要件定義の本質——選択と責任——は人間のままです」と。

アーキテクトの新しい役割。生成AI時代のアーキテクトには、新しい役割が生まれています。それは「AIとの協働プロセスを設計する」ことです。どの作業をAIに任せ、どの判断を人間が行うか。この分界点を設計することが、アーキテクトの仕事に加わりました。

例えば、以下のような判断が必要になります。

AIに任せるべきこと: 要件の文書化、過去事例の調査、影響範囲の分析、選択肢の列挙
人間が判断すべきこと: 対立する要件の優先順位付け、ステークホルダとの合意形成、「これでいく」という最終決定

組織によって「AI活用」の意味も違う。SIerでは「AIで提案書の品質を上げる」だろう。事業会社では「AIでプロトタイプを高速に作り、検証する」だろう。スタートアップでは「AIで仮説検証のサイクルを速める」だろう。

要件定義という言葉のズレと同様に、「AIを活用する」という言葉もズレます。だからこそ、プロジェクトの冒頭で「このプロジェクトにおいてAIをどう使うか」も明示的に合意すべきです。

腹を括って成功した経験

ここまで抽象的な話が続いたので、具体的な経験を1つ書きます。冒頭で「検索機能を作ったが使われなかった」失敗を書きました。今度は、逆のケースです。

あるプロジェクトで、私たちは「検索機能を作らない」という判断をしました。クライアントは検索機能を強く要望していました。競合製品にはすべて検索機能がある。チーム内にも「作るべきだ」という声がありました。

しかし私は、ユーザーインタビューの結果を見て、違う結論に達しました。ユーザーが本当に困っていたのは「探す」ことではなく、「何を探せばいいか分からない」ことでした。検索機能を作っても、検索ワードが浮かばないユーザーには役に立ちません。

私は「検索機能は作らない。代わりに、よく使う項目を自動で上位に表示する仕組みを作る」と提案しました。クライアントとチームから、大きな反対はありませんでした。「もし改善しなかったら、そのときに検索機能を作りましょう」という落とし所で合意しました。

結果は成功でした。リリース後、ユーザーからの問い合わせが激減しました。「欲しい情報がすぐ見つかる」という評価を得ました。

振り返ると、この判断には先ほど挙げた3つの条件がすべて揃っていました。代替案（検索機能を作る）を知っていた。失敗したときのシナリオ（クライアントからのクレーム、追加開発のコスト）を想定していた。そして、自分の名前で決めた。

腹を括れば、成功と失敗の両方から学べます。腹を括らなければ、どちらの結果からも何も得られません。

おわりに

この記事では、AI時代の要件定義について考えてきました。

2025年現在、AIの能力は驚くほど高くなりました。コードを書くだけでなく、要件の分析・矛盾の指摘・テストケース生成・ドキュメント作成まで行えます。AIエージェントは自律的にタスクを実行し、エラーがあれば自分で修正します。

それでも、要件定義の本質は変わりません。ステークホルダのニーズを実現可能な形に変換し、合意を取り付けるプロセス。対立するナラティブを調整し、「これでいく」と腹を括る行為。うまくいかなければ次の手を打つ覚悟。これは、人間同士の営みであり続けます。

変わるのは、道具です。AIは問いを立てられます。選択肢を提示できます。分析もできます。リスクを列挙できます。これらを使いこなせば、要件定義の質は上がります。しかし、最後に「これでいく」と決めるのは人間です。責任を引き受けるのも人間です。

「AIに最適化された要件定義」を一から発明する必要はありません。IPAのガイドに体系化された「128の勘どころ」は、数十年にわたる失敗と成功の蓄積です。この基盤の上に、AIという新しい道具を載せていく。それが現実的なアプローチだと私は考えています。

冒頭で触れた「仕様通りに作ったが使われなかった」システム。あのとき私に足りなかったのは、技術力ではありませんでした。「なぜこれを作るのか」を問う力。「これでいく」と決める覚悟。うまくいかなければ別の手を打つ姿勢。そういうものでした。

痛みのない決断は、決断ではなく計算です。

AIは計算が得意です。しかし、決断はできません。決断とは、不確実性を引き受けることであり、責任を引き受けることだからです。

エンジニアとして、アーキテクトとして、私たちはこの時代にどう立ち向かうべきでしょうか。私の答えはシンプルです。AIを使いこなしながら、決断する力を磨く。AIに任せられる作業は任せる。しかし、最後に「これでいく」と決めるのは自分です。技術選定、アーキテクチャ設計、トレードオフの判断——これらの決断を、自分の名前で行う。うまくいかなければ、次の手を打つ。この姿勢は、AIが進化しても変わりません。

この10年間、私はコードを書くことに時間を使ってきました。そのうちどれだけが「贖罪」だったかは、あまり考えたくありません。これからの10年は、「何を作るべきか」を選ぶことに時間を使いたい。選んで、合意を取り付けて、責任を引き受けて、うまくいかなければ次の手を打つ。その繰り返しに時間を使いたいと思っています。