エンジニアの生産性も稼働率もマネジメントの指標にはならないことをマネージャ自身が気づかないのはなぜか

プロジェクトマネージャはプロジェクトの目的を達成するためにプロジェクト遂行に必要なリソースを確保して、プロジェクトの目的の一つである納期に契約に記載されたアウトプットをプロジェクトに求められる要求品質を満たして納めるための活動にフォーカスして行動基準を定め、判断するものです。

なぜならそれがプロジェクトマネージャのロールだから。

プロジェクト最適化というフロー効率という考え方

プロジェクト最適化とはプロジェクトの活動の中でプロジェクトに寄与することを最優先とする行動規範です。冒頭に記載のように判断しなければならないときに、そのくだす判断がプロジェクトにとって最大の利益に結びつく結果を選択します。

プロジェクト最適化をプロジェクトマネージャが行うとき何を考えているかというと、解決したい課題が最速で、リスクのエクスボージャが最小となるような手段を選択するということです。厄介ごとは手早く片付けたいという心理が働くということです。

ここで注目したいのは手早くエクスボージャを最小でとしているので投下するリソースは最小でかたづけたいということです。これは効率よく課題を解決したいのでリソースのフローを効率的に使いたいという心理が働きます。

なぜなら、本来のWBSは並行して動いており、課題解決をするためには本来のWBSに投下をしているリソースから剥がして持ってくるか、予算措置的に確保しているコンテンジェンシプランの予算から切り出して充てがうからです。

この課題解決の対策を斬新的且つ中途半端に対処すると課題可決のめどが立たず課題がプロジェクトのトラブルにクラスチェンジするので悪手であるのですがそれはまた別のテーマで。

稼働率というリソース効率という考え方

ところで、プロジェクトマネージャが管理職になってマネージャになるとそれまでリソース効率を行動の判断基準としていたプロマネが同じ人なのにエンジニアのコストを外部からの収入で利益化することの効率性を行動基準に宗教替えしてしまうマネージャがいます。

プロジェクトマネージャのときは少数のリソース投下で最大限の効果を得ることを判断基準としてきたのに、マネージャになるとどんな仕事をしているかどうかはどうでもよくエンジニアの月当たりの稼働時間のうちどのくらいの割合を使用しているかという、リソースの源泉は同じエンジニアなのにエンジニアの成果で判断しなくなるということが起きます。

これに類似しているのが、プログラムの生産性です。ほら、もう、エンジニアの稼働率もプログラミングもそういった数値は計測可能だし簡便に得られるけれど勘弁に手に入れられるからこそ、そこから導き出される率には数字に何か意味があるか、エンジニアの稼働率であれば価値あるアウトプットを生産したかやプログラムの量が機能数と相関関係があるかと問えばそれはノーです。

ではどうしで宗教替えをしてしまうマネージャが出てくるのでしょうか。それは、マネージャ自身がマネージャの仕事をオペレーションと捉えているからです。

ビジネスを拡大すること、つまり利益を生むことがマネージャの仕事だとしたら、デリバリーして利用される機能が期待する成果を産んだかを測ることが必要なのです。