私の経験では、これがよくあることだとは思わないな。複雑な解決策を提案するのは、経験の浅い若手エンジニアが多いし、逆に経験豊富なエンジニアはシンプルさを重視することが多いんだ。彼らは複雑さに苦しんできたからこそ、シンプルさの価値を理解しているし、問題を明確にして、最もシンプルな解決策にたどり着くための経験もある。こういう意見を言うのは簡単だけど、表面的には良さそうに聞こえるだけで、実際には検証に耐えない気がする。これが本当にトレンドなのか、証拠や研究を見てみたいな。

私はAmazonの小売プラットフォームで、9桁の収益を生む技術的な機能を立ち上げたことがある。立ち上げた時はインフラが全くなかったんだ。各コアプラットフォーム（詳細ページ、カート、チェックアウトなど）に小さな変更を加えただけ。最初は「まあ、大したことしてないね」って言われたけど、価値を見たら状況が一変した。人を引き込むためにはちょっとしたマーケティングが必要なんだよね。残念ながら、しばしば見える影響は複雑さと相関している。

いい記事だね。私が思う反論としては、有名なビル・アトキンソンの-2000行のコードの話がある。建築家として、ミニマリストなプロジェクトに特別な愛着を持っていた。建物は複雑な問題空間なんだ。不要な複雑さを完全に排除することは通常できない。だから、目標（完成形）からインフラ（建物の構造）に遡って、最終製品をほとんど何もないように見せる方法を考えなきゃならない（ミースの「beinahe nichts」）。この記事が言うように「複雑さは印象的だ」が、目の肥えた人はシンプルさの方がさらに印象的だと理解している。これで、フレッド・ブルックスの「ノー・シルバー・ブレット」と、必須の複雑さと偶発的な複雑さの考え方に思いを馳せる。もう少しニュアンスを加えて考えると、「偶発的」ではなく、少なくとも「偶然的」だと思う。

これは単なる事実じゃないよ。人は影響を与えたことで昇進するんだから、解決策が複雑でもシンプルでも関係ない。私が知っている最高のエンジニアは、大きな会社で巨大な複雑なシステムを扱える人で、通常は複雑な解決策から始めて、達成したいことを理解した後に、既存の複雑なシステムの中で最小限のコード変更で再実装するんだ。

これには共感するなぁ。「シンプルさ」って、欠けてるときにしか気づかないもので、ほとんどの組織は「起こらなかったこと」に対して報酬を与える良い方法がないんだよね。このダイナミクスは何度も見てきた。ある人がつまらない実装を出して、何も壊れず、みんなそのまま進む。一方で、別の人が「プラットフォーム」バージョンを出すと、ドキュメントや図、社内のプレゼンがあって… そしたら新入社員に説明しなきゃいけないサブシステムができちゃう。どっちが「インパクト」として見えるかは明らかだよね。あまり話題にならないと思うのは、複雑さには持ち運びコストがあって、それがビルダーに請求されることはほとんどないってこと。チームが後でそのコストを払うことになる：表面積が増え、失敗の可能性が増え、変更する前に読む時間が増える。そういう意味では、得られない複雑さはレバレッジを持つことに似てる。時にはそれが正しい選択だけど、ただの熱意じゃなくてビジネスケースが必要だよね。私が好きなチームで役立ったのは、「シンプルさ」を意思決定の記録として明確にすること。PRやADRで、取らなかった「クールな」選択肢を明示的にリストアップして、その理由を書いて、後でアップグレードするためのトリガー条件も書くんだ（「p95がY日間Xを超えたら」とか、「2番目のプロデューサーを追加したら」とか）。これで「実装された機能X」が「意図的なトレードオフを行い、リスクを減らし、明確な逃げ道を定義した」ってなる。そうすると、「未来を見越した」みたいな雰囲気じゃなくて、具体的に議論することが強制されるんだよね。それと、面接のポイントにも賛成。多くのシステムデザインの面接は、面接官がうなずくまでボックスを増やすことが目標だと無意識に教えてる。もっと上級者の動きは、まずシンプルに始めて、計測して、閾値を設定してから機械を追加することなんだけど、45分でそれを「演じる」のは、カフカやシャーディングを並べるより難しいよね。組織がインセンティブを修正したいなら、レビューで聞くべき質問は「あなたが作ったものの大きさは？」じゃなくて、「次の四半期にシステムを変更しやすくしたか？」だと思う。それが積み重なるインパクトで、シンプルさと通常相関してるんだ。

