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

エンジニアの認知戦略はなぜすれ違うのか

ソフトウェアエンジニアとして業界に長くいると、現場や SNS 上でのエンジニアどうしの「すれ違い」を何度も目にします。技術力の優劣ではない、性格や趣味嗜好の問題とも少し違う、なのにこの「すれ違い」は、驚くほど普遍的に業界内に存在しています。

この記事では、わたしがそのような「すれ違い」を何十年も観測し続けた末にたどり着いた一つの認知モデルに基づく見解です。科学的に証明された理論ではありません。しかし、この視点を持つだけで、日常の摩擦の見え方がかなり変わるはずです。

チーム内での症状

チェックリスト: あなたのチームで以下の状況を見たことはありますか?

• コードレビューで同じ PR に真逆の指摘が出る。
• 設計について、すぐ手を動かしたい派と全体像を合意してから着手したい派で割れる。
• 「なぜこうしたか」は誰かの頭の中にあり、その「誰か」を探す必要がある。
• 文書化のルールを作っても、書く人とあまり書かない人が固定される。
• 同じタスクでも、かかる時間と成果物のスタイルがメンバーによって大きく異なる
• チームを移動した人が、そちらでは必要不可欠なメンバーになった。
• 技術力は高いのに第三者への説明となると苦手な人がいる。
• コードを読めば分かることをわざわざコメントで説明されている。
• 「違和感」ベースの指摘と「根拠」ベースの指摘がかみ合わない。

3 つ以上のチェックが付いたなら、おそらくこの記事は役に立ちます。

これらの症状を、わたしたちは「趣味の違い」「感覚の違い」として長年流してきました。しかし、これらは驚くほど規則的に、同じパターンで繰り返されています。趣味の範囲と断じるにしては再現性が高すぎます。

帰属が間違っているかもしれない

こうした摩擦に直面したとき、わたしたちは原因を以下の表の真ん中の列のように考えがちです。しかしどれも実際の構造は違っていて、的外れな帰属を示しています。

症状	よくある誤帰属	実際の構造
ドキュメントを書かない	怠慢、意識が低い	本人の認知の中で文書化に価値を感じる回路がない
作業が遅い	スキル不足	目に見えない工程 (可視化、文脈記録) に時間を投資している
説明やプレゼンが下手	コミュニケーション能力が低い	知識の再構成プロセスが認知として機能しにくい
設計の議論が終わらない	優柔不断	構造を完成させてから進みたい認知欲求がある
設計原則を無視する	勉強不足、経験不足	全体が頭に入っているので分割の必要を感じない
過剰に設計を作り込む	神経質、凝り性	誰でも分割認知可能な構造を作っている

いくつか例を見てみましょう。

「ドキュメントを書かない人」は、怠けているのではなく、本人の頭の中ではすべてが繋がっているので、それをわざわざ別の形式に書き直す行為に「本気で」価値を感じていない。わたしたちが歩行について「片足を上げている間は、もう片方の地面に足を付けていないと転ぶ」という説明をわざわざ求められるのに近い感覚かもしれません。

「作業が遅い人」は、能力が低いのでなく、全体像を把握し、構造を可視化し、将来の参加者を想定した成果物を作るという、外から見えない工程に時間を使っています。これらの工程を除けば確かに早くはなりますが、それは品質の定義を変えることになります。

「プレゼンが下手な人」のケースは、コミュニケーション能力が欠如しているわけではなく、一対一であれば極めて明晰な技術議論ができます。問題は、自分の知識を相手のレベルに合わせて再構成するプロセスが、その人の認知の仕組みでは発動しにくいということです。

お気づきでしょうか? 上の表では、構造の問題を個人の態度に帰着させています。これはよくある帰属バイアスです。

もしこの摩擦の原因が、個人の意識やスキルではなく、もっと根底にある認知の仕組みの違いだとしたらどうでしょう。必要な対処は、近視の人に「もっとよく見ろ」と言うのではなく、正しいレンズを与えることです。

診断

レンズを合わせる ─ 情報の保持と外化

先ほどの摩擦のほとんどは、それぞれの情報の持ち方の違いから生じています。

わたしたちエンジニアは、日々大量の情報や知識を扱っています。仕様、設計判断、コードの構造、過去の障害、チームの文脈 —— これらをどう処理しているかを分解すると、とてもシンプルな構造になります。

1. 分割 (チャンク化). 膨大な情報や知識を、本人が扱える大きさの塊に分けます。実際は、ここに情報分類や階層化などの構造化作業が入りますが、この記事では省略します。
2. 圧縮. 分割した塊を、自分が処理しやすい形にエンコードします。これはノイズ除去、自明な情報の排除、無関係な情報の削除、パターン化、抽象化、既知のモデルへのマッピングなどです。
3. 記録.
   1. 保持. すぐに必要な情報は、脳のワーキングメモリに格納します。高速にスキャンでき、取り出しも速いですが、ただし容量に限りがあります。
   2. 外化. すぐに必要のない情報や、一度整理が必要な情報、不確定要素の多い情報は、自分の外側に配置します。これは、既存の文書やコードベースの参照先を覚えておくか、自分で文章に書く、図を描く、コメントに残す、といったことを行います。取り出しには一手間かかりますが、容量はほぼ無限です。

「保持」と「外化」の二つの手段は誰もが使っています。しかし、どちらに比重を置くかが人によって大きく異なります。そしてこの比重の違いが、冒頭で挙げたすれ違いのほぼすべてを説明します。

この記事では、保持に比重を置く人を圧縮型 (Internalizer) と呼び、外化に比重を置く人を展開型 (Externalizer) と呼びます。それらの特徴の違いを見てみましょう。

二つの傾向を比較する

この 2 つの傾向について、自分自身はどちら寄りか考えながら読んでみてください。

場面	圧縮型	展開型
好みの作業環境	CLI、ターミナル、ショートカット多用	IDE、GUI、情報の一覧性
コードの書き方	識別子は短く、記号的	識別子は長く、説明的
開発の進め方	まず動かしてから整える	まず全体を描いてから実装する
ドキュメント	現状説明のみで背景や文脈が不足	図で全体を示し、文で文脈を補う
コメント	書かない、コードを読めば分かる	こまめに残す
ログ	入れない、デバッガを使えばいい	手厚く仕込む
新しい技術の理解	速い、既知の概念に接続	遅い、全体構造の中の位置を探る
判断の仕方	素早く確定する	情報が揃うまで保留する
問題認識のスコープ	局所的、短期的	大局的、長期的
言語の親和性	C, Perl, Go	Java, Swift, SQL

これは対比を強調するために過度なステレオタイプになるように振った選択肢ですので、どちらかに完全に当てはまる人は稀です。多くの人は「だいたいこっち寄り」という比重の問題ですし、また場面によって使い分けている人も少なくないと思います。圧縮型と展開型の対比は 0 か 1 かの分類ではなく、スペクトラム上の位置です。

私自身は二十代の頃は圧縮傾向でしたが、キャリアの途中で意識的に展開を伸ばし始めた経緯があります。長年両方の側からの「すれ違い」を経験し、その認知構造の解体をして、圧縮/展開という異なる傾向から派生する特徴の違いがあるなと感じてまとめたのが、この記事になります。

では、なぜこの比重の違いがチームで摩擦を生むのでしょうか? 次のセクションでは、その原理を掘り下げます。

なぜこの違いが生まれるのか

圧縮型と展開型の違いは、好みやスタイルの問題ではありません。もっと根底にある認知コストの違いから生まれます。

二つの戦略の根源

圧縮型は、速い判断と手数を重視した認知戦略をとっています。圧縮型を獲得する人は先天的に大きなワーキングメモリ (記憶力) を持っていることが多く、その優位性をさらに高めるために、なるべく多くの情報を脳内に収めようと努めて情報や知識に対する圧縮効率を重視します。その過程で、自分に明白/無関係な文脈、コメント、ログ、果ては識別子まで、無駄なノイズとしてとことん削ぎ落とします。一方で、目に入る情報を高度に抽象化し、非常にコンパクトで核心的な本質を抜き出すよう意識的に訓練します。これらは圧縮効率を最大化する戦略の必然的な帰結です。さらに、外化という行為そのものに対しても「速度を落とすもの」という潜在的な抵抗感を持っています。

一方、展開型は、自身のワーキングメモリを超える情報量に耐え得る認知戦略をとっています。ワーキングメモリに収まらない情報は、無理に圧縮せずに分割して外部メディアに配置します。安価でほぼ無限の容量が使えるので圧縮への強い動機を持たず、むしろ文脈や意図を残す方の価値を重視します。図を描き、文章を書き、ログやコメントを残し、構造を可視化する。ワーキングメモリには「今まさに考えている部分」だけを載せ、残りは必要なときに参照します。この戦略の帰結として作業は遅くなります。しかし、書き出されたものはそのまま他者との共有インターフェースとなってチームに残ります。作業が遅いのは能力の問題ではなく認知の範囲を外部に拡張する戦略コストです。

どちらの戦略も限られたワーキングメモリという同じ制約に対する、異なる最適化の方向です。圧縮型は「容量内に収めるために少しの入力も削りたい」、展開型は「容量の外となる場所に入力を残したい」。同じ問題に対する、それぞれの戦略の合理的な解です。

曖昧さの保持コスト

圧縮型と展開型の違いが最も顕著に現われるのはまだ確定していない情報への反応です。

圧縮とは、情報を確定させて効率的にエンコードする行為です。しかし、未確定の情報は圧縮できません。曖昧な情報を抱えている間、圧縮型はそれをワーキングメモリに「非圧縮で」置いておくしかありません。脳のワーキングメモリは容量が限られた高コスト資源ですから、有用かどうか分からないもの、いつ解決するか分からないものにこの領域を占有されるのは認知的な息苦しさを強く感じます。

圧縮型は曖昧さを早く消し去りたいと考え、仮説を立ててすぐ検証したい欲求に駆られます。曖昧さの排除を強く訴え、とりあえず動かし、議論を早く結論に持って行く、といった振る舞いはすべて、曖昧で圧縮不可能な情報を早くワーキングメモリから追い出したい欲求からの合理的な行動です。

一方、展開型は曖昧な情報を「？」付きで外部に置いてワーキングメモリを空けることができます。これは、全体図の中に空白のボックスを描き、赤ペンで「要確認」と矢印を書いておくだけです。外部メディアの容量はほぼ無限ですから保持コストは低く済みます。

展開型は曖昧さを比較的多く長く保持できます。判断に必要な情報が揃うのを待てる、「どうも引っかかるが、今時点ではなんとも言えない」という状態を抱えたまま続けられるという特性を持ちます。「？」が増えすぎると全体像が霧散してしまいますが、それでも頭の中だけで抱えるよりはるかに多くの未確定要素を長期間保持できます。

	圧縮型	展開型
曖昧な情報の置き場	ワーキングメモリ (高コスト)	外部メディア (低コスト)
曖昧さへの反応	素早く確定/棄却判断、または拒絶	受容、保持
判断のタイミング	少ない情報でも素早く	情報が揃うまで待つ
リスク	早すぎる確定 (過学習)	遅すぎる確定 (機会損失)
ネガティブケイパビリティ	低い	高い

見ての通り、これは性格の問題ではありませんし、忍耐力の問題でもありません。情報の置き場のコストが違うだけです。

この構造は統計学における頻度主義とベイズ主義の挙動にも似ているように感じます。手元のデータからただ一つの最尤推定値を確定させるか、事前分布を保持したまま推定値を逐次更新していくかですね。

しかし、このコスト構造の違いが実務では「すれ違い」を生むことがあります。展開型が「何か引っかかるが、まだうまく言えない」という曖昧な懸念を圧縮型に持ち込んだとき、圧縮型はそれを即座に棄却しがちです。言語化できない = 根拠がない = 問題ではない、という判定が瞬時に働くからです。そして、棄却された懸念が後に実際の問題として顕在化したとき、それは「すれ違い」ではなく「事前に気付いた問題を見逃した」という組織構造上の問題になります。

このすれ違いでさらに厄介なのは、事後にも認識が一致しないことです。展開型は「何か良くなさそうなことは検知していたのに」と後悔しますが、圧縮型は「言語化されていなかったのだから、見逃されるべくして見逃された問題だ」と切り捨てます。それぞれの認知フレームの中では完全に正しいというのが、認知戦略の違いから生じる摩擦の根深い部分です。

エラー発見プロセスの非対称性

この認知の違いが実務で現われやすいもう一つの例は、エラーの発見プロセスです。一般に、仮説を立てて検証する、デバッガでステップ実行する、ログを grep する、といった論理的探索は職業プログラマ全員の基本スキルです。違いはその先にあります。

	圧縮型	展開型
強み	コード上の論理的探索範囲が広大	構造上の問題検知という別のレイヤーを持つ
なぜ可能か	コードベース全体を圧縮して頭の中に保持しているため	全体像を外部に展開して俯瞰しているため
検出が得意なもの	実装レベルのバグ、エッジケース、既知のパターンの問題	粒度の不均一、依存の偏り、設計思想の一貫性の欠如、また認識されていない問題
典型的な発言	「あのモジュールのあの分岐が怪しい」	「この設計、なんか歪じゃないですか」

展開型が検知する「形の歪さ」は、例えばこういうものです。

• 異なるドメイン概念が一つのクラスやテーブルで共通化されている。
• ある一つのコンポーネントに依存の矢印が集中しすぎている。
• モジュール分割の粒度が不均一で一つだけ妙に大きい。
• レイヤー構造のはずなのに一箇所だけ層を飛び越えた依存がある。
• シーケンス図を描くと一箇所だけ不自然に往復が多い。

こういった凝集、結合、依存、並列性、セキュリティなどに関わるゆがみは個々のコードを一行ずつ読んでも発見しにくい問題です。論理的には正しく動作しているコードでも、構造として見たときに不自然な形状をしている。この違和感が、将来の障害や保守性の低下 (技術負債)、セキュリティ脆弱性を予見していることがあります。

どちらが優れているかではなく検出しやすいものの種類が違います。圧縮型の広域スキャン能力は「今そこにあるバグの原因」を見つけるのに強く、展開型の構造検知能力は「まだ認知されていないが、いずれじわじわと問題になるゆがみ」を見つけるのに強い。チームには両方の観点がないと、どちらかの種類の問題が検出されないまま (検出どころか問題として認知されないまま) 残ります。

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

認知科学には「知識の呪い (curse of knowledge)」という概念があります。ある知識を持ってしまうと、持っていない状態を想像するのが困難になるという現象です。

圧縮型はこの呪いにかかりやすい構造を持っています。知識が高度に圧縮されて個人特化して内部に統合されているため、どのステップで相手がつまずくかを想像しにくい。さらに、圧縮の過程で背景や文脈を「自明なもの」として意識の外へ捨ててしまっている傾向があります。本人にとっては圧縮後の本質情報だけが知識であり、捨てたものはもはや想像力に関与しません。しかし聴衆にとっては、そこにこそ理解の手がかりがあります。圧縮型のプレゼンが「単なる機能説明」になりがちなのはこのためです。

展開型は知識を外部に展開した状態で保持しているため、「想定する聴衆はこの部分を持っていない」を構造的に同定しやすい。加えて、普段から図や文章、さらには本質とは直接関係のない「感想」も気軽に外部に記録しているため、プレゼンの素材がすでに手元にあります。特に感想は、聴衆には公式情報では得られない面白みとして効果的な材料となります。聴衆に合わせたプレゼンができるのは、コミュニケーション能力が高いからではなく、自分の知識構造へのアクセス経路が異なり、表現の道具を日常的に蓄積しているからです。

圧縮型と展開型はどこから来るのか

ここまで読んで「これらは生まれつきの性格だろう」と思った方もいるかもしれません。私の観察はもっと複雑です。

学校教育の大部分は圧縮と外化の両方の訓練プログラムです。私たちは 10 年以上かけてこれらスキルをたたき込まれています。つまり、圧縮と外化のスキルは全員が既に持っています。

ところが、プログラミングの世界に入ると状況が変わります。コードという形式は極めて強力な圧縮表現であり、書くこと自体が思考と成果物を兼ねます。学校で学んだ「ノートに書いて整理する」「図にまとめる」はコード上で仮想的に代替され、あらためて外化することを冗長に感じるようになります。

段階	何が起きるか
学校教育	全員が圧縮と外化の基礎を訓練される (暗記、テスト、ノート、レポート)
プログラミングとの出会い	コードという強力な圧縮表現を知り、一部の人は外化を「不要」と感じ始める
初期の成功体験	圧縮で成功体験を得た人は外化を捨てて行き、外化で成功体験を得た人は維持する
環境の複雑化	圧縮だけでは回らなくなり、かつて捨てた外化を再び拾い上げる

圧縮型は外化を「知らない」のではなく、知っているが圧縮の成功体験によって戦略的に捨てた人、展開型は外化を「新たに獲得した」のではなく、学校で身につけたものを捨てなかった、あるいは一度捨て再び拾い上げた人、と考えることができます。

キャリアの始まりでは、多くの人は学校教育で獲得した圧縮と外化を使って情報に向き合おうとします。これは自然な出発点で、認知戦略と呼べるほどのものではありません。扱う問題の範囲が小さいうちはワーキングメモリだけで間に合うことや、前述の外化不要の疑念により、初期はまず圧縮型寄りの振る舞いを出す傾向があるように思います。

状態	説明
未分化	問題の範囲が小さく、ワーキングメモリだけで間に合っている。教育の延長で外化している人もいて、まだ戦略が確立していない。
圧縮型	先天的なワーキングメモリの大きさを活かし、広範囲を高速に頭の中で処理できるように強い圧縮を獲得したタイプ。
展開型	ワーキングメモリの限界を超える環境に適応するために、外化という戦略を獲得したタイプ。

展開型は圧縮型の「次の段階」にも見えます。ある時点で「環境」の要求が自分のワーキングメモリ容量を超え、外部展開という戦略を取った人は圧縮+展開になりえますし、ごく少数ですがそのようなスーパーマンも見ています。つまり外部展開は自身の圧縮容量を超える環境への変化の中で生き残るための適応戦略です。そしてどちらも後天的な訓練と経験を通じて確立される認知戦略という点が未分化との違いです。

ただし、展開型を再活性化するのにもきっかけが要ります。多くの場合、そのきっかけへは余裕のある自己研鑽ではなく、もっと切実な環境適合クライシス下の生存戦略として訪れます。

きっかけ	例
実務環境の複雑化	責任範囲が広がり、脳の中だけでは回らなくなった。
生活環境の複雑化	家庭を持ち、割り込みタスクが増えてワーキングメモリが揮発しやすくなった。
加齢による記憶力の変化	以前は頭に入っていたものが入りきらなくなり、書き出さざるを得なかった。
優秀な実践者の模倣	尊敬する先輩が図や ADR を書いているのを見て取り入れた。
再活性化しないまま	ワーキングメモリ容量内の環境に留まり続けた、またはアイデンティティ障壁。

アイデンティティ障壁とは、外部展開を自身の美学に反するものとして拒絶する心理です。圧縮型として速い判断と作業で長く成功してきた人にとって、「頭の中だけで全部処理できる」ことは能力の証であると同時に、自己像の核心でもあります。このため「自分の圧縮力では足りない」と認めることは合理的ではなく、美学のレベルで抵抗が生じます。

キャリア初期の成功体験も大きく影響します。ベンチャー企業の流動性が高いシステムで素早くコードを書いて評価された人は圧縮をさらに高め、業務開発企業で資料を「分かりやすい」と評価された人は外化をさらに磨きます。最初のチーム、最初のメンター、最初の成功体験が、この認知戦略の方向を決め、一度決まった方向は確証バイアスで自己強化されて変えにくくなります。

実感として、業界 2～3 年目あたりで「短いコードこそ正義」と「説明力こそ正義」のような極端に振れることがあります (そしてしばしば、不幸な炎上が起きているのを SNS で目にします)。技術的な自己像が固まり始めた頃に、自分の実装哲学を定義するために振り子を大きく揺らしているように見えます。

あなたが今どちらのタイプに見えるかは、本質的な能力と言うより、キャリアの初期条件とその後の生存戦略の産物という要因が大きいと言えます。ただし、ワーキングメモリ容量という制約を除けば。

非対称な訓練可能性

チームリーダーにとって実務的に重要な知見がここにあります。

方向	本質	難易度
圧縮型 → 展開スキル獲得	低コストの外部記憶の使い方を学ぶ	比較的容易。既存の圧縮の領域は失われない
展開型 → 圧縮スキル獲得	ワーキングメモリの容量を増やす	困難。生物学的な制約にぶつかる

圧縮型が展開スキルを獲得することは、純粋な能力の拡張です。従来通り頭の中で圧縮し、切り捨てていた文脈や背景、未確定の情報などを外部に置く、という使い分けが可能になります。脳のハードウェアは何も変わっていないのに、使える記憶域が増える効果があります。

一方、ワーキングメモリ容量は強力な物理制約です。展開型に対して「作業を早くするためにもっとワーキングメモリを増やせ」と言っても改善幅は限られています。

将棋や囲碁、チェスの熟練者は高度な圧縮型です。チェスの古典研究^[1]によれば、熟練者が盤面を記憶できるのは、盤面を対局上の「ある意図」のパターンの塊として圧縮し、認識しているからだそうです (駒をランダムに配置した状態では素人とあまり差がない)。しかし、その巨大な塊を比較して瞬時に手を読むには、巨大なワーキングメモリの存在が前提です。圧縮の技法は訓練できても、同時に操作できる塊の数はハードウェアの制約があります。

設計原則は展開型の認知を前提としている

ここで一つ、興味深い接続があります。

ソフトウェア設計で「良い」とされている「関心の分離」「単一責任原則」「レイヤードアーキテクチャ」「ドメイン分離」といった原則を突き詰めると、システム全体を一度に頭に入れなくて良いように、部分的にワーキングメモリにロード可能な構造を作るという、分割 (チャンク化) のための手法です。

つまり、これらの設計原則は展開型の認知を前提とした設計です。

圧縮型がこれらの原則になじみにくいのは、本人にとっては既に全体が頭に入っているから。全体が見えている人にとって、関心の分離は「余計な分割」に感じられ、インターフェースの抽象化は「不要な間接参照」に見えます。それだけでなく、圧縮型には「限られた圧縮容量にすべてを収めるために、圧縮の邪魔になるものは排除するべき」という暗黙の原則があり、これが設計原則と真正面から衝突します。分割も抽象化も、圧縮型にとっては情報量を増やす行為であり、頭の中の限られた空間を圧迫するものです。

しかしこれらの原則が存在する理由は、書いた本人以外の人間もそのコードに関わるからです。チームの他のメンバー、将来の保守者、新しく参加する人、彼らのワーキングメモリ容量を前提とした設計であり、チームで開発する以上、避けて通れないものです。

一方で、展開型がこれらの原則に溺れるリスクも指摘しておくべきでしょう。部分ロード可能な構造を作れるようになると、分割や細分化が止められなくなる病気にだれもが一度はかかります (先ほどの 2-3 年目問題など)。少し前にトレンドだった過剰なマイクロサービス化の弊害議論はその典型例です。DDD におけるドメインモデル貧血症も関心の分離を過剰に適用した結果と見ることができます。

タイプの相対性

最後に、重要な補足があります。圧縮型/展開型は、個人に貼る固定的なラベルではありません。環境との相対的な位置です。

ある人が、圧縮型ばかりのチームでは展開型として評価され、展開型のチームの中では圧縮型として評価されることがあります。前のチームでは「設計原則をうまく使う人」だった人が、次のチームでは「アウトプットの速い人」と言われる。本人は変わっていません。変わったのは周囲の基準です。

環境だけでなく経験も影響します。経験を積むにつれて、場面に応じて両方の戦略を使い分けるメタ認知能力を獲得する人もいます。障害の初期対応では圧縮型として素早く動き、設計やセキュリティのレビューでは展開型として構造を見せる。こうした「認知戦略のスイッチ」ができるようになるのが、認知戦略そのものの成熟です。

違いを理解した上で、どうするか

ここまで読んだあなたは、恐らく自分がどちら寄りかを既に自覚しているはずです。そして、チームの中のすれ違いにも、以前とは違う解像度で見られるようになっているかもしれません。

自分のタイプを知り、相手の行動を認知戦略の違いとして翻訳できること。これが出発点です。その上で、摩擦を解消するためにチームとして具体的に何ができるか考えましょう。

冗長度の合意を明示的にする

チームの実践として最も効果が高いのは何をどこまで外化するかをチームで明示的に合意することです。「ちゃんと責務を分けろ」も「自明なものを書くな」も解決策にはなりません。どちらも片方の認知戦略をもう一方に強制しようとしているだけです。必要なのは、成果物の種類ごとに外化の水準を決めることです。例えば以下のような合意です。

成果物	合意の例
設計判断	ADR (Architecture Decision Record) として必ず残す。なぜこの構成にしたか、却下した代替案は何か。
運用手順	ランブック化する。オンコール担当がその場で参照できる形に。
コードコメント	「なぜ」に限定する。「何を」「どうやって」はコードで自明であれば書かない。
障害ポストモーテム	時系列・根本原因・再発防止の型を守る。
日常の実装の進め方	各自の認知戦略に委ねる。

この合意があれば、展開型も圧縮型も「ここは自分のやり方で進めて良いが、別のところでは相手の意図を汲もう / 認知戦略をスイッチしよう」と安心できます。

双方の貢献を評価できる基準を作る

冗長度を合意しても、評価軸が偏ったままだと効果は限定的です。よくある「チケット消化数」のような評価指標は、圧縮型の貢献だけが可視化され、展開型の貢献は見えないままになります。しかし、これは評価者の怠慢ではなく、観測可能性の非対称性がもたらす自然な帰結です。両者の貢献は観測のしやすさが構造的に違います。

観測の性質	圧縮型寄りの貢献軸	展開型寄りの貢献軸
形式	アウトプット型 (動くコード、修正の速さ)	ストック型 (ドキュメント、構造、ADR)
効果観測タイミング	即時	遅延 (数ヶ月〜数年後)
局所性	局所的	分散的 (他者経由)
帰属の明確さ	明確 (誰の成果か明らか)	拡散 (円滑なオンボーディング、問題の未然防止、などは個人成果に紐付けにくい)
顕在化の条件	起きたこと	起きなかったこと

特に最後の行が決定的です。展開型の貢献の多くは「起きなかった障害」「短縮されたキャッチアップ時間」「事前に潰された技術負債」という反事実的な成果として現われます。起きなかった事象は、定義上、観測しにくく評価しにくい。組織が意識して計上しなければ貢献は「ない」ことになります。

組織に必要な貢献はチームに機能するどんな価値が生まれたかです。その観点で、それぞれのタイプが持つ強みがより性格に評価される評価軸の例を考えてみましょう。

評価軸	観測されるもの	主に発揮されやすいタイプ
即時成果	リリース完了、バグの収束速度、局所診断の的中	圧縮型寄り
広域探索	コードベース全域を踏まえた的確な変更、根本原因の特定	圧縮型寄り
持続資産	ADR、設計ドキュメント、ランブック、テスト資産	展開型寄り
検知貢献	未然防止された障害、構造的弱さの早期発信	展開型寄り
育成・伝播	レビューコメントの教育的価値、後任の立ち上がり速度	展開型寄り

各軸はタイプではなく行為に紐付くので、同じ人が複数の軸で評価され得ます。さらに「持続資産」や「検知貢献」を独立軸として立てることで、反事実的な貢献を観測可能な対象に変換します。例えばポストモーテムに「事前に検知されていた懸念」の欄を作る、設計レビューで回避された問題を四半期で棚卸しする、オンボーディングで「どの資料が役に立ったか」を聞く、といった観測記録です。記録がなければ「あの人が前に懸念していたが拾われなかった」という記憶は組織から消えていきます。逆に圧縮型の貢献も、単なる「タスク完了数」ではなく「広域探索の的中率」「根本原因の特定速度」として再記述すると、圧縮の認知戦略が持つ強みがより正確に評価されます。

ただし、各評価軸の重み付けは固定的ではありません。チームに求められる振る舞いの重心は、フェーズや事業の盛衰の時々で移動し、リーダーは評価軸の重みをそれに連動させる必要があります。ここで気をつけるべきは評価軸そのものにも慣性が働くことです。初期の評価軸の頂点にいた人にとって、重みの変更は自身の相対的価値の低下を意味するため、心理的な抵抗が生じます。個人のアイデンティティ障壁の組織版です。評価軸の妥当性そのものをレビューする上位のサイクルがないと、フェーズが進んでも評価軸が動かず、今の組織に本当に必要な貢献が静かに失われます。

最後に、もう一つ重要な補足。評価軸を設計するリーダー自身が圧縮型なら、展開型の貢献を構造的に過小評価しやすく、逆も同様です。人は無自覚に、自分の認知戦略に親和的な軸を重く、そうでない軸を軽く設定する傾向を持ちます。評価軸の設計を一人で完結させるのではなく異なる認知タイプの観点を意図的に組み入れることが、評価の歪みを抑える実務的な対処法です。

圧縮型が外化スキルを獲得するには

機序のセクションで述べた通り、圧縮型が展開型スキルを獲得することは純粋な能力の拡張です。既存の圧縮力は失われず、新しい記憶域が追加されます。しかし「価値がある」と分かっていても、習慣にならなければ意味がありません。ドラッカー^[2]の言葉を借りれば、後天的な能力の習得は習慣によってのみ身につきます。

しかし外化の習慣化には、その手前に超えるべき心理的ハードルが一つあります。

身につけると良いとは分かっていても、ごちゃごちゃ書くことに時間を割くのは、自分の性格や価値観とは合わないんだよなぁ…

圧縮型として成功してきた人にとって「頭の中だけで高速に完結する状況を作ること」は自分の強みの証であり、自己像の一部です。外化を習慣化する試みは、まずその自己像と衝突します。しかし、外化の習慣化にはどうしてもその認識を更新して乗り越える必要が生じます。外化は、圧縮できないから仕方なくやる代替手段ではなく、圧縮力を保ったままさらに使える記憶域を増やすことという認識が重要です。

そして、思い出してください。学校教育で何年もかけて訓練されたスキルが、本人の中に眠っています。「昔やっていたことをプログラミングの文脈で思い出す」だけとも言えるので、ハードルは思っているより低い。

この認識の更新が起きないまま「そういう環境に置いて身につけよう/身につけさせよう」という OJT 的な需要だけ作っても、ストレスが増えるだけでうまくいきません。

実際のところ、外化を習慣化できる要因は人それぞれなので、ここで定石を示すのはなかなか難しいところです。例えば、展開スキルをうまく使う「尊敬する実践者」の模倣から始まることが多いというのは一つのやり方でしょう。社内や業界に神的な展開スキルを実践している人がいれば、その人の発想や着眼点をまねすること自体が最良の訓練になります。

展開型の「遅さ」への対処

より難しいのは展開型です。脳というハードウェア制約を緩和することは難しい。となればもう一つのパラメータである圧縮率を高くして、より多くの情報や知識をワーキングメモリに載せられるのではないでしょうか?

• 目や耳からの入力情報を超高～超低の解像度で抽象化/具象化し「何が本質か」を見抜く。
• それらを集めて、自分のワーキングメモリに収まる「ある意味のある塊」を見出す。

自分なりに意識してやってみる価値はありますが^[3]、既に容量を超える環境への適応戦略に入っているケースではあまり大きな効果は期待できません。

展開型を速くしたいなら、圧縮を強いるのではなく、展開のボトルネックを解消する方向に向かうほうが効果が見込めます。

ボトルネック	内容	改善アプローチ
外化速度	外部に書き出す行為自体に時間がかかる	テンプレート、ツールの整備で時間コストを下げる。
コンテキストスイッチのコスト	「今の作業を続けるか、外部を参照するか」の判断に迷う	外部資料のインデックスを整理、15分詰まったら外部参照ルール、など。
インデックス性能	目的の情報を探すのに時間がかかる	検索可能化。置き場の統一。目次や付箋、マーカーの色など。
ロード速度	外部に置いた情報をワーキングメモリ読み戻すのに時間がかかる	図やドキュメント構造を一覧性の高い形式に統一する。探さなくても目に入る配置。壁に貼る。

展開型を速くしたいなら、圧縮を強いるのではなく、展開の I/O コストを下げる。この発想の転換が効果的です。

フェーズで期待される振る舞いは変わる

チームの認知構成には「常にこれが正解」はありません。プロダクトのフェーズによって、チームに求められる振る舞いの重心が変化します。

