2024-03-20

IT企業のチーム内ロール構成事例集

分業で組織のパフォーマンスを最大化する

他社のチーム構成をまとめたい

営業ができて技術もわかりコミュ力高く事業、プロダクト開発も推進してくれるスーパーマンで全て構成された組織があれば市場変化へ耐性も強いです。一方でそういう人は組織に属するメリットが薄くフリーランスなど別の業態での方が活躍できる可能性もあります。

会社という業態は言ってしまえば分業によってスーパーマンでない人、凡人の組み合わせで収益を上げる仕組みの側面もあって、投資家目線で言うと例えば法的参入障壁のライセンスを持っている企業が採用容易性の高い人材を採用してしまえば収益が100倍になるビジネスの方が投資対象になりやすい可能性があります。

IT企業においてインターネット上には各社のチーム構成の資料がちらほら上がっていることがあり、参考までにまとめておきます。

食べログ(2021)

https://qiita.com/tkyowa/items/c0eab592d5bc356eefd6

モバイルアプリの開発でチーム内にウェブとアプリのエンジニアを含む構成。

PM
EM
企画 x 1
デザイン x 1
ウェブ開発 x 3
アプリ開発 x 2

くらいが標準的な構成か。

freee(2021)

PM
UXD
Eng x 4

あたり。

カンム(2022)

https://tech.kanmu.co.jp/entry/2022/03/02/105111

モバイルアプリの開発でチーム内にBizサイドも入っているパターン。

バックエンド/インフラ x 4
モバイル x 1.5
データサイエンティスト x 2
デザイナー x 2.5
マーケター x 3
PM x 1
何でもやる人 x 1

メルカリ(~2022)

https://engineering.mercari.com/blog/entry/20220120-2fd1a3e4ba/

メルカリのみ遷移が書かれているので複数書いています。初期ほどPOとPMが分業しているパターン。

ローンチ期

PO
PM
Backend
iOS
Android
Frontend

グロース期

PJO
PM
Backend
iOS
Android
Frontend

PMM/EM体制期

iOS、Andoirdと技術軸ごとにチームとは別にレポートラインを持ちEMがいる。

PMM
PM
iOS
Android
Frontend
Backend

Campシステム期

各チームがローンチ期に近いミニスタートアップに近い構成。デザイナーが共有ぎみか。

Team 1

PM
EM
iOS x2
Android x 2

Team 2

PM
EM
iOS x2
Android x 2

Camp共有

PM Head
Eng. Head
Designer
QA

SODA(2023)

割合マネジメント特化のEM組織を別に組成するパターン(に見える)

プロダクト開発

Web x 5
Flutter x 2
Design x 1
PdM x 1

エンジニアリングマネジメント

EM x 3

Voicy(2023)

各チームのばらつきが大きく型が定まっていない。マネジメントだけのEMの兼業が多いパターン。

Mission

(EM x 1)
iOS
Android
BE
UX/UI
PM

App Enabling

iOS x 3
Android x 3

Backend Enabling

SRE
BE x 5

Timee(2023)

チーム内にPOとは別にスクラムマスターがいる構成。

PO x 1
SM
Backend x 2
Android x 1~2
iOS x 2
(Analyst x 1)
Designer

その他

所感

個人的にはスケールする上でPMの組織化は必須で、マネジメントだけするEMの組織化はAssessOpsの観点から微妙だと思っています。

全体的にプロダクトオーナーとプロダクトマネージャーが分かれていたり、プロダクトマネージャー(PdM)とプロジェクトマネージャー(スクラムマスター)を別に置いている組織が多いですね。

例えば日本のSIerで多重下請け構造が問題とされることがあります。同一労働同一賃金の流れの中でグループ内企業で安い子会社から派遣みたいな業態は法律上の制限が増えた部分もあるのですが、意外と下請けのレイヤー通りに階層があることは稀で色んな所属の人がいる現場、正社員率が100%でない場合も経験上多いです。

自分は専任のスクラムマスターは業態によっては不要という立場ですが、解雇規制の強さから一部開発をアウトソースしていたり、所属バラバラの混成チームが多い日本の現場の場合、プロジェクト管理のコストが高く、結果としてPdMとテックリードの二元論だけだと間のボールになりやすいのかもしれないですね。

2024-02-09

[Zenn投稿] プログラマーの能力は経験年数で測れない

プログラミングマネジメント Zenn

経験年数より大切なもの

Zennに投稿しました

Zennに「プログラマーの能力は経験年数で測れない」を投稿しました

zenn.dev

所感

RQ1の

