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

少し前に話題だった「ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか」を読んで。

https://zenn.dev/torao/articles/20260502-differences-in-engrs-cognitive-strategies

引用した記事の要旨

まず初めに引用した記事の要旨を示します。たくさんの仮説を提示しているので、その仮説を列挙する形で提示します（生成AIの類は使っていません）。

• 仮説1. エンジニアは情報を「分割→圧縮→記録」という順で処理する。
• 仮説2. 記録の方法には「保持」と「外化」の２種類がある。
• 仮説3. 「保持」と「外化」のどちらに重きをおくかが人によって大きく異なる。
• 仮説4. 「保持」に重きをおく人（「圧縮型」）と「外化」に重きをおく人（「展開型」）で「すれ違い」が発生しがち。
• 仮説5. 「圧縮型」と「展開型」の違いは認知コストの違いから生まれる。

以下はすべて「圧縮型」と「展開型」の分類を認めた上でのそれらに対する仮説。

• 仮説6-1 「圧縮型」は先天的に大きなワーキングメモリ (記憶力) を持っていることが多い。
• 仮説6-2 「圧縮型」はその記憶力故に圧縮して記憶に収めることを重視する認知戦略を取りがち。
• 仮説6-3 「圧縮型」は「外化」に大して「速度を落とす」という抵抗感を持つ。
• 仮説7-1 「展開型」は記憶できない情報は圧縮を放棄し外部メディアに配置する認知戦略を取りがち。
• 仮説7-2 外部メディアは参照コストが記憶よりも重いために作業が遅くなりがち。
• 仮説8 「圧縮型」と「展開型」の違いが最も顕著に現われるのはまだ確定していない情報への反応。
• 仮説8-1 「圧縮型」は記憶に早く収めるために曖昧さを早く消し去りたいと考える。
• 仮説8-2 「展開型」は曖昧なままコスト感の低い外部メディアに情報をおけるので、曖昧さ消去への欲求が低い。
• 仮説8-3 この欲求の違い（コスト感の違い）が実務で「すれ違い」を生む。
• 仮説9-1 「圧縮型」は「今そこにあるバグの原因」を見つけるのに強い。
• 仮説9-2 「展開型」は「まだ認知されていないが、いずれじわじわと問題になる歪み」を見つけるのに強い。
• 仮説10-1 「圧縮型」は「展開型」に比べて知識の呪いにかかりやい。
• 仮説10-2 仮説10-1により「展開型」の方が「圧縮型」に比べプレゼン能力が高い。
• 仮説11 「展開型」と「圧縮型」の分化は職業的にコーディングを行うことで進む。
• 仮説12 記憶力の制約から「展開型」から「圧縮型」への移行は困難が伴う。
• 仮説13-1 ソフトウェアの「設計原則」は「展開型」の認知を前提としている。
• 仮説13-2 この認知の違いが「設計原則」を巡る摩擦を生む。
• 仮説14 「圧縮型」は「展開型」は固定的なラベルではなく、環境の基準との相対的な位置で測られる相対的な分類。
• 仮説15 AIは「外化に長けた究極の圧縮型」。
• 仮説16 「圧縮型」「展開型」と文字優勢、視覚優勢は関連があるかも。

コメント

全体的に仮説提示に対する論拠の提出が弱すぎて鵜呑みにするのは危険すぎると感じました。

特に気になったものだけピックアップしてコメントします。

仮説1-5および仮説14について

圧縮型と展開型の対比は 0 か 1 かの分類ではなく、スペクトラム上の位置です。

と断ってはいますが、その上でも怪しいと思います。少なくとも人間に対して当てはめる指標としては大雑把すぎるように感じます。このような分類が可能としたとて、せいぜいある分野にある傾向を示すことがありえるかもしれないくらいのものではないでしょうか。

個人的にはそもそもこの分類が無理筋のような気がしています。「展開型」といいっても、外部メディアに記録したことさえ忘れてしまえば意味はないため。少なくともpointerを保持しておく必要があるからです。外部に記憶する量が増えれば増えるほど必要なメモリは普通は増加します。もちろんこの発散を防ぐために例えばZettelkastenのようなものが開発されたりしているわけです。しかし、結局のところ使える知識として蓄えるためには自らの記憶は必要です。「圧縮」と「外化」を対立概念のように扱うことに疑問を感じました。

仮説8について

