エンジニアと経営のクロスオーバー

第9回 委任が苦手だと会社は成長しない

この記事を読むのに必要な時間:およそ 1.5 分

エンジニア出身社長の経営する会社の規模は,相対的には規模が小さい場合が多いかと思います。理由の1つには,この連載の当初で挙げたように,ビジネスモデルを考えるのが不得手なことが多いというものが考えられます。また,そもそも起業したのが「やりたいビジネスを実現するため」ではなく「働きたいチームを作りたいから」⁠つまりそもそもコンパクトで居心地のいいチーム自体が手段ではなく目的になっているというケースもあるでしょう。さらに別の理由として,エンジニアは委任が苦手,かもしれないから――それが今回のテーマです。

やり方を細かく指示するのがsupervised,出てきた結果のみ評価するのがdelegation

そもそも,委任というのは何でしょうか。英語にするとdelegationです。オブジェクト指向などに出てくる継承・委譲の委譲もdelegationですが,委任と委譲はちょっと違います(そもそも委譲はdelegationとはちょっと違いますが,それはさておき)⁠

委任というのは,その字面のとおり,委ねて任せることです。マネジメントをしていくときに,1つのハードルというかステップになるのが,この委任です。

一般的には,マネージャーとスタッフの関係において,最初から委任が発生することはあまりありません。マネージャー側のマネジメントスキルの問題とか,スタッフ側の力量とか,相互の信用・信頼関係の程度などがある程度そろわないと,委任というのはなかなかできないためです。最初は,事細かにやる内容を指示し,そのプロセスもマメにチェックし,相談に乗りながら仕事を任せていく感じだと思います。そういう業務の進め方をsupervisedといいます。

それに対して委任は,欲しい結果のみを伝え,その取り組みや進め方にはいちいち関与せず,出てきた結果を評価します。ちょっとたとえとしてはイマイチですが,supervisedは鵜匠,delegationは鷹狩りのような,⁠つながっているか,つながっていないか」という違いがあります。言ってみれば,supervisedはローリスクローリターン,delegationはハイリスクハイリターンです。

supervisedの場合,自分も監督しながらになるため,その業務からはあまり手を離せない代わりに,出てくる結果もそこまでおかしなものになることはありません。一方でdelegationは,自分が完全に手を離せる代わりに,出て来る結果が期待と全然違う可能性もあります。

supervisedでは組織の段数が増えても負担が同じ,もしくは高くなる

supervisedは一番の違いは,supervisedは拡大に限界があるということです。監督の手綱を自分が持つ必要があるので,100本つまり100人の直属スタッフと関わるのは現実的ではありません。監督能力が低いと3人くらい,高くても30人くらいではないでしょうか。それに対してdelegationは,直属スタッフの数を無限に増やせるわけではないですが,supervisedの数倍まで増やせるでしょう。

そしてここが重要なのですが,delegationの場合はその先もdelegationにすることが可能になります。もちろん,delegationした先のスタッフの能力が,さらにdelegationを任せられるくらい高い必要はありますが。それに対してsupervisedの場合,supervisedの先にsupervisedを置くことはできますが,⁠自分がsupervisedの先のsupervisedまで監督する」必要があります。

つまりdelegationの場合,段数が増えても自分の負担は増えませんが,supervisedは段数が増えても直接監督する人数が増えるだけで,増える負担は同じ,もしくはもっと負担が高くなることすらあります。プログラミングでいうと,supervisedは,関数から関数を呼ぶときに引数とか返り値をずっと渡し・戻し続けなければいけないようなものです。

まめに監督するのは,一見親身なようで,スタッフへの負担を強いているようなもの

このように,supervisedな手法でマネジメントをしていくと,自ずと組織の拡大のキャパシティに限界が出てきます。ところがエンジニアの場合,私の経験とか感覚的には,業務のdelegationが苦手というケースが多いような気がします。

  • 「任せた業務をどう進めているか気になる」
  • 「細かくチェックして,必要なら軌道修正したい」
  • 「任せっきりにして放置は不安」

という感じです。それどころか,⁠業務を任せた場合に,その内容をまめに監督するのはよいマネジメント」というポリシーがある気もします。

もちろん,それはそれでまちがいではないのですが,全部が全部そうしてしまうと,前述したようにマネジメントできる限界を拡大できないため,そのうち組織の拡大にブレーキがかかります。つまり,なんでもかんでもsupervisedで進めようとするのは,一見親身なようで,じつはマネージャーひいてはトップ自身がスタッフへの負担を強いているようなものなのです。

スタッフを信用・信頼し,委任で任せられるところはズバッと任せる,もしくは任せられるように成長を促す・教育することで,組織は大きく強くなり,マネージャーもスタッフも長く安定して業務を続け,向上していくことが可能になります。

著者プロフィール

山崎徳之(やまざきのりゆき)

青山学院大学卒業後,アスキー,So-netなどでネットワーク,サーバエンジニアを経験。オン・ザ・エッヂ(現ライブドア)のデータセンターである「データホテル」を構築,運営。2003年にベイエリアにおいてVoIPベンチャーであるRedSIP Inc.を創業。2006年6月に株式会社ゼロスタートコミュニケーションズ(現 ZETA株式会社)を設立,代表取締役就任(現任)。ECソリューションの「ZETA CX」シリーズとして検索エンジンやレコメンドエンジンを開発,販売している。

blog:http://blog.zaki.jp/
社長コラム:https://zetacx.com/column

コメント

コメントの記入