ハクソク

世界を動かす技術を、日本語で。

Googleでの14年間からの教訓

141日前原文(addyosmani.com)

概要

Googleでの14年間の経験から得た、技術力以外でエンジニアが成長・活躍するための重要な教訓をまとめた内容。 技術選定やコードだけでなく、人間関係、組織運営、思考法がキャリアに大きな影響を与えることを強調。 ユーザー志向、チームの調整、行動優先、明確なコミュニケーションの重要性を解説。 失敗や曖昧さ、見えない貢献の扱い方についても具体的なアドバイスを提示。 個人の成長と組織の成果を両立させるための普遍的なパターンを体系的に紹介。

Googleで学んだエンジニアリングの本質的な教訓

  • 優秀なエンジニア は、単にコードを書くのではなく、 人間関係や組織の複雑さ を乗り越えるスキルを持つことが重要。
  • 技術的な知識やツール は変化しやすく、普遍的な価値は 行動パターンや思考法 にある。
  • 経験を通じて得た教訓 を共有し、次世代のエンジニアに役立てる意図。

1. ユーザー課題への執着

  • 最も価値を生むエンジニア は、技術よりも ユーザーの課題 を深く理解することに執着。
  • サポートチケットやユーザー観察を通じて 本質的な問題 を掘り下げる姿勢。
  • シンプルな解決策 は、問題の本質を理解したときに自然と現れる。

2. 「正しさ」より「共に正解へ」

  • 技術議論で勝つ ことより、 チームで合意形成 することの重要性。
  • 他者の意見を尊重し、確信に疑いを持つ 姿勢が長期的な成功を生む。

3. 行動優先・まずは動く

  • 完璧主義は停滞 の元。 まず動き、後で改善 することが成果につながる。
  • プロトタイプやMVP を早期にユーザーへ届け、現実から学ぶ重要性。

4. 明確さ＝シニア性

  • 巧妙なコード よりも、 明確で分かりやすいコード が組織的なリスクを減らす。
  • 他人が保守しやすい設計 を常に意識。

5. 新規性のコスト意識

  • イノベーションは限定的に。標準から外れる技術選定は 運用負荷や障害 のリスクを伴う。
  • 「退屈な技術」 の方が予測可能で安定。

6. コードは自己主張しない

  • 成果を認知してもらうには、人の推薦や説明 が不可欠。
  • 自分の価値を他者に伝える工夫 がキャリアを左右。

7. 書かないコードが最良

  • 不要なコードを追加しない勇気。削除や未実装がシステム改善につながる場合も多い。

8. バグも依存関係になる

  • 大規模サービスでは、バグや挙動もユーザーに依存される 現実。
  • 互換性維持や廃止設計 の重要性。

9. 遅いチームの本質は「不一致」

  • 実行力不足よりも、方向性や優先度の不一致 が進捗を妨げる主因。
  • シニアエンジニアは調整や優先順位付け に多くの時間を割く。

10. コントロールできることに集中

  • 組織変化や外部要因は制御不能。自分の行動や学びに集中することが効果的。

11. 抽象化は複雑さを移動させる

  • 抽象化の裏側を理解 し続ける姿勢。障害発生時に基盤知識が活きる。

12. 書くことで理解が深まる

  • 他者に説明・文書化することで、自分の理解の浅さ に気づける。
  • 教えることは自己学習の最短ルート。

13. 見えない貢献（Glue work）の可視化

  • ドキュメント作成や調整業務 は不可欠だが、 意図的・限定的に実施し、成果として残す ことが重要。

14. 議論で全勝＝サイレント抵抗の蓄積

  • 簡単に勝ちすぎる議論は要注意。本当の合意には時間と歩み寄りが必要。

15. 指標は目標化した瞬間に無効化

  • 測定指標は必ず操作される。速度と品質・リスクの両面でトレンドを重視。

16. 「知らない」と言える安全な文化

  • シニアほど「分からない」と言える強さ がチームの心理的安全性を高める。

17. ネットワークはキャリアを超える

  • 人脈構築の重要性。信頼関係が新たなチャンスや成長を生む。

18. パフォーマンス向上は「不要な作業の削除」から

  • 賢い最適化より、不要な処理をやめる ことが最速の改善策。

19. プロセスは不確実性削減のため

  • 書類作成や形式的な手続き ではなく、 協調や失敗コスト削減 が本来の目的。

（続きや新たな論点が必要な場合は、次のセクションで展開できます）

Hackerたちの意見

すべてのエンジニアはこれを読むべきだよ。ちょっとありふれてるように見えるけど、実は本当に真実なヒューリスティックの素晴らしいコレクションなんだ。特に目を引くのは、

