【テンプレあり】英語スケジュール管理計画書の書き方｜ITプロジェクトで使える日英フォーマット付き

英語でスケジュール管理計画書を作るよう言われたとき、プロジェクト計画書やWBSとどう違うのか、何をどの粒度で書けばよいか迷った経験はないだろうか。

スケジュール管理計画書（Schedule Management Plan）は「プロジェクトのスケジュールをどのように作成・管理・変更するか」のルールを定めた文書だ。スケジュール作成方針・マイルストーン計画・進捗管理プロセス・スケジュール変更管理の4つを押さえれば、英語でも問題なく整備できる。

この記事では、英語スケジュール管理計画書に必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のプロジェクト立ち上げで活用できる。

スケジュール管理計画書に必要な4つの構成要素
1. スケジュール管理計画書とWBSの違い
2. なぜ英語で書くのか
テンプレートをダウンロード（Word）
日本語版テンプレート（コピペOK）
英語版テンプレート（コピペOK）
各セクションの書き方と例文
1. RAGステータスの運用ポイント
2. 変更管理との連携
スケジュール管理計画書でよく使う英語表現
1. 進捗報告・遅延連絡フレーズ
2. マイルストーン・期日調整フレーズ
まとめ：英語スケジュール管理計画書は4つのセクションで完成する

スケジュール管理計画書に必要な4つの構成要素

スケジュール管理計画書はプロジェクトの日程を「どうやって決め・どうやって守り・遅延したらどうするか」のルールを定める文書だ。スケジュールを作るだけでなく、進捗の測り方と遅延時の対処ルールまで決めることで、計画が形骸化するのを防げる。以下の4つが実務で使いやすい構成要素になる。

スケジュール作成方針（Schedule Development Approach）
マイルストーン計画（Milestone Plan）
進捗管理プロセス（Progress Monitoring Process）
スケジュール変更管理（Schedule Change Management）

スケジュール管理計画書とWBSの違い

WBSはプロジェクトの全作業を階層的に分解し「何をするか」を定める。スケジュール管理計画書はWBSの作業を時間軸に並べ「いつ・どの順序でやるか」を管理するルールを定める。WBSで作業を定義したあと、スケジュール管理計画書でその日程と進捗管理方法を整備する順番になる。

WBSの詳しい作業分解は英語WBSの書き方でも確認してほしい。WBSで作業を分解したあと、この記事のスケジュール管理計画書テンプレートで日程と進捗管理ルールを整備すると、計画の全体像が完成する。

なぜ英語で書くのか

グローバルプロジェクトでは、スケジュール共有・進捗報告・遅延の連絡が英語で行われることが多い。英語でスケジュール管理計画書を整備することで、タイムゾーンをまたいだチームでも同じ基準で進捗を把握できる。

テンプレートをダウンロード（Word）

以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。

📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)

日本語版テンプレート（コピペOK）

基本情報

項目	内容
プロジェクト名	（例：〇〇システム開発プロジェクト）
作成者	（例：田中（PM））
作成日	（例：2026年1月10日）
バージョン	（例：v1.0）
承認者	（例：鈴木（PMO））

スケジュール作成方針

項目	内容
スケジュール管理ツール	（例：Jira / MS Project / Confluence）
スケジュール単位	スプリント（2週間）/ フェーズ（1〜3ヶ月）
作業見積もり方法	ストーリーポイント / 工数（人日）
バッファ設定	全体工数の10〜15%をバッファとして確保
クリティカルパス	要件定義 → 設計 → 開発 → テスト → リリース
スケジュール更新頻度	週次（毎週月曜日にJiraを更新）

マイルストーン計画

No.	マイルストーン	期日	担当	完了基準
M1	キックオフ完了	2026年1月15日	PM	キックオフ議事録の承認
M2	要件定義完了	2026年2月28日	PM + 開発リード	要件定義書のステークホルダー承認
M3	設計完了	2026年4月30日	テックリード	設計書のレビュー完了・承認取得
M4	開発完了	2026年8月31日	開発チーム	全機能の実装完了・単体テスト合格
M5	テスト完了	2026年10月31日	QAチーム	全テストケース合格・Critical/Highバグゼロ
M6	UAT完了	2026年11月15日	PM + ステークホルダー	ステークホルダーの受け入れ承認
M7	本番リリース	2026年11月30日	PM + インフラ	本番環境への展開完了・動作確認済み

