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くらいでちょっとずつ世界に出していくのも一つのアイディアですが、技術は陳腐化していくのでうまくいくかは未知数。

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-11-06

itoで価値観共有のレベリング

マネジメントゲーム

ボードゲームで価値観共有を行う

itoとは

たまたま「彼女、お借りします」のマンガを読んでいたらitoというボードゲームを知りました。どちらかというと合コン用なんかに使われるのを想定しているようなんですが、それ以外のチームビルディングにも使えそうなので今回紹介します。

itoはオリジナルのitoとv2.0のレインボーが存在します。基本的な部分に差異はないのですが、改善がされているので今から買うならレインボーの方がいいかもしれません。

オリジナルとレインボーの違いはざっくり

カードが小さくなって持ち運びやすく
お題カードの問題が2個から3個に増え、フレームが付くように
目印のクリスタルが付属
ルールがシンプルに

があります。

itoのルール

YouTubeにプレイ動画をあげている人がちらほらあげているのでそれを見るとルールを掴みやすいと思います。

大きく2種類のカードがあります。

お題カード
1~100までの数字カード

お題カードはレベリングの対象となるテーマです。例えば「コンビニで買える食べ物の人気」であり、例えば「夏に行きたい場所や国の人気」があります。

お題カードは表裏に3つずつ質問が書かれているので一つ選んでそれに対して意見交換します。

数字カードが各ユーザーに配られるカードです。ちゃんとシャッフルして配ると各ユーザーが違う数字を持つことになります。この数字を元にお題のテーマの割合にあうものを提案して裏にして(0のカードの横に)並べます。表にしたときに数字が小さい順に並んでいたら成功です。

例えば18と58と79のカードを各ユーザーが引いたとしましょう。コンビニで買える食べ物の人気は議論の余地があるポイントですが、18ならプライベートブランドのお菓子、58ならガリガリくんのアイス、79ならしゃけ弁当とかそんな感じですね。裏にした状態で他の人の数字を推測して並べていくのがおもしろポイントです。

協力ゲームなので言い直してもいい

ito3つの誓いには

全員が楽しめることを第一に遊びます
誰かが悩んだ時は、積極的に考えを聞いてみます
意見がずれるのは当たり前の精神で、価値観の違いをむしろ楽しみます

とあります。

ダイバーシティーの逆をいくハイコンテキストなゲームなので、他人の価値観を否定するより議論して協力プレーするのが醍醐味。提案を言い直してもいいみたいです。

仕事のレベリングに使ってみる

家族とかとやってみても違いが浮き彫りになるので面白いですが、お題さえ使えば仕事にも使えそうですね。

「営業で大口の顧客に契約切ると言われました。優先順位として68点の打ち手は？」、「急にWebサービスにアクセスできないと呼び出しがありました。優先度47の対応は？」などなど。

元はその場に物理的にいることを想定していますが、オンラインなら各人が手元で乱数生成などでしょうか。数字被ったりはありそうですがその場合はどちらでもOKとか。いずれにせよオリジナルに敬意を表してちゃんと会社で購入するといいですね。

$ irb
> (1..100).to_a.sample

所感

メインのゲームのルールがクモノイトとされているのは芥川龍之介の蜘蛛の糸からでしょうね。0のカードから数字を小さい順に並べていく様が糸がつながって生死を分ける感じを模しているのかと。

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ではエンジニアリングマネージャーの採用にもコーディング面接が課されるようです。

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

リセッション期にマネージャーは需要が減る

もう一つ技術のわからないエンジニアリングマネージャーの需要が減るポイントがあって、それが景気のリセッション期です。X(Twitter)やメタでレイオフした際、マネージャーにプレイヤーに戻るよう求めるシーンがありました。

プレイヤーとマネージャーで言えば景気のいい時、組織拡大期ほどマネージャーの需要が高まります。逆に景気後退局面では組織をダウンサイズするのでマネージャー:プレイヤー比を一定に保とうとするとマネージャーのポジションは世の中全体で減ります。

不況時に手に職があると強いの実態は、マネージャーvsプレイヤーで言うとリセッション局面ではプレイヤーの方が需要があるということだと理解しています。

まとめ

まとめです。

技術のぽっと出係数に応じてマネージャーに求める技術力の最適ポイントは変わる
人事評価でマネージャーが技術力を測定するならマネージャーにも技術力は必要
エンジニアリングマネージャーに求められる技術力は年々上がる
会社規模が小さいとプレーイングマネージャーの方が有利
階層が深い大企業ほどマネジメント力がいきるポジションがある
中途のエンジニアリングマネージャーの採用にコーディング面接は必要
不況時にはプレイヤーの方が需要がある