「新しさは停電や採用、認知的オーバーヘッドで返済する借金だ。」 と 「抽象化は複雑さを取り除くわけじゃない。呼び出し当番の日に移すだけだ。」 っていう警告だね。あまりにも賢くなりすぎないようにってことだ。

└

同意だね。エンジニアだけじゃなくて、デザイナーやPMを含む製品作りに関わるすべての人に読んでほしい。ここにある一つ一つのポイントは金の価値があるよ。

└

新しい言語や技術スタックが提供する利点が、10年の経験で得た知識を上回ることはほとんどないよ。馴染みのある環境が本番でどう動くかを観察してきたから、未知の未知の領域がほぼゼロに近づいてる。

└

うーん、確かに。でも同時に、他の誰かの言うことを読んでも学びは得られないよね。経験から学ぶもので、みんなそれぞれ違うし。例えば「Googleで14年働いた」エンジニアがキャリアアドバイスをする専門家になるわけじゃないけど、そう書きたがる人が多いよね。こういう記事は、知識のある人からの心のこもったアドバイスというより、自己中心的な人たちのプロモーションみたいに感じる。著者の「バイオ」ページも、三人称で書かれていて、自分の業績を誇張した主張や、有名人との写真がいっぱい。こういう人たちの言うことはほとんど無視するようにしてる。もしこれがビッグテックで成功する人たちのタイプなら、そこは本当に耐え難い場所だろうね。

かなり洞察に満ちてるね。特にこれが印象的だった：

「行動に偏ること。出荷せよ。悪いページは編集できるが、白紙のページは編集できない。」 自分も似たようなことを言ってて、白紙のページを良くするためにどんなに良いアドバイスをもらっても無駄だって。まずは何かを発表しないと、アドバイスの恩恵を受けられないよね。

└

チーム全体がそれを信じているならいいけど、メンバーが違う考え方を持っていると、半端だとかハッキングっぽいって見られちゃう。もし悪いフィードバックがあったら、「ほら、言った通りだ」って言われて、責任を押し付けられることになるよ。

└

あれも好きだけど、別の理由があるんだ。ページに最初の文字を入力すると、自分が知らなかった問題が明らかになるんだよね。キーボードがない。あるけど、接続されてなくて、USBポートに届くために予想外に重い本棚を動かさなきゃいけない。Dvorakを学ばなきゃいけない。ページ作成の権限がなくて、解決に1週間かかるチケットを開かなきゃいけない。ページは作れるけど、他の人はそのページを読むことができない。なぜなら、彼らのマシンにはあなたのページが必要とするPageReader™プラグインのバージョンをインストールすることが許可されてないから（そして、彼らのバージョンにダウングレードするにはVPの例外が必要）。などなど。これらはすべて、開発（とデプロイ！）サイクルを一回終えないと明らかにならない静かなスケジュールキラーなんだ。これらの問題は馬鹿げているように見えるけど、Googleのような大きくて複雑な場所では現実から遠くないよ。

└

グーグルがもうちょっと品質とパフォーマンスに偏ってくれたらいいのに。ユーザー向けの製品は、ちょっと不安定なところが多いけど、Gmailはまあまあ良いかな。一般的に「早く出して壊れたものを直す」って考え方は、壊れたソフトウェアを出さない選択肢がないかのような誤ったジレンマを前提にしてると思う。こんな考え方じゃ、ソフトウェアがダメになるのも無理ないよね。チームには、追加機能を遅らせたり、ビジョンの制約されたバージョンを出すことになっても、ちゃんと動く、正しい、パフォーマンスの良いソフトウェアを出してほしいな。ソフトウェアのミニマリズムは、結局半端な機能で詰め込むよりも、プラスになると思うし。

「新しさは停電や採用、認知的オーバーヘッドで返済する借金だ」というアイデアを最初に知ったのは、これがきっかけで、今でもお気に入りのソフトウェアアーキテクチャに関するエッセイの一つだよ： https://boringtechnology.club/ それと、「抽象化は複雑さを取り除くわけじゃない。呼び出し当番の日に移すだけだ。」ってのは、ジョエル・スポルスキーの23年前の名作「漏れた抽象化の法則」を思い出させるね： https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

スケールが大きくなると、あなたのバグにもユーザーがいる。 大学卒業後に最初に働いた会社では、新入社員向けの大きな研修セミナーがあったんだ。ある日、彼らが負荷時間を5分から30秒に改善した話を聞かされた。これは90年代中頃の話だよ。クライアントからのネガティブな反応は即座に来た。負荷時間の改善が、彼らの会社文化を壊してしまったんだ。みんながオフィスに来て、コンピューターを立ち上げて、次の10分間おしゃべりしながらコーヒーを飲む代わりに、ソフトウェアは立ち上がる前に準備ができてしまった！この話の教訓、つまり引用のポイントは、改善をしないべきだということじゃない。むしろ、あなたが作っているソフトウェアはPRDやテストスイートの中に存在するわけじゃないってことを思い出させるんだ。それは、実際に世界で人々が触れるシステムなんだ。習慣が形成され、回避策が開発され、バグは実際のユースケースに合わせて学ばれていく。だからこそ、あなた、ソフトウェアエンジニアは、自分のソフトウェアの目的と現実の使用法を理解することがめちゃくちゃ重要なんだ。あなたの仕事は、プロダクトマネージャーからのリストにある要望を満たすチケットを完了することじゃない。ユーザーの問題を解決するソフトウェアを作ることがあなたの仕事だよ。

