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

45日前原文(terriblesoftware.org)

概要

シンプルさは高い美徳だが、評価や報酬の仕組みが複雑さを優遇しがち
過剰設計が昇進や評価で有利になる現実
シンプルな解決策の価値を可視化・言語化する重要性
リーダーやマネージャーの評価基準・問いかけの変革が必要
文化やインセンティブの見直しがシンプルな技術文化の鍵

シンプルさが報われないエンジニアリング現場

Edsger Dijkstraによる「シンプルさは美徳だが、努力と教育が必要」という言葉
複雑な設計が昇進や評価で目立つ現実
シンプルに解決した人の成果が目立たず、評価されにくい構造
意図的ではないが、過剰設計が報われる仕組み
仕事の評価方法が根本的な問題

典型的なエンジニアAとBの比較

エンジニアA：問題を分析し、一番シンプルな実装を選択
- 50行ほどのコード、テストや保守も容易
- 数日でリリース、次のタスクへ
エンジニアB：より「堅牢さ」を追求
- 新しい抽象化レイヤー、pub/subシステム、拡張性のための設定フレームワークを追加
- 実装に3週間、複数のPR、ドキュメントも充実
昇進審査ではBの方が「実績」が目立つ
- 「スケーラブルなアーキテクチャ設計」「再利用可能な抽象化レイヤー導入」など
Aの成果は「Feature Xを実装」だけで、目立たない

複雑さが評価されやすい構造の背景

複雑さは「賢そう」に見えるため評価されやすい
面接でもシンプルな提案は「スケールは？」「1,000万ユーザーなら？」と追加要求される
- 結果的に複雑な設計が「正解」に見える学習効果
設計レビューでも「将来のために拡張性を持たせるべき」と指摘されがち
- 実際には不要な抽象化や柔軟性が増えるだけ
本来の問題解決よりも、「複雑さを避けた判断」が評価されない構造

本当に必要な複雑さと「不要な複雑さ」の違い

大量トランザクションや大規模チーム開発など、複雑な解決策が必要な場合もある
問題が複雑なときにのみ、複雑な解決策が正当化される
「将来必要かも」で今から複雑化するのは「不相応な複雑さ」
経験あるエンジニアほど「何も足さない」判断ができる
- 本当のシニアは「使わない勇気」を持つ

シンプルさを評価・可視化するためのアクション

エンジニア自身が「シンプルさの価値」を伝える工夫
- 「Feature Xを実装」ではなく、「3つのアプローチを比較検討し、必要十分な実装を選択、6ヶ月間インシデントゼロで運用」と説明
- 「作らなかったもの」も意思決定として明記
設計レビューで「将来のために拡張すべき？」と問われた際
- 「後から追加するコスト」と「今追加するコスト」を比較して説明
- 十分な根拠を持って「今は不要」と判断
マネージャーとの対話も重要
- 「自分の意思決定も評価に反映したい」と相談
- マネージャーに「評価のための言語」を提供

組織文化とインセンティブの課題

複雑さばかり評価される組織なら、それがその組織の文化
- シンプルさを本当に評価する組織も存在
- どちらの環境かを見極める重要性
リーダーやマネージャーの役割
- 昇進基準や設計レビューの「問い」を変える必要
  - 「スケールは？」ではなく「最もシンプルな実装は？」と問う
  - 複雑さの正当性を証明する責任をエンジニア側に課す
- 昇進議論でも「本当に必要だったか？」を問う
- シンプルな実装をしたエンジニアの実績を積極的に言語化・評価
チーム内で称賛するポイントも見直し
- 大規模プロジェクトだけでなく、不要なコードを削除した人や「今は不要」と判断した人も称賛

まとめ：シンプルさを報いる文化の構築

複雑さを報い、シンプルさを無視する限り、複雑なものばかり増える
解決策自体はシンプルであり、シンプルさを評価する仕組み作りが本質
本当に価値ある判断は「何を作らないか」を見極めること

Hackerたちの意見

