この記事は、これからPMとしてキャリアを始めたい人、事業会社で初めて要件定義フェーズのPMを任された人、IT関連の仕事でPMが要件定義で何を決めるのか知りたい人、すでにPMとして働いているものの、要件定義工程で自分が何に責任を持つべきかがまだ曖昧な人（およびPMを支えるPMOの方）に向けて書いています。
「要件定義書、ちゃんと揃ってるけど、このまま進めていいのか分からない」——PMとして要件定義フェーズに立ったとき、一度はこの感覚を持つはずです。成果物は大量にあり、PMOやベンダーが用意してくれる。でも、最後に「OK」を出すのは自分。何を見て、何をもってOKと判断すればいいのか。
この問いに答えるため、架空のプロジェクトを題材に、要件定義書（ビジネス要件）の全スライドを1枚ずつ解説します。前回の記事で「ビジネス要件とは何か」を概念的に説明しましたが、今回は「実際にどんな資料を、どんな順番で作るのか」を見ていきます。
題材は、架空の食品商社「Turtle Food株式会社」の受発注管理システム刷新プロジェクト（ORDER-NEXT）。年商120億円・従業員約500名のBtoB食品商社が、FAXや電話中心の受注業務をデジタル化するために、1億2,000万円・18ヶ月のウォーターフォール型プロジェクトを立ち上げた、という設定です。全記事でこのシナリオに統一しています。
要件定義書の実物はこちら。記事を読みながら手元で開くと、解説とスライドが一対一で対応していて理解が進みます。
まず結論：ビジネス要件の5プロセスに沿って、27枚の成果物を作る
IPAの要件定義ガイドでは、ビジネス要件を5つのプロセス（BR.1〜BR.5）で進めると定めています。ORDER-NEXTプロジェクトの要件定義書も、この5プロセスの順番で構成されています。
各プロセスと、そこで作成する成果物の対応は以下の通りです。
- BR.1 ステークホルダー把握：誰がプロジェクトに関わるかを整理する
- BR.2 As-Is（現状）把握：今の業務の流れとデータを可視化する
- BR.3 問題・ニーズ把握：何に困っているかを洗い出し、構造化する
- BR.4 施策検討：どんな施策で解決するかを検討し、優先度をつける
- BR.5 To-Be（あるべき姿）検討：新しい業務の流れとシステムの姿を設計する
以下、プロセスごとに各スライドの「何がわかるか」「なぜ必要か」を解説します。
成果物をどの順番で作り、誰が何を決めるか
ビジネス要件の成果物は「作って終わり」ではなく、1枚ごとに「誰かが何かを決める」ために存在します。以下は、成果物を作る順番と、それぞれの意思決定の流れです。
| ステップ | やること | 主な成果物 | 作成者 | 意思決定者 | 何を決めるか |
|---|---|---|---|---|---|
| 1 | プロジェクトの存在理由を合意する | ビジネスコンセプト確認ドキュメント | PM・PMO | 経営者 | 「このKGIで投資を進めるか」 |
| 2 | 関係者を整理する | ステークホルダー一覧・ステークホルダー関係図 | PMO | PM | 「この人たちで進めてよいか」 |
| 3 | 責任と会議体を設計する | RACI表・コミュニケーション計画 | PMO | PM→経営者 | 「この体制・ルールで承認するか」 |
| 4 | 用語を統一する | 業務用語定義 | PMO＋業務部門 | PM | 「この用語でよいか」 |
| 5 | 現場の業務全体を把握する | リッチピクチャ・業務全体図（As-Is）・業務フロー（As-Is） | PMO＋業務部門 | PM | 「現状認識は合っているか」 |
| 6 | 業務の構成要素とデータを整理する | 業務機能構成表・業務データ一覧 | PMO＋業務部門 | PM | 「業務の粒度と定義はこれでよいか」 |
| 7 | 現場の困りごとをヒアリングする | ヒアリング議事録 | PMO | 各業務部門 | 「現場の声を正しく拾えているか」 |
| 8 | 課題を洗い出し構造化する | 課題一覧・問題原因分析図・優先度マトリクス | PMO | PM→経営者 | 「どの課題を優先的に解決するか」 |
| 9 | 何をシステム化するか決める | 管理対象分類図 | PM・PMO | 経営者・PM | 「システム化の範囲はここまででよいか」 |
| 10 | 施策を検討し投資判断する | 要求構造図・要求一覧・ROI試算 | PM・PMO | 経営者 | 「この施策に投資するか」 |
| 11 | 新しい業務の姿を設計する | ビジネスプロセス関連図・業務全体図・業務フロー（To-Be）・業務機能構成表（To-Be）・As-Is→To-Be変化サマリ | PMO＋ベンダー | PM→経営者 | 「この業務の姿で進めるか」 |
| 12 | 業務ルールとデータ構造を定義する | 概念データモデル・業務処理定義・状態遷移図 | PMO＋ベンダー | PM | 「この仕様でベンダーに渡してよいか」 |
この表の左から右へ読むと「何を→誰が作り→誰が決め→何が決まるか」がわかります。上から下へ読むとプロジェクトの意思決定の流れがわかります。以降の解説は、この流れに沿って進みます。
ビジネスコンセプト：プロジェクトの「存在理由」を経営層と合意する
BR.1のステークホルダー整理と並行して最初に固めるのが、プロジェクト全体の「存在理由書」です。外部環境（EDI標準化・インボイス制度・競合のデジタル化）と内部課題（手入力ミス年間60件・月次集計3日）を整理し、ビジネスゴール（KGI：業務コスト年間1,500万円削減・受注ミス年間5件以下・受注確認書5分以内発行）を経営層と合意します。以降のすべての要件はこのKGIに紐づく形で正当化されます。ここでKGIへの合意が得られなければ、どれほど精緻な課題分析や施策設計も「何のためにやるのか」が曖昧なまま進んでしまいます。
BR.1 ステークホルダー把握：「誰が関わるか」を最初に決める
要件定義で一番最初にやるのは、プロジェクトの関係者を整理することです。「誰にヒアリングするか」「誰の承認が必要か」が決まらないと、後の作業が全部止まります。
ステークホルダー一覧
プロジェクトに関わる全員の「プロフィールカード」です。名前・役職だけでなく、各人がプロジェクトに対して「何を重視しているか」まで記載します。たとえば経理部の大西課長が「月次業務の負荷軽減」を重視していることが分かれば、ヒアリングで何を聞くべきかが事前に設計できます。まず誰が関わるかを一覧で把握してから、関係性を図に落とします。
ステークホルダー関係図
一覧で把握した関係者を「人間関係地図」として可視化したものです。丸山社長→田中PM→各業務部門という意思決定ラインと、PMとPMOの役割分担、ITベンダーとの関係が1枚で見えます。図の上下は「偉さ」ではなく「要件が流れる方向」を表しています。業務部門が中段にいるのは要件の出元だから、ITベンダーが下段にいるのはそれを受けて作る側だからです。
責任分担表（RACI表）
「誰が何に対して責任を持つか」の契約書です。各成果物・プロセスに対してA（承認）・R（実行）・C（相談）・I（情報共有）・S（支援）を割り当てます。これがないと「誰かがやってくれると思っていた」という抜け漏れと、「それは私の仕事ではない」という押しつけが必ず起きます。
コミュニケーション計画
「誰に、何を、いつ、どうやって伝えるか」を整理した計画です。ステークホルダー関係図・一覧・RACI表があってはじめて作れるもので、BR.1の集大成にあたります。定例会議の頻度・参加者・報告内容が明文化されていることで、「聞いてない」「知らなかった」というトラブルを防ぎます。
BR.2 As-Is把握：「今どうなっているか」を全員で共有する
次にやるのは、現状の業務を可視化することです。現場は自分の部門の業務しか把握していないことが多く、全体像を見せることで初めて「同じ土俵」に立てます。
業務用語定義
「受注」「EDI」「WMS」「インボイス制度」など、プロジェクトで頻出する業務・技術用語の定義を統一した辞書です。用語ごとに定義・説明・関連業務・出典を記載し、「この定義はどこに根拠があるか」まで明示することで、後工程での認識ズレと解釈の揺れを防ぎます。用語がバラバラだと、要件定義の議論で「同じ言葉で違うことを話している」状態が起きます。業務フローや課題一覧を作る前に統一しておくことが重要です。
リッチピクチャ（業務の現状俯瞰）
業務の流れだけでなく、現場の「困り感」や感情を含めた非形式の俯瞰図です。FAXが飛び交い、電話で在庫確認し、Excelに手入力している現場の混乱を、1枚の絵として伝えます。経営層やITベンダーに「なぜこのプロジェクトが必要か」を直感的に伝える際に最も効果的な資料です。
業務全体図（As-Is）
業務の全体像を「機能の箱」として構造化した図です。業務フローが「流れ」を見せるのに対し、業務全体図は「地図」です。どの業務領域にどんな機能があるかを俯瞰し、システム化する範囲を視覚的に検討できます。リッチピクチャで掴んだ全体感を、構造化された形に落とし込むのがこの図です。
業務フロー（As-Is）
業務全体図が「地図」なら、業務フローは「設計図」です。部門ごとのスイムレーン形式で業務の流れを正確に記述し、課題がある工程に赤枠をつけます。ORDER-NEXTの場合、受注管理課の工程がほぼ全部赤枠で、「受注管理課が最大の改善対象」であることが一目でわかります。To-Beフローを作るときの出発点になります。
業務機能構成表（業務一覧）
業務を「機能」の単位で分解し、一覧にしたものです。業務全体図が業務の「全体地図」なら、この表は「各業務の詳細仕様書」です。どの業務がどの部門の担当で、現在どんな手段（FAX・電話・Excel・紙）で行っているか、頻度・業務量・課題まで含めて整理します。As-Isの段階では、あくまで現状の手段を記載します。To-Beの手段（EDI・API・自動化など）はBR.5で設計します。
業務データ一覧
業務で扱うデータをエンティティ（受注ヘッダ・受注明細・得意先マスタ等）の単位で一覧にしたものです。区分（トランザクション／マスタ／ログ）・生成業務・利用業務・主要データ項目・保存期間を整理し、「どの業務機能がどのデータを作り・使うか」のつながりを可視化します。後工程の概念データモデルやシステム要件のインプットになります。
BR.3 問題・ニーズ把握：「何に困っているか」を掘り下げる
As-Isが可視化できたら、次は業務のどこに問題があるかを洗い出します。まず現場の声を聞き、それを構造化していきます。
ヒアリング議事録
現場担当者へのヒアリング内容をまとめた記録です。ORDER-NEXTでは受注管理課・経理部・営業部門の3部門からヒアリングを行い、各部門が「何に困っていて、何を望んでいるか」を生の声として記録しています。たとえば受注管理課の中村課長は「Excelの打ち込みミスで出荷違いが年60件」、経理部の大西課長は「月末3日間は請求書作業で完全に埋まる」と語っています。この生の声が、次の課題一覧の根拠になります。
問題・ニーズ・課題一覧
課題ID（C01〜C06）をつけて、業務上の問題を整理した一覧です。ヒアリングで得た現場の声を「課題」という単位に整理し、影響度と数値根拠を明記します。この段階でやることは「何が問題か」を明確にすることまでです。「どのIT施策で解決するか」はBR.4の施策検討で初めて扱います。BR.3の課題一覧は業務課題の把握が目的であり、IT施策の翻訳を行う段階ではありません。
問題原因分析図
個々の問題がどのような原因構造から生まれているかを掘り下げた図です。課題一覧が「何が問題か」を列挙するのに対し、原因分析図は「1つの問題をなぜなぜで深掘りした結果」を示します。根本原因にたどり着くことで、表面的な対症療法ではなく本質的な施策を設計できます。ORDER-NEXTでは、C01〜C06の各課題について「なぜ起きているか」を掘り下げ、「受注ミスが多い→手入力工程が多い→FAX受注が廃止できていない→デジタル化投資の優先度が低かった」というように根本原因まで連鎖させています。
問題・ニーズ優先度マトリクス
課題を「影響度」と「緊急度」の2軸でマッピングした図です。6つの課題のうちどれを優先的に解決すべきかが視覚的にわかります。限られた予算と工期の中で「何を先にやるか」を関係者全員で合意するための判断材料です。
BR.4 施策検討：「どうやって解決するか」を決める
問題が整理できたら、次はそれをどう解決するかを検討します。
管理対象分類図
施策の対象を「システム化する領域」「運用で対応する領域」「対象外」に分類した図です。すべてをシステムで解決するわけではなく、業務手順の変更で対応するもの、今回は手をつけないものを明確に区分けします。課題が整理された段階でまず「何をシステム化するか」の範囲を確定させることで、後続の要求構造図・施策一覧の検討がブレなくなります。
要求構造図
課題→施策→機能要件のつながり（トレーサビリティ）を図で示したものです。ORDER-NEXTでは、ビジネスゴール（KGI）を頂点に置き、その下に各課題ID（C01,C02,C03,C05など）、さらに施策ID（S01〜S08）、最後に業務機能ID（BZ-01,BZ-03,BZ-06…）が連鎖する構造になっています。「C01（受注ミス）→S01（Web受注ポータル）→BZ-01（受注受付）」という線がつながることで、「なぜこの機能が必要か」が一目でわかり、後工程でのスコープ議論の根拠にもなります。
要求一覧（施策一覧）
施策ID（S01〜S08）をつけて、課題IDと紐づけた施策の一覧です。ORDER-NEXTでは8つの施策が検討され、フェーズ1で採用する5つ（Web受注ポータル・在庫API連携・WMS出荷連携・請求書自動生成・注文履歴ダッシュボード）と、フェーズ2以降に見送る3つ（与信管理・ERP統合・AI需要予測）が明示されています。「何を作るか・作らないか」を公式に決める最重要ドキュメントです。
施策費用対効果試算（ROI）
各施策の導入コストと年間削減効果を数字で示した試算表です。ORDER-NEXTの場合、年間削減効果が約1,420万円、投資回収期間は約2.1年と試算されています。経営層が「この投資は妥当か」を判断するための材料です。
BR.5 To-Be検討：「将来どうなるか」を設計する
最後に、新しい業務の姿を設計します。As-Isと同じ形式の成果物をTo-Be版として作り、「何がどう変わるか」を対比で示します。
ビジネスプロセス関連図
IPAが定める「ビジネス全体の俯瞰図（ヒト・モノ・カネの流れ）」です。受注→出荷→請求→分析のプロセスフローを中心に、各プロセスを担当する部門（受注管理課・倉庫部門・経理部・営業部門）、連携するシステム（ERP・WMS・会計）、外部エンティティ（得意先）との関係を1枚で示します。BR.2のリッチピクチャが「現状の混乱と課題」を感情も含めて描いたのに対し、ビジネスプロセス関連図は「To-Beで業務がどう整理されるか」を構造的に示し、経営層・業務部門・ベンダーが同じ全体像を共有するための図です。
業務全体図（To-Be）
As-Is版と対になる、将来の業務機能構成図です。BZ-01〜BZ-15の15機能を体系的に並べ、「システム化する」「手作業で残す」を色分けで明示しています。たとえば受注受付（BZ-01）はEDI/Web化される一方、ピッキング（BZ-07）は現場作業として残る、といった判断が一目でわかります。この図がそのまま機能要件定義書の目次になります。
業務フロー（To-Be）
As-Isフローと対比する形で、新しい業務の流れを描いた図です。「FAXで受注→Excelに手入力」が「EDIで自動受信→APIで在庫照会→WMSへ自動出荷指示」に変わることで、関係者は「何がどう変わるのか」を具体的にイメージできます。
業務処理定義（業務ルール）
新システムが守るべき業務ルールを定義したものです。「在庫が引当数に満たない場合はアラートを出す」「14時までの確認受注は当日出荷、14時超は翌営業日」「キャンセルは管理者承認必須」といったルールを明文化し、ベンダーがシステムを設計する際の仕様の根拠にします。
状態遷移図（受注ステータス）
受注データが「未確認→確認済→引当済→出荷指示済→出荷済→完了→請求確定→月次締め」と変化する流れを図にしたものです。どのタイミングでどんな処理が走り、どの状態に遷移するかを定義します。キャンセル（管理者承認が必要）や引当待ち（在庫不足時の自動リトライ）といった例外パターンも含めて設計します。
業務機能構成表（To-Be）
As-Is版と対になる、将来の業務機能一覧表です。各業務機能が「システム化する」「手作業で残す」「今回対象外」のどれに分類されるかを明示します。担当部門・使用システム・業務量の目標値もあわせて記載することで、To-Beの業務全体図（構造図）を補完する詳細リストとして機能します。ベンダーへの要件提示時に「どの機能をシステムで実装するか」の根拠ドキュメントになります。
概念データモデル（ER図概要）
新しい業務で扱うデータ（得意先・商品・受注・在庫など）の関係を図にしたものです。「受注は得意先と商品に紐づく」「在庫は商品と倉庫に紐づく」といったデータ構造を可視化します。現在受注管理システムが存在しないORDER-NEXTでは、これはTo-Be（将来のシステム）のデータ構造設計であり、システム化要件でのデータベース設計の出発点になります。To-Be業務フローが確定した段階でデータ構造を設計することで、業務の流れとデータの関係が整合します。
As-Is → To-Be 業務変化サマリ
As-IsとTo-Beの変化点を一覧で整理したサマリーです。各業務が「現状はこう→将来はこう」と対比される表形式で、経営層やベンダーに「プロジェクト全体で何が変わるか」を短時間で伝えるのに使います。BR.5の締めくくりとして、全体の変化を1枚で俯瞰できる形にまとめます。
1分で振り返るまとめ
- ビジネス要件は、まずビジネスコンセプトで経営層とKGIを合意し、5つのプロセス（BR.1〜BR.5）に沿って成果物を作る
- ビジネスコンセプト：KGI・外部環境・内部課題を整理し「この投資を進めるか」を経営層と確定する
- BR.1：ステークホルダー一覧・関係図・RACI・コミュニケーション計画で「誰が関わるか」を整理
- BR.2：業務用語定義→リッチピクチャ→業務全体図→業務フロー→業務機能構成表→業務データ一覧で「今どうなっているか」を可視化
- BR.3：ヒアリング議事録→課題一覧→問題原因分析図→優先度マトリクスで「何に困っているか」を構造化
- BR.4：管理対象分類図→要求構造図→要求一覧→ROIで「どう解決するか・何をシステム化するか」を決める
- BR.5：ビジネスプロセス関連図→業務全体図→業務フロー→業務処理定義→状態遷移図→業務機能構成表（To-Be）→概念データモデル→変化サマリで「将来どうなるか」を設計する
- 成果物はすべてIPAの要件定義ガイドに準拠。課題ID→施策IDのトレーサビリティが全体をつなぐ
Discussion