未来につなげるためにプロジェクトの報告会を開こう

プロジェクトが終わったあとの報告会での風景。そのプロジェクトはいろいろあったけれど結果的にはQCDは計画どおりだったので成功プロジェクトなんですが。

そのPMはここ数年プロジェクトマネージャを担うようになってきた中堅のシステムエンジニアでプロジェクトの途中のプログレスミーティングで助言をすると素直に聞いてくれる性格の持ち主です。

そんなPMの完了報告会も性格がでるのか「ここはこうすればよかった」とか「ああすればよかった」とかそんな調子で振り返りながらページを捲っていく。

とても感じる違和感。プロジェクトは成功しているのだからもっと「やったぜ感」を出していいと思うんだよ。反省するのではく、今回はここは「計画した」ようにできなかったから「次のプロジェクトで計画を立てるとき」は考慮するぜ、と言って欲しい。

未来を変えることが経験からの「学習」なのだから。

もう一つ気になったこと。

起きたトラブルのなかで印象的なものを説明しているが、そこトラブルの経緯と結果を聞いても仕方がない。プロジェクトチームのメンバと振り返りをするために共有するならそれを思い出すためにはいいだろうと思うけれど、この場は違うんだよ。学習したこと、得た教訓を共有するための場であるのだから。

だから、結果までをサラッと話して次のトラブルの話に進んではいけないんだ。何を教訓としたのかを言葉にして共有しなければそれは経験したPMだけの経験「知」になってしまう。それでは集まっている意味がないのです。

なので、次のトラブルに移るところで止める。ざっと見ると今のトラブルの経験から得ただろう教訓を共有できれば。あとは得られた教訓は特色もないので良さそうだ。「そのトラブルで得た学びはなにかな」そう割り込みを入れることでPMにレポートに書いていないことを言語化してもらおう。

こういった報告会は次につなげるために行うものだと思っているので、繋がるものがなければ意味はないんだよね。何を次につなぐのかを意識して聞かないと失敗したプロジェクトならPMの糾弾に、成功したプロジェクトはよかったね、となってしまうから危ないんですよ。

プロジェクトは期限のある唯一無二の業務活動であるから全く同じ条件での比較はできないけれど、未来のプロジェクトを見積もるための類推見積もりや経験知としての参考にするために活用することは意義があるのです。というか、全部は経験できないのだから他人の経験は参考程度であってもそういった情報がどこにあるかリンクとしては持っておいたほうがいいんです。

そうたときに欲しいのはやっぱり定量的な数字なんですよ。工数の実績や品質の状況とか。仔細な数字ではなく、自分が計画した数字が過去の実績から特異にないっているかいないか位置を知るために。

なので、レポートの中に数字があるか、その数字の塊の単位が「次に活用する際と同じ単位か」だけが気になるんです。ぶっちゃけ中身の数字はどうでもいい。それはプロジェクトの特性なのだから。それよりは、再活用出来るかどうか。そのために報告会をやるのです。