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

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

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

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

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