This article was originally commissioned by Luca Rossi (paywalled) for refactoring.fm, on February 11th, 2025. Luca edited a version of it that emphasized the importance of building “10x engineering teams” . It was later picked up by IEEE Spectrum (!!!), who scrapped most of the teams content and published a different, shorter piece on March 13th.
This is my personal edit. It is not exactly identical to either of the versions that have been publicly released to date. It contains a lot of the source material for the talk I gave last week at #LDX3 in London, “In Praise of ‘Normal’ Engineers” (slides), and a couple weeks ago at CraftConf.
私たちの多くは、まるで魔法使いのようなエンジニアに何度か出会ったことがあるでしょう。複雑なメンタルモデルを推論したり、明白ではないのにエレガントな解決策に飛びついたり、並外れた速度で高品質なコードを生み出したりする能力において、他のエンジニアとは明らかに一線を画す人々です。
私はキャリアを通じて、数多くのこうした素晴らしい存在に出会ってきました。これこそが「10xエンジニア」というミームが不思議なほど長続きする理由だと思います。根拠となる研究は脆弱で粗雑なものであり、それを擁護するために人々が述べてきた主張はしばしば滑稽（例：「10xエンジニアはダークな背景を使い、UI作業はほとんどせず、メンターや面接官としては不適切」）で、あるいは露骨にステレオタイプを強調するものでした（「私たちはマーク・ザッカーバーグを思い出させるパーカーを着た若い男性を探す」）。しかし、経験と共鳴する点は否定できません。ただ真実に感じるのです。
問題は、生産性において他のエンジニアの10倍のエンジニアが存在するという考え方自体ではありません。この主張に問題はありません。実際、その程度は自明に真実だと思われます。私が問題視するのは、次の2点です。
第一に：生産性をどのように測定しているのか？ 生産性を測る「唯一の正しい指標」が存在し、それを標準化して人々を並べ替えられるという含意に問題があります。関わるスキルと経験の組み合わせの膨大さを少し考えてみてください。
マイクロプロセッサ、IoT、データベース内部、Webサービス、ユーザー体験、モバイルアプリ、コンサルティング、組み込みシステム、暗号、アニメーション、生成AIのモデル訓練など、どの分野で働いているのか？
golang、python、COBOL、lisp、perl、React、brainfuckなど、どの言語を使っているのか？ どのバージョン、どのライブラリ、どのフレームワーク、どのデータモデルか？ 他に習得しなければならないソフトウェアやビルド依存関係は何か？
デザイン、セキュリティ、コンプライアンス、データ可視化、マーケティング、ファイナンスなど、隣接するスキル、市場セグメント、または製品に関する専門知識を活用しているか？
開発のどの段階か？ 利用規模はどれくらいか？ コンサルティング的な助言をすること、製品市場適合を見つけるために素早くプロトタイプを作ること、長年の保守を見越して保守性とパフォーマンスに優れたコードを書くこと——どれが最も重要か？ あるいは火星探査機向けか、決して変更できないパッケージソフトウェアか？
また、人々とそのスキル・能力は静的ではありません。かつて私はかなり良いDBREでした（その本も共著しました）。当時は10xのDBエンジニアだったかもしれませんが、今は違います。クエリプランをデバッグしたことは何年もありません。
「10xエンジニア」という言葉は、10倍の生産性が個人の不変の特性であるかのように聞こえます。しかし、特定のスキルセットで10xのエンジニアであっても、それ以外の無数の領域では普通か平均（またはそれ以下）でしょう。私は世界クラスのエンジニアを多く知っていますが、すべての状況で誰よりも10倍優れている人には出会ったことがありません。
第二に、そしてより重要な点：だから何だというのか？ それは重要ではありません。個々のエンジニアがソフトウェアを所有するのではなく、チームがソフトウェアを所有します。 ソフトウェアの所有とデリバリーにおける最小単位はエンジニアリングチームです。個々のエンジニアがどれだけ速くソフトウェアを書けるかは問題ではなく、チームが集合的に、所有するソフトウェアを書く・テストする・レビューする・出荷する・保守する・リファクタリングする・拡張する・設計する・改訂する速度が重要です。
全員が同じソフトウェアデリバリーパイプラインを使います。もし貴社の最も遅いエンジニアが1行のコードを出荷するのに5時間かかるなら、最も速いエンジニアでも1行のコードを出荷するのに5時間かかります。コードを書く時間は、通常、ソフトウェア開発ライフサイクルの他のすべての部分に費やす時間に比べてはるかに小さいのです。
もしサービスやソフトウェアコンポーネントが単一のエンジニアによって所有されているなら、その人は単一障害点となります。
これが決して起こるべきではないと言っているわけではありません。スタートアップでは個人がソフトウェアを所有することはごく普通です。直面する最大の存続リスクは、十分に速く動けず、製品市場適合を見つけられず、事業を閉じることにあります。しかし、企業として成長し始め、ユーザーがより多くを求め、会社の存続を数年先まで見据え始めるにつれ、所有権はチームに移す必要があります。個々のエンジニアは病気になり、休暇を取り、会社を去ります。ビジネスはその事実に耐えられなければなりません。
チームがソフトウェアを所有するなら、あらゆるエンジニアリングリーダーの重要な仕事は、高パフォーマンスのエンジニアリングチームを作ることです。もし何かを10倍にする必要があるなら、これを10倍にしてください。 10xエンジニアリングチームを構築しましょう。
世界クラスのエンジニアリング組織について語る際、人々はしばしば、スタッフエンジニアやプリンシパルエンジニアが過剰に配置されたチーム、または元FAANG社員や一流大学出身者を積極的に採用しているチームを思い浮かべます。
しかし、本当に優れたエンジニアリング組織とは、「最高の」または最も由緒あるエンジニアでなくても、仕事をこなし、ビジネスに大きな影響を与えられる組織だと私は主張します。
実は逆だと考えています。本当に優れたエンジニアリング組織とは、普通の、日々の業務をこなすソフトウェアエンジニア——まともなソフトウェアエンジニアリングスキルと通常程度の専門知識を持つ人々——が、一貫して速く動き、コードを出荷し、ユーザーの声に応え、自分たちが構築したシステムを理解し、日々・週ごとにビジネスを少しずつ前進させられる組織です。
世界で最も経験豊富で優秀なエンジニアだけで製品を構築し進捗を生み出せる組織を作ることは、誰にでもできます。それは難しくありません。そして、個人の能力に spotlight を当てることは、リーダーが自らの仕事を怠ることを許すことにつながります。経験の浅いエンジニアでも、その努力とエネルギーを製品とビジネスの勢いに変換できる社会技術的システムを構築できれば、それは巨大な競争優位性となります。
本当に優れたエンジニアリング組織は、世界クラスのソフトウェアエンジニアを育てる組織でもあります。ただし、ここでは先走りしすぎています。
多くの技術者は、賢い子供としてのアイデンティティに強く執着してきました。ソフトウェア業界は、Netflixの「世界の才能の上位10%を探す」という表現から、Amazonの「bar-raising」の話、Coinbaseの最近の「上位0.1%を採用する」という主張まで、あらゆる場面でこの preoccupation を反映・強化する傾向があります。（本気ですか？ わかりました、Honeycombは上位.00001%のみを採用します！）
このエッセイでは、その荷物を脇に置き、自分たちを普通の人々として考えてみることを提案します。
自分を普通の人と思うのは謙虚なことですが、実際のところ私たちのほとんどは普通の人です（ただし、長年の高度に専門化された実践と経験を持っています）。そして
それは何も問題ありません。特定の基準で認定された天才であっても、運動感覚的、感情的、空間的、音楽的、言語的など、他の面ではかなり普通である可能性が高いのです。
ソフトウェアエンジニアリングは、抽象的推論を中心とした特定のタイプの知性を選択し、発達させますが、誰もが生まれつき優れたソフトウェアエンジニアではありません。 優れたエンジニアは作られるのであって、生まれるものではありません。自分たちを特別な階級の人々として考えることから得られる価値は、比較的普通の人々がかなりニッチな技能を非常に長い間実践してきた人々として集合的に考えることから得られる価値に比べて、それほど多くはないと思います。
才能を採用しチームを構築する際には、はい、間違いなく、人々がどのように exceptional で才能があり、強いのかを見極めることに注力すべきです。しかし、ソフトウェアデリバリーのための社会技術的システムを構築する際には、人々が普通であるすべての側面に焦点を当てるべきです。
普通の人々には認知バイアス——確証バイアス、近接バイアス、 hindsight bias——があります。私たちは一生懸命働き、気にかけ、最善を尽くしますが、物事を忘れたり、焦ったり、ぼーっとしたりもします。私たちの目は、色盲でない限り、赤色に引き寄せられます。私たちは習慣ややり方を身につけ、それを変えることに抵抗します。同じテキストブロックを繰り返し見ると、読むのをやめます。
私たちは身体を持つ存在であり、圧倒されたり疲労したりします。午前3時にアラートで起こされた場合、そのアラートに対応する際に、午後3時に同じことをしようとする場合よりもミスをしやすいのです。感情状態は仕事の質に影響します。人間関係は仕事を成し遂げる能力に影響します。
システムが普通のエンジニア向けに設計されている場合、彼らが持つ余剰の brilliance は、システム自体を navigating するのに浪費されるのではなく、製品そのものに注がれることになります。
これは特に驚くべきことではありません。すべてよく知られた知恵です。普通のエンジニアが速く動き、継続的に学び、チームとして優れた結果を出すことを可能にするソフトウェアデリバリーのための社会技術的システムを構築するためには、次のことを行うべきです。
可能な限り短くする。短ければ短いほど良い。私はこれについて何度も何度も書いて講演してきました。間隔が短いほど、認知的な carrying cost は低くなります。反復が速いほど良い。構築プロセスではなく製品に脳の多くを割けるようになります。
最も強力なことの一つは、1回のデプロイで1つのコミットを出荷できるほど短く高速なデプロイサイクルを持つことです。私はこれを「ソフトウェアエンジニアリングのデススパイラル」と呼んできました……デプロイサイクルが非常に長くなり、毎回のビルドに複数のエンジニアの差分をまとめて投入せざるを得なくなる状態です。遅くなればなるほどバッチングが増え、何が起こったのかを把握したりロールバックしたりすることが難しくなります。時間がかかればかかるほど必要な人員が増え、調整コストが高くなり、全員の動きが遅くなります。
デプロイ時間は開発プロセスの中心にあるフィードバックループです。これを短く緊密に保つことの重要性は、いくら強調してもしきれません。
開発者は自分のコードをデプロイし、それが意図した通りに動作しているかどうかを判断し、もしそうでなければ迅速かつ容易にロールフォワードまたはロールバックできるべきです。面倒なく、混乱なく、考える必要もなく。
デザイナーとデザイン思考を、エンジニアが本番システムに触れるすべての接点に取り入れましょう。プラットフォームエンジニアリングチームを使って、人々が迅速に変更を加えセルフサービスできるようにする方法を考える一方で、人々が深夜や非常にストレスを感じ、疲れており、おそらくパニック状態で本番に関わることも多いことを忘れないでください。ガードレールを構築しましょう。1行のコードを出荷する最速の方法は、同時に1行のコードを出荷する最も簡単な方法であるべきです。
書いたコードが実際に何をするのかは、読むだけでは——本当の意味で——わかりません。確実な方法は、コードを計装し、本番環境で実際のユーザーが実行する様子を観察することです。良い、フレンドリーな社会技術的システムは、センスメイキングのためのツールに多額の投資をします。
自分の仕事を可視化できることが、エンジニアリングの抽象概念を実際のエンジニアにとってアクセス可能にします。自分のコードをデバッグするためだけに世界クラスのエンジニアである必要はありません。
高速で安全なデプロイ、ガードレール、計装、高度に並列化されたテストスイートが「みんなの仕事」になると、結局誰の仕事にもなりません。エンジニアリング生産性はアウトソースできるものではありません。ソフトウェアベンダーと自社チームの間のインターフェースを管理することは、科学であり芸術でもあります。それを簡単で直感的に見せることは本当に難しいのです。所有者が必要です。
成長は標準であり、ベースラインです。人々は所属感を感じるときに最高の仕事をするものです。インクルーシブな文化とは、誰もが質問したり、探求したり、ミスをしたりすることを安全に感じられる文化です。誰もが同じ高い基準に置かれ、目標を達成するために必要なサポートと励ましを与えられる文化です。
ええ、似たような背景を持つ超シニアエンジニアだけで構成されたチームは信じられないほど速く動けますが、 monoculture は脆いです。誰かが病気になり、誰かが妊娠し、成長し始めて他の背景の人々を統合する必要が生じると、チーム全体が急速に脱線する可能性があります。
チームが、性別、人種的背景、アイデンティティ、年齢層、家族状況、地理的位置、スキルセットなどの多様性の中で運用することに慣れている——これが just table stakes、標準的な運用手順である場合——人生で何かが起こったときに、それに対応する準備がより整っています。
最高のエンジニアリングチームは、スタッフエンジニアやプリンシパルエンジニアが過剰に配置されているチームではありません。最高のエンジニアリングチームは、誰もオートパイロットで走っていない、300回目のログインページを叩き出しているわけではないチームです。誰もが自分に挑戦し、限界を押し広げることに取り組んでいます。誰もが学んでいて、誰もが教えて、誰もが自らの限界を押し広げ、成長しています。常に。
ちなみに、システムを resilient で、よく設計され、人間的になるために行ったすべての作業は、新しいエンジニアをオンボーディングしたり、ジュニア人材を育成したり、エンジニアがチーム間を移動したりするのを助けるためにも必要な作業と同じです。
それは何度も何度も何度も使われ、再利用されます。
エンジニアリング生産性に関して実際に重要な唯一のことは、ビジネスを確実に前進させているかどうかです。
つまり……私たちは真空の中でこれを行うことはできません。最も重要な質問は、正しいことに取り組んでいるかどうかであり、それはエンジニアリングだけでは、製品、デザイン、およびビジネスの他の部分からの助けなしには答えられない問題です。
ソフトウェアエンジニアリングは、大量のコードを書くことではなく、技術を使ってビジネス上の問題を解決することです。
シニアおよび中堅エンジニアは、実際には業界の主力です。彼らは日々・一歩一歩、ビジネスを前進させます。彼らは周囲の組織を常に確認して調整問題を解決するのではなく、頭を下げて作業に集中できます。製品を前進させるためにスタッフ+エンジニアである必要があるなら、何かが深刻に間違っています。
優れたエンジニアリング組織とは、世界最高のエンジニアの一人である必要がなくても大きな影響を与えられる組織です。しかし——むしろ皮肉なことに——優れたエンジニアリング組織は、世界クラスのエンジニアを誰よりも多く生み出します。
最高のエンジニアリング組織は、世界で最も賢く経験豊富な人々がいる組織ではなく、普通のソフトウェアエンジニアが一貫して進捗を生み、ユーザーに価値を提供し、日々ビジネスを前進させられる組織です。
エンジニアが仕事をこなし、大きな影響を与えられる場所は、トップパフォーマーを引きつける磁石です。エンジニアを最も幸せにするのは、ものを作り、問題を解決し、進捗を生み出すことです。
もし組織に世界クラスのエンジニアがいるなら、それは素晴らしいことです！ リーダーとしてのあなたの役割は、彼らの brilliance を顧客と他のエンジニアの利益のために活用し、その brilliance に依存しすぎないようにすることです。結局のところ、これらの人々はあなたに属しているわけではありません。彼らはいつでもドアから出て行く可能性があり、それは問題ないことなのです。
これらの人々は、チームプレイヤーでありエゴを抑えられるのであれば、驚異的な資産となり得ます。おそらくそれが、シリコンバレーをはじめとする多くのテック企業が彼らを特定し採用することに執着する理由でしょう。
しかし、企業はこれらの人々をすでに生み出された後に探し出すことに categorically overindex しており、その結果、世界全体の偏見や不平等を強化・再現することになります。才能は人口全体に均等に分布しているかもしれませんが、機会はそうではありません。
私たち（人類全体を指します）は、個人の主体性や特性に過度に重点を置き、私たちを形作り行動に影響を与えるシステムに十分な重点を置いていません。
エンジニアリングの採用と面接における「最高の人々を採用する」という過度な強調から、「適切な人々を採用する」というより合理的で正確な方向へ焦点を移すだけで、候補者が面接プロセスから self-selecting out する、応募者の多様性など、多くの問題が改善されるだろうと感じています。
人々を弱点の欠如ではなく独自の強みで採用できる環境を構築し、チームを構成することに重点を置き、インクルーシビティを倫理的理由だけでなくパフォーマンスを全員にとって高めるものとして当然のこととする——それは競争優位性です。インクルーシブな文化こそが、実際の meritocracy が依存するものです。
これは、エンジニアリングの才能（および良い人間）が蛾が炎に引き寄せられるように引き寄せられる場所です。 出荷することは気持ちが良い。ビジネスを前進させることは気持ちが良い。スキルを磨き、技能を向上させることは気持ちが良い。世界クラスのエンジニアになりたいと思う人々が集まる場所です。そして、世界クラスのエンジニアが次世代を育成するために留まりたいと思う場所です。
<3, charity
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.