#10 エンジニア組織と評価
多くのIT企業でエンジニアの組織や評価が困っている企業が多いのでは
と思います。
20人を超えるあたりから組織が大きくなりすぎて
誰がどのタスクをして、どれくらいの生産性で
どれくらいのスキルがあるのかをマネージャーが把握しづらく
なってきているのではと思います。
四半期に1回ぐらいのOne On Oneミーティングでしか
マネージャーと１スタッフと話さないって事は大きくなってきてる
組織のあるあるかと思います。
ただ、２０人をまとめるという発想自体が間違いです。
アマゾンのジェフ・ベゾスがチームはピザ２枚を分けて満腹するぐらいの人数
と言ってるぐらいなので、４〜７人くらいって事だと思います。
小松自身の経験でもチーム全員とプロジェクトをしっかり管理できる人数は
１０人までが限界で１０人の時でも残業２０％ぐらいしてたぐらいでした。
それ以上超えそうになると別にチームを分けてリーダーも立てて
そのリーダーに権限と裁量を与えて
完全に任せるといった体制にしていました。
よくマネージャーの採用項目にある
30人〜50人をまとめた経験必須とかの欄がありますが、
50人をまとめるなんてできないので、
ほぼ伝言役の仕事しかしてないと思います。
よくあるのが、束ねているチームの人数が多いほどその
リーダーが優れいていると勘違いしている事です。
リーダーの力量とチームの人数は関係ないです。
一番パフォーマンスが発揮するのは
5人プラスマイナス２ぐらいが一番チームの生産性が上がる人数だと思います。
組織が大きくなってくると、ピラミッドにしてしまいがちになります。
・トップのマネージャーが自分の横に来られるのは嫌
・トップのマネージャーが人に任せる事に対して不安
・マネージャーになると責任範囲が広くなるのでなりたい人もいない
などの理由でトップのマネージャーが横にマネージャーを置かず
自分の下に置きたがります。
まず多くのIT企業が勘違いしていて、技術とサービスを分けようとします。
チームはサービス中心のチームにすべきで技術中心ではないです。
「技術を極める」「技術中心の会社」という言葉は存在しません。
いかによりよいサービスを提供できるか、そのサービスのための実現方法が
技術で、技術が目的になってはいけません。
例えば、スマホのライブ動画で自由にユーザー同士がライブ発信できて
いいライブであればなげ銭できるような仕組みをWEBで実現したい
などの場合WebRTCと決済会社を連携させて開発して実現する事が技術です。
しかしよくある「技術を極める」時に出てくる話が、
シンプルなjavascirptで書けばいい所をTypescriptでこねくり回して
リリースの時間が伸びて、引き継ぎもやりづらいコードになってしまったっていう
話を聞きますが、そうなるとその素晴らしい技術は「誰が得しているの？」
てなります。
あと技術中心でチーム構成すると、フロントエンドチーム（javascriptチーム）
、バックエンドチーム（PHPチーム）
インフラチーム（AWSチーム）みたいに分かれてしまい
フルスタックエンジニアが２度と生まれないチーム体制になってしまいます。
別の動画でも説明していますが、WEBの技術はそこまで難しくないです。
企業や現場がチャンスを与えて一年働けばフルスタックエンジニアになれます。
技術中心でチーム構成してしまうとそのチャンスも失わせる事になり、
各エンジニアが好きな技術で属人的にさせてしまうことさえあります。
そういった問題を解消するには、そもそものエンジニアの評価を事業者がやれば
リーダー不足、マネージャー不足を解消できるのではと思います。
では事業者がどうやって評価できるのか？と疑問に思うかもですが、
評価だけであれば、機能に対しての工数が少ないのか多いのか
ぐらいはわかると思います。
あとは、同じような案件をエンジニアに見積もらせる時に複数人に見積もり
とアサインしてもらい比較ができるので、エンジニアのパフォーマンスの
評価も可能かと思います。
大企業であれば半年に1回ぐらいに給料やプログラマーの人数に対しての
機能開発の量やリリースまでの速さを事業者側同士で比べる事もできます。
そうすればプログラマー、できないプログラマーというのが
CTOでなくても自然にわかると思います。
そうなればAWSチームみたいに、事業者からしたら何をやってるかわからないような
チームはなくなって、自然にフルスタックのエンジニアが生まれる体制になるのでは
と思います。
事業者が評価してしまうとコードが汚くなって、負債が増えてしまうのでは
という懸念もありますが、負債が増えそうなのであれば、同じチームが
嫌がるので、そこの心配は不要かと思います。
スタートアップなど小さい企業が新しいサービスを始める場合も
事業者、つまり経営者がエンジニアの評価やエンジニアの採用もしているぐらいなので
大手企業の各事業担当者がエンジニアの評価をするのはなんら不思議でもありません。
これも別の動画で説明しましたが企画側、事業側も詳しくなるべきです。
海外では当たり前のように元プログラマーがサービスを考えています。
サービス中心のチームにして所属しているエンジニアをそのサービスの
売上にコミットすべきかと思います。
利益が上がってその分所属しているエンジニアにボーナスとして分配すれば
モチベーションも上がり、サービスを考えられるエンジニアが増える
事になります。
日本では利益やコストにこだわるエンジニアが極めて少ないです。
さらにシステムのコストに関してはエンジニアしかコストカットできないので、
コストカットできる余地は大きいにもかかわらず、
無駄使いになっている現場だらけです。
「なぜ日本のWEBサービスは海外で通用しないか」の動画でも取り上げたように
日本ではプログラマー・エンジニアがサービスを考える事が少ないので、
世界的に通用するサービスがないです。
なので、サービス中心のチームにすればサービス指向のエンジニアが増え世界的に
通用するサービスも生み出される確率も高くなります。
チーム単位は4人〜7人くらいのチームに分けて
そのチームのサービスに対しての利益に全員がコミットするべきです。
チームを細かく分けると、各チーム間での連携が取れないのでは？
と思うかも知れませんがそこをDBとAPIとリポジトリでチームの責任の
範囲を明確にできるのではと思います。
サービスにコミットして開発をしていくとそのサービスに愛着も湧きいいのですが、
受講生、エンジニア取材募集しています。
〜〜全文〜〜
デメリットとしてはプログラマー・エンジニアの異動がしづらくなる所です。
それに、ずっと同じサービスで同じような仕事をしているとどうしても
マンネリ化して生産性が下がってしまうのも事実です。
同じ人が同じ部分を開発してしまうので、属人的になる可能性もあります。
なのであらかじめ、同じサービスに3年以上居座る事はなく3年立てば異動
する事前提で採用なりチームを構成しておくといいかと思います。
ここでリーダーの定義をしてみます。
・チームで一番スキルが高い
・チームの中で誰が抜けても代わりになれる
・採用の判断ができる
・予算は企画と相談して決定権がある
・経費の判断もできる
・技術選定もできる
・自分でもコーディングをする
CTO, VPoE, エンジニアマネージャーとエンジニアの管理職は色々ありますが、
この上の定義に当てはまらない場合は、スキルの高いエンジニアが担う必要性は
ないと思います。
ミーティングで口先だけ動かす仕事なのであれば、人事や事業側に任せればよくて
エンジニアのトップなのであれば先頭を切ってモノやサービスを創り上げていかなくては
いけないかと思います。
逆に採用などの裁量が与えられていない場合はここでいうリーダーに裁量を与えるべきで
そうでないと、スピーディーなエンジニアチームが作れないかと思います。
多くの現場でマネージャーと言う名のもとにただ単に
伝言ゲームしかしていない所を見てきたため、これを見た人は今の現場が
そうなっていないのか確かめてみてもいいのかも知れません。
