ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
エンジニア同士の設計観、レビュー観、ドキュメント観のすれ違いを、能力や性格ではなく「情報をどう保持するか」という認知戦略の違いとして捉える記事。 著者は、頭の中で情報を圧縮して扱う「圧縮型」と、文書・図・ログなどへ外化して扱う「展開型」というモデルで、チーム内の摩擦を説明している。 設計原則やドキュメントを嫌う人を単純に低品質志向と見るのではなく、その人にとって外化が認知コストや速度低下として感じられている可能性を示している。 チーム設計では、どちらかを正解にするのではなく、両方の検出能力を活かす仕組みが必要になる。
本文¶
この記事は、コードレビューで真逆の指摘が出る、設計議論で「すぐ作る派」と「全体像を固める派」に分かれる、ドキュメントを書く人と書かない人が固定される、といった現場の反復的な摩擦を起点にしている。
中心概念は「保持」と「外化」。 保持は、必要な情報をワーキングメモリに載せて高速に扱うこと。 外化は、文書、図、コメント、ログ、既存コードへの参照など、頭の外に情報を置いて扱うこと。 著者は、保持に強く寄る傾向を「圧縮型」、外化に強く寄る傾向を「展開型」と呼ぶ。
圧縮型は、短い識別子、CLI、まず動かしてから整える進め方、少ないコメント、素早い判断に寄りやすい。 これは乱暴さではなく、情報を脳内に収めるためにノイズを削る戦略として説明される。 一方、展開型は、説明的な識別子、図、文書、ログ、全体像を描いてから実装する進め方に寄りやすい。 これは慎重すぎるのではなく、ワーキングメモリを超える情報量を外部メディアに分散させる戦略として説明される。
重要なのは、曖昧さへの反応の差。 圧縮型にとって未確定な情報は圧縮しづらく、頭の中に高コストで残るため、早く確定・棄却したくなる。 展開型は未確定な論点を「要確認」として外に置けるため、曖昧さを長く保持しやすい。 この違いが、根拠が言語化されていない違和感をめぐる衝突につながる。
エラー発見にも非対称性がある。 圧縮型はコードベースを頭の中で広くスキャンし、実装レベルのバグや既知パターンの問題を見つけやすい。 展開型は構造を外に広げて見るため、依存の偏り、粒度の不均一、設計思想の不整合、将来の保守性低下につながる歪みを検出しやすい。 チームには両方の視点が必要になる。
この記事の実務的な読みどころは、設計原則やドキュメントへの反応を「意識が低い」「神経質」といった人格評価に落とさない点にある。 個人の態度に見えるものの背後に、情報処理の得意不得意とコスト構造があると仮定すると、レビュー、設計会議、ドキュメントルールの作り方が変わる。
要点¶
- 設計原則や文書化への好き嫌いは、能力差ではなく認知戦略の差として説明できる場合がある。
- 圧縮型は情報を頭の中で圧縮して速く扱うが、曖昧さや外化にコストを感じやすい。
- 展開型は情報を外部に置いて構造を見るが、作業速度が遅く見えやすい。
- 圧縮型は実装上の論理探索、展開型は構造上の歪み検出に強みを持つ。
- チーム運営では、どちらか一方を矯正するより、レビューや設計プロセスで両方の観点を明示的に使う方がよい。