エンジニア組織と評価
多くの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, エンジニアマネージャーとエンジニアの管理職は色々ありますが、この上の定義に当てはまらない場合は、スキルの高いエンジニアが担う必要性はないと思います。
ミーティングで口先だけ動かす仕事なのであれば、人事や事業側に任せればよくてエンジニアのトップなのであれば先頭を切ってモノやサービスを創り上げていかなくては
いけないかと思います。
逆に採用などの裁量が与えられていない場合はここでいうリーダーに裁量を与えるべきで、そうでないと、スピーディーなエンジニアチームが作れないかと思います。
多くの現場でマネージャーと言う名のもとにただ単に伝言ゲームしかしていない所を見てきたため、これを見た人は今の現場がそうなっていないのか確かめてみてもいいのかも知れません。
登録日：
更新日：