プロジェクトマネジメントガイド · リスク、品質、コントロール
プロジェクト状況報告書：テンプレート、例、書き方のコツ
プロジェクトのステータスレポートとは、プロジェクトが計画に対してどう進んでいるか、何が完了し、次に何が来るか、どのリスク、課題、意思決定に注意が必要かをステークホルダーに伝える、定期的で短い報告です。その役割は、活動を記録するだけでなく、意思決定を支えることです。
要点
- ステータスレポートは、活動を羅列するだけでなく、意思決定を支えるものであるべきです。
- 赤・黄・緑の評価基準は事前に定義し、必ず言葉で説明を添えましょう。
- 短く、一貫性があり、最新のデータに基づくものにしましょう。
- 必要な意思決定は、読み手の目に留まる場所に置きましょう。
優れたステータスレポートの役割
- 全体のステータスを一目でわかるよう正直に示す。
- マイルストーン、予算、スコープについて、進捗を計画と比較する。
- 今重要な、少数のリスクと課題を強調する。
- 必要な意思決定や支援を明確に依頼する。
- 傾向が見えるよう、期間ごとに一貫した形式にする。
ステータスレポートテンプレートの構成
| セクション | 記載すべき内容 |
|---|---|
| ヘッダー | プロジェクト名、報告期間、作成者、スポンサー、日付 |
| 全体のステータス | 赤・黄・緑の評価と1行の理由 |
| 概要 | 2〜4文で：現在の状況と最も重要なこと |
| スケジュール | 主要な マイルストーン：予定日、予測日、ステータス |
| 予算 | 予算、現時点までの実績、完了時の予測、差異。参考： アーンドバリューマネジメント |
| スコープ | 今期に承認された変更。参考： 変更管理 |
| 今期の成果 | 完了した項目を3〜5件、成果物とひも付けて |
| 次期の予定 | 主な活動を3〜5件 |
| 主なリスクと課題 | 次から上位3〜5件： RAIDログ（担当者とアクション付き） |
| 必要な意思決定や支援 | 何を、誰から、いつまでに |
赤・黄・緑のステータスの定義
評価がその時の気分に左右されず一貫するよう、最初の報告の前に各色の意味を定義しましょう。
| ステータス | 意味 | しきい値の例 |
|---|---|---|
| 緑 | 軌道に乗っている。ガバナンス側の対応は不要 | 時間、コスト、スコープが許容値の範囲内 |
| 黄 | リスクあり。チームに挽回計画がある、またはまもなく対応が必要 | 許容値の半分以上を使う予測、または重大なリスクが未解決 |
| 赤 | 軌道から外れている。許容値の範囲外、または介入しなければ範囲外になる | 予測が許容値を超えている。スポンサーまたは委員会の意思決定が必要 |
例：週次のステータスレポート
プロジェクト： 顧客ポータル。 期間： 3月14日までの週。 全体：黄 - 構築は順調だが、決済連携のテストが止まっている。
| 領域 | ステータス | 詳細度 |
|---|---|---|
| スケジュール | 黄 | UAT開始の予測は3月28日（予定は3月21日） |
| 予算 | 緑 | £480kのうち£212kを支出、予測は£470k |
| スコープ | 緑 | CR-05（ブランドカラー）承認済み、影響なし |
| 今週完了したこと | - | アカウントページ完成、請求書ダウンロードのテスト完了 |
| 来週 | - | パスワードリセットを完成させ、性能テストを開始する |
| 主な課題 | 黄 | I-007：決済サンドボックスのエラー。サプライヤーによる修正は3月18日予定 |
| 必要な意思決定 | - | スポンサーが3月17日までに、UATを1週間後ろ倒しすることを承認する |
作成の手順
- 対象者、頻度、形式は次で合意する： コミュニケーション計画.
- レポートが最新のデータに基づくよう、先にスケジュール、予算、RAIDログを更新する。
- 合意した定義に基づいて、全体の赤・黄・緑の評価を決める。
- 概要は、全体の流れがわかってから最後に書きましょう。
- 可能な限り1ページまたは1画面に収め、詳細はリンクで示しましょう。
- 決まった曜日と時間に送り、依頼した意思決定をフォローアップしましょう。
よくある間違い
- 「スイカ」報告：外側は緑、中身は赤。
- マイルストーンに対する進捗ではなく、活動を羅列すること。
- 意思決定の依頼を一番下に埋もれさせること。
- 重要な少数ではなく、すべてのリスクを載せること。
- 毎回形式を変えて、傾向を比較できなくすること。
このトピックの無料テンプレート
よくある質問
プロジェクトのステータスレポートとは何ですか？
計画に対するプロジェクトの進捗についての定期的な報告で、スケジュール、予算、スコープ、リスク、課題、必要な意思決定を扱います。
プロジェクトのステータスレポートには何を含めるべきですか？
全体のステータス、短い概要、マイルストーン、予算、スコープの変更、成果、次のステップ、主なリスクと課題、必要な意思決定です。
プロジェクトのステータスレポートはどのくらいの頻度で送るべきですか？
進行中のプロジェクトでは毎週が一般的です。より長期で安定したプロジェクトや上級の対象者には、隔週や毎月が適している場合もあります。
ステータスレポートにおける赤・黄・緑のステータスとは何を意味しますか？
赤・黄・緑：プロジェクトやある領域が軌道から外れているか、リスクがあるか、軌道に乗っているかを示すシンプルな評価です。
プロジェクトのステータスレポートはどのくらいの長さにすべきですか？
理想的には1ページまたは1画面に収め、詳細はリンクで示します。
プロジェクトのステータスレポートは誰が作成しますか？
プロジェクトマネージャーが、チームからの情報とプロジェクトの各種ログをもとに作成します。
ステータスレポートにおける「スイカ」プロジェクトとは何ですか？
実態は赤なのに緑として報告されているプロジェクトのことです。通常、赤・黄・緑の定義があいまいだったり、悪い知らせを共有したがらなかったりすることから生じます。
ステータスレポートと進捗報告書の違いは何ですか？
これらの用語は区別なく使われることがよくあります。チーム向けの詳細な報告を「進捗報告書」、スポンサー向けの要約を「ステータスレポート」と呼び分ける組織もあります。
ハイライト報告書はプロジェクトのステータスレポートと同じですか？
PRINCE2での呼び名で、プロジェクトマネージャーがステージの進捗についてプロジェクト委員会に送る定期的なステータスレポートのことです。
例外報告書はステータスレポートとどう違いますか？
ステータスレポートは定期的に送られます。例外報告書は、予測が合意した許容値を超える場合にのみ作成され、委員会に向けて選択肢と推奨案を示します。
プロジェクト管理ソフトウェアでプロジェクトのステータスレポートを作成できますか？
はい。多くの プロジェクト管理ツール がダッシュボードやステータス更新の機能を備えていますが、プロジェクトマネージャーによる短い文章のまとめにも依然として価値があります。