能力が高いプログラマーほど、より少ないコードエレメントをより短時間で修正するという点で、より効率的にコードを読むという先行結果を確認することができる。しかし、弱い相関しか示さない指標もある。

RQ2の

能力が高いプログラマは、完了時間が早いにもかかわらず、認知的負荷がわずかに低い。能力が高いプログラマほど、認知負荷の高いスパイクが少ない。これは、能力が高いプログラマほどベータが低く、アルファとガンマのパワーが高いというこれまでの知見と一致している。

も読んでて面白いです

2024-02-02

企業技術ブログを続けるために必要なエンジニアの人数の推定

プログラミングマネジメント

企業技術ブログはリソースヘビーか

採用広報の一つの戦略としての技術ブログ

求人倍率が10倍を超えている(ソフトウェア)エンジニアを企業が採用するためには採用広報が重要です。

オープンソースプロジェクトに課金する、カンファレンスのスポンサーになる、勉強会で登壇するとならんでよく行われるのが企業技術ブログの運営です。

一方で熱量の高いメンバーがはじめたものの周りは乗り気でない、最初は勢いよく始めたものの止まってしまった等々というのはよく聞く話です。頭数だけが全てではないですが、どのくらいのエンジニアがいれば続くものでしょうか？

参加は任意で前提をそろえる

推定する前に前提をそろえます。

全員参加強制にする企業もあるのですが、参加は任意とします。

デザイナーやBiz職含めて投稿する場合もありますが、エンジニアのみの参加とします。

リファレンス事例を調べる

ZOZO

アドベントカレンダーにおいて

2021年: 125記事/75人 = 1.66記事/人
2022年: 175記事/112人 = 1.56記事/人

の投稿のようです。熱量の高い人がちょっと多めに書いているとするとリアルかもしれないですね。

Merpay

技術ブログの情報によると発信に関わっている人は、メルペイエンジニア組織全体の約20～30％だそうです。

メルカリ・メルペイはかなり発信に力を入れているイケイケのイメージですが全員が関わっているわけではないんですね。

月一投稿に何人エンジニアが必要か

以上の情報を元に下記前提で計算します。

毎年3割のエンジニアが記事を書くとする
記事を書くエンジニアは毎年1.6記事書くとする

祝日は予約投稿する、アドベントカレンダーには参加しないとして

毎週投稿

365日/7 = 52記事

52 / 1.6 * 10/3 = 108人

隔週投稿

365日/14 = 26記事

26 / 1.6 * 10/3 = 54人

月1投稿

12 / 1.6 * 10/3 = 25人

愚直に計算するとエンジニア25人いて初めて月一の技術ブログが成立する と言った感じでしょうか。

アーリーフェーズほどCTOがひたすら勉強会で登壇するなど別の施策のほうがよく、レイターになるほど技術ブログがワークするかもしれないですね。

技術ブログは離職率低下に効く

FOMO(fear of missing out), 取り残されることへの不安という言葉があります。IT系、特にWeb系は技術の進化も速くキャッチアップが大変です。

発信には

外に対する発信
外に言うけれど中の人に外に言っていると宣伝するための発信

があると思っているのですが、技術ブログの運営には中の人に我々は技術を重要視している、高い技術水準をキープしていると言う効果があります。発信というと採用、採用と攻め側の話ばかりされがちな印象ですが、守る側にも効きます。

実際、技術ブログを運営できる企業はキャッチアップの感度も高く社内勉強会だったり、FOMOを減らす、メンバーのスキルレベルをふりではなくキープできていることが多いと思います。

採用に力を入れているという企業でも離職率の低下についてはおざなりということはありますね。そういう意味で 技術ブログを継続できているというのは離職率低下に効く のでないか。

所感

評価基準にブログの執筆もいれている企業もあるのですがインセンティブ設計としてはどうですかね？たいして技術的に高度なことをやっていないのにノルマなので実名で記事を書かないとか形骸化すると地獄ですね。

アドベントカレンダーシーズン(12月)に世の中のお祭りムードを利用して社内アドベントカレンダーをやって、記事のストックをためて、月2くらいでちょっとずつ世界に出していくのも一つのアイディアですが、技術は陳腐化していくのでうまくいくかは未知数。

2024-01-02

2023年に読んだ本、個人的トップ10

プログラミングライフ中国語ファイナンス書評

2023年の振り返り

2023年も本をたくさん読んだ

2022年の年末にアウトプットをもっと増やそうと誓ったはずなのですが、結局2023年もインプット過多でたくさん本を読みました。集計途中ですが300冊を超えているのでコロナが5類になったのにも関わらず前より多いですね。。。

