Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？

GoogleでGoogle CloudやGeminiに携わるソフトウェアエンジニアのアディ・オスマニ氏が、Googleで約14年間働く中で得た「21の教訓」を自身のブログで公開しました。オスマニ氏は当初「良いコードを書くことが仕事」だと思っていたものの、長く働くほど「活躍するエンジニアは必ずしも最高のプログラマーではない」「コードの周りにある人間関係・社内政治・認識合わせ・曖昧さを乗りこなせる人が伸びる」と実感したとのことです。

AddyOsmani.com - 21 Lessons From 14 Years at Google
https://addyosmani.com/blog/21-lessons/

◆1：ユーザーの問題に執着する
新しい技術に執着して使い道を探し始めるのは自然なことですが、価値を生む人は逆向きに考えるとのこと。「サポートチケットを読む・ユーザーに話を聞く・ユーザーがつまずく場面を見るといった行動で問題を掘り下げ、理解から解決策を生み出すべき」だとオスマニ氏は述べています。

◆2：正しさより合意形成
社内での技術的な議論に勝ち続けると表面上は勝っても「静かな反感」が積み上がり、開発に入った段階で抵抗として表れることがあるとのこと。オスマニ氏は「議論の目的は正しさよりも問題の認識合わせ・他人が話せる余地づくり・自分の確信への懐疑」だと述べています。

◆3：まず出す。白紙は直せない
「完璧主義でいくら議論を重ねても、現実に触れないと正解は出にくい」とオスマニ氏は指摘。「まず作る→正しくする→より良くする」の順で、最初は必要最低限の形でもいいのでユーザーに触れてもらい反応を見る方が学びが速いとしています。

◆4：コードは美しさより分かりやすさ
うまく書かれたコードは有能さの証明に見えますが運用においてはリスクになるとのこと。コードは深夜のトラブル対応で他人が読む「メモ」でもあるため、自分が思うコードの美しさよりも他人が理解しやすい書き方を優先すべきだとオスマニ氏は述べています。

◆5：新技術は「借金」
オスマニ氏は新しい技術を採用する判断を「イノベーションに使える枠」で捉え、標準から外れる選択をするたびにあとからコストを払う考え方を示しています。新技術の導入そのものを問題視しているわけではなく、導入するのであれば見返りが期待できる領域に限定し、それ以外は無難で実績のある選択を基本にすべきとのこと。

◆6：成果は「人」が伝える
大きな組織では自分が参加しない会議で要約だけを頼りに意思決定が進むことがあります。自分がいない場で成果を説明できる人がいないと影響力はおまけ程度のものになってしまうため、成果と価値がどうつながっているかを周囲に分かる形にする必要があるとのこと。

◆7：「書かない」のが最高のコード
「機能を追加するためにコードを足すよりも不要なコードを消す方がシステムを良くする場合があるものの、コードの削除は評価されにくい」とオスマニ氏は指摘。作る前に「何もしなかったらどうなるか？」を徹底的に考えるべきだとしています。

◆8：利用者が多いとバグも仕様になる
利用者が多くなると、本来思っていた挙動ではなくても「仕様」と化し、バグですらも他の要素と依存関係を構成することがあります。こうなってくると、互換性対応は「保守」にとどまらない「価値」となるので、機能の非推奨化は「移行」として設計すべきだとのこと。

◆9：遅さの原因は認識ズレ
遅延の原因を実行力や技術のせいにしがちですが、実際は「他の人との方向性・役割分担のつなぎ目・優先度の不一致が原因であることが多い」とオスマニ氏は指摘。経験のあるエンジニアほど「速くコードを書く」より「認識合わせ」に時間を使うのはそこがボトルネックだからだとしています。

◆10：自分の手の中に集中する
組織改編・方針転換などは自分の手の外にあるため悩み続けても不安が増えるだけになりやすいとのこと。「自分の影響範囲に集中し、不確実性は分解して今すぐ取れる行動を特定すべき」だとオスマニ氏は述べています。

