上流に行きたいのに行けない人へ──要件定義ができない“本当の理由”

「要件定義ができるようになれば、上流に行ける」

そう思って勉強もしているのに、実務になると手が止まる。
会議では議事録は取れる。WBSも引ける。仕様書も読める。

でも“要件”になると、言葉が曖昧になってしまう。

今日は、その詰まり方の正体を、
できるだけ痛みの少ない形で言語化してみる。

結論から言うと、要件定義ができない理由は「書き方を知らないから」ではない。多くの場合、要件を「定義する立場」に立つ覚悟と構造が揃っていないからだ。

スキル不足というより、前提の不足に近い。

要件定義ができない人が、無意識に抱えている5つの前提ズレ

1) 「要件＝機能」だと思っている

要件定義で最初に崩れるのはここだ。
機能は「手段」で、要件は「目的の条件」に近い。

たとえば「承認フローを3段にしたい」は機能っぽい。
でも要件は本来、「誰が・何を・どの基準で・どんな責任で承認する必要があるか」という意思決定のルールだ。フロー段数は、その結果にすぎない。

僕が現場でよく見るのは、機能を集めるほど要求が膨らみ、最後に「で、何のためだっけ？」が消えるパターン。これは能力というより、視点の置き場所の問題だ。

2) 「正解の仕様」を当てに行っている

要件定義はクイズじゃない。
でも多くの人が、無意識に「相手の頭の中にある正解を当てるゲーム」になっている。

だから、言質を取りたくなる。だから、会議で「決めてくれ」待ちになる。
要件定義の本質は、不確実な状況で、合意可能な仮説を立て、検証可能な形に落とすことだ。正解探しをしている限り、要件はいつまでも霧の中に残る。

3) 「業務理解が足りない」と思い込み、聞けなくなる

上流に行けない人ほど、「業務を知らない自分が口を出すのは怖い」と感じている。これが沈黙を生む。沈黙は観察不足を生む。観察不足はますます業務理解を遅らせる。悪循環だ。

でも要件定義で必要なのは、業務の「丸暗記」じゃない。
必要なのは、業務を分解して質問できる構造だ。

• その作業は「何の判断」を生むのか

• 判断の前提データは何か（誰が作り、どこで変わるのか）

• 例外は何があるのか（頻度はどれくらいか）

• その判断が間違うと、誰が困るのか（損失は何か）

この質問ができれば、業務知識は会話の中で増えていく。逆に言えば、質問の構造がないと、いつまでも「もっと勉強してから…」で止まり続ける。

4) 「関係者の利害」を扱うのが怖い

要件定義は、技術作業ではなく政治作業だ。ここから目を逸らすと一気に崩れる。
関係者は同じ言葉を使っていても、欲しいものが違う。

• 現場は「手戻りを減らしたい」

• 管理は「統制したい」

• 経営は「リスクとコストを抑えたい」

• 情シスは「運用負荷を増やしたくない」

• 監査は「説明責任を果たしたい」

要件定義ができない人は、衝突を避けるために「全員がYESと言う曖昧さ」に逃げやすい。
でも曖昧さは、後工程で必ず爆発する。要件定義の仕事は、衝突を無くすことじゃない。衝突を、合意できる形に変換することだ。

5) 「要件＝ドキュメント作成」になっている

これは罠として強い。
要件定義は資料を作る工程ではなく、意思決定を成立させる工程だ。

要件定義の成果物は、WordやExcelの前にまず「決めたこと」と「決めてないこと」を誰でも追える状態。
資料がきれいでも、決まっていないなら要件定義は終わっていない。逆に、資料が粗くても意思決定が揃っていれば前に進める。

「要件定義ができる人」が持っている3つの型

型1：Why→What→How を、順番を崩さない

会話が荒れるとき、ほぼ確実に How（実装や機能）から入っている。
要件定義で最初に固定すべきはWhy（目的）とWhat（満たす条件）だ。

• Why：何のために変えるのか（業務・統制・収益・リスク）

• What：何が満たされれば成功か（判断・責任・品質・速度）

• How：それをどう実現するか（機能・画面・運用）

上流に行けない人は、技術者として誠実だからこそHowから入る。だが要件定義では、その誠実さが裏目に出ることがある。

型2：論点を「決める箱」に分ける

要件定義を難しくしているのは、論点が混ざることだ。僕は最低でも次の箱に分ける。

• スコープ（どこまでやる/やらない）

• 業務ルール（判断基準・責任・例外）

• データ（定義・粒度・発生源・更新点）

• 画面/帳票（入力/出力の目的）

• 非機能（性能・権限・監査・可用性）

• 運用（誰が何をいつやるか、障害時どうするか）

箱があれば、会議で迷子にならない。迷子にならないと、合意形成が前に進む。

型3：「合意」を設計する

要件定義ができる人は、会議のゴールを“議論”ではなく「合意」に置いている。
そのために、次を明示する。

• 今日決めること（Decision）

• 今日決めないこと（Parking）

• 不明点（Issue）と調査担当（Owner）

• 次回までの宿題（Action）と期限（Due）

これを運用できるだけで、要件定義は劇的に前に進む。上流に行けない人は、実はここが一番効く。

じゃあ、明日から何を変えるか（最小の一歩）

いきなり要件定義を“完璧に”しようとすると折れる。だから僕は、まず次の3つだけを徹底するのが現実的だと思っている。

1. どの議題でも「それはWhy/What/Howのどれですか？」を自分の中でラベル付けする

2. 1つの会議で「決める箱」を1つに絞る（今日はデータ定義だけ、など）

3. 会議の最後に「決めたこと/決めてないこと/次の宿題」を口頭で復唱する

これだけで、周りからの見え方が変わる。
“要件が書ける人”ではなく、要件が決まるように場を動かせる人に近づくからだ。

最後に：上流は「肩書」ではなく「責任の引き受け」

要件定義ができない「本当の理由」は、多くの場合、能力不足ではない。
要件定義は、誰かの期待を裏切る可能性を含んだ意思決定を扱う。そこには怖さがある。僕もそうだった。

でも、上流に行くというのは、その怖さをゼロにすることじゃない。
怖さがあるままでも、論点を分け、合意を設計し、意思決定を進めることだ。

要件定義ができるようになると、技術の幅が広がる以上に、仕事の主導権が変わる。

「作る人」から「決める人」へ。

その入口は、案外、派手な知識ではなく「構造」と「合意」の
運用だったりする。

次に読む：

はじめての方へ：

マガジンの紹介：

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