Kindle日替わりセールのページとPacktの日替わりフリーページを巡回する癖がついてしまったのも敗因かなというところ。

読んだ中でおもしろかった10冊(+α)を紹介します。

デュアルキャリア・カップル

就活生が選ぶ人気ランキング企業だとコンサルだったり外資系金融だったり比較的激務で高収入な職業が人気な傾向にあります。

一方で、結婚している人の統計だと共働きは増えているがフルタイム共働きは増えておらず、片方が激務で融通の効かないモデルが少子化の原因になっているのでは？とも思うときもあります。実際、日本の女性の労働参加率は働き世代全体だとアメリカやフランスより高いことを知りました。フルタイム共働きを希望している人ほど結婚できていない、子供を産めていないのではという気もするんですよね。

デュアルキャリア・カップルは共働きについて書かれた本で自分とパートナーのキャリアが独立だと仮定すると崩壊しやすいそうです。

人間は自分がやった家事を過大評価する傾向があるので透明性が重要だそうで、逃げ恥のドラマで紹介されていたやった家事を言い合うシステムは科学的にも合理的なんだと思いました。

パン・豆類・ヨーグルト・りんごを食べてはいけません

今年はWinnyの映画を観に行きました。金子勇氏は若くして亡くなっているのですが椅子の上でプログラミングして寝るような生活をしていたようで、反面教師として食事や運動に気をつけようと思いいくつか本を読みました。

昔からお腹を壊しやすいのですが、 「パン・豆類・ヨーグルト・りんごを食べてはいけません」は低FODMAP食について書かれた本で、体質によっては納豆やヨーグルト、りんごなんかが腸内環境上悪い方向に働くということ視点が目からウロコでした。

低FODMAP食は継続すると栄養価的に悪い状態になる説もあるので、自分に合わない食べ物を短期で探すためのツールくらいに捉えるとよさそうですが、自分は食べ物見直して牛乳はオーツミルクに切り替え、コーヒーを飲むのをやめて体調が安定した気がします。

科学的に正しい筋トレ最強の教科書

どんなに運動をしていても座っている時間が長いと死亡率が上がるという論文もあるようで運動が万能ではないですが、とはいえリモートワークで筋力の衰えを感じたのでジムに通いはじめました。

「世界一シンプルで科学的に証明された究極の食事」という食事の健康への影響のエビデンスをまとめた本があるのですが、「科学的に正しい筋トレ最強の教科書」はその筋トレ版という雰囲気で筋トレにおけるエビデンスがかなり詳しくまとまっていてよかったです。

「ウォーキングの科学」にのっているインターバル速歩も試してみたのですが、継続できなかった。。。素直にジム通う方が自分にはあっていました。

最高の髪型解剖図鑑

コロナが5類になって少し外に出るマインドになったので少し身なりに気をつけようと思って髪型の本を読みました。

「最高の髪型解剖図鑑」は髪型には整形と同じ効果があるという主張の元、普通の人の顔は芸能人と違って左右対称でなかったり何かしら歪みがある、それを髪型でどうカバーするかという本です。

髪型が似合うかは結構フィーリングによりがちですが、なぜ似合うかの根拠が色々と書かれていて面白かったです。

異文化理解力――相手と自分の真意がわかるビジネスパーソン必須の教養

ソフトウェアのバグはコードそのものよりも組織構造から生じることが多いという論文を読んだこともあり、組織構造やコンフリクトマネジメントの本を読みました。

キャリアコンサルとのYouTubeやスクラムの元論文も得るものはあったのですが、本だと「異文化理解力」が面白かったです。

いくつかの軸をベースに理詰めで国ごとの文化パラメーターが振ってあって、この国の人はこういう性格や仕事の進め方をする確率が高いという傾向がまとめられています。グローバル志向の企業も増えているので職場のダイバーシティが増えるとより重要そうですね。

会社売却とバイアウト実務のすべて

ファイナンスだとUnityの決算書を読んだりしたのですが、本だと「会社売却とバイアウト実務のすべて」、かなり細かく実際のフローを想定していてよかったです。

プロフェッショナルCFO検定も資格取ろうと思って、問題集パラパラ読んでいたときもあるのですが、企業価値まわりの情報量はこちらの方が詳しい印象です。

類書として「新規事業を成功させるPMFの教科書」も事例が豊富でよかったです。

中国時代劇で学ぶ中国の歴史 2023年版

今年は中国語版のヒカルの碁をずっと観ており、人類が碁のAIに勝った話もまとめました。

