Sphere System Consulting ltd. スフィアシステムコンサルティング株式会社

Vol.11 ITプロジェクトは必ず振り返りをする

 コラム

ITプロジェクトは必ず振り返りをする

 

忙しい業務の中で、ついつい忘れ去られてしまうこと。それは「徹底的に振り返ること」ではないでしょうか。IT導入プロジェクトでは、特に振り返りが大事です。
大規模なシステム導入が数年に一度だからこそ、前回の失敗原因を繰り返してはいけません。

 

完了時にお疲れ様の飲み会はやっても、真面目な報告会をやるのはまだまだ少ないです。
プロジェクトは完了報告会をもって終了しますが、通常ITベンダー側しか行いません。
本当は、システム発注側企業にこそプロジェクト完了報告会が必要です。

 

また、完了報告会を形式的にやるのでは意味がありません。
非常に興味深いのは、システムの受注側と発注側、それぞれが完了報告またはプロジェクト途中で失敗原因を掘り下げようとするとき、両社の言い分はまったく異なります。
会社対会社の言い分であり、それぞれメンツがある。お互いに触れたくないことには触れず、報告のための報告を作っておしまい。
このようなケースは、プロジェクトが大きくなればなるほど顕著になります。

 

とある大型プロジェクトでのこと。発注側企業で上手くいかなかった原因をメンバー全員からヒアリングし、真因を追求しようとする試みがありました。
システム受注側の言い分は、技術者が様々な原因でプロジェクトを離れることになり、代わりに来るメンバーが状況を把握し戦力になるまでに時間がかかってしまった。とのこと。

確かに事実かもしれないが、真因ではない。発注側からも反省すべき点はなかったか?を知ろうとする良い試みでした。

 

この試みは不完全なまま終了してしまいます。事象をメンバー全員からヒアリングするところまでは良かったのですが、なぜそれが起きたのかを分析する作業をリーダーひとりに一任していたため、そのリーダー主観での判断となり、そのリーダーが上長へ報告するための報告書へと目的がすり替わってしまいました。

公平な立場ではなく、触れたくないことには触れない骨抜きの報告書となりました。

 

このような結果になるのは、失敗は責められるという文化があり、事実を明るみにすることと罰を与えられることがごちゃ混ぜになっているという背景があります。

世の中の不祥事は、公平な第三者の調査機関が入るのが当たり前となっています。
そこまでせずとも、リーダーが謙虚に事実を受け入れる姿勢をもっていれば対応は可能です。もちろん、ここで言うリーダーとは中小企業の経営者です。

 

失敗が責められない雰囲気作りはとても重要です。
失敗が責められる雰囲気だから隠そうとします。重要な情報が隠された報告書には、正直な経験や教訓が無いのです。
先ほどの大型プロジェクトの例で言えば、教訓を残そうとしたにも関わらず不十分なままなので、次も失敗する確率が高いのです。
そうなると、誰も残されたドキュメントを信用しなくなり、使われることもなくなってしまいます。

 

振り返りには苦痛を伴います。できれば避けたい。これが本音ではないでしょうか。
しかし、リーダーが率先して振り返ることで雰囲気はがらりと変わります。

 

振り返りをやらない一番の理由は、目先の仕事が忙しく、目先の売上目標達成の方が重要だからではないでしょうか。
しかし、本当に差別化となるのは「重要で緊急」のことだけをやるのではなく、「重要で緊急ではない」ことをいかに多く着手するか。これに尽きます。

皆さんの会社には、振り返りをする文化はありますか?
それは形式的なものになっていませんか?