/note/tech

「Googleでの14年間で学んだ21の教訓」を 個人的な解釈でまとめてみた

要約:

■ 1. 記事の概要

  • Googleで14年間Chromeに携わり現在はGoogle Cloud AIでディレクターを務めるAddy Osmani氏が経験から学んだ教訓をまとめたブログの解説
  • 技術的なTipsではなくエンジニアとして無理せず長く続けていくための実践的な知恵が詰まっている
  • 原文は「21 Lessons From 14 Years at Google」

■ 2. 21の教訓

  • 教訓1: 技術ではなく「ユーザーの困りごと」から始める
    • 「この技術どこで使おう?」ではなく「ユーザーは何に困ってる?」から考える
    • 問題を本当に理解しているエンジニアは解決策が予想よりシンプルであることに気づく
  • 教訓2: 正論で勝っても意味がない
    • 議論に勝ってもチームの協力が得られなければプロジェクトは進まない
    • 「強い意見を弱く持つ」— 不確実な状況での決定を自分のアイデンティティにすべきではない
  • 教訓3: 考えすぎる前に手を動かす
    • 完璧な設計を考え続けて何も作らないより雑でもいいからまず作る
    • 「まず作る→直す→良くする」の順番
  • 教訓4: 「賢いコード」より「読みやすいコード」
    • 深夜の障害対応で読むのは未来の誰か
    • 明快さはスタイルの好みではなく運用リスクの低減
  • 教訓5: 新技術の導入は「借金」と同じ
    • 導入するたびに「学習コスト」「採用難」「トラブル時の情報不足」という借金を背負う
    • 独自に報酬を得ている場所でだけイノベーションしそれ以外は退屈でいい
  • 教訓6: 良い仕事も伝わらなければ存在しないのと同じ
    • 自分がいない場で誰もあなたの成果を説明できないならその成果は実質オプション
    • 自己宣伝ではなく価値の連鎖を「読める」ようにしておくこと
  • 教訓7: 最高のコードは「書かなかったコード」
    • 書いたコードは全部将来のバグ/保守/説明の対象になる
    • 問題は書くのが上手すぎて書くべきかどうかを問うのを忘れること
  • 教訓8: 大規模になるとバグにもユーザーがつく
    • ユーザーが増えるとバグや癖を前提にした使い方をする人が出てくる
    • 互換性作業を「メンテナンス」新機能を「本当の仕事」として扱うことはできない
  • 教訓9: 遅いチームは実は「ズレてる」チーム
    • 本当の原因は方向性や優先順位がチーム内で揃っていないこと
    • シニアの仕事は「速く書く」より「認識を揃える」こと
  • 教訓10: 変えられないことは気にしない
    • 自分がコントロールできることだけに集中する
    • 受動的な受容ではなく戦略的なフォーカス
  • 教訓11: 抽象化は複雑さを「後回し」にしているだけ
    • 便利なライブラリやフレームワークは「中身を知らなくていい」という賭け
    • シニアエンジニアはスタックが高くなっても「低レベル」のことを学び続ける
  • 教訓12: 教えると自分の理解が深まる
    • 人に説明しようとすると自分が曖昧に理解していた部分が見つかる
    • アウトプットは最高のインプット
  • 教訓13: 「縁の下の仕事」は大事だが見えないと評価されない
    • ドキュメント整備/新人教育/チーム間の調整は不可欠だがただの「お人好し」で終わりやすい
    • 性格特性ではなくインパクトとして可視化する
  • 教訓14: 議論で全勝してるなら裏で反感を買っている
    • 相手は納得したのではなく諦めただけかもしれない
    • 正しいという短期的な感覚は意欲的な協力者とものを作る長期的な現実よりはるかに価値が低い
  • 教訓15: 指標は「目標」にした瞬間意味を失う
    • 人は測定されるものを最適化する
    • スピードと品質両方の指標をセットで見ることが大事
  • 教訓16: 「わからない」と言えることがチームを安全にする
    • シニアが知ったかぶりをすると若手は質問できなくなる
    • 最もシニアな人が混乱を認めないチームでは質問は出ない
  • 教訓17: 人脈はどの仕事よりも長く続く
    • 関係を築いた人は何年後かに機会を運んでくれる
    • 打算ではなく好奇心と誠実さで人と繋がる
  • 教訓18: 速くするには「やらないこと」を増やす
    • 一番効くのは「そもそもこの処理いる?」と削ること
    • 最適化する前にその仕事がそもそも存在すべきかを問う
  • 教訓19: プロセスは「安心のため」ではなく「不確実性を減らすため」
    • 目的を説明できないプロセスは見直す
    • 最悪のプロセスは助けるためではなくうまくいかないときに責任を割り当てるために存在する
  • 教訓20: いつか「時間>お金」になる
    • 何を差し出しているか自覚して選ぶ
    • 時間は再生不可能な資源
  • 教訓21: 近道はない。でも「複利」はある
    • 一発逆転を狙うより毎日少しずつ学んで積み上げる方が強い
    • 学習は単なる新しい雑学ではなく新しい選択肢を生み出すときに複利になる

■ 3. まとめ

  • 21の教訓は3つに集約される:
    • 好奇心を持ち続ける — 学ぶことをやめない
    • 謙虚であり続ける — 「わからない」と言える/一緒に答えを探す
    • 人を忘れない — ユーザーのために作りチームと一緒に作る
  • 尊敬すべきエンジニアは常に正解を出した人ではなく失敗から学び気づきを周りと分かち合い諦めずに現場に立ち続けたエンジニア
  • 最終的には「どうすれば自分をすり減らさずにこの仕事を長く続けられるか」を教えてくれるもの