以前アニメをやっていたパリピ孔明もドラマ化され中国語のドラマにそれなりにはまっていました。

「中国時代劇で学ぶ中国の歴史」は中国語のドラマをベースにこれの年代はここらへん、それの年代はそこらへんと歴史ドラマの紹介が位置づけとともに書かれた本です。時代は架空というドラマもちらほらあるので、すべてがつながっているわけではないのですが、中国史の全体観が掴めてよかったです。

類書の「33地域の暮らしと文化が丸わかり! 中国大陸大全」も省ごとの違いがわかってよかったです。

20世紀の巨人産業家ヘンリー・フォードの軌跡

NHKの朝ドラが牧野富太郎をベースにしたもので、お嫁さんが研究費を稼ぐために商いをやって成功したらしいのが印象的でした。

ともすれば技術者/研究者はビジネス面だと下手くそということはままあり、そうならないように技術者出身の経営者の本を読みました。

「20世紀の巨人産業家ヘンリー・フォードの軌跡」は自動車で有名なヘンリーフォードがどう経営をやったか書かれた本です。100年前の人なので価値観はところどころ古いのですが、技術者出身でちゃんと経営者やっている点は学びがありました。

類書で「ピーター・ティール世界を手にした「反逆の起業家」の野望」も面白かったです。

ソフトウェアアーキテクチャの基礎

今年は論文にテストよりもコードの複雑性がバグを起こす原因と書かれていたこともあり、アーキテクチャや静的解析まわりについて自由研究していました。

X( 旧Twitter)のアーキテクチャについてまとめた記事がよく読まれており、Xの運営のグダグダ感からどうやったらXをコピーできるかを考えた人は多かった気がします(たぶん)。

「ソフトウェアアーキテクチャの基礎」は比較的に最後に読んだのですが、個別の記事で各品質指標を調べる前に読んでおけばよかったという本で、ソフトウェアアーキテクチャのよさの計測について把握するのにおすすめです。

アジャイル開発の法務

弁理士を特集したドラマにはまったこともあり、知財や法律まわりの本を何冊か読みました。

「アジャイル開発の法務」は文字通りアジャイル開発に関わる法律についてまとめた本で、個人的には偽装請負の問題点についてまとまっていてよかったです。

駆け出しエンジニアが一時期から減ったのも、国からのお達しが出て、いきなりフリーランスやSESだと専門性や独立性が怪しくなって、煽っていた人がビジネスとして成り立たなくなったからな気もするんですよね。

類書で「知識ゼロからの外国人雇用」も知らない世界が知れて面白かったです。

所感

2024年はどんな本を読もうかな。(すでにたくさん積まれている)

2023-12-18

[Qiita投稿] CohesionでPythonの凝集度を計測する

Qiita プログラミング Python アーキテクチャ

Pythonでの凝集度の測り方

Qiitaに投稿しました

Qiitaに「CohesionでPythonの凝集度を計測する」を投稿しました。Python Advent Calendar 2023 Day 18の記事です。

qiita.com

所感

LCOM4の関心はクラス設計ですが、一つずらしてモジュールにしてみても面白そうですね。

Webフレームワークでのサービス/フォームクラス<=>モデルクラスの関係はメソッド<=>変数の関係と同じなので、モジュールの凝集度が測れるとマルチモジュールの境界設計の良さを数値にできそうです。

ランキング参加中

プログラミング

2023-12-13

[Qiita投稿] Misskeyで学ぶdependency-cruiser

Qiita プログラミングフロントエンド TypeScript アーキテクチャ

フロントエンドの依存の可視化、バリデーション

Qiitaに投稿しました

Qiitaに「Misskeyで学ぶdependency-cruiser」を投稿しました。TypeScript Advent Calendar 2023 Day 13の記事です。

qiita.com

所感

Rails+Packwerkとできることが近い気もします。なんでもexportできるJS/TSとオートローダーで何でもグローバルに入れちゃうRailsは実は近い説。

spm-goと比べて抽象度は出力できないですが、不安定度の計算が近似ではないのはいい部分ですね。

ランキング参加中

プログラミング

2023-12-05

[Qiita投稿] spm-goでGoの結合度を計測する

プログラミング Qiita golang アーキテクチャ

よいパッケージ性の測り方

Qiitaに投稿しました

Qiitaに「spm-goでGoの結合度を計測する」を投稿しました。Go 言語Advent Calendar 2023 Day 5の記事です。

qiita.com

所感

結合度関連だとConnascenceも面白そうですが、GitHub漁った感じ実装なさそうですね。

