はじめに
Googleで長年 Chrome に携わり、現在は Google Cloud AI でディレクターを務める Addy Osmani（アディ・オスマニ）氏が、14年間の経験から学んだ教訓をまとめた 『21 Lessons From 14 Years at Google』 がとても面白かったので、個人的な解釈を交えながらまとめてみました。
オスマニ氏は、O'Reilly などで多数の技術書を執筆していることでも知られ、長年にわたり Web 開発コミュニティに貢献してきたエンジニアです。
これらを共有するのは、同じように経験を分けてくれたエンジニアたちから、私自身が計り知れないほどの恩恵を受けてきたからです。これは、その恩を次へとつないでいくための、私なりの試みだと思ってください。
そんな想いで書かれたこのブログには、技術的な Tips ではなく、エンジニアとして無理せず長く続けていくための、実践的な知恵 が詰まっていると感じました。
この記事は翻訳ではなく、原文を読んで私なりに解釈・整理したものです。
感じ取ったことを日本の現場感覚で言葉にしている（自分の言葉で咀嚼した）部分もあるため、原文の空気を味わいたい方はぜひ元記事も読んでみてください。既に日本語記事でも話題になっています。※意味の取り違えを防ぐため、要所ではChatGPTで原文のニュアンス等の確認を行っています。
1. 技術ではなく「ユーザーの困りごと」から始める
The best engineers are obsessed with solving user problems.
（最高のエンジニアはユーザーの問題を解決することに執着する）
新しい技術を覚えると使いたくなる。でも本当に価値を生むのは、「この技術どこで使おう？」ではなく 「ユーザーは何に困ってる？」から考えられる人。サポートに来る声やユーザーの行動をよく観察しよう。
問題を本当に理解しているエンジニアは、洗練された解決策が誰もが予想していたよりもシンプルであることに気づく。
2. 正論で勝っても意味がない
You can win every technical argument and lose the project.
（技術的な議論にすべて勝っても、プロジェクトに負けることがある）
議論に勝っても、チームの協力が得られなければプロジェクトは進まない。「自分が正しい」を証明するより、みんなで良い答えに辿り着くことを優先しよう。
「強い意見を、弱く持つ」— 確信がないからではなく、不確実な状況での決定を自分のアイデンティティにすべきではないから。
3. 考えすぎる前に手を動かす
You can edit a bad page, but you can't edit a blank one.
（悪いページは編集できるが、白紙は編集できない）
完璧な設計を考え続けて何も作らないより、雑でもいいからまず作る。フィードバックは頭の中の議論より100倍学びがある。「まず作る→直す→良くする」の順番で。
勢いは明確さを生む。分析麻痺は何も生まない。
4. 「賢いコード」より「読みやすいコード」
Your code is a strategy memo to strangers who will maintain it at 2am during an outage.
（あなたのコードは、障害中の午前2時にそれを保守する見知らぬ人への戦略メモだ）
トリッキーなコードは賢く見えるかもしれない。でもそれを深夜の障害対応で読むのは未来の誰か。その人が一瞬で理解できるコードこそプロの仕事。
ソフトウェアエンジニアリングとは「時間」と「他のプログラマー」を加えたときに起こること。明快さはスタイルの好みではなく、運用リスクの低減。
5. 新技術の導入は「借金」と同じ
The "best tool for the job" is often the "least-worst tool across many jobs."
（「最適なツール」は、しばしば「多くの仕事で最も悪くないツール」である）
最新技術はワクワクするが、導入するたびに「学習コスト」「採用難」「トラブル時の情報不足」という借金を背負う。本当に必要な場所だけに絞ろう。それ以外は枯れた技術で十分。
「イノベーションするな」ではない。「独自に報酬を得ている場所でだけイノベーションせよ」ということ。それ以外は退屈でいい。退屈には既知の失敗モードがあるから。
6. 良い仕事も、伝わらなければ存在しないのと同じ
If no one can articulate your impact when you're not in the room, your impact is effectively optional.
（あなたがいない場で誰もあなたの成果を説明できないなら、その成果は実質オプションだ）
「良いコードを書けば評価される」は幻想。あなたがいない会議で、誰かがあなたの価値を説明できなければ、評価対象にならない。自慢ではなく価値を見える形にしておくこと。
自己宣伝の話ではない。価値の連鎖を、自分を含めた全員に「読める」ようにしておくこと。
7. 最高のコードは「書かなかったコード」
Before you build, exhaust the question: "What would happen if we just… didn't?"
（作る前に「もしやらなかったら？」を徹底的に考えろ）
書いたコードは全部、将来のバグ・保守・説明の対象になる。作る前に 「本当に必要？」と問う習慣 をつけよう。
問題は、エンジニアがコードを書けないことじゃない。書くのが上手すぎて、書くべきかどうかを問うのを忘れること。
8. 大規模になると、バグにもユーザーがつく
At scale, even your bugs have users.
（規模が大きくなると、バグにさえユーザーがつく）
ユーザーが増えると、想定外の使い方をする人が必ず現れる。バグや癖を前提にした使い方をする人も出てくる。互換性の維持は立派なプロダクト開発。
互換性作業を「メンテナンス」、新機能を「本当の仕事」として扱うことはできない。互換性はプロダクトだ。ほとんどの「API設計」は実際には「API引退」である。
9. 遅いチームは、実は「ズレてる」チーム
Most slowness is actually alignment failure.
（ほとんどの遅さは、実際にはアラインメントの失敗だ）
プロジェクトが遅れると「人が足りない」「能力不足」と思いがち。でも本当の原因は 方向性や優先順位がチーム内で揃っていない こと。シニアの仕事は「速く書く」より「認識を揃える」こと。
シニアエンジニアは「コードをより速く書く」より、方向性・インターフェース・優先順位を明確にすることに多くの時間を費やす。そこに実際のボトルネックがあるから。
10. 変えられないことは気にしない
Energy spent on what you can't change is energy stolen from what you can.
（変えられないことに使うエネルギーは、変えられることから奪われている）
組織変更、上の判断、市場の変化…コントロールできないことは山ほどある。自分がコントロールできることだけに集中しよう。それが正気を保つ秘訣。
受動的な受容ではなく、戦略的なフォーカス。組織再編が起こるかはコントロールできない。仕事の質、どう対応するか、何を学ぶかはコントロールできる。
11. 抽象化は複雑さを「後回し」にしているだけ
Abstractions don't remove complexity. They move it to the day you're on call.
（抽象化は複雑さを除去しない。オンコールの日に移動させるだけだ）
便利なライブラリやフレームワークは「中身を知らなくていい」という賭け。でも何かは必ず漏れる。いざという時のために、下のレイヤーも理解しておこう。
シニアエンジニアはスタックが高くなっても「低レベル」のことを学び続ける。ノスタルジアからではなく、抽象化が失敗し午前3時にシステムと一人になる瞬間への敬意から。
12. 教えると、自分の理解が深まる
Teaching is debugging your own mental models.
（教えることは、自分のメンタルモデルをデバッグすること）
人に説明しようとすると、自分が曖昧に理解していた部分が見つかる。アウトプットは最高のインプット。ブログ、ドキュメント、何でもいいから説明してみよう。
何かを理解していると思うなら、それをシンプルに説明してみる。つまずく場所が、理解が浅い場所。
13. 「縁の下の仕事」は大事だが、見えないと評価されない
Priceless and invisible is a dangerous combination for your career.
（貴重で見えないのは、キャリアにとって危険な組み合わせだ）
ドキュメント整備、新人教育、チーム間の調整…これらは不可欠だが、ただの「お人好し」で終わりやすい。成果物として残し、インパクトを可視化しないとキャリアに響く。
タイムボックスする。ローテーションする。ドキュメント・テンプレート・自動化という成果物に変える。性格特性ではなく、インパクトとして可視化する。
14. 議論で全勝してるなら、裏で反感を買っている
People stop fighting you not because you've convinced them, but because they've given up trying.
（人が反論をやめるのは納得したからではなく、諦めたからだ）
いつも議論に勝っているなら要注意。相手は納得したのではなく、諦めただけかもしれない。不満は会議ではなく「仕事の進め方」で表れる。
正しいという短期的な感覚は、意欲的な協力者とものを作る長期的な現実よりも、はるかに価値が低い。
15. 指標は「目標」にした瞬間、意味を失う
If you track lines of code, you'll get more lines. If you track velocity, you'll get inflated estimates.
（コード行数を測ると行数が増える。ベロシティを測ると見積もりが膨らむ）
人は測定されるものを最適化する。1つの指標を追うと必ず歪む。スピードと品質、両方の指標をセットで見ることが大事。
すべてのメトリクス要求にはペアで応答する。1つはスピード用、1つは品質またはリスク用。閾値を崇拝するのではなく、トレンドを解釈する。目標は監視ではなく洞察。
16. 「わからない」と言えることが、チームを安全にする
When a leader admits uncertainty, it signals that the room is safe for others to do the same.
（リーダーが不確実性を認めると、他の人も同じことをしていいという信号になる）
シニアが知ったかぶりをすると、若手は質問できなくなる。「わからない」と言える空気を作る のがリーダーの仕事。
最もシニアな人が混乱を認めないチームを見てきた。質問は出ない。仮定は挑戦されない。ジュニアは他の全員が理解していると思い込んで黙っている。
17. 人脈は、どの仕事よりも長く続く
Your job isn't forever, but your network is.
（仕事は永遠ではないが、人脈は永遠だ）
仕事に集中してネットワーキングを怠ると、後で困る。関係を築いた人は、何年後かに機会を運んでくれる。打算ではなく、好奇心と誠実さで人と繋がろう。
関係に投資した同僚たちは、最初に機会を聞き、より速く橋を架け、役職に推薦され、何年もかけて信頼を築いた人々とベンチャーを共同創業した。
18. 速くするには「やらないこと」を増やす
The fastest code is code that never runs.
（最速のコードは、実行されないコードだ）
遅いシステムを速くしたいとき、「キャッシュを足す」「並列化する」と考えがち。でも一番効くのは 「そもそもこの処理いる？」と削ること。
不要な仕事を削除することは、必要な仕事をより速くすることよりも、ほぼ常にインパクトがある。最適化する前に、その仕事がそもそも存在すべきかを問え。
19. プロセスは「安心のため」ではなく「不確実性を減らすため」
If you can't explain how a process reduces risk or increases clarity, it's probably just overhead.
（そのプロセスがリスクを減らすか明確さを増すか説明できないなら、それはただのオーバーヘッドだ）
「念のため」で増えたルールや手続きは、気づくとチームを遅くする。目的を説明できないプロセスは見直そう。
最良のプロセスは調整を容易にし、失敗を安くする。最悪のプロセスは官僚的な劇場—助けるためではなく、うまくいかないときに責任を割り当てるために存在する。
20. いつか「時間＞お金」になる
Know what you're trading, and make the trade deliberately.
（何を交換しているか知り、意図的に交換せよ）
キャリア初期は時間をお金に換える。でもある時点で価値観が逆転する。昇進のために燃え尽きた先輩は「本当に価値があったか」と後悔していた。何を差し出しているか、自覚して選ぼう。
答えは「頑張るな」ではない。「何を交換しているかを知り、意図的に交換せよ」ということ。時間は再生不可能な資源。
21. 近道はない。でも「複利」はある
The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
（キャリアを宝くじではなく複利として扱うエンジニアは、最終的にはるかに先に行く）
一発逆転を狙うより、毎日少しずつ学んで積み上げる方が強い。書くこと、再利用できる仕組みを作ること、失敗から学ぶこと。地味だけど、これが複利で効いてくる。
学習は、単なる新しい雑学ではなく、新しい選択肢を生み出すときに複利になる。書く—エンゲージメントのためではなく、明確さのために。傷跡をプレイブックに集める。
まとめ
私がこのブログを読んで、特に大切だと感じたことをまとめます。
Stay curious, stay humble, and remember that the work is always about people.
（好奇心を持ち続け、謙虚であり続け、仕事は常に人のためにあることを忘れるな）
21の教訓は、結局この3つに集約される
- 好奇心を持ち続ける — 学ぶことをやめない
- 謙虚であり続ける — 「わからない」と言える、一緒に答えを探す
- 人を忘れない — ユーザーのために作り、チームと一緒に作る
The engineers I admire most aren't the ones who got everything right - they're the ones who learned from what went wrong, shared what they discovered, and kept showing up.
（私が本当に尊敬しているのは、常に正解を出した人ではなく、失敗から学び、気づきを周りと分かち合い、諦めずに現場に立ち続けたエンジニアたちです。）
この21の教訓には「こんな考え方もあったのか！」「確かにこれは大事だな」と、自分の働き方を見直したくなる気づきが、いくつもありました。
特に２番の「強い意見を、弱く持つ」はすごく新しい発想でした。
そして...最終的には 「どうすれば自分をすり減らさずに、この仕事を長く続けられるか」 を教えてくれるものだと感じました。
もちろん、すべてをそのまま受け入れる必要はなくて、今の自分に響いたものだけを拾い、自分のやり方に合わせて持ち帰れば良いと思っています。
引用
原文: 21 Lessons From 14 Years at Google - Addy Osmani
※ 本記事は原文の紹介・解説を目的としています。詳細はぜひ原文をご覧ください。
参考記事
こちらの日本語の記事がわかりやすいです。