大規模なエンジニア組織
管理する人数
まず、結論。５人単位のCTOがベスト
３~7人 予算が 200万円~400万円
元々は社員2人 = 50万円
業務委託3名 = 210万円
それで小規模のチームを運営していました。
260万円が合計です
働いているうちに、業務委託の2名がパフォーマンスが悪いので契約を終了しました。
その代わりに5名くらいの社員を雇えるんじゃって計算でした。
2名で130万円25 x 5 = 125万円の計算です。
しかしながら、なかなか雇えなかったのを覚えています。
CTOでもこんな勘定している人は、少ないと思います。
雇用は人件費
エンジニアの組織を考えれば雇用=コストです。
コストを下げる効率がいい組織って事はイコール誰かをクビにする事になります。
なので、１CTOとかマネージャーとかの判断でない所が多いと思います。
なぜなら日本の社員雇用の法律がガチガチすぎて一旦雇うと解雇はできません。
そして、一旦給料も上げると下げれないとかです。
チーム横断は逆に非効率
横断チームを作るとサービスへの関心が薄くります。
技術がコモディティ化してるので得る知識は少ないのでメリットはないかと思います。
チーム横断で利用できるSDK作ったから、それをチーム横断で利用するのは最悪のパターン。
横断チームのSDKの押し売りが始まります。
SDKの導入始めのチームがほぼテスターみたいになったりします。
横断チームを作成というよりは、チーム間での不具合や障害を共有するに留めるだけにしておいたほうがダメージは少ないかと思います。
最適化されたチームの定義
５人体制CTOの定義はチームの誰が欠けてもCTOが補える事
CTOもハンズオンで作業を行うこと
チーム全体の責任を負う
技術的に分けるのではなくてサービスで分ける
といった定義がいいのではと思います。
マイクロサービスのベストプラクティス
１DB、１レポジトリ毎に分かれてる
責任の所在が分かれてる
あるAPIのレスポンスが遅かった場合、そのAPIのURLでどこのチームかがすぐに判断できてそのチームは１つのレポジトリの調査だけすれば、DBのレスポンスの遅い原因を把握できるっといった具合であれば、責任、調査のしやすさ的にベストプラクティスな分け方かと思います。
業績連動がいいのでは
業績連動のメリット
1. モチベーション
2. サービス指向になる
業績連動のデメリット
1. となりの事業のエンジニアになればボーナスがもらえるなどの不満が出る
デメリットの相殺として、採用時に状況を伝える。
例えば、スキルの高い仕事だが、利益が少ない場合は需要と供給で、必然的に利益が高いチームに人があるまる、人が集まれば必然的に給料も下げられるのでは？という考え方。
給与体系
年収４００万円以上の基本給は上げない方がいいのではと思います。
それ以上は全てボーナス至急、従業員の給料は変動であるべきかと思います。
裁量労働よりも全員エンジニアは時間給で計ったほうが、正しい工数の見積もりと評価ができるのではと思います。
今の日本の就業規則で一度基本給を上げると下げれないのは、従業員の怠惰を招いてしまいかねないと思います。
下げられるかもっていうプレッシャーはあったほうがいいのではと思います。
なので倍以上のボーナスで年収を補うのが長期的にはいいかと思います。
でないと保守的な従業員しか会社に残らないという結果をまねくのではと思います。
評価をどうするか
３６０度評価、１８０度評価にしても、、、
エンジニアのカウンターパートナーに評価させるのも結局比べる事ができない状況がほとんどなので、厳しいと思います。
結局は５人チームのリーダーがあつまり４半期毎に評価し合う１８０度的な事が一番なのかも！？
もしくはやはり、トップのCTOがいてCTOが他のリーダーを評価するっていう一般的なやり方が妥当なのかも。。
結局は評価しあうとしても、キッチリ評価する制度を導入してしまうと、どうしてもギクシャク感が出てしまいガチ。
１５人以上になるとチームが３つ以上できるので３人のリーダーに１０ポイントずつ渡して自分以外の２人を評価するっていうやり方はどうなるのか気になる所ではあります。
１０人以下であれば、社長とCTOだけで評価と給料を決めるって事で話が早いと思います。
登録日：
更新日：