その他、調整先が多い業態かでも合理的なチームトポロジーは変わりスクラム不要論に書きました。チーム分割についてはガイドラインを参照してください。

2023-10-02

バックエンドとフロントエンドで人を分けるべきか

プログラミングマネジメントテックリードアーキテクチャフロントエンド

要はバランス

バックエンドとフロントエンドで人を分けるべきかは業態による

Web開発がCGIでデザイン性のあまりない匿名掲示板を作る位の時代だと、そもそもフロントエンドができることがブラウザの仕様やパフォーマンス上の理由により制限されていたので、今ほど要求は少なかったのですが、デザイン性やUXの部分がプロダクトの中でのウェイトが上がってくるにつれ、ReactやVueを使ったようなサイトも増えバックエンドエンジニアが兼業でフロントエンドを担当するのもつらいシーンも増えました。

そういったケースの場合、Web開発においてバックエンドとフロントエンドを別エンジニアが担当し、分業するのが合理的な場合もあります。一方でPhoenix LiveViewやRuby on RailsのHotwire、LaravelのLivewireといったバックエンドの言語でフロントエンドを一部代替する動きや、React Server Componentsのようなフロントエンドがバックエンドに歩みよる動きもあり、以前より距離が近くなってはいます。

業態などによって変わるのですが、どういうケースだとバックエンドとフロントエンドで人を分ける合理性が高いでしょうか？

技術面での分業の合理性の分岐点はAPIコールしているか

まずバックエンドとフロントエンドと言った時、フロントエンドが指すものは企業によってまちまちという視点はあった方がいいと思います。

バックエンドエンジニアに求められるフロントエンド力やアーキテクチャは以下のようにもっとグラデーションがあると思います。

Lv.0: バックエンドのAPIなら開発はできる
Lv.1: HTMLやCSSは書ける
Lv.2: jQueryや生JSに近い部分でHTMLを動的に書き換えられる
Lv.3: HTMLに埋め込んだデータを使ってReactなどで画面を作れる
Lv.4: JSONのAPIを使って(場合によっては複数APIコールして)Reactなどで画面を作れる
Lv.5: React Routerなどフロントのルーティングを持ったSingle Page Applicationが作れる
Lv.6: React Nativeなどを使ったネイティブ(デスクトップ/モバイル)アプリが作れる

個人的にはLv.4のJSONのAPIを使って通信を明確にし、バックエンドとフロントエンドを疎結合したあたりからバックエンドとフロントエンドを完全分業することができるラインのように思います。

Lv.3くらいだとHTML経由でデータを受け渡すためフロントエンドエンジニアでも多少はバックエンドの言語をかけた方が融通がきくかもしれないライン、逆にLv.5くらい複雑になってくるとバックエンドエンジニアの兼業では厳しいように思います。システムの系は疎結合になっているのに同一担当が実装するのはコンウェイの法則とのねじれがあり、つらみが大きいです。

初期スタートアップでは完全分業はやめた方がいい

技術以外に会社のフェーズによっても合理性は変わってくると思います。フロントエンドとバックエンドだけではないですが、成熟したプロダクトと違って初期スタートアップのプロダクトほどピボットだったり、人材不足によりフルスタック性が求められます。

その人の雇用を守るための仕事が発生すると全体の速度が落ちるので、事業内容やプロダクトの方向性、タスクが多少変わってもカバー範囲の広いバッファーがある人員のみの構成比率を大きくした方が無駄が少ないです。

逆にフェーズが上がってくると高度な専門性がないと解けない課題を解く合理性が増える、ユーザー数が増えることによって細かいケースでも面積が上がってくるのでフルスタックエンジニアよりは分業の合理性が高くなることはあります。

バックエンド、フロントエンド兼務から分業への緩やかなパスが欲しい

そう考えるとバックエンド、フロントエンド兼務から分業への緩やかなパスが欲しいですが、自分の知る限りその方法は発明されていない認識です。

例えばGETに絞ればLv.3のHTMLに埋め込んだデータを使うのとLv.4のJSONのAPIを使ってデータを取るのではデータを取るという点において共通しています。HTML経由でquerySelectorでデータを取るのとAPI経由でJSON受けとるので書き方が変わる必要はなく、ラッパーメソッドを通せば裏側は可変に簡単にできるのが技術の進化の方向性のように思います。

fetchにはdata URLが渡せるみたいですね。configのfromHTMLがtrueなら fetch("/api/movies/1") は <div id="_fetch_api_movies_1"></div> からデータ取るように自動で切り替わる方向性だとだめなのかなと。

