ITコーディネータの吉田聖書です。
7月にサービスを開始した7payが
9月いっぱいでサービスを終了する
ということが発表されました。
このまま続けることは得策ではない
という経営判断とのことですが、
事故原因がまだ究明されない中での幕引きに
感情的にはモヤモヤが残るところです。
特にガバナンスの問題、意思決定の問題は
ほとんど公表されることがないので、
真の原因と再発防止策について
続報に期待しましょう。
さて、本題に入りたいと思いますが、
プロジェクトの支援をしている中で
システム開発の場合はリリースなど
一定の区切りがついたタイミングで
「ふりかえり」あるいは「反省会」
というイベントを行うことがあります。
本当であれば
全てのプロジェクトで行われるべきですが、
残念ながらふりかえりが行われない、
行われても表面的にしか行われない
というケースもまだまだあります。
尚、ふりかえりのフレームワークと
その使い方については
という記事も書いていますので
参照していただければと思います。
「ふりかえり」というのは
必ずしも悪かった点にフォーカスするのではなく、
しっかりと良かった点にもフォーカスして、
今後の教訓を得る取り組みです。
ただ、プロジェクトが炎上していた場合は
どうしても悪かった点にフォーカスされますし、
それはやむを得ないことだろうと思います。
いわゆる炎上プロジェクトの場合、
一番まずいのが
「反省すべき人が反省しない」
という点です。
その「反省すべき人」が
プロジェクトマネージャや部門長
である確率が高いのですが、
そういう立場の人が
ふりかえりを主導すると、
現場のメンバーにだけ反省させて
本人は反省しないということが
往々にしてあります。
それだと、
本当の意味での教訓は得られず、
メンバーだけが責められているような
惨めな気持ちになります。
メンバーは必死で頑張ったのです。
メンバーに反省を促すよりも
まず、責任ある立場の人が
率先して自らをふりかえるべきでしょう。
以前、友人の会社と共同で、
「炎上プロジェクトから学ぶセミナー」
というワークショップを開催したことがあります。
ここでのポイントは、
炎上してしまった場合にどうするか、
炎上しないようにするにはどうするか、という
「消火」と「防火」という2つの観点で
議論を行っていました。
このような教訓は
効果的な反省が行われて初めて得られるものです。
「運が悪かった」とか
「計画が甘かった」といった
反省しか出てこないようでは
効果的な反省が行われたとは言えません。
もし、適切なマネジメントが
行われなかったことが問題だったのであれば、
なぜ適切なマネジメントが行われなかったのか
どうしていくべきだったのか、
その原因と対策を
掘り下げていく必要があります。
プロジェクトマネージャ個人の力量の問題
ということもあるでしょうし、
それをサポートできなかった組織の問題
ということもあるでしょう。
いずれにせよ、タスク遂行上の問題だけでなく
マネジメント上の問題についても原因も明らかにし
それを取り除く、あるいは改善する
という方向に動かなければ、
その組織はまた同じ失敗を犯すでしょう。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。