「現場」という言葉にみる「マネージャvsエンジニア」論と、そのもう一歩先

このエントリーは、『DevLOVE Advent Calendar 2013 「現場」』の５９日目の記事になります。
※詳しくはコチラ→　http://devlove.doorkeeper.jp/events/7039

mfks17さんの華麗なバトンを受け、DevLOVE Advent Calendar ２度目のエントリーです。なので自己紹介は省略します。詳しくは前回のエントリーをご覧下さい。

マネージャの仕事って何だろう？

一方で、「もっと現場を見て下さい」という言葉は、（社内外問わず）今でもよく耳にします。むしろ「現場ブーム」とも言える昨今の方が、より耳にする機会が増えてきた気がします。

なぜでしょうか？

ここから先は私の個人的な意見ですが、「マネージャ」と呼ばれる人たちが、自分たちの仕事に求められているものとそのやり方を理解できず、結果としてメンバーに適切なアドバイスを出来ていないことが多いからではないかと考えています。

例えば、ソフトウェア開発における「マネージャ」の仕事って何ですかね？

線表や WBS を書いて、工数管理をすることですかね？
進捗が予定よりも遅れたら、メンバーを叱ることですかね？
さらに上位の人に報告書をたくさん出すことですかね？

工事現場など、肉体労働や定型的な作業をする場合のマネジメントであれば妥当かも知れませんが、各々が高度な専門知識を持っている知識労働者をメンバーとするソフトウェア開発でのマネジメントでは適さないと思います。なぜならば、

何を作るべきかが初めから予見しづらく、頻繁に変更が求められる仕事であること。
（専門分化が進み）マネージャがメンバーよりも全ての面で優れているということがまずないこと。
マネージャが全てを決めてその通りにメンバーに従わせるということに妥当性がないこと。
ある程度の報告は必要だが、報告書の量が売り上げにつながる訳ではないこと。むしろそのリソースを製品改善に回した方が売り上げ増加になりやすいこと。

それでは改めて、ソフトウェア開発で求められる「マネージャ」の仕事とは何でしょうか？私が現時点で考えている定義は、「自発的に目標を設定し、メンバーを成長させ、目標を達成し続けること」というものです。具体的には、

何を作るべきかではなく、自分たちの仕事が目指すべき目標を提示し、メンバーに具体的にどのような貢献をして欲しいかを説明すること。
メンバーの専門知識を融合させて、単なる人数以上のより大きな価値を提供できるようにすること。
メンバーに自発的な行動を促し、さらに成長させること。
自分自身も成長すること。

昔から使われている手法を特に考えもせずに使って「プロジェクト管理」をしようとして、メンバーの意見も聞かず、モチベーションを下げるような言動を平気でするような「現場を見ない」マネージャは、技術が更に進化して、より高度な専門知識を持つ知識労働者を必要とする現在のソフトウェア開発には適さなくなりつつあるなと感じています。おそらく、マネージャのあり方について再考する必要のある時期に来つつあるのかなというのが実感です。

エンジニアはマネージャに甘えてないか？

一方で、「現場を見ない」マネージャを批判するエンジニアを改めて見直してみると、「これはおかしいぞ」と思うことがあります。

例えば、技術的な難問にぶつかって、予定通りの進捗が上がらなかったとき。この際に、進捗が上がらなかった理由をキチンと説明しないエンジニアがいるんですね。曰く、「それはマネージャの仕事だから、自分が説明する必要はない」、「マネージャが理解できない難問を解いてやっているんだから、マネージャは文句言わないで協力しろ」と。（実話）

これって、ある意味エンジニアの思い上がり・甘えだと思うんですね。

自分たちエンジニアのやっていることがマネージャに理解されにくいという現状があるのであれば、エンジニアはマネージャにやっていることを説明すれば良いんです。もちろんそこで、マネージャが「現場を見ない」タイプのマネージャである可能性はありますが、そうであることを確認もせずに「ここから先はマネージャの仕事だ」って言って説明をしないのは、エンジニアというプロフェッショナリズムに対する怠慢だと思います。

もちろん、マネージャに説明することは心理的な抵抗が伴いがちなこと、また、つい「面倒くさい」と思ってしまいがちなことは重々承知しています。（かく言う私もよくあります。）でも、だから「言わなくてもよい」ということにはならないと思うんです。

エンジニアリングをより良くするためにマネージャの理解を得ることがプラスになるのであれば（多くの場合はなるはず）、話をすることはエンジニアの立派な仕事ですよ。