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

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

[hfdkexia]

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

[naoya2k]

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

[sgo2]

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

[toro-chan]

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

[lunaphilia]

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

[unmarshal]

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

[kagerouttepaso]

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

[chrome_cgi]

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

[koh023]

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

[kakei-akihiko]

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

[hkdn]

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

[secseek]

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

[nuara]

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

[monokoto01]

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

[strawberryhunter]

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

[tworks]

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

[disatance2]

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

[GENS]

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

[kohiro0]

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

[nunulk]

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

[tsimo]

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

[short_tanu]

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

[sionsou]

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

[en-en-ra]

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

[yo_aibou]

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

[nida3001]

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

[yojik]

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

[pmint]

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

[dalmacija]

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

[turum]

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

[Domino-R]

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

[myr]

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

[poponponpon]

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

[t1mvverr]

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

[quantumworld]

ふむふむ