エンジニアを分類する、3つのタイプ
先日投稿したこのツイートがめっちゃバズりました
エンジニアのタイプは、技術が好きか、プロダクトが好きか、組織が好きかの3つに大きく分類できる。技術の人は技術の本質を追求しテックリード/アーキテクト、プロダクトの人は技術を手段と割り切りフルスタックエンジニア/PdM、組織の人は開発生産性を高めようとEM/PMOを目指すことが多い
— 山本 正喜 / Chatwork CEO (@cwmasaki) February 9, 2022
思っていた以上の反響をいただいて、いろいろと「このケースはどうなんだろ」というコメントも多数いただくので、この分類にいたった背景や考察などを、しっかり記事にしてみようと思います。140文字だと伝えきれない・・！
エンジニアとしての志向性を技術・プロダクト・組織のどれが好きかで分類すると、目指すキャリアパスを考えやすいよねという話で、私がよくエンジニアの若手に話している内容をツイートしたものでした。
3つのタイプについて
まず、この3つのタイプは、スキルの絶対量の話ではありません。
例えば、技術を手段として割り切るプロダクトが好きなエンジニアであっても、そこらの技術が好きなエンジニアに負けない技術力を持っている人は全然います。
あくまで何を「目的」とし、何を「手段」とするかというスタンスの違いなのです。
技術が好きな人は、技術の本質を追求することを目的とし、理論の実践・検証の手段としてプロダクト開発を行います。コンピューターサイエンスとしての体系だった考え方に基づき知識を積み上げ、あるべきアーキテクチャを現実に落とし込みたいのです。
数学的なアルゴリズムやバイナリ・プロトコルなど低レイヤの技術、プログラム言語そのもの、個々のフレームワークというよりもアーキテクチャの考え方自体、に興味を持ちます。プログラム言語は複数扱える人も多くフルスタックエンジニアに見える人もいますが、全レイヤを実装するためというより、言語設計が興味深い言語を勉強の意味で学んでいます。
できるだけ本質的なコードを書きたいので、PdMやPjMにはなぜやるかというロジックを強く求めますが、自分が調整役やPOになるイメージはあまりありません。チームの心理的安全性やカルチャーは重視しているが、非合理な人の感情と向き合うことは好きではなく、マネジメントはせず技術だけに向き合うテックリードやアーキテクトになりたいという人が多い気がします。
プロダクトが好きな人は、良いプロダクトをつくりユーザーに価値提供することを目的とし、その手段のひとつとして技術を使います。手段なので、別にどんな技術を使おうが、そして自分がコードを書かなくてもいいのです。必要であれば、書きますが。
自分のつくりたい機能をまるっと実装したいので、技術領域としてはレイヤをまたいでフルスタックに広く浅くなりやすい傾向があります。フロントエンドやモバイルなどUIに近いところから入り、FirebaseなどBaaS系を利用しながらも限界を感じてサーバーサイドに手を出していく、という人が最近は多い気がします(サーバーサイドからLL系言語で入る人も多い)。
興味範囲は技術の領域だけにとどまらず、UXやUIの領域やデータ分析などにも強いこだわりを持ちます。どう実装するかよりも、なぜ何をつくるか、どう改善していくのかを考えるようになり、PdMへのキャリアを進む人も。
組織が好きな人は、高い開発生産性を持つ優れた開発チームつくることを目的とし、手段としてプロダクトのデリバリを重視しますが、使用する技術や生み出したビジネス価値、事業インパクトそのものには深く踏み込みません。
一定の制約条件のなかで最大の成果を出すことにコミットし、スクラムなどアジャイル開発などに強く専門性を持っていく方もいますし、EMやdevHRとしてピープルマネジメント領域でチームコンディションやスキル開発、技術広報的な分野で活動を広げていく人もいます。
また、技術が好きなエンジニアだからといってプロダクトに興味ゼロかというとそんなことはありません。
技術：プロダクト：組織＝５：３：２のように、どの志向性が自分は強そうかな？というバランスとしてとらえておくと良いと思います。マネージャーやチームメンバーと相互評価してみると良いかも。
このバランスが極端に違う人とチームになった場合、会話が噛み合わなくなることがあります。特に、技術志向の人とプロダクト志向の人は目的と手段が逆なのですから。でも、そうはじめから認識しておくことで、相互理解が進むことがあると思います。
そして、この3つのうちどのタイプが優れているかという話ではなく、成功するプロダクトをつくるには、この3タイプがプロダクト組織にそろっていることが必須だと思います。
私がそう思うに至った、Chatworkでの事例をシェアできればと思います。
Chatworkでの事例
もともと私は学生起業からスタートし、20代の若いうちから技術の責任者をしてきました。
まだ小さな会社だった時は、自分が一番技術ができたし、プロダクトのこともリードしながら、開発組織のマネジメントもすべてやってきました。
その頃、自分のエンジニアとしての志向性に気づいていませんでしたが、私は典型的なプロダクトが好きなタイプ。
モバイルからフロントエンド、サーバーサイド、DB設計なども含めてフルスタックにゴリゴリとコードを書き、プロダクトの仕様も自分でコードを書きながらその場で決めていくような、超高速な開発スタイルで実装を行っていました。
転機が来たのは、Chatworkというプロダクトが大きく当たった時。スピード優先で積み上げてきた技術的負債と、激増するトラフィックとデータ量にPaaS任せにしたアーキテクチャの限界が来たのです。
原因不明の障害が頻発するようになり、胃が痛い毎日を過ごしていた私は、アーキテクチャの大刷新を決断します。無謀なチャレンジだったのですが、その決断をブログに書いたところ業界トップクラスの高い技術力を持つエンジニアが興味を持ってくれ、参画してくれることとなりました。
それが、私がはじめて技術が好きなエンジニアと出会った経験でした。
自分とのあまりの技術力の差や、その技術の本質を追求し続けるその純粋さと熱量に、大きなショックを受けたことをいまでも覚えています。
これが、本物のエンジニアなんだと。
ハイレベルな開発チームが立ち上がり、DDD(ドメイン駆動設計)の考え方をベースにユビキタス言語の整備やドメインモデルの設計が進み、旧システムからのマイグレーションプランも含め、理想的なアーキテクチャが見えてきました。
しかし、アーキテクチャの刷新プロジェクトは1年半の開発を経て、大失敗することとなります。理想的すぎるアーキテクチャを目指しすぎて完成に至らず、頓挫してしまったのです。。。
私含めた開発チームが絶望に包まれていたそんな時に、強力なVPoEが入社してくれました。そう、開発チームに欠けていた組織が好きなエンジニアが加わってくれたのでした。
開発チームに明確なドキュメント文化が導入され、段階的なPoCを経てのアーキテクチャ選定およびプロジェクト進行、高い技術力を持つ外部ベンダの協力をとりつけるなど、大きくプロジェクトの進め方は刷新されました。
そこから約1年を経て、スコープを限定はしましたが無事に刷新プロジェクトはリリースされ、劇的にサービスの安定性向上を実現することができました。
プロダクトが好きなエンジニアがいなければ、そもそもChatworkの成長はなかったでしょう。
技術が好きなエンジニアがいなければ、サービススケール時に起きる技術的な課題を突破することはできませんでした。
組織が好きなエンジニアがいなければ、規模が拡大したプロジェクトを完遂することはできていなかったはずです。
プロダクトづくりはチーム開発。自分ひとりで持てる専門性には必ず限界があります。自分とは違うタイプのエンジニアを理解し、お互いのスタンスを尊重しあいながら、強み・弱みを補完しあえるチームをつくっていくことが大切なのだと思います。（もう一度言いますが、どのタイプが優れているかという話ではありません）
CPO + CTO + VPoE のような構成(タイトルは何でも良い)で、このタイプが揃っているマネジメントチームをつくり、組織全体としてバランスがとれると強いプロダクトチームになっていくのではないかと思っていて、いまでも意識しています。
あわせて、この記事に関連する他の投稿もどうぞ
エンジニア組織のトップとなるCTOについて、どのような人を採用すべきか、どうやって採用すべきかなどをまとめています。本記事の3タイプを意識しながら読むとCTOへの理解が深まるかもしれません
エンジニアだけの話ではないですが、私が最終面接でどのような点を見ているかをまとめています。エンジニア採用の時では、本記事の3タイプも意識して確認しています
最後まで読んでいただきありがとうございました。
↓❤️スキをクリックしていただけると継続する励みになります！🙇🏻♂️