そうだね。ビジネス用語で説明しないとダメだよ、テクノロジー用語じゃなくて。「インシデントを80%削減」、「コストを40%削減」、「パフォーマンスを33%向上させつつ、サーバーのフットプリントを25%削減」みたいな感じで。単純さそのものは評価されないけど、単純さの結果はすごく評価されるんだ。

└

以前はそうだったね。企業は効率を重視するから。現代のAIと比べてどうなんだろう？その指標は逆の方向に行く気がする。

└

君はネガティブな指標を挙げてるね。実際には、企業はポジティブな指標にしか興味がないんだ。「限界収益を30%増加させる」ってね。コスト削減やリスク軽減についての口先だけのことは関係なしに。AI経済では成長が全てだから、状況は悪化する一方だよ。

└

その通りだね。もし彼らに「早く欲しいか、シンプルにしたいか」って聞いたら、毎回「早く」って選ぶと思うよ。

└

>「インシデントを80%削減」、「コストを40%削減」、「パフォーマンスを33%向上させつつ、サーバーのフットプリントを25%削減」私の経験では、こういうことでは誰も本当に昇進したり報われたりしないし、少なくとも最初の一回の拍手を超えることはないよ。みんなが気にしてるのは機能のリリース速度だけ。もし本当にインシデントを80%削減できるなら、君の組織は基本的に毎日の問題に対して非常に高い耐性を持っていて、それを週に一回に減らしたか、もしくは元々インシデントが少なすぎて、80%減っても年4回から年1回になるだけで、経営陣やユーザーにはほとんど気づかれないんだ。

└

複雑さの山を作らないことの影響は測れないよね。

└

その動詞（減少した、増加した、減った）は、すでに「悪い」状況だったことを前提にしてるよね。初期設計でそれを避けるのがあまり評価されない。初日から速いシステムを作るより、遅いシステムを作って80%速くする方が評価されることが多いよ。

└

こういう指標を実際に見たことがない、特にエンジニアリングでは。

私たちのインタビューの一つは、候補者に公共図書館のためのウェブベースのシステムを設計させる技術的なデザインの質問なんだ。どれだけシンプルに保てるかを明示的にテストするもので、「小さな町の図書館」から始めて、「全国のすべての図書館」に要件を変更するんだ。最高のパフォーマンスを出した人は、理論上の最大規模でも、中くらいのサーバーとPostgresがあれば十分だと見積もったんだよ。

└

ちょっと待って、つまり、全ての会社がデザインシステムのインタビューでSpotifyを作ってるわけじゃないってこと？ありえないよ。

└

その答えを言ったせいで、100%面接に落ちたことがあるよ。彼らのスケールの定義が10,000 req/secだったから！2026年にはそれ、10 req/secとあまり変わらないし、元の設計で全然問題ないのに…でも、面接官が「シニア」な24歳で、ただプロンプトを読み上げてるだけだとこうなるんだよね。

└

みんな忘れがちだけど、初期のウェブってサーバーのクローゼットで、現場で毎秒何百ものリクエストを処理してたんだよね。開発者たちがもっとサーバーが欲しいって言って、理由を説明するのに疲れちゃって、ビジネスがハイパースケーラーに売られたんだ。そしたら、ダウンしてる間は毎秒お金が失われるから、高可用性のサービスが売り込まれた。でも、実際にそれを構築・維持するコストが、失うお金よりも高いってことは、大きな組織以外は誰も言わなかったよ。履歴書重視の開発の話はもうやめておくけど、もしかしたら俺が完全に間違ってるかもしれない。これはあくまで一つの視点だからね。

AIのコーディングツールは、この問題を微妙に悪化させてるね。エージェントが5分で「スケーラブルなイベント駆動アーキテクチャ」を生成できると、複雑さの構築コストはほぼゼロに近くなる。でも、メンテナンスコストは変わらない。だから、エンジニアBのアウトプットがさらに早く、さらに印象的な抽象化で出てくるし、昇進パケットも数分で自動的にできちゃう。でも、実際のコスト—デバッグ、オンボーディング、午前3時のインシデント対応—はそのままか、悪化するんだ。なぜなら、誰も生成されたものを完全には理解していないから。シンプルさの本当のテストは、次にこのコードに触れる人が君に聞かずに理解できるかどうかなんだ。AIが生成した複雑さは、そのテストに見事に失敗するよ。