これにはいくつかの理由があると思う。まず、シンプルなデザインは複雑なデザインよりも開発者に高い要求をする。ちょうどいいデザインを作るには、十分な経験とビジネスの深い理解が必要なんだ。そうじゃないと、何度も繰り返すうちにコードが膨れ上がってしまう。例えば、1つのファイルが2,000行を超えたり、1つの関数が500行を超えたりすることがある。次に、以前読んだ（正確な出典は思い出せないけど）言葉に強く同意する。「良いコードは最初から完璧に書かれるわけじゃない。それは継続的なリファクタリングを通じて形作られる。適切なタイミングでリファクタリングが必要だ。」でも、ほとんどの会社は新しい要件が次々と入ってくるから、リファクタリングのための時間を割いていない。こうした制約の中で、ほとんどの会社がエンジニアリングのトレードオフとして複雑なデザインを好むのは明らかだ。複雑なデザインのためのツールは色々あるけど、シンプルにするためのガイダンスはほとんどない。開発者がデザインが過剰設計かどうかを判断する基準や、ちょうどいいデザインとは何かを議論しているブログはあまり見かけない。そういう場合、デザインがある方が全くないよりはマシだよね。結局、多くの会社は本当にデザインなしで運営していて、既存のソリューションをコピーするだけなんだから。

安定したコードとバグの多いコードの違いも見てきた。Aさんはただ動くコードを書いて、誰もそれを聞かないから、その開発者は背景に消えてしまうことがある。Bさんはたくさんのミスをして、問題を修正してヒーローになろうとするけど、みんなその問題を引き起こしたのを忘れてしまう。昇進の時が来ると、Bさんは週末に自分のコードを修正してヒーローになったから、みんなの記憶に新しい。彼らは出荷された機能や運用作業のクレジットを取れる。一方、Aさんは見落とされて、ただしっかりしたコードを出荷して、ぐっすり眠れたって感じ。

何百ものインターフェースを見かけるたびにこれを考える。全部が単一クラスの実装で。いつも返ってくる言い訳は「でも拡張可能だから」なんだけど、アプリケーションにConfigurationSingletonの実装が何個必要なの？クラスを入れて、後でインターフェースが必要になったら、2つ目のクラスができたときにリファクタリングツールで簡単に作れるよ（99%の確率でそんなことは起こらないけど）。これが、AIがボイラープレートに最適だと言われると心配になる理由だ。彼らが「よく設計されていて拡張可能であるべき」とAGENTS.mdに書いてしまったせいで、こんなボイラープレートを作るんじゃないかと心配してる。

シンプルさで昇進したことが何度かある。「なんでネットワーク共有でXbaseファイルを複数のユーザーが同時に更新できるようにするために、こんなに手間をかけてるの？あ、PostgreSQLを紹介してもいい？」とか、「聞いて、10Mの同一GETリクエストを処理するためにウェブサーバーの艦隊を展開する代わりに、数台のサーバーをVarnishキャッシュの後ろに置いて1秒の有効期限を設定したらどう？」とか、「待って、このシステムは1日3000リクエストを処理するように設計されてて、週に20時間のダウンタイムが許容されてるの？Kubernetesはクールだけど、単一のVPSを立ち上げてその上で全スタックを運用しようよ。」開発チームを崖から引き戻すのは微妙な技術だけど、時にはシンプルな道が全ての面で良いこともある。それを見極めることができるのは貴重だし、もちろん、最もシンプルで合理的なバージョンがまだかなり複雑であることを理解し、それに合わせて進むことも同じくらい重要だ。

シンプルさで昇進することは確かだよ、もしそれが現実世界で具体的な形で反映されるならね。他の人たちが複雑すぎる解決策を持っていて、問題を引き起こすことが多いと、上司や同僚は技術的な細部まで理解できないこともあるけど、彼らはバカじゃないからパターンに気づくことができる。すべてのケースで公平な評価はないかもしれないけど、平均的にはそうなる。仕事がしやすい人が昇進するし、それはシンプルな解決策を作ることから派生している。