◆11：便利さのツケはトラブル対応で払う
便利な仕組み(抽象化)は「下の仕組みを理解しなくて済む」という賭けだとオスマニ氏は指摘。普段は内部を意識しなくて済む一方で、障害や想定外の挙動が起きると抽象化で隠れていた複雑さが表に出てきて深夜に一人で原因を追う状況になりがちとのこと。そのため、便利な仕組みを使いこなしつつも下層でどう壊れうるかという失敗パターンの理解も持つべきだとしています。

◆12：書いて理解を固める
ドキュメントを書いたり発表したりレビューで説明したりAIに向かって整理して話したりする中で「うまく説明できない部分がまだ理解できていない部分」だとオスマニ氏は述べています。

◆13：誰かを支える仕事は可視化する
ドキュメントの整備・新人の立ち上げ支援・チーム間の調整などは重要ですが、無自覚に抱えると燃え尽きやすいとのこと。時間を区切る・持ち回りにする・成果物に変えるなどして可視化すべきだとしています。

◆14：議論で勝ち続ける裏には「抵抗の蓄積」がある
議論でいつでも勝つのは状況がなにかおかしい時で、多くの場合反論をしなくなるのは説得されたからではなく諦めたからだとオスマニ氏は指摘。この場合、異議は会議の中ではなく実行段階になってから噴き出すことになるため、時間をかけてフィードバックを取り入れ時には考えを変える必要があるとのこと。

◆15：指標は歪みやすい
オスマニ氏は見せた指標は最適化されやすいとし「コード行数や開発速度だけを追うと歪む」と指摘しています。速度の指標と品質やリスクの指標をセットにして数値の基準を絶対視せず推移で判断すべきとのこと。

◆16：「分からない」が安心を作る
経験のある人が不確実性を認めると周囲が質問しやすくなり前提も検証されます。逆に「分かったふり」の文化では問題が隠れ、爆発しやすいとのことです。

◆17：人脈は長期資産
オスマニ氏は「仕事だけに集中してネットワーク作りを怠るのは失敗だった」と振り返り、人との関係に投資した人はチャンスを早く得たり推薦されたりする恩恵を長期で受けると述べています。打算ではなく好奇心と寛大さで向き合うべきとのこと。

◆18：パフォーマンス向上の多くは「足すこと」より「減らすこと」で生まれる
システムのパフォーマンスが低下すると対策を追加したくなりますが、オスマニ氏は「そもそも計算しなくていい処理は何か？」を問う方が効く場合が多いと指摘。最速のコードは「実行されないコード」だと述べました。

◆19：工程は不確実性を減らすために存在する
オスマニ氏は「良い工程やルールは調整を楽にし失敗したときのコストを小さくする一方で、悪い工程やルールは責任追及のための形だけの作業になりがち」であり、リスク低減や明確化と結びつけて説明できない工程は負担でしかないと述べています。また、作業そのものよりも記録することに時間を費やしているのであれば「何かが根本的に間違っている」と指摘しています。

◆20：時間は最重要資源になる
キャリア初期は時間をお金に換えるのも自然なことですが、ある時点で時間が再生不能な資源だと実感するそうです。昇進や報酬のために燃え尽きる前に何と引き換えにしているかを理解し、意図的に選ぶべきだと述べています。

◆21：成長は積み重ね
専門性は意図的な練習の積み重ねであって近道はなく、学習は選択肢を増やす形で積み上がるとオスマニ氏は主張。「明確さのために書く」「再利用可能な部品を作る」「経験を手順書にまとめる」といった行動が長期で効いてくると述べています。

オスマニ氏は最後に「21の教訓は好奇心・謙虚さ・仕事の中心はユーザーとチームメイトに集約される」とまとめました。エンジニアのキャリアは失敗しても挽回できるほど長く、尊敬されるのは「すべてを正しくやった人」ではなく「うまくいかなかったことから学び、共有し、現場に戻り続けた人」だとしています。