プロジェクト完了報告書の書き方とテンプレート｜振り返り項目と例文つき

プロジェクト完了報告書とは、プロジェクトの終わりに「目標に対して何ができたか」「予定と実際の差はどれだけで、理由は何か」「次に何を引き継ぐか」をまとめる文書です。 システム開発では、品質（Q）・費用（C）・納期（D）の3つを数値で示し、差の原因と次の案件への申し送りまで書くと、読んだ人がそのまま判断や計画に使えます。

この記事では、章立てと項目の一覧、Markdownのテンプレート、架空の「備品予約システム開発」で全項目を埋めた記入例を載せます。数値は Python で計算し、経営層向けの1枚要約版と詳細版の2種類を用意しました。振り返りの章は、原因分類の一覧と引き継ぎ事項の例文集として使えます。

確認環境：Ubuntu 24.04、Python 3.11.15（標準ライブラリのみ）。記入例の数値はすべて架空で、掲載したコードの実行結果と一致させています。

完了報告書の章立て早見表

読み手別に何を前に出すか

同じ内容を、1枚の要約版と詳細版の2つに分けて作ると、読み手ごとに書き直す手間が減ります。要約版は詳細版の章0を独立させたものです。

書く手順

1. 計画書から、目標・スコープ・予定の日程・予定の工数と費用を抜き出す（比べる元をそろえる）。
2. 実際の値を集める（工数の記録、費用、マイルストーンの日付、テストとバグの集計、課題管理表）。
3. 差と割合を計算する（次の節のコード）。
4. 差の大きい箇所について、原因を分類して1〜2行で書く。
5. 残作業と引き継ぎ事項に、担当と期限を付ける。
6. 最後に要約を書く。本文の数値と要約の数値が一致しているかを確かめる。

予定と実際の差・達成率・品質の数値をPythonで計算する

計算式は次のとおりです。

目標値が0の項目や、小さいほど良い項目（不具合件数、所要時間）は、割り算の達成率が意味を持たないため、「目標値以下かどうか」で達成を判定します。

# 完了報告書に載せる「予定と実際の差」と品質の数値を計算する（架空データ）
from datetime import date

# 工程別の工数（人日）: (工程, 予定, 実際)
effort = [
    ("要件定義", 40, 46),
    ("基本設計", 60, 63),
    ("詳細設計", 70, 68),
    ("実装・単体テスト", 150, 171),
    ("結合テスト", 70, 82),
    ("システムテスト・受入支援", 50, 49),
    ("管理", 40, 43),
]
print("■ 工数（人日）")
print(f"{'工程':<14}{'予定':>6}{'実際':>6}{'差':>6}{'差の割合':>9}")
tp = ta = 0
for name, plan, actual in effort:
    tp += plan; ta += actual
    print(f"{name:<14}{plan:>6}{actual:>6}{actual - plan:>+6}{(actual - plan) / plan * 100:>+8.1f}%")
print(f"{'合計':<14}{tp:>6}{ta:>6}{ta - tp:>+6}{(ta - tp) / tp * 100:>+8.1f}%")

# 期間（暦日）
plan_start, plan_end = date(2026, 4, 1), date(2026, 8, 31)
act_start, act_end = date(2026, 4, 1), date(2026, 9, 14)
pd_, ad = (plan_end - plan_start).days + 1, (act_end - act_start).days + 1
print("\n■ 期間（暦日）")
print(f"予定 {pd_}日 / 実際 {ad}日 / 差 {ad - pd_:+}日（{(ad - pd_) / pd_ * 100:+.1f}%）")

# 費用（万円）: (費目, 予定, 実際)
cost = [("人件費", 2400, 2610), ("外部委託費", 600, 600), ("環境・ライセンス費", 180, 162), ("予備費", 120, 0)]
print("\n■ 費用（万円）")
cp = ca = 0
for name, plan, actual in cost:
    cp += plan; ca += actual
    print(f"{name:<10}{plan:>6}{actual:>6}{actual - plan:>+6}")
print(f"{'合計':<10}{cp:>6}{ca:>6}{ca - cp:>+6}  予算消化率 {ca / cp * 100:.1f}%")

# 目標の達成率: (目標, 目標値, 結果, 小さいほど良いか)
goals = [("二重予約（件/月）", 0, 0, True), ("承認までの平均日数", 1.0, 0.8, True),
         ("システム経由の予約割合（%）", 90, 84, False), ("実装した機能数", 32, 31, False)]
