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

エンジニアの認知戦略はなぜすれ違うのか ソフトウェアエンジニアとして業界に長くいると、現場や SNS 上でのエンジニアどうしの「すれ違い」を何度も目にします。技術力の優劣ではない、性格や趣味嗜好の問題とも少し違う、なのにこの「すれ違い」は、驚くほど普遍的に業界内に存在しています。 この記事では、わたしがそのような「すれ違い」を何十年も観測し続けた末にたどり着いた一つの認知モデルに基づく見解です。科学的に証明された理論ではありません。しかし、この視点を持つだけで、日常の摩擦の見え方がかなり変わるはずです。 チーム内での症状 チェックリスト: あなたのチームで以下の状況を見たことはありますか? コードレビューで同じ PR に真逆の指摘が出る。 設計について、すぐ手を動かしたい派と全体像を合意してから着手したい派で割れる。 「なぜこうしたか」は誰かの頭の中にあり、その「誰か」を探す必要がある。

[hfdkexia]

長すぎて途中で読むのやめた。自分の経験では、綺麗に作ることを想定して工数出しても、工数かかりすぎと怒られ、とりあえず評価して動くものになりがち。

[naoya2k]

原則じゃないものを原則とラベリングして、原則だから従えと押し付けてくるのが嫌いなだけなんです。そういう人はKISS原則は平気で無視するので (たぶん誰もが何かの原則を嫌っているのだ

[sgo2]

万人が理解出来る文書を書くのは困難だしレビュー以後二度と読まれないケースが大半で、労力が成果に釣り合わないから書くのが面倒くさい派 (それでも仕事だから書く/コメントは費用対効果が高いので積極的に書くが)

[hkdn]

圧縮型はこの文章読めない。人が丁寧だなと思うような文章を冗長で無意味だと感じるのだ。

[chrome_cgi]

圧縮型/展開型という切り口は面白いけど、それと内化/外化、視覚/言語優位へのマッピングは単純化しすぎてて惜しい気がする（本文にもあるが全てスペクトラム状なので）。もう少し掘り下げるとより深い発見がありそう

[toro-chan]

自分がどちらの型だかよく分からなかった。型のような固定的な関係じゃない気がする。どちらが多いと正解なのか自体が、思った以上に状況による。正解がない以上に流動的。

[unmarshal]

面白かった。文章を見ると著者自身がかなり展開型寄りだと思った。 “コードという形式は極めて強力な圧縮表現であり、” ここ違和感があってどちらかというと強力な外化表現では？

[kagerouttepaso]

性善説により過ぎに思えた。そもそも仕様を満たす事までが責任で、保守を意識した設計品質の維持は責任外ってマインドの人もいる。そこまでする給料貰ってないと言われたてしまったらもうどうしょうもない

[lunaphilia]

必要性を感じないと人は動かない　認知構造や制約や文脈により個々人が感じる必要性は変わるのだろうとは思った　AIは必要性なんて考えない　問いが重要というのは同意

[nida3001]

『コードを読めばわかることをコメントで書いている』ことを悪と断ずる思想が本当に嫌いです。こういうことを言う人はそもそもコメントを書いてくれないから理解負債をどんどん増やしていく

[jumbochikuwa]

自分への批判記事と読んでは反発している圧縮型が多いのがまさに > リスク 早すぎる確定 (過学習)

[ihirokyx]

認知戦略の違いを情報の保持と外化で説明

[msakamoto-sf]

自分は開発キャリア初期は圧縮型でしたが加齢とともに理解力・記憶力が衰えて展開型に移行したタイプです。自分が展開するのは下手で、アウトプットはどうしても箇条書きやディテールの羅列になりがち。

[satosssi]

これは興味深い仮説。こじつけもあるんだろうけど思い当たる節もたくさん。AIと協業しながら思いついたのかしら？

[nyamadori]

いろんな要素を2つのラベルにざっくりまとめすぎていて納得感がなかった。記憶の保持（圧縮型）、外化（展開型）というより、成果のポイントを短期に置くか中長期化に置くかの認識の違いに見える。

[NOV1975]

大したことが書いてあるとは思うんだが、どうにも主観的な分析のように見える。この話の裏付けってあるんだろうか。

[pchatsu]

via https://x.com/inuro/status/2054576613141192838

[Windymelt]

面白い読み物だった。

[gnt]

汎用性が高すぎる気もするけどわかる

[naqtn]

問題は環境とのマッチングよなぁ

[hoozuki37]

ワーキングメモリが健常者より足りてないので強制的に展開型寄り（作業に落とし込む時は圧縮する）　テキストもベクトルで処理している実感がAI台頭以前からあり、ポインタが低精度。引っ掛け問題には大体躓く。

[nabinno]

圧縮型は初速に強いが、そのまま本番に持ち込むと属人化と統制崩壊を招く。問題は手法ではなく転換設計の不在。規制・監査・サプライチェーン前提の現代では展開型への強制移行が前提となる。

[kiririmode]

圧倒的な言語化力だ… 開発における設計原則や文書化をめぐる対立は、圧縮して頭の中で扱う人と、外化して構造として扱う人の認知戦略の衝突という分析。チームは外化の水準を合意し、両者の強みを組み合わせる。

[aike]

複雑さに立ち向かう2種の戦略。C言語は簡単か？の議論とか、昔からあるSimple/Easyの違いとか。自分の場合シンプルで見通しがよく予測可能な状態が好きだけど、自分の記憶はあまり信用しないというのが基本方針。

[toaruR]

帰属？！……まぁわかるけど、認識とか方が日本語しては自然と思う。元はAttributionなんかな？

[masa8aurum]

・圧縮型として成功してきた人にとって「頭の中だけで高速に完結する状況を作ること」は自分の強みの証

[fu_kak]

おもしろい

[matchy2]

極稀に文書化できないひらめきで良いコードが書けることがあって、むしろそういうのの言語化をAIにやってほしいぐらいなんだけど、どうも世の中逆になってそう

[tg30yen]

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

[Shinwiki]

偏った嗜好を持たないエンジニアで優れた人を見たことがない。ビジネス上でそれをうまく隠せるかどうかの違いはそれぞれある。

[lycolia]

腹落ち度の高い記事。必要性がないから嫌っているという話。前半は解るが後半はLLMのコンテキストが破綻してそうで読む価値薄め。LLMによる生成記事

[Hazel]

よくある対立に概ね納得がいく説明がつく感じでいい

[twotiger]

「この文章を読めないのは圧縮型」「圧縮型はAIで代替される」「圧縮型は展開型の能力を獲得する必要がある」

[aceraceae]

ここでいうところの「圧縮型」だがワーキングメモリは小さい、「設計原則」はシステム開発をするようないわゆる「IT業界」の話で、メーカーにおける開発ではあまり重要視されないんで一般化されると違和感がある。

[moronbee]

面白かった。圧縮型と展開型というラベル整理と、由来、訓練方向、チーム内での合意、AI時代の分担まで。

[nemoba]

単純に認知スコープの彼我で分けてるだけじゃ。違いは向きだから〇〇が得意もなく直感に合わないと思う。概念として圧縮したものを冗長に呼ぶ人いないでしょ「はてぶ」を「はてなが運営するソーシャル～

[t-murachi]

自分の中の「要はバランスおじさん」がすごく疼く文章だ…(´・ω・`)

[JULY]

歳を重ねた結果、「展開型」になったという実感はあるが、図を描くのは苦手で、ひたすら箇条書きする。なので余談として書かれている仮説は、少なくとも自分には当てはまらない。

[snare_micchan]

イデオロギーに依るのもあるよ。ルールに従うことは権力に屈伏することになるから従いませんと豪語する人がたまに居る。極左思想というけど

[rarirurero9999]

ソフトウェア開発の原則って"ことわざ"の域を出てないのが多いと思ってて、他分野と異なり日が浅いかつ進展が早いので、原則だからと言って必ず従うのは違うかなと。どちらかというとチーム内統制を取る方が大事では