進捗管理プロセス

管理項目	内容	担当	頻度
スプリントレビュー	スプリントの完了状況と成果物を確認する	PM + チーム全員	2週間ごと
週次ステータスレポート	進捗・課題・リスクをステークホルダーに報告する	PM	毎週金曜日
バーンダウンチャート更新	残作業量の推移をJiraで可視化する	PM	毎日
マイルストーンレビュー	マイルストーンの達成状況を確認する	PM + ステークホルダー	マイルストーン到達時
EVM（出来高管理）	スケジュール差異（SV）・コスト差異（CV）を計測する	PM	月次

進捗状況の判断基準（RAGステータス）

ステータス	意味	対応
🟢 Green	計画通りに進捗している	通常管理を継続する
🟡 Yellow	遅延リスクがある（計画比80〜99%）	PMが原因分析・対策を検討する
🔴 Red	遅延が確定している（計画比80%未満）	PMがステークホルダーにエスカレーションする

スケジュール変更管理

ステップ	内容	担当	期限
1. 遅延の検知	スプリントレビューや週次報告で遅延を検知する	PM	随時
2. 影響分析	遅延がマイルストーン・全体スケジュールに与える影響を分析する	PM + テックリード	検知後2営業日以内
3. 対策立案	スコープ削減・増員・残業・並行作業などの回復策を検討する	PM + チーム	分析後1営業日以内
4. 承認	変更内容をステークホルダーに提示し、承認を得る	PM	対策立案後3営業日以内
5. 計画更新	承認された変更をJira・ガントチャートに反映する	PM	承認後1営業日以内
6. 周知	変更後のスケジュールをチームとステークホルダーに共有する	PM	計画更新後1営業日以内

スケジュール回復戦略

戦略	内容	適用条件
ファストトラッキング	本来順番に実施する作業を並行して実施する	依存関係が低い作業がある場合
クラッシング	リソースを追加して作業期間を短縮する	予算の余裕がある場合
スコープ削減	優先度の低い機能をリリース後対応に変更する	スコープ変更の承認が得られる場合
リリース日の延期	ステークホルダーの合意のもとリリース日を延期する	品質を優先する場合

英語版テンプレート（コピペ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)

Schedule Development Approach

Item	Details
Scheduling Tool	(e.g., Jira / MS Project / Confluence)
Schedule Unit	Sprint (2 weeks) / Phase (1–3 months)
Estimation Method	Story points / Effort (person-days)
Buffer	Reserve 10–15% of total effort as buffer
Critical Path	Requirements → Design → Development → Testing → Release
Update Frequency	Weekly (update Jira every Monday)

Milestone Plan

No.	Milestone	Due Date	Owner	Completion Criteria
M1	Kickoff complete	January 15, 2026	PM	Kickoff meeting minutes approved
M2	Requirements complete	February 28, 2026	PM + Dev Lead	Requirements document approved by stakeholders
M3	Design complete	April 30, 2026	Tech Lead	Design docs reviewed and approved
M4	Development complete	August 31, 2026	Dev Team	All features implemented, unit tests passed
M5	Testing complete	October 31, 2026	QA Team	All test cases passed, zero Critical/High bugs
M6	UAT complete	November 15, 2026	PM + Stakeholders	Stakeholder acceptance sign-off obtained
M7	Production release	November 30, 2026	PM + Infra	Deployed to production and verified

Progress Monitoring Process

Activity	Description	Owner	Frequency
Sprint Review	Review sprint completion and deliverables	PM + Full team	Every 2 weeks
Weekly Status Report	Report progress, issues, and risks to stakeholders	PM	Every Friday
Burndown Chart	Visualize remaining work trend in Jira	PM	Daily
Milestone Review	Confirm milestone achievement	PM + Stakeholders	At each milestone
EVM	Measure Schedule Variance (SV) and Cost Variance (CV)	PM	Monthly

RAG Status Definitions

Status	Meaning	Action
🟢 Green	On track as planned	Continue normal management
🟡 Yellow	At risk of delay (80–99% of plan)	PM analyzes root cause and prepares mitigation
🔴 Red	Delay confirmed (below 80% of plan)	PM escalates to stakeholders

Schedule Change Management