ランキング参加中

プログラミング

2023-11-19

IT企業の待遇差ファクターの分解

プログラミングマネジメントキャリア

経営者と労働者で目線がずれる理由の正体を探る

日本のエンジニアの給料は高いのか低いのか

日本のソフトウェアエンジニアの給料の良さについては諸説あり、他職種より高いので高いと言われることもあれば、国別比較だと他国、特にシリコンバレー周辺より低いので低いと言われることもあります。

こういった議論をするとき、IT企業と非IT企業の業種の格差、営業やデザイナー、エンジニアの職種間の差、東京と東京以外の都道府県の差、中小企業、上場企業、スタートアップの差、会社員とフリーランスの差、日本とアメリカの国間の差などなどが混ざってしまっているように感じて、分解してみることで知見を得られるのではと思い今回比較してみます。

IT企業と非IT企業の業種の格差

dodaの業種別データをグラフ化しました。

平均年収403万円でインターネット／広告／メディアだと412万円で+2.2%、IT／通信だと436万円で+8.1%。あまり差はないですね。

営業やデザイナー、エンジニアの職種間の差

同じくdodaの職種別データをグラフ化

平均年収403万円でデザイナーはクリエイティブ系とすると374万円で-7.2%。営業だと439万円で+9.2%、技術系は電気/電子/機械でもIT/通信でも442万円で+10.0%

日本は非IT企業に所属しているエンジニアよりIT企業に所属しているエンジニアが多いと言われているのと、単純に掛け算していいのか微妙なところはあるのですが、簡単な推定で

Web系企業(インターネット)に所属しているエンジニアなら全体平均年収403万円 x 業種ブースト+2.2% x 職種ブースト+10.0% = 453万円でしょうか。同様にIT企業に所属しているデザイナーなら373万円、営業なら450万円。

東京と東京以外の都道府県の差

同じくdodaの都道府県別データでみると平均年収403万円に対し、東京は440万円で+9.2%。「年収は「住むところ」で決まる」という本もありましたね。

簡単な推定で東京のWeb系エンジニアなら495万円、デザイナーなら407万円、営業なら491万円。

中小企業、上場企業、スタートアップの差

平均勤続年数12年の日本人にとってスタートアップで勤務するというのはリスクが伴います。別記事に書いた通りシリーズCでも2割弱倒産します。

ネクストユニコーン調査の結果ベースで上場企業(正社員)で平均年収622万円、スタートアップだと688万円。

最近福岡他のスタートアップも増えてはいますが、スタートアップの暗黙の前提で東京でWeb系のファクターは入っている気がしますね。エンジニア比率が高いかは微妙なところですがSaaSなんかだと低めの割合なので一旦無視します。

上場企業の半分は東京なので東京ファクター+9.2が半分かかるとして上場企業勤務は+47.6%のファクター。スタートアップは業種ブースト+2.2%、東京化の+9.2%を間引いて+53.0%のファクター。東京IT企業間で上場=>スタートアップは+3.7%のファクター。

東京のWeb系企業で上場企業だとエンジニアは731万円、デザイナーは601万円、営業は725万円。同様に東京のスタートアップだとエンジニアは758万円、デザイナーは623万円、営業は752万円。

グロースになる前のマザーズの上場企業は平均年収560.9万円のようなので上場企業も市場区分によって変わるかもしれないですね。

会社員とフリーランスの差

別記事に書いた通り、解雇規制の強さは国によって違いがあります。日本が厳しいというよりアメリカがかなり他国比で緩い。

国間の比較の際にここの項が入ってしまいそうなので会社員からフリーランスになった時も比較しておきます。フリーランス=アメリカ企業の社員と同じ前提にできればと。

フロントエンド/バックエンド比較の際に作成したグラフを再掲します。

営業の待遇が下がって、デザイナーと同じになり、エンジニアとの差は開いています。上場企業勤務の営業の人がいたらフリーランスになるのは割りの悪い勝負と言えます。逆にエンジニアはデザイナー比での待遇が+18.5%=>+35.1%(バックエンドエンジニア)となっています。

飲食店の賃上げなんかをみても分かる通り、人手不足による賃上げは人材の新規獲得性の高い企業からおきます。ソフトウェアエンジニアの求人倍率は14倍と言われますが、そういう状況だと

ソフトウェアエンジニアの待遇は毎年上昇する
待遇上昇は新規獲得性の高いフリーランス、スタートアップなど中小企業から起きる

といえます。

逆に需給が反転した際にも待遇減は中小企業から起きるのでそうなった際は、市場感反映に時差のある大企業にしがみついた方がいいですね。

