LESSON 30分

進捗報告書の書き方

ストーリー

「来週のステークホルダーミーティングに向けて、 進捗報告書を作ってほしい」

渡辺マネージャーの依頼に、あなたは戸惑った。

「進捗報告書......何を書けばいいですか？」

「いい質問だ。報告書は『相手が判断できる情報』を 構造化して書くものだ。テンプレートを教えよう」

進捗報告書の目的

進捗報告書は、プロジェクトの現在地と今後の見通しを関係者に伝えるドキュメントです。

読み手が知りたいこと

読み手知りたいこと
マネージャースケジュール通りか？リスクは？判断が必要な事項は？
プロダクトオーナー要件通りに進んでいるか？リリースはいつ？
他チーム依存関係に影響はないか？自チームへの影響は？
経営層ビジネス目標の達成に向けて順調か？

週次進捗報告テンプレート

基本構成

markdown
# 週次進捗報告 - [プロジェクト名]
日付: YYYY/MM/DD
報告者: [名前]
対象期間: MM/DD〜MM/DD

## サマリー
全体ステータス: [順調 / 注意 / 要対応]  ← 信号機で表現
今週の一言: [1文で全体状況を伝える]

## 進捗状況

### 完了したタスク
- [タスク名] (PR #xxx)
- [タスク名] (PR #xxx)

### 進行中のタスク
| タスク | 進捗 | 予定完了日 | 備考 |
|--------|------|-----------|------|
| [名前] | 80%  | MM/DD     | 順調 |
| [名前] | 40%  | MM/DD     | 遅延リスクあり |

### 来週の予定
- [タスク名] に着手
- [タスク名] の完了

## リスク・課題
| リスク/課題 | 影響 | 対策 | 期限 |
|------------|------|------|------|
| [内容]     | [影響]| [対策]| MM/DD|

## 判断が必要な事項
- [判断事項の説明と選択肢]

## メトリクス
- スプリントバーンダウン: XX SP / 30 SP 完了
- バグ件数: X件（先週比 +Y件）

信号機ステータスの基準

全体の状況を一目で把握できるように、信号機（Green/Yellow/Red）で表現します。

ステータス基準アクション
順調（Green）スケジュール通り。重大なリスクなし通常運転。定期報告のみ
注意（Yellow）軽微な遅延、またはリスクが顕在化しつつある対策を講じている旨を報告。注視が必要
要対応（Red）重大な遅延、ブロッカー、スコープ変更が必要即座にエスカレーション。判断を仰ぐ

判断に迷うケース

Q: 1日遅延しているが、来週挽回可能。GreenかYellowか？

A: Yellowにする。

理由:
  - 遅延の事実は報告すべき
  - 「挽回可能」は見込みであって確定ではない
  - Yellowで報告し、挽回できたらGreenに戻す方が信頼される
  - Greenと報告して結局遅延する方が信頼を失う

バーンダウンチャートの読み方と活用

バーンダウンチャートの見方

残SP
 30 │●
    │  ●
 25 │    ●
    │      ● ← 理想線
 20 │        ●
    │    ○     ● ← 実績線が理想線より上 = 遅れ気味
 15 │      ○     ●
    │        ○     ●
 10 │          ○     ●
    │            ○     ●
  5 │              ○
    │                ○
  0 │──────────────────→ 日
    月  火  水  木  金

バーンダウンから読み取れること

パターン意味対応
実績が理想線の下順調（予定より早い）そのまま継続
実績が理想線の上遅れ気味原因を分析し、対策を報告
実績が横ばいブロッカーが発生している即座にブロッカーを報告・解消
急激に下がる大きなタスクが一度に完了見積もりの粒度を見直す

報告書の書き方のコツ

1. 数値で語る

悪い例: 「テストはだいたい書けています」
良い例: 「テストカバレッジ: 75%（目標80%、先週比+10%）」

悪い例: 「パフォーマンスが改善しました」
良い例: 「APIレスポンスタイム: 平均200ms（改善前: 500ms、60%改善）」

2. 事実と推測を分ける

悪い例: 「テストが不十分なので品質が心配です」

良い例: 「テストカバレッジは60%です（事実）。
        カバレッジ80%未満の場合、リリース後のバグ率が
        2倍になる傾向があります（過去データ）。
        リリース前に80%への引き上げを推奨します（提案）」

3. 「So What?（だから何？）」を意識する

報告には必ず「次にどうするか」「何を判断してほしいか」を含めます。

悪い例: 「外部APIの仕様が変更されました」
       → だから何？ 影響は？ 対応は？

良い例: 「外部APIの仕様変更により、決済処理の修正が必要です。
        修正に3日かかるため、リリース日を3日後ろ倒しにするか、
        決済機能を次リリースに延期するか、判断をお願いします」

日報の書き方

毎日の日報は、進捗報告書の元データになります。

日報テンプレート

markdown
# 日報 - YYYY/MM/DD

## 今日やったこと
- [タスク名]: [具体的な成果] (PR #xxx)
- [タスク名]: [具体的な成果]

## 明日やること
- [タスク名]: [具体的な計画]

## 学んだこと / 気づき
- [技術的な学び、プロセスの改善案など]

## 困っていること
- [ブロッカーや相談したいこと]（なければ「なし」）

まとめ

ポイント内容
進捗報告の目的相手が判断できる情報を構造化して伝える
テンプレートサマリー、進捗状況、リスク、判断事項、メトリクス
信号機ステータスGreen/Yellow/Redで全体状況を一目で伝える
バーンダウン理想線と実績線の差から状況を読み取る
書き方のコツ数値で語る、事実と推測を分ける、So What を意識

チェックリスト

  • 週次進捗報告のテンプレートを使える
  • 信号機ステータスの判断基準を理解した
  • バーンダウンチャートの読み方を知っている
  • 数値・事実・提案を含む報告が書ける

次のステップへ

次のセクションでは、最も難しい報告のひとつ「悪いニュースの伝え方」を学びます。遅延、障害、ミスをどう報告すれば、信頼を失わずに済むかを身につけましょう。

推定読了時間: 30分