└

今の時代、利他的な完璧主義者は辛いよね。ハンズオンのテクノロジーやチームリーダーのポジションは絶対避けた方がいいよ。

└

その反面、メンテナンス性が大きなセールスポイントの言語は、価値が劇的に上がったね。

└

シンプルさはより良い抽象化を促進するんだけど、AIがある今、新しい抽象化を開発することってできるのかな？

└

その一方で、AIコーディングツールを使うと、こういうことに役立つポリシーを設定して適用するのが比較的簡単になるよね。AGENTS.mdにはこんな感じのことを書いておきたいな。## 指針 - 長期的なメンテナンス性を最適化する - KISS - YAGNI

└

> 今や誰も生成されたものを完全には理解していないまあ、正直なところ、LLMが存在する前の午前3時に呼ばれたオンコールの人たちも、彼らがサポートしていたシステムをあまり理解していなかったよね。これが状況を悪化させることは間違いないと思う。今は、安全なキャリアパスを描くためには、どの組織がコードやスタックを理解する文化が強いのかを評価することが大事だと思う。もう二度と、誰もその場で何がどう動いているのか知らない状況にはなりたくないし、上司が何か重要なものが壊れたことでパニックになっているのを見たくないよ。

└

この理由で、ソフトウェアが製品としての価値が下がると思う。もし君の仕事が問題を解決することで、AIを使ってその問題を解決するツールを生成したら、それでもその問題を解決するのは君の仕事なんだ、どのツールを使うかに関わらず。もし君が誰も理解できないものを生成してしまったら、君が辞めて新しい仕事に就くとき、他の誰かが君のプロジェクトを使って、その問題を解決するための自分のやり方に合ったものを生成するだろう。時間が経てばニーズも変わるし、彼らもまた部分的にしか理解できないものを手に入れることになる。そして、彼らが去ると、そのサイクルは繰り返されるんだ。

誰が言ったか忘れたけど、AIって結局、ツールを使う人の才能（またはその欠如）を増幅するものみたい。経験豊富な開発者やデザイナーが使えば、いい結果をより早く出せるし、逆に経験のない人が使うと、ただ早く混乱を生み出すだけになっちゃう。生成されたものを評価するスキルがなければ、それに気づかないこともあるしね。

└

経験がないけど疑い深い人が、AIを使って自分のコードを学んだり修正したりするのはどう？

└

僕はシンプルさを重視するエンジニアで、AIが僕が作業しているコードのシンプルさを高める方法を見つけられなかったんだ。放っておくと、Claudeは冗長性を分析したり排除する代わりに、メンバー変数やラッパー関数、型変換を追加するのが大好きなんだよ。だから、AIは「もっとコードを追加する」という解決策を常に選ぶエンジニアタイプに近いと感じているよ。

面接で聞かれた質問があったんだ。もし二人がスプレッドシートをメールでやり取りして何かを追跡してたら、どうする？って。俺は「Googleシートに移す」って答えたんだけど、その後5分くらい awkward な時間が続いた。ソフトウェア開発者の面接だったから、どんなツールを作るかについて話すべきだったんだ。でも、ちょっと目から鱗だったけど、正しい教訓が何だったのかはまだよく分からない。

└

俺の共同創業者が、ストライプとアクイハイアについて話してたんだけど（俺が辞めた後ね）。その一環で、システム設計の面接を受けることになったんだ。プロンプトをもらって、スループットの要件について質問して、「じゃあ、全部Postgresに入れるよ」って言ったんだ。正解だった！Postgresはその負荷を十分に処理できるからね。そしたらパトリック・コリソンから電話がかかってきて、面接に失敗したって言われて、何があったのか聞かれたんだ。彼は自分の説明をしたけど、パトリックは「うん、君は正しいかもしれないけど、面接の目的も理解してるよね」と言ったんだ。結局、もう一度やらされて、合格したよ。

