要求事項とスコープはどう関係する？
要求事項（requirements）は、成果物やプロジェクトが満たすべき条件や能力です。「会員が30秒以内に予約を終えられる」「個人情報は国内のサーバーに保存する」などが例です。
スコープは、要求事項をもとに「何を作り、何を作らないか」を決めたものです。集めた要求事項を、すべて実現するとは限りません。予算・期限・目的に照らして選び、関係者と合意したものがスコープに入ります。全体の流れはスコープマネジメントの記事で扱っています。
要求事項は、種類に分けて整理すると抜けに気づきやすくなります。ビジネス上の要求（組織として何を達成したいか）、関係者の要求、成果物の機能・非機能の要求、移行の要求（研修やデータ移行）などです。
なお、日本の IT の現場では「要求」と「要件」を呼び分けることがあります。利用者の「こうしたい」が要求、実現すべき条件として整理し合意したものが要件、という使い分けです。PMBOK の日本語版は requirements を「要求事項」と訳しており、この記事もその用語で書きます。
要求事項の主な収集手法は？
代表的な手法を、向いている場面と注意点で比べます。
| 手法 | 向いている場面 | 注意点 |
|---|---|---|
| インタビュー | 専門家や決裁者から深く聞く。機密性の高い話 | 1対1は時間がかかる。相手の言葉どおりが本当のニーズとは限らない |
| フォーカスグループ | 特定の利用者層の期待や反応をまとめて知る | 声の大きい参加者に引っ張られやすい。進行役が要る |
| ワークショップ | 部署をまたぐ要求を短時間で集め、食い違いをその場で解消する | 決定権のある人の参加が必要 |
| アンケート（質問票） | 人数が多い、場所が離れている、統計的に傾向を見たい | 深い理由は聞けない。設問の作り方で結果が偏る |
| 観察（ジョブシャドウイング） | 利用者が作業の手順をうまく言葉にできない | 観察されると普段と違う動きになることがある |
| 文書分析・ベンチマーク | 既存の業務手順書、規制、他社の事例から要求を拾う | 古い文書は現状とずれていることがある |
| ブレーンストーミング | アイデアを広く出す | 出した後に絞り込みと優先順位付けが必要 |
実際は、1つの手法で済むことはまれです。たとえば、アンケートで全体の傾向をつかみ、インタビューで理由を深掘りします。最後にワークショップで、部署間の優先順位を合意します。
ユーザーストーリーとプロトタイプはどう使う？
ユーザーストーリー は、「（利用者）として、（目的）のために、（機能）がほしい」という形で、要求を利用者の視点で短く書く方法です。誰の何のための要求かが分かるので、優先順位を付けやすくなります。ストーリーには受入基準を添え、完成の判定ができるようにします。書き方はユーザーストーリーの書き方で詳しく扱います。
アジャイルでは、要求事項は最初に集め切るものではありません。ストーリーとしてプロダクトバックログに並べ、近いうちに作るものから詳しくしていきます。スプリントレビューで利用者の反応を見て、新しい要求が見つかるのも普通のことです。
プロトタイプ（試作） は、完成品の前に簡単な模型を作って見せ、反応を集める方法です。画面の紙芝居、クリックできる模型、簡易な試作品などがあります。「見れば分かるが、言葉では説明できない」要求を引き出すのに強い手法です。
作って見せる→意見をもらう→直す、を繰り返すので、アジャイルの考え方とも相性がよいです。この繰り返しを図にします。
- 1
試作を作る
最小限の手間で
- 2
見せて使ってもらう
利用者・関係者
- 3
反応を集める
良い点・困る点・足りない点
- 4
要求を更新する
優先順位も見直す
要求が十分に分かるまで繰り返す
当サイトの整理
集めた要求はどう絞り込む？
集めた要求を、すべて作ることはできません。予算・期限・目的に照らして優先順位を付け、関係者と決めます。決め方の代表例は次のとおりです。
- MoSCoW：Must・Should・Could・Won't の4つに分ける。使い方はMoSCoW分析で詳しく扱います。
- 投票：全員一致、過半数、相対多数（最も票の多い案）などのルールで決める。
- 多基準意思決定分析：費用・効果・リスクなどの基準に重みを付け、案を点数で比べる。
- 1人が決める：スポンサーなどが決める。速いが、ほかの人の納得は得にくい。
大事なのは、決め方を先に合意しておくことです。結論が出てからルールを決めると、負けた側が納得しません。それでも合意できないときは、プロジェクトの目的に立ち返り、最後はスポンサーが判断します。
要求事項トレーサビリティマトリクスとは？
要求事項トレーサビリティマトリクス（RTM）は、要求事項ごとの「つながり」を表にした道具です。どの目的から来て、どの成果物で実現され、どの試験で確かめるかを1行で追えるようにします。
| 要求ID | 要求事項 | 出どころ（目的） | 成果物（WBS） | 確認方法 |
|---|---|---|---|---|
| R-01 | 会員は30秒以内に予約を終えられる | 成功基準：予約完了率の向上 | 3.1 予約機能 | 利用者試験 T-12 |
| R-02 | 予約の確認メールを即時に送る | 顧客満足の向上 | 3.2 通知機能 | 結合試験 T-20 |
| R-03 | 個人情報は国内サーバーに保存 | 社内規程の順守 | 4.1 基盤設計 | 設計レビュー D-03 |
RTM の効き目は2方向です。要求から成果物へたどれば、作り忘れ（抜け）が見つかります。成果物から要求へたどれば、どの要求にもつながらない作業、つまり余計な追加が見つかります。後者はスコープクリープを見つける手がかりにもなります。
終盤には、RTM の「確認方法」の列が、成果物を受け入れてもらう場面で役立ちます。要求を満たしたことを示す根拠になるからです。
PMP試験では要求事項の収集がどう問われる？
新しい ECO（2026年版）で、要求事項の収集は Process タスク2「スコープを作り、管理する」の土台にあたります。品質の要求事項を集めることは、Process タスク7のイネーブラーにも挙がっています。2021年版では、スコープのタスクに「要求事項を決めて優先順位を付ける」が明記されていました。2026年版のタスク2からは、この文言が外れています。それでも、スコープを定義する前提であることは変わりません。
手法の名前を答えさせる問題より、場面に合う手法を選ぶ問題が中心です。
- 利用者が作業の手順をうまく説明できない → 観察やプロトタイプ
- 部署ごとに要求が食い違っている → 決定権のある関係者を集めたワークショップで合意
- 全国の多数の利用者から意見を集めたい → アンケート
- 作った後に「思っていたのと違う」と言われる → 早い段階で試作を見せる、短い反復で確認する
手法の選び方は、タスク別ドリルで場面ごとに練習できます。
POINT
よくある誤答：①関係者の言葉をそのまま要求事項にする（背景の目的を確かめる）。②声の大きい部署や人数の多い部署の要求を採る（目的に照らして合意する）。③食い違いを記録しただけで先送りする、またはすぐスポンサーに上げる（まず関係者を集めて話し合う）。
確認問題1
言葉にできない業務の要求
（当サイトの独自問題）倉庫の出荷作業を支援するシステムを作ります。作業員へのインタビューでは「いつもどおりやっているだけ」という答えが多く、具体的な手順や困りごとが出てきません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。本人が言葉にしにくい作業の要求は、実際の作業を観察すると引き出しやすくなります。観察で見えたことは、後でインタビューや試作で確かめます。
1：言葉にできない人に記入を求めても、同じ問題が起きます。2：現場の実態が反映されないおそれがあります。4：他社の仕様は参考になりますが、この現場のニーズと一致するとは限りません。
確認問題2
部署ごとに要求が食い違う
（当サイトの独自問題）経費精算システムの要求事項を、部署ごとにインタビューしました。経理部は承認の段階を増やしたいと言い、営業部は承認を減らして早く精算したいと言っています。どちらの部長も決定権を持っています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。対立する要求は、決定権のある関係者が同じ場で議論して合意するのが効果的です。判断の物差しは、プロジェクトの目的（例：統制と処理速度のバランス）です。合意できなければ、スポンサーが判断します。
2：一方の関係者を外すと、後で反発が起きます。3：合意なしに両方作ると、スコープが膨らみます。4：記録は必要ですが、関係者で解決を試みる前に判断を上げており、自分では動いていません。
確認問題3
抜けた要求の見つけ方
（当サイトの独自問題）試験工程に入る前のレビューで、抜けが見つかりました。「監査ログを5年間保存する」という規制上の要求が、どの成果物でも実現されていません。今後、同じような抜けを早く見つけたいと考えています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。要求事項トレーサビリティマトリクスで、要求→成果物→確認方法をつないで追跡します。実現されていない要求を、早い段階で見つけられます。今回の抜けは、影響を分析して変更の手続きで対応します。
1：一覧では、どの成果物で実現されるかが分かりません。2：試験は遅い段階での発見になり、手戻りが大きくなります。3：負担が大きく、仕組みとして続きません。