出来事の日付：2026年1月4日。

Googleのエンジニア、アディ・オスマニは、同社での約14年間を節目にキャリアを振り返り、特定の技術よりも、エンジニアリングを成功させるための周辺条件に焦点を当てた。その中心的な主張は、プログラミング能力は重要だが、長期的に成果を上げるには、ユーザーを理解し、人々の足並みをそろえ、影響を伝え、不確実性を管理することも必要だというものだ。

オスマニはエンジニアに対し、好みのツールではなく、ユーザーの問題から始めるよう助言している。解決策を選ぶ前に、サポート依頼を調査し、ユーザーと話し、どこで苦労しているかを観察することを勧める。技術を起点にすると、正当化の理由を後から探すような、不必要に複雑なものを作り出しかねない一方、問題を深く理解すれば、より単純な答えが明らかになることがあると論じている。

同じ慎重さは技術的な議論にも当てはまる。オスマニは、エンジニアが議論には勝っても、反感を生んだり、同僚が納得しないままになったりすることで、プロジェクトを損なう可能性があると書いている。彼は、問題について認識を合わせるために議論へ臨み、他者に発言の余地を与え、証拠が変われば変更できるだけの柔軟性を保って決定を扱うことを好む。曖昧さのある仕事では、大まかな試作版や初期の実用最小限の製品から得られる勢いの方が、理想的なアーキテクチャをめぐる長時間の議論よりも明確さをもたらし得る。

明快さは、コードに対する彼の姿勢も導いている。巧妙な実装は技量を示せるかもしれないが、ソフトウェアは長期間使われ続け、障害発生時に対応する人々を含む他の保守担当者へ引き継がれる。そのためオスマニは、読みやすいコードを運用リスクの低減として捉えている。標準的でない技術の採用は、限られた数の「イノベーション・トークン」を消費することだと考え、目立った価値を生む領域のために新規性を温存し、それ以外では使い慣れたツールを受け入れるよう提案している。

いくつかの教訓は、組織が過小評価する仕事に関するものだ。オスマニは、人員配置やプロジェクトに関する決定が行われる会議ではコードが自らを説明してくれるわけではないため、影響を分かりやすく示さなければならないと述べる。彼はそうした可視性を、中身のない自己宣伝と区別している。また、何もしなくてもユーザーに害を与えず保守を回避できる場合には、コードを削除する、あるいは書くことを断るべきだとも主張している。

彼の説明では、互換性はプロダクト業務としての地位に値する。十分な数のユーザーが観察可能な挙動に依存するようになれば、文書化されていない癖でさえ重要になり得る。したがって、非推奨化は単なる後始末として扱うのではなく、時間、ツール、共感を伴う移行として設計すべきだ。

進捗の遅いプロジェクトについて、オスマニは個人の努力や技術よりも、認識の一致を原因として挙げることが多い。チームを増やせば調整コストが上がるため、シニアエンジニアはコーディング速度を上げるよりも、優先順位やインターフェースを明確にすることで、より大きな効果を生み出せる可能性がある。彼はこの一連の助言を、主体性に焦点を当てて締めくくっている。組織の変化や市場の変動はエンジニアの制御外かもしれないが、対応、学習、仕事の質はそうではない。これらの教訓は、シニアエンジニアリングを、コードそのものを生産するのと同じくらい、コードをめぐる判断を実践する仕事として描いている。