はじめに
株式会社ソナー、エンジニアリングマネージャの佐藤です。
開発組織にいると、
「この人がいれば大丈夫」
と思える 強いエンジニア に出会うことはないでしょうか？
設計も判断も速く、トラブル対応も一人でこなせる。
短期的には、これほど心強い存在はいません。
ただ一方で、
強いエンジニアがいるのに、チームが強くならない
という状況も、同じくらいよく見かけます。
この記事では、
「強いエンジニア」と「強いチーム」は何が違うのか、
そしてなぜ私たちは後者を選びたいのかについて書いてみます。
1. 強いエンジニアがいる＝チームが強い、ではない
強いエンジニアがいるチームでは、こんなことが起きがちです。
- 設計や難しい判断は、いつも同じ人が決める
- レビューは「正解」を教える場になる
- 周囲は「任せたほうが早い」と考え始める
結果として、
- その人が休むと開発が止まる
- 他のメンバーが育ちにくい
- チームとしての判断力が溜まらない
これは本人の能力や姿勢の問題ではありません。
むしろ 優秀で責任感が強い人ほど起きやすい構造 だと感じています。
2. ソフトウェア開発は「チームスポーツ」
Google のエンジニア文化を紹介した書籍
『Team Geek ― Googleのギークたちはいかにしてチームを作るのか』
では、ソフトウェア開発について次のような前提が語られています。
ソフトウェア開発は個人競技ではなく、チームスポーツである
この本で繰り返し強調されているのは、
技術力そのもの以上に、
- 謙虚さ（Humility）
- 尊敬（Respect）
- 信頼（Trust）
といった、人と人との関係性です。
どれだけ優れたエンジニアであっても、
チームとして機能しなければ、
長期的に価値を出し続けることはできない。
この考え方に立つと、
「誰か一人がどれだけ強いか」よりも、
「チームとしてどれだけ回り続けられるか」が
自然と重要になってきます。
3. Netflixのブリリアントジャークと、もう一つの難しさ
Netflix のカルチャーを紹介した
『NO RULES（ノー・ルールズ） 世界一「自由」な会社、NETFLIX』
には、ブリリアントジャーク という言葉が登場します。
意味するところはシンプルで、
- 圧倒的に優秀であってもチームを壊す存在であればその人は不要である
という考え方です。
ただ、現場で本当に難しいのは
いわゆる「嫌な人」ではありません。
問題になりやすいのは、
善意で、責任感が強く、結果を出してしまうエンジニア です。
- 教えるつもりで設計を先に決めてしまう
- 良かれと思って、レビューで正解を出し続ける
- チームを守るために、自分が抱え込む
本人はチームのために動いている。
それでも結果として、チームは考えなくなり、強くならない。
このタイプはブリリアントジャークとは違うため、
より気づきにくく、修正が難しい問題だと感じています。
4. 強いエンジニアより、強いチームを作るという選択
私たちが目指しているのは、
誰か一人が強い状態 ではなく、
チームとして戦える状態 です。
そのために意識していることは、特別なことではありません。
- 設計や判断を一人に集めない
- レビューは「正解を教える場」にしない
- 失敗する機会を奪わない
- リードやマネージャーは、前に立つより後ろで支える
強いエンジニアが
あえて一歩引くことで、
チーム全体が一段強くなることがあります。
それは個人の弱体化ではなく、
チームスポーツとしての成熟 だと考えています。
おわりに
私たちは
「一人で何でもできるエンジニア」よりも、
「チームを強くしようとするエンジニア」と一緒に働きたいと考えています。
もし、
- 強さを分けること
- 教える側に回ること
- チーム全体で成果を出すこと
に価値を感じる方がいれば、
きっと相性の良い環境だと思います。