概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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