もったいないプロジェクトの「ふりかえり」や「完了報告」

プロジェクトが終わったら、プロジェクトの目的や目標を達成したか検証することが必要です。ただ実際には、あまりプロジェクトの完了報告をしてこなかったのではないか、と思うんです。

なぜそう思うかと言うと、

・契約がプライムコントラクタではないのでプロジェクト計画は部分的なため
・報告がプロジェクトマネージャやメンバの失敗を糾弾する場になっているため
・そもそもプロジェクト計画を作っていない

こういった、やらないための理由をつくり、また、それがやらない理由としてまかり通っていたから、です。

でも、ここ最近はプロジェクトの完了報告は形を変えて浸透してきていると思うのです。それが、ふりかえり、です。

ふりかえりがこれまでのプロジェクトの完了報告と違うところは、その重きが数字での計画と実績の評価から、プロジェクト開発チームのメンバ一人ひとりがそのプロジェクトで経験してきたことを共有し、次につなげるというところにあるからではないか、と思うのです。

それを具体的に表しているのが、ケプト(KPT)です。ケプトについてはこれまで何度かこのブログで書いてきました。

プロジェクトの完了により残された情報は、宝の山だっと思っています。記録されていれば、ですが。さらに、プロジェクトの開発チームのメンバが経験してそれぞれが持っている知識も価値のあるお宝です。

ただし、メンバが経験してきた知識も開発チームの中で共有されてこそ、価値を生むのです。それは、共有されることで初めて、経験したことが暗黙知から汎化され、形式知となって他者が理解できるカタチになるからです。

こうした価値を生む可能性のある経験を、数値による糾弾ではなくケプトなどによる次のプロジェクトにつなげることを前面に押し出すことで完了報告と言う行為をカジュアルに、でも、有効性のある場の提供に変えようとしている転換期に差し掛かっているのではないかと思います。

ただ、こうしたふりかえりは定量的な数字をあまり扱わないものです。なぜなら、ふりかえりは開発チームのメンバを中心として編成するためです。

プロジェクトは遊びではなくてビジネスですから、やはり、プロジェクトの目標で立てた定量的な数値での計画と実績を比較し、結果については情報の収集と次につなげる定量的な分析をする必要があります。

そういったことを念頭にすれば、開発チームとプロジェクトマネージャはふりかえりを、プロジェクトマネージャとステークホルダは完了報告と夫々目的に沿って分けて開催する必要がある、ということが言えます。

さて、ふりかえりも完了報告もどちらも有用性は理解できると思いますが、一番大切なことは、その場のファシリテーションです。間違っても、プロジェクトマネージャやプロジェクトメンバを指して非難をしないことです。そんなことをしても、何も新しく生み出せるものはありません。あるとしても、非難されたことによる恨みつらみとふりかえりや完了報告には二度と出ないということだけです。

かならず、資料やホワイトボードでモノ、数字などを対象に話すことです。これを忘れては、折角のふりかえりや完了報告の時間が無駄になってもったいないです。