名前のついたロールはいずれコモディティ化する

名前のついたロールはいずれコモディティ化するという考え方もあって、人間が十分に賢く合理的ならその技術専門性の価値は年々減衰します。

Web系は変化がはやいためとある技術専門性がコモディティ化したタイミングで別の技術専門性にトレンドが移り現状そこまで収束してはいませんが、技術の進化が止まったらバックエンドとフロントエンド両方書ける人が普通になる点はいずれ訪れます。

現状ソフトウェアエンジニアの求人倍率は14倍ですが、実際機械や電気系のエンジニアの求人倍率はそれより低いです。社会的にその専門性を持っている人員の需要が大きいなら、賢い為政者がいれば教育機関の定員を増やすなどして、需要が合うよう調整します。

日本では日本国内の地方格差拡大防止のために東京23区内の大学定員の抑制がされていますが、2023/04にそれをIT系に限り緩和する例外措置の指針が発表されました。ただいくつか制約はあるので手放しの緩和ではないようです。

デザインエンジニアやWebAssemblyは別のスキルアドオンの形

バックエンドとフロントエンドの二元論も短絡的で、バックエンドエンジニアのスキルアドオンはフロントエンドだけではありません。

モノリスのバックエンドとマイクロサービスのバックエンドは違いますし、インフラがわかるバックエンドエンジニアもいれば、機械学習のわかるバックエンドエンジニアもいるでしょう。アーキテクトとしての能力を売りにしている方もいますね。

逆にフロントエンジニアはデザイン系のツールを使いこなしデザインエンジニアを売りにしている人もいます。それほどまだ事例はないですが、WebAssembly周りは最近変化が大きいので、クライアント繋がりでWebAssemblyのコードも書けるもセールスポイントでしょう。

企業によってはクライアントサイドテックリードとサーバーサイドテックリードを分けていることはあります。どちらかというとアプリの会社でiOS/Android両方できる人をクライアントサイドテックリードと呼んでいることは多い気がしますが、例えばflutter_hooksのようにReactのhookに影響を受けたような概念はモバイルアプリ開発でも増えてきてはいます。

クライアントなら全てわかるも一つのキャリアの方向性かもしれません。

所感

最新のフリーランスの職種別待遇だとインフラ < フロント < バックエンド < iOS/Android < PM < DS/MLみたいですね。

インフラ周りはセキュリティ要件でフリーランスには任せられないという会社もありそうなので、実需要はもう少し高い気はするのですが、直近マイクロサービスよりモジュラーモノリスの選択をする企業が増えています。

マイクロサービスのバックエンドが簡単かというと語弊はあるのですが、マイクロサービスがインフラは大変だけどバックエンドは簡単な構成だとすればモジュラーモノリスはインフラは簡単だけどバックエンドは大変なアーキテクチャで、バックエンド/フロントよりバックエンド/インフラの需給間の変化の方が直近では大きいかもしれません。

2023-08-11

くるみんマークを取得しているIT企業一覧

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

子育てサポート企業の見分け方

公的な証明で働きやすい企業を見抜くには

20・30代の7割がマネージャーを希望していないそうです。転職でも年収よりワークライフバランスが重要というケースも増えました。たくさん残業しなければいけないなら、高給でなくてもいいという人も増えているのが時代の流れかなと。

経営者が働きやすい会社です、子育て世代に寄り添っていますと口で言うだけなら簡単ですが、転職して入ったら思ったのと違ったというケースもあると思います。完璧ではないものの、くるみんマークは公的な認証であり、その企業のワークライフバランスへの投資の本気度を測る指標になり得るので今回見ていきます。

くるみんマークとは

くるみんマークは子育てサポート企業として厚生労働大臣の認定を受けた場合に使えるマークです。行動計画を策定する必要があり、いくつかの要件も満たす必要があります。

2022年4月に要件が厳しくなった他、トライくるみんが追加され、要件の厳しさに応じて基本的にプラチナくるみん、くるみん、トライくるみんの3マークの運用になりました。

ざっくりとした基準の違いは以下です。

プラチナくるみん
- 男性育休取得率: 30%以上(<= 13%以上)
- 男性育休・育児目的休暇取得率: 50%以上(<= 30%以上)
くるみん
- 男性育休取得率: 10%以上(<= 7%以上)
- 男性育休・育児目的休暇取得率: 20%以上(<= 15%以上)
トライくるみん
- 男性育休取得率: 7%以上
- 男性育休・育児目的休暇取得率: 15%以上)

