/note/tech

ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか

要約:

■ 1. 記事の主張

  • エンジニア間の「すれ違い」は性格や能力の問題ではなく、情報処理における認知戦略の構造的な違いから生じる
  • チームで観察される共通のパターン:
    • コードレビューで矛盾した指摘が出る
    • 設計について「すぐ着手派」と「全体合意派」に分かれる
    • ドキュメント作成の習慣に大きな個人差がある
    • 同じタスクでも時間と成果物のスタイルが異なる
    • 技術力は高いが説明が苦手な人がいる
  • これらの症状はリーダーから「怠慢」「スキル不足」「コミュニケーション能力の欠如」と判断されがちであるが、実態は異なる:
    • ドキュメントを書かない人: 本人の頭の中では完全につながっており、外部化に価値を感じていない
    • 作業が遅い人: 見えない工程(構造化、可視化)に時間を投資している
    • プレゼンが下手な人: 聴者レベルに合わせた知識の再構成プロセスが認知で機能しにくい

■ 2. 情報処理の二つの戦略

  • 圧縮型(Internalizer):
    • 情報を脳のワーキングメモリ内に保持することを優先する
    • 短い識別子、簡潔なコード、ショートカットの多用を好む
    • 迅速な判断と手数の少なさを重視する
    • 外化を「速度を落とすもの」と感じる傾向がある
    • 強み: コードベース全体を頭の中に保持し、実装レベルのバグや既知パターンの問題を検出する能力が高い
    • 弱み: 知識が内部に閉じ込められ、プレゼン能力が低下しやすい
  • 展開型(Externalizer):
    • ワーキングメモリを超える情報を外部(図、文書、コメント)に配置する
    • 長く説明的な識別子、詳細なドキュメントを好む
    • まず全体像を描いてから実装する
    • 文脈や意図の保存を重視する
    • 強み: 全体像を外部で俯瞰することで、構造的ゆがみや設計の一貫性欠如を検出する能力が高い
    • 弱み: タスク完了速度が遅くなる傾向がある

■ 3. 違いが生じる根本原因

  • 両戦略は、同じ物理的制約(ワーキングメモリの容量限界)に対する異なる最適化である:
    • 圧縮型: 容量内に収めるために情報を削りたい
    • 展開型: 容量外に情報を置きたい
  • 未確定情報への対応が両者の決定的な違いである:
    • 圧縮型: 曖昧さをワーキングメモリに「非圧縮のまま」置く必要があるため高コストを感じ、早期確定を求める
    • 展開型: 曖昧さを「?」付きで外部に置けるため、低コストで保持できる

■ 4. エラー検出能力の非対称性

  • 圧縮型が得意な検出: 実装レベルのバグ、既知パターンの問題
  • 展開型が得意な検出: 構造的ゆがみ、設計の一貫性欠如、未認識問題
    • ドメイン概念の不自然な統合
    • 特定コンポーネントへの依存集中
    • モジュール粒度の不均一性
    • 層構造の不自然な飛び越え

■ 5. 知識の呪いとプレゼン能力

  • 圧縮型の人は高度に圧縮された知識をもつため、背景や文脈を「自明」として意識から除外している
  • 聴者にとって理解の手がかりとなる情報がプレゼンに含まれない結果、説明が不十分になる
  • 展開型は知識を外部に展開した状態で保持するため、「聴者が持たない部分」を構造的に認識でき、より効果的なプレゼンができる

■ 6. 認知戦略の発生過程

  • 認知戦略は「生まれつきの性格」ではなく、後天的に獲得されるものである
  • 発達段階:
    • 学校教育段階: 全員が圧縮と外化の両方を訓練される
    • プログラミング導入期: コードという強力な圧縮表現を発見し、一部の人が外化を「不要」と感じ始める
    • 初期の成功体験: 圧縮で成功した人は外化を捨て、外化で成功した人は維持する
    • 環境複雑化時: 外化を捨てた人も再び必要性を感じ、拾い上げる
  • 圧縮型が外化スキルを習得することは純粋な能力拡張(新しい記憶域の追加)であり、比較的容易
  • 展開型がワーキングメモリを物理的に増やすことは困難

