シンプルさでは昇進できない

45日前原文(terriblesoftware.org)

概要

シンプルさは高い価値を持つが、評価されにくい現実
複雑さがエンジニアの評価や昇進で優遇される傾向
シンプルな解決策が目立たず埋もれてしまう問題
インセンティブ構造の見直しが必要
シンプルさを可視化し、正当に評価する方法の提案

シンプルさと複雑さの評価の歪み

Edsger Dijkstraの「シンプルさは美徳だが、評価されにくい」という指摘
エンジニアリング現場で複雑な設計や実装が評価されやすい構造
シンプルな実装は印象に残りにくく、昇進や評価で不利になりがち
複雑なシステムを作るエンジニアは**「スケーラブルな設計」などの実績**として評価されやすい
シンプルに解決した場合、「feature Xを実装」だけで終わり、評価材料が少ない
複雑さが賢く見えるという誤った印象が蔓延

面接・設計レビューにおける複雑さの偏重

システム設計面接でシンプルな解決策を出しても「スケーラビリティは？」などの質問で複雑な案を求められる
面接官や設計レビューで**「将来の拡張性」「将来的な問題」を理由に不要な抽象化やレイヤー追加**を要求されがち
結果として現実には不要な複雑さが増え、保守性や開発速度が落ちる

複雑さが必要な場合とそうでない場合

本当に複雑な問題（大規模トランザクション処理や多数チーム開発）には複雑な解決策が必要
問題がシンプルな場合、**複雑さは「未然の心配」や「見た目のプロフェッショナリズム」**でしかない
**「やらない決断」**も重要な技術的判断

シンプルさを評価するための具体策

自分の仕事を言語化する工夫
- 「feature Xを実装」ではなく、「複数案を検討し、要件を満たす最もシンプルな実装を選択」
- 判断プロセスや選択理由を記録・説明
設計レビューでの対応
- 「将来的な拡張」要求には「必要になった時の追加コスト」と「現時点での複雑化コスト」を比較
- **「今は待つべき理由」**を説明
マネージャーへの相談
- 「自分の判断や選択を正当に評価できるようなドキュメント化をしたい」と相談
- マネージャーに評価材料を提供

組織文化とインセンティブの転換

複雑なシステムを作った人ばかりが昇進する組織は、シンプルさを評価しない文化
シンプルさを評価する組織かどうかを見極めるポイント
エンジニアリングリーダーの役割
- 昇進や評価の基準を見直し、「何を作らなかったか」も評価
- 設計レビューでは「最もシンプルな案は何か？」を問う
- シンプルな実装や不要なコード削除を積極的に称賛

結論：シンプルさを報酬とする文化へ

複雑さばかりを評価し続ければ、複雑なものしか生まれない
シンプルさを可視化し、正当に評価するインセンティブ設計が重要
問題の本質は「複雑さ」ではなく、「不必要な複雑さ」の温存
シンプルな解決策を誇れる組織文化の醸成が最終的なゴール

Hackerたちの意見

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

└

私はあまり多くの会社で働いたわけじゃないから、ちゃんとした意見は持ってないけど、確かに賢い人たちが無茶な複雑さに従っていたところにはいたことがある。その理由の一つは、すでにものすごく複雑な状態になっていて、シンプルな解決策が政治的に実現可能ではなかったからだと思う。

└

ある大銀行のエンジニアリングチームが、クライアントからの単一のAPIコールが1,100のマイクロサービスと相互作用する4,000以上のマイクロサービスを持っているというブログ記事を以前に書いていた。素晴らしいアーキテクチャに聞こえるよね？/s これを4年以上も「シニアスタッフ」の役職で簡素化する責任を持ちたいと思う？これは複雑さを持つ多くの例の一つで、祝福されている。マイクロサービスの流行（Netflixから始まり、Thoughtworksによって過剰に宣伝された）は、この狂気を引き起こし、ある人たちにとっては維持するための技術的負債の山になってしまった。もし、自社の複雑なインフラコストから救うための非常に良い理由がない限り、このアーキテクチャを簡素化しようとすると、他のシニアスタッフエンジニアのチームから激しい反発に遭い、リスク担当者との何百もの会議や、建築家との永遠の会議でブロックされることになるよ。

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

└

