英語で要件管理計画書を作るよう言われたとき、要件定義書（BRD）や仕様書とどう違うのか、何をどの粒度で書けばよいか迷った経験はないだろうか。
要件管理計画書（Requirements Management Plan）は「プロジェクトの要件をどのように収集・記録・管理・変更するか」のルールを定めた文書だ。要件収集方針・要件の優先順位付け・要件変更管理・要件トレーサビリティの4つを押さえれば、英語でも問題なく整備できる。
この記事では、英語要件管理計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のプロジェクト立ち上げで活用できる。
要件管理計画書に必要な4つの構成要素
要件管理計画書はプロジェクトの要件を「どうやって集め・どうやって整理し・変更が発生したらどうするか」のルールを定める文書だ。要件を収集するだけでなく、優先順位のつけ方と変更管理のルールまで決めることで、要件のスコープクリープを防げる。以下の4つが実務で使いやすい構成要素になる。
- 要件収集方針（Requirements Elicitation Approach）
- 要件の優先順位付け（Requirements Prioritization）
- 要件変更管理（Requirements Change Management）
- 要件トレーサビリティ（Requirements Traceability）
要件管理計画書とBRD（Business Requirements Document）の違い
BRDは「ビジネスが何を必要としているか」という要件の内容を記述する文書だ。要件管理計画書は「その要件をどうやって管理するか」のルールを定める文書だ。BRDが「何を作るか」を定義するのに対し、要件管理計画書は「どうやって要件を管理するか」を定義する。
BRDの書き方は英語BRD（要件定義書）の書き方でも確認してほしい。
なぜ英語で書くのか
グローバルプロジェクトでは、要件収集・レビュー・承認が英語で行われることが多い。英語で要件管理計画書を整備することで、タイムゾーンをまたいだチームでも同じ基準で要件を管理できる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | （例：〇〇システム開発プロジェクト） |
| 作成者 | （例：田中（PM）） |
| 作成日 | （例：2026年1月10日） |
| バージョン | （例：v1.0） |
| 承認者 | （例：鈴木（PMO）） |
要件収集方針
| 項目 | 内容 |
|---|---|
| 収集方法 | インタビュー / ワークショップ / アンケート / 既存ドキュメントのレビュー |
| 収集対象 | プロジェクトスポンサー・業務担当者・システム管理者・エンドユーザー |
| 要件記録ツール | Confluence（BRD）+ Jira（ユーザーストーリー） |
| 要件の種類 | 機能要件（Functional） / 非機能要件（Non-Functional） / ビジネスルール |
| 要件レビュー頻度 | 要件定義フェーズ：週次 / 開発フェーズ：月次 |
| 要件承認者 | プロジェクトスポンサー（最終承認） + 業務担当者（内容確認） |
要件の優先順位付け（MoSCoW法）
| 優先度 | 定義 | 対応方針 |
|---|---|---|
| Must Have | プロジェクトの成功に必須の要件 | 必ずスコープに含める |
| Should Have | 重要だが必須ではない要件 | 可能な限りスコープに含める |
| Could Have | あると良いが優先度が低い要件 | 時間・コストに余裕がある場合に対応する |
| Won’t Have | 今回は対応しない要件 | 次フェーズ以降の候補として記録する |
要件変更管理
| ステップ | 内容 | 担当 | 期限 |
|---|---|---|---|
| 1. 変更要求の受付 | ステークホルダーからの変更要求をJiraの変更チケットとして登録する | PM | 随時 |
| 2. 影響分析 | スコープ・スケジュール・コストへの影響を分析する | PM + テックリード | 受付後2営業日以内 |
| 3. 優先度評価 | MoSCoW法で変更の優先度を評価する | PM + ステークホルダー | 影響分析後1営業日以内 |
| 4. 承認 | 変更内容をスポンサーに提示し、承認を得る | PM | 優先度評価後3営業日以内 |
| 5. 要件更新 | 承認された変更をBRD・Jiraに反映する | PM | 承認後1営業日以内 |
| 6. 周知 | 変更後の要件をチームとステークホルダーに共有する | PM | 更新後1営業日以内 |
要件トレーサビリティ
| 要件ID | 要件名 | 優先度 | 設計 | 開発 | テスト | ステータス |
|---|---|---|---|---|---|---|
| REQ-001 | ログイン機能 | Must Have | DS-001 | DEV-001 | TC-001 | 完了 |
| REQ-002 | パスワードリセット機能 | Should Have | DS-002 | DEV-002 | TC-002 | 開発中 |
| REQ-003 | 多要素認証（MFA） | Could Have | — | — | — | 未対応 |
英語版テンプレート（コピペOK）
Basic Information
| Item | Details |
|---|---|
| Project Name | (e.g., [System] Development Project) |
| Prepared By | (e.g., Tanaka, PM) |
| Date | (e.g., January 10, 2026) |
| Version | (e.g., v1.0) |
| Approved By | (e.g., Suzuki, PMO) |
Requirements Elicitation Approach
| Item | Details |
|---|---|
| Elicitation Methods | Interviews / Workshops / Surveys / Review of existing documents |
| Stakeholders | Project sponsor, business owners, system admins, end users |
| Documentation Tool | Confluence (BRD) + Jira (user stories) |
| Requirement Types | Functional / Non-Functional / Business Rules |
| Review Frequency | Requirements phase: weekly / Development phase: monthly |
| Approvers | Project Sponsor (final approval) + Business Owner (content review) |
Requirements Prioritization (MoSCoW)
| Priority | Definition | Action |
|---|---|---|
| Must Have | Essential for project success | Always include in scope |
| Should Have | Important but not critical | Include if possible |
| Could Have | Nice to have but low priority | Address if time and budget allow |
| Won’t Have | Out of scope for this project | Record as a candidate for future phases |
Requirements Change Management
| Step | Action | Owner | Deadline |
|---|---|---|---|
| 1. Receive Request | Log the change request as a Jira ticket | PM | As needed |
| 2. Impact Analysis | Assess impact on scope, schedule, and cost | PM + Tech Lead | Within 2 business days of receipt |
| 3. Prioritization | Evaluate priority of the change using MoSCoW | PM + Stakeholders | Within 1 business day of analysis |
| 4. Approval | Present to sponsor and obtain approval | PM | Within 3 business days of prioritization |
| 5. Update Requirements | Reflect approved changes in BRD and Jira | PM | Within 1 business day of approval |
| 6. Communicate | Share updated requirements with team and stakeholders | PM | Within 1 business day of update |
Requirements Traceability Matrix
| Req ID | Requirement | Priority | Design | Dev | Test | Status |
|---|---|---|---|---|---|---|
| REQ-001 | Login feature | Must Have | DS-001 | DEV-001 | TC-001 | Done |
| REQ-002 | Password reset | Should Have | DS-002 | DEV-002 | TC-002 | In progress |
| REQ-003 | MFA | Could Have | — | — | — | Deferred |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
MoSCoW法の運用ポイント
MoSCoW法は要件の優先順位を「Must / Should / Could / Won’t」の4段階で分類するフレームワークだ。重要なのは「Must Have」の比率をコントロールすることで、全要件をMust Haveにするとスコープクリープが発生する。Must Haveは全体の60%以内に抑えるのが実務上の目安になる。
| 日本語 | 英語 |
|---|---|
| この要件は必須です | This requirement is a Must Have. |
| この機能はあると良いですが必須ではありません | This feature is a Should Have, not essential. |
| 今回のスコープ外にします | This will be a Won’t Have for this release. |
| 優先度を下げることを提案します | I suggest lowering the priority of this requirement. |
| 要件変更を正式に依頼します | I’d like to formally request a change to this requirement. |
コミュニケーション管理との連携
要件変更が発生した場合、変更内容をステークホルダーに適切に伝えるためのコミュニケーションルートが必要だ。英語コミュニケーション管理計画書の書き方と合わせて整備することで、要件変更の情報が関係者全員に迅速に届く体制が整う。
要件管理計画書でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
要件収集・確認フレーズ
| 日本語 | 英語 |
|---|---|
| 要件を確認させてください | Let me confirm the requirements. |
| この要件の優先度を教えてください | Could you share the priority of this requirement? |
| 要件に変更はありますか？ | Are there any changes to the requirements? |
| この要件はスコープ内ですか？ | Is this requirement within scope? |
| 要件を追加する場合は変更管理プロセスを経てください | Any new requirements must go through the change management process. |
要件変更・エスカレーションフレーズ
| 日本語 | 英語 |
|---|---|
| 要件変更の影響を分析しました | I’ve analyzed the impact of this requirements change. |
| スコープへの影響は〇〇です | The impact on scope is [description]. |
| スケジュールへの影響は〇〇日です | The schedule impact is [X] days. |
| 承認をお願いします | Please approve this change. |
| 要件を更新しました | The requirements have been updated. |
要件の変更がプロジェクトに大きな影響を与える場合はエスカレーションが必要になる。英語エスカレーションメールの書き方と合わせて活用することで、要件変更の判断を適切なタイミングで上位者に委ねる体制が整う。
要件の変更が発生した場合は変更管理プロセスを通じて正式に申請する必要がある。英語変更要求書の書き方と合わせて活用することで、要件変更の影響をスコープ・スケジュール・コストの観点から正確に評価できる。
まとめ：英語要件管理計画書は4つのセクションで完成する
英語要件管理計画書に必要な構成要素を整理した。
- 要件収集方針はインタビュー・ワークショップ・アンケートの収集方法と承認者を定め、「どうやって要件を集め・誰が承認するか」の共通ルールをプロジェクト開始前に合意する
- 要件の優先順位付けはMoSCoW法でMust/Should/Could/Won’tの4段階に分類し、「何を必ずやり・何を後回しにするか」をチーム全員が同じ基準で判断できる状態にする
- 要件変更管理は6ステップのプロセスで変更要求を受付から周知まで一貫して管理し、スコープクリープを防ぐ
- 要件トレーサビリティは要件IDと設計・開発・テストの対応を一覧化し、「この要件がどこに実装されどこでテストされたか」を追跡できる状態にする
テンプレートをコピーして、まず「MoSCoW法の優先度基準」をステークホルダーと合意してほしい。優先度基準を最初に合意することで、要件変更の議論が「必要か・不要か」ではなく「どの優先度か」という生産的な議論になる。
リスク管理と要件管理は密接に連携する。要件の未確定がリスクになる場合は英語リスク管理計画書の書き方のリスク対応戦略と組み合わせて管理することで、要件リスクの早期対処が可能になる。
コメント