PJ活動お役立ちコラム
第8回　2021年01月19日
プロジェクトの振り返りについて（後編）

皆さんの社内プロジェクト、やりっぱなしになっていませんか。
どんなプロジェクトであれ、プロジェクトの終了時に振り返りあるいは反省会を行うと思います。もし振り返りをやらずに済ませようとしていたら、ぜひ実施してみませんか。

前回は「プロジェクトの振り返りについて」の前編として、振り返りの重要性と、「意味のある」振り返りのために目的を明確にすることが大切であることをお話ししました。
後編の今回は、「意味のある」振り返りで必要な、もうひとつのことをお話しします。

振り返りの観点を型として持っておくこと

「意味のある」振り返りのために必要な、もうひとつのことは、振り返りを行う観点を整理することです。私たちが開発プロジェクトの振り返り会に立ち会うときは、次のような型に当てはめながらメンバーの意見を探るようにしています。

プロジェクトには必ず達成目標があったはずです。まずは、その目標と現実の成果とのギャップを、QCDの観点で振り返ります。
成果あるいは成果物の品質は、プロジェクト発足時に期待したものと比べてどうだったのか。期待を上回ったのか、下回ったのか。どういう点で上回った／下回ったのか。これが「Q」です。
では、その品質を得るためにかけた、あるいはかかったコストは適切だったのか、プロジェクト発足時に想定した範囲内に収まったのかどうか。想定を超えてしまった場合は、その理由が妥当だったのかどうか。これは「C」です。
次が「D」。プロジェクトのスケジュールはどうだったのか。プロジェクト発足時の想定通りの納期で終えることができたのか、それよりも前倒しできたのか、あるいは遅延してしまったのか。それはどの程度前倒し/遅延だったのか。それは諸々の情勢から考えて妥当な範囲の変動だったのか。
こういったQCDの観点で振り返ったとき、良くできたこと、うまくできたことと、うまく行かなかったこと、失敗してしまったことを洗い出します。KPT法を使うのも良いでしょう。

次に、その結果・成果に至るまでのプロセスを以下の観点で注目すると良いでしょう。

プロマネはプロマネの視点で、メンバーはメンバーの視点で時系列に沿ってひとつひとつの事象を振り返り、うまく行ったこと、うまく行かなかったことを挙げると良いでしょう。とくにトラブルやインシデントが起きているなら、それがどの作業フェーズで起こったことなのか、その要因が人にあるのかプロセスにあるのか、といった仕分けを意識的に行うことは、次に生かす組織知を得るうえで重要です。

振り返りの結果を次に残すために

これまで2回にわたって、プロジェクトの振り返りの重要性と、そこで語るべき内容についてご説明しました。まとめると、こういうことです：

こうして挙げられた意見の数々は、文字通り玉石混交です。「次」に生かすためには、組織の財産となり得るポイントを整理し見極めたうえで、その真因を探り当て、それを抽象化・一般化する作業が必要になります。これについてはまた別の機会にお伝えしたいと思います。

> プロジェクトの振り返りについて（前編）