テクノロジー

ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか
2026/05/11 07:23 コメント 69件
1: mkusaka 2026/05/12 00:25

エンジニアの「圧縮型(Internalizer)」と「展開型(Externalizer)」の認知差が摩擦を生む理由を図解し、ADR等で外化合意を提案する

2: peketamin 2026/05/12 06:58

能力の高低や態度の善悪ではなく、関心や志向性の違いと環境的事情の差である、みたいなのはヘルシーな考え方だと思う一方で、逐次的な向き合いも大事な気がした。AI論はなんとも。

3: hfdkexia 2026/05/12 07:07

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

4: nguyen-oi 2026/05/12 07:09

ワーキングメモリの多寡で設計思想が決まるってのは面白いな。自分は完全に書き出さないと死ぬ展開型だわ

5: otihateten3510 2026/05/12 07:15

同僚がかわいそうだ

6: Ubobibube 2026/05/12 07:24

すれ違い。物事をシンプルに表現する人と、長く複雑に表現する人。

7: sgo2 2026/05/12 07:32

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

8: moke222 2026/05/12 07:53

ささる、ささる。当人が気づいてないから話がかみ合わない。気付いてないから理解しようともしない

9: remonoil 2026/05/12 08:06

攻殻機動隊の外部記憶って考え方がカッコイイと思ったから外化してるので、この記事の傾向には全然当てはまらなかった

10: unmarshal 2026/05/12 08:13

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

11: kakei-akihiko 2026/05/12 08:14

そもそも銀の弾丸はないとさんざん言われているわけで、世間的に良いと言われている設計原則だろうと誰にとっても良いわけじゃない。

12: naoya2k 2026/05/12 08:18

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

13: ch1248 2026/05/12 08:23

文章にAI的冗長さを感じる。内容は良い。

14: labor9 2026/05/12 08:28

こういうのをAIで取り崩して、均一化いく時代かな

15: chrome_cgi 2026/05/12 08:43

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

16: quantumworld 2026/05/12 08:45

ふむふむ

17: toro-chan 2026/05/12 08:45

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

18: t1mvverr 2026/05/12 09:05

本当はソースやテストコードが正義なのでドキュメント作るぐらいならそっちを整えたものを作る方が有用ではあるけど、

19: lunaphilia 2026/05/12 09:10

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

20: poponponpon 2026/05/12 09:12

“ドキュメントを書かない人” に近い人だけど、どうせ誰も見ないからってのが一番デカかったなぁ

21: myr 2026/05/12 09:18

タイトルでいきなりよく分からなかった

22: koh023 2026/05/12 09:20

文章が展開型すぎる。もう少しシンプルにできそう。

23: kagerouttepaso 2026/05/12 09:36

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

24: Domino-R 2026/05/12 09:58

ある意味でホワイトカラーとブルーカラーのジョブの差なのよね。前者は大規模化複雑化に有利なため世間的に評価されるが、技術的なキャパシティの向上が「全圧縮」を可能にし「分割」を無価値化すると思ってる。

25: turum 2026/05/12 10:03

必要性が腹落ちしてないものを強制されるのは誰でも嫌。SWEはスタンドプレイ多すぎ。組織教育は大切

26: dalmacija 2026/05/12 10:08

認知形式もあるが、どちらも信念とタイプが乖離してる人もいて、展開型だけど思考力無いみたいな人は厄介

27: pmint 2026/05/12 10:17

低品質。AI使っても思うように文章を書けないか。

28: yojik 2026/05/12 10:21

個々の設計原則の良し悪しはプロジェクトにかかっているフォースによって変わる。個人の資質に帰着してはいけない。

29: nida3001 2026/05/12 10:37

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

30: yo_aibou 2026/05/12 10:41

このコメントにも「長すぎて読むのをやめた」派閥と「全部読んだ」派閥がいて、おそらくこれも圧縮型/展開型に分類できるのかなーと思った。ちなみにワイは断片的に読んだ（圧縮型？）

31: en-en-ra 2026/05/12 10:56

プロなら自分の認知パターンが何であれチーム全体として上手くいく事を優先しましょうね

32: sionsou 2026/05/12 10:57