print("\n■ 目標の達成")
for name, target, result, smaller in goals:
    ok = result <= target if smaller else result >= target
    rate = "" if smaller else f" 達成率 {result / target * 100:.1f}%"
    print(f"{name:<16} 目標 {target} / 結果 {result} → {'達成' if ok else '未達'}{rate}")

# 品質
kloc, design_pages = 24.0, 180
review_findings, it_cases, it_bugs, st_cases, st_bugs, uat_bugs, after_bugs = 126, 1250, 31, 410, 6, 3, 2
before = review_findings + it_bugs + st_bugs + uat_bugs
print("\n■ 品質")
print(f"レビュー指摘密度（設計書） {review_findings / design_pages:.2f} 件/ページ")
print(f"テスト密度（結合）        {it_cases / kloc:.1f} 件/KLOC")
print(f"バグ密度（結合）          {it_bugs / kloc:.2f} 件/KLOC")
print(f"バグ密度（システム）      {st_bugs / kloc:.2f} 件/KLOC")
print(f"受入で見つかった不具合    {uat_bugs} 件")
print(f"利用開始後2週間の不具合   {after_bugs} 件（{after_bugs / kloc:.2f} 件/KLOC）")
print(f"欠陥除去率                {before / (before + after_bugs) * 100:.1f}%")

実行結果です。

■ 工数（人日）
工程                予定    実際     差     差の割合
要件定義              40    46    +6   +15.0%
基本設計              60    63    +3    +5.0%
詳細設計              70    68    -2    -2.9%
実装・単体テスト         150   171   +21   +14.0%
結合テスト             70    82   +12   +17.1%
システムテスト・受入支援      50    49    -1    -2.0%
管理                40    43    +3    +7.5%
合計               480   522   +42    +8.8%

■ 期間（暦日）
予定 153日 / 実際 167日 / 差 +14日（+9.2%）

■ 費用（万円）
人件費         2400  2610  +210
外部委託費        600   600    +0
環境・ライセンス費    180   162   -18
予備費          120     0  -120
合計          3300  3372   +72  予算消化率 102.2%

■ 目標の達成
二重予約（件/月）        目標 0 / 結果 0 → 達成
承認までの平均日数        目標 1.0 / 結果 0.8 → 達成
システム経由の予約割合（%）   目標 90 / 結果 84 → 未達 達成率 93.3%
実装した機能数          目標 32 / 結果 31 → 未達 達成率 96.9%

■ 品質
レビュー指摘密度（設計書） 0.70 件/ページ
テスト密度（結合）        52.1 件/KLOC
バグ密度（結合）          1.29 件/KLOC
バグ密度（システム）      0.25 件/KLOC
受入で見つかった不具合    3 件
利用開始後2週間の不具合   2 件（0.08 件/KLOC）
欠陥除去率                98.8%

この数値を、次の記入例の表にそのまま使います。

テンプレート1：経営層向け1枚要約版

# ○○プロジェクト 完了報告（要約）

- 報告日：YYYY-MM-DD　報告者：
- 結論：（完了／一部を残して完了／中止）。（1文で理由）

## 結果
| 観点 | 目標・予定 | 結果 | 差 | 評価 |
|---|---|---|---|---|
| 目的の達成 | | | | |
| 品質 | | | | |
| 費用 | | | | |
| 納期 | | | | |

## 差の主な理由（上位3つ）
1.
2.
3.

## 残った事項
| 内容 | 担当 | 期限 |
|---|---|---|

## 次に活かすこと（3つまで）
-

## ご判断いただきたいこと
-

記入例（1枚要約版）

# 備品予約システム開発 完了報告（要約）

- 報告日：2026-10-02　報告者：PM 鈴木
- 結論：一部を残して完了。9/14に利用を開始し、成功の基準3つのうち2つを達成。残る1機能は10/30に提供する。

## 結果
| 観点 | 目標・予定 | 結果 | 差 | 評価 |
|---|---|---|---|---|
| 目的の達成 | 二重予約 月0件、承認まで平均1.0日以内、システム経由の予約90% | 0件、0.8日、84% | 経由割合 −6ポイント | 3項目中2項目を達成 |
| 品質 | 利用開始後の重大な不具合 0件 | 重大0件（軽微2件、対応済み） | なし | 達成 |
| 費用 | 3,300万円 | 3,372万円 | +72万円（予算消化率102.2%） | 予備費を使い切り、72万円超過 |
| 納期 | 8/31 利用開始 | 9/14 利用開始 | +14日（+9.2%） | 2週間の延伸 |

