🏠 ホーム
キャリア
エンジニア組織
働き方
炎上のシステム現場

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

  フリーランスCTO >     エンジニア組織 >  

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

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

前回の記事

サンプルケース

ケースA

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

このような組織ではピラミッドのトップが正社員の事が多く月100万円ぐらい
で上から2段目のマネージャー・リーダーが正社員で月60万円〜80万円くらい
もらっている事が多いです。

そして、末端のエンジニアがだいたい20万〜50万円くらいで

事業側は月70万円くらいもらっているマネージャーがいて下に 月20万円〜50万円くらいもらっている

事業者・マーケターが3〜4人ぐらい

このような組織が一般的な組織図と給料体系かと思います。

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

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

ケースB

このケースBの場合は事業者のスキルも高くなくチームリーダーが一人

単価が高く、他のエンジニアは安くなっています。

このケースが組織に関しての説明動画10.0のリーダーが強い理想的なチームです

リーダーのスキルが高いので他のエンジニアは未経験でもリーダーが育てられる事ができるという組織になっています

ケースC

設計、セキュリティなどのコンサルをで月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部門が生産性または生産効率をあげてもらえればいつか海外でも通用するようなサービスが産まれるかもしれません

登録日：

更新日：

by

コメント         tweetでコメント