└

教訓は、時には面接を受ける側が面接官よりも有能で、彼らが運営すべきだってこと。

└

これも俺のお気に入りの面接質問の一つだよ。技術的には、俺が面接している専門的なスキルセットを使って解決できるデザインの質問をするけど、実際にそれを現実世界でやるのはクレイジーだと思う。彼らがどれだけ実用的でオープンマインドかを見るための良いオープナーなんだ。

└

学ぶべき教訓は、社内開発グループはしばしば「カスタムソフトウェアソリューション」を自分たちの組織に「売る」ことにインセンティブがあるということ。彼らの存在（予算）はそれに依存しているからね。面接を受ける側としては、面接しているグループが本当にそういう風に運営されているのかを見極めることが大事だよ。具体的には、どうやってあなたの給料を払うお金を得るつもりなのか？そうすれば、面接の質問に対して的外れな答えをするのを避けられるよ。

└

> もし二人の異なる人が、何かを追跡するためにスプレッドシートを行ったり来たりしている場合、あなたはどうしますか？これは面接のゲームの一部だと理解しているけど、もしかしたら最良の回答は、まずこの状況がなぜ問題なのかを尋ねることかもしれないね。その後、技術的な解決策に入る前に。相手に、このやり方がビジネスにとってうまくいっていない具体的な（作り話の）理由を提供させるように仕向けるんだ。それから、いつも通りに進めればいい。

└

フォローアップの質問はいつも役立つよ。「何を追跡しているの？」とか「スプレッドシートを使うことでどんな問題が起きているの？」ってね。これで、彼らが求めている答えの手がかりが得られることが多いよ。答えがでたらめでも、彼らのゲームに乗って面接を通過することが大事だからね。

└

なんで彼らはメールで送っているのか、聞いてみるよ。もしかしたら、シートを使えない良い理由があるかもしれないしね。

└

これは文化的なフィット感の質問だね。「すべて自分たちで作る」文化の時は、あまりフィットしていない。逆に「ただ問題を解決する」文化の時は、すごくうまくフィットするよ。

└

それ、ひどい面接の質問だね。面接準備を手伝ってたとき、みんな面接の振り返りをしてアドバイスを求めてたんだ。君みたいに質問の妥当性を議論しちゃって、面接が脱線することが多かったよ。多くの人は悪い面接の質問について愚痴りたいだけなんだけど、それはそれでいいんだ。ただ、実践的なアドバイスとしては、面接の質問は数学の問題みたいなもので、具体的な内容は恣意的で論理的じゃないこともあるって思い出してほしい。解決策を提示して、過程を示すことが重要なんだ。これが一番明らかになるのは、完全に恣意的な質問のとき。「3で割り切れる場合を除いて、各行の数字を印刷する必要があります。その場合は「Fizz」と印刷します…」みたいな感じね。（実際、面接でFizzBuzzの質問の妥当性を議論しちゃった人もいたけど、予想通り面接は早々に終わったよ。）こういう質問には、面接の文脈に合わせた言葉の問題だと思って対処するのがいいよ。良い返答は「まあ、Google Sheetsを使うことを提案します。これは解決済みの問題ですから！でも、他の理由でシンプルなカスタムソリューションが必要だと仮定するなら、要件を集めてシンプルなウェブフォームを提案します…」って感じ。イライラする？そうだね。でも、面接の質問を議論したり、言葉の問題の本質を見失ったショートカットの回答をしようとするのは、面接官をイライラさせるだけだよ。

└