## 差の主な理由（上位3つ）
1. 承認の流れに関する要件が実装中に2件追加され、実装と結合テストの工数が増えた（+33人日）。
2. 備品台帳の初期データの受領が2週間遅れ、結合テストの開始が後ろにずれた。
3. 拠点の利用者への案内が利用開始の直前になり、システム経由の予約割合が84%にとどまった。

## 残った事項
| 内容 | 担当 | 期限 |
|---|---|---|
| 利用状況の集計のCSV出力（1機能） | PL 田中 | 10/30 |
| 利用者向け説明会（2回目） | 総務 佐藤 | 10/20 |

## 次に活かすこと（3つまで）
- 承認の流れは要件定義で画面の試作を見せて確定する。
- 発注側に依頼するデータは、キックオフで期限を決め、2週間前に状況を確認する。
- 利用者への案内は利用開始の1か月前に始める。

## ご判断いただきたいこと
- 超過分72万円の扱い（追加要件2件に対応した費用として処理する案）

テンプレート2：詳細版（Markdown全文）

# ○○プロジェクト 完了報告書

| 項目 | 内容 |
|---|---|
| 文書番号・版数 | |
| 報告日 | |
| 報告者 | |
| 承認者 | |

## 0. 要約
（1枚要約版の内容を置く）

## 1. 概要
- 目的：
- 期間：（予定）YYYY-MM-DD〜YYYY-MM-DD ／（実際）YYYY-MM-DD〜YYYY-MM-DD
- 体制：
- 対象範囲：

## 2. 目標と結果
| 成功の基準 | 目標値 | 結果 | 達成 | 補足 |
|---|---|---|---|---|

## 3. スコープと成果物
### 3.1 機能の完了状況
| 分類 | 予定 | 完了 | 残り | 補足 |
|---|---|---|---|---|

### 3.2 成果物
| 成果物 | 状況 | 保管場所 |
|---|---|---|

### 3.3 変更の一覧
| No | 内容 | 依頼日 | 影響（工数・日程） | 対応 |
|---|---|---|---|---|

## 4. スケジュール
| マイルストーン | 予定日 | 実際の日 | 差（日） | 理由 |
|---|---|---|---|---|

## 5. 工数と費用
### 5.1 工程別の工数（人日）
| 工程 | 予定 | 実際 | 差 | 差の割合 | 理由 |
|---|---|---|---|---|---|

### 5.2 費用（万円）
| 費目 | 予定 | 実際 | 差 | 理由 |
|---|---|---|---|---|

## 6. 品質
| 指標 | 計画時の目安 | 結果 | 評価 |
|---|---|---|---|

- 利用開始後の不具合：
- 既知の不具合と回避方法：

## 7. リスクと課題
### 7.1 発生したリスクと対応
| リスク | 計画時の備え | 起きたこと | 対応と結果 |
|---|---|---|---|

### 7.2 課題の件数
| 起票 | 完了 | 未完了 | 未完了の引き継ぎ先 |
|---|---|---|---|

## 8. 振り返り
### 8.1 うまくいった点
| 内容 | 効いた理由 | 次も続けること |
|---|---|---|

### 8.2 うまくいかなかった点
| 内容 | 原因分類 | 原因 | 次に行うこと |
|---|---|---|---|

## 9. 引き継ぎと残作業
### 9.1 残作業
| 内容 | 担当 | 期限 |
|---|---|---|

### 9.2 運用への引き継ぎ
| 項目 | 引き継ぎ先 | 資料 | 完了日 |
|---|---|---|---|

### 9.3 次の案件への申し送り
-

## 10. 添付
- 計画書、成果物一覧、テスト結果報告、課題管理表、変更管理表の場所

記入例（詳細版）：備品予約システム開発

章0は上の1枚要約版と同じ内容のため、章1から示します。

## 1. 概要
- 目的：共用備品の予約・承認・貸出・返却を1つのシステムで扱い、二重予約と確認作業を減らす。
- 期間：（予定）2026-04-01〜2026-08-31（153日）／（実際）2026-04-01〜2026-09-14（167日）
- 体制：責任者 総務部長、PM 鈴木、PL 田中、開発4名、利用部門窓口 佐藤
- 対象範囲：本社の共用備品 約200点。拠点の備品と購入申請は対象外。

