SIerのマネージャとして機能するために

SIerのマネージャは、所謂、従来のマネジメントの役割をロールとして担わされている。従来のマネジメントの役割とは、分掌するビジネス領域をキャリーし、部下へ指揮命令を行うことである。分掌自体は組織の役割分担で決まるからビジネス上のスコープ(業種業界、ソリューションなど)は固定である。

部下への指揮命令は、アサイメント、プログラム・プロジェクトマネジメント(マネジメントとして)、育成、その他多岐にわたるため、そのマネージャが優先する業務に傾斜が掛かる。

担当ビジネスにおけるプロジェクトにフォーカスすると、プロジェクトの見積もり、契約に関わる(マネジメントとしてその案件をやるかやらないかの意思決定)。GOをかければチーム編成にも関わり、プロジェクトチームのプロジェクトマネジメントのモニタリングを開始する。

モニタリングを開始し、プロジェクトの進捗が滞るとか進捗上の障害が発生するとプロジェクトチームに口を出し始める。

程度の違いやマネジメントの関心事に依る優先順位で濃淡はあるにしても、こういうことをやってきたはずであるし、やっているはずである。

観測範囲で言えば、モニタリングをろくにせず、問題の火を消せなくなってしまってから口先介入をするようになり、問題の根本解決には至らないリソースの暫時追加や介入によるオーバーヘッドを余計に作っているように見える。

全くもって阿呆らしい。

問題になるのは、プロジェクトチームとして満たさなければならないスキルセットとレベルをマネージャが見切れていないでGOを出すことであるし、条件付きでGOするならモニタリングの閾値を下げ、感度を上げておかなければならないはずである。

根本は、案件のリスク識別が根っこにあり、それを識別できないからプロジェクトとして必要な、でも過剰でないプロジェクトのスキルセットを構成できない。

どうして出来ないのか。

これを端的に『不確実性が高まっているから』で片付けてしまうと先に進まない。出来ないマネージャは、ビジネスとしてやると判断する案件を『自分がやる』つもりで見ていないからではないか。誰か(部下)にやらせるから、細いところは部下にやればいい。そこにリスクを識別する機会を自ら失っているのではないだろうか。

『マネージャは忙しい』『それもやるのが部下の仕事だ』と思ったら、それはマネージャの仕事を増やしているだけだと理解すべきだ。マネージャのリソースが問題であるのなら、組織の役割を見直さなけばマネージャは仕事をしていないことにもなる。

その解決方法が、PO(Product Owner)、SM(Scrum Master)、EM(Engineering Manager)という役割分担なのではないか。

そうだとすると、従来のマネージャはそうしたいくつもの仕事を一人でこなしてきたということだ。なぜ今では複数の人に割り振っている仕事を出来ていたのか。多分に、それまでの経験知で対応できる反復型のビジネスであったからなのだろう。ほとんど同じように繰り返される案件だから、脊髄反射的に対応してもなんとかなってきたのではないか。ところが、今は案件ごとの性質にバラツキが大きく、組み合わせるパーツがそれこそ型にはまらなくなっている。だから、部下に『やって』『やりました』と行かなくなったのだろう。

マネージャなのだから、自身が担当するビジネスの中では規程で制限されていなければ、内部の組織デザインは裁量で可能である。であるから、ビジネスの実現方法も(結果が伴えば)フリーハンドである。

マネージャのリソースが足らず、ビジネスの案件の不確実性が高いと認識する(できる)のであれば、組織内のデザインを速やかに変えなければならない。

それが組織を機能させることであり、生き残る戦略なのである。なお、配下のことなので、成功してから組織内へ成功事例としてアピールすれば良く、わざわざマネージャ自身で成功のハードルを上げる必要はない。

 

 

 

FGO手帳2019.4-2020.3

FGO手帳2019.4-2020.3

 
フレディ・マーキュリー~孤独な道化~

フレディ・マーキュリー~孤独な道化~