偶然似たような話だけど、違う結末があった。私はAstro（Amazonのホームロボット）の最終組立ラインからテストステーションを排除したんだ。テストステーションがキャッチできるユニークな故障モードがなかったから（アイデアを集めて、提案された故障モードを分析した結果、他のステーションで全て検出できることがわかった）。これで約100万ドルの節約が見込まれ、ワークフローもシンプルになり、最終テストにかかる時間も減った。昇進を推進するためにマネージャーにこのことを話したら、「その価値を作ったのは他の誰かだよ、君はそれを無駄にしないようにしただけ」と言われた、笑。もっと強く押すべきだったかもしれないけど、確かに評価されてないと感じたし、もっと認識されるべきだったのか今でもわからない。でも、私のことを気の毒に思わないで、給料は十分良かったし、今は自分のやりたいことを楽しんでるよ :)

└

そんな大きなシステムの一つの変更の集まりで、どうやって収益の数字を割り当てるの？おそらく、同じ時期に他にもたくさんの機能がリリースされていたんじゃないの？その周りでA/Bテストはたくさん行われていたの？

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

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

└

こんな感じのことを言おうと思ってた。シンプルに物事を保つのが得意なら、インパクトを出すのに役立って、それが昇進につながるよ。

└

どんなルールにも例外や天才がいるけど、一般的にはシンプルな解決策をもとに昇進を主張するのは難しい。大きな影響を与えたとしても、トップ評価や少し大きめのボーナスはもらえるかもしれないけど、昇進は難しい。大企業には昇進のための基準があって、結局は「複雑」って言葉に集約される。「1年間のイニシアチブを推進する」とか「複数のチーム」とか「複数のコンポーネントを持つ大きな複雑なタスク」なんてのがその例だ。

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

└

このコメントには、私の耳にはLLMっぽい表現がいくつかあるな。特に「それが積み重なるインパクトだ」って部分。

└

機能的な組織では、主なエンジニアの役割は、複雑さと新しいシステムを減らすためにデザインをレビューすることになる。組織の目標（そしてその組織内のエンジニアの目標も）は、インパクトを提供することだ。シンプルな実装で3つの新機能のインパクトを出せるエンジニアは、1つの複雑な実装を作るのにかかる時間で昇進すべきだ。

└

> 組織がインセンティブを改善したいなら、レビューで聞くべき質問は「どれだけ大きなものを作ったか」じゃなくて、「次の四半期にシステムを変更しやすくしたか」だと思う。これが私の個人的な目標で、マネジメントに入る動機でもある。エンジニアが一番シンプルなものを作った時に報われるようにするのが私の仕事だと思ってる。今まで見つけたインセンティブを合わせる一番の方法はシンプルなポリシーだ。「君が望むものは何でも出荷するけど、君の電話番号は知ってるし、君のシステムのためにオンコールだよ。少なくとも2次オンコールね。」ちょっと意地悪かもしれないけど、エンジニアが質問されたり、3ヶ月前に作った変なものについてアラームが鳴ったりするせいで何もできないと感じると、すぐにシンプルにし始めることに驚くよ。 > 多くのシステムデザインの面接は、面接官がうなずくまでボックスを増やすことが目標だと無意識に教えてしまっている。もっと上級者の動きは、通常はシンプルに始めて、計測して、閾値を設定して、それから機械を追加することだ。システムデザインの面接をやるとき、失敗する一番簡単な方法は解決策を過剰に設計することだ。私は深く掘り下げる質問をするから、ちゃんと答えを用意しておいてね。私のお気に入りの答えは、「ああ、そうだね、このボックスは価値を追加しないから、取り除けるね。」っていうやつ。

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

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

└

そうだね、少なくとも眠れるから。

└

私もBさんだったことがあって、一度スタッフエンジニアに昇進したことがある。今は新しい組織でシニアに戻って、Aさんになろうとしてるけど、自分が何をしているのか、どう影響するのか、なぜそれが重要なのかをしっかり伝えるようにしてる。自分の仕事の価値をビジネスにどう説明するか（スクリーンショット、デモ、ドキュメント）を理解するのに、実際の仕事をするよりも時間を使っている気がする。でも、それは大事だと思う。そうしないと、昇進しないAさんになっちゃうから。

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

└

私の経験では、AIシステムがこれをやるのは、特に頼まない限り見たことがない。時々結果がちょっと複雑になることもあるけど、もっと抽象的なものが欲しいときは具体的に促さなきゃいけない。

└

正直、興味がある質問なんだけど、なんでインターフェースが複雑さを加えると思う？インターフェースは、その利用者が依存できる契約を指定するものだ。インターフェースがあることで、クラスを読むときに依存関係の実装を読む必要がなくなる。

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

└

小さなVPSでダメなGoアプリや、君が言ったようなVarnishやPostgresのような退屈な技術で解決できる問題がたくさんあるけど、ここでの直感は、これはものすごく早く進化する分野で、最先端にいないと怖いってことだ。だから、私たちは本当に変なものを作るんだ。

└

アートって何？

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

ハクソク