AI時代の要件定義──仕様を書く人から、問いを設計する人へ

「要件定義って、結局は仕様を書くだけでしょ？」
もし今そう思っているなら、AI時代に一番損をするのはその感覚かもしれない。

生成AIが普及して、コードはもちろん、画面案、テスト観点、ドキュメントの叩き台まで一瞬で出せるようになった。
この変化で起きているのは、要件定義の価値が下がったことではない。むしろ逆で、要件定義の「中身」が二極化した。

片方は、仕様を書く人。
もう片方は、問いを設計する人。

そして、AIが強いのは前者だ。文章の整形、要素分解、例示、テンプレ化、網羅性の補助。これらはAIが得意で、人間より速く、疲れず、ブレない。
つまり「仕様を書く」行為そのものは、コモディティ化が進む。

じゃあ人間は何をやるのか。
答えはシンプルで、「何を仕様にするべきか」を決める側に回ること。さらに言うと、その前段にある「何を決めるべきか」を決めること。
ここが「問いの設計」だ。

要件定義の本質は「正解を書くこと」ではない

要件定義という言葉が誤解を生む。
要件を「定める」と書くから、何か確定させる作業に見える。でも実務の現場で起きているのは、確定よりも「未確定の扱い」だ。

• そもそも何が課題なのか、関係者でズレている

• 目的が「手段」にすり替わっている

• 成功の定義が曖昧で、評価ができない

• 制約（予算・期限・体制・法務・運用）が後から出てくる

• 現場の業務は例外だらけで、仕様に落ちない

この状態で仕様を「きれいに書く」ほど危険になる。
なぜなら、仕様が整った瞬間、みんなが「理解した気」になるからだ。
AIでドキュメントが整えば整うほど、この罠は強くなる。

だからAI時代の要件定義は、まず問い直すところから始まる。
「それって本当に決めるべきこと？」
「それって本当に今決めるべきこと？」
「それを決めたら、誰がどう楽になる？」
「決めないまま進んだら、どこで破綻する？」

仕様を書く力より、問いの選球眼の方が価値になる。

仕様を書く人が詰む瞬間

要件定義で詰む典型パターンがある。

1. 依頼をそのまま要件にしてしまう
   「こういう機能が欲しい」が、なぜ欲しいのかに踏み込まない。
   結果、作ったのに使われない。

2. 網羅性＝正しさだと思い込む
   項目が多い＝安心に見える。でも現場は「重要な未確定」が一つ残っているだけで炎上する。
   網羅より、致命点の特定が先。

3. 合意を“議事録”で代替する
   文章があるから合意した、は成立しない。
   合意とは「意思決定」と「責任の所在」がセットで初めて成立する。

AIはこれらの「それっぽい成果物」を大量生産できる。
だからこそ、人間側は成果物ではなく意思決定を扱う役割に上がらないといけない。

問いを設計するとは何か

僕が現場で「問いを設計する」とき、やっているのは次の4つだ。

1. 目的を言い換える（言葉の再定義）

目的が曖昧なまま仕様を書くと、全員が別々の方向に走る。
だからまず、目的を「測れる形」に翻訳する。

例：
「問い合わせ対応を効率化したい」
→「1件あたりの対応時間を平均◯分短縮し、一次対応で解決する割合を◯%にしたい」

この翻訳ができると、必要な要件と不要な要件が切り分けやすくなる。AIにも適切に指示できる。

2. 制約を前に出す（後出しを潰す）

要件定義の炎上は、ほぼ制約の後出しだ。

• 現場はPCを持ち歩けない（スマホ限定）

• 夜間バッチは動かせない

• 個人情報が絡むのでログが取れない

• 既存システムの改修が禁止

• 運用チームの人員が増えない

これを早い段階で「問い」にする。
「今回、絶対に守る制約は何ですか？」
「変えられない前提は何ですか？」
「誰がNOを出す可能性がありますか？」

AIは制約が明確なほど、現実的な案を出せる。逆に制約が曖昧だと、綺麗で使えない案が量産される。

3. リスクを構造化する（未確定を見える化）

問いの設計とは、未確定を放置しないこと。

• 何が分かっていないのか

• どれが致命的なのか

• いつまでに確定すべきなのか

• 誰が決めるのか

これを整理して「意思決定のWBS」を作る。
機能のWBSより先に、意思決定のWBSが必要になる時代だと思っている。

4. 体験を設計する（仕様より「使われ方」）

要件定義で最後に効くのは、機能ではなく「使われ方」。

• その機能は、誰が、どのタイミングで、何のために使うのか

• 使う人は忙しいのか、慎重なのか、ITが得意なのか

• 例外が起きたとき、誰がどこまで判断するのか

• 入力が増えるのか、確認が増えるのか、責任が増えるのか

ここを問いにしていくと、仕様は自然に削れる。
削れる仕様は、だいたい誰も使わないか、運用で破綻するか、責任の押し付け合いになる。

AIを「要件定義の相棒」にする具体例

ここからは実務寄りの話。AIは要件定義の仕事を奪うというより、要件定義の「雑務」を奪う。
奪わせていい。むしろ奪わせないと、人間が問いに集中できない。

例えば僕なら、AIにこういう役割を任せる。

• ヒアリングメモから論点候補を抽出

• 利害関係者ごとの関心事を整理

• 要件の抜け漏れチェックリストを生成

• 仕様テンプレに沿って叩き台を作成

• 変更要求が来たときの影響範囲候補を列挙

• テスト観点・受入基準のたたき台を作る

ただし重要なのは、AIに投げる前に「問い」を渡すこと。
「この仕様を作って」ではなく、
「この目的と制約のもとで、意思決定が必要な論点を列挙して」
「合意形成で揉めそうな点を、反対意見として書いて」
「運用担当が嫌がりそうなポイントを10個出して」
こういう投げ方をする。

AIを使うほど、問いの質がそのまま成果に直結する。
つまり、問いを設計できる人は加速し、できない人は「それっぽい資料」だけが増えて溺れる。

仕様を書く人から、問いを設計する人へ

ここまで読んで、「じゃあ自分はどう変わればいい？」と思ったはず。

僕が勧める最短ルートは、要件定義のアウトプットを変えることじゃない。
要件定義で「最初に書くもの」を変えることだ。

仕様書より先に、次の3つを書いてみてほしい。

1. 目的（測れる言葉で）

2. 制約（変えられない前提を列挙）

3. 未確定リスト（誰がいつ決めるかまで）

これが書けるだけで、会議の質が変わる。議論が「機能の好き嫌い」から「意思決定」に移る。
そしてAIは、その意思決定を支える材料づくりで最大限働けるようになる。

AI時代に価値が残るのは、仕様を書く手の速さではない。
問いを立て、決めるべきことを決め、合意と責任を前に進める力だ。

あなたは今、仕様を書く側にいるだろうか。
それとも、問いを設計する側に移れそうだろうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね！