#10.2 エンジニア組織 ケーススタディ

もう一本動画を作ろうと思ったのですが、面倒だったので、ブログにしました。

具体的な組織と単価も例にして説明していきたいと思います

ケースA　一般的な30人以上のチームを例に挙げます

このような組織ではピラミッドのトップが正社員の事が多く月100万円ぐらい
で上から2段目のマネージャー・リーダーが正社員で月60万円〜80万円くらい
もらっている事が多いです。
そして、末端のエンジニアがだいたい20万〜50万円くらいで
事業側は月70万円くらいもらっているマネージャーがいて下に
月20万円〜50万円くらいもらっている事業者・マーケターが3〜4人ぐらい
このような組織が一般的な組織図と給料体系かと思います。

前回の動画でも説明した通りこの組織では伝言ゲームが多発して
社内調整・社内政治が増え一人辺りの生産性が低下しています。

そこでマイクロサービスを利用して30人のチームを5人単位の6つに分けます

ケースB
30万円の事業者
80万円のリーダー
4人は25万円

このケースBの場合は事業者のスキルも高くなくチームリーダーが一人
単価が高く、他のエンジニアは安くなっています。
このケースが組織に関しての説明動画10.0のリーダーが強い理想的なチームです
リーダーのスキルが高いので他のエンジニアは未経験でもリーダーが育てられる事
ができるという組織になっています

ケースC
50万円の事業者
40万円のエンジニア 2人
25万円のエンジニア 3人
設計、セキュリティなどのコンサルをで月20万円程度で依頼

スキルの高いリーダーが不在の場合の理想のケースです
組織の説明動画10.0ではケースBのみが理想のケースとしましたが、
事業者のスキルが高ければそのチームのエンジニアのスキルがそこまで
高くなくてもチームとして成り立ちます

これらのケースB，Cの場合
リーダーもしくは事業者がスキルが高く理想的なチーム編成された場合
エンジニアとしてのキャリアとしてはチームのマネージャーになるか
事業者にならない限り高い給料がもらえないという事です
そして、高い給料がもらえるポジションもごく限られてしまいます。

そういった事もあって小松自身がフリーランス時代にエンジニアという職種から
Webディレクターという職種に変更して働いていた理由です
ただ現在ネットを調べる限り転職の需要と供給でいけば
Webディレクターやマーケターなどの事業者側よりも
エンジニアの給料の方がまだ高いことになっています

エンジニアであってもチームを構成する立場つまり雇う側でなければ高い給料は
望めないという事になります。
さらに優れたマネージャーが増えれば増えるほどそれ以外のエンジニアの給料が
下がってしまう事になると危惧し、フリーランスからまた会社員に戻ったという
のが理由です

しかしながら、このようにフリーランス時代に小松が思っていたIT業界の給料の
推移は間違っていました。

優れたマネージャー優れた事業者が増えればというのが条件でしたが、実際
そこまで増えなかったこととそれ以上にエンジニアの需要が上がった
事が原因でエンジニアの給料は上がり続けています。

それでも将来的にキャリアを考えた場合はできるだけ上の管理職になることを
おすすめします

上に行けば行くほど任される裁量の範囲が大きくなることで、チームとしての
生産性をいかに上げれるリーダーなのかで高い給料をもらう上で分かれてくる
のではと思います。

管理職に就くためには大手企業や有名企業での経験が有利に働くかと思います。
本質的にはいかに本人のスキルがあるかどうかなのですが、今のIT業界の現状です

技術的にはフルスタックで身につければ管理職に就くチャンスが増える事になるかと
思います。とはいえ実践プログラミングの範囲の事を学べばフルスタックの大部分は
まかなえるかと思います。

管理職に就きたくなく、ある特定分野を極めたいという人もいるかと思います。
しかしながら例えばJavascriptを極めたハイエンドエンジニアでないと開発できない
ポジションの求人があったとするならば、そもそもそういうシステムにしてしまった
プロジェクト自体が破綻しているかと思います。
システム開発は後から未経験者でも引き継げるように務める事が大事なのですが
そうなっていない会社、チーム、プロジェクトも多いことも事実です。

なのである特定の分野しかできないエンジニアのポジションもまだまだ
あると思いますが、遠い将来優れた管理者が増える可能性があるのでフルスタック
に技術範囲を広げておいたほうがいいかと思います

他のシステム開発組織が生産性が低いままなのであれば自分だけこのような論理で
開発体制を築けば他のチームとおおきな生産性の差をつける事ができるのではと思い
他ではやってない色々な事を試しました。

1.未経験を採用
　自分自身のスキルに自信があったので、未経験を雇って育てる方針で
　採用しました
　中途でハイスキルなエンジニアを雇うよりリスクは低く単価も低く
　抑えられる事ができます

2.プログラミングで採用
　一般的なピラミッド型のチームではプログラミングを応募者に
　させてトップの採用する人がプログラミングをチェックする時間がないこと
　がほとんどです。
　その事もあって、チームを小分けにしてより現場に近い立場の人が採用すれば
　プログラミングでの採用も可能になるのではと思います

3.リモートワーカーを採用
　コロナが蔓延する前からリモートワーカーの採用をしてました。
　今では一般的でしたが、当時はセキュリティ、勤怠管理で問題があるとの
　事でほとんどのエンジニアが会社で働いていたと思います。
　勤怠はプログラミングのGitの成果物で管理すればクリアできて
　セキュリティに関しては個人情報に関わる機能、ページを別レポジトリに
　切り出して、運用すれば
　入ってきたばっかのエンジニアには個人情報のデータが入っていない部分の
　開発に入ってもらえればクリアにできるかと思います。
　実際個人情報が入っているテーブルは全体の１割ぐらいなので、分ける事は面倒
　ですが、一回分けさえすればリモートワーカー採用の最大の障壁をクリアできる
　かと思います。

4.外国人を採用
　大手IT企業のように意図的に外国人を雇うというより、日本人と同じ基準で
　日本語が話せない外国人の募集をかけると、日本人の20倍以上の応募が来た
　経験があります。
　応募者の優劣に差があるため、そこでプログラミングによる試験を実施する
　事でより時間を節約しながら採用を可能にすることができました。

5.アルバイト採用
　いきなり正社員を雇うのはクビにできない分リスクが高いので、プログラマーの
　採用の条件はアルバイトの雇用が条件の一つでした。
　プログラミングで応募者をふるいにかける時点である程度できる人に絞られますが
　それでも一旦チームに入ってからのパフォーマンスは想定と違う事があります。

6.10人以上になった時にチーム分け
　リーダーに、チームの採用権限、評価と給与査定、技術選定、コーディングスタイル
　など全て任せました。
　これぐらい権限と裁量を渡さないとマネージャーになる面白みがないかと思います
　よく管理できるエンジニアが少ないという話を聞きますが、よくよく
　聞いてみると上記の裁量は一切渡さずに何人かをまとめてほしいというポジションが
　ほとんどだと思います。
　よく転職エージェントから頂くポジションもこのポジションで
　裁量はない、でも10人〜20人をまとめてほしいというポジションです。
　だいたい大手で利益も高い会社なので、給料はいいですが、10人以上をまとめる
　という考えも間違えで、裁量も与えないというのも間違えです。
　中途採用で入って既にシステムを知っているエンジニア20人の管理となると
　仕事内容は伝言ゲームと社内政治しかないかと思います。

7.仕事を技術でわけない。
　javascriptをのタスクだからこのエンジニアと技術で分けてしまうと
　1つの単純なタスクにPHPのモデル担当1人、コントローラー担当1人、View担当1人、
　Javascript担当1人と複数人が携わりシステム連携の部分などのコミュニケーション
　コストが発生してしまいます。
　フロントのタスク、バックオフィスのタスクとして業務内容でエンジニア1人に
　タスクを任せれば効率よくタスクを消化できエンジニア自身も
　フルスタックのキャリアを積めることになると思います。