給与所得の手取り早見表とフリーランスの手取り早見表からフリーランスデザイナーの年収777万円は手取り520万円。厚生年金の会社負担額777*0.0915=71万円を引いて449万円。会社員だと年収580万円くらいでしょうか。

同様にバックエンドエンジニアをエンジニアの代表として1050万円で手取り675万円程度、厚生年金の会社負担額96万円を引いて579万円。会社員だと年収780万円くらいでしょうか。

スタートアップ=>フリーランスは営業で-22.9%のファクター、デザイナーは-6.9%のファクター、エンジニアは+2.9%のファクター。

思ったより全体が上がるわけではなかったので一旦無視します。

日本とアメリカの国間の差

本当は英語が話せるブースト、外資系企業に勤めているかもあるのですが、手元にデータがないのでスキップします。

Cartaというベンチャーキャピタルがデータを公開していたので他国、おそらくほぼアメリカ(以降アメリカ前提)の待遇と比較します(1USD=150JPY)。ストックオプション他も入っています。

営業を1とするとデザイナーが+7.5%、エンジニアが+24.0%。日本比で営業の待遇が低くてデザイナーの価値が高いですね。一つの国でなくグローバルで戦っている企業が多いからかもしれないし、日本は漫画文化の影響で絵を描いたりデザインをできる人材が豊富と言えるかもしれない。

日本=>アメリカのスタートアップだとエンジニアは3.58倍、デザイナーは3.78倍、営業は2.91倍。アメリカに行けとう記事はエンジニアが書いていることが多い(当社調べ)ですが、一番ゲインが多いのはデザイナーかもしれないですね。

アメリカの平均年収が1420万円、アメリカのBigTech除くテック企業の平均年収が2550万円なので、日本とアメリカの平均年収の差が3.5倍。テック企業は都市部にあるとしてテック企業ブーストが日本は+64.8%なのに対して、アメリカは+80.0%。

確かにテック企業かどうかの差はありますが、それより国力の差がありますね。テック企業=>Big Giant(GAFA)でも+40.6%のアップあり。

国間のソフトウェアエンジニアの待遇比較

国別ソフトウェアエンジニアの待遇データも見つけたのでグラフ化したものをのせておきます。(USD)

やはりアメリカも高いですがスイスも強いですね。日本を1とするとシンガポールで+16.2%、フランスで+21.7%、ドイツで+45.1%、カナダが+71.2%。イスラエルが1.99倍、スイスが2.7倍、アメリカが3.1倍。

少しズレがありますが上の統計ともあっていますね。

考察

Web系のエンジニア限定でまとめていくとこんな感じでしょうか。

インターネット業界で働くと+2.2%
エンジニアになると+10.0%
東京で働くと+9.2%
上場企業勤務だと+47.6%
上場企業=>スタートアップだと+3.7%
(スタートアップ=>フリーランスだと+2.9%)
日本=>シンガポール(アジア英語圏)で+16.2%
シンガポール(アジア)=>カナダ(北米)で+47.3%
カナダ=>アメリカで+81.0%
(非テック企業=>テック企業の日米差+15.2%)

思ったよりいい国やいい企業に勤めるかが大事でエンジニアであることのメリットが少ないですね。語学力が低くても仕事ができるという意味では有利ですが。

営業出身の社長の感覚で言うと日本において営業とエンジニアは同等かIT以外だと待遇面で営業の方が上の認識があるかもしれません。最近は日本のスタートアップでもグローバル思考の企業が増えてはいますが、アメリカと同等に収束するとすればエンジニアは営業の1.24倍になる気もします。

一方で例えば日本は非IT企業にいるエンジニアの数が少ないと言われており、toB SaaSのオンボーディングの労力が他国より必要とも聞いています。営業が重要なのもそういう日本特有の構造部分があるかもしれないですね。

例えば非テック企業=>テック企業の日米差もメンバーシップ雇用の名残とも取れて、ジョブ型に移り、セカンダリー・マーケットが成熟してくれば株式を含めた割合においてテック企業ブーストが+80.0%に収束することは普通にありそうです。

統計を見る限りアメリカではスタートアップとBig Techの待遇の逆転は起きていないように見えます。例えば日本でもCFOが外資系金融のポジションとの比較で待遇が下がることがなかったり、データサイエンティストが保険のアクチュアリーのおかげで買い叩かれることが少ないように思います。Big Techと言わないまでもメガを超えたベンチャーがもっと増え札束で殴り合うと需給上労働者有利になるのになというところ。