■ 7. 設計原則と認知の前提

  • 設計原則(関心の分離、単一責任、レイヤード化など)は展開型の認知を前提としている
  • これらの原則は「システム全体を一度に頭に入れなくてよい構造を作る」ためのもの
  • 圧縮型にとっては既に全体が見えているため、分割は「余計」「不要な間接参照」に感じられる
  • 圧縮型/展開型は固定的なラベルではなく環境との相対的な位置であり、同じ人が別のチームでは別のタイプに見えることもある

■ 8. 実践的な対処法

  • 冗長度の明示的合意:
    • ADR(意思決定記録)、ランブック化、コメント規則など、成果物ごとに「何をどこまで外化するか」をチームで定める
  • 双方の貢献を評価できる基準の設定:
    • 圧縮型の貢献は即座に観測可能だが、展開型の貢献は「起きなかった障害」など反事実的である
    • 評価軸として「持続資産」「検知貢献」「育成・伝播」を独立させる
  • 圧縮型の外化スキル獲得:
    • 尊敬する実践者の模倣から始める
    • 自己像との衝突を超える必要があり、「能力拡張」という認識が重要
  • 展開型の効率化:
    • 「圧縮を強いる」のではなく、外化のI/Oコストを下げることが効果的
    • テンプレート整備、検索性向上、参照のボトルネック解消など
  • フェーズごとの期待値変更:
    • 初期: 圧縮型的な素早さが優先される
    • 成長期: 設計可視化が重視される
    • スケール期: 構造の安定性が重視される
    • チームの行動規範や評価軸をフェーズに応じて更新する

■ 9. AI時代の展望と教育への示唆

  • AIは「究極の圧縮型」として位置づけられる:
    • 圧縮型の強み(広域スキャン、論理的探索)で圧縮型の作業を完全に代替する
    • 展開型の作業面での強み(文書作成、可視化)も大部分代替する
    • 両者に共通で残るのは「何を問うべきかの組み立て」という判断力
  • AIの普及により、形式化された問題解決能力の価値が相対的に低下し、曖昧な要件から本質を見極める力がより重視される
  • 従来の学校教育は圧縮と外化の両方を訓練してきたが、プログラミング教育偏重やAI教育偏重ではこの基盤が失われる可能性がある
  • AIを使いこなすには、AIなしで考える能力が前提になる

■ 10. 結論

  • 圧縮型は本質を見出す力を持ち、展開型は歪みを見出す力を持つ
  • この二つが補完関係にあることを理解することが、チームの認知能力を最大化する第一歩である

論評:

■ 1. 概要

  • 本記事はエンジニア間の「すれ違い」を「圧縮型(Internalizer)」と「展開型(Externalizer)」の二類型で説明するモデルを提示する
  • 著者の数十年にわたる個人的観察に基づく
  • 著者自身が「科学的に証明された理論ではない」と明示しているが、その後の論述は留保と整合しない強度の主張を多数含む

■ 2. 論理構造の一貫性

  • 二分法の採用と放棄の混在:
    • 「スペクトラムであり0か1ではない」と断りつつ、両者をほぼ固定的な類型として扱い続ける
    • 「展開型はワーキングメモリを物理的に増やせない」という非対称な主張はスペクトラムモデルと相性が悪い
    • どちらの前提で議論しているかが揺れており、都合に応じて使い分けられている
  • 圧縮型の定義における循環論法:
    • 「圧縮型は先天的に大きなワーキングメモリを持っていることが多い」という主張の根拠が不明
    • ワーキングメモリの大きさを観察する方法が「圧縮型的な行動をとる」ことであり、説明が循環している
  • 結論が前提を証明していない:
    • 設計原則への忌避反応という「症状」から認知戦略の差異という「原因」を推論している
    • 同じ症状を説明できる他の原因(訓練不足、組織文化、インセンティブ構造、経験領域の偏り)への検討がほぼない

