プチ炎上プロジェクトを発見するしくみづくり
プチ炎上プロジェクト＝ボヤとは違う
大炎上するほど燃料投入もなくて、規模相応のプチ炎上するプロジェクトなんてほんとザラにあるでしょう。ほら、アナタのプロジェクト、プチ炎上してません？
＃ドキッとした？
プチ炎上してるプロジェクト、これは結構、素養があって、ハンドリングを間違えると大炎上する可能性を秘めているものです。燃料が足らないだけ。燃料を自家生産し始めたら焦土とかすか、採算を度外視して物量的に人を投入して鎮火させるしか方法がないかと。
ボヤは、それこそボヤですからね、素養的には大炎上するものもあるでしょうが、なにせボヤの時点で発見しているので、それこそ早期に消すなり、握り潰すなりできるわけです。火が付きそうな前に掌握していることが違う。
プチ炎上しているプロジェクト、原因はどこにあって、同じことを繰り返さないようにするにはどうしたらいいでしょうかね。
プチ炎上プロジェクトの原因は現場だけではない
一番矢面になるのは現場の責任者のプロジェクトマネージャと言いたいでしょうが、本当の戦犯はマネジメントです。accountabilityの観点からも、ビジネスのオペレーションの観点からも。
大概、自己防衛が働くので責任転嫁をするから、ことが済んでから報告会と称して“葬式のような反省会”をすることになるものです。で、強い口調で、物言いが始まる。
それを聞く身になってほしい。いや、アナタ、
って、しか思いませんね。葬式のような報告会は、何も生産しないし、何も次に繋がらない。積みあがるのは硬貨のなさそうなチェックリストや手続き。
プチ炎上したプロジェクトマネージャが気骨なら、そんな声は受け流して問題点を冷静に分析して、じゃあ次はどうすると切り返すものですが、人が良すぎる人が多いからね、強く言われれば、
「どーもすみません。」とシュンとするものです。“あーすればよかったなー”って。修正パッチを当てられない過去に当てようとする。ガラス窓越しに絆創膏を貼るようなもの。
組織としてやらなければならないこと
組織としても、当事者のプロジェクトチームとしても、関係者が全員集まってやらなければならないことは、次に同じ過ちをしない“しくみづくり”です。プロジェクトをキャリーするための“業務プロセス”、手続き。
勿論、山のようなチェックシートを作って、対策をした気になるような手順の無駄を作り込むことは愚の骨頂です。本質はそんなところにはないことをどれだけ見抜けるか。
マネジメントも直ぐに改善案とか再発防止とかやりたがりますが、形としてはやるにしても、真の原因を見極めないと効果のない、益、ここで言うのは炎上の燃料を安全に取り扱うための“しくみづくり”に結びつきませんから、それに注意することが必要で、それこそ、マネジメントがマネジメントたるための役割だと思いますね。
マネジメントに責める資格はない
プチ炎上するようなプロジェクトは大抵それほどプロジェクトのサイズも大きくなくて、手ごろなサイズゆえにそれほど経験のないエンジニアをプロジェクトマネージャとしてアサインしたくなるものです。大概、そうアサインしたくなるときって、リソース的に適当なスキルを持つエンジニアが出払っているからでもありますが。
プチ炎上するプロジェクトがプチ炎上するのは、ボヤの時点で煙が燻っていることを発見することが出来ない“しくみ”となっているところに問題があるものです。しくみは組織の中で、マネジメントに裁量が与えられていることが多いからこそ、マネジメントの役割の範疇であるとするところでもあるし、プロジェクトマネージャに「ああせい、こうせい」と指示できるロールを持っているところにも由来していると思っています。
それがあって、プチ炎上するプロジェクトあるとするなら、ボヤを発見できない業務プロセスの“しくみ”なり、マネジメントとしてのプログレスのチェックが職能として働いていないか、そもそもプロジェクトが炎上したときにどうなるかの最悪のシナリオが想像出来ないプアなスキルしかないことに原因があるかもしれない。
そのようなマネジメントなら、プロジェクト終了後の報告会で、プチ炎上したプロジェクトマネージャを一方的に責める資格はない。顧客にサービスをデリバリする責任者としての役割を果たしていないのだから。
＃きっぱり。
で困ったことに、このようなマネジメントは、デッドラインを読み間違えることが多いのもまた、涙を誘うものです。
業務プロセスで発見するしくみづくり
マネジメントが一から十までチェックするのか？と問われれば、それは違う。業務のプロセスとして、
“ボヤを発見できるしくみを作りなさい”
と言うことです。
ボヤを発見できるしくみは、出来れば機械的に発見できる方が良く、それをキッカケにマネジメントが現場にふらっと行って、あたかも世間話するようにレポートと内情のギャップをインタビューするとか、当のプロジェクトマネージャにぶっちゃけどうかと聴いて、必要なトッププライオリティのアクションだけアドバイスするくらいが良いのだと思う。
あと、上手く行ってもボヤが起きてもプチ炎上してもプロジェクトが終わったら、ケプトで“ふりかえり”しましょう。ケプトで。