また、不妊治療のための休暇制度等の追加要件を満たせば、プラチナくるみん/くるみん/トライくるみんはプラチナくるみんプラス/くるみんプラス/トライくるみんプラスマークになれます。

認定企業が中小企業の場合、上限50万円のくるみん助成金をもらえる他、公共調達においてくるみん認定企業は加点を得られます。

くるみんマークの認定基準

くるみんマークの認定基準の10要件は以下です。

雇用環境の整備について、行動計画策定指針に照らし適切な行動計画を策定したこと。
行動計画の計画期間が、２年以上５年以下であること。
策定した行動計画を実施し、計画に定めた目標を達成したこと。
策定・変更した行動計画について、公表および労働者への周知を適切に行っていること。
次の（１）または（２）のいずれかを満たしていること。
1) 計画期間における、男性労働者の育児休業等取得率が１０％以上であり、当該割合を厚生労働省のウェブサイト「両立支援のひろば」で公表していること。
2) 計画期間における、男性労働者の育児休業等取得率および企業独自の育児を目的とした休暇制度利用率が、合わせて２０％以上であり、当該割合を厚生労働省のウェブサイト「両立支援のひろば」で公表していること、かつ、育児休業等を取得した者が１人以上いること。
計画期間における、女性労働者の育児休業等取得率が、7５％以上であり、当該割合を厚生労働省のウェブサイト「両立支援のひろば」で公表していること。
３歳から小学校就学前の子どもを育てる労働者について、「育児休業に関する制度、所定外労働の制限に関する制度、所定労働時間の短縮措置または始業時刻変更等の措置に準ずる制度」を講じていること。
計画期間の終了日の属する事業年度において次の（１）と（２）のいずれも満たしていること。なお、認定申請時にすでに退職している労働者は（１）・（２）のいずれも、分母にも分子にも含みません。
1) フルタイムの労働者等の法定時間外・法定休日労働時間の平均が各月４５時間未満であること。
2) 月平均の法定時間外労働６０時間以上の労働者がいないこと。
次の①～③のいずれかの措置について、成果に関する具体的な目標を定めて実施していること。
1) 所定外労働の削減のための措置
2) 年次有給休暇の取得の促進のための措置
3) 短時間正社員制度、在宅勤務、テレワークその他働き方の見直しに資する多様な労働条件の整備のための措置
法および法に基づく命令その他関係法令に違反する重大な事実がないこと。

中小企業だと軽減もあるのですが、学生起業で若手ばかりの人員構成だと5の実績面が満たせない場合はありそうなのと、8の残業規定は引っ掛かりそうなポイントでしょうか。育休をカバーするために一部の名ばかり管理職がたくさん残業してカバーするとダメそうですね。

プラチナくるみんだと少し要件が厳しくなるのですが、8の残業の規定は変わらないようで、個人的にはもう少し厳しめでもいい気はします。誰かがカバーして残業している会社は真の子育てサポート企業ではないかなと。

くるみんマークを取得しているIT企業一覧

くるみんマークを取得している企業は公表されているのでIT企業を抽出してみます。2023年6月末時点の表をベースに202x年で認定のある企業。

IT企業の定義が難しいのもあるのですが、似たような名前が多いのもつらいですね。公共調達で有利になるからか取得企業にSIerが多いように感じます。C向けのWeb系の会社は少ないですね。

プラチナくるみん認定

ソフトバンク株式会社
キヤノンＩＴソリューションズ株式会社
日鉄ソリューションズ株式会社
株式会社日立ソリューションズ・クリエイト

くるみん認定

株式会社ジャパンテクニカルソフトウェア
ＮＥＣソリューションイノベータ株式会社
株式会社エヌ・ティ・ティ・データ・フィナンシャル・ソリューションズ
かんぽシステムソリューションズ株式会社
キーウェアソリューションズ株式会社
住友電工システムソリューション株式会社
中外製薬ビジネスソリューション株式会社
パナソニックシステムソリューションズジャパン株式会社
三井倉庫サプライチェーンソリューション株式会社
横河ソリューションサービス株式会社
株式会社早稲田大学アカデミックソリューション
ＧＭＯペイメントゲートウェイ株式会社
ＫＤＤＩ株式会社
株式会社ＮＴＴデータＳＭＳ
株式会社ＮＴＴデータＮＪＫ
株式会社ＮＴＴデータアイ　
株式会社オールアバウト
株式会社ぐるなび
サイバネットシステム株式会社
さくら情報システム株式会社
株式会社ソフマップ
日本ヒューレット・パッカード合同会社
ビットバンク株式会社
楽天銀行株式会社

トライくるみん認定

該当なし

くるみんマークを見るコツ