2023-10-25

[Zenn投稿] SonarQubeでフロントエンドのCognitive Complexityを計測する

Zenn プログラミングフロントエンドテックリード TypeScript

フロントエンドのコードスメルのあたりのつけ方

Zennに投稿しました

Zennに「SonarQubeでフロントエンドのCognitive Complexityを計測する」を投稿しました。

zenn.dev

所感

Web系の会社で使われる言語で言うとSwiftだけcommunity editionでサポートされていないのは儲けポイントなんでしょうね。

RubyだとFlogを使ってAbcSizeを測るやり方がお手軽でいいですが、そういったツールがない言語もあるので便利。

ランキング参加中

プログラミング

2023-10-15

エンジニアリングマネージャーはいずれレビューマネージャーになる

プログラミングマネジメントテックリード

テックリードとエンジニアリングマネージャーの分業は合理的か

マネージャーにプレーヤーとしての能力は必要か

技術などの専門性を競争力としている企業において、マネージャーにプレーヤー能力をどこまで求めるかはしばしば議論になるポイントです。

一般にプレーヤーとマネージャーとしての能力は完全に相関するものではなく、優秀なプレーヤーをそのままマネージャーにするというのは適正がない場合もあります。能力主義の階級社会において、誰しもが有能さを発揮できていた地位から、無能ぶりを露呈することになる限界の地位まで昇進させられる（ピーターの法則）。

実際、管理職になることだけが昇給する唯一の方法だと名ばかり管理職を産みやすく、適切なマネージャー:プレーヤー比率を保てず企業としての競争力が低下することもあります。

一方で「IT分野の管理職は高いIT能力を持っていなければならないと思う。優れたコードを書けないソフトウェア部門の管理職なんて、馬に乗れない騎兵隊の隊長みたいなものだ」という主張もあり、テスラなどでは管理職にも最高の技術力を要求することでビジネスとして成功しているようにも見えます。

ここら辺は言ってしまえば会社によってポリシーが違う、最高の人材とだけ働きたいので札束で殴って管理職にもトップの技術力を求めますという会社もあれば、人材獲得性の観点から凡庸なスキルの人の組み合わせだけで事業が継続できるようにしますという会社もあるというだけではあるのですが、本には⚪︎⚪︎と書いてあるので××のパターンが絶対正しいですという主張をする人もたまにいます。

要はバランスの部分ではあるのですが、どういう時にマネージャーにプレイヤーとしての能力を求めても経営合理性があるかについてまとめてみます。

技術が出てからどのくらいたったかで最適ポイントは変わる

マネージャーにプレイヤーとしての能力を求めるかで一番最初に考慮するポイントは技術のぽっと出係数だと思います。

例えば刺身にたんぽぽをのせるのを仕事にしている会社があるとして、作業が信じられないくらい高度に専門的なため管理職は作業内容を全く知らなくてもいいという判断になることはないと思います。日本では現在一般事務の求人倍率が1を割っていますが、その仕事が(他の仕事との相対比較で)30年前からやることにあまり変化が起きていない場合、長い年月の中でそのスキルを持った人の割合が増えており、そのスキル+管理職スキルを持っている人の求人をかけても採用できる確率が上がります。

例えば、機械学習コンペにおいて、ベテランのエンジニアより学生エンジニアの方が強いケースがしばしばみられますが、新しい技術は若者の方がキャッチアップしていることが多いように感じます。新しい技術を覚えるには学習時間が必要で、身銭を稼ぐのに忙しい社会人エンジニアは可処分時間で負けがちです。

一般に社会人経験が長いほど管理職スキルを持っている確率が高いわけですが、新しい技術+管理職能力だと人材獲得の面で不利であります。今なら例えばLarge Language Model周りは変化も速くキャッチアップそれ自体で大変で、LLMのプレーイングマネージャーをやるのはより枯れた技術領域のプレーイングマネージャーをやるより大変でしょう。

実際Web開発黎明期は若者技術者と技術はそんなにわからないベテランを組み合わせるのが合理的であったように思います。

人事評価でEMが技術力測定するならEMに技術力は普通に必要

一般に人事評価をプレイヤーとマネージャーどちらかやるかというとマネージャーの仕事とされることが多いようと思います。ただそこには欺瞞もあって、技術者と管理職を完全分業する組織において、技術者の一番大事な技術力を技術のわからない管理職が評価できるか？というと外しているケースも多いように思います。

