2026/03/04 20:43
「単純さだけを理由に昇進する者は存在しません。」
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Summary
エンジニアリングチームは、複雑なシステムが昇進パッケージや面接パネルで印象的に見えるため、過剰設計を報奨する傾向があります。短く迅速に配備できる単純なソリューションは、キャリアの進展議論では目立たず、報酬が少なくなることが多いです。面接官や設計レビューは、追加サービス、キュー、シャーディング、抽象化を求めることで、複雑さをスケーラビリティの代理指標として扱います。この「将来性確保」マインドセットは、不要な層を生み出し、コードを理解しにくく保守しづらくしてしまい、見た目の洗練感が実際には無意味になる原因となります。
根本的な問題は、影響力を機能規模と等価化する昇進基準です。これに対抗するために、エンジニアは意思決定プロセスを文書化すべきです（「X のアプローチを評価し、現在の要件に合わせて Y を選択した」など）ので、ミニマリズムがレビューで認識されやすくなります。リーダーはインセンティブ構造を調整する必要があります：例えば「私たちが配備できる最も単純なバージョンは何か？」と質問し、昇進議論の際に不要な複雑さを挑戦します。公的認知は、大規模プロジェクトと同等にコード削除やミニマリズムを報奨することで、最適化インセンティブを転換すべきです。
チームが単純さの価値付与努力にもかかわらず複雑なシステム構築者を昇進させ続ける場合、それは文化的不一致を示し、エンジニアが派手なアーキテクチャよりも健全な判断を重視する組織へ流れる可能性があります。インセンティブをシンプルで保守しやすい解決策に向けることで、昇進と実際の影響力を一致させ、技術的負債を減らし、ユーザーと企業双方に対して製品の信頼性を向上させます。
本文
「シンプルさは素晴らしい美徳ですが、実現には大きな努力と、評価するための教育が必要です。さらに悪いことに、複雑さのほうが売れやすい。」 — エドスガー・ディジャーク
私は、多くのエンジニアリングチームを静かに狂わせている何かがあると感じています。面接時、昇進パケットで、設計レビューでも同様です。過剰に構築したエンジニアは説得力のある物語を持ちますが、最もシンプルに動くものだけを出す人には…何も言えません。
当然ながらこれは意図的なことではありません。誰も「過剰設計者を昇進させるようにしろ！」と決めているわけではないのです。しかし、企業が仕事を誤って評価するとき、（そして繰り返し起こっています）そうなる可能性があります。
同じチームに属する二人のエンジニアを想像してください。Aさんはある機能を担当します。彼女は問題を見て数つの選択肢を検討し、最もシンプルなもの―直感的で 50 行程度のコード―を選びます。読みやすく、テストもしやすく、次に引き継ぐ人にも扱いやすいです。それが機能します。数日でデプロイし、次へ移ります。
Bさんも同じような機能を担当します。彼は問題を見て「もっと『頑丈』にできる」と思い込みます。新しい抽象化レイヤーを導入し、コンポーネント間の通信には pub/sub システムを作り、将来のユースケース向けに拡張性を持たせる構成フレームワークまで追加します。それは三週間かかります。複数の PR が出て、多くのエモジが寄ってきます。
昇進時になると、B さんの仕事はほぼ自動的に「スケーラブルなイベント駆動型アーキテクチャを設計・実装し、再利用可能な抽象化レイヤーを導入し、将来拡張性を可能にする構成フレームワークを構築した」と書き込まれます。これは Staff+ へと直感的に飛び上がります。
しかし A さんの仕事はほぼ言うことがありません。「機能 X を実装しました。」三語だけです。彼女の仕事の方が優れていたとしても、そのシンプルさゆえに見えなくなってしまいます。構築しなかったものについて魅力的な物語を書くことはできません。複雑さを避けたことで昇進する人はいません。
複雑さは「賢い」ように映ります――それ自体が賢いわけではなく、システムがそれを報酬として設計されているからです。このインセンティブ問題は昇進時点で始まるものではなく、仕事を得る前から始まります。
面接を考えてみてください。あなたはシステム設計ラウンドにいて、単一データベース・直感的な API だけでなくキャッシュレイヤーまで提案します。インタビュアーは「スケールはどうする？1000 万ユーザーになると？」と言います。そこでサービスやキュー、シャーディングを追加し、ホワイトボードにさらに箱を書き込みます。最終的にインタビュアーは満足します。
あなたは複雑さが人々を印象づけることを学びました。シンプルな答え自体は間違っていませんでした――ただ興味深くないだけです。そしてそのレッスンをキャリアに持ち込むかもしれません。正直言えば、インタビュアーが拡張性を求めるのには合理的な理由もあります―圧力下でどんな考え方をするか、分散システムを理解しているかを見たかったりします。しかし候補者にとって「単純すぎた」という結論になるなら、何かがおかしい。
設計レビューでも同じことが起こります。エンジニアがクリーンでシンプルなアプローチを提案すると、「将来性はどうですか？」と言われます。そのためにまだ必要ではないレイヤーや抽象化、要求されていない柔軟性まで追加してしまうのです。問題が求めているわけではなく、部屋（＝評価者）がそれを期待するからです。
私はエンジニア（自分自身も含む）に、数行だけのコードを重複させるために抽象化を作ったケースを見ました。結局はより理解しづらく保守しづらいものになりましたが、その度に「正しいこと」をしていると感じていました。コードはもっと「プロフェッショナル」だった、という印象です。しかしユーザーは機能を速く手に入れられず、次のエンジニアはその抽象化を理解するために半日も費やさなければなりませんでした。
ここで明確に言っておきます。複雑さが必ずしも悪いわけではありません。もし数百万件のトランザクションを処理しているなら、分散システムが必要になるでしょう。10 チームが同じ製品を扱う場合はサービス境界が必要です。問題が複雑であれば、解決策も（おそらく）複雑であるべきです。
問題なのは「無駄な」複雑さです。「データベースの制限に直面してシャーディングが必要だ」と言うことと、「3 年後にデータベースの制限に直面するかもしれないので今すぐシャードしよう」ということには違いがあります。
一部のエンジニアはこれを理解しています。彼らのコードやアーキテクチャを見ると「そうだ、当然だ」と思えます。魔法でもなく、賢さもなく、あなたがそれを理解できないから愚かに感じるようなものではありません。それこそが要点です。
本当の上位職への道は、ツールやパターンを学ぶことではなく、それらを使わない判断力を身につけることです。誰でも複雑さを追加できますが、除外するには経験と自信が必要です。
それで私たちは何をすべきでしょうか？「シンプルに保とう」と言うのは簡単です。インセンティブ構造を変えるのはもっと難しいことです。
エンジニアとして、シンプルさを可視化する方法を学びましょう。仕事が自動で語るわけではありません――良いからといってそう言う必要はないですが、多くのシステムはそれを聞くように設計されていません。
まず自分自身の仕事について話す方法から始めます。「機能 X を実装しました」だけでは意味が薄いです。代わりに「イベント駆動型アーキテクチャとカスタム抽象化レイヤーを含む三つのアプローチを評価し、現在および将来の要件すべてを満たすシンプルな実装が最適であると判断しました。2 日でデプロイし、6 か月間ゼロインシデントでした。」というように、意思決定過程を文書化します。構築しない選択も重要な決断です。
設計レビューでは「将来性はどうする？」と聞かれたら、「後で追加する場合の手順とコスト、今現在の費用を示します。今回は待つ方が良いと思います」と答えます。反論しているわけではなく、自分で調査した上で選択したことを示すだけです。
そしてマネージャーにも「自分の仕事の文書化方法を改善したいので、次回のレビューでどのように表現すれば良いか相談できますか？」と話します。ほとんどのマネージャーはこれを喜びます――彼らの仕事が楽になるからです。自分を主張するための言語を提供してくれるわけです。
もしこの全てを行っても、チームが依然として最も洗練されたシステムを構築した人だけを昇進させるのであれば、それは有用な情報です。自分が働いている環境について何か教えてくれます。ある文化は本当にシンプルさを評価しますし、別の文化はそう言いながらも逆に複雑さを報酬として与えます。後者の場合はゲームをプレイするか、良い判断が認められる場所へ移るか選択できます。
エンジニアリングリーダーなら、他よりずっとこの課題に直面します。インセンティブを設定しなければなりません――それが無意識のうちであってもです。多くの昇進基準は実際には複雑さを報酬として設計されています。「インパクト」は構築したものの規模と範囲によって測られますが、避けたことも同じくらい重要です。
まず質問内容を変えてみましょう。設計レビューでは「スケールはどうする？」の代わりに「最もシンプルなバージョンは何で、どんな具体的サインがより複雑なものを必要とすると示しますか？」という質問を投げるとゲームが変わります。これでシンプルさがデフォルトになり、複雑さには証明責任が生じます。
昇進議論では、誰かのパケットが印象的なシステムのリストだけなら「それは本当に必要だったのですか？pub/sub システムは実際に必要だったのでしょうか？」と問い返します。チームでクリーンでシンプルなものを出したエンジニアには、「複数のアプローチを評価し、最も単純な解決策を選択しました」と物語を書く手助けをします。それが説得力ある昇進ケースになるのは、実際にそれを扱うときです。
さらに一つ。公開で祝福するものに注意しましょう。チームチャネルで大規模・複雑プロジェクトだけが称賛されるなら、人々はその方向へ最適化します。コードを削除したエンジニア、まだ必要ではないと判断し正解だった人を認めるようにしましょう。
結局のところ、もし私たちが複雑さを報酬として与え続け、シンプルさを無視し続ければ、まったく予想通りの結果が得られるはずです。しかし解決策はそれほど複雑ではありません――これこそがポイントと言えるでしょう。