#10.1 ゾンビ化するエンジニアがいる組織とは
前回の動画では具体的な例で説明してなかったので、今回は
具体的な例とマイクロサービスで規模を小分けにする方法などを
説明していきます。
5人チームのケース
5人ぐらいのエンジニアチームの場合は前回の動画でも紹介した通り
エンジニアの一人あたりの生産性が一番高いチーム構成ではあります
事業としてはスタートアップとか赤字かどうかぐらいの状況かと思います
予算が少ないので社長がエンジニアの採用や評価、昇給などを考える事が
多いです。なので、社長が24時間働いているみたいになります。
その社長判断で一番スキルが高いと思うエンジニアがCTOになるぐらいです
10人以上チームのケース
社長がエンジニアの採用、評価を全て細かいところまでできなくなってきます
CTOが他エンジニアを採用、評価、給与査定をするようになります
CTOでも末端の細かいシステムのところまでは把握できなくなります
CTOが他部署とMTGでも実際手を動かさないのでただの伝言ゲームのタスクが増えます
例えば、「このページのここの数値はどのようなロジックで成立していますか？」
などの事業側からの質問にCTOがエンジニアチームの
そのページに詳しいエンジニアに聞いて事業側担当者に伝えるっていう伝言ゲームが
発生します
あとは、インフラの問題、アクセス権、有料ツールの契約、委託会社との契約書、
経理処理など雑用の割合がCTOに増えます
スキルと単価の高いCTOが雑務と伝言ゲームのタスクをする分生産性が下がります
前の動画のルールでいけば、10人以上になった場合は2人事業者側に担当者を設け
10人のチームを2つに分けて2人の事業者がその分かれたチームの一つを担当して、
採用、評価、昇給をするべきかと思います
なので、10人になる前にチームを拡大するとなった時にエンジニアだけに任せる
のではなく、担当になった事業者も一緒になって採用をしていってエンジニアを増やす
という形になるかと思います
そうなった場合は
「このページのここの数値はどのようなロジックで成立していますか？」
などの事業側からの質問は直接担当エンジニアに聞くことになるので
伝言ゲームが発生しません
30人以上のチームのケース
事業としては大成功しているので、エンジニアに対しての予算は多いです
サービスの歴も長くあの人しか知らない仕組みみたいな属人的なシステムが
多くなってきます
3段階、4段階のピラミッドができる
トップのCTOはもちろんトップ2段目も末端のシステムの把握ができない
ピラミッド型の組織になるので、承認と決断する人が現場をあまり知らないまま
承認、判断することになります。
現場の情報を細かく知ろうとすればその分情報収集、決断がさらに遅くなります
そのため、どう情報を伝えるか、調整するとかの社内調整という名の社内政治に
かかる時間が増えてきます
トップから2段目まではシステムを把握しておかないといけないため
末端からすれば無意味なミーティングが増えます
機能追加などの仕様もトップから伝わってくるので、その分伝言ゲームが増えます
これらの要因でいわゆる官僚主義的な組織になり、
一人あたりの生産性は最悪になります。
パーキンソンの法則！？
パーキンソンの法則とは予算があればあるほど必要な費用が膨らんでいき
予算のMAXまで使われる事です。
さらに悪い事には30人を抱えるシステムの予算になると事業者側も把握できず
システム側の費用を言い返す事ができないため
システム側の言い値になりがちになってしまいます
時間に余裕ができるので不必要な勉強会が増える事になります
人数が多いのでエンジニアの好みの技術に対してのチームが誕生します
フロントエンドチーム、AWSチームなどなど
そうなると追加機能の開発でエンジニアチーム内でも伝言ゲームが
発生する事になります
DBからデータを取得するエンジニア - バックエンドエンジニア
ページをつくるエンジニア - フロントエンドエンジニア
さらに、エンジニア自身も同じ領域のみでの仕事をする事が増え
フルスタックのような縦に伸びる技術が身につかなくなります
これらの事でよりシステムに費やす予算が増え
一人あたりの生産性は下がる事になります
一旦予算が増えた場合その予算を減らす事はエンジニアの解雇などに繋がるため
なかなか予算を削ることは難しいのが一般的です
最後にこれらの組織が全て正社員で構成されている時はそのエンジニアが
ゾンビ化する可能性があります。
システム内製化の動画で説明していなかった部分もあるので、改めて説明します
エンジニアがゾンビ化！？
これだけの追加機能で！？っていうぐらい開発スピードは遅くなります
エンジニア側からすれば属人的で代わりのエンジニアがいないため、
いくらでも遅く開発しても文句が言えない状況にあります
事業者側、エンジニア側問わずシステムの仕様の知識があることが社内での立場を
優位にする事になるため、どうしてもシステムの仕様に詳しいエンジニアの立場が
優位になります。
昇給も限界なしに上げることができないため、ある程度の時点でブレーキが
かかります。
どうせ昇給がないのであれば、
サボっても一緒と考える社員が増え働かなくなります
以上の結果で開発が遅く、文句言って働かないゾンビ社員が増える事になります
このような30人以上のチームで構成している会社は事業は成功しているので、
そこまで問題ないのかもしれないですが、今までの経験上、一人あたりの生産性が
低くなっている事は事実です。
人数が増えても生産性と保守性を維持するには冒頭で述べた5人チームに分ける事を
おすすめします。
CTOというようなポジションは設けず、ピラミッド型より台形型の組織にして
あくまで事業者がその5人の採用、評価、昇給を判断する必要があるかと思います
ゾンビ化を防ぐためにも組織を硬直したままにはせず一人のエンジニアが同じチーム
同じ評価者で3年以上働かないように全然違うチームの違う評価者の下に異動させる
事をおすすめします。
30人だったチームを5人規模のチームに分けて、各サービスをAPIなどで連携するようにすれば
大きい１つの組織を細かい生産性の高い小さい組織に分けることができます。
これがマイクロサービスを利用する大きなメリットです
よく優秀な人がやめて使えない人が残るという話を聞きますが、優秀な人は
そのチームで褒められる事が多いので、同じ評価者から褒められることに飽きて
違う評価者の下でも褒められるかどうか試してみたいと思うようになります
それと異動する事で各エンジニアが持っているブラックボックスの中身を
空けれることになるので、その点でもチーム外の異動はしたほうがいいです
強引に異動して環境が変わったことによるストレスでエンジニアが
退職するかもしれない懸念はありますが、属人的なブラックボックスを
放置したまま退職されるよりリスクは低いかと思います
エンジニア的にも違う環境でもいい評価を受ける対応能力が身につくかと思います
今回ゾンビ化していると説明しましたが割と一般的でよく見る組織運営かと
思いますが、その今あるエンジニア組織に疑問を持って改革に取り組んでも
損はないと思い今回の動画を上げてみました。
こういった巨大組織で働くエンジニアは楽なのでそのままがいいと思いますが、
できれば事業者、社長や会社代表の目に届けばと思います。
