譯者註
此篇為翻譯文章，原作者為Takami
Torao。感謝原作者同意提供翻譯與再刊出的授權。
第一次翻譯長篇日文文章，若有翻譯上的指正與建議，或是需要下架文章，可使用email或留言功能與我聯絡。謝謝。
This article is the translation of Takami Torao's blog post
"ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか".
Special thanks to the original author for allowing me to translate and
repost this article.
為了閱讀的順暢度，以及處理中文沒有的用法，本文有部分句子經過小幅度的改寫，並沒有100%與原文對應。章節名稱有包含翻譯前的原文，可以和原文對照閱讀。圖片因原圖已有英文，就不再翻譯。
AI/LLM使用揭露：有使用AI做為初稿翻譯，但結果未達到自己的要求，幾乎每一句都有重新調整/寫過。
原文出處與作者資訊
Original author: Takami Torao
Original post title:
ソフトウェアの「設計原則」を、なぜ一部のエンジニアは生理的に嫌うのか
Original post URL: https://zenn.dev/torao/articles/20260502-differences-in-engrs-cognitive-strategies
Translated version: 2026/5/13
導讀
作者舉出了自己的觀察：工程師會因為職涯的經驗發展成「壓縮型」與「展開型」兩種做事風格。
- 壓縮型（Internalizer）：依賴巨大的working memory將知識和context，積極壓縮（encode）後儲存在腦袋內的人
- 展開型（Externalizer）：積極將知識外部化(offload)到外部的人
這兩類人在任務處理上容易發生衝突，應該如何化解衝突，與組織應如何正確的評價這兩類風格的工程師，以及兩種做事風格的人應如何應對AI時代的來臨。
以下為正文開始
工程師的認知策略為何會產生分歧 (エンジニアの認知戦略はなぜすれ違うのか)
身為軟體工程師，在業界待久了，無論是在工作現場或社群平台上，都會反覆目睹工程師之間的「分歧」。不是技術能力的高低之分，也不完全是性格或喜好的差異，但這種「分歧」卻驚人地普遍存在於整個業界。
這篇文章是我觀察這類「分歧」數十年後所歸納出的一個關於認知模型的見解。這並非經過科學驗證的理論。然而，光是擁有這個視角，就能大幅改變你看待日常衝突的角度。
團隊內的症狀 (チーム内での症状)
Checklist：你的團隊中是否曾出現過以下狀況？
- Code review 時，同一個 PR 出現完全相反的意見。
- 關於設計，分裂成「想馬上動手做」派和「先對全貌有共識再開始」派。
- 「為什麼這樣做」只存在於某人的腦中，需要找到那個「某人」才能得知。
- 即使制定了文件化規則，寫的人和不太寫的人依然維持原本的作法。
- 同樣的任務，不同成員花費的時間和產出的風格差異極大。
- 轉到其他團隊的人，在那邊卻成為不可或缺的成員。
- 有技術力很高，卻不擅長對別人說明的人。
- 明明一看就懂的程式碼卻有註解
- 「感覺」和「證據」的意見沒辦法統一
如果發生有三個以上的話，那這篇文章應該對你有幫助
這些症狀，我們長年以來都以「偏好不同」「感覺不同」來帶過。然而，它們的規律性很高，以相同的 pattern 反覆出現。若要說只是喜好的範疇，其重複性也太高了。
歸因可能是錯的 (帰属が間違っているかもしれない)
面對這些衝突時，我們往往會像下表中間欄那樣思考原因。然而每一個問題的實際結構都不同，導致錯誤的歸因。
| 症狀 | 常見的錯誤歸因 | 實際的結構 |
|---|---|---|
| 不寫文件 | 懶惰、專業意識不足 | 在本人的認知中，對於文件化感受不到價值 |
| 作業速度慢 | 能力不足 | 正在投資時間於看不見的工程（視覺化、context 記錄） |
| 說明和報告品質低落 | 溝通能力低 | 沒有認知到「知識的重構」 |
| 設計討論沒完沒了 | 優柔寡斷 | 有「完成結構後再前進」的認知需求 |
| 無視設計原則 | 學習不足、經驗不足 | 因為腦中已有全局，感受不到切割的必要 |
| 過度設計 | 神經質、吹毛求疵 | 正在建構任何人都能理解的架構 |
讓我們看幾個例子。
「不寫文件的人」並非偷懶，而是在本人腦中所有事情都是連貫的，所以感受不到刻意轉換成另一種形式寫下來的價值。或許類似於我們被要說明走路是「抬起一隻腳時，另一隻腳如果沒有著地就會跌倒」這樣的感覺。
「作業速度慢的人」並非能力低，而是在掌握全貌、結構視覺化、給未來的團隊的產出物等從外部看不見的工程上投入了時間。如果省略這些工程確實會變快，但那等於是改變了品質的定義。
「報告技巧不好的人」並非缺乏溝通能力，他們一對一時能進行極為清晰的技術討論。問題在於，將自己的知識重構為對方知識程度的步驟，在該人的認知機制中不易啟動。
你注意到了嗎？上表中，將結構性問題歸因於個人的態度。這是常見的錯誤歸因。
如果這些衝突的原因不是個人的意識或技能，而是更根本的認知機制差異呢？對策不是對近視的人說「看仔細一點」，而是給予正確的鏡片。
診斷 (診断)
調整鏡片 ── 資訊的保持與外部化 (レンズを合わせる ─ 情報の保持と外化)
剛才提到的衝突，幾乎都源於各自保有資訊的方式不同。
我們工程師每天都在處理大量的資訊和知識。規格、設計決策、程式碼的結構、過去的障礙、團隊的 context。將處理資訊的方式分解來看的話，會是一個非常簡單的結構。
〔資訊的分割、壓縮、保持與外部化的步驟圖〕
- 分割（Chunking）。將龐大的資訊和知識分成本人能處理的大小。實際上這裡包含分類和階層化等結構化作業，但本文省略。
- 壓縮 (Encoding)。將分割後的區塊編碼成自己容易處理的形式。包括去除雜訊、排除重複資訊、刪除無關資訊、pattern 化、抽象化、mapping 到已知 model 等。
- 記錄。
- 保持。立即需要的資訊儲存在大腦的 working memory 中。可以高速掃描，取出也快，但容量有限。
- 外部化。將不是立即需要的資訊、需要再次整理資訊、不確定因素多的資訊，放置在大腦之外。這包括記下現有文件或 codebase 的參照位置，或自己寫成文章、畫圖、留在註解等等。取出需要多一道手續，但容量幾乎無限。
「保持」和「外部化」這兩種手段每個人都在使用。然而，偏向哪一邊因人而異。而這個偏向的差異，幾乎能解釋開頭列舉的所有分歧。
本文將偏向保持的人稱為壓縮型（Internalizer），偏向外部化的人稱為展開型（Externalizer）。讓我們來看看它們特徵上的差異。
比較兩種傾向 (二つの傾向を比較する)
關於這兩種傾向，請一邊思考自己偏向哪邊一邊閱讀。
| 場景 | 壓縮型 | 展開型 |
|---|---|---|
| 偏好的工作環境 | CLI、terminal、大量使用快速鍵 | IDE、GUI、資訊的一覽性 |
| 程式碼的寫法 | identifier 簡短、符號化 | identifier 長且具說明性 |
| 開發的推進方式 | 先動手再整理 | 先描繪全貌再實作 |
| 文件 | 僅現狀說明，缺乏背景和 context | 用圖展示全貌，用文字補充 context |
| 註解 | 不寫，讀程式碼就好 | 勤於留下 |
| Log | 不寫，用 debugger 就好 | 大量埋入 |
| 理解新技術 | 快，連接到已知概念 | 慢，在全體結構中尋找定位 |
| 判斷方式 | 迅速確定 | 資訊齊全前保留 |
| 問題認知的範圍 | 局部的、短期的 | 全局的、長期的 |
| 語言的偏好 | C, Perl, Go | Java, Swift, SQL |
這是為了強調對比而刻意加強刻板印象的選項，完全符合其中一邊的人非常少見。大多數人是「大概偏向這邊」的比例問題，也有不少人會根據場景切換使用。壓縮型和展開型的對比不是 0 或 1 的分類，而是光譜上的位置。
我自己二十多歲時偏向壓縮傾向，但在職涯途中開始有意識地發展展開能力。多年來與兩類人都經歷過了「分歧」。拆解他們的認知結構後，發現「壓縮」「展開」這兩種傾向衍生出的特徵，就整理出來成為這篇文章。
那麼，為什麼這個偏向的差異會在團隊中產生衝突呢？下一節將深入探討其原理。
為什麼會產生這種差異 (なぜこの違いが生まれるのか)
壓縮型和展開型的差異不是喜好或風格的問題。它源自於更深層的認知成本差異。
兩種策略的根源 (二つの戦略の根源)
壓縮型採取的是重視快速判斷和處理的認知策略。獲得壓縮型特質的人往往先天擁有較大的 working memory（記憶力），為了進一步發揮這項優勢，盡可能將更多資訊收納在腦中，重視對資訊和知識的壓縮效率。在這個過程中，徹底刪除對自己來說已知/無關的多餘雜訊： context、comment、log、甚至 identifier。另一方面，有意識地訓練自己將眼前的資訊高度抽象化，抽出非常精簡且核心的本質。這些都是壓縮效率最大化策略的必然結果。此外，對外部化這個行為本身也抱有「會拖慢速度」的潛在抗拒感。
〔壓縮型的認知步驟圖〕
另一方面，展開型採取的是能承受超出自身 working memory 容量的認知策略。不勉強壓縮無法容納在 working memory 中的資訊，而是分割後放置在外部媒體。因為可以使用廉價且幾乎無限的容量，所以沒有強烈的動機去壓縮，反而重視保留 context 和意圖的價值。畫圖、寫文章、留下 log 和註解、將結構視覺化。Working memory 中只載入「現在正在思考的部分」，其餘在需要時對照察看。這個策略的結果是作業會變慢。然而，寫出來的東西會直接成為與他人共享的資訊留在團隊中。作業慢不是能力問題，而是將認知範圍擴展到外部的成本。
〔展開型的認知步驟圖〕
兩種策略都是面對「有限的 working memory」這個限制時，朝不同方向的最佳化。壓縮型是「為了收進容量內，盡可能削減input」，展開型是「想把input保留在腦袋之外的地方」。對同一問題，產生了各自的合理策略。
模糊性的保持成本 (曖昧さの保持コスト)
壓縮型和展開型的差異最大的地方表現在「對尚未確定的資訊的反應上」。
壓縮是將資訊釐清並高效編碼的行為。然而，未釐清的資訊無法壓縮。在持有模糊資訊的期間，壓縮型只能將其「未壓縮地」放在 working memory 中。大腦的 working memory 是容量有限的昂貴資源，被不知是否有用、不知何時能解決的東西佔據這個區域，會感受到強烈的認知窒息感。
壓縮型想要盡快消除模糊，被想要立即驗證假設的慾望所驅使。強烈主張排除模糊性、先跑起來再說、把討論盡快帶到結論。這些行為都是「想把模糊且無法壓縮的資訊盡快從 working memory 趕出去」的合理行動。
另一方面，展開型可以將模糊資訊帶著「？」放到外部，釋放 working memory。這就像在全覽圖中畫一個空白的 box，用紅筆寫上「待確認」並畫一個箭頭。外部媒體的容量幾乎無限，所以保留的成本很低。
展開型能夠相對較多且較長時間地保留模糊性。能夠等待做判斷所需的資訊齊全、能夠在「總覺得哪裡不對，但目前還說不上來」的狀態下繼續。如果「？」增加太多，整體概念就會越來越模糊，但即使如此，也比只記憶在腦袋中，能保留多更多的不確定因素。
| 壓縮型 | 展開型 | |
|---|---|---|
| 模糊資訊的存放處 | Working memory（高成本） | 外部媒體（低成本） |
| 對模糊性的反應 | 快速確定/放棄判斷，或拒絕 | 保留、保持 |
| 判斷的時機 | 即使資訊少也快速 | 等資訊齊全 |
| 風險 | 過早確定（overfitting） | 過晚確定（錯失機會） |
| Negative capability | 低 | 高 |
如你所見，這不是性格問題，也不是耐心問題。只是資訊存放處的成本不同。
這個結構讓我感覺類似統計學中機率推論和貝氏推論的行為差異。從手邊資料確定唯一的最大概似估計值，或是保持事前分佈的同時逐次更新估計值。
然而，這個成本結構的差異在實務中會產生「分歧」。當展開型的人帶著「總覺得哪裡不對，但說不清楚」的模糊疑慮找壓縮型的人時，壓縮型的人會馬上判斷「無法語言化 = 沒有根據 = 不是問題」而立即丟棄疑慮。而當被丟棄的疑慮之後實際顯現為問題時，那就不是「分歧」而是「事前察覺到的問題被忽略了」這種結構上的問題。 （譯者註：語言化 = verbalize）
這種分歧更棘手的是，連事後的認知也不一致。展開型會後悔「明明有發現到不太對勁的事」，但壓縮型會切割說「既然沒有被語言化，那就是理所當然會被忽略的問題」。在各自的認知 framework 中都完全正確——這正是認知策略差異所產生的深層衝突。
發現問題的不同過程 (エラー発見プロセスの非対称性)
這個認知差異在實務中容易出現的另一個例子是問題的發現過程。一般來說，建立假設並驗證、用 debugger 逐步執行、用 grep 搜尋 log 等邏輯性探索，是所有職業 programmer 的基本技能。差異在更深層的地方。
| 壓縮型 | 展開型 | |
|---|---|---|
| 強項 | 程式碼上邏輯的探索範圍極為廣大 | 從不同層的角度檢視結構上的問題 |
| 為何可能 | 因為將整個 codebase 壓縮保持在腦中 | 因為將全貌展開在外部進行俯瞰 |
| 擅長發現的東西 | 實作層級的 bug、edge case、已知 pattern 的問題 | 粒度不均、dependency 偏向、缺乏一貫設計思想、未被認知的問題 |
| 典型發言 | 「那個模組的那個分支很可疑」 | 「這個設計，是不是哪裡歪了？」 |
舉例來說，展開型所發現到的「形狀的歪曲」是：
- 不同的 domain 概念被共用在一個 class 或 table 中。
- dependency 的箭頭過度集中在某一個 component。
- Module 分割的粒度不均一，只有一個特別大。
- 明明是 layer 結構，卻只有一處跨越 layer 的 dependency。
- 畫 sequence diagram 時只有一處的往返不自然地多。
這些關於 cohesion、coupling、dependency、concurrency、security 等的歪曲，是逐行讀個別程式碼也難以發現的問題。邏輯上正確運作的程式碼，從結構來看卻有不自然的形狀。這種違和感，有時是預見了未來的障礙、或是可維護性的降低（技術債）、安全性漏洞等等。
這不是哪個比較優秀的問題，而是容易發現到的東西種類不同。壓縮型的大範圍掃描能力擅長找到「現在就在那裡的 bug 原因」，展開型的結構偵測能力擅長找到「尚未被認知但遲早會慢慢成為問題的異常扭曲」。團隊中如果缺少任一方的觀點，某一類的問題就會在未被發現（甚至未被認知為問題）的狀態下殘留。
知識的詛咒與報告能力 (知識の呪いとプレゼン能力)
認知科學中有「知識的詛咒（curse of knowledge）」這個概念。一旦擁有某個知識，就難以想像沒有那個知識的狀態。
壓縮型擁有容易受到這個詛咒影響的結構。知識被高度壓縮並以個人化方式整合在內部，因此難以想像對方會在哪個步驟卡住。此外，在壓縮過程中有將背景和 context 作為「自我說明之物」丟棄到思考之外的傾向。對本人而言，壓縮後的本質資訊才是知識，丟棄的東西已不在想像力的範圍內。但對聽眾來說，那邊才是理解的線索。壓縮型的報告容易變成「單純的功能說明」就是因為這個原因。
展開型因為將知識以展開的狀態保持在外部，所以能結構性地辨識出「預設的聽眾缺少這個部分」。加上平時就將圖、文章、甚至與本質沒有直接關係的「感想」也輕鬆地記錄在外部，報告的素材已經在手邊了。特別是感想，作為聽眾無法從官方資訊中得到的趣味性，是很有價值的材料。能做出配合目標受眾的報告，不是因為溝通能力高，而是因為對自身知識結構的存取路徑不同，且日常蓄積了表達的工具。
壓縮型和展開型從何而來 (圧縮型と展開型はどこから来るのか)
讀到這裡你可能覺得「這些是天生的性格吧」。我的觀察比這更複雜。
大部分學校教育的計畫是壓縮和外部化兩方面皆有。我們花了 10 年以上的時間被灌輸這些能力。也就是說，每個人都已經具備壓縮和外部化的能力。
然而，進入程式的世界後狀況就變了。程式碼是極為強力的壓縮形式，寫程式碼本身就兼具思考和產出。程式碼虛擬地取代了在學校學到的「寫在筆記上整理」「彙整成圖」，會覺得再把程式碼重新外部化是多餘的行動。
| 階段 | 發生了什麼 |
|---|---|
| 學校教育 | 所有人都被訓練壓縮和外部化的基礎（背誦、考試、筆記、報告） |
| 與程式的相遇 | 認識了程式碼這種強力的壓縮表現，一部分人開始覺得「不需要」外部化 |
| 初期的成功體驗 | 用壓縮獲得成功體驗的人逐漸捨棄外部化，用外部化獲得成功體驗的人則維持 |
| 環境的複雜化 | 只靠壓縮已經處理不了，重新撿回已經捨棄的外部化 |
壓縮型不是「不知道」外部化，而是知道，但因壓縮的成功體驗而策略性地捨棄；展開型不是「新獲得了」外部化，而是沒有捨棄在學校學到的東西、或是曾經捨棄後重新撿回。
職涯開始時，許多人會用在學校教育中獲得的壓縮和外部化來面對資訊。這只是自然的出發點，還稱不上認知策略。在處理的問題範圍還小的時候，只靠 working memory 就足夠應付，再加上前述不需要外部化的疑慮，初期通常先表現出偏壓縮型的行為。
| 狀態 | 說明 |
|---|---|
| 未分化 | 問題範圍小，只靠 working memory 就足夠。也有人以學校教育的延伸在做外部化，尚未建立策略。 |
| 壓縮型 | 發揮先天 working memory 大的優勢，獲得了能在腦中高速處理廣範圍的強壓縮的人。 |
| 展開型 | 為了適應超出 working memory 極限的環境，獲得了外部化這個策略的人。 |
展開型看起來也像是壓縮型的「下一個階段」。在某個時間點「環境」的要求開始超過自己的
working memory
容量，這時採取了外部展開策略的人可以變成「壓縮+展開」，雖然不多，但我確實見過這樣的超人。也就是說外部展開是為了讓自己在超出自身壓縮容量的環境變化中活下去的方法。
而兩者都是透過後天的訓練和經驗建立的認知策略，這是和「未分化」區別所在。
不過，重新活化展開型也需要契機。多數情況下，那個契機不是從容的自我精進，而是更迫切的適應危機環境下的生存策略。
| 契機 | 範例 |
|---|---|
| 工作環境的複雜化 | 責任範圍擴大，只靠腦袋已經處理不過來了。 |
| 生活環境的複雜化 | 建立了家庭，不斷增加的插隊任務使得 working memory 容易揮發。 |
| 因老化導致記憶力變化 | 以前能裝進腦中的東西裝不下了，不得不寫下來。 |
| 模仿優秀的實踐者 | 看到敬重的前輩在畫圖和寫 ADR 而學習採用。 |
| 未重新活化 | 持續留在 working memory 容量內的環境，或自我認同障壁。 |
所謂自我認同障壁，是指將外部展開當作違反自身美學的東西而拒絕的心理現象。對於長期作為壓縮型以快速判斷和作業獲得成功的人來說，「只靠腦中就能處理所有事」既是能力的證明，也是自我形象的核心。因此承認「自己的壓縮力不夠用」不是理性問題，而是在美學層面產生抗拒。
職涯初期的成功體驗影響也很大。在新創企業的高彈性系統中快速實作獲得好評的人會進一步強化壓縮，在商用軟體開發公司中，資料被評為「很好懂」的人會進一步磨練外部化。最初的團隊、最初的 mentor、最初的成功體驗決定了認知策略的方向，而一旦方向確定就會因為確認偏誤而自我強化，變得難以改變。
以實際感受來說，在業界第 2～3 年左右會出現「短的程式碼才是正義」和「說明力才是正義」這樣的極端表態（而且常常會在社群平台上看到不幸的炎上）。看起來是在技術上的自我形象開始固化的時期，為了定義自己的實作哲學而做出的行動。
你現在看起來屬於哪種類型，與其說是本質能力，不如說職涯的初始條件和其後的生存策略的因素更大。不過，working memory 的容量限制除外。
不同的可訓練性 (非対称な訓練可能性)
對團隊 leader 來說，這裡有實務上重要的見解。
| 方向 | 本質 | 難度 |
|---|---|---|
| 壓縮型 → 獲得展開能力 | 學習低成本的外部記憶使用方式 | 比較容易。既有的壓縮能力不會消失 |
| 展開型 → 獲得壓縮能力 | 增加 working memory 容量 | 困難。會碰到生理上的限制 |
壓縮型獲得展開能力是純粹的能力擴張。一如以往在腦中壓縮，並將以前捨棄的 context 和背景、未確定的資訊等放到外部。大腦的硬體完全沒有改變，卻可以增加可用的記憶區域。
另一方面，working memory 容量是強力的物理限制。對展開型說「為了加快作業速度，增加 working memory 吧」，改善幅度也是有限的。
熟練的將棋、圍棋、西洋棋玩家是高度的壓縮型。根據西洋棋的經典研究1，熟練者能記住盤面是因為將盤面壓縮為對局中「某種意圖」的 pattern 來認知（棋子隨機配置的狀態下與素人差異不大）。然而，要比較那些大量的 pattern 並瞬間讀出下一步的前提是需要巨大的 working memory。壓縮的技巧可以訓練，但能同時操作的數量卻有硬體的限制。
設計原則是以展開型的認知為前提 (設計原則は展開型の認知を前提としている)
這裡有一個有趣的連結。
在軟體設計中「好的設計」：「Separation of Concerns」「Single Responsibility Principle」「Layered Architecture」「Domain separation」等原則深究下去，就是建構不需要一次將整個 system 放進腦中、能部分載入 working memory 的結構——也就是分割（chunking）的手法。
換言之，這些設計原則是以展開型的認知為前提的設計。
壓縮型之所以難以適應這些原則，是因為對本人而言全體已經在腦中了。對於能看到全貌的人來說，separation of concerns 感覺是「多餘的分割」，interface 的抽象化看起來是「沒必要的間接參考」。不僅如此，壓縮型有「為了把所有東西塞進有限的壓縮容量中，應該排除妨礙壓縮的東西」的隱含原則，會與設計原則正面衝突。分割和抽象化對壓縮型來說都是增加資訊量的行為，會壓迫腦中有限的空間。
然而這些原則存在的理由是：作者以外的人也會涉及那些程式碼。團隊的其他成員、未來的維護者、新加入的成員——在團隊開發的前提下，以其他人的 working memory 容量為前提去設計是無法迴避的問題。
另一方面，我們也應該指出展開型沈溺於這些原則的風險。一旦能夠建立了可以「部分載入」的結構，就會陷入無法停止切割和細分的症狀（例如前述的第 2-3 年問題）。前陣子廣泛討論的「過度套用 microservice 的危害」就是典型的範例。DDD 中的 anemic domain model 也可以看作是過度套用 separation of concerns 的結果。
型態的相對性 (タイプの相対性)
最後，有一個重要的補充。壓縮型/展開型不是貼在個人身上的標籤。它是與環境的相對位置。
某人可能會在全是壓縮型的團隊中被當作展開型稱讚，在展開型的團隊中則被當作壓縮型稱讚。前一個團隊裡「善用設計原則的人」，到下一個團隊就變成「output 很快的人」。人沒有改變，改變的是周圍的基準。
不只是環境，經驗也有影響。隨著經驗的累積，有些人會獲得根據場景切換使用兩種策略的 metacognition 能力。在系統故障的處理初期中作為壓縮型迅速行動，在 review 設計和安全性時作為展開型展示結構。能夠做到這種「認知策略的切換」，本身就是成熟的認知策略。
理解差異之後，該怎麼做 (違いを理解した上で、どうするか)
讀到這裡的你，大概已經自覺自己偏向哪一邊了。對於團隊中的分歧，或許也能看的更清楚了。
能知道自己的型態，將對方的行為翻譯為認知策略的差異。在此基礎上，讓我們思考作為團隊能具體做什麼來消除摩擦。
明確達成冗餘度的共識 (冗長度の合意を明示的にする)
作為 team building 最有效的是明確地在團隊中達成「什麼要外部化到什麼程度」的共識。「好好分離職責」和「不要寫自我說明的東西」都不是解方。兩者都只是在將一方的認知策略強加於另一方。需要的是按產出的種類決定外部化的等級。例如以下的共識：
| 產出 | 共識的例子 |
|---|---|
| 設計決策 | 必定留下 ADR（Architecture Decision Record）。為什麼採用這個結構、被否決的替代方案是什麼。 |
| 運行維護 | 製作Runbook。待命負責人能在現場即時對照的形式。 |
| 程式碼註解 | 限定於「為什麼」。如果程式碼能自我說明「做什麼」「怎麼做」則不寫。 |
| 事後檢討報告 | 遵守時間軸・根本原因・防止再發生的格式。 |
| 日常實作的推進方式 | 依賴各自的認知策略。 |
有了這個共識後，展開型和壓縮型都能安心：「這裡可以用自己的方式推進，但別的地方要體諒對方的想法 / 切換認知策略」。
建立能評估雙方貢獻的基準 (双方の貢献を評価できる基準を作る)
即使達成了冗餘度的共識，如果績效指標有偏頗的話效果也有限。常見的「ticket 消化數」等績效指標，只有壓縮型的貢獻可被看到，展開型的貢獻仍然看不見。然而，這不是主管的怠惰，而是可觀測性的不同所帶來的自然結果。兩者的貢獻能被觀察到的難度結構性地不同。
| 觀測的性質 | 壓縮型偏向的貢獻度 | 展開型偏向的貢獻度 |
|---|---|---|
| 型態 | Output 型（能動的程式碼、修正的速度） | 累積型（文件、結構、ADR） |
| 效果觀測時機 | 即時 | 延遲（數月～數年後） |
| 局部性 | 局部的 | 分散的（經由他人） |
| 歸屬的明確度 | 明確（是誰的成果一目了然） | 擴散（順暢的 onboarding、防止未發生的問題等難以歸屬到個人成果） |
| 顯現化的條件 | 發生的事 | 沒有發生的事 |
特別是最後一行有決定性的影響。展開型的貢獻多數以「沒有發生的障礙」「進入狀況的時間被縮短」「事前被消滅的技術債」這種「反事實」的成果呈現。沒有發生的事情，在定義上，就難以被觀測和評論。如果組織不去有意識地記入這些貢獻，那麼這些貢獻就「不存在」。
組織需要的貢獻是對團隊產生了什麼有用的價值。舉例來說，讓我們從這個觀點思考，能更正確評估各類型強項的績效指標：
| 績效指標 | 被觀測到的東西 | 主要較容易發揮的類型 |
|---|---|---|
| 即時成果 | Release 完成、bug 收斂速度、局部分析的命中率 | 偏向壓縮型 |
| 大範圍探索 | 基於整個 codebase 的精確變更、找出root cause | 偏向壓縮型 |
| 持續性資產 | ADR、設計文件、runbook、test assets | 偏向展開型 |
| 發現型貢獻 | 被成功預防的災難、早期通報的結構性弱點 | 偏向展開型 |
| 養成・傳播 | Review comment 的教育價值、後任的學習速度 | 偏向展開型 |
各指標綁定的是行為，而非類型，所以同一人可以在多個指標被評估。此外，將「持續性資產」和「發現型貢獻」設立為獨立指標，就能將反事實的貢獻轉換為可觀測的對象。例如在事後檢討報告中紀錄「事前被發現到的疑慮」、design review 中每季盤點被迴避的問題、在 onboarding 時詢問「哪份資料有幫助」等等。如果沒有記錄下來，「那個人之前有表示疑慮但沒被處理」這類的記憶會從組織中消失。反過來壓縮型的貢獻也不只是單純的「task 完成數」，而是重新描述為「大範圍搜尋的命中率」「找到root cause的速度」，壓縮的認知策略所持有的強項就能被更正確地評估。
不過，各績效指標的權重並非固定。團隊被期待的行為偏向會隨著專案的階段和事業的盛衰而移動，leader 需要讓績效指標的權重與之連動。這裡要注意的是績效指標本身也有慣性。處於初期績效指標頂點的人，權重的變更等同於自身相對價值的降低，因此會產生心理抗拒。這是個人認同障壁的組織版。如果沒有審視績效指標本身正確性的循環(上位のサイクル)，專案的階段改變了但績效指標不動，現在組織真正需要的貢獻就會悄悄的流失。
最後再補充一個重要的事。設計績效指標的 leader 本身如果是壓縮型，就容易結構性地低估展開型的貢獻，反之亦然。人會無自覺地將靠近自身認知策略的指標加重、遠離的指標減輕。實務上減輕評價扭曲的方法是：不要讓績效指標的設計由一人完成，而是有意識地納入不同認知類型的觀點。
壓縮型如何獲得外部化能力 (圧縮型が外化スキルを獲得するには)
如機制章節所述，壓縮型獲得展開型能力是純粹的能力擴張。既有的壓縮力不會消失，新的記憶區域被追加。然而即使知道「有價值」，如果不成為習慣就沒有意義。借用 彼得·杜拉克2 的話，後天能力只能透過習慣來讓身體學習。
但在習慣外部化之前，有一個需要跨越的心理門檻。
雖然知道學會會比較好，但花時間寫一堆東西，跟自己的性格和價值觀就是不合……
對於長期作為壓縮型成功的人來說，「只靠腦袋思考就能快速做完」是證明自己能力的手段，也是自我形象的一部分。嘗試習慣外部化，首先會與那個自我形象衝突。然而，在習慣外部化時，無論如何都需要更新認知才能跨越。
這個認知很重要：外部化不是因為無法壓縮才勉強做的替代手段，而是在保持壓縮力的同時進一步增加可用記憶區域。
而且，請回想一下。在學校教育中花了好幾年訓練的能力，就沈睡在本人之中。也可以說只是「在寫程式的 context 中想起以前做過的事」。門檻比想像中來得低。
如果在未更新認知的狀態下只是執行「放到那種環境中去學/去學吧」這樣的「做中學」方式，只會增加壓力，而不會順利學會的。
實際上，能讓外部化變成一個習慣的因素因人而異，所以很難在這裡給出指引。例如，從模仿擅長的人的「尊敬的實踐者」開始也是一種常見的作法。例如模仿公司或業界裡「展開能力的高手」，就是最好的訓練方式。
對展開型「慢」的對策 (展開型の「遅さ」への対処)
更困難的是展開型。要突破大腦這個硬體限制很難。那麼另一個 parameter：提高壓縮率，是否就能在 working memory 中載入更多資訊和知識呢？
- 將眼睛和耳朵的輸入資訊以超高～超低的解析度進行抽象化/具體化，看穿「什麼是本質」。
- 收集這些資訊，找出能收進自己 working memory 的「有意義的區塊」。
有意識地試試看是有價值的3，但在已經超出 working memory 容量的情況下，不能期待會有什麼效果。
如果想讓展開型變快，與其強迫壓縮，不如朝著消除展開的瓶頸的方向前進更有效。
| 瓶頸 | 內容 | 改善方法 |
|---|---|---|
| 外部化速度 | 寫到外部的行為本身花時間 | 準備樣板、工具來降低時間成本。 |
| Context switch 成本 | 猶豫「繼續現在的作業還是對照外部」 | 整理外部資料的目錄、規定卡住15分鐘就參照外部。 |
| 目錄效能 | 找目標資訊很花時間 | 可搜尋化、統一放置、目錄或便利貼、標籤顏色等。 |
| 讀取速度 | 將外部的資訊讀回 working memory 花時間 | 將圖和文件結構統一為一看就懂的形式、放在不用找就映入眼簾的位置、貼在牆上。 |
想讓展開型變快，與其強迫壓縮，不如降低展開的 I/O cost。這是一個有效的想法轉換。
不同階段有不同的期待 (フェーズで期待される振る舞いは変わる)
團隊的認知構成沒有「永遠的正解」。隨著產品的階段(Phase)，團隊被期待的行為重心會改變。
| Phase | 被重視的行為 | 理由 |
|---|---|---|
| 初期（啟動・MVP） | 快速判斷、高速實作、最少共識 | 速度是活下來的條件。需要少人數快速成形。比起完美的設計不如先做市場驗證。 |
| 中期（成長・擴大） | 設計視覺化、onboarding文件、內隱知識的外部化、對應compliance | 團隊擴大，只靠內隱知識已經無法處理。 |
| 營運、維護（成熟期） | 設計文件化、SOP、架構review | 人員替換後仍能持續運作的機制會決定品質。 |
初期用壓縮型行為成功的團隊，如果進入成長期仍繼續同樣的行為，事業規模擴大時就會遇到困難。隨著不同階段的進展，需要有意識地提高團隊整體展開型行為的比例。這不是改變個人的性格，而是更新團隊的行為規範、前述的冗餘化共識和績效指標的權重。
作為人才的認知類型 (人材としての認知タイプ)
也觸及一下人才的觀點。不過，這裡是不適用單純二分法的領域。許多 junior engineer 仍處於尚未建立策略的未分化狀態。處理的問題範圍小，只靠 working memory 就足夠，所以認知策略尚未建立。
| 未分化 | 壓縮型 | 展開型 | |
|---|---|---|---|
| 人才庫 | 多（大家都從這裡出發） | 少（需要資質 + 訓練） | 少（需要經驗 + 獲得） |
| 傳統的招募手法 | Coding test 容易測量 | 只能靠實績和面談判斷 | 傳統手法難以測量 |
| 離職時的風險 | 低 | 大量內隱知識消失 | 留下外部化的資產 |
| 育成方向 | 可以分化為任一方 | 追加展開能力可擴大能力 | 高效的外部化可改善速度 |
要注意的是「養成方向」。未分化的成員可以朝任一方成長。如前所述，最初稱讚什麼、安排跟隨什麼前輩，都會左右認知策略的方向。不過，並非所有未分化的人都能建立某一方的策略。成為壓縮型需要 working memory 的資質和訓練，成為展開型需要外部化的獲得實作機會和容忍(工作慢)。也有一定的暗數在兩者都未獲得的情況下只有責任變多。
以前常說的「35 歲 programmer 退休論」的其中一個原因，或許不是因老化而導致的能力降低，而是認知策略未能跟隨環境scale up所致。二十多歲時處理的範圍小，只靠 working memory 就能處理的來，到了三十多歲責任變多，處理的資訊量開始超出容量。此時能已有外部化策略的人可以 scale up，但沒有該策略的人用以前的方式就已經處理不動了。
壓縮型人才因為在本身素質的延伸線上，職涯序盤就有嶄露頭角的傾向。不過如果是「仰賴二十多歲特有的體力和超強集中力」的壓縮型，因老化導致記憶力和集中力降低時，環境適應危機和自我形象危機可能會同時出現。另一方面，展開型人才因為是進一步升級，多會在職涯中盤以後而獲得外部化能力。兩者都不容易用 coding test 找到，等到需要時才開始找就太晚了。著眼於下個專案階段的人才計畫很重要。
今後會有什麼改變 (これから何が変わるのか)
AI 這個「擅長外部化的究極壓縮型」加入團隊 (AI という「外化に長けた究極の圧縮型」がチームに加わる)
AI 讀程式碼、寫程式碼、debug 的時代已經來了。用壓縮型/展開型的模型來看這個變化，會浮現出有趣且痛苦的畫面。
首先，AI 是究極的壓縮型。瞬間載入整個 codebase、大範圍掃描發現邏輯性錯誤、即使文件不足也能大致掌握 context——擁有巨大 working memory 的壓縮型。是人類無法到達的領域。
同時，AI 也擅長外部化。只需簡單的 prompt 就能生成配合讀者的文件、從會議記錄和 ADR 整理 context 和設計緣由、留下適當的 comment 和 log。也就是說 AI 兼具壓縮型的強項，和展開型在作業面的強項。
簡單來說，就會變成這樣：
| 能力 | 原本的擔當者 | AI 的取代程度 |
|---|---|---|
| 大範圍的程式碼探索・實作 | 壓縮型 | 幾乎完全可取代 |
| 設計的語言化・context 的整理・製作文件 | 展開型 | 大部分可取代 |
那麼，留給人類的是什麼？
| 能力 | 原本的擔當者 | 為什麼 AI 難以做到 |
|---|---|---|
| 建立「該問什麼」 | 兩者 | 需要質疑前提的批判性思考 |
| 判斷「該做出什麼」 | 壓縮型 | 需要市場・組織・user 的默認知識 |
| 判斷「為了誰而外部化」 | 展開型 | 需要團隊構成和未來變化的預測 |
| 發現非自我說明的 context・內隱知識 | 展開型 | 無法從 codebase 讀取的決策背景和未說明的前提，需要人類的 context 理解才能發現 |
| 判斷結構的扭曲 | 展開型 | 與邏輯正確性不同的、結構上的異狀 |
壓縮型在作業面的強項幾乎被吃掉。而且因為 AI 能補完壓縮型的弱點（不外部化），壓縮型使用 AI 就能取代展開型作業面的價值的大部分。對展開型來說，作業面的強項也有很多被吃掉。不過，展開型日常外部化的產出在成為與他人的交流的接點的同時，也直接成為對 AI 有用的輸入。為「慢」付出成本而累積的外部資產，在 AI 時代以別的形式保住了價值。
兩種類型共通的是，留下的不是作業而是判斷，以及更上游的「問題的建立」。
AI 對給定的問題回傳高品質的答案。但是留給人類的是「我們想做的是什麼？」「說到底這是正確的問題嗎？」「這個問題背後是否隱藏著別的問題？」「這個前提是不是有問題？」這類構成問題本身的能力，也是哲學和批判性思考的領域。
Coding Test 的劇變 (コーディングテストの動揺)
Programming contest 和 coding test 的劇變是這個變化的象徵。
這兩個測驗都是在限制時間內、不對照外部、解決有明確定義的問題。這種測驗形式是測量壓縮型的人能力的裝置。當 AI 能比人類更好地完成這類測驗，就代表了這個測驗測量的不是人類固有的能力，而是可被電腦取代的能力。
「那應該測量什麼？」的答案，或許出在兩種類型共通留下的判斷力和問題的建立上。從模糊的需求中判斷該做什麼的力量、判斷結構之美的力量、提出正確問題的力量。這些能力難以用標準化的方式來測量，但卻是AI時代要求的能力。
對教育的啟示 (教育への示唆)
這個模型也對教育有相同的啟示。
傳統的學校教育透過考試和背誦訓練壓縮，透過筆記和報告訓練外部化，兩方都有被均衡地訓練。正因為有這兩方面的基礎，人在職涯的任何階段都能朝需要的方向分化，也才能做到外部化能力的「重新活化」。然而，如果教育偏重其中一邊，這個基礎可能就會崩潰。
| 教育的重心 | 壓縮能力 | 外部化能力 | 職涯後半的基礎 |
|---|---|---|---|
| 傳統學校教育 | 以考試・背誦・心算訓練 | 以筆記・報告・圖表訓練 | 兩方面的基礎都有 |
| 偏重程式教育 | 用程式碼進一步強化 | 訓練薄弱 | 壓縮強但外部化能力弱 |
| 偏重 AI 教育 | 委託給 AI 因此沒被訓練？ | 委託給 AI 因此沒被訓練？ | 兩方面的基礎都沒有？ |
最後一行是最嚴重的。要駕馭 AI，需要自己建立該問什麼的力量、評估 AI 輸出的力量，這些能力建立在壓縮或展開、或兩者兼備的認知基礎之上。駕馭 AI 的能力是在沒有 AI 的情況下的思考能力的升級版，而非替代品。
題外話：個人的假說 (余談: 個人的な仮説)
最後，再提一個完全沒有科學根據的個人假說。
壓縮型和展開型，或許與文字優勢/視覺優勢4的認知特性也有相關。我的體感是壓縮型傾向以（文字、數值、程式碼）處理資訊，展開型傾向以空間性的 pattern（圖、配置、形狀）處理資訊。
| 特徵 | Verbalizer | Visualizer |
|---|---|---|
| 學習時的視線 | 長時間停留在文字 | 長時間停留在圖和圖像 |
| 資訊處理方式 | 線性的、逐次的 | 大範圍、全體的 |
| 問題解決策略 | 偏好語言性・非視覺性手法 | 構築空間性・圖示性表現 |
| 大腦活性區域 | 音韻處理區域（左緣上回） | 視覺處理區域（梭狀回） |
| 文字 + 圖像的學習 | 主要從文字學習 | 主要從圖像學習 |
| 學術領域傾向 | 心理學較多 | 工學是空間型、美術是對象型較多 |
最後一行可以觀察到，工程師多是空間型的視覺處理，這正好與展開型用架構圖和循序圖思考的特徵一致。
如果是這樣的話，以下的對比或許也成立：
| 場景 | 壓縮型（文字優勢） | 展開型（視覺優勢） |
|---|---|---|
| 筆記方式 | 文字、條列清單、大綱 | Mind map、圖、箭頭 |
| 記憶路徑 | 「第二個紅綠燈右轉」（步驟） | 地圖上的相對位置（空間） |
| 學習新技術 | 讀文件 | 實際動手做 |
| 監控系統 | Text log、alert | Dashboard、graph |
| 工作管理 | Text-based 的 TODO list | Kanban board、便利貼 |
| 程式碼的讀法 | 作為文字從上往下讀 | 先看 class diagram 或 sequence diagram |
| 設計的傳達 | 文字規格書 | 在白板上畫 |
| 時鐘的偏好 | 數位時鐘（作為數值閱讀） | 指針時鐘（作為空間閱讀） |
| 報告 | 文字為主、功能說明式 | 用圖表和動畫構成 |
如果你感覺有符合的部分，你的認知策略或許不只滲透到程式的寫法中，而是滲透到日常的各種場景中。
結語 (おわりに)
本文為工程師「做法的差異」命名為壓縮型和展開型，指出這些差異的大部分可能源自於認知策略的結構性差異。這裡雖然寫成像是個性，但實際上我覺得更像 丹尼爾·康納曼 的《快思慢想》5 那樣，是存在於同一人之中的兩個不同的認知系統。
無法避免的是，每個人之間擁有不同的認知策略。既然無法避免，理解別人是比較合理的作法。不把「那個人怎麼這樣？」歸因於性格或能力，而是重新理解為認知策略的差異，光是這樣就可以降低日常的摩擦成本。然後就能夠思考還能做什麼，才能往更好的方向前進。另外，團隊 leader 應該妥善調整，不要造成一方的認知策略強加於另一方的結構。
壓縮型是發現本質的力量，展開型是發現歪曲的力量。理解這兩者是互補關係，是最大化團隊認知能力的第一步。
順帶一提，你是怎麼讀這篇文章的？用圖掌握整體後再讀表格和粗體，還是一邊壓縮文章一邊讀？那或許就是你的認知類型。
留言
張貼留言
因為廣告太多了，留言會經過審核才顯示。通常我會每天看。