└

ほぼ10年、私のビジネスは当時の主要ブラウザであるMicrosoftとNetscapeの共通のバグに関わっていた。毎回のリリースで「今回は直してくれるだろう」と思ってたけど、それが本当に頭痛のタネになってた。でも、結局直らなかったんだよね！

└

じゃあ、その特定の問題に対する正しい解決策は、顧客ごとに読み込み時間を調整することなの？

└

https://xkcd.com/1172/

└

ハイラムの法則についてはよく話題になってたね。これもグーグルの人から来たものだし。 https://www.hyrumslaw.com/ > 「APIのユーザーが十分にいる場合、契約で何を約束しても関係ない。システムのすべての観察可能な挙動は、誰かに依存されることになる。」

└

一番クレイジーだったのは、ユーザーが「ノートパソコンが熱くなりすぎてうるさい」と文句を言ってきたことかな。正しくタスクを並列化したら、効率が良くなりすぎちゃって。スピードは好きだけど、ファンがフルスピードで回って、CPU（つまりノートパソコン全体）がすごく熱くなっちゃった（2010年頃の話）。だから、ファンが「ブーン」ってならないように、処理をちょっと遅くしなきゃいけなかったんだよね。

└

それは https://xkcd.com/1172/

この一文をメモしておくよ：

「もしすべての議論に勝っているなら、あなたはおそらく静かな抵抗を蓄積している。」

└

あれはちょっと不安になるな、良くないサインだ…

これらのほとんどには同意するけど、こういうリストの一番の価値は、実際に書き出すことだと思う。キャリアのいろんな側面を振り返って、まとめる必要があるんだよね。読むだけじゃほとんど意味がない。ニュースがいっぱい載ってるページをざっと見るようなもので、日常の仕事を始めると全部忘れちゃう。やっぱり、自分でそういうリストを作ってみるのが一番のアドバイスかな。

スケールが大きくなると、あなたのバグにもユーザーがいる これは「硬直化」とも呼ばれる。ネットワークプロトコルの文脈でよく聞く言葉だけど、ユーザーが未定義の動作やバグに依存するすべてのシステムに一般的に当てはまる。HTTP/3やQUICについて読むのは、その点で興味深い。最初は暗号化にこだわる理由が分からなかったけど、単なるセキュリティやプライバシーだけじゃなくて、必要なもの以外を全部暗号化することで、「ミドルボックス」がすべきでない仮定をすることが不可能になるんだ。APIでも似たようなアプローチが使えると思う。指定された以上のものは露出させないようにして、内部状態にアクセスできる能力はバグとして扱うべきだよ。秘密だからじゃなくて、ユーザーがそれに依存し始めると、内部の変更が何も壊さないはずなのに壊れちゃうから。

  1. 明確さはシニアリティである。賢さはオーバーヘッドである。明確さは、メンテナブルで拡張可能なコードを作る上で最も重要な要素だと思う。もちろん、言うのは簡単だけど、実際にどう見えるかを説明するのは難しいよね。明確なコードを書く方法を教える本を書いたよ。 https://elementsofcode.io > 11. 抽象化は複雑さを取り除くわけではない。それは、オンコールの日に移動するだけだ。これは悪い抽象化に当てはまる。 > 抽象化の目的は曖昧になることではなく、絶対的に正確である新しい意味レベルを作ることだ。（ダイクストラ）抽象化をその観点で考えると、その有用性が明らかになる。CPU命令をプログラミング言語に抽象化することで、データ構造や関数のように、より正確な用語で問題を考えることができる。言語自体の上にさらに高い精度の抽象化を作るのは明らかに有用だ。問題は抽象化ではなく、目的の明確さだ。私たちはしばしば、モデル化しようとしている挙動を理解する前に、複雑な行動モデルを作ってしまう。まるで土木技師が、設置すべき地形を調べずに倉庫で橋を作ろうとしているようなものだ。うまくフィットしないとき、橋の概念を責めることはないよね。

「すべての議論に勝つと、たぶん静かな抵抗を蓄積している。」これは私生活でも本当にそうだよね。

グーグルに入る前にこれを読んでおけばよかったな。