8.単価を下げる
　パフォーマンスが悪いフリーランスのエンジニアには単価を下げた
　事もあります。
　チームが7人以下であれば日頃のパフォーマンスがわかって自分自身も
　コーディングできるのでコーディングで何が正しいかを知らしめる事で、
　同じチームに対して厳しい姿勢でいられる事もできます
　10人以上管理するとなると各エンジニアの仕事内容を完全に把握することは
　難しくなるので、どうしてもチームのエンジニアに甘くせざるを得なくなります
　そうなると生産性は落ちるばかりです

9.ローテーションをさせる
　同じ業務領域でタスクをこなしているエンジニアに同じようなタスクを
　任せる事が一番早くて簡単なのですが、長いこと同じような領域で任せてしまうと
　属人的になってしまいます。
　なので、ローテーションをさせて違う領域のタスクをアサインさせますが、
　なかなか一筋縄ではいかないかと思います。
　エンジニア自身も慣れ親しんだ自分のシステムからの追加改修の方がやりやすい
　ですし、他のエンジニアが作ったシステムをそのエンジニアに聞きながら
　追加改修するとどうしても自分と違うコーディングは見づらく見え
　その見づらいソースコードに合わせるのは初めの内は苦痛かと思います
　そういう事もあってローテーションを行って属人的なシステムを解消している
　チームは少ないのではと思います

10.違うチームに送り込む
　だいたいの場合はパーキンソンの法則で予算が最大に取れる時にチームが最大人数
　になってしまいその状態が続いてそれでも人が足りない状態になってます
　今までチームにいた人数分タスクがあってそのエンジニアの領域のタスクを
　継続して同じ人に任せているので、そんな状態でわざわざ自分のチームの
　エンジニアを他のチームに送り込もうとする人は少ないかと思います

　キャリア的にも管理する人数が減ればマイナスになります
　　一般的に管理してきた人数が多いいほど転職にも有利になるためです。
　　今までで「100人の統括した事があります」って言ってた人がいましたが、
　　絶対管理できてなかったかと思います。しかしながら、そんなハッタリ
　　が転職に有利なのも今の日本のIT業界の現状かと思います。
　　チームの人数の多さは管理職のスキルではなく事業の予算の割当が多い
　　というのが本質なのですが、社長やCTOも管理してきた人数＝管理能力
　　と勘違いしている人が多いかと思います。
　　一般的に管理するチームの人数を減らす＝管理能力が低くなったとみなされる
　　ことが多い状況で他のチーム、部署に優秀なエンジニアを送り込む
　　事ができる管理職のエンジニアはほぼ皆無に近いかと思います。
　
　前回の動画で同じ評価者で同じような仕事をしていた場合どうしても
　マンネリしてしまいモチベーションが下がると説明しました。
　加えて管理者のエンジニアが優秀であればエンジニアのスキルが未経験、
　初心者レベルでもいいチーム編成でも組み立てられると１と説明しましたが
　未経験者でも月日が立てばスキルが上がることになるので、昇給なども発生します
　エンジニアが成長することは喜ばしい事なのですが、スキルアップと昇給は比例する
　のでマンネリ解消とエンジニア本人の昇給を実現するために全然違うチームに
　異動させた事もあります。

　エンジニアとりわけ優秀なエンジニアの数を減らして
　生産性を保つ事に成功した経験者も少ないのではないかと思います。
　これも事業者マインド、サービス指向の視点でシステム開発を考えているから
　こそできる事かと思います。

こういった理論でできる限り多くのIT企業やIT部門が生産性または生産効率を
あげてもらえればいつか海外でも通用するようなサービスが産まれるかもしれません