## 2. 目標と結果
| 成功の基準 | 目標値 | 結果 | 達成 | 補足 |
|---|---|---|---|---|
| 二重予約 | 月0件 | 0件 | 達成 | 利用開始後2週間の集計 |
| 承認までの平均日数 | 1.0日以内 | 0.8日 | 達成 | 承認依頼の通知が効いた |
| システム経由の予約割合 | 90% | 84% | 未達（達成率93.3%） | 拠点の利用者への案内が直前になった |

## 3. スコープと成果物
### 3.1 機能の完了状況
| 分類 | 予定 | 完了 | 残り | 補足 |
|---|---|---|---|---|
| 予約・検索 | 12 | 12 | 0 | |
| 承認 | 8 | 8 | 0 | 追加要件2件を含めて完了 |
| 貸出・返却 | 7 | 7 | 0 | |
| 集計・出力 | 5 | 4 | 1 | CSV出力を10/30に提供 |
| 合計 | 32 | 31 | 1 | 完了率96.9% |

### 3.2 成果物
| 成果物 | 状況 | 保管場所 |
|---|---|---|
| 要件定義書、基本設計書、詳細設計書 | 最終版を登録済み | 共有フォルダ 20_設計 |
| テスト結果報告書 | 登録済み | 共有フォルダ 40_テスト |
| 操作手引き、運用手順書 | 登録済み | 共有フォルダ 50_運用 |

### 3.3 変更の一覧
| No | 内容 | 依頼日 | 影響（工数・日程） | 対応 |
|---|---|---|---|---|
| 1 | 承認者が不在のときの代理承認 | 6/10 | +18人日 | 実施 |
| 2 | 高額備品の2段階承認 | 6/24 | +15人日 | 実施 |
| 3 | 集計のグラフ表示 | 7/8 | +10人日 | 次期に見送り |

## 4. スケジュール
| マイルストーン | 予定日 | 実際の日 | 差（日） | 理由 |
|---|---|---|---|---|
| 要件確定 | 4/30 | 5/8 | +8 | 承認の流れの確認に時間を要した |
| 基本設計完了 | 5/29 | 6/5 | +7 | 要件確定の遅れを引き継いだ |
| 実装完了 | 7/17 | 7/29 | +12 | 追加要件2件に対応 |
| 結合テスト完了 | 8/7 | 8/24 | +17 | 初期データの受領が2週間遅れた |
| 受入完了 | 8/26 | 9/9 | +14 | 上流の遅れを引き継いだ（期間は3日短縮） |
| 利用開始 | 8/31 | 9/14 | +14 | 同上 |

## 5. 工数と費用
### 5.1 工程別の工数（人日）
| 工程 | 予定 | 実際 | 差 | 差の割合 | 理由 |
|---|---|---|---|---|---|
| 要件定義 | 40 | 46 | +6 | +15.0% | 承認の流れの確認会を2回追加 |
| 基本設計 | 60 | 63 | +3 | +5.0% | |
| 詳細設計 | 70 | 68 | −2 | −2.9% | |
| 実装・単体テスト | 150 | 171 | +21 | +14.0% | 追加要件2件 |
| 結合テスト | 70 | 82 | +12 | +17.1% | 追加要件分のテストと、データ待ちによる再実施 |
| システムテスト・受入支援 | 50 | 49 | −1 | −2.0% | |
| 管理 | 40 | 43 | +3 | +7.5% | 期間の延伸分 |
| 合計 | 480 | 522 | +42 | +8.8% | |

### 5.2 費用（万円）
| 費目 | 予定 | 実際 | 差 | 理由 |
|---|---|---|---|---|
| 人件費 | 2,400 | 2,610 | +210 | 工数 +42人日 |
| 外部委託費 | 600 | 600 | 0 | |
| 環境・ライセンス費 | 180 | 162 | −18 | 検証環境を1台減らした |
| 予備費 | 120 | 0 | −120 | 人件費の超過に充当 |
| 合計 | 3,300 | 3,372 | +72 | 予算消化率102.2% |

## 6. 品質
| 指標 | 計画時の目安 | 結果 | 評価 |
|---|---|---|---|
| レビュー指摘密度（設計書） | 0.5〜1.0 件/ページ | 0.70 件/ページ | 目安の範囲内 |
| テスト密度（結合） | 40〜60 件/KLOC | 52.1 件/KLOC | 目安の範囲内 |
| バグ密度（結合） | 0.8〜1.6 件/KLOC | 1.29 件/KLOC | 目安の範囲内 |
| バグ密度（システム） | 0.5 件/KLOC 以下 | 0.25 件/KLOC | 目安の範囲内 |
| 受入で見つかった不具合 | 5件以下 | 3件 | すべて修正済み |
| 欠陥除去率 | 95%以上 | 98.8% | 達成 |

