私は、エンジニアがプロジェクトに与える多様な影響や、「10x エンジニア」といった評価の背後にある真の意味についてずっと考えてきました。過去数年間、この概念について多くの記事が議論されており、ある人々はそれを神話と呼び、他の人々はチームに少なくとも一人は必要だと考えています。これは注目を集める話題であり、この用語がしばしば論争を引き起こすのも理解できます。しかし、開発者がチームにもたらす真の価値を理解することは、どんな数字評価や彼らの leetCode スコアを超えて非常に重要だと思います。
私は 10x エンジニアが素晴らしい人々であるべきだと考える派の一人であり、私の見解は夢物語から来ているわけではありません。しかし、私はより微妙な見方を持っています。10x エンジニアは彼のコーディング能力とは無関係であり、むしろ誰もが 10x エンジニアになる可能性があると考えています。これは個人の資質ではなく、ソフトウェア開発者として行うすべての小さな決定の累積効果です —— 選択するツール、デバッグの試み方、チームメイトとの関わり方です。
私の初期のキャリアの中で、普通の開発者が一夜にして 10x エンジニアになる様子を目の当たりにしました。私たちは、毎秒何千ものリクエストに対応する高負荷プロジェクトを持っており、このプロジェクトは小さなチームによって開発されていました —— これは迅速に作業する必要があり、多次元クエリに一致させるために大量のデータをスキャンする必要がある検索モジュールです。一見、すべては順調に見え、コードは生産環境でしばらく動作していましたが、一部のユーザーはランダムに応答を受け取れないと不満を訴えていました。
時間が経つにつれて、エラー率は持続的に上昇しましたが、私たちは誰にも助けを求めることができませんでした。最初の開発チームは別のプロジェクトに移行しており、私たちを助ける時間がありませんでした。製品はすでにリリースされており、未解決の同時実行問題による予測不可能な動作のために、ユーザーは不満を抱く理由がありました。
その時、私たちの主要な開発者が立ち上がりました。彼は数日間問題を特定しようとし、コードの各行をデバッグしました。彼は私が知っている中で最も優れたエンジニアではありませんでしたが、その重要な瞬間に彼のプロジェクトへの貢献は、チームの他の誰よりも 10 倍でした。彼は私たちが半年以上も戦ってきた問題を一人で解決しました。
振り返ってみると、「10x 開発者」という言葉は、必要な貢献を公正に扱うには不十分です。これは、他のエンジニアよりも 10 倍速いということではなく、重要な決定を下し、チーム全体に顕著なポジティブな影響をもたらすことに関するものです。もしあなたの速度が速くても、他のすべてが問題になってしまった場合、あなたは本当に 10 倍のエンジニアなのか、それとも 0.1 倍のエンジニアなのでしょうか？
10 倍効率エンジニア：認知バイアスによって歪められた見解#
10 倍効率エンジニア（10x engineer）という用語は非常に魅力的です。それは劇的に人々の注意を引きます。誰かが一日で迅速に解決策を考案すると、すぐに —— 彼らは 10 倍効率エンジニアの称号を与えられます。しかし、この用語の使用には私たちの認知バイアスが満ちています。私たちは常に星のように輝く人物に目を奪われがちですが、実際にはシステムの正常な運転を静かに維持している地道で信頼できるエンジニアをしばしば見落としています。
なぜそうなるのでしょうか？私たちの脳はヒーローの物語を好むからです。私たちは生まれつき、目立つ異常者に対して賞賛を示すのが容易です。これは私たちの初期の生存本能に遡ります。誰かが何かにおいて非常に優れていると、私たちは彼らに注目します。たとえそのような状況が満月の夜に偶然にしか起こらないとしても。野外では、このヒューリスティックな思考は有用ですが、日常の判断においては、私たちに偏見をもたらす可能性があります。
たとえば、上の画像は 10 倍効率エンジニアに関する悪い例であり、完全に間違っています。
非常に一般的な認知バイアスの一つはハロー効果（halo effect）です。私たちの全体的な印象が、ある顕著な特性や業績によって影響を受けるとき、ハロー効果が発生します。たとえば、チームのあるメンバーが短期間で複雑なバグを解決した場合、私たちは彼のプロジェクトの締切における連続的な苦労を無視し、彼を依然として高効率な人物と見なすかもしれません。それは彼の一度の印象的な業績に基づいています。これにより、私たちは彼の能力を過大評価し、不合理に期待値を引き上げることがあります。
コントラスト効果（contrast effect）は、他のより目立つ同僚と比べて一人のスキルがすぐに目立たないために、彼らを過小評価する原因となることがあります。これにより、私たちは成功にとって同様に重要でありながら比較的目立たない安定した貢献を見落とすことがあります。私たちが二人のエンジニアの能力を直接比較し、彼ら自身の長所に基づいて判断するのではなく、こうしたことが起こります。想像してみてください、もし私たちの一人の開発者が素晴らしい機能のデモを終えた直後に、別の開発者のデモがそれほど目立たなかった場合、二人目のエンジニアは不公平に劣っているように見えるかもしれません —— 彼らの仕事が悪いわけではなく、他の人の輝きに隠れてしまったからです。単に隠れているからといって、彼らが 0.1 倍効率エンジニアであるとは限りません。私はその見解には同意しません。
次のバイアスは確認バイアスです。誰かが以前に素晴らしいことをしたのを見たとき、私たちはその人に対する見方を支持する詳細に注意を払い、合わない状況を無視し始めます。たとえば、誰かに 0.1 倍効率のレッテルを貼った場合、私たちは無意識のうちに彼らの成功を無視し、どんな小さなミスにも過度に注目し、初期の評価を強化してしまうかもしれません。
「生産環境でバグが発生しました。きっとまた David の問題のある変更です。」
ここでの問題は、私たちが目立つ行動に賞賛を与えるとき、コードのクリーンさを向上させるためにバックグラウンドで静かにリファクタリングを行っているチームメンバーや、新しい同僚を指導するために時間を費やしている人々を見逃してしまうことです。これらの行動は「10 倍効率エンジニアがここにいる」と大声で叫ぶことはありませんが、チームの長期的な成功にとって非常に重要です。
典型的なシーンと行動の表れ#
前述のように、10 倍効率エンジニアと - 10 倍効率エンジニアの議論は、日常的に行う無数の決定や、異なる状況に対する反応に大きく依存しています。それは単にコードを書く速度や実装するアルゴリズムの「賢さ」とは関係ありません。具体的なシーンを通じて、10 倍効率エンジニアになることは実際にはそれほど難しくないことを示しましょう。
生産中のバグの処理#
顧客または利害関係者がアプリケーションにおいて、あなたが担当している機能に関連する不一致を発見したと想像してみてください。誰かがあなたのコードに問題があると言ったとき、以下はあなたの反応の基本的なガイドラインとして考えられます。
✅ 10 倍効率エンジニア：「すぐに確認し、できるだけ早くお返事します。」あなたは迅速に問題を特定し、バグを修正し、チームに通知し、事後分析で将来の問題を避けるための解決策を共有します。
❌ 0.1 倍効率エンジニア：「私のコンピュータではうまく動いています。」最初は報告を無視し、問題を環境やユーザーの操作ミスに帰属させ、最終的に施した一時的なホットフィックスは問題を根本的に解決しませんでした。
コードレビューへの対応#
より経験豊富な開発者があなたのコードをレビューしており、別の実装案を提案し、Pull Request が承認される前に、会社の一般的な基準に従ってリファクタリングする必要があると述べています。
✅ 10 倍効率エンジニア：「フィードバックありがとうございます。これらの提案を非常に感謝しています！」あなたは心からこれらのフィードバックに感謝し、提案を統合するよう努力し、同僚の洞察に感謝します。個人の agenda を押し進めるのではなく、製品のより良い発展に集中します。
❌ 0.1 倍効率エンジニア：「あなたが間違っています、私のコードはすでに完璧です。」フィードバックに対して防御的になり、不合理に反論し、これはレビューのプロセスを遅らせるだけでなく、個人に焦点を当ててしまいます —— 彼らが書いたコードが製品全体の改善よりも重要だと考えています。
上層管理や行政業務の処理#
ソフトウェアエンジニアリングは単にコードを書くことではないことは周知の事実です。機能をリリースするには、多くの追加作業が伴います。日常の会議で、管理者がプロジェクト管理ツールを通じて透明性を高めるよう要求し始めたと想像してみてください。彼らは状況理解が不足しており、プロジェクト全体を円滑に進めるのが難しいと述べています。
✅ 10 倍効率エンジニア：「はい、Jira は時々確かに煩わしいですが、あなたの言いたいことは理解しています。それは確かに皆を同期させ、各自の役割を助けます。」あなたは開発と管理のバランスの重要性を理解し、必要な行政業務を処理するよう努力し、両者が重視されるようにします。
❌ 0.1 倍効率エンジニア：「Jira はひどい、誰もそれを気にしていない、それは本当の仕事とは言えない。」すべてのデモ、図面、チケット作業に対して非常に不耐性を示します。
新技術の導入#
あなたのプロジェクトが最後に正しくリファクタリングされてから 5 年が経過しました。ビジネスが多くの変化を遂げる中で、コードベースにはビジネスの成長によって引き起こされたすべての新しい境界条件に対処するための多くの一時的な解決策が追加されました。正しく行う時が来ました。変化するビジネスニーズに適応するためにゼロから始めます。
✅ 10 倍効率エンジニア：「私たちは概念実証を行い、どの技術が最適かを見てから、どの技術に投資するかを決定します。」あなたは新しいフレームワークを評価する際に慎重に考慮し、チームの能力とプロジェクトのニーズを考慮します。潜在的な技術的負債を考慮し、必要なリファクタリングを行うことを考えます。
❌ 0.1 倍効率エンジニア：「私たちは Angular を選ぶべきです、なぜならそれが最高だから、私が唯一知っているフレームワークで、私は今後 45 分間あなたと議論するつもりです。」新技術の採用を無考慮に推進し、技術的負債を蓄積し、新機能の開発を長期的なプロジェクトの健康よりも優先します。
チームの会議#
あなたとチームは、要求機能の代替開発案を実現するために座り込んでいます。多くの異なる実装方法があり、誰かがサーバーレスのアプローチを提案し、誰かが Rust 言語を使用してローカルのインフラストラクチャで構築することを提案します。多くの良いアイデアがチームメンバーの間で頻繁に交換されています。
✅ 10 倍効率エンジニア：「皆の意見を聞きましょう。」あなたは建設的な態度で議論に参加し、対話が秩序正しく進むようにし、時間制限を守ります。各メンバーが見解を述べるように促し、チームの共同決定に基づいて最も適切な行動方針を選びます。
❌ 0.1 倍効率エンジニア：「ここに私の見解があります、皆さん 45 分間静かにしてください。」議論を支配し、話題を逸らし、感情的な議論を引き起こします。
失敗したプロジェクトに直面する#
物事は常にうまくいくわけではなく、時には失敗します。失敗に対するあなたの反応も、0.1 倍効率エンジニアとの違いを示すことができます。これらの小さな相互作用は非常に重要です。
✅ 10 倍効率エンジニア：「さて、どこに問題があったのか客観的に分析し、誰かを責めることなく、将来同様のことが起こらないようにしましょう。」あなたは建設的な方法で問題を分析し、スケープゴートを探さない環境で探求し、将来の問題を防ぐために必要な改善を理解します。
❌ 0.1 倍効率エンジニア：「これはすべて誰々のせいだ、彼 / 彼女のコードはいつも問題がある。」他人に責任を押し付け、共同責任を回避し、プロジェクトの失敗の真の原因を隠すことが多く、自分の立場や虚栄心を守ります。
最小限の実行可能製品（MVP）の開発#
あなたがチームの主要なエンジニアであるか、技術共同創業者の役割を始めたばかりの場合、CEO が何を開発すべきか、いつリリースすべきかについてあなたに相談するかもしれません。重要なのは、作業量はそれに割り当てられた時間を満たすということです。
✅ 10 倍効率エンジニア：「私たちは十分良い製品を作り、市場に投入しましょう。」あなたは初期のユーザーを満足させるのに十分な機能を持ち、製品コンセプトを検証する最小限の実行可能製品（MVP）を提供することに集中します。
❌ 0.1 倍効率エンジニア：「私たちは製品を完璧にしてから、二度とリリースしないつもりです。」完璧を追求し、製品がリリースされるときに完全に機能することを望みます。
機能の優先順位付け#
すべてのソフトウェアエンジニアは、管理者と密接に協力する必要があります。通常、管理者はチームと話し合い、どの機能の開発順序を決定し、次に何を開発すべきかについてチームの意見を求めます。
✅ 10 倍効率エンジニア：「顧客からのフィードバックはどうですか？彼らの最大の問題点はどこですか？」あなたは製品管理と密接に協力し、顧客に最大の価値をもたらす機能の開発を優先します。
❌ 0.1 倍効率エンジニア：「私は Kubernetes を展開したいです。」技術的な内容が高いが影響力が小さい複雑な機能の開発を主張し、これらの機能は技術力を示しますが、ユーザーのニーズやビジネス目標には合致しません。
これらのシーンが示す目的は、あなたが夜遅くまで働いたり、残業したりすることなく、高度に複雑なソフトウェアを提供し、10 倍効率エンジニアとしての認識を得ることができるということです。重要なのは、日常業務の中で正しい決定を下し、高品質のコードを提出することです。
普通の人々が推進力#
大規模プロジェクトの成功は、特定のスーパースターデベロッパーの独力によるものではなく、チームの集団的（共同）努力によるものです。もちろん、問題を迅速に解決し、プリンターのようにプログラミングできる人がチームにいるのは素晴らしいことです。しかし、10 倍の能力や 100 倍の効率を持つエンジニアにも限界があります。彼らは病気になることもあり、休暇が必要なこともあり、時には調子が悪いこともあります。彼らは退職することもあります。これらの「スーパーヒーロー」に依存するプロジェクトは、これらの「スーパーヒーロー」が休息を必要とする際に、厄介な状況に直面する可能性があります。
10 倍エンジニアを雇う。出典：workchronicles.com
前述のシーンからわかるように、正しい態度を維持することは、あなたがチームの中で際立ち、10 倍エンジニアと見なされるのに十分です。もし全員がこのように進めば、あなたはベストプラクティスに目を向け、完璧を追求する優れたチームを持つことができるでしょう。それが最も重要ではないでしょうか？誰かが一日で非常に複雑な機能を作成したことを祝うよりも、重要ではありませんか？スムーズに行われた重要なソフトウェアの更新や製品リリースを考えてみてください。それは一人によって行われたのでしょうか？ほとんど不可能です。これは、全体のチームが数千の小さなタスク、苦情、問題、業務を処理して、すべてが正確であることを確認した結果です。
私たちは、さまざまなレベルでの貢献を公平に評価し、感謝すべきです。結局のところ、本当に成功したプロジェクトは、個人の瞬間的なひらめきによるものではなく、さまざまな側面からの共同努力によって生まれます。
2024 年 4 月 23 日更新：もしあなたが読むのではなく動画を見る方が好きで、私の姿を見たいだけなら —— 私は 10 倍エンジニアが持つべき特徴を共有する動画を録画しました。動画の最後まで視聴し、私の個人的な経験を共有してください。こちらをクリックして動画を見る。