誰が誰に何のために報告するのか。これを意識することが報告書の内容を考えるうえで重要である。

　完了報告書を作成する役割は，プロジェクト・マネージャが担うケースが一般的である。システム開発プロジェクトでは発注側であるユーザー企業と受託側であるベンダーの双方にプロジェクト・マネージャが存在するが，どちらのプロジェクト・マネージャが誰に対して報告するのかによって完了報告書を書く目的は少々異なってくる。その報告者と報告先は下記の三つのパターンに分けることができる（図1）。

図1●報告者と報告先の関係

報告の目的が何かによって，「誰が」「誰に」報告するかが変わる

[画像のクリックで拡大表示]

A.ユーザー企業のプロジェクト・マネージャが経営者や上長に報告する

B.ベンダーのプロジェクト・マネージャがユーザー企業に報告する

C.ベンダーのプロジェクト・マネージャが自社の経営者や上長に報告する

　Aの場合の完了報告書の主な目的は，経営者や上長が決断したシステム投資に対して，担当者として説明責任を果たすということである。システム開発が終了し，そのシステムがカットオーバーしたことを報告すると同時に，「今の稼働状況がどうであるか」「プロジェクトが実際にどのように行われたのか」「プロジェクトを推進していく上で何が良かったのか悪かったのか」を報告する。

　Bの場合は受託先として契約書に記載されたシステム開発が完了し，納品も終わったことを宣言し，ユーザー企業から検収をもらうための最終報告を行うことが主な目的となる。

　Cの場合は受託案件として担当したマネージャやメンバーからの業務報告，あるいはコストやスケジュールの予実対比による案件評価の材料とすることが主な目的となる。

　完了報告書の本来あるべき姿はAである。Bはその変形で，Cは別物である。そう考える理由は，報告先の違いにある。報告先とはシステム投資を最終的に決断した人または組織である。投資判断を下した社長，役員あるいは取締役会などに対して結果責任を負ったプロジェクト・マネージャがその結果を報告するということである。

　実際には，Cのパターンで完了報告書が書かれるケースも多い。報告すべき項目そのものは大半の部分がA〜Cで共通するので，完了報告書という名称以外では呼びにくいことも事実である。ベンダーにとっても「受託したシステム開発が予定通りのコストと納期でできたのか，泥沼化して赤字プロジェクトになってしまったのか」「その原因と責任はどこにあるのか」をきちんと報告させることは重要である。

　このような観点から，ここではCも完了報告書として扱うが，報告者と報告先によって完了報告書の色合いが変わることは理解してほしい。ここからはAのユーザー側のプロジェクト・マネージャが自社の経営者や上長に報告する場合を主に想定して解説する。

完了報告書を書くタイミング

　完了報告書を作成，提出する時期については，特にこのタイミングでなければならないという縛りはない。システムの性質や，本番稼働後の状況にもよるだろう。一般的な目安としては，初期トラブルやユーザー対応などが一段落するカットオーバー1カ月後あたりがタイミングとしては最適だろう。稼働後1カ月経過してもトラブルや業務上の混乱が多数発生してとても完了報告書を書けるような状況ではないのであれば，それはプロジェクトがまだ終了していないと判断すべきである。

　また，完了報告書は納品の検収とも少なからず関係する。一般的な検収のタイミングから考えても，やはりカットオーバー後1カ月前後の時期が現実的だと考えられる。