リーダがメンバを使えるようなしくみ作りをしないといけないのは仕事を抱え込まない対策でもあるわけで

新任のマネージャやマネジメントの本を読んでも得るモノのないマネージャに多いのが、自分のメンバを使えないと嘆く人々。そういう人たちには、問題が起きれば昔取った杵柄なのか、責任感なのか自分が現場に乗り出したりして、ミイラ取りがミイラになるを地で演じしまうのを風の噂や、直接知る機会に恵まれるとなかなか趣深く感じるものです。ただ、残念なのはこうした事象に季節感がなく、年がら年中そこここで起きるのは風情が少し足らない気がしないわけでもないです。

マネージャに限らず、プロジェクトマネージャであっても、まず大事なことは、人的リソースはgivenなのであって、まさに、与えられたものであることを忘れてはならないのです。不平不満があるとしてもそれは多くは感情に基づくもので、マネージャと名のつくロールにいるなら自分の分掌に則して結果を出さなければならない。そうそう、マネージャやプロジェクトマネージャ自身も与えられた人的リソースですが、ただ他の人的リソースと違うのは、本人が望めば人的リソースの中身のスキルを変えていくことができることです。

実際は、みなさんいいますね。「このメンツでは……。」とか。そんなんうまくいく人を集めたチームなんてあると思っている方が頭の中がお花畑なんです。理想の、ドリームチームが組めるのは現実問題としてビジネスが閑散としていて余剰になっているから組めるだけです。そんな状況になっていることの方が組織として存続が危ないわけで。

マネージャの名のつく職種になったら手始めにすることはメンバの把握とビジネスに耐えられる育成です。それだけ。それは、ビジネスの問題だけではなく、プロジェクトでも同じです。プロジェクトの方がビジネスより、より、個別最適化の力学が働きますが、それでもやっぱり基本的には、集まった人的リソースのパフォーマンスを如何に最大限に引き出し続けてプロジェクトのゴールを目指すか、それを意識していないと行き当たりばったりのプロジェクト運営になってしまうんです。

そうならないように、メンバのパフォーマンスが出ないからと言って目先のタスクをプロジェクトマネージャが一緒になって作業の当事者にならないようにしなければいけない。それを支えるのがプロセスだし、タスクごとの完了条件の明確化です。何を最優先に考えられるか、式で表せば、プロセス＜完了条件の明確化です。ただ、それを成立させるには、プロジェクトマネージャとしてコントロールする事柄とメンバの裁量に任せる範囲を決めて、運営できなければタスクの完了に得られるdeliverableは品質の面で大分怪しくなるので注意が必要です。

ところで、プロジェクトマネージャがメンバと一緒に作業をしてしまっている状態と、プロセスを決めてタスクの完了条件を合意した上でプロジェクトマネージャがタスクの定義の整理に入るとか途中途中の方向性の確認をするのとは、全く違うのです。そこは混同しないように。

前者はやってはいけないことだけど、後者は、やらないといけないことです。プロジェクトマネージャと担当のエンジニアの間にサブリーダがいれば、後者はサブリーダに任せていいけれど、すべてをサブリーダに任せるのではなく、タスクのdeliverableや方向合わせの確認はしないといけないですが。それを欠くと単なる丸投げです。プロジェクトマネージャとサブリーダが意思疎通出来てお互い何をやればいいのかわかっていればいいのですが、そういう関係はそうそうないので。

結局、育成やプロセスなどのしくみ作りは自分が一作業者として入り込まないための対策なのですよ。