フェーズ	重視される振る舞い	理由
初期 (立ち上げ・MVP)	速い判断、高速な実装、最小限の合意	スピードが生存条件。少人数で素早く形にする必要がある。設計の完璧さより市場検証が優先。
中期 (成長・スケール)	設計の可視化、オンボーディング整備、暗黙知の外化、コンプラ対応	チームが拡大し、暗黙知だけでは回らなくなる。
運用保守 (成熟期)	設計経緯の文書化、運用手順の整備、構造レビュー	人が入れ替わっても動き続ける仕組みが品質を決める。

初期で圧縮型の振る舞いで成功したチームが、成長期に入っても同じ振る舞いを続けると、事業のスケールが困難になります。フェーズが進むにつれて、チーム全体で展開型の振る舞いの比重を意識的に上げて行く必要があります。これは個人の性格を変えることではなく、チームとしての行動規範や、前述の冗長化の合意や評価軸の重みを更新することです。

人材としての認知タイプ

人材の観点も触れておきます。ただし、ここは単純な二分法が通じない領域です。多くのジュニアエンジニアは、まだ戦略を持っていない未分化の状態です。扱う問題の範囲が小さく、ワーキングメモリで間に合っているだけなので認知戦略が確立していません。

	未分化	圧縮型	展開型
人材プール	広い (全員ここから)	狭い (資質 + 訓練が必要)	狭い (経験 + 獲得が必要)
従来の採用手法	コーディングテストで計りやすい	実績と面談でしか見極められない	従来の手法では計りにくい
離脱時のリスク	低い	暗黙知の大量消失	外化された資産が残る
育成の方向	どちらにも分化しうる	展開スキルの追加で能力拡大	外化の効率化で速度改善

注意すべきは「育成の方向」です。未分化のメンバーはどちらにも育ち得ます。前述の通り、最初に何を褒めるか、どんな先輩に付けるかがその認知戦略の方向を左右します。ただし、未分化の全員がどちらかの戦略を確立できるわけではありません。圧縮型になるにはワーキングメモリの資質と訓練が要り、展開型になるには外化の獲得機会と受容が要る。どちらも獲得しないまま、責務だけが拡大していくケースも暗数として存在します。

かつて語られた「35歳プログラマ定年説」の一因は、加齢による能力低下というより、認知戦略が環境に対してスケールしなかったことにあるのかもしれません。二十代は扱う範囲が小さくワーキングメモリだけで回っていたものが、三十代で責務が拡大して扱う情報が容量を超え始める。このとき外化戦略を獲得できた人はスケールしますが、獲得できなかった人は以前と同じやり方では回せなくなる、ということです。

圧縮型の人材は素質の延長線上にいるので、キャリアの序盤から頭角を現している傾向があります。ただし「二十代特有の体力と過集中」に頼った圧縮型の場合、加齢による記憶力と集中力の低下で適合クライシスと自己像クライシスが同時に訪れるリスクがあります。一方で展開型の人材は、さらなるステップアップとして外化を獲得するため、キャリア中盤以降に多い傾向があります。どちらもコーディングテストでは見つけにくく、必要になってから探し始めると遅い。フェーズの先を見据えた人材計画が重要です。

これから何が変わるのか

AI という「外化に長けた究極の圧縮型」がチームに加わる

AI がコードを読み、書き、デバッグする時代が既に来ています。この変化を圧縮型/展開型のモデルで見ると、興味深く少し苦い構図が浮かびます。

まず、AI は究極の圧縮型です。コードベース全体を瞬時にロードし、広域をスキャンして論理的なエラーを検出し、ドキュメントが不足していても大まかな文脈を把握する、巨大なワーキングメモリを持つ圧縮型。人間には到達できない領域です。

同時に、AI は外化にも長けています。簡単なプロンプトだけで読み手に合わせたドキュメントを生成し、議事録や ADR から文脈や設計の経緯を整理し、状況に適切なコメントやログを残せます。つまり AI は圧縮型の強みを持ちながら、展開型の作業的な強みも兼ね備えています。

正直に整理すると、こうなります。

能力	元の担い手	AI による代替
広域のコード探索・実装	圧縮型	ほぼ完全に代替される
設計の言語化・文脈の整理・文書作成	展開型	大部分が代替される

では、人間に残されたものは何か。

能力	元の担い手	なぜ AI には難しいか
何を問うべきかの組み立て	両方	前提を問う批判的思考が必要
具体的に何を作るべきかの判断	圧縮型	市場・組織・ユーザの暗黙知が必要
何を誰のために外化すべきかの判断	展開型	チーム構成と将来の変化の予測が必要
非自明な文脈・暗黙知の検出	展開型	コードベースからは読み取れない、判断背景や暗黙の前提を検出するには人間の文脈理解が必要
構造的なゆがみの判断	展開型	論理的正しさとは別の、構造としての違和感

圧縮型の作業面での強みはほぼ食われます。そして、AI が圧縮型の弱み (外化しない) を補完してくれるため、圧縮型が AI を使えば展開型の作業的な価値の多くも代替できてしまう。展開型にとっても、作業面の強みの多くが食われます。ただし、展開型が日常的に外化している成果物は、他者とのインターフェースとなると同時に、そのまま AI への有用な入力資産にもなります。「遅さ」のコストを払って蓄積してきた外部資産は、AI 時代には別の形で価値を持ちます。

両タイプに共通するのは、残るのは作業ではなく判断、そしてさらにその上流にある「問いの組み立て」 です。

AI は与えられた問いに対して高品質の答えを返します。しかし「我々は何をしたいのか」「そもそもこれは正しい問いか」「この問題の裏に別の問題が隠れていないか」「前提として疑うべきことは何か」といった問いそのものを構成する能力は、哲学や批判的思考の領域であり、人間の側に残ります。

コーディングテストの動揺

この変化を象徴的に示しているのが、プログラミングコンテストやコーディングテストの動揺です。