Step	Action	Owner	Deadline
1. Detect	Identify delay via sprint review or weekly report	PM	As needed
2. Impact Analysis	Assess impact on milestones and overall schedule	PM + Tech Lead	Within 2 business days of detection
3. Recovery Plan	Evaluate options: scope reduction, additional resources, overtime, parallel work	PM + Team	Within 1 business day of analysis
4. Approval	Present changes to stakeholders and obtain approval	PM	Within 3 business days of recovery plan
5. Update Plan	Reflect approved changes in Jira and Gantt chart	PM	Within 1 business day of approval
6. Communicate	Share updated schedule with team and stakeholders	PM	Within 1 business day of plan update

Schedule Recovery Strategies

Strategy	Description	When to Apply
Fast-tracking	Run tasks in parallel that were originally sequential	When tasks have low dependency
Crashing	Add resources to shorten task duration	When budget allows
Scope reduction	Move lower-priority features to post-release	When scope change can be approved
Release date extension	Extend the release date with stakeholder agreement	When quality takes priority

各セクションの書き方と例文

テンプレートを埋めるときに悩みやすいポイントを解説する。

RAGステータスの運用ポイント

RAG（Red/Amber/Green）ステータスは週次報告でよく使われる進捗の信号機だ。Greenだから安心・Redだからダメというわけでなく、YellowやRedになったときに「なぜ・どう対処するか」をセットで報告することが重要だ。

日本語	英語
計画通りに進んでいます	We are on track.
遅延リスクがあります	There is a risk of delay.
〇〇日の遅延が見込まれます	We are expecting a delay of [X] days.
回復策を検討中です	We are working on a recovery plan.
スケジュールを更新しました	The schedule has been updated.

変更管理との連携

スケジュール遅延への対処としてスコープ削減や増員を行う場合、変更管理プロセスとの連携が必要だ。英語変更管理計画書の書き方と合わせて整備することで、スケジュール変更を正式なプロセスで承認・記録できる。

スケジュール管理計画書でよく使う英語表現

実務でよく使う英語表現を場面別にまとめた。

進捗報告・遅延連絡フレーズ

日本語	英語
〇〇フェーズは予定通りです	The [phase] is on schedule.
〇〇に遅延が発生しています	[Task/Phase] is running behind schedule.
原因は〇〇です	The root cause is [reason].
〇〇日の遅れを取り戻す予定です	We plan to recover [X] days of delay by [action].
スケジュールへの影響を確認中です	We are assessing the impact on the schedule.

マイルストーン・期日調整フレーズ

日本語	英語
M3の期日を〇〇に変更することを提案します	I propose changing the M3 deadline to 2026/07/04.
リリース日の延期をご検討いただけますか？	Could you consider extending the release date?
期日の厳守が難しい状況です	Meeting the current deadline is challenging.
最優先事項を確認させてください	Let me confirm your top priority.
スケジュールをリベースラインします	We will re-baseline the schedule.

スケジュール遅延リスクを管理するには英語リスク管理計画書の書き方のテンプレートが役立つ。確率影響マトリクスでリスクをスコアリングし、優先度の高いリスクを早期に対処することで、スケジュール遅延を未然に防げる。

スケジュール変更や遅延の報告ルートは英語コミュニケーション管理計画書の書き方と連携して整備してほしい。誰に・いつ・どの手段で報告するかを事前に定めることで、遅延情報がステークホルダーに迅速に届く体制が整う。

まとめ：英語スケジュール管理計画書は4つのセクションで完成する

英語スケジュール管理計画書に必要な構成要素を整理した。

スケジュール作成方針はツール・見積方法・バッファ・更新頻度を定め、「どうやってスケジュールを作り・維持するか」の共通ルールをプロジェクト開始前に合意する
マイルストーン計画はM1〜M7の形式で完了基準を明記し、「何が達成されたら次のフェーズに進めるか」を全員が同じ基準で判断できる状態にする
進捗管理プロセスはスプリントレビュー・週次報告・バーンダウンチャートの3点セットで進捗を可視化し、遅延を早期に発見する
スケジュール変更管理はファストトラッキング・クラッシング・スコープ削減・延期の4つの回復戦略を定義し、遅延が発生したときに「どの戦略を選ぶか」を迷わず決められるようにする

テンプレートをコピーして、まず「マイルストーン計画」から埋め始めてほしい。マイルストーンの完了基準を最初に合意することで、フェーズの境目が明確になり、進捗の議論がシンプルになる。