■ 3. 主張の妥当性・実証性

  • 「ワーキングメモリ」の使い方が認知科学と乖離:
    • 成人のワーキングメモリ容量は概ね4チャンク前後(Cowan 2001)という制約がある
    • 記事はこれを「圧縮型は先天的に大きい」「展開型は小さい」として個人差を本モデルの基軸に据えるが、根拠が薄弱
    • チェス熟練者の研究(Chase & Simon 1973)への言及はチャンク化による圧縮の説明であり、ワーキングメモリ容量の個人差の証拠にはならない
  • 訓練非対称性の主張が強すぎる:
    • 「圧縮型が展開スキルを獲得することは比較的容易、展開型がワーキングメモリを増やすのは困難」という主張は一方向的に過ぎる
    • 展開型もチャンクの品質を高めることで処理できる情報量を増やせる
    • 圧縮型の外化習慣化の困難さは「比較的容易」と言えない程度の摩擦がある
  • 「35歳定年説」の再解釈が投機的:
    • 「加齢による能力低下ではなく認知戦略の不適合が原因」という仮説に対し、他の説明(市場変化、給与水準の上昇、家庭責任、技術スタックのシフト)を退ける根拠がない
    • 著者の信念の表明であって論証ではない

■ 4. 設計原則についての主張

  • 「設計原則(関心の分離・SRP等)は展開型の認知を前提としている」という着眼はユニークで一定の説得力がある
  • 「設計原則 = 展開型のための道具」と断定することの問題:
    • 設計原則が生まれた背景にはテスタビリティ、保守性、チームスケール、変更容易性など複数の動機がある
    • 「展開型認知への適合」は後付けで接続できる説明の一つに過ぎない
    • 因果の方向が逆の可能性(展開型の思考法と親和性が高いから好む)も検討されていない
  • 展開型が設計原則に「溺れる」リスク(過剰なマイクロサービス化など)への言及は公正

■ 5. AI論の妥当性

  • 「AIは究極の圧縮型」という比喩の問題:
    • AIにワーキングメモリという概念は当てはまらない
    • LLMのコンテキストウィンドウや推論機構は人間の作業記憶とは全く異なる仕組み
    • 比喩を事実として使用する論理的誤謬がある
  • AI代替についての主張:
    • 「圧縮型の作業はほぼ完全に代替され、展開型の作業的強みも大部分代替される」という主張は現時点のAI能力の過大評価と将来についての根拠のない断言が混在している
  • 「残るのは問いの組み立てと判断力」という結論は本記事のフレームワークから導出されたものではなく、既存の言説に乗っかっている

■ 6. 実践的有用性

  • 有用な提案:
    • 「冗長度(外化水準)を成果物ごとにチームで明示的に合意する」という提案は具体的かつ実行可能
    • 「圧縮型の遅さを叱るのではなく外化I/Oコストを下げる」という発想の転換は有用
    • フェーズ別の期待値変更(初期は速度優先、成長期は可視化重視)は実務的に正しい観察
  • 問題点:
    • 圧縮型が外化スキルを獲得するための具体的な方法が「尊敬する実践者を模倣する」という程度に留まっており、最も重要な部分が最も薄い

■ 7. 総合評価と総括

  • 総合評価(2.4/5):
    • 論理構造の一貫性: 2/5
    • 主張の妥当性・実証性: 2/5
    • 設計原則論の妥当性: 3/5
    • AI論の妥当性: 1.5/5
    • 実践的有用性: 3.5/5
  • 最大の問題は「科学的証明はない」という免責と、科学的に証明されたかのような強度で行われる主張の間の矛盾:
    • 「ワーキングメモリ容量の先天的差異」「訓練可能性の非対称性」「AIが圧縮型の仕事をほぼ完全代替する」はいずれも免責文言と整合しない断定の強さで語られている
  • 個人観察を経由した仮説に神経科学・認知科学・AI論を接合することで疑似的な権威付けを行っており、接合部の論理が弱い
  • エンジニア間のすれ違いを「性格ではなく構造」として再解釈しようとする動機と方向性自体は評価できる
  • 「ワーキングメモリ容量の先天的差異」を持ち出すことは「性格の問題」を「脳の問題」に置き換えているだけであり、本質主義の罠に落ちている可能性がある