PJ活動お役立ちコラム
第15回　2021年03月9日
プロジェクトで得た教訓の残し方（後編）

皆さんの社内プロジェクト、やりっぱなしになっていませんか。自分たちが経験したこと、良かったこと悪かったことを振り返って、次のプロジェクトに引き継ぐ活動ができていますか。

前回は「プロジェクトで得た教訓の残し方」の前編として、再現できるように情報を残すことが重要であることをお話ししました。

今回は後編として、「抽象化して情報を残す」ということをお話しします。

抽象化して情報を残すということ

プロジェクト振り返りで挙げられた意見やコメントは、事象として個別具体的であることが多いと思います。つまり、そのプロジェクトのその場面で発生した出来事です。
たとえば：
AかBかどちらを選ぶかという場面で、プロマネは顧客に直接掛け合って合意を得たうえでBという判断を下した。その結果トラブルが発生した。
「Aを選んでおけば問題は起きなかったのに、なぜBだったのか？」
「それは顧客の意見に従ったまでだ。」
「いや、そんな話になっていたとは俺は知らなかったよ。いつ決まったの？」
「そんなはずはない、あそこに書いてあったはずだけど」　・・・

よくある光景ですね。多少脚色していますが実話です。実はこの事例の振り返りで最後に残した教訓は、「顧客との合意事項はタイムリーに関係者に共有しよう」ということ。そして、それを有効に実施するためにどういった手を打てばよかったのかメンバーが考えた対策を添えて、次世代プロジェクトへの申し送り事項としました。
ここで注目したいのは、「AではなくBを選んだこと」自体も反省点であり、トラブルの直接的な要因なのですが、そのことではなく「情報共有」を教訓として残したということです。より抽象的ですよね。

経験上、プロジェクトで起きる「トラブル」はいくつかの類型に収まるもので、目の前に見えているのが個別具体的な事象であっても、原因を突き詰めていくと、ほとんどは別のどれかと同じ事象と判断できます。事象を抽象的に捉えることで類型化が可能になった、とも言えるかもしれません。
大事なことは、このプロジェクトにおいて「顧客との合意事項がタイムリーに共有できていなかった」というよくある事象が発生したという事実です。
つまり、このプロジェクトのメンバーは、その事象に直面した経験を持っているのです。彼らの経験談は、次の世代で同じような事象に遭遇した人から見ると、貴重なアドバイスになり得るでしょう。なぜなら、本やネットで見かける事例よりも個別具体的で、しかも自分たちに近い境遇の事例なのですから。
「プロジェクト全体で情報共有がうまく行っていない気がする」と感じているプロマネやプロジェクトメンバーが、この事例を目にすれば、気付きが得られる可能性は十分にあります。
一方、「AではなくBを選んだこと」はどうでしょうか。同じような境遇でしかも「AかBかどちらを選ぶか」という場面がもう一度再現されるとは考えにくく、具体的過ぎて、誰にとっても役に立つ教訓とは言えないでしょう。

また、次世代プロジェクトのメンバーが再利用しやすい形で残す、という配慮も重要です。
今回の事例でも、おそらく役に立つのは「情報共有は重要だよ」という抽象的な教訓ではなく、そこに付け足されている「それを有効に実施するためにどういった手を打てばよかったのかメンバーが考えた対策」という具体的な情報の方でしょう。これはとても具体的だからこそ応用が利くのです。そう、コンビニエンスストアやテーマパークのマニュアルにおける「事例」と同じです。ということは自分の場合はこうすればいいんだな、と想起し再利用できることが、とても重要なのです。

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

ということで、前回のコラムの内容に、新しいポイントが加わりました。

皆さんも、プロジェクトの振り返りを行う際は、抽象と具体をうまく織り交ぜて事象を整理し、次世代のプロジェクトに貴重な経験を引き継ぐことを意識してみてください。

> プロジェクトで得た教訓の残し方（前編）