 |
プロジェクトが終了した時点で，プロジェクト・マネージャ（PM）は，得られたノウハウや教訓などを次のプロジェクトに役立てるため整理して記録をしておく必要がある。そのためには，プロジェクト完了報告会できちんと議論することが欠かせない。これは，プロジェクトの発足時に「キックオフ・ミーティング」を実施するのと同じぐらい重要である。
トラブル・プロジェクトの場合は，反省会として実施されることが多い。だが，プロジェクトがトラブルに陥らなかった場合は省略されがちである。それではいけない。筆者の会社では，反省会ではなく「プロジェクト完了報告会」として定義している。
そもそも計画段階で「完了（終結）プロセス」としてプロジェクト完了報告会が計画されていないプロジェクトが多いのが実態だろう。完了報告会は，プロジェクトを正式に完了させ，メンバーを解放する目的もあるが，それ以上にPMをはじめ，メンバーが得たノウハウや教訓などを，次のプロジェクトに引き継ぐための重要なプロセスである。さらに組織の行動の質を上げられるので，組織そのものをよくするという意味でも非常に重要である。
完了報告会できちんと評価する
プロジェクトで得られたノウハウや教訓・経験などを一生懸命整理しても，誰も評価してくれないようだとやる気がでない。従って，プロジェクト完了報告会を利用して，プロジェクトで苦労した点や改善点について率直に議論する時間を設けるべきである。
往々にして完了報告会は，プロジェクトチームの苦労をねぎらうだけの形式的なものになりやすい。会社の将来を考える経営層やプロジェクトの成功率を向上させる目的を持ったPMOに所属する人は，「どうしてうまくいったのか」「どうして品質が悪くなったのか」「次回のプロジェクトではこうしたらどうか」などといったことを，PMやメンバーに率直に質問するべきである。時には厳しい質問でも構わない。プロジェクトには，メンバーしか理解できない，言葉で説明し難い苦労もある。また，チーム以外の人が当該プロジェクトに対し，苦言を呈しにくい雰囲気がある。しかし，あえて苦言や質問を重ねることで，PMやメンバーはプロジェクトについて深く考える機会を得ることになる。
報告会は，図やグラフを使って見える化して報告し，参加者同士で評価しあう。それがPMやメンバーの能力向上や組織の発展につながる。多くのPMは，プロジェクトが終了する前から次のプロジェクトがアサインされていて，終わったと思ったら次のプロジェクトの開始という状況である。だからこそ，完了報告会をきちんとやって行動や気持ちを一度リセットすることも重要である。
完了報告会の終了後，親睦会（打上会）を行なうのも効果的な手段の一つである。一見仕事に関係ないように思えるが，区切りとして会を催すのは非常に良い。次のプロジェクトに向けて気持ちも切り替わり，リフレッシュにもなる。ここで集まったメンバーは，いずれ，また同じチームになるかもしれない。
失敗が責められない雰囲気作りが重要
PMであれば誰でも，失敗はしたくないものである。また，万一失敗した場合は他の人に極力知られたくないのが普通である。しかし，プロジェクトで得た経験やノウハウを次のプロジェクトで役立てるように整理しようとすると，公にせざるを得なくなる。ここで重要になってくるのが失敗を責めない風土（社風）である。実はこれが一番難しい。
失敗や出来なかったことを公表したり評価されるのを恐れるPMも多いだろう。恥ずかしいとか人に言いたくないという気持ちを払拭して積極的に公表すると，そのPMにとっても良いし，そういうPMが増えれば組織や会社もどんどん伸びるはずである。
失敗が責められない雰囲気は，プロジェクトの遂行中でも重要である。進捗管理や問題点管理でも失敗が責められる雰囲気があれば隠すからである。プロジェクトの遂行段階から失敗が責められない雰囲気作りができていれば，最後の完了報告会もあまり抵抗なく実施できるはずである。完了報告会で正直な経験や教訓などが残せなければ，誰も記録を信用しなくなり，使うこともなくなる。
定量的数値が真実を導き出す
PMやメンバーは，プロジェクト完了時に良かった点や悪かった点，改善すべき点などいくつか頭にあるはずだ。ただ，PMやメンバーが感じている問題点が，必ずしもプロジェクトの実態を表しているとは限らない。
例えば，あるプロジェクトで開発規模が増加したため，納期遅延や原価が大幅に増加したとメンバーが思っていたとしよう。この点を反省すると，開発規模の見積精度を上げようという結論になる。
だが，実際に何Kステップの予定に対して，実績が何Kステップになったのか。仕様変更や追加はあったのか。工程ごとの開発規模の推移はどうだったのか。実際に集計したり，整理したりしてみないと分からない。実は大して規模は増加していなかったことが分かる場合もある。
プロジェクト完了報告会を実施する場合は，プロジェクトの実績を数値で示した資料を作成する。プロジェクトの実績を示す数値とは，具体的には表のようなものである。
| 項目 | 単位 | 備考 |
| 開発規模 | Kステップ，FP，画面数など | 予定/実績，工程別推移 |
| 工数 | 時間，人月など | 予定/実績，工程予実績 |
| 作業期間 | xxxx年xx月xx日～xxxx年xx月xx日 | 予定/実績，工程別作業期間の予実績 |
| 不良件数 | 件 | 予定/実績，工程予実績 |
| チェックリスト件数 | 件 | 予定/実績，工程予実績 |
| ドキュメント量 | ページ数 | ドキュメント別の予実績 |
| … | … | … |
これらの数値を算出するためには，日頃からきちんと定量的にデータを残しておくことが重要である。日頃の進捗管理を定量的に把握しているプロジェクトであれば簡単に整理できるはずである。
資料に提示する数値は，プロジェクトの実態を明らかにする定量的データでなければならない。何について，どれだけ詳細にするかは，プロジェクトをどのように評価するかによって適切に定める必要がある。
また，プロジェクトを評価するには実績数値だけではなく，予定の数値も必要である。予定と実績との比較が，プロジェクト評価の基本になるからだ。筆者の会社で実際に利用しているプロジェクトの定量的数値を提示する帳票は図に示すものである。
会社の財産としてノウハウを残す仕組みを持つ
プロジェクトの経験やノウハウ・教訓が整理され次のプロジェクトで役に立つ「プロジェクト完了報告書」が完成しても，報告書を蓄積し，活用できる仕組みが会社になければ無駄になる。ここで，ポイントになるのは，誰でも報告書にアクセスできる仕組みが必要であることと，どのようなプロジェクトが蓄積されているのかが，分かりやすく整理されていることである。
筆者の会社では，プロジェクト管理システム（PMS）を構築し，キーワード検索（業種，PM，技術，開発言語など）でプロジェクト完了報告書を見られるようになっている。ただ，完了報告書にプロジェクトを成功させる答えが載っているわけではない。あくまでも参考であり，現状のプロジェクト特性やメンバー，顧客状況などに応じて最適な解を導き出すのは，PMの仕事である。
日立システムアンドサービス
プロジェクト推進部 部長
