「要件定義書、ひと通り目を通しておいて」。新人にそう渡したのに、いざ設計レビューで質問してみると、書いてある単語をなぞるだけで、何が決まっていて何が決まっていないのか答えられない。曖昧な要件をそのまま実装に持ち込み、後工程で手戻りが発生する。受託開発の現場で、こうした場面に心当たりのあるリーダー・PMは多いはずです。
問題は新人本人の理解力ではなく、「要件定義書をどう読めばよいか」の型を渡していないことにあります。要件定義書は読み物ではなく、判断のための文書です。読み手側にも「何を確認するために読むか」という視点が必要で、その視点は経験で身につくものではなく、指導で渡すものです。
本記事では、新人に要件定義書を読み解かせるための「目的・範囲・前提・曖昧点」の4視点と、段階的に身につけさせるための練習フローを、受託開発の現場で使える形で整理します。
新人が「読めない」とはどういう状態か
まず、新人の「要件定義書が読めない」という症状を分解しておきます。指導を効果的に行うには、まず症状を細かく把握することが大切だからです。
現場でよく見るのは、次の3つの状態です。
- 表面読み：書いてある単語や見出しは追えるが、何が決まり事で何が課題かを区別できない
- 質問できない：違和感はあるのに、それが「自分の理解不足」なのか「要件側の曖昧さ」なのか切り分けられず、結果として黙ってしまう
- 当たり前読み：「普通こうでしょう」という自分の前提で空白を埋めて読み、書かれていない部分を勝手に確定させてしまう
このうち、後工程で最も痛いのが「当たり前読み」です。新人本人は「読めた」と思っているので、レビューでも質問が出てこない。設計や実装に入ってから、顧客との認識ズレが顕在化し、仕様変更扱いか手戻りかでもめる、という流れになります。
新人を要件定義書の読み手に育てるとは、この3つの状態から順番に抜け出せるように導いていく作業です。
なぜ表面読みになるのか
新人が表面読みにとどまる背景には、要件定義書という文書の特性と、指導側の渡し方の両方に原因があります。
要件定義書は、業務知識・システム前提・契約上の制約・関係者の意図が積み重なった、いわば「合意の記録」です。書き手側は議論の文脈を共有していますが、後から渡された読み手には、文脈が抜け落ちた結論だけが見えます。経験のある人は、文脈が抜けていることを前提に「ここは仮置きだろう」「これは前提条件だろう」と当たりをつけて読みますが、新人にはその当たりのつけ方がありません。
加えて、指導側が「読んでおいて」とだけ渡してしまうと、新人は何のために読むのかが分からないまま、ひとまず最初から最後まで目で追うことになります。読書感想文と同じ姿勢で読まされている、と言ってもよいかもしれません。
つまり、表面読みは新人の能力の問題ではなく、読む目的と視点を渡していない指導側の問題として捉え直す必要があります。視点を渡せば、読み方は変わります。
要件定義書を読み解く4視点
新人に渡したい視点は、「目的・範囲・前提・曖昧点」の4つです。順番に意味があります。上から順に読み下ろしていくことで、要件定義書を「合意の記録」として読み解けるようになります。
視点1：目的（なぜ作るのか）
最初に確認させるのは、このシステムや機能が「なぜ作られるのか」です。業務上のどんな課題を解決するのか、誰のどんな行動を変えたいのか、という業務目的です。
目的を押さえないまま機能仕様に入ると、すべての要件が等価に見えてしまいます。本来は「目的に直結する中核要件」と「周辺要件」があるはずなのに、その重みが分からないまま全部を実装対象として捉えてしまう。これが優先順位の判断を狂わせます。
新人には、「この機能は何のためにあるのか、自分の言葉で説明してみて」と問い返すのが有効です。説明できなければ、目的が読み取れていないということです。
視点2：範囲（どこまで作るのか）
次に確認させるのは、対応範囲とスコープ外です。受託開発の現場では、ここを曖昧に読んだままだと、後で「これも入っていると思っていた」というスコープ崩れにつながります。
具体的には、次の問いを新人に立てさせます。
- どの業務プロセスを対象とし、どこからは対象外か
- どの利用者・どのデバイス・どの拠点までを対象とするか
- 対象データの種類と期間はどこまでか
- 連携する周辺システムと、その境界はどこか
範囲は、要件定義書の中で明示されている部分と、暗黙に想定されている部分が混在します。新人には「明示的に範囲外と書かれていること」と「書かれていないが範囲外であろうこと」を分けて言語化させるのが、よい訓練になります。スコープ崩れを防ぐ感覚は、こうした問いから育ちます。スコープ管理の実務的な考え方は、追加要望で納期崩壊する前に｜受託PMの線引き合意フレームでも整理しているので、合わせて読ませると効果的です。
視点3：前提（何を当たり前としているか）
3つ目の視点は、要件定義書が暗黙に置いている前提条件です。ここが、新人にとって最も難しい部分でもあります。
要件定義書には、「業務プロセスがある程度標準化されている」「マスタデータが整備されている」「特定のブラウザ環境で利用される」など、書かれていない前提が必ずあります。書き手は当たり前すぎて書いていないのですが、その前提が崩れた瞬間、要件は意味をなさなくなります。
新人には、「もしこの前提が崩れたら、この要件はどうなるか」を考えさせます。たとえば「マスタデータが整備されている」が前提だとして、実は半分以上の支店で表記揺れが残っている、という現場ならどうなるか。前提を疑う訓練が、後の要件ヒアリングや顧客との議論に効いてきます。
視点4：曖昧点（決まっていないことを見つける）
最後に、曖昧点の抽出です。これが、要件読解の到達点と言ってもいい部分です。
曖昧点は、次のような形で現れます。
- 主語が抜けている（「承認する」とあるが、誰が承認するのか書かれていない）
- 数値が幅を持っている（「速やかに」「適切に」など、判断軸が言語に逃げている）
- 条件分岐が網羅されていない（正常系は書かれているが、異常系・例外系の扱いが空白）
- 用語の定義が文脈で揺れている（「顧客」が一般顧客と法人顧客で同じ語で使われているなど）
新人には、要件定義書を読みながら、こうした曖昧点を箇条書きで列挙させるのが効果的です。「この箇所はAともBとも読める」「この用語の指す範囲が章ごとに違うように見える」と言語化できれば、表面読みからは脱却できています。
段階的に身につけさせる3ステップ練習法
4視点を渡しても、新人がいきなり一人で要件定義書を読み解けるわけではありません。指導者側で、難易度を3段階に分けて練習させていきます。
ステップ1：完成版の要件定義書で、視点ごとに読み解く
最初は、すでに過去に納品済みのプロジェクトの要件定義書を題材にします。完成された文書なので、答えに近いものが手元にあります。
新人には、4視点それぞれについて1ページ程度のメモを作らせます。目的は何だったか、範囲はどう切られていたか、どんな前提が置かれていたか、当時どこが曖昧だったか。指導者は、自分の記憶と新人のメモを突き合わせながら、視点ごとに読みのズレを補正します。この段階の目的は、4視点で読むと「文書からこういう情報が取り出せる」という感覚を持たせることです。
ステップ2：ドラフト版の要件定義書で、曖昧点を洗い出す
次に、進行中の案件の、まだドラフト段階の要件定義書を渡します。ここでは曖昧点の抽出に集中させます。
ポイントは、量です。「気になる箇所を100個挙げてみて」と数で指示します。質を求めると、新人は最初から「これは些細だ」と自己検閲してしまい、3〜4個で止まってしまいます。100個挙げさせると、後半は粒度の細かい違和感まで拾うようになり、それが結果的に質の高い曖昧点リストにつながります。
挙がった項目は、指導者が「設計に影響する／影響しない」「顧客に確認すべき／社内で判断できる」の2軸で分類してあげると、新人側に判断基準が残ります。質問の出し方を覚えるための実践演習でもあります。
ステップ3：顧客との打ち合わせ前に、確認事項をまとめる
最後の段階では、顧客との要件確認ミーティングの前に、新人自身に確認事項リストを作らせます。
ここまで来ると、4視点で読む→曖昧点を抽出する→設計に影響する箇所を選ぶ→顧客への質問文に変換する、というサイクルが回り始めます。指導者は、リストの中から実際に顧客にぶつける質問を一緒に選び、ミーティングに同席させて、自分の質問で要件が動いていく経験をさせます。
この経験を1〜2案件くぐらせると、新人は「要件定義書を読む人」から「要件を動かす人」へと立ち位置が変わります。指導者の役割も、視点を渡す側から、判断を相談される側に移っていきます。
指導者が陥りがちな失敗
最後に、4視点を渡す指導側がやってしまいがちな失敗にも触れておきます。
ひとつは、指導者自身の答えを早く出しすぎてしまうことです。新人が考えている途中で「この箇所はこういう意図だよ」と答えを与えてしまうと、視点を使って自分で読み解く経験が積めません。違和感を持たれても、すぐには答えず、「なぜそう感じた？」と返すほうが育ちます。
もうひとつは、曖昧点を挙げた新人を否定してしまうことです。新人が挙げた曖昧点には、的外れに見えるものもあります。しかし、的外れに見える指摘の中にも、顧客が暗黙の前提にしている箇所が含まれていることがあります。「それは大丈夫」と切り捨てる前に、なぜ大丈夫と言えるのかを言語化してみると、指導者側の前提も棚卸しできます。
要件定義書の読解力は、新人だけでなく、チーム全体の合意形成力に直結します。受入基準が曖昧になる現場の問題は、源流をたどればこの読解力の不在に行き着くことも多く、受入基準とリリース延期を止める品質ゲート設計の実務で扱った受入基準の精度も、要件読解の積み上げの上に成り立っています。
まとめ
これまでの内容をまとめると、新人に要件定義書を読み解かせる指導のポイントは次の通りです。
- 「読めない」状態を、表面読み・質問できない・当たり前読みの3つに分解する
- 4つの視点（目的・範囲・前提・曖昧点）を順番に渡す
- 完成文書 → ドラフト文書 → 顧客打ち合わせ前リスト、の3ステップで段階的に練習させる
- 指導者は早く答えを出さず、新人の違和感を引き出す側に回る
要件定義書を読めるかどうかは、若手・新人の伸び代を大きく左右するスキルです。指導者が型を持って渡せば、新人は半年〜1年で「要件を動かす人」へと変われます。
新人本人にも要件定義の体系的な学習を促したい場合は、本記事の「目的・範囲・前提・曖昧点」フレームと整合する『FEX-119：要件定義の読み方入門（家を建てる設計図で学ぶ要件の構造）』が自学用の教材として自然です。さらに、抽出した曖昧点をリスクとして扱う訓練には『IPJ-101：架空PJで学ぶリスクマネジメント実践』を組み合わせると、要件読解からリスク登録までの動きが一気通貫でつながります。
各講座の詳細とUdemyへの導線は、講座一覧ページからご確認ください。