IT管理をしていた頃、これがよくあったんだ。技術に詳しくない人がスプレッドシートをメールで送って、また別の技術に詳しくない人がそれを編集して保存する。最初の人が変更が見えないって文句を言うんだ。そう、だってそれは誰も訪れないようなMS Windowsのプロファイルの場所に保存されてるからね。私の解決策は、共有リソース上のファイルへのリンクだけをメールすることだった。こんな問題を解決するためにソフトウェアを書くなんて、考えもしなかったよ！今、もし面接で「普遍的なシンプルな解決策を使います」って言われたら、「そうだね！それでたくさんのエンジニアリング時間を節約できたし、会社もお金を節約できたね」って言うよ。

俺は2005年から2008年までアマゾンでソフトウェア開発エンジニアとして働いてた。会社の文化を強調するために、四半期ごとの全体会議で2つの賞が授与されてたんだ。*「Just Do It」賞は、目の前の明らかな問題を解決した人を認めるもので、責任は問われない。*「ドアデスク」賞は、みんなが使ってた基本的なドアフレームの四本脚のデスクにちなんで名付けられた節約の賞。多くの意味で、ドアデスク賞はシンプルさのためのものだった。ある時、誰かが使われていない大きなLCDテレビがあるオペレーションルームを片付けたことで賞をもらったことを覚えてる。これらの賞をもらっても、実際には何か特別な報酬はなかった。ただ会議で認められるだけ。でも、その時は本当にその人にテレビが渡されたんだ。

└

ただし、もちろん「シンプル」なDoor Deskは、実際にはIKEAの同等品よりも高かったし、特に追加機能もなかったし、組み立てるのにもっと時間がかかったんだよね。これがメタファーを少し曖昧にするんだよね… (amzn 94-96)

複雑さが評価される場所にいるなら、シンプルさを正しく理解するためには、複雑な情報理論やその分野に関する存在論的知識を深く理解する必要があるって主張できるかもね。これが本当だってのは助かるよね。「ベイズのオッカムの剃刀」や、コードのエントロピーを最小化すること、テストやインフラのエントロピーについても話せるよ。

それは完全に正しいわけじゃないよ。ビジネスの利害関係者が主導する環境では、機能を迅速に出荷し、稼働中にほとんど壊れないエンジニアは大いに評価される。逆に、シンプルな機能を過剰に設計して、予期しない問題が発生するエンジニアはあまり評価されない。過剰設計が評価される環境は、エンジニアリング部門がエンドユーザーから（あまりにも）離れているところだと思う。壁で区切られた大企業や、エンジニアが存在しない問題に対処するために何かを作り始めるような組織を考えてみて。

問題は複雑になり得るし、時には解決策も複雑になる必要があることもある。でも、複雑な問題をシンプルな方法で解決できることも多いんだ。いくつかの方法があるよ：a) 空間や解決策をシンプルにする新しい理論的枠組みを見つける、b) 他の人が見つけられなかった既存の抽象を利用する方法を見つける、c) 組織やビジネス、UXレベルでスコープを削減し、要件をシンプルにするために非技術的な手段を使う。複雑さをキャリアに活かす方法は、なぜその問題が複雑なのかを明確にし、問題をシンプルにするために自分が何をしたのかを示すことだよ。シンプルな解決策だけを提示しても、誰も理解してくれない。これは「過程を示す」ことに似ている。一部の組織では、実装の複雑さを本当に評価するから、これは絶望的だね。

これは私のキャリアを通じてのテーマで、公開しなかった良いシナリオがたくさんあるんだ。「最も複雑なシステム」だけじゃないんだよ。同じことが他の多くの方法でも起こる。例えば、良いシンプルな解決策は一度で済むけど、複雑なものは後々間接的な問題を引き起こす原因になることが多い。で、2人目のエンジニアがそれを修正することになる。さらに、10倍の成果を上げるエンジニア（全ての10倍のエンジニアに当てはまるわけじゃないけど）が他のプロジェクトを「修正」するように求められ、次に移ってしまうと、チームに全ての負債を残していくってパターンもある。このダイナミクスは、ゲーム理論の観点から研究する価値があると思う。これは、ジャーヴェイスの原則を支える隣接行動の一つかもしれない。今、AIがこの仕事の多くを標準化しているから、もうすぐ終わる可能性が高いね。

ハクソク