- 優れたエンジニアとは、最高のプログラマーではなく、コードの周囲にある人間関係、政治、調整、曖昧さを乗りこなす術を身につけた人たちである
- 技術そのものよりも、プロジェクトやチームで繰り返し現れるパターンに焦点を当てており、ユーザー課題の解決、チーム協業、コード品質、キャリア管理などを幅広く扱っている
- 明確さこそがシニアエンジニアの中核的資質であり、賢さは単なるオーバーヘッドにすぎないこと、そして書かれなかったコードこそ最高のコードであるという逆説的な洞察を示している
- 大規模組織では、アラインメントの失敗が速度低下の主因であり、測定指標が目標になると歪みが生じるという、組織運営の落とし穴を明らかにしている
- 長期的な視点では、時間はお金よりも価値のある資源になり、ネットワークはどの職場よりも長く続くため、意図的なキャリア設計が必要になる
1. 最高のエンジニアはユーザー課題の解決に執着する
- 先に技術に惚れ込み、あとから適用先を探すのは魅力的だが、最も大きな価値を生み出すエンジニアは逆向きに考える。つまり、ユーザーの問題を深く理解し、そこから解決策を導く
- ユーザーへの執着とは、サポートチケットに時間を使い、ユーザーと話し、ユーザーの困りごとを観察し、根本にたどり着くまで**「なぜ」を問い続けること**を意味する
- 問題を本当に理解しているエンジニアは、しばしば優雅な解決策が予想より単純であることに気づく
- 解決策から出発するエンジニアは、その正当化のために複雑さを積み上げがちである
2. 正しいこと自体は簡単だが、みんなでそこに到達することこそが本当の仕事
- 技術的な議論にはすべて勝っても、プロジェクト全体では負けることがある。常に部屋で一番賢い人でありながら、静かな反感を積み上げていく優秀なエンジニアたちを見てきた
- その代償は、のちに「不可解な実行上の問題」や「妙な抵抗」として現れる
- 本当に重要なスキルは、正しいことそのものではなく、問題のアラインメントのために議論に参加し、他人のための余地を作り、自分の確信に懐疑的であり続けることである
- 強い意見、弱い執着。それは確信が足りないからではなく、不確実性の下での意思決定を自分のアイデンティティと結びつけるべきではないからだ
3. 行動バイアスを持ってリリースせよ。悪いページは編集できるが、空白のページは編集できない
- 完璧主義は麻痺を招く。まだ一度も作ったことのないものの理想的なアーキテクチャを、何週間も議論しているエンジニアたちを見てきた
- 完璧な解決策は思考だけからは生まれず、現実との接触から立ち現れる。AIはさまざまな形で助けになりうる
- まずやる、次にちゃんとやる、そしてさらに良くする、という順番で進める。醜くてもプロトタイプをユーザーの前に出し、雑でも設計ドキュメントのドラフトを書き、少し気恥ずかしいMVPをリリースする
- 1週間の実際のフィードバックからは、1か月の理論的な議論よりも多くを学べる。推進力は明確さを生み、分析麻痺は何も生み出さない
4. 明確さはシニアの証であり、賢さはオーバーヘッド
- 巧妙なコードを書きたくなる本能は、エンジニアにはほぼ普遍的で、能力の証明のように感じられる
- ソフトウェアエンジニアリングは、時間と他のプログラマーが加わったときに成立する。その環境では、明確さはスタイルの好みではなく、運用リスクの低減を意味する
- コードは、障害対応中の午前2時に保守する見知らぬ誰かのための戦略メモである。だから優雅さではなく、その人の理解しやすさを最適化すべきだ
- 最も尊敬されるシニアエンジニアたちは、賢さを毎回明確さと交換する方法を学んでいる
5. 新しさは、障害、採用、認知オーバーヘッドで返済する借金である
- 技術選定は、小さな**「イノベーショントークン」予算を持つ組織**のように扱い、実質的に非標準なものを採用するたびに1枚ずつ消費すると考えるべきだ。多くは抱えきれない
- 要点は「決して革新するな」ではなく、**「独自の革新によって報われる場所でのみ革新せよ」**ということ。それ以外では、退屈さがデフォルトであるべきだ
- 退屈さには既知の失敗モードがあるからだ
- 「その仕事に最適なツール」とは、しばしば**「多くの仕事にまたがって最悪を最小化するツール」**を意味する。ツール動物園の運営には本当にコストがかかるからだ
6. コードはあなたを擁護しない。人が擁護する
- キャリア初期には、優れた仕事はそれ自体が語ると信じていたが、それは誤りだった。コードはただリポジトリの中に静かに置かれているだけだ
- マネージャーが会議であなたの名前を出すか出さないか、同僚がプロジェクトにあなたを推薦するか別の人を推薦するかが現実である
- 大規模組織では、招待されていない会議で、あなたが直接書いていない要約をもとに、5分しかなく12個の優先事項を抱えた人たちが意思決定を行う
- あなたのいない部屋で誰もあなたの影響を言語化できないなら、その影響は実質的に任意扱いになる。これは自己宣伝の話ではなく、価値の連鎖を自分を含む全員にとって読めるものにすることだ
7. 最高のコードは、書く必要がなかったコード
- エンジニアリング文化では創造が称賛されるが、削除のほうが追加よりもシステムを良くすることが多いのに、コードを消して昇進する人はいない
- 書かれなかったすべてのコード行は、デバッグも、保守も、説明も不要な行である
- 作る前に問いを尽くすべきだ。「そもそも……やらなかったらどうなる？」。ときには答えが「何も悪いことは起きない」であり、それが解決策になる
- 問題は、エンジニアがコードを書けないことでも、AIで書けないことでもなく、あまりに上手く書けるせいで、そもそも書く必要があるのかを問うのを忘れてしまうことだ
8. 規模が大きくなると、バグですらユーザーを抱える
- 十分な数のユーザーがいれば、観測可能なあらゆる挙動が依存関係になる。約束したものかどうかは関係ない。誰かがAPIをスクレイピングし、癖を自動化し、バグを前提にキャッシュする
- ここからキャリアレベルの洞察が生まれる。互換性のための作業を「保守」、新機能を「本当の仕事」とみなすことはできない。互換性そのものが製品なのだ
- 時間、ツール、共感を伴って廃止を移行として設計しなければならない
- 多くの「API設計」は、実際には**「APIの引退設計」**を意味する
9. たいていの「遅い」チームは、実は足並みがそろっていない
- プロジェクトが遅れると、本能的には実行力を責めたくなる。皆が十分に頑張っていない、技術が悪い、エンジニアが足りない、と。しかし通常、本当の問題はそこではない
- 大企業では、チームは並行性の単位だが、チームが増えるほど調整コストは指数関数的に増えていく
- ほとんどの遅さは、実際にはアラインメントの失敗を意味する。間違ったものを作っているか、正しいものを互換性のない形で作っているのだ
- シニアエンジニアは、「より速くコードを書くこと」よりも、方向性、インターフェース、優先順位の明確化に多くの時間を使う。真のボトルネックがそこにあるからだ
10. コントロールできることに集中し、できないことは無視せよ
- 大企業では、無数の変数が自分のコントロール外にある。組織変更、経営判断、市場変化、製品転換。そこに囚われると、主体性のない不安が生まれる
- 正気を保ち、効果的でいられるエンジニアは、自分の影響範囲に集中する。再編が起きるかはコントロールできないが、仕事の質、どう反応するか、何を学ぶかはコントロールできる
- 不確実性に直面したら、問題を小さな断片に分け、自分に可能な具体的行動を見つけるべきだ
- これは受け身の受容ではなく、戦略的集中である。変えられないことに使うエネルギーは、変えられることから奪われるエネルギーだ
11. 抽象化は複雑さを消さない。ただ、自分がオンコールのときに押しつけてくるだけだ
- すべての抽象化は、その下に何があるかを理解しなくても済むだろう、という賭けであり、ときにはその賭けに勝てる
- しかし何かしらは必ず漏れ出す。そして漏れたときには、自分が何の上に立っているかを知っていなければならない
- シニアエンジニアは、スタックが高くなるほど、「より低いレイヤー」のことを学び続ける。それはノスタルジーではなく、抽象化が破綻し、午前3時にシステムと二人きりになる瞬間への敬意ゆえだ
- スタックは使えばいい。ただし、基礎的な失敗モードについての動作モデルは持っておく必要がある
12. 書くことは明確さを強制する。何かをよりよく学ぶ最速の方法は、教えようとすること
- 書くことは明確さを強制する。概念を他人に説明するとき――ドキュメント、発表、コードレビューコメント、さらにはAIとのチャットでさえ――自分の理解の穴に気づく
- 他人にとって読める形にする行為は、自分にとってもより読める形にする
- もちろん、外科医になる方法を教えることで学べる、という意味ではないが、その前提はソフトウェアエンジニアリングの領域では概ね真実だ
- これは知識共有の寛大さであるだけでなく、利己的な学習ハックでもある。理解したと思うなら、簡潔に説明してみること。詰まる場所こそ理解が浅い場所だ
- 教えることは、自分のメンタルモデルをデバッグすることである
13. 他の仕事を可能にする仕事は価値があるが、見えにくい
- グルー業務――ドキュメント整備、オンボーディング、チーム間調整、プロセス改善――は不可欠だが、無意識に引き受けると技術的な軌道を停滞させ、燃え尽きにつながりうる
- 罠は、それを単に「助かること」として扱い、意図的で、境界があり、可視化された影響として扱わないことだ
- 時間制限を設け、ローテーションし、成果物に変換すべきだ。ドキュメント、テンプレート、自動化などへ。そしてそれを性格特性ではなく、影響として読める形にしなければならない
- 価値があるのに見えない、というのはキャリア上危険な組み合わせである
14. すべての議論に勝っているなら、たぶん静かな抵抗を積み上げている
- 自分の確信を疑う方法を学んだ。あまりにも簡単に「勝てる」ときは、たいてい何かが間違っている
- 人々があなたと戦うのをやめるのは、あなたに説得されたからではなく、諦めたからかもしれない。そしてその不一致は会議ではなく実行の場で現れる
- 本当のアラインメントにはもっと時間がかかる。異なる視点を本当に理解し、フィードバックを統合し、ときには公然と考えを変える必要がある
- 正しいという短期的な感覚は、進んで協力してくれる同僚たちと長期的に何かを築く現実に比べれば、はるかに価値が低い
15. 測定が目標になると、それはもはや測定ではなくなる
- 管理側に見せるあらゆる指標は、最終的にはゲーム化される。悪意があるからではなく、人間は測定されるものを最適化するからだ
- コード行数を追えば行数が増え、ベロシティを追えば水増しされた見積もりが出てくる
- シニアの一手は、あらゆる指標要求に対してペアで応えることだ。1つは速度のため、もう1つは品質またはリスクのため。そして閾値崇拝ではなく、トレンドの解釈を主張する
- 目標は監視ではなく洞察である
16. わからないと認めることは、知ったふりをするよりも大きな安心感を生む
- 「わかりません」と言えるシニアエンジニアは、弱さを見せているのではなく、許可を生み出している
- リーダーが不確実性を認めると、他の人も同じようにしてよいという合図になる。対照的なのは、全員が理解しているふりをし、問題が爆発するまで隠される文化だ
- 最もシニアな人が混乱を認めないチームと、その被害を見てきた。質問は出ず、前提は疑われず、ジュニアエンジニアは他のみんなが理解していると思い込んで黙ってしまう
- 好奇心を体現すれば、本当に学ぶチームが生まれる
17. ネットワークは、あなたが持つどの仕事よりも長く続く
- キャリア初期には仕事に集中し、ネットワーキングをおろそかにしていた。振り返れば、それは失敗だった
- 社内外の関係性に投資した同僚たちは、何十年にもわたって恩恵を受けてきた
- 彼らは機会をいち早く耳にし、より速く橋を架け、役割に推薦され、何年もかけて信頼を築いた人たちとベンチャーを共同創業した
- 職場は永遠ではないが、ネットワークはそれぞれの職場より長生きする。取引的な立ち回りではなく、好奇心と寛大さをもって向き合うべきだ
- 去る時が来たとき、しばしば扉を開くのは人間関係である
18. ほとんどの性能向上は、賢さを足すことではなく、仕事を減らすことから生まれる
- システムが遅くなると、本能的には何かを足したくなる。キャッシュ層、並列処理、より賢いアルゴリズム。ときにはそれが正しいが、「そもそも計算しなくていいものは何か？」と問うことから、より大きな性能向上が生まれるのを何度も見てきた
- 不要な仕事を削ることは、ほぼ常に必要な仕事を速くすることよりも影響が大きい。最速のコードは、実行されないコードだ
- 最適化の前に、その仕事が本当に存在すべきなのかを疑うべきだ
19. プロセスは不確実性を減らすために存在するのであって、書類の痕跡を残すためではない
- 最高のプロセスは調整を容易にし、失敗を安くする。最悪のプロセスは官僚的な演劇であり、助けるためではなく、何かが起きたときに責任を割り当てるために存在する
- そのプロセスがどうリスクを減らし、どう明確さを高めるのか説明できないなら、おそらくただのオーバーヘッドである
- 人々が実際の仕事をするよりも、仕事を文書化することに多くの時間を使っているなら、何かが深刻に間違っている
20. 最終的に、時間はお金よりも価値のあるものになる。だからそれに応じて行動せよ
- キャリア初期には時間をお金と交換する。それ自体は問題ない。しかしある時点で、計算は逆転する。時間が再生不能な資源だと気づき始めるのだ
- 次の昇進レベルを追い、報酬の数パーセントをさらに最適化しようとして燃え尽きるシニアエンジニアたちを見てきた
- 何かを得た人もいるが、多くは後になって、手放したものにそれだけの価値があったのかと疑問を抱く
- 答えは「一生懸命働くな」ではなく、**「何と何を交換しているのかを理解し、意図的に交換せよ」**である
21. 近道はないが、複利はある
- 専門性は意図的な練習から生まれる。今のスキルを少し超えるところまで自分を押し出し、振り返り、繰り返す。それを何年も続ける。圧縮版はない
- 希望が持てるのは、学習が新しい選択肢を生むとき、複利で効いてくることだ。ただ新しい豆知識が増えるだけではない
- 書くこと。ただしエンゲージメントのためではなく、明確さのために。再利用可能な部品を作り、傷跡の組織をプレイブックとして蓄積する
- キャリアを複利運用として扱うエンジニアは、宝くじのように扱うエンジニアよりも、はるかに先へ進む傾向がある
最後に
- 21の教訓は多く見えるが、実際にはいくつかの中核的な考えに収束する。好奇心を保ち、謙虚さを保ち、仕事は常に人に関わるものだということ。つまり、作る相手であるユーザーと、ともに作るチームメンバーの両方である
- エンジニアリングのキャリアは、たくさん失敗してもなお前に進めるだけ十分に長い。そして私が最も尊敬するエンジニアたちは、すべてを正しくやった人ではなく、間違いから学び、見つけたことを共有し、現れ続けた人たちだった
- 旅の始まりにいるなら、時間とともにこれがより豊かになっていくことを知ってほしいし、すでに深いところにいるなら、このいくつかに共感してもらえればと思う
5件のコメント
Hacker Newsの反応
「規模が大きくなると、バグにもユーザーがつく」という言葉を思い出した
最初の職場でロード時間を5分から30秒に短縮したとき、顧客から不満が噴出したことがあった
以前はコンピュータを立ち上げてコーヒーを飲みながら雑談していた時間がなくなったからだ
この話の教訓は、単に改善するなということではなく、ソフトウェアは実際の人々の習慣や相互作用の中に存在することを忘れるなということだ
エンジニアの仕事はチケットを処理することではなく、本当のユーザー課題を解決することだ
効率を上げるほど従業員がより多くの肉体労働をしなければならず、かえって不満が出た
結局私は「良いシステムを壊した人」のように見られた
「十分に多くのユーザーがいれば、システムのあらゆる観測可能な挙動は、誰かにとって依存対象になる」という言葉がある
毎回「今度こそ修正されるだろう」と思っていたが、10年間修正されず、そのおかげでむしろ事業が成り立っていた
この三者は問題をそれぞれ異なる形で理解する
コードの意味は意図や希望で変わるものではなく、現実世界の制約の中でのみ機能する
関連記事: Laws of Software Evolution
だが、すべての会社がそう考えているわけではない
面接時の期待値を明確に把握することが重要だ
Addy Osmaniが書いた記事を見て、少し偽善を感じた
以前、彼は私のコードを盗用し、後に謝罪文を掲載したが、SNSでは共有しなかった
本当に誠意ある謝罪なら、フォロワーにも公開すべきだと思う
最初の3つの教訓が特に刺さった
教育課程で言語やフレームワークばかり学び、問題そのものを学ばないのが問題だ
合意は創造的なプロセスの中で積み上がり、権力は危機のときに使うべきだ
失敗を恐れて議論ばかりし、時間を無駄にすることが多い
「Boring Technology」のエッセイで「イノベーショントークン」という概念を初めて知った
boringtechnology.club の記事だが、今でも私が最も気に入っているアーキテクチャ関連の文章のひとつだ
「抽象化は複雑さを取り除くのではなく、単に自分がオンコールのときへ移すだけだ」という言葉は、Joel Spolskyの Law of Leaky Abstractions を思い出させる
リーダーシップ職を15年務め、大手小売企業で数十億ドル規模のシステムを運用してきた
だが結局重要だったのは政治と人間関係だった
もっと賢い人たちでも、政治ができず昇進できない
子どもたちに「政治とごますりを学べ」と教えなければならないという苦い結論だ
「Clarity is seniority」という言葉に深く共感した
明確さが保守性と拡張性の鍵だ
私はそれを教える本 Elements of Code を書いた
抽象化が悪いのではなく、問題は目的の明確さだ
地形を見ずに倉庫の中で橋を架ける土木技師のようなものだ
抽象化そのものを責めるのではなく、何をモデリングしようとしているのかを理解しなければならない
間違った抽象化はむしろ明確さを損ない、不要な複雑性を生む
むしろ抽象化が足りないほうがましだと思う
こうしたリストの本当の価値は自分で書いてみることにある
読むだけではすぐ忘れてしまい、自分のキャリアを振り返って整理してこそ意味が生まれる
この記事はGoogleの公式な価値観ではなく、Googleで働きながら学んだ個人的な教訓だ
組織が教えたのではなく、経験の中で自分で気づいたことだ
大企業でもなお難しい部分だという点が重要だ
「規模が大きくなるとバグにもユーザーがつく」というのは、ossification（硬直化）現象に近い
ネットワークプロトコルだけでなく、あらゆるシステムに当てはまる
HTTP/3とQUICの暗号化設計の理由も、中間装置が誤った前提を置けないようにするためだ
APIも同様に内部状態を露出すべきではない
「Bias towards action」という一文が印象的だった
どれほど良い助言でも、空白のページには役に立たない
まず何かを作らなければ、フィードバックは得られない
最初の1文字を入力した瞬間、予想していなかった問題が見えてくる
巨大な組織ほど、こうした見えないボトルネックが多い
「Ship fast」は「雑に出せ」という意味ではない
完成度の高い最小機能製品のほうがむしろ良いと思う
現実と理想のあいだのギャップは大きく、書き手は「Kool Aidはうまかった」と皮肉っていた
そうでないと「手抜き」だと誤解され、問題が起きたときにスケープゴートにされる
良い文章ですね。キャリアの成長には人格的な成熟も含まれるという考え方を、あらためて思い出す機会になりました。興味深く読ませていただきました。
まったくその通りのことばかりですね
1つ目からとても重要な教訓ですね。
最近、身にしみて感じています（笑）
良い内容が本当に多く、洞察に満ちた文章が多くて感嘆しました。主要な文を太字で表記してくれていたのも、さらに良かったです。
"正しさという短期的な感覚は、喜んで協力してくれる同僚たちと一緒に何かを築くという長期的な現実より、はるかに価値が低い。"
"戦略的な集中を行うべきであり、変えられないものに使うエネルギーは、変えられるものから奪ってくるエネルギーである。"
仕事だけでなく、人生にも応用しやすい内容がたくさんありました。良い文章をありがとうございます。
"コードは、障害発生時の午前2時に保守対応する見知らぬ人たちのための戦略メモなので、理解しやすさを最適化できるべきだ。"
"推進力が明確さを生み、分析麻痺は何も生み出さない。"