設計原則ではなくて俺ルールを勝手に作って押し付けるからでは

33: short_tanu 2026/05/12 11:14

設計判断のすれ違いは認知タイプの違い、という話。めちゃくちゃ面白かった。タイトル変えた方が良くない？

34: tsimo 2026/05/12 11:34

経験則を取りまとめたものを「原則」と呼ぶのは優良誤認を意図してるように思っちゃう。

35: nunulk 2026/05/12 11:35

面白かった。ドキュメントなしで難解なコードを読み書きできる人は、情報圧縮効率が高いからなのかもしれないと思った（自分とは逆）

36: kohiro0 2026/05/12 11:41

話は変わるけど、質問に対して回答をしない人が理解できない。私「～ですよね？」理想「はい or いいえ」？「それは～なので～です」私「（同じ質問をもう一度する）」/こういう人はどちらかというと展開型？

37: GENS 2026/05/12 11:47

ITエンジニアのルールは宗教。最初に見たルールを自分の親＝ルールだと思い込みがち。本日の宗教バトル会場はここですか。

38: disatance2 2026/05/12 11:50

圧縮型と展開型という用語を使って動物占いみたいなネタをぶち込んでるだけじゃない。占いの領域だよ。

39: tworks 2026/05/12 11:50

両方を経験しているだからか面白かった。どっちがいいかはケースバイケース。再現性ある組織を作るなら展開型に向かうのだろうと思っています。自分だけしかみないコードとかだと圧縮型ばかりかな。

40: strawberryhunter 2026/05/12 12:01

唐突な設計原則という言葉に定義も無いことに苦情を言いたいし、センスの違いにここまで長文で書く意味もわからん。

41: monokoto01 2026/05/12 12:02

設計というより、くそ長いポエム読まされたらぶちギレるだろ

42: nuara 2026/05/12 12:07

無意識にやってることを言語に翻訳させられると、微妙な齟齬もあるし再翻訳も必要だしで、負荷が高まるのではないか。

43: secseek 2026/05/12 12:16

展開はもっと難しい気がします。まず圧縮と比べて学校で訓練されていないのでやってもできない人が多そうです。バランスがよいと書かれていますが少なくとも昔は圧縮に偏っていました

44: hkdn 2026/05/12 12:18

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

45: morimarii 2026/05/12 12:35

コメント欄も含め非常に示唆に富む内容／「長い」ってのがもう認知乖離起こしてんのよね

46: atkin 2026/05/12 12:43

長いのは長い。が、酷評されるのはよくわからない。内容は比較的実感に合うが、設計原則の話はあまり関係なかった

47: skmtpalm 2026/05/12 12:56

“ネガティブ”

48: rarirurero9999 2026/05/12 13:04

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

49: hjmk 2026/05/12 13:07

他人の書いたクソコードに触れたことがあるか否かで分かれる気がする。

50: snare_micchan 2026/05/12 13:31

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

51: hogetax 2026/05/12 13:32

taitoruno

52: JULY 2026/05/12 13:37

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

53: t-murachi 2026/05/12 13:37

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

54: nemoba 2026/05/12 13:58

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

55: moronbee 2026/05/12 14:03

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

56: aceraceae 2026/05/12 14:18

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

57: twotiger 2026/05/12 14:40

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

58: Hazel 2026/05/12 15:40

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

59: lycolia 2026/05/12 15:59

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

60: shiketanotsuna 2026/05/12 16:13

これは社内共有されても誰も読んでくれないドキュメントに分類される文章だろうなぁ書いてて虚しくなるやつ

61: Shinwiki 2026/05/12 16:14

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

62: tg30yen 2026/05/12 16:35

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

63: atsushieno 2026/05/12 16:57

圧縮型の人間はAIにでも要約させればいいのでそこに難癖をつけるのは反生産的行為

64: matchy2 2026/05/12 17:02

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

65: fu_kak 2026/05/12 18:30

おもしろい

66: masa8aurum 2026/05/12 18:51

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

67: toaruR 2026/05/12 19:36

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

68: aike 2026/05/12 20:39

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

69: kiririmode 2026/05/12 23:30

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