PMの後任に指名されても困らないようにチームのSPOFを潰せ

マネージャのみなさんと是非とも共通理解を得たいと思うのですがよろしいでしょうか。

 

計画した予算や期日どおりに推進できるエンジニアがいたら最大級の待遇をしてあげてください。

 

放置したままでプロジェクトが計画した予算や期日に終わることはありません。計画どおりに推進できるエンジニアつまりプロジェクトマネージャやリーダが機能して初めて計画どおりに進捗するのです。

みなさんが最大の誤解をしているのは計画どおりに、普通に進捗していることはとてもレアですごいことなんです。

ましてやプロジェクトチームのリーダ役が異動ややめてしまった後はどうなるかを想像するだけでもおぞましいです(未経験のエンジニアが後任なら)。

例として次のエントリがありますが、プロジェクトのタスクコントロールをしていなければアドホックに作業とをしているのですからモグラ叩き状態で仕事をしていることになります。これでは作業を区切るという概念がプロジェクトの中にないのと同じことですから残業し放題な環境をリーダ役が自ら提供していると思われても仕方がない事案です。まあ、自爆案件です。

qiita.com

 

エントリの前説にプロジェクトマネージャが異動して後任にメンバが繰り上がったと記載があるのを読んで思うことは、プロジェクトマネージャやリーダクラスがいついなくなってもいいようにしておこうな、チームのSPOFを作らないようにしておけってことですよねぇ。

情報の SPOF

 プロジェクトチームが持つ情報は誰かが独占するものは何一つありません。全ての情報は、役割、分掌に応じて共有する必要があります。組織の中でのお仕事だからね。

プロジェクトの機微な情報はプロジェクトマネージャとマネージャとチームの中の役割ではなく組織を含めた関係の中で共有される場合もありますけど、それ以外の情報はプロジェクトの目的を達成するためにメンバが知り得た情報は持ち寄る必要があります。

情報を持ち寄りいつでも誰でもがアクセスでき、利用できないのなら情報にSPOFがある状態です。これでは、誰かメンバが朝の通勤でバスに轢かれてしまったら…。そうそうないことで例えていますが1ー2週間くらい(インフルエンザとか忌引とか)で休むこともよくあるので情報の断片が起きないようにプロジェクトを始めた時から共有する文化を作りこむ必要があります。

役割の SPOF

 プロジェクトマネージャの異動もそうですが人的リソースとして役割を負っているエンジニアがチームから抜ける理由は様々です。

例え少人数のチームであっても、役割のSPOF対策はプロジェクトを開始するときから方針を決めておく必要があります。経験的にはチーム内でセカンドを決めておけばいいので。

困るのがリーダ未経験者をPMのセカンダリにする場合です。そのようなメンバ構成の場合は、ことが起きたときに経験させるのではなく、通常運転のときにこそセカンダリのメンバにタスクを一部渡して経験させ訓練をしておくことが対策の一つとなります。

そういったセカンダリのメンバがぎこちなくても機能させるためにはやはり情報のSPOF対策が運用できていることが必要になるのです。

 

 

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

 
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