プラチナかどうかも確かに大事なのですが、公表されている企業の中にはだいぶ昔に取ってからそのままの企業も多そうなので、そういう観点でも見た方がいいですね。

助成金がもらえたから取得したという企業だったり、過去取ったものの今は要件を突破できなくなってしまったという企業もありそうなので、継続的にくるみんマークを取得している企業は信頼できるなと。

IT企業かというと微妙なラインですが、日本ヒューレット・パッカードは2007~2021で計5回取得しているようです。

所感

両立支援のひろばにも統計データおいてあるようなので分析してみたいですね。

子育て世代が働きやすい会社というのは関係ない人でも働きやすい会社というのはよく言われることで、くるみんマーク取得企業が増えれば多少はワークライフバランスを考えた会社が増えるのではと思いました。

2023-07-02

IT企業でけんかを防ぐには

マネジメント

よくある話

前口上: IT企業ではけんかが起こりがち

IT企業で働いていると時折口論が起きることがあります。スタートアップで共同創業者間でもめて抜けた話はよく聞きますし、上場企業でも急拡大の結果、昔からいた人と新しく入った人とで溝ができてしまったなんて話は割とよくあるように思います。

こういった話はお仕事全般に共通するのでIT企業だけではないのですが、比較的企業サイズが小さく、労働(知識)集約的で、安定期でないケースが多いので起こりがちかな印象です。

どうすればIT企業でけんかを防げるでしょうか？いくつか論点を取り上げてみたいと思います。

組織が続く方が尊いので他の優先度は下げてもいい

大前提、自分は組織が続く方が尊いので他の優先度は下げてもいいというスタンスにあります。

イーロンマスクはじめPayPalマフィア(PayPalの元関係者)は成功事例が多いですが、初期のPayPalでも技術的な選択で口論になって、技術的に最高の選択より仲がいいことの方が重要として、必ずしもイケていない技術を採用したそうです。

それほどプロダクトの成否以前にとりわけスタートアップでは組織由来の崩壊がしやすく、こういうと技術者目線だと怒られるかもしれないですが、セキュリティーは別ですが、技術関係で揉めたら少しイケていない程度ならメンバー間の不和が生じないことを優先した方がいいと思っています。

けんかが生じる原因は何か

けんかが生じる原因はたくさんあるのですが、思いつくところだと

専門性よりフルスタックさを求められる
ピボットによる急な方針転換
平均的な人間の能力を高く仮定し過ぎている
手を動かす人の割合が高すぎる
情報共有の透明性の低さ
待遇への不満

あたりでしょうか。

規模の小さい会社ほど事業的不安定さ由来のストレスが多く、規模の大きい会社ほど隣の部署は役所というか構造が硬直的であることへの不満が多い印象。

規模が小さいと事業的不安定さ由来のストレスが多い

専門性よりフルスタックさを求められる
ピボットによる急な方針転換

は新規事業よりのケースで起きるけんかのケース。

新規事業だと投資しても儲かるのかわかっていないのでまずはミニマムでとしてスタートアップでも大企業でも最低限の人数しか割かれないケースが多いと思います。

小規模組織に移ると今までの仕事より職務範囲が増え、間のボールを拾わなければいけないことがストレスになる人もいます。

また、想定した仮説が外れてピボットした結果、売るもの作るものが変わった結果、不満につながることもあります。

優秀な人材はベンチャーには来ない

平均的な人間の能力を高く仮定し過ぎている
手を動かす人の割合が高すぎる

あたりはマネジメントの問題ですね。

スタートアップの創業者は高学歴のケースが多いそうです。必ずしもスタートアップに勤めた経験があるわけではなく、大企業勤務から急にスタートアップを始めたケースも結構あります。

ホリエモン、堀江貴文氏が以前言われていたんですが、優秀な人材はベンチャーには来ない です。そういう前提で動いた方がいい。

最近はスタートアップも待遇が上がってきたのでその仮定は少しずつ変わってきてはいるのですが、それでも日本は就職における新卒のウェイトがまだ高いです。創業当初から実績のある優秀なCXOがあなたの会社にジョインしてくれる可能性は低いでしょう。

それこそ中高一貫で大学もいい学校でした、一流大企業にずっと勤めていましたケースにおいて、 平均的な人間の能力を高く仮定し過ぎている 傾向はあると思って、あなたが今まで関わってきた人間は少しフィルターされているというか、地頭だけでいえば世の中平均より高かったことを認識できていないケースはあるように思います。

そういったケースにおいて大人な人間はそうそう喧嘩しないと誤った仮定をしている場合もあると思って、想定より起こりがちかなと。