英語でリソース管理計画書を作るよう言われたとき、WBSやプロジェクト計画書と何が違うのか、何をどの粒度で書けばよいか迷った経験はないだろうか。
リソース管理計画書（Resource Management Plan）は「プロジェクトに必要な人・ツール・設備をどのように確保・配分・管理するか」を定めた文書だ。リソース計画・役割と責任・リソースカレンダー・リソースリスク管理の4つを押さえれば、英語でも問題なく整備できる。
この記事では、英語リソース管理計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のプロジェクト立ち上げで活用できる。
リソース管理計画書に必要な4つの構成要素
リソース管理計画書は「誰が・何を・いつ担当するか」と「リソースが足りなくなったときにどう対処するか」を定める文書だ。リソース計画が不明瞭なままプロジェクトを開始すると、担当者の過負荷や予算外の増員が発生しやすい。以下の4つが実務で使いやすい構成要素になる。
- リソース計画（Resource Plan）
- 役割と責任（Roles and Responsibilities）
- リソースカレンダー（Resource Calendar）
- リソースリスク管理（Resource Risk Management）
リソース管理計画書とWBSの違い
WBSはプロジェクトの全作業を階層的に分解した文書で、「何をするか」を定める。リソース管理計画書はWBSの各タスクに「誰が・何工数で対応するか」を割り当て、リソースの過不足を管理する。WBSと合わせて整備することで、スケジュールとリソースが連動した計画になる。
WBSの詳しい作業分解は英語WBSの書き方でも確認してほしい。WBSで作業を分解したあと、リソース管理計画書で担当者と工数を割り当てることで、計画の実現可能性を検証できる。
なぜ英語で書くのか
グローバルプロジェクトでは、チームメンバーが複数の国や拠点に分散していることが多い。英語でリソース管理計画書を整備することで、タイムゾーンや担当範囲をチーム全体で共有し、誰が・いつ・何を担当するかの認識ズレを防げる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | （例：〇〇システム開発プロジェクト） |
| 作成者 | （例：田中（PM）） |
| 作成日 | （例：2026年1月10日） |
| バージョン | （例：v1.0） |
| 承認者 | （例：鈴木（PMO）） |
リソース計画（人材）
| 役割 | 必要スキル | 人数 | 配置フェーズ | 調達方法 | 月次工数 |
|---|---|---|---|---|---|
| PM（プロジェクトマネジャー） | PMP・PgMP相当、英語ビジネスレベル | 1名 | 全フェーズ | 社内 | 160時間 |
| テックリード | Java/Python上級、システム設計経験5年以上 | 1名 | 設計〜リリース | 社内 | 160時間 |
| バックエンドエンジニア | Java/Python中級以上、REST API設計 | 3名 | 開発〜テスト | 社内2名 + 外部1名 | 各160時間 |
| フロントエンドエンジニア | React/TypeScript中級以上 | 2名 | 開発〜テスト | 社内1名 + 外部1名 | 各160時間 |
| インフラエンジニア | AWS・Terraform、セキュリティ設計 | 1名 | 設計〜リリース | 社内 | 80時間 |
| QAエンジニア | テスト設計・自動化経験 | 1名 | テスト〜リリース | 社内 | 160時間 |
| データベース管理者 | MySQL/PostgreSQL上級、移行経験 | 1名 | 設計〜移行 | 外部 | 80時間 |
リソース計画（ツール・インフラ）
| カテゴリ | ツール・サービス | 用途 | 月額コスト目安 |
|---|---|---|---|
| バージョン管理 | GitHub Enterprise | ソースコード管理・コードレビュー | 〇〇円 |
| CI/CD | GitHub Actions / CircleCI | ビルド・テスト・デプロイ自動化 | 〇〇円 |
| クラウドインフラ | AWS（EC2・RDS・S3等） | 本番・ステージング環境 | 〇〇円 |
| プロジェクト管理 | Jira | タスク管理・スプリント計画 | 〇〇円 |
| ドキュメント管理 | Confluence | 仕様書・設計書・手順書の管理 | 〇〇円 |
| コミュニケーション | Slack | 日次コミュニケーション・アラート通知 | 〇〇円 |
| 監視 | Datadog | 本番環境の監視・アラート | 〇〇円 |
役割と責任（RACI）
RACI：R=実施責任（Responsible）、A=最終承認責任（Accountable）、C=相談（Consulted）、I=情報共有（Informed）
| タスク | PM | テックリード | バックエンド | フロントエンド | インフラ | QA |
|---|---|---|---|---|---|---|
| 要件定義 | A | R | C | C | I | C |
| システム設計 | C | A | R | R | R | C |
| 開発 | I | C | R | R | C | I |
| インフラ構築 | C | C | C | I | R/A | I |
| テスト計画 | C | C | C | C | I | R/A |
| UAT調整 | R/A | C | I | I | I | C |
| リリース判断 | A | C | I | I | C | C |
リソースカレンダー
| フェーズ | 期間 | PM | テックリード | バックエンド（3名） | フロントエンド（2名） | インフラ | QA |
|---|---|---|---|---|---|---|---|
| 要件定義 | 1〜2月 | ◎ | ◎ | ○ | ○ | △ | △ |
| 設計 | 3〜4月 | ○ | ◎ | ◎ | ◎ | ◎ | ○ |
| 開発 | 5〜8月 | △ | ○ | ◎ | ◎ | ○ | △ |
| テスト | 9〜10月 | ○ | ○ | ◎ | ◎ | ○ | ◎ |
| 移行・リリース | 11月 | ◎ | ◎ | ○ | ○ | ◎ | ◎ |
凡例：◎ フル稼働（160時間/月）、○ 部分稼働（80時間/月）、△ 最小稼働（40時間/月以下）
リソースリスク管理
| リスク | 発生可能性 | 影響度 | 対応策 |
|---|---|---|---|
| キーパーソンの突然の離脱 | 低 | 高 | ナレッジをドキュメント化・バックアップ担当者の指定 |
| 外部リソースの確保遅延 | 中 | 高 | 調達リードタイムを考慮した早期発注・代替候補の準備 |
| チームメンバーの過負荷 | 中 | 中 | 月次工数レビュー・必要時の増員または優先度調整 |
| スキルミスマッチ | 低 | 中 | 事前のスキルアセスメント・OJTプランの準備 |
| 複数プロジェクトへの掛け持ち | 中 | 中 | 専任比率の明確化・他プロジェクトとの調整 |
英語版テンプレート（コピペ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) |
Human Resource Plan
| Role | Required Skills | Count | Phase | Source | Monthly Effort |
|---|---|---|---|---|---|
| PM (Project Manager) | PMP/PgMP equivalent, business-level English | 1 | All phases | Internal | 160 hours |
| Tech Lead | Senior Java/Python, 5+ years system design | 1 | Design–Release | Internal | 160 hours |
| Backend Engineer | Mid-level Java/Python, REST API design | 3 | Development–Testing | 2 internal + 1 external | 160 hours each |
| Frontend Engineer | Mid-level React/TypeScript | 2 | Development–Testing | 1 internal + 1 external | 160 hours each |
| Infrastructure Engineer | AWS, Terraform, security design | 1 | Design–Release | Internal | 80 hours |
| QA Engineer | Test design, test automation experience | 1 | Testing–Release | Internal | 160 hours |
| Database Administrator | Senior MySQL/PostgreSQL, migration experience | 1 | Design–Migration | External | 80 hours |
Tool and Infrastructure Plan
| Category | Tool / Service | Purpose | Est. Monthly Cost |
|---|---|---|---|
| Version control | GitHub Enterprise | Source code management, code review | [Amount] |
| CI/CD | GitHub Actions / CircleCI | Build, test, deploy automation | [Amount] |
| Cloud infrastructure | AWS (EC2, RDS, S3, etc.) | Production and staging environments | [Amount] |
| Project management | Jira | Task tracking, sprint planning | [Amount] |
| Documentation | Confluence | Specs, design docs, runbooks | [Amount] |
| Communication | Slack | Daily communication, alert notifications | [Amount] |
| Monitoring | Datadog | Production monitoring and alerts | [Amount] |
Roles and Responsibilities (RACI)
RACI: R = Responsible, A = Accountable, C = Consulted, I = Informed
| Task | PM | Tech Lead | Backend | Frontend | Infra | QA |
|---|---|---|---|---|---|---|
| Requirements | A | R | C | C | I | C |
| System Design | C | A | R | R | R | C |
| Development | I | C | R | R | C | I |
| Infrastructure Setup | C | C | C | I | R/A | I |
| Test Planning | C | C | C | C | I | R/A |
| UAT Coordination | R/A | C | I | I | I | C |
| Release Decision | A | C | I | I | C | C |
Resource Calendar
| Phase | Duration | PM | Tech Lead | Backend (×3) | Frontend (×2) | Infra | QA |
|---|---|---|---|---|---|---|---|
| Requirements | Jan–Feb | ◎ | ◎ | ○ | ○ | △ | △ |
| Design | Mar–Apr | ○ | ◎ | ◎ | ◎ | ◎ | ○ |
| Development | May–Aug | △ | ○ | ◎ | ◎ | ○ | △ |
| Testing | Sep–Oct | ○ | ○ | ◎ | ◎ | ○ | ◎ |
| Migration & Release | Nov | ◎ | ◎ | ○ | ○ | ◎ | ◎ |
Key: ◎ Full capacity (160 hrs/month), ○ Partial (80 hrs/month), △ Minimal (≤40 hrs/month)
Resource Risk Register
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Key person sudden departure | Low | High | Document knowledge; designate backup assignees |
| Delay in securing external resources | Medium | High | Order early considering lead times; prepare backup candidates |
| Team member overload | Medium | Medium | Monthly effort review; add headcount or adjust priorities as needed |
| Skill mismatch | Low | Medium | Pre-project skill assessment; prepare OJT plan |
| Concurrent project assignments | Medium | Medium | Clarify dedicated allocation ratio; coordinate with other PMs |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
RACIマトリクスの使い方
RACIはタスクごとに「誰が実際にやるか（R）・誰が最終責任を持つか（A）・誰に相談するか（C）・誰に共有するか（I）」を定めるツールだ。1つのタスクに対してAは必ず1人だけ設定することがポイントだ。Aが複数いると最終判断が曖昧になる。
| 日本語 | 英語 |
|---|---|
| 担当は〇〇です | [Name] is the owner of this task. |
| 最終承認は〇〇が行います | [Name] is accountable for the final decision. |
| 相談先として〇〇を入れてください | Please include [Name] as a consulted party. |
| 〇〇に情報共有します | We’ll keep [Name] informed. |
| RACIを確認してください | Please review the RACI matrix. |
変更管理との連携
リソース変更はプロジェクト計画全体に影響するため、変更管理プロセスと連携することが重要だ。英語変更管理計画書の書き方と合わせて整備することで、増員・担当変更・ツール追加などのリソース変更を正式なプロセスで管理できる。
リソース管理計画書でよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
リソース確認・調整フレーズ
| 日本語 | 英語 |
|---|---|
| 〇月の工数を確認できますか？ | Could you confirm your availability for [month]? |
| 今月はキャパシティがありません | I’m at full capacity this month. |
| 別のタスクを優先することを提案します | I suggest we prioritize a different task. |
| 増員を検討してほしい | I’d like to request additional headcount. |
| 担当を変更してもよいですか？ | Is it possible to reassign this task? |
リソース報告・エスカレーションフレーズ
| 日本語 | 英語 |
|---|---|
| チームのキャパシティが不足しています | The team is running out of capacity. |
| 〇〇の作業が遅延しています | [Task] is running behind schedule. |
| 優先度の見直しが必要です | We need to reprioritize our tasks. |
| 外部リソースの追加を提案します | I propose adding an external resource. |
| スコープの縮小を検討してください | Please consider reducing the scope. |
まとめ：英語リソース管理計画書は4つのセクションで完成する
英語リソース管理計画書に必要な構成要素を整理した。
- リソース計画は人材だけでなくツール・インフラも含めて一覧化し、「何を・いつ・いくらで」確保するかをプロジェクト開始前に合意する
- RACIマトリクスはタスクごとにR・A・C・Iを割り当て、特にAは1タスクに1人だけと決めることで意思決定の権限を明確にする
- リソースカレンダーはフェーズごとの稼働率を可視化し、「このフェーズに全員フル稼働は無理」という過負荷を計画段階で発見する
- リソースリスク管理はキーパーソンの離脱・外部リソースの遅延・過負荷の3大リスクに対して代替手段を事前に準備しておく
テンプレートをコピーして、まず「リソース計画（人材）」から埋め始めてほしい。「誰がいるか」を最初に整理することで、工数見積もりとスケジュールの実現可能性が明確になる。
コメント