この点がCOO的マネージャーと区別するために技術もある程度はわかるエンジニアリングマネージャーという用語が出てきた理由だと思います。HIGH OUTPUT PLAYERにおいて人間の能力を分解しましたが、コンピテンシー的部分のみ管理職が評価し、技術力についてはプレイヤーのトップが見るというパターンも一つの合理性なのですが、あまりみない類型ですね。

例えば人事評価で外部の技術者を呼んで、技術力評価委員会を設置し、査定の一部を管理職から切り離している会社もあるのですが、それができている会社は少ない印象です。部署間格差を最小化する必要はあるのですが、AssessOps的合理性で言えば普段の仕事ぶりをみている人が評価者にちゃんと入った方が納得感があるのも事実で、技術軸のトップが別のチームに所属しているとそこにねじれはあります。普段の仕事をみている管理職の技術力が高ければ高いほど技術者の技術力を評価する精度が上がるように思います。

エンジニアリングマネージャーに求められる技術力は年々上がる

しばしばエンジニアリングマネージャーに上がった人はもう技術をキャッチアップしなくていいんだと安堵する人も一定数いると思うのですが、アセスが仕事内容に含まれる場合、矛盾があります。技術が登場したタイミングから時間が経つにつれて技術がわかり、管理職もできる人が増えてくるというか、あぐらをかいていると同僚の管理職比で劣ってみえるわけです。

エンジニアリングマネージャーに求められる技術力は年々上がるというのは不都合な真実ですが存在するように思います。

人材市場とちゃんとベンチマークすると、技術のぽっと出係数が減ってくるにつれてテックリードとエンジニアリングマネージャーのラップ範囲が増えていると思います。実際営業など技術系より鮮度に敏感ではない職種は管理職は業務内容を知らなくていい、マネジメントだけしていればいいとならないことが多く感じます。

ぽっと出係数100: 管理職は技術について何も知らなくていい(COO的マネージャー)
ぽっと出係数75: 管理職は技術者経験がある必要がある。元バックエンドエンジニアがiOSのマネージャーをするなどねじれはあっても良い(エンジニアリングマネージャー)
ぽっと出係数50: 管理職はマネージャーをする領域の技術者経験がある必要がある。iOSのエンジニアのマネージャーは2流でもいいが元iOSエンジニア。(レビューマネージャー)
ぽっと出係数25: 管理職はマネージャーをする領域の技術者経験があり技術力も高い必要がある。(プレイできるレビューマネージャー)
ぽっと出係数0: (特定領域はExcel使える程度に広く普及し、管理職はより複合的な技術力を求められる)

最近のWeb系の会社だとテックリードと分業する場合、ぽっと出係数100はあまりポピュラーでなくてぽっと出係数75〜50くらいが求められる要件な気はしますね。次に来るトレンドはエンジニアリングマネージャーはいずれレビューマネージャーになる であり、そういう企業もちらほらいる印象。ガツガツ実装はしないがプルリクのレビュアーには一応入っている状態。

会社規模が十分に大きいか、階層は深いか

実際スタートアップのCTOはテックリードとエンジニアリングマネージャーを兼務しているような働き方が多いです。会社規模が小さいと人が辞めた時にカバーしないといけない範囲が大きいわけで、自然プレイできるレビューマネージャーであることが求めらます。

CEOをChief Executive OfficerでなくChief Everything else Officerと茶化していう創業者もいますが、切り出せる範囲が大きいとCEOとしては楽なわけで、スタートアップ文法で言えば細かすぎるロールより余白の多い人材が重宝される傾向にあります。

階層が深いかも重要な視点で、例えばCTOがエンジニアを採用すると徐々にレビューマネージャーに移り、そこも任せられる人が採用できたらより抽象度の高いマネージャーのマネージャーに移るというパターンもあるでしょう。

プレイヤー/マネージャー論争している時点でその人の見えているスコープは現場よりで、それこそマネージャーのマネージャーのマネージャーになるとより抽象度の高い人を動かすマネジメント力が要求されます。逆に単なる１チームのマネージャーならかなり現場よりなので技術を全て忘れらるかというと、それでワークするケースは少ないように思います。

中途のエンジニアリングマネージャーの採用にコーディング面接は必要

実際Googleではエンジニアリングマネージャーの採用にもコーディング面接が課されるようです。

多くの企業では評価制度上、プレイヤーとマネージャーに分岐する前、基礎となる部分は共用しています。新卒からのプロパーマネージャーなら元エンジニアであることが保証されているわけです。それを中途の採用になった時にマネジメントだけできればいいというのは不整合な話で、分岐する前の元エンジニア分の技術力があるかをちゃんとコーディング面接で見るのは一貫しているようにも思います。