- 「10xエンジニア」は直感的にはもっともらしいが、実際の生産性を客観的に測定することは非常に難しく、不変の個人的特性として捉えるのも誤ったアプローチである
- ソフトウェアの実質的なオーナーシップと成果物は、エンジニアリングチーム単位の協業と能力によって決まる
- 本当に優れた組織とは、特別に卓越した人だけでなく、普通のエンジニアが継続的に良い結果を出せる環境を作る場所である
- システムは普通の人がミスをしたり疲れたりもすることを考慮して設計すべきであり、**「10xチーム」**を作ることに集中すべきである
- ソフトウェアシステムの設計と文化は、**「普通の人」**の特性、多様性、成長の可能性を基盤にすべきである
- 最終的に生産性の中核指標はビジネスインパクトであり、「最高の人材」ではなく「適切な人」を採用し、チームを構成することが重要である
「普通のエンジニア」を称えて
- この記事は、「10xエンジニア」という概念への批判と、普通のエンジニアたちが卓越したチーム成果を生み出す組織の重要性を説明する
「10xエンジニア」神話とその限界
- 誰もがキャリアの中で、まるで魔法使いのような並外れたエンジニアに出会った経験がある
- そこから「10xエンジニア」という概念が生まれたが、これは根拠が乏しく、偏見を強めることもある
- 生産性の単一の尺度を定めることは不可能に近い
- 使っている技術スタック、ドメイン、開発段階、市場状況、経験など、変数の組み合わせが無限にある
- ある人が特定の分野では10xエンジニアであっても、ほとんどの領域では普通か平均以下である可能性がある
- かつて優れたDBREだったとしても、時間がたてばその分野で普通の水準になることがある
- 結局、誰もあらゆる分野で常に10倍優れていることはできない
チーム中心のソフトウェアオーナーシップ
- ソフトウェアはチームが所有し管理するものであり、個人が担当するものではない
- ソフトウェアの提供、保守、改善、拡張、リファクタリングなど、あらゆる過程はチーム単位で行われる
- 一人が所有するシステムは、その人が休暇や転職などで不在になると**単一障害点（SPOF）**となり、組織の脆弱性として作用する
- スタートアップでは初期に個人所有が避けられない場合もあるが、組織が成長したら必ずチームオーナーシップへ移行すべきである
- エンジニアリングリーダーの中核的な任務は高性能チームの育成に集中することであり、「10xエンジニア」より10xチームを作ることが重要である
真に高成果な組織の条件
- 多くの企業はFAANG出身者、有名大学卒、Staff Engineer中心でチームを組むことを好む
- しかし本当に良い組織とは、普通のエンジニアが安定して実質的なインパクトを出せる場所である
- 「最高」の人だけが成果を出せる組織ではなく、一般的な開発者でも主体的に成長し、製品とビジネスに前向きな影響を与えられるシステムを作ることのほうが、より大きな競争力になる
- むしろこうした組織のほうが、より多くのワールドクラスのエンジニアを育てる
「普通さ」の意味の再定義
- ソフトウェア業界には「上位10%」「top .1%」などのエリート中心の思考が蔓延している
- しかし大多数のエンジニアは、多様な経験と練習を通じて成長してきた普通の人であると認めることが重要である
- 誰も生まれつき「優れたエンジニア」として生まれてくるわけではない
- 偉大なエンジニアは作られるものであり、誰もが学習と経験を通じて素晴らしくなれる
普通の人のためのシステム設計
- 採用時には突出した強みを見るのが正しいが、システムを設計するときは、人が普通にミスをし、疲れ、慣れに頼るという現実を考慮しなければならない
- 一般的なエンジニアは認知バイアス、疲労、感情の波などの影響を受ける
- システムが賢い少数ではなく普通のエンジニアの観点に合わせて設計されてこそ、優れた人材の創造的能力を製品そのものに集中させられる
「10xチーム」を作る方法
- コードを書くこととデプロイの間隔をできるだけ短くする
- 迅速なデプロイサイクルは認知負荷を減らし、より速い実験とフィードバックを可能にする
- デプロイが遅いほど複数の変更が一度にまとまり、問題追跡とロールバックが難しくなる
- ミスからの復旧とロールバックを容易にする
- 開発者が自分でコードをデプロイし、問題を見つけたら迅速に復旧できるべきである
- 正しい行動を簡単に、誤った行動を難しくする
- デザイナー、プラットフォームエンジニアと協力し、ガードレールとセルフサービスの仕組みを構築する
- 可観測性と計測ツールに積極的に投資する
- 実際のコードの動作を可視化し、すべてのエンジニアが容易にシステムを理解しデバッグできるよう支援する
- 内部ツールと生産性向上にエンジニアリングリソースを投資する
- こうしたシステムには別個のオーナーシップが必要であり、全社的な優先事項であるべきだ
- 包摂的な文化を醸成する
- 誰もが質問し、ミスし、探索できる環境
- 多様な背景、スキル、年次が混ざり合ったチームは、よりレジリエンスが高く、変化に強い
- あらゆるレベルのエンジニアが混在するチームを構成する
- ジュニアからシニアまで、互いに学び教え合いながら共に成長する構造
- こうしたシステムは、新規入社者のオンボーディングやチーム間異動などにも再利用できる
生産性の本当の尺度: 「ビジネスインパクト」
- 最終的にソフトウェアエンジニアリングの生産性の尺度はビジネスインパクトである
- 多くのコードを書くことではなく、問題を解決し価値を生み出すことが本質である
- 実際に業界を動かしている主役はStaff+エンジニアではなく、シニアおよびミドルレベルのエンジニアである
- 彼らが組織の基盤を成し、継続的にビジネスを前進させる
- Staff+レベルだけがインパクトを出せるのなら、それは組織に問題があるというサインである
ワールドクラスのエンジニアを育てる組織
- 優れたエンジニアでなくても、誰もがインパクトを出せる組織こそ本当に良い組織である
- 最高の組織は、必ずしも世界最高水準の人材だけを別途採用しなくても、自然とワールドクラスのエンジニアを最も多く生み出す
- エンジニアが問題解決、成長、インパクトに没頭できる場所に人材が集まり、「幸せに働き成長する経験」そのものが好循環を導く
- リーダーは優れた人材の個人能力に依存するのではなく、それを組織全体の成長と顧客価値につなげる役割を担うべきである
「最高の人材」より「適切な人」を採用する
- 業界は「最高」ばかりを求めがちだが、本当に重要なのはシステムと環境である
- 「最高の人材」より、チームと組織に適した人を見つけることのほうが、より大きな競争力になる
- 弱点のない人より、固有の強みを持ち、**組織の多様性と調和を高める「適切な人材」**でチームを構成するほうが効率的である
- 包摂的で多様なチームが、実質的に成果、成長、長期的成功を導き出す
- 誰もが仕事を楽しみ、成長し、意味のある結果を出せる場所こそ真の世界最高の組織であり、失敗やミスからも学べる文化の中でエンジニアと組織の双方が成長する
- そうした組織こそが次世代のエンジニアを惹きつけ、すでに優れた人材にも留まりたいと思わせる環境である
1件のコメント
Hacker Newsのコメント
ソフトウェアの所有権とデリバリーの最小単位をエンジニアリングチームだとする主張には共感するが、少し物足りなさも感じる立場だ。この構造は、エンジニアがマネージャーやプロダクト部門に比べて二級市民になる文化とつながっている。私たちはデリバリーにしか責任を持たず、本当に意味のある意思決定を、チームのごく小さな範囲を超えて独立して下すことはできない。最高のチームでは裁量のスパンが数か月、時には数年に及ぶが、ほとんどのチームでは数日から数週間のレベルまで縮んでしまう。しかし実際には、エンジニアが実質的な所有権を持ちながら、システムが壊れたり危険になったりせず長く続けられる構造は十分可能だ。秘訣は余裕（slack）を確保し、質の高い仕事を奨励し、メンバーの誰もが柔軟に業務を切り替えられるだけの十分な自由を与えることだ。各自が所有権を持って長期的な決定を下しつつ、ad hocに協業し、暗黙知を共有することで、誰かが突然入って助けたり、そのまま引き継いだりするシナリオも自然に成り立つ。実体験では、こうしたチームは普通のチームよりリライトは多いが、全体としてはるかに生産的だ。システムを小さな塊ごとに段階的にリライトすることは、設計の進化と組織内の知識・能力の蓄積の両方に非常に効果的だ。表面的には無駄に見えても、組織全体を柔軟で回復力のあるものにするために不可欠な余裕だ。むしろ、いわゆる無駄を減らそうとするトップダウン組織の多くのプロセスが、実際には重要な「slack」を消しているのだという確信がますます強くなっている
エンジニアリング外の人は、エンジニアが下した長期的な決定をすぐには評価できず、どんな報酬を与えるべきか分からないことが多い。これは同じエンジニアリングチームの外に出ても同じだ。内在的な価値を持つ長期作業について、その価値が本当にあるのかどうかを自分で直接評価する能力がないからだ。自分が長期的な意思決定とslack timeの使い方に自信があるなら、デリバリーへの報酬を受け取る形でも構わない。いずれその長期的な取り組みが、より良い結果として返ってくるからだ
ソフトウェアのリライトは開発過程で重要な役割を果たすと思う。本当の「アジャイル」とは、最初のアーキテクチャを気にしすぎず、すばやくプロトタイプを作って要求の変化に柔軟に対応するやり方だ。コーディングは文章を書くことに似ていて、最初の草稿は荒くてもまず書き進め、2つ目のバージョンで改善するほうがずっと効率的だ。最初の草稿の目的は良いものを作ることではなく、素早く何かを作って問題領域を探索し、エッジケースを把握することにある。こうした働き方は経営陣にはあまり通じない。動くプロトタイプを見せた瞬間に「これをそのまま出そう」と言うだけで、リライトの時間をくれない。解決策としては、組織の階層をフラットにし、エンジニアにコードの所有権を実際に戻すのがよい。エンジニアとプロダクトオーナーが一緒に民主的に意思決定する構造が望ましい
私もかつては「個人の所有権」を重視していたし、今でもエンジニアが所有権を持てるとは思うが、実際には多くのエンジニアがそれを望んでいないことも認める。大半のエンジニアはチーム単位なら受け入れるが、個々のエンジニアレベルの所有権にはあまり関心がない。単なる生計のための仕事だからだ。これを個人任せにするとチーム内の不信を生んだり、リーダーシップ志向のないメンバーを疎外したりして、結局は誰も実質的な裁量を持たない事態になりやすい。チーム単位で所有権と裁量を与える構造のほうがはるかに簡単で効果的だ。チームリーダーやマネージャーがいるからこそ可能なダイナミクスでもある。個人ごとにソフトウェアの所有権を持たせると、人の入れ替わり、安定性、キャリアなどの変数による失敗リスクが大きすぎる。どれほど健全な組織でも大小の問題はあるもので、こうした構造では失敗に至る経路が最短になる。ギアボックスを考えると分かりやすい。ギアが1つしかなくて壊れたら進めないが、複数あれば不便でも、どれかが壊れてもすぐには止まらずに進み続けられる
本当に実質的な個人所有権は可能だと思う。むしろ唯一、本当に「生産的」になり得る方法だとさえ思う。ただし、これが本質的な論点ではない。個人は代替不可能だが、チームメンバーは構造次第である程度は代替可能だ。組織が大きくなるほどチーム単位の予測可能性を求めるようになり、そのためにはメンバーの代替可能性の確保、つまり redundancy が必要になる。エンジニアリングでも、信頼性（回復力）のために redundancy を持たせ、効率性とは redundancy を減らすこととのトレードオフでもある
私たちは「デリバリー」にしか責任がないという構造で働かされ、所有権とは結局負担だけが増えて実質的な報酬はないものだった。仕事はページに機能を貼り付けることに限定される。追加の責任が生じるなら、それに対する追加の報酬があるべきだ。マネージャーや役員は責任を負う人数に応じて報酬が増えるのだから、開発者も同じであるべきだ
最高のチームは、普通のエンジニアがすさまじい成果を出せる文化を持つチームだと確信している。世間で言う「エンジニアリングの質」や人材採用よりも、文化、信頼、システム、プロセスのほうがはるかに重要だ。「誰でも最高のエンジニアがいる組織を作れる」という言い方があるが、実際にそんなチームを作り上げた組織は本当に少数だ。ほとんどがトレーディング会社か特殊・研究組織で、なぜ皆できないのか不思議に思う。結局のところ、「生産性」という概念自体が何を意味するのかも曖昧だ。単に組織内の dysfunction に耐えて突破する能力を見る評価システムもあるが、それが本当の「トップエンジニア」の意味だとは思わない
本当に優れたエンジニアの供給は限られているので、結局はより大きな会社が、より面白い仕事やより高い給料を掲げて同じ人材を連れていくことになる
他の人たちが言っていたお金の問題も大きいが、「時間」も非常に大きい。会社には完璧な「ユニコーン」人材が現れるまで待つ余裕がなく、今すぐ採用できる人材で急いで穴を埋めるしかないこともある。一部の会社、とくにクオンツファイナンスのような分野では、システムプログラマ・数学者・金融市場の専門家を1人で兼ねるスーパーエンジニアが、3人の専門家チームよりはるかに大きな価値を出すこともある。しかし、そういう人を見つけるには時間がかかりすぎる。Web開発だけを見ても、ネットワークプロトコルからシステム管理、分散システム、データベース、フロントエンドまで本当に幅広く理解する「真のフルスタック」開発者はごく少数だ。十分な時間とコストを持つ組織だけが、こうした人材を集めて最高の製品を作れる。もちろん、その製品が本当にそこまでの品質を必要とするかは別の問いだ
根本的に、世界中の「最高のエンジニア」の供給量はきわめて限られている。上位10%の給与を払え、そのレベルの人材を集めて維持できるなら成功だ。実際には「誰でも」できることではなく、経営陣が学習と成長に集中するソシオテクニカル・システムを設計するリーダーシップが本当に必要だ。それ自体が見事な仕事だ
最大の問題は、たいていの一線級・二線級の経営陣がそれほど優秀ではないことだ。生産的な環境を作り、維持する能力が足りない。根本的な解決策は結局「金」を多く払うことだ。金額が大きければ、たいていの厳しい条件も受け入れられる
予算の問題を離れても、本当に優秀なエンジニアがチームプレーにはむしろ向かないこともある。優れた頭脳は、ときに必要不可欠な妥協や、退屈だが必要な作業の妨げになり得る
「ビジネスインパクトだけが唯一の生産性指標だ」という主張には大きく同意できない。この見方は、測定可能な変化と短期成果へと視野を移し、熟練したエンジニアの本当の価値を見落とさせる。本当に実力のある人は、プロジェクトや会社を台無しにしかねない危険な landmine を事前に防ぐところにいる。しかし、こうした「消えたリスク」は測定しにくく、しかも平凡に聞こえる形で伝えるのはほとんど不可能だ
「インパクト」は必ずしも短期の観点ではない。組織に最大のインパクトを与える人は、長期的な視点で動いている
私は「生産性」や「インパクト」をあえて曖昧な表現で語っている。たとえば「全体として見れば、Xは本当に仕事ができた」といった具合に。こういうものは数値化も明確な規定も難しいが、もともと複雑で創造的な組織では、人間の洞察と判断のほうが重要だ。経営を何でも数値化しようとするのは、本質的に近視眼的だ
プロジェクト管理やリスク回避だけでエンジニアの価値を測ることには同意しないが、すべてを「ビジネスインパクト」に還元するのも不快だ。世の中には、お金とは無関係に個人や人類や世界にとって意味のある仕事がたくさんある。私が最も尊敬するエンジニアは、ポスト2001のシリコンバレーの神話的な人物たちよりも、ジョン・フォン・ノイマン、ロバート・オッペンハイマー、ニコラ・テスラ、レオナルド・ダ・ヴィンチ、ローマの水道やエジプトのピラミッドを作った誰か、バビロニアやメソアメリカの天文学者たちだ。彼らはビジネスインパクトを残したのか。テスラがかつて Westinghouse に利益をもたらしたとしても、それで彼の業績を説明することはできない。実際、彼はビジネス面では平凡だった。現代のコンピューティング産業の巨人も同じだ。Nvidia や Geoff Hinton が途方もない成功を収めたのには、インターネットの広告化でデータが爆発的に増えたという「運」も一役買っている。本当に実力がありながら埋もれたまま消えていった例も多い。Doug Lenat のような AI 分野の大家でさえ、結局は歴史の流れの中で発掘されなかったこともある。成功するかどうかは、多くの場合、本人の努力とすら無関係だ
効率的なシステムを作るか、災害の可能性を最小化するシステムを作るかの二者択一だ。実際にどんな惨事が防がれたのかを証明するのは難しく、負の影響そのものが「起きなかった出来事」なので、結果として示すことも困難だ
会社は「未知のもの」のリスクを、何とかしてもっと上手く定量化しようと努力すべきだ
幸運にもこれまで複数の素晴らしいチームで働き、今もそうしたチームを率いている。記事とは違って、こうしたチームほど組織として管理するのが難しいことが多い。大規模組織は標準化に焦点を当てるため、かえって優秀なエンジニアが力を発揮できず、動機も失いがちだ。全員を優れたエンジニアに育てることはできないという悲観的な見方には同意しない。実際には、継続的に投資すれば立派なエンジニアに育てられるし、長期的には優秀な人材プールが厚くなることで得られる利益が、その投資コストを十分に上回ると思っている
効果的に測定できないからといって、そのもの自体が存在しないわけではない。個別の生産性、つまり個人の仕事上の成果は確かにある。たぶんグループ単位の生産性のほうが測りやすいだけだ。「ビジネスインパクト」はむしろずっと恣意的で、そんな尺度では本当に生産的な人材を残しにくい。専門知識の評価は、同等の経験がない限り非常に難しい。助言はできても、相手にそれを受け入れるだけの知的な余裕があるかは別問題だ。自分が天才なのか、ただ自信過剰なだけなのか、どうやって分かるだろうか
問題は、生産性を「測定」できないことではなく、抽象的な意味でさえ「定義」できないことだ。単に「replacement」よりどれだけ多く貢献したかを測っても、その結果が具体的にどうしてそうなったのかは説明してくれない。実際には、個人の影響力は文脈と組織全体によって決まる。もっと直接的な定義を下そうとしても、正解は組織や状況ごとに千差万別だ。これは十分考える価値があるが、「Top 1%」エンジニアという基準自体が本当に意味を持つのかにも疑問がある
本物の天才は、自分の成果を礼儀を守って分かりやすく説明できる。だから違いは十分に見分けられると思う
「普通のエンジニアが偉大な仕事をできるようにしてくれる組織が最高だ」という一節が気に入った。チーム全員がスーパースターである必要はない。平均的な開発者が十分に良く、信頼できる実力を発揮できるよう、どれだけうまく支援できるかが本当に重要だ
「正しいことを簡単に、間違ったことを難しくする」という原則は、私が出会ってきたすべてのプラットフォームチームの中核スローガンのようなものだ。目標は、エンジニアが直面する問題に対して「正解」が自然と目に入り、簡単に実装できるようにシステムを設計することだ。信頼性と運用しやすさを備え、自然とその方向に開発の「筋肉」を鍛えられるようにすれば、組織全体が利益を得る。この真理は今後も変わらず有効だ
golang, python, COBOL, lisp, perl, React, brainfuck などさまざまな言語やフレームワークが言及されるたびに、React をフロントエンド生態系全体だと勘違いする傾向があるように長いこと感じてきた。実際には React 以外にも多様なフロントエンドの世界があるのに、皆 React がすべてだと思っているようだ
うちの会社では、いつも態度の良い平均的なエンジニアを採用するほうを好む。資格だけ立派で態度の悪い人は、評判作りがうまくて上層部の信頼を簡単に得て、その後は無敵の存在になる。こういう人が居座ると、周囲は理不尽だと思っても問題提起しづらくなる。上層部も、自分の認識に合わないデータを簡単に無視する。客観的データより認識に頼るほうがずっと楽だからだ
「誰でも最高のエンジニアと一緒に働ける組織を作れるし、個人の能力中心の考え方はリーダーの実際の役割を曖昧にする。より未熟なエンジニアが力を尽くして結果を出せるようなシステムを作ることが、ものすごい競争優位になる」という主張に本当に共感する。私は 10x エンジニアではないが、最近の経験で言えば、チームに経験や実力の足りない人が多いと、複雑なチケットは結局いつも自分だけが引き受けることになった。このパターンが続くと、自分ひとりが大半の仕事を片付けるようになり、実際その役回りは大変だし、不公平にも感じる。正直、良い SRE は少し怠け者なくらいであるべきだと思っているので、チームメンバーにもっと仕事を分担してほしい気持ちが強かった。そこで数週間かなり集中的に働いて、最も複雑な部分にさまざまな抽象化を導入した（私は主に IAC を扱っているが、ソフトウェアでも似たようなパターンだ）。すると、比較的スキルや経験が不足しているエンジニアでも私の役割を分担できるようになり、私は自分の時間をより面白い問題に使えるようになった。誰に言われるでもなく、こんな試みをしたのは初めてだった。逆に、こうした構造がなく、ひとりでヒーローのように振る舞っていると、チーム全員が後ろからついて回ってミスの後始末に追われることになり、結局は本当に非効率なチームになってしまう