不寛容 (Intolerance of Ambiguity) の研究は古くからあり（原著1950年、日本語版1980年『権威主義的パーソナリティ』が有名？）、また現代でも研究されている概念です。以下の区別も大切とされています。

• Tolerance of Ambiguity
• Intolerance of Uncertainty
• Ambiguity Aversion

もともと専門家でもなく、すでに論文を読める立場でも今はないので解説は控えますが、アクセスできる立場の方は調べてみてください。いわゆる気分障害との関連性も研究されているはずです。

仮説8-3に関して重要に感じた文をここに引用します。

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

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

曖昧さへの耐性の話を「圧縮型」と「展開型」の話にすり替えており、乱暴な議論と感じます。

仮説13について

仮説13-1は「ソフトウェアの「設計原則」は「展開型」の認知を前提としている」です。

これはある意味で当たり前のことを言っていると思います。ソフトウェアは、とくに業務で扱うようなものは、大抵の場合1人の人間がすべてを詳細に記憶しておくのは不可能なサイズまで肥大化するものだからです。

次の仮説13-2 「この認知の違いが「設計原則」を巡る摩擦を生む」が、タイトルの「ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか」への回答です。つまり「一部のエンジニア」は「圧縮型」であり、彼らは「限られた圧縮容量にすべてを収めるために、圧縮の邪魔になるものは排除すべき」という暗黙の原則に従っているために「設計原則」と衝突するという説明です。

これに関連して重要だと感じた文を引用します。

ソフトウェア設計で「良い」とされている「関心の分離」「単一責任原則」「レイヤードアーキテクチャ」「ドメイン分離」といった原則を突き詰めると、システム全体を一度に頭に入れなくて良いように、部分的にワーキングメモリにロード可能な構造を作るという、分割 (チャンク化) のための手法です。
(中略)
圧縮型がこれらの原則になじみにくいのは、本人にとっては既に全体が頭に入っているから。全体が見えている人にとって、関心の分離は「余計な分割」に感じられ、インターフェースの抽象化は「不要な間接参照」に見えます。それだけでなく、圧縮型には「限られた圧縮容量にすべてを収めるために、圧縮の邪魔になるものは排除するべき」という暗黙の原則があり、これが設計原則と真正面から衝突します。分割も抽象化も、圧縮型にとっては情報量を増やす行為であり、頭の中の限られた空間を圧迫するものです。

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

一方で、展開型がこれらの原則に溺れるリスクも指摘しておくべきでしょう。部分ロード可能な構造を作れるようになると、分割や細分化が止められなくなる病気にだれもが一度はかかります (先ほどの 2-3 年目問題など)。

ここで仮想標的にされている「圧縮型」の人も「展開型」の人も（ステレオタイプ紹介としての誇張があるとしても）程度が低すぎるように思います。「圧縮型」の人は「設計原則」の目的を理解していない（するつもりがない？）し、「展開型」の人は「設計原則」が何を目指すものか理解していない。つまり。ここでやり玉に挙げられている問題行為は「設計原則」の目的に対する不理解の現れです。「圧縮型」「展開型」という分類が仮に正しいとして、それに帰されるようなすれ違いとはいえないのではないでしょうか。

引用記事の筆者は、スペクトラムだと語ったり、相対的だと語ったりして譲歩しているようですが、名前をつけることの魔力をソフトウェアエンジニアならよくご存知のはずです。なにかあったとき「この人は「圧縮型」か？」みたいな思考がよぎってしまうことになります。個人的にはこのような対立概念の提示方法は良くないと思っています。

おわりに

なにか摩擦があったときに「あの人は多分ああいう人だから」という考え方は危険です。実際のところ類型化できることもあるのですが、先にカテゴライズしてから話を聞くのと聞いてからカテゴライズするのでは違いが発生し得ると感じています。人間をマネジメントする立場の方は気をつけてほしいと思います。AIとの感情的対立は今のところ問題にならなさそうなので、対AIではまだそれほど気にしなくて大丈夫そうです。

また、「あくまで仮説」「科学的な議論ではない」と断られてはいても読んでいるうちに説得力を感じてしまい、知らず知らずに影響をうけるのは怖いことです。説得力があることはそれが正しいことを意味しないということを理屈では理解していても、訓練を受けていないと批判的に読むのは難しいものだと思います。ショーペンハウアーではありませんが文章を読むときには他人の価値観を無意識にインストールしないように重々注意すべきでしょう。