事業内容によって必要なエンジニア組織は異なる - Melting Pot of Thoughts

CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど

[komutan1]

過去に見た失敗例：カルチャーフィットを求めすぎて採用が進まない、内製化にこだわるわりに技術への理解が不足している、オフショアに移行したが仕事の進め方を変えなかったので大炎上／成功例：採用に金をかける

[toruhjp]

「事業内容によって必要な〇〇は異なる」というわけで、〇〇にはなんでも当てはまるでしょうね。なにが必要か判断するべく期間やスコープや予算などで区切らないと、まともな議論にはなりにくいもんです。

[tg30yen]

toCであっても管理画面側はtoBに近いと思う。

[t2y-1979]

チームにシニアエンジニアが1人いればいいと思う。前にシニアが1人もいないチームが迷走しているのをみたことがある

[chiroruxx]

UXが重要だからプロダクト志向の人を採るっていうのがよくわかんないな。

[boomerangj]

必要なのがエンジニアですらない場合もあるからな。作っても作っても間に合わないのは、作るもの自体が無駄だったり無理だったりするのが根本原因のケースも。金だけはあるから下手に採用力は高かったりして困るやつ

[satosssi]

今日の参考文献

[cpw]

たしかにねー。本当そう思う。言語の選択とかも採用を考えてしていきたいですよね