- ソフトウェアエンジニアリング文化では、複雑なシステムを作る人のほうが高く評価され、単純な解決策を選んだ人は評価されにくい構造が続いている
- 昇進評価や面接、設計レビューなどで、複雑さが「インパクト」と誤認され、不必要な抽象化や拡張性を追加する傾向が強まる
- 単純な実装は「見えない成果」として残る一方、複雑な構造は華やかな説明や文書化で昇進資料を埋めやすい
- 本当の熟練とは、より多くのツールを使うことではなく、いつ複雑さを排除すべきかを知る判断力と自信にある
- エンジニアとリーダーの双方が単純さを可視化し、それを正式に認める評価・報酬の仕組みを作る必要がある
単純さ vs 複雑さ: 昇進ストーリーの非対称性
- 同じチームの2人のエンジニアの例: Engineer Aは50行の簡潔なコードで数日で機能をリリースし、Engineer Bは新しい抽象化レイヤー、pub/subシステム、設定フレームワークを導入して3週間かけて完成
- Engineer Bの仕事は昇進パケットに「スケーラブルなイベント駆動アーキテクチャの設計、再利用可能な抽象化レイヤーの導入、設定フレームワークの構築」と記述できる
- Engineer Aの仕事は「機能Xの実装」という3語でしか表現されない
- 実際にはより良い仕事だったが、単純に見えるように作ったため、不可視の貢献になってしまう
- 「避けた複雑さ」で昇進する人はいない — 複雑さが賢そうに見えるのは、評価制度がそれに報いるように作られているからだ
面接とデザインレビューで複雑さが強化される構造
- システムデザイン面接で単純な解決策（単一データベース、直感的なAPI、キャッシュレイヤー）を提案すると、面接官が「ユーザーが1000万人来たら？」と圧力をかける
- サービス、キュー、シャーディングを追加するほど面接官が満足する、という経験につながる
- 候補者が学ぶ教訓: 「単純な答えでは十分ではなかった」
- 面接官が圧力をかけることには合理的な理由（プレッシャー下での思考力、分散システムの理解度の確認）があるかもしれないが、候補者に伝わるメッセージは「複雑さは印象的だ」ということ
- デザインレビューでも「将来に備える(future-proof) べきでは？」という問いによって、不必要なレイヤーや抽象化を追加してしまうパターンが繰り返される
- 問題が要求しているからではなく、会議室がそれを期待しているから追加している
- 数行のコード重複を避けるために作った抽象化が、かえって理解と保守を難しくする例を何度も経験してきた
- コードはより「プロフェッショナル」に見えたが、ユーザーが機能をより早く受け取れたわけではなく、次のエンジニアは変更前に半日を抽象化の理解に費やした
適正な複雑さ vs 不必要な複雑さ(Unearned Complexity)
- 複雑さそのものが問題なのではない — 数百万件のトランザクション処理には分散システムが必要で、10チームが同じ製品を作るならサービス境界が必要になる
- 問題は不必要な複雑さだ: 「データベースの限界に達したのでシャーディングが必要」と「3年後に限界に達するかもしれないので今シャーディングしよう」の違い
- これを理解しているエンジニアのコードやアーキテクチャは、「当然そうだよね」と感じられ、魔法のようでも過度に賢くもなく、理解できないせいで自分が愚かに感じることもない
- シニアになる本当の道は、より多くのツールやパターンを学ぶことではなく、いつ使わないかを知ることにある — 複雑さを追加するのは誰にでもできるが、取り除くには経験と自信が必要だ
エンジニアのための実践策
- 単純さを可視化しなければならない — 仕事はそれ自体では語ってくれず、評価制度もそれを聞き取れるようには設計されていないからだ
- 「機能Xを実装」ではなく、「イベント駆動アーキテクチャやカスタム抽象化レイヤーを含む3つのアプローチを評価したうえで、単純な実装が現在と予想される要件の両方を満たすと判断し、2日でリリースして6か月間無停止で運用した」 と記述する
- 何かを作らないと決めた判断もまた判断であり、重要な判断だ — それに見合った文書化が必要
- デザインレビューで「将来に備えるべきでは？」と聞かれても単に屈するのではなく、「後から追加するならこれだけかかり、今追加するとこれだけのコストが発生するので、待つほうがよい」と示す
- マネージャーに「作業の文書化の仕方を、コードだけでなく自分が下した判断も反映するものにしたい」と直接伝える — マネージャーにとっても擁護に使える言葉が提供されることになる
- これだけ努力しても、最も精巧なシステムを作った人だけを昇進させるチームなら、それも有用な情報だ — ある組織は単純さを本気で価値あるものと考え、別の組織はそう言いながら反対のものに報いる
エンジニアリングリーダーのための実践策
- インセンティブを設定するのはリーダーの責任だ — ほとんどの昇進基準は複雑さに報いるよう設計されており、「インパクト」は構築したものの規模と範囲で測られる傾向がある
- 構築したものだけでなく、回避したものも評価に反映すべきだ
- デザインレビューで「スケーラビリティは考慮したか？」の代わりに、「リリース可能な最も単純なバージョンは何で、より複雑なものが必要だと示す具体的なシグナルは何か？」 と問いを変える
- この1つの問いがゲームを変える: 単純さをデフォルトにし、複雑さに立証責任を負わせる
- 昇進の議論で、印象的なシステムの一覧で構成されたパケットに対して「それは本当に全部必要だったのか？ pub/subシステムは本当に必要だったのか、それとも書類映えしただけなのか？」と問い返す必要がある
- チームメンバーがきれいで単純なものをリリースしたら、そのストーリー作りを手助けすべきだ — 「複数のアプローチを評価し、問題を解決する最も単純なものを選んだ」という内容が説得力のある昇進事例になるには、リーダーが実際にそう扱わなければならない
- チームのチャネルで公に称賛する対象に注意する — 大きく複雑なプロジェクトだけを褒めると、人はそこに最適化する
- コードを削除したエンジニア、「まだ必要ない」と言って正しかったエンジニアを認めるべきだ
10件のコメント
レジュメ主導の設計...
この記事に出てくる提案が無意味だとは思いませんが、「巨大な設計」に勝つにはあまりにも力不足だと思います。あちらは説明するのがあまりにも簡単すぎるので :(
Hacker Newsのコメント
面接の質問で、2人がメールでスプレッドシートをやり取りしている状況を提示されたことがあった
私はGoogle Sheetsに移行すると答えたが、面接官は私にツールそのものを設計してほしかったようだ
当時は気まずかったが、今でもそこからどんな教訓を得るべきなのかはよく分からない
良い答えとして認めたうえで、その次に「これは技術設計を評価するための仮想シナリオなので、新しいシステムを設計してみましょう」と誘導するべきだった
応募者がその前提を受け入れられないなら、それはまた別のシグナルとして評価すればよい
私なら「既存の解決策がない前提で新しく設計しましょうか？」と聞くだろう
これは面接官が自分の望む答えだけを聞きたがるシステム設計版のアルゴリズム論争のようなものだ
実際それが正しい判断だったが、Patrick Collison本人から電話があり、「面接は通らなかったが、意図は分かるか」と聞かれた
結局その後もう一度面接を受けて合格した
面接の目的を理解することの重要性を示す逸話だった
ある大手フェリー会社がGoogle Sheetsで船の位置や従業員の配置を管理していて、友人は「これは大企業のやることではない」と言っていた
しかし私は、すでに検証済みのツールで問題を解決したのは素晴らしいと思った
そのおかげで社内開発チームや高額な外注なしで運用できる
私にとってはうぬぼれを深く葬ることになった経験だった
相手に何が具体的に合っていないのか説明してもらってから、そこで初めて技術設計を始めるべきだ
Sheetsを使えない理由はいろいろある — 機能制約、中国国内でのアクセス制限、会社のポリシー、ネットワークの問題など
顧客がすでにそうした理由でカスタムソリューションを求めているかもしれない
つまり、単に「Google Sheetsを使ってください」ではなく、顧客の文脈を理解することが開発者の役割だ
AIコーディングツールが問題をさらに微妙なかたちで悪化させている
今では複雑なアーキテクチャを5分で生成できるが、保守コストはそのままだ
その結果、より派手な構造がすぐ作られ、昇進用の文書もあっという間に完成する
しかし実際には、誰もそのコードを完全には理解していない
本当のシンプルさの基準は「次の人が質問なしに理解できるか」だが、AI生成コードはその試験を完全には通過できていない
今はそれがさらに悪化するだけだ
だから私は組織のコード理解文化がどれだけ強いかをキャリア選択の基準にしている
誰もシステムを分かっていない状況は二度と経験したくない
問題解決が目的なら、AIで作ったツールでも購入したツールでも、結局は問題を解決しなければならない
しかし既製品が合わないなら、最終的には自分で生成したカスタムソリューションが増えていくだろう
ただしそれを誰も理解できなければ、次の人がまた最初から作り直すことになる
それでも、利用者と作り手の距離が近づくという点では改善かもしれない
たとえば
AGENTS.mdに「KISS」「YAGNI」のような指針を明記しておくと役に立つ問題は、「次の人」が結局6か月後の自分自身だということだ
AIもcontext windowの限界で同じ問題を抱える
多くの開発者は人気スタックばかり追い、運用のしやすさを考えない
AIも「これは過剰設計だ」とは言ってくれない
KubernetesやElasticSearchが欲しければ、そのまま作ってくれるだけだ
FAANGとスタートアップの両方を経験した立場から言うと、複雑さとシンプルさのバランスが核心だ
大企業では場当たり的なハックが何千人もの生産性を損なう可能性があり、
スタートアップでは過剰なインフラが会社を潰しかねない
本当に熟練したエンジニアとは、その2つの状況を見分け、経験に基づいて適切なトレードオフを選べる人だ
Amazon（2005〜2008）で働いていた頃、会社文化の象徴だった2つの賞があった
「Just Do It」賞は自発的な問題解決、「Door Desk」賞は節約とシンプルさを象徴していた
実際に、役に立たないテレビを片付けた社員が賞をもらい、報酬としてそのテレビを渡されたという逸話がある
比喩としてのシンプルさは、現実では少し曖昧だった
シンプルさを主張するなら、ビジネスの言葉で表現しなければならない
「インシデント80%削減」「コスト40%削減」「性能33%向上」のように
シンプルさ自体は評価されなくても、その結果は高く評価される
私はリファクタリングをコストモデルに変換してKPIを計測し、MTTRを60%削減した
こうした数値を自分で示して初めて認められる
マネージャーとして私はシンプルなコードを好んでいた
ただしそれは、チームが熟練したメンバーで構成されていたからだ
経験の浅いチームでは、The Parable of The Toaster のようなことが起きる
年を重ねるほど複雑性に抵抗するようになる
しかしリーダーシップはしばしば、それを「理解できないから反対している」と誤解する
もっとも長く生き残ったプロジェクトは、シンプルで置き換えやすいものだった
AIツールはこうしたアプローチをさらに簡単にしてくれる — 独立したサンプルプロジェクトでコンポーネントを試し、検証済みコードを本番プロジェクトに統合するのだ
社内ネットワーク環境なのでAIを直接つなげてはいないが、このやり方は非常に有用だ
だから私は「複雑なものも作れますが、まずは簡単なバージョンから始めましょう」と提案する
たいていはそのシンプルなバージョンが、結局何年も動き続ける本番コードになる
シンプルな解決策を素早く出した開発者は、残った時間でさらに多くの機能を実装できる
一方で複雑な解決策にこだわる人は、1つの機能に何週間も費やす
結局、生産性指標ではシンプルなアプローチのほうが魅力的に見える
私自身も「大きなアイデア」より、着実に結果を出す人としてキャリアを築いてきた
うちの会社の面接の1つに、公共図書館システム設計の問題がある
最初は小さな町の図書館規模から始め、全国規模に拡張していくシナリオだ
最良の回答は「最大規模でもミドルクラスのサーバーとPostgresで十分だ」だった
現実には10でも10,000でも大差ないのに、経験のない面接官がプロンプトを読んでいるだけのことが多い
その後、過剰なインフラと履歴書主導の開発が問題を大きくした
AIは結局、利用者の力量を増幅するツールだと思う
熟練した開発者には生産性を高めてくれるが、未熟な人には混乱を素早く拡散する道具になる
むしろ不要なラッパー関数や型変換を追加する傾向がある
AIは「コードをもっと足す側」に近いと感じる
ただし、深みのない「vibe coding」が増えるのは不安だ
私が会った面接官たちも複雑さを好んでいました。
シンプルさが高く評価されることまでは期待していませんよ。現実には、複雑にして問題を起こし、その後始末をしたことで昇進することさえあるんですから。
サービスのための設計ではなく、能力を誇張するための過剰設計がはびこっていますね
評価者の理解度が高いことが重要だと思います。
説明も十分に聞く必要があるのもその通りです。
それを評価できる人が上にいるならすべてうまくいくのですが、そもそもそれができていないから、こういうことが正当に評価されず、だからそういう人たちは上に上がれず……
これが悪循環なんですよね……
会社の立場からすると、バランスの取れたエンジニアとして成功して上に上がってこそ、良いエンジニア／エンジニアリングのprincipleも守れるのだと思います。
現実の大半は、単純に機能実装だけができる人と、拡張性を意識して設計できてトレードオフもうまく判断できる人、という違いではないでしょうか
複雑に作業したとしても、結局は機能Xの実装と言えるわけで、
それを評価者にどのように表現するかの違いですね