The HIRO Says

If you smell what The HIRO is cooking!!!

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

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

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


最近芽生えた疑問

今回敢えて2度目のエントリーをして「現場」の話を書きたいと思ったのは、「現場」という言葉を、エンジニアが自分たちを理解してくれない上司やマネージャを批判するための言葉として使っている人が多いなと改めて感じたためです。

実は私自身も昔、自分の能力を「正当に」評価してくれないマネージャに対して、「もっと現場を見て下さい」と言っていたことがあります。(ここでの「正当に」とは、自分の能力に過信があったというよりは、日々の成果を見てもらえずに「こいつは出来ない奴だ」というマネージャの思い込みだけで評価されていた、という語感です。)

ですが、アジャイルコーチとしてチームの支援を続け、現場を「試行錯誤しながら価値を生み出す場」であると考えるようになってから、何らかの試行錯誤をし価値を生み出すために努力している人は、別にエンジニアだけではなく、マネージャやビジネスアナリストの人たちにも言えることだと感じるようになりました。
いま私の周りにいるマネージャは、「もっと会社をよくするためにはこういうことをしてみてはどうだろう?」と真剣に考え、私にも多くの相談をしてくれる人たちです。


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

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

なぜでしょうか?

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


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

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


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

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


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

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


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


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

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

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


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


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

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

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


エンジニアこそ自らをマネージすべき

先日、会社の先輩から、ドラッカーの『プロフェッショナルの条件』という本を勧められて読んでみました。
そうしたら、知識労働者の要件の1つとして、「自らをマネジメントできる存在」という定義をしているんですね。

度々使用している知識労働者」という言葉ですが、ドラッカーの本では、高度な専門知識を持ち、それをもって成果だす労働者として定義されています。ソフトウェア開発に当てはめると、エンジニアがこれに該当します。

実は、知識労働者であるエンジニアがマネージャに甘えず、自分自身をマネージできるようになることが、「現場を見ろ」発言に見られる「マネージャvsエンジニア」論を克服する一つの方法ではないか?と、ドラッカーの本を読んでから考えるようになってきました。

  • 自分自身が自らのマネージャとなり、解決策の見えない状況に対して仮説設定・検証して成果を出し続けられる仕組みをつくること。
  • それを実現するための検証の場として、現場を活用すること。
  • さらに現場を通じて、メンバーおよび自身を成長させること。


これこそが、もう一歩先のエンジニアとマネージャの関係かなと思っています。


次!

次は、アジャイルサムライ横浜道場などでよくお世話になっているすなださんです。最近コミュニティなどで発表される機会も増えてきたようで、どのような心境の変化があったのか、個人的に非常に興味深いです。