- 利用開始後の不具合：2件（軽微。表示の文言1件、並び順1件。いずれも対応済み）
- 既知の不具合と回避方法：なし

## 7. リスクと課題
### 7.1 発生したリスクと対応
| リスク | 計画時の備え | 起きたこと | 対応と結果 |
|---|---|---|---|
| 要件の追加 | 変更依頼票で受け付け、影響を見積もる | 3件の依頼 | 2件を実施、1件を次期に見送り。+33人日 |
| 初期データの遅れ | 期限を10日前に再確認する | 受領が2週間遅れ | 仮データで先行してテスト。結合テスト完了が17日遅れ |
| 担当者の交代 | 設計書と手順書を都度更新 | 7月に開発1名が交代 | 引き継ぎ5日で復帰。影響は小さかった |

### 7.2 課題の件数
| 起票 | 完了 | 未完了 | 未完了の引き継ぎ先 |
|---|---|---|---|
| 47 | 45 | 2 | 運用担当（1件）、次期開発（1件） |

## 8. 振り返り
### 8.1 うまくいった点
| 内容 | 効いた理由 | 次も続けること |
|---|---|---|
| 承認依頼の通知で承認までの日数が0.8日になった | 要件定義で利用者の1日の動きを聞き取った | 業務の流れの聞き取りを要件定義の最初に行う |
| 利用開始後の重大な不具合が0件 | 設計レビューで観点表を使い、指摘を全件修正した | 観点表を使ったレビュー |
| 担当交代の影響が小さかった | 手順書を作業のたびに更新していた | 手順書の都度更新 |

### 8.2 うまくいかなかった点
| 内容 | 原因分類 | 原因 | 次に行うこと |
|---|---|---|---|
| 実装中に承認の要件が2件追加 | 要件 | 例外の流れ（不在、高額）を要件定義で確認しきれなかった | 画面の試作で例外の流れを確認する |
| 結合テストが17日遅れ | 外部依存 | データ提供の期限が口頭の約束だった | キックオフで期限を決め議事録に残す |
| システム経由の割合が84% | 展開 | 拠点への案内が直前になった | 案内の計画を全体スケジュールに入れる |

## 9. 引き継ぎと残作業
### 9.1 残作業
| 内容 | 担当 | 期限 |
|---|---|---|
| 集計のCSV出力 | PL 田中 | 10/30 |
| 利用者向け説明会（2回目） | 総務 佐藤 | 10/20 |

### 9.2 運用への引き継ぎ
| 項目 | 引き継ぎ先 | 資料 | 完了日 |
|---|---|---|---|
| 日次の確認作業、問い合わせ対応 | 運用担当 高橋 | 運用手順書 v1.2 | 9/11 |
| 備品台帳の更新方法 | 総務 佐藤 | 操作手引き 4章 | 9/11 |
| 未完了の課題2件 | 運用担当 高橋 | 課題管理表 No.31、No.44 | 9/30 |

### 9.3 次の案件への申し送り
- 承認の流れを含む開発では、要件定義の工数を今回の比率（全体の8.8%）より多めに見積もる。
- 発注側に依頼するデータは、提供の期限と形式をキックオフで合意する。
- 集計のグラフ表示（見送り分、+10人日の見積もり）は次期開発の候補とする。

要件定義の比率8.8%は、実際の工数46人日 ÷ 合計522人日で求めた値です。

振り返りの原因分類一覧

うまくいかなかった点は、出来事をそのまま書くだけでは次に使いにくくなります。原因を分類して書くと、複数の案件を並べたときに傾向が見えます。 人の名前ではなく、仕組みや手順に目を向けて分類します。

タブ区切り版です。

分類  内容  次に行うことの例
要件  要件の漏れ、あいまいさ、後からの追加  試作や業務の流れ図で早めに確認する
見積もり    規模や難しさの見込み違い    類似案件の値と比べ、根拠を残す
計画  作業の漏れ、依存関係の見落とし 作業の洗い出しをチームで行う
設計  方式の選び直し、設計の手戻り  早い段階で小さく試す
技術  初めて使う技術や製品の習得   習得の時間を計画に入れる
品質  レビューやテストの観点の偏り  観点表を見直し、レビューの時間を確保する
体制  人数、スキルの組み合わせ、交代 役割を分け、手順を文書にする
コミュニケーション   認識のずれ、連絡の遅れ 決定事項を議事録に残し翌日に共有する
外部依存    他部門・他社・他システムの都合 期限を合意し、事前に状況を確認する
環境・ツール  開発環境、テスト環境、ツールの準備   環境の準備を最初のマイルストーンにする
変更管理    変更の受け付けと影響の判断   変更依頼票と影響の見積もりを必ず通す
展開  利用者への案内、教育、移行   案内と説明会を全体スケジュールに入れる

