艱難辛苦を乗り越えてシステムが無事サービスインし安定稼働に達したら通常プロジェクトは解散されます。でも最後に絶対にやってほしいこと、それはプロジェクトの「振返り会」です。
（「反省会」という言葉を使う人もいますが、私は「振返り会」という方が好きです。「反省会」だと悪いことしたみたいでしょ）
「振返り会」を実施する目的
「振返り会」を実施する目的は以下の通りです。
・プロジェクトの実施中に培われたノウハウを再利用可能な形に成形し、メンバー全員で共有すること
ここで重要なのは「再現可能な形に成形」することです。どんなに有用なノウハウであっても再利用可能（今後のプロジェクトで活用できる）な形になっていなければ意味がありません。また「メンバー全員での共有」という部分も大事で、ベテランから若手までできるだけ多くのメンバーが理解できかつ再利用できる形にできれば、そのノウハウの価値、「振返り会」の価値は計り知れないものになります。
「振返り会」のやり方
(1) 振返り会実施目的の共有
まず最初に上記振返り会実施目的を参加者全員で共有します。
(2) プロジェクト実施中のトラブルを洗い出す
プロジェクト期間中に発生したトラブルについて洗い出します。ただし「経験したトラブルを挙げて！」というだけだとなかなか出てこないので、以下のようなインプットを使用します。（私の場合「振返り会」ためにわざわざ資料を作ることはありません）
・課題管理表
->説明不要ですね。プロジェクトで発生したトラブルは課題管理表にある”はず”ですよね。
・スケジュール/進捗資料
->スケジュール上の問題を挙げてもらうために改めて見てもらいます。具体的にはスケジュール上でどのあたりが厳しかったかをメンバーに聞いてみます。
・システム構成図などの成果物
->作成したシステムの全体を眺めることで大小にかかわらず発生したトラブルを思い出してもらいます。
(3) トラブルの原因を考える
トラブルが挙がったところで、そのトラブルの原因を考えます。ここでのポイントは
・まずはトラブルの当事者に考えてもらう
・自分以外の原因(環境が悪い、情報が悪い、XXさんが悪い)を考えてもらう
ここで非常に重要なのは原因を自分以外に置いてもらう（自分は悪くないというスタンス）ことです。
ビックリしましたか？ トラブルの原因において「自分は悪くない」というスタンスをとることは一見間違いのように感じるかもしれませんが、日本人の特徴なのかこのようなシーンにおいて当事者は「自分が悪かったです」となりがちなのです。これでは再利用可能なノウハウに繋がりません。トラブルの原因が「私がもっと注意していればよかった」で対応策が「次は気を付けます」というのでは振返り会をやる意味がなくなってしまいます。
(4) トラブルの発生条件と対応を考える
次に原因が分かったところで、トラブルの発生条件と対応を考えます。この辺りをしっかり考えることでトラブルノウハウが再利用可能な形になっていきます。
＜発生条件＞
・どのような条件の時にそのトラブルは発生するのか？
＜対応＞
・未然に防ぐ方法は？
ただし、すべてのトラブルに対し未然に防ぐことができない、もしくは未然に防ぐことが効率的ではない場合もあるので、必要に応じて以下のポイントで議論を深めていきます。
・未然に防げないとすればトラブル発生を察知する方法はあるのか？
・トラブル発生を察知した後の効果的な対応方法とは？
最終的にここでのディスカッション内容は表にまとめて、プロジェクトメンバー全員で共有します。（これはマネジャからのメンバーへの最後のプレゼントとなります）
いかがでしょうか？ 実際のところ（打ち上げの飲み会はやっても）「振返り会」ってあまりやられていない気がします。しかし、プロジェクトの実施中には様々なノウハウが生まれますのでその内容をしっかり整理して、メンバー全員の今後の仕事生かしてもらえるようすることがマネジャの最後でかつ大切な仕事ですよ！
コメント