いざ「完了報告書」を作ろうとしても，何をどうすればよいのかなかなか分からない。どのように記録を残し，どのように活用すればよいのか。事例から探った。
完了報告書を残すべきことは，PMBOKでも推奨されている。統合マネジメントの項目に，プロジェクト終結時に作成すべきアウトプットとして，次の四つが挙げられている。
- 事務終了手順
- 契約終了手順
- 最終プロダクト，サービス，所産
- 組織のプロセス資産
プロジェクトを終結させるには，これらが必要だというのである。このうち四つ目の組織のプロセス資産が，本特集でいう完了報告書に相当する。その中身は次の四つだ（図1）。
- 発注者が開発した成果物を受け入れたことを示す受け入れ文書
- プロジェクトを遂行する中で作成，利用したファイル類
- 運用部門などに業務を引き渡したことを示すプロジェクト終了文書
- 過去の情報と教訓
要は，プロジェクトをきちんと終わらせたことを文書で提示する。その上で，プロジェクトで得たノウハウを次に伝えるという考え方である。
作るのが大変な三つの理由
とはいえ，実際に試みたことのある人なら分かるだろうが，完了報告書の作成は意外に面倒な作業である。取材でも，毎回，きちんと作っている現場はそう多くはないという印象を受ける。日本ユニシスの服部克己氏（プロジェクト支援室 室長）は，その理由を三つ挙げる。
第一に手間がかかる。エンジニアの多くは，わざわざ終了したプロジェクトの後始末に費やす時間がもったいないと感じている。
第二にメリットが見えない。もちろんPart1で説明したように記録を残すメリットは多々あるのだが，そのメリットを当事者が享受できるまでラグがある。
第三に人がいない。システムが稼働すると，保守要員を除くメンバーの大半は次のプロジェクトに投入される。完了報告書を作成するタイミングでは，開発した人員の大半は散らばってしまっているのである。
完了報告書を通じてノウハウや教訓を伝えていくには，これらの問題を解消する工夫が必要である。最初から完全なものを作ろうと意気込む必要はない。できることからステップを踏めば，現場レベルで十分役に立つものができる。
ここからは「どこから手を付ければよいか分からない」「いざ記録を残すとなると大変そう」「完了報告書を作ったことはあるが何の役にも立たなかった」という課題を解決するために，有効な記録の残し方や使い方を紹介する。誰にでもできる最初の一歩（Step1～3）から，実践で役に立つ工夫（Step4～6），ここまでやれば相当なノウハウを継承できるという一応のゴール（Step7～9）までの9ステップを，事例を基に解説する。
