エンジニアリングにおける良いセンスは実力とは別の概念である [翻訳記事]

ソフトウェアエンジニアリングにおける「良いセンス」は、特定の技術スタックの好みではなく、与えられたプロジェクトの状況に最も合ったエンジニアリング上の価値を柔軟に選ぶ能力だ、という話。

センスは実力とは別の概念

• 技術的なセンスは料理の味の好みのように、実力とは独立した感覚であり、コードを実際にうまく書けなくても「このコードは見やすい／好きではない」「この設計判断は気に入る／微妙だ」を見分ける能力として表れる概念である。
• for ループ vs map/filter のような選択は、絶対的な技術的優劣ではなく、それぞれがより重要だと考える価値（可読性、単純さ、性能など）によって分かれるセンスの違いにすぎず、エンジニアは結局、自分が重視する価値のセットを基準に判断することになる。

エンジニアリングのセンス = 価値の優先順位

• ソフトウェアエンジニアリングにおける意思決定の大半は、性能・可読性・正確性・柔軟性・拡張性・復元性・移植性・開発速度といった価値のあいだのトレードオフの問題であり、常にどちらか一方が絶対的に正しい選択になることはまれである。
• あるエンジニアのセンスは、これらの価値のうち何をどれだけ優先するかによって定義され、たとえば速度と正確性を開発速度より重視すれば Rust や特定のクラウドに手が伸び、復元性を速度より重視すればマルチリージョン分散のような選択を自然に取るようになる。

悪いセンス: 柔軟性のない「ベストプラクティス」崇拝

• 悪いセンスとは、その人が好む価値が現在のプロジェクトに合っていないにもかかわらず、過去にうまくいったと信じている方法論（形式検証、特定言語への書き直し、過剰なマルチリージョン、複雑なメタプログラミングなど）を文脈に関係なく押し通す態度として現れる。
• こうした人たちは「これはベストプラクティスだから」といった絶対的な基準に頼って選択を正当化し、特殊な状況ではうまく機能しても、文脈が変わるとコンパスが狂うようにチームを誤った方向へ導く問題を生む、という比喩が使える。

良いセンス: 文脈に合った価値選択と柔軟性

• 良いセンスとは、特定の問題と組織・ビジネス上の制約の中で、どの価値を前面に出し、どれを犠牲にするかを適切に選ぶ能力であるため、単純な質疑応答や理論テストでは測定しにくく、実際のプロジェクトの設計や結果の中でのみ表れる。
• 自分が同意した設計が入ったプロジェクトがうまく進み、同意していなかった選択が入ったプロジェクトが苦労するというパターンを、複数のプロジェクトで繰り返し観察して初めて、「自分のセンスはこの文脈では合っていた／外れていた」と検証できる。

良いセンスを育てる方法

• 良いセンスは、単一の正解や教科書から得られるものではなく、さまざまなタイプのプロジェクトを経験しながら、「どこがスムーズで、どこで苦労したのか」「どの価値判断が後になって足かせになったのか」を継続的に意識して振り返る過程の中で、少しずつ積み上がっていくという主張である。
• 核心は柔軟性であり、特定の言語・パターン・アーキテクチャを絶対的なルールのように扱わず、新しいドメインや同僚のセンスにも開かれた姿勢で、さまざまな視点や言語を試しながら自分の基本的なセンスを更新し続ける態度が重要だと強調している。