システム開発ならではの問題
PMBOK（プロジェクトマネジメント知識体系）ガイド 第3版では，プロジェクトを「独自のプロダクト，サービス，所産を創造するために実施される有期的な業務」と定義している。かみ砕いて言えば「何かを作り出すために開始し，作り終わった時点で終了する一連の活動」となる。
ところが，多くのシステム開発プロジェクトでは，後半の「作り終わった時点で終了する」の部分がないがしろにされている。プロジェクト・マネジメントのコンサルティングを手掛けるウェッブアイの森川勇治氏（代表取締役社長）は，システム開発の場合はそれがないがしろにされやすい状況があるのだと指摘する（図1上）。
第1に，システム開発の場合，完了時点を明確にしづらい。「ビルや電気製品は完成形が目に見えるから，完成した時点でプロジェクトを完了できます。ところが，情報システムは稼働後もバグをつぶす作業が続くのが普通だし，機能の積み残しも珍しくない。どこまで作れば完成と言えるのかが不明瞭なのです」（森川氏）。その結果，だらだらとプロジェクトが続いてしまったり，なんとなく終わってしまったりする。
第2に，責任の所在が不明瞭である。プロジェクトを完了させるには，最初に掲げた目的や計画に照らしてどこまで達成できたのかを報告するというプロセスが必要だが，そのプロセスがあいまいである。システムが稼働してしまえばそれらが問われることもあまりない。「利用部門や経営層から，自然発生的に開発案件が立ち上がることもあるので，誰がプロジェクトのオーナーなのかはっきりしないケースが多いのです」（森川氏）。
第3に，開発のプロセスが自己流である。各工程でどんな作業をすべきなのか，どんなドキュメントを残すべきなのか，それらをどうマネジメントすればよいのかが，現場の裁量に任されている。プロジェクトを完了させる手順についても同様で，現場担当者にノウハウや教訓，情報を残そうという意思がなければ，稼働後にシステム以外何も残らない。
最後に，稼働後のことにあまり目が行かない。一つのプロジェクトを遂行すれば大量の情報やデータを取得できるはずなのに，そういう意識がない。例えば，見積もりがブレてしまった原因，スケジュールが遅延した理由，難しいと見られていた短期開発を成功に導いた工夫，直面したトラブルの詳細，身に付けたスキルの棚卸し…。完了時に振り返ることで，こうした“プロジェクト資産”を現場は蓄積できるはずなのである。
完了報告書を作る現場が増えてきた
プロジェクトから見えない資産を発掘し記録するのは，いわゆる「プロジェクト完了報告書」である。最近，きちんと記録を付けようという現場が増えてきた。
「2006年から完了報告書を作るようになりました」。
こう語るのは，日立ハイテクノロジーズの卜部良基氏（情報システム推進部 部長代理）。それまでも担当者レベルで記録を残すことはあったし，失敗事例から学ぶべきは学んできたが，それをルール化した。
「自社の製造部門では，以前から完了報告書に相当するドキュメントを作っていました。情報システム部門でもそういうドキュメントを整備する必要を感じていたのです」（卜部氏）。
今のところ，情報システム担当者は誰でも完了報告書を見られるようにしている。フォーマットが決められており，その内容は「システム計画書」「機能概要」「全体スケジュール」「費用・効果取りまとめ表」「反省，特記事項，参考資料」で構成する。
完了報告書作成の四つのメリット
完了報告書を作成するメリットは大きく四つ挙げられる（図1下）。いずれも先に挙げた，それがないがしろにされていることによる弊害の裏返しである。第1に，プロジェクトが完了したことの公式な宣言となる。報告書が提出された時点をもってプロジェクトは解散し，運用部門などに業務が移管される。ドキュメントを作ることでそのけじめを付けるわけである。
第2に，プロジェクトの責任者を明確化できる。報告書というからには「報告する人」と「報告を受ける人」の両者がいるはずである。あいまいになりがちなこの関係を明確にできるという効果がある。
第3に，正しいプロセスを意識できる。「後で完了報告書を作ることが分かっていれば，項目を埋めるために何と何をやればよいかということを考えやすくなる」（森川氏）。
最後に，様々なノウハウを蓄積できる。報告書に記載する情報には，「次回の見積もりに役立つ工数や金額などのデータ」「見逃しがちなリスク情報」「経験により蓄積したスキル」などいろいろある。いずれも後で見返すと，次のプロジェクト計画書を作成するときに役立つものばかりである。
