 |
プロジェクト完了報告会は，通常「反省会」などと呼ばれ実施されることが多い。反省会と言うと「反省しなくては」となってしまい，一生懸命に失敗した点を探し出すプロジェクト・マネージャ（PM）がいる。そのため，筆者の会社では，反省会ではなく「プロジェクト完了報告会」とした。
完了報告会では，成功した点と失敗した点の両面から振り返ることが重要である。成功した原因については「PMやメンバーが持っている知識や経験に基づき成功したのか」「プロセスや仕組みなどに工夫をしたから成功したのか」「何か偶発的なことで成功したのか」「偶発的であれば，実際に何が良かったのか」を振り返る必要がある。そして，成功した要因のプロセスや仕組みを共有・文書化・蓄積し，次のプロジェクトに生かしていく必要がある。
一方，失敗した原因については，どうしても失敗したプロセスに携わった「人」にフォーカスされがちである。人にフォーカスすると誰かを責めるだけで，何の経験や教訓も残らない。失敗も成功と同様に，原因を追究し，二度と同じ失敗を起こさないようにすることが必要である。ここで重要なのは，失敗した原因を追究し，同じ原因が発生しないようにすることである。
世の中には，同じ失敗を繰り返すPMがいる。本人は違うことで失敗したと思い込んでいるが，第三者からみるとプロセスは違っても，原因は同じであることが多い。よって，同じ失敗となる。では，そのPMは無能なのか。必ずしもそうではない。きちんとした反省（振り返り）が行われず，その結果失敗が教訓として生かされていない場合が多いだけだ。
反省だけなら猿でもできる
一昔前にテレビに反省する猿が出てきて，茶の間をにぎやかしてくれた。そこから「反省だけなら猿でもできる」という言葉が生まれた。この猿と同じような光景を見かけることはないだろうか。
PMO（プロジェクト・マネジメント・オフィス）の立場で筆者が，トラブル・プロジェクト（不採算・納期遅延など）の完了報告会に参加すると，会社幹部や他部門からの指摘に「申し訳ありません」「反省しています」など機械的に反省の弁を述べるPMがいる。これだけでは処世のための安全弁にはなっても，再発防止の観点からみると，全く役に立っていない。
また「このプロジェクトは非常に難しいプロジェクトであった」あるいは「顧客の仕様変更や要求が厳しくて，不採算プロジェクトになってしまったのは仕方がなかった」というような顔をして，何の反省も感じられないプロジェクト完了報告会も見かける。
プロジェクトが失敗に終わったのであれば，失敗した原因を追究し「同じ失敗を二度と起こさないぞ」という心構えで，そのためにはどうすればよいかを，前向きに真剣に考えることが「プロジェクト完了報告会」の重要なテーマである。もし，失敗やミスをしたら反省する。反省は，再発防止と能力向上に役立つ。反省時には次の二つのプロセスを実行することになる。
成功・失敗の知識化がポイント
成功や失敗の情報は，客観的に整理されていることが必要なのは言うまでもない。成功や失敗の詳細をつかむのに役立つ。しかし，これを新しい仕事に役立てるには，正確な経過や原因の他に「どうすればよいのか」という知識化された情報が必要である。
現在，知識の蓄積と活用というナレッジ・マネジメントの重要性が叫ばれている。一番大事なことは，ナレッジそのものが充実しているかどうかで，活用方式はその次の話である。成功や失敗情報が，他の人が活用するに値するナレッジになっているかである。つまり，他の人が見て役立つような分かりやすい情報として纏め，知識化する必要がある。
例えば，失敗や事故情報が伝わりにくいのは，失敗や事故自体を知られたくないとか，隠したい，恥ずべきものと感じることがその原因である。失敗や事故から得た教訓や再発防止策のような前向きな知識であれば，誰にも気遣いは不要である。その知識が拡がったとしても，当事者が不利になることはない。知識であれば広く伝わった方が会社や組織に役立つ。知識化とは誰にでも役立ち，誰にでも伝わりやすい形にすることである。プロジェクト完了報告会の資料も真の意味で知識化されているか見直し，他の人に役立つプロジェクト完了報告書にすべきである。
日立システムアンドサービス
プロジェクト推進部 部長