次の案件への引き継ぎ事項の例文集

申し送りは、「どんな場面で」「何をするか」「根拠となる今回の数値」の3点を入れると、読んだ人がそのまま計画に使えます。

分野別の例文

見積もり・計画

• 要件定義の工数は、今回の結果（全体の8.8%）を下限の目安とし、承認や権限を含む場合は上乗せする。
• 結合テストの開始条件に「初期データの受領」を入れ、マイルストーンとして管理する。
• 追加要件に備え、予備費は人件費の5%以上を確保する。今回は120万円（5%）を使い切った。
• 利用者への案内と説明会を、開発の作業と同じスケジュール表に載せる。

要件・設計

• 承認の流れは、通常の流れに加えて、不在・差し戻し・取り消しの3つを要件定義の確認項目に入れる。
• 集計や出力の機能は、利用者が実際に使っている帳票を集めてから項目を決める。
• 他システムと連携する項目は、基本設計の完了前に相手側の担当者とレビューを行う。

品質

• 設計レビューは観点表を使い、指摘は工程の完了前に全件修正する。今回の指摘密度は0.70件/ページだった。
• 受入テストの前に、利用部門の担当者と操作の確認会を1回行う。受入で見つかった3件はいずれも画面の文言と並び順だった。
• バグの原因工程を記録し、設計起因の割合を次の案件のレビュー計画に使う。

体制・コミュニケーション

• 手順書は作業のたびに更新する。今回は担当交代の引き継ぎが5日で済んだ。
• 決定事項は会議の翌営業日までに議事録で共有し、口頭の合意だけで作業を始めない。
• 発注側の窓口と承認者を1人ずつ決め、不在時の代理も決めておく。

変更管理

• 変更の依頼は変更依頼票で受け付け、工数と日程への影響を見積もってから実施を決める。今回は3件中2件を実施、1件を次期に見送った。
• 見送った要望は一覧に残し、次期開発の候補として引き継ぐ。

運用・展開

• 利用開始の1か月前に、利用者向けの案内を始める。
• 利用開始後2週間は、問い合わせの内容を日次で集計し、手引きに反映する。
• 運用担当への引き継ぎは、利用開始の1週間前までに手順書の読み合わせで行う。

書くときのポイント

よくある質問

Q. 完了報告書はいつ書きますか？ A. 利用開始または納品から2週間〜1か月以内が書きやすい時期です。記憶が新しく、利用開始直後の不具合や利用状況の数値も入れられます。数値の収集は、工程が終わるたびに進めておくと最後の負担が小さくなります。

Q. 予定を超えた項目はどう書けばよいですか？ A. 差の大きさ（数値と割合）、原因分類、原因、次に行うことの4点を表で書きます。事実と数値で書くと、次の見積もりの材料として受け取ってもらえます。

Q. 完了報告書と振り返りの会の記録は別に作りますか？ A. 別にするのが扱いやすい方法です。振り返りの会ではチームで出た意見を広く記録し、完了報告書にはそこから原因分類と申し送りに絞ったものを載せます。

Q. 小さな案件でも詳細版が必要ですか？ A. 1枚要約版だけで十分な場合が多くあります。目安として、期間が1か月以内で数名の案件は要約版、複数の部門が関わる案件や次期開発が控えている案件は詳細版まで作ります。

まとめ

• 完了報告書は目標に対する結果、予定と実際の差と理由、引き継ぎの3つを書く。
• 品質・費用・納期を数値で示す。差は「実際 − 予定」と割合の両方を書く。
• 1枚要約版と詳細版の2種類を作ると、読み手ごとの書き直しが減る。
• 目標値が0の項目や小さいほど良い項目は、達成率ではなく目標値以下かどうかで判定する。
• うまくいかなかった点は原因分類を付け、仕組みと手順の話として書く。
• 申し送りは場面・行うこと・今回の数値の3点を入れる。
• 残作業と引き継ぎには担当と期限を必ず付ける。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。