制限時間内に、外部参照なしで、明確に定義された問題を解く。この形式は圧縮型の能力を測定する装置でした。AI がこの種のテストを人間以上にこなせるようになったことで、このテストが測定していたのは人間固有の能力ではなく、計算機で代替可能な能力だったことが露呈しました。

「では何を測定すべきか」この問いへの答えは、恐らく両タイプに共通して残る判断力と問いの組み立てにあります。曖昧な要件から何を作るべきかを見極める力、構造の美しさを判断する力、正しい問いを立てる力。これらは標準化されたテストでは計りにくい。しかし AI 時代に求められるのは、まさにそちら側です。

教育への示唆

このモデルは教育にも示唆を与えます。

従来の学校教育は、圧縮をテストや暗記で、外化をノートやレポートで、両方バランス良く訓練していました。この両方の基盤があるからこそ、キャリアのどの段階でも必要な方向に分化でき、外化の「再活性化」もできます。しかし教育の重心が偏ると、この基盤が崩れる可能性があります。

教育の重心	圧縮スキル	外化スキル	キャリア後半の基盤
従来の学校教育	テスト・暗記・暗算で訓練	ノート・レポート・図表で訓練	両方の基盤がある
プログラミング教育偏重	コードでさらに強化	訓練が薄い	圧縮は強いが外化が薄い
AI 教育偏重	AI に委ねるため訓練されない?	AI に委ねるため訓練されない?	どちらの基盤もない?

最後の行が最も深刻です。AI を使いこなすには、何を問うべきかを自分で組み立てる力、AI の出力を評価する力が必要です。これらは圧縮か展開か、あるいはその両方の認知基盤の上に成り立っています。AI を使いこなす能力は、AI なしで考える能力の上位互換であって、代替ではありません。

余談: 個人的な仮説

最後に、これも科学的根拠のない完全に個人的な仮説をもう一つ。

圧縮型と展開型は、もしかすると文字優勢/視覚優勢^[4]という認知特性とも相関しているかもしれません。つまり、圧縮型は情報をシンボル (文字、数値、コード) として処理する傾向が強く、展開型は情報を空間的なパターン (図、配置、形状) として処理する傾向が強いという体感があります。

特徴	Verbalizer	Visualizer
学習時の視線	テキストに長く滞在する	図や画像に長く滞在する
情報処理の仕方	線形的、逐次的	広域統合的、全体俯瞰的
問題解決の戦略	言語的・非視覚的手法を好む	空間的･図式的表現を構築する
脳の活性領域	音韻処理領域 (左縁上回) が活性	視覚処理領域 (紡錘状回) が活性
テキスト+画像の学習	テキストから主に学ぶ	画像から主に学ぶ
学術分野の傾向	心理学に多い	工学は空間型、美術は対象型が多い

特に最後の行が示唆的です。エンジニアに多いのは空間型の視覚処理、これはまさに展開型がアーキテクチャ図やシーケンス図で思考する特徴と一致します。

だとすればこんな対比が成り立つかもしれません。

場面	圧縮型 (文字優勢)	展開型 (視覚優勢)
ノートの取り方	テキスト、箇条書き、アウトライン	マインドマップ、図、矢印
経路の記憶	「二つ目の信号を右」(手順)	地図上の相対位置 (空間)
新技術の学習	ドキュメントを読む	実際に手を動かす
システム監視	テキストログ、アラート	ダッシュボード、グラフ
タスク管理	テキストベースの TODO リスト	カンバンボード、付箋
コードの読み方	テキストとして上から下へ読む	まずクラス図やシーケンス図を見る
設計の伝達	テキスト仕様書	ホワイトボードに書く
時計の好み	デジタル (値として読む)	アナログ (空間として読む)
プレゼン	文字中心、機能説明的	図表とアニメーションで構成

もし当てはまる感覚があるなら、あなたの認知戦略はコードの書き方だけではなく、日常のあらゆる場面に浸透しているかもしれません。

おわりに

この記事では、エンジニアの「やり方の違い」に圧縮型と展開型という名前を付け、その違いの多くが認知戦略の構造上の差異から生じている可能性を指摘しました。ここでは個性のように書きましたが、実際にはカーネマンの Fast & Slow^[5] のように一人の人に内在する 2 つの異なる認知システムのように思います。

わたしたちは多様な認知戦略を持つ人間どうしであることは避けられません。避けられないなら、理解する方が得です。「あの人はなぜああなのか」を性格や能力のせいにするのではなく、認知戦略の違いとして捉え直すだけで、日常の摩擦コストは確実に下がります。そして、より良い方向に進むために何ができるかを考えことができます。またチームリーダーは、片方の認知戦略をもう一方が押しつけられる構造にしないようにうまく調整すべきです。

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

ところで、あなたはこの記事をどう読みましたか? 図で把握して表と強調で補完して読んだか、文章を圧縮しながら読んでいたか。それがあなたの認知タイプかもしれません。

脚注

1. William G. Chase, Herbert A. Simon. Perception in chess (1973)

2. ピーター・ドラッカー. マネジメント (2001)

3. AI にこの記事を読ませ「圧縮率を高めるには?」と聞いてみて下さい。パターンカタログを作る、複数のパラダイムを試す、名前を付けるなどの方法があります。まず論文 Ericsson KA, Kintsch W. Long-term working memory (1995) について AI との壁打ちをおすすめします。

4. KOĆ-JANUCHTA, Marta, et al. Visualizers versus verbalizers: Effects of cognitive style on learning with texts and pictures – An eye-tracking study (2017)

5. ダニエル･カーネマン. ファスト&スロー (2014)