ゾンビ化するエンジニアがいる組織とは
前回の動画では具体的な例で説明してなかったので、今回は具体的な例とマイクロサービスで規模を小分けにする方法などを説明していきます。
#10.1 ゾンビ化するエンジニアがいる組織とは【政経】 - YouTube
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などで連携するようにすれば大きい１つの組織を細かい生産性の高い小さい組織に分けることができます。
これがマイクロサービスを利用する大きなメリットです
よく優秀な人がやめて使えない人が残るという話を聞きますが、優秀な人はそのチームで褒められる事が多いので、同じ評価者から褒められることに飽きて違う評価者の下でも褒められるかどうか試してみたいと思うようになります
それと異動する事で各エンジニアが持っているブラックボックスの中身を空けれることになるので、その点でもチーム外の異動はしたほうがいいです
強引に異動して環境が変わったことによるストレスでエンジニアが退職するかもしれない懸念はありますが、属人的なブラックボックスを放置したまま退職されるよりリスクは低いかと思いますエンジニア的にも違う環境でもいい評価を受ける対応能力が身につくかと思います
今回ゾンビ化していると説明しましたが割と一般的でよく見る組織運営かと思いますが、その今あるエンジニア組織に疑問を持って改革に取り組んでも損はないと思い今回の動画を上げてみました。
こういった巨大組織で働くエンジニアは楽なのでそのままがいいと思いますが、できれば事業者、社長や会社代表の目に届けばと思います。
登録日：
更新日：