網友 EL 小姐在臉書上說賈伯斯不會對台灣的選舉表達意見，她真懷念蘋果執行長，她說 HTC 是中國品牌，這是王雪紅自己說的。她的看法引起了另一位網友 LU 君的不同意見，他說王雪紅和朋友的中國概念並不一樣，王雪紅和所有台灣人有相同的權利，沒有人可以否定她是台灣人的事實。

對 LU 君的質疑，EL 小姐提到賽斯說「世界上從來沒有兩個人真正地溝通過」，並且希望他能好好的想一想。從政治意識談到新時代的身心靈觀點，同人覺得 EL 小姐指出的問題很有趣。確實人與人之間不能溝通和個體之間的差異有絕對的關係，但我認為 EL 小姐所說的歧異並非本質而是表相，它是讓我們尋求整體一致性的必要開始。

為什麼世界上從來沒有兩個人真正地溝通過？賽斯也說過，話語最大的力量，並不在話語的本身，而在於話語之間的標點和停頓，它們蘊涵了說話者的很多情感，因而能夠產生強而有力的能量。我想這正是人們沒辦法透過溝通來分享意義，也就是讓彼此能夠進行「對話」來幫助思考的原因；這讓人沒有想到要在歧見之後停下來思考雙方其實是代表更大脈絡整體的一部分，只從片斷的差異性來分離彼此，否則他就可以尊重對方。在意於雙方的差異性，讓我們的信念只能創造彼此無法溝通的實相。

Mark Wu 對同人的上述觀點提出了他的想法，他說也許應該思考兩者間的不同。他提到了下面的觀點：

我想到朝倉啟太中解釋同理心的一段話，透過對話來了解雙方的不同點，就是因為體會到「對方與自己不一樣」，所以更尊重對方。

我是很喜歡這樣解釋的。因為再怎麼一致，只要有 1% 的不同，其實都很難去思考 99% 的相同 … 因為眼中只有「自己的不同」。那還不如更去正視雙方的不同 …

Mark Wu 認為對話不是尋求一致，而是積極地在不同中尋求解決。但實際上不同個體間的差異不見得能夠被解決（Resolved），卻需要去面對（Confrontation）由差異所造成的對立現象。當雙方出現的歧異太大，很多時候是不可能找到彼此都能接受的方案，更不可能要某一方去屈就於另一方的道理去做。因此如果彼此的溝通不能求同存異，那麼就不可能尊重對方的差異，也就沒有可以對話的立基點。

同人認為 Mark Wu 提到透過對話來了解雙方的不同點，就是因為體會到「對方與自己不一樣」，所以更尊重對方。這句話並不是不正確，而是在要在溝通過程中完全做到根本相當困難。想想看，如果我們確認自己絕對沒有錯，那麼對方一定有錯，而且還不知道自己錯誤真是錯得相當離譜。你真的能夠尊重這種執迷不悟的人嗎？這時候我們嘴巴說尊重或包容，其實只是宣稱自己比對方高尚的歧視，對方必然感受不到絲毫的尊重而讓彼此對立更加劇烈。分別心的執念擴大了非我族類的歧異，但其實這一切可能只是因為自我的迷惑。

對與錯和是與非，往往是一體兩面，關鍵在一體，但人多半習慣在兩面的執念。其實這個執念往往是我們一廂情願的想法，讓我們無法跳脫思想讓雙方共同創造整體的一致性。所以賽斯說「話語的力量不在話語本身，而在話語的間隔」，在歧見之後，如果在間隔之中我們只有抽取他人的片斷意義、以記憶取代思考、以確定性拒絕可能性、以及強迫他人以自己的觀點來看事情，那麼雙方就只能各說各話。除非我們改變另一種不一樣的溝通行為，歧見便是雙方得以共同思考的起點，以創造出更大的可能性，來達到「對話」的目的－共享意義。

近年來台灣因為政治因素的影響，使得社會上的歧見很難相互對話，這是令人憂心的事情。同人很喜歡《深度匯談》提及的對話的一致性原則及尊重行為的觀點，這本書提到下列幾個相關的內容：

1. 在我們不願意接受他人的看法時，表示我們對該項看法沒有產生任何的關聯性。在這種情況下，我們常常會忽略別人的看法其實擁有一致性的意義，而我們只是一味地拒絕接受，認為他們就是不對的。我們如果真的這樣做，一定會忽略別人思想與經驗的正當來源，而這些思想與經驗都是我們加以探求就可以理解的。假如我們拒絕瞭解他人的看法和經驗，就是堅持在自己和他人之間製造分裂的狀況。
2. 對話的基礎就是，認知到這世界為無法分割的主體，而問題就在於我們沒有清楚瞭解這個事實。世界已經是完整不可分割了，而我們面臨的挑戰是以各種方法來洞悉這個事實。
3. 「尊重」這個動作的核心精神，是將他人視為「正當的」個體，即使我們不喜歡他做的事、說得話或思考方式，但我們仍然無法否定他們是「正當」生命體的事實。

看完上面這些有關一致性原則和尊重行為的內容，再看看台灣在總統大選後的社會氛圍，不知你看到了什麼？同人認為他人的歧見絕對不是整個社會無法理性對話的原因，關鍵在於我們能不能尊重差異，在歧見之後的間隔中思考彼此的一致性觀點，以促進提昇整體社會的進展。因為偏好不同而否定其他人的正當性是沒有用的，因為世界是不能分割的整體，分離意識只會造就自我與現實矛盾的衝突。

同人上週四才剛回到家，老婆就說我們家漏水了。她說帶女兒放學回家之後，女兒發現靠近浴室的牆面下有一大攤水，牆壁也出現水痕和潮濕的現象。老婆趕緊拿抺布來擦乾地板並且塞了乾的抺布到牆邊來吸水，這時候樓下的王媽媽出現告訴老婆她們家漏水了，而且情況比我們家還嚴重，她表示四樓前不久前才裝修完房屋，懷疑很可能是因為四樓裝修不慎而造成我們家和她家漏水的現象。

同人家住一樓，兩個月前才修好後陽台熱水管路的漏水問題。當時，也讓王媽媽家中飽受漏水的困擾，讓她們半夜都無法安眠。當老婆告訴我家裡發生漏水的情形發生之後，雖然我認為出在家中管路問題的機率應該不高。但對於王媽媽對漏水現象原因的假設，我覺得應該要有具體的根據來證明它的合理性，因為雖然四樓最近裝修了浴室，但二樓和三樓都沒有漏水，換作是同人也沒辦法相信因為四樓的裝修而造成一樓和地下一樓的漏水現象。

晚餐之後，老婆到樓下王媽媽家去了解她們漏水的情形。回來之後，老婆說王媽媽的狀況真的非常嚴重，並且提到四樓要找人在週六或週日到我們家，查看漏水是不是因為她們家施工造成的問題。後來老婆在我們家樓上夾層的房間發現牆壁也有潮濕的現象，這樣看起來的確很有可能漏水不是我們家管路漏水的問題，因為漏水通常不是從上面流到上面，而是從上面往下面流，所以造成漏水問題的來源很可能在我們家的樓上。

接下來我們等了兩天，在這段期間中，我們必須不斷地更換塞在牆邊的抹布，潮濕的抹布因為連日陰雨不容易晾乾，甚至必須找一些破舊的衣服來充當抹布。到了周六早上，王媽媽上來問我們四樓的人有沒有過來看漏水的狀況。我回答說沒有，王媽媽希望我打電話過去問看看，不要讓對方以為只有王媽媽家裡有受到影響。

同人撥了電話，接通之後我向對方表明身份，並說明我家和樓下王媽媽家漏水的狀況。對方四樓的景小姐認為他沒有動到水管，我則表示不確定她的疑慮是否存在，她當然可以朝這些方向提出明證，但由於漏水發生的時間和她裝修房子有時間的巧合，我覺得兩者或許會有關係，打電話給她只是想傳達我和王媽媽家漏水的狀況都十分嚴重，撥空到我們家察看對釐清責任也會有幫助。

景小姐表示她會找時間來看，只是最近很忙，她要再安排時間，並向我表達造成我們困擾的歉意。直到傍晚，我都沒有看到景小姐，也沒有收到她的任何消息，這時候樓下王伯伯和王媽媽來了，王伯伯表示我們兩家原來都沒有出現漏水的現象，一直到四樓裝修之後就發生漏水了。他認為這水很可能是從四樓的管路漏下來的，他一直想找四樓出面來確認是不是這個原因，但卻都一直找不到人。

王伯伯建議大家一齊上樓把四樓那一戶的總水開關關起來，我們在到頂樓水塔前還問二樓有沒有發生漏水，二樓回答沒有漏水不能證實漏水是四樓的問題，後來因為我們無法確認那一個水錶是四樓的，還是沒有關閉四樓的水源總開關。大家討論覺得到找主委出面協調解決這件事，但當我要打電話的時候，同人嫂卻覺得有問題而阻止我聯絡主委。果然後來王媽媽的兒子來電告訴我們，主委在下午已經和四樓達成共識認為漏水事件和他們家的裝修無關，要我們兩家共同找水電來檢修漏水的問題。

老婆覺得漏水有可能是我們家的問題，即使我們家水管會突然漏水的機會並不高，但至少要先懷疑自己家裡沒問題，才有立場質疑是別人家的問題。於是同人到頂樓水塔關閉了我們家的水源總開關，結果漏水現象好像有減緩的跡象，第二天，樓下的王伯伯和王媽媽很驚訝地跑來告訴我們他們家不再漏水，同人才確認漏水事件是因為我們家管路問題所造成的，並且告知王伯伯和王媽媽我們會找水電來修好它，在修復之前我們都不會把我們家的水源總開關打開。

還好同人的房屋瑕疵保固尚未超過民法規定的六個月，我們會要求前屋主負起漏水問題修繕的責任。雖然在漏水問題修復之前我們家都無水可用，還真是令人感到困擾及麻煩，但這個過程卻讓同人體悟到易經乾卦九四「或躍在淵」的道理，實在是非常寶貴的教訓及經驗。

有道是「聽某嘴，大富貴」（台語），她反對同人打電話給主委，要我緩和一下衝動的情緒，這讓我想到我們面對的正是易經乾卦三爻和四爻的凶險處境，面對這種危險的境地，惟有從自我反省和警愓才能及時採取適當的做為來避免犯錯。

雖然四樓的景小姐沒有履行他的承諾而令人失望，但萬一真相不是因為她裝修房屋而造成漏水，我們的行為豈不更顯得魯莽；而且就算漏水事件真的和她的裝修房子有關，沒有自我檢測之前就懷疑別人也違反了信仰的道德。其實我一開始就了解這個道理，但看到王伯伯和王媽媽的慘境，感染到他們緊張的心情而忘了處於危險處境的因應之道。《易經》乾卦〈文言〉曰：

九三曰：「君子終日乾乾，夕惕，若厲，無咎。」何謂也？
子曰：「君子進德修業，忠信，所以進德也。修辭立其誠，所以居業也。知至至之，可與幾也。知終終之，可與存義也。是故，居上位而不驕，在下位而不憂。故乾乾因其時而惕，雖危而無咎矣。」

九四：「或躍在淵，無咎。」何謂也？
子曰：「上下無常，非為邪也。進退無恆，非離群也。君子進德修業，欲及時也，故無咎。」

……

九三，重剛而不中，上不在天，下不在田。故乾乾因其時而惕，雖危無咎矣。
九四，重剛而不中，上不在天，下不在田，中不在人，故或之。或之者，疑之也，故無咎。

當人處於乾卦的三爻和四爻的情況，會面臨所謂「不三不四」的混亂。由於情況多變詭譎難測而埋藏許多危機，此時必須因其時而愓，以忠信來進德、以修辭立其誠來居業，這樣就算是在上位也不驕，在下位也不憂，所以情況雖然凶險也不會有過錯發生。

在混亂的局勢中，從顛峰掉落到谷底不見得是因為個人的邪妄所致，而是因為世事無常；進退沒有按照常理也不是因為想表現與眾不同，而是因為時機不同的緣故。君子應該在德業上下功夫，在適當的時機修正自己的行為，所以才能夠在危險的境地中不發生過錯。

因此，從乾卦九三的「行事也」，關鍵在因其時而愓，到了九四的「自試也」，重點乃在懷疑自己有沒有問題的自我檢視的態度。只有在確定自己沒有問題之後，「或躍在淵」乃是在適當的時機讓自己更上一層樓，而達到飛龍在天的狀態。這是「上治也」的境界，但它除了機遇之外，更需要機遇在尚未來臨前的自持功夫。從房屋漏水事件可以體悟「或躍在淵」之道，深覺在生活中，易理真是無所不在而且非常有趣呀。

溫伯格說官僚是每件事都在掌控中，但是一切全都失控了。他提到：

當專案規模變得相當龐大，通常就會因為專案成員對整體狀況缺乏掌控，不了解本身工作與整個專案的相關性，而導致官僚作風出現。

在這種情況下，大家一定會在不知不覺中做出危害品質的事，甚至會阻礙到專案的完成。這就是官僚－人們不明究裏地在做事。

要評量軟體開發組織的「官僚特性」（bureaucratic nature），溫伯格認為可以藉由有多少事情在不明究裏的情況下完成。他指出在不明究裏的情況下完成事項，占完成事項的百分比就是評量官僚的一種方式。

想要減少團隊的官僚特性，管理者應該要讓團隊成員充分了解專案計劃。溫伯格提醒管理者有計劃還是不夠，應該要讓參與專案的團隊成員了解計劃，並且透過傳達與溝通讓每一個人都了解計劃。他強調只有高層了解的秘密計劃（而且就連高層自己也不太清楚這些計劃），勢必會在大型專案中引發官僚之災。

溫伯格的觀點解釋了在軟體開發團隊常見的官僚特性。在軟體開發過程中，人們不知不覺犯下危害軟體的品質或阻礙專案的進行的錯誤，通常並不是因為計劃不夠完整，而是因為團隊成員缺乏對專案計劃的整體了解。專案成員從專案計劃知道他的任務，但卻不知道他的任務和整體專案的關係。

換句話說，團隊成員知道他應該做什麼、和如何做，可是卻不知道為什麼要這樣做，工作只是由上面丟下來交辦，他只是奉命行事而已。比如說：

• 程式開發者按照系統設計規格開發程式，可是卻不知道為什麼系統要這樣設計。
• 系統設計者按照系統分析規格設計系統，可是卻不知道為什麼系統要這樣分析。
• 系統分析者按照客戶提出的需求來分析系統，可是卻不知道為什麼系統會有這個需求。
• 管理者覺得開發者沒有把事情做對，可是卻總是不早點告訴開發者什麼叫做把事情做對。

為什麼團隊成員在他們不知道為什麼的時候，不先溝通把事情的來龍去脈弄清楚才開始執行任務呢？可能是團隊成員的能力只能知其然，而不能知其所以然；也有可能是因為團隊成員的態度並不想多花心力去了解事情的根源。同人認為不管是成員能力或態度的因素，管理者都應該要為開發團隊的官僚特性負起最大的責任。

因為軟體開發團隊的官僚特性本質上是品質文化的問題，基本上和管理者的態度及核心價值觀有關。如果程式的開發者不能了解程式和設計、需求、乃至於其所要解決的問題，就很難確定他能夠在正確的問題方向上思考，以發展在正確問題下的有效解決方案。也許他做不到的原因是因為尚未培養面對問題獨立思考的技能和習慣，但如果管理者不能在團隊中建立共享語意庫或增進共享意義暢通的管道，要求開發者要有能力知其所以然只是緣木求魚罷了。

從另一種角度來看，團隊成員在態度上不想多花心力去了解事情的根源之真相，很可能是管理者在態度上並沒有鼔勵團隊成員多多參與討論、以及提供成員表達個人意見的管道。即使管理者在言語上聲稱他們願意接受不同的建言，但實際上面對團隊成員提出不同意見的質疑，卻是表現出不能接納建言的行為。慢慢地，團隊當中自然愈來愈沒有人願意表達他們的異議，成員傾向聽命辦事來規避把事情攬在自己身上，於是讓這樣的心態更加深團隊的官僚特性。

當然，管理者因為態度而加深開發團隊的官僚特性，最後必然會「個人造業個人擔」。最後團隊有想法、有抱負的「年輕人」會愈來愈少，只知道制度和規範而忽略思考創新的「老人」愈來愈多；這裡指的年輕人和老人不是基於年齡，而是基於成員面對問題的心態。當團隊的大部份成員都已經心態老化，思考僵化是軟體品質不良的根本原因，不論管理者加深團隊的官僚特性是有意或無意，他都必須為此承擔相對的代價。

「年輕人」比「老人」對事情的「理所當然」更不以為然，因此前者可以透過思考和創意來創造更多的可能性，這正是後者限於官僚特性所看不到的世界。

同人記得聽過某個長官曾經對下屬提的意見表示：「不要只提出問題，要有 solution！」不過接下來聽到另人激賞的反駁：「如果要有 solution 才​能提問題，那誰敢提呀？」表現對官僚特性的反抗，當然反抗的結束是最後反駁者終於離開那位長官的團隊。

同人不知道那位長官心中到底有沒有意識到「如果這麼快就可以有 solution，那根本就不成問題」的真相，但我知道他的管理風格無法適應會對「理所當然」質疑的思考者，他只能「管理」聽命辦事的工作者，也許只有加深團隊的官僚特性才能減輕他對管理彈性不足所反應的焦慮吧！

XDite 在文章中前半段，提到他對做測試的看法：

我個人的看法是認為在大多數的情形下，你需要對你的「軟體」寫 "Test"，而且是要先寫 "Test" 再行撰寫程式，也就是 Test-Driven Development。因為程式碼會逐漸龐雜，沒有人可以 write code without bug，也不可能每次都有辦法用手測出來，加上有時候寫錯程式時的損失不是事後修理就有辦法彌補的，所以我們必須要寫 Test Case，及早抓出問題。

XDite 說這是所謂寫測試的重要性。但他強調這卻不是程式設計師「可以」不合時宜的盲目在「任何類型」的專案強行導入 BDD / TDD 的藉口。XDite 指出寫測試程式來確保程式正確性的解決方案，存在著額外多付成本的代價，亦即：

1. 「 寫測試 + 寫程式」 所花的時間，大概是純寫程式的 1.5 -2 倍時間。
2. 「會寫 Test」、「正確的測到該測的部份」、「寫出好的測試」，都需要學習時間以及功力。

於是 XDite 提出了四點原因，用來當成反對盲目 BDD/TDD 的理由。即使是程式設計師因為厭倦了維護在之前的專案後期的維護，因為修改程式碼而一再發生的問題（無論是小問題，大問題），而決定在下個專案，無論什麼專案類型都要導入 TDD / BDD，XDite 認為這在他眼中認為這是相當不正確的事情。

1. 每個專案類型不盡相同，有的是要求高正確性且牽扯到金流問題且開發時間充裕。有的純粹只是 event，用過極丟。有的是幫人外包，只要求規格正確，開發時間不寬裕。有些則是混合型。有些部分的程式碼則是相當難以寫測試（如 View），C/P 值極低。應該考慮每個專案的類型甚至是 component 去決定哪部分該嚴厲的規定寫測試，而哪些部分可有可無。

2. Startup 前期應不應該導入 TDD/BDD ? 我認為不應該。為什麼，很多人都認為 TDD / BDD 是為了確保「程式的正確性」，所以無論如何我們都應該執行。卻忽略了 Startup 的成功要素是「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」。

3. 寫測試只是為了要能自動驗證「程式的正確性」、降低「程式出錯的機率」，但團隊合作開發程式最重要的是團隊中的「溝通」，大家對 function 和架構要有一定程度以上的理解，共同撰寫程式要有一定程度以上的 convention。變更任何重大架構（如 core function, db schema, 底層設計前）都要提醒大家。

如果每個人都只寫自己的，然後想改什麼東西照自己心情，沒有人想舉手之勞通知大家、跟隊友溝通。坦白說，那寫測試有個屁用，可能只是不會爆 production code，development 拉下來還是爛光光，還是要修到死。

完全不溝通、不制定規範，卻期待寫測試能夠解決一切，這樣的想法不是很奇怪嗎？

4. 無論如何，就算寫了再完美的測試，再完美的程式碼。程式還是可能在你完全預期不到的狀況爆掉，所以應該做的是要接受無論如何就是要修 bug 的這件事，然後想辦法把修 bug 的成本儘量壓低，也把因為 bug 會產生的損失也儘量壓低。

不要期待測試是萬靈丹。否則期待越大，失望也大。

到底是評論 TDD、還是做測試？

同人覺得 XDite 這篇文章的論點令人混淆；他到底是在評論盲目導入 TDD 的行為、還是在探討開發者該不該多花時間寫測試程式，以確保「程式的正確性」？這兩者完全是不能相提並論的事情，同人很不能理解在前面提到寫測試程式來確保「程式的正確性」需要花更大的代價，而下一段就拿寫測試程式必然會忽略其它開發活動（如溝通、修正程式 bug 等活動）來否定 TDD/BDD 的價值。

難道 XDite 以為 TDD 就只是在做確保「程式的正確性」之測試而已嗎？假如 XDite 真的是這樣認為，那麼顯然他把 TDD 誤解成是在做測試。不過，對於同人在文章後面留言提出的質疑，XDite 回應否定他把 TDD 誤解成寫測試，而是不喜歡一些沒有把 TDD 搞清楚的人，強行要把「TDD」和「測試」混在一起，綁在一起要求無論如何都要「TDD」。他提出了一種典型把測試跟 TDD 混淆綁在一起的狀況，是遇到下面這種混蛋邏輯：

因為程式會爆炸，或者是以後改來改去又會暴很麻煩 => 所以我們需要寫測試 => 既然要寫測試，也許我們不應該事後補寫 Test Case，而是應該來試著 TDD。

另外，XDite 還提到理想狀況開發者可以用 TDD 來開發產品，先寫測試去制定出規格，然後寫出實際程式通過測試，達到 System Design。接著藉由不斷的寫新測試、新規格，然後寫出更多的程式，邊修邊測到 boundary。但現實狀況是，就算是熟悉 TDD 的開發者，他卻不一定是「規格」、「設計」的主導者。

XDite 說在這樣的「現實狀況」，很多時候， Team 裡面有開發者不能強迫導入 TDD 的環節。強行推動只是互相絆倒和拖垮彼此的時程。XDite 認為 TDD 只在某種「單純」（專案成員素質接近一致，沒有 highly dynamic factor，目標單純）的專案、環境、Component 下適用。

雖然 XDite 對他的觀點，似乎並沒有留下和同人繼續討論的空間；我發現我後來的留言被當成 spam 處理。同人猜想也許他的文章說歡迎指教，但我的留言讓他感到威脅、或是覺得再繼續討論壓力太大，於是想中止和我就這個議題繼續討論。同人不想責怪他對我留言的反應，即使他這樣做只是要表達內心情緒的不滿，但我仍然不會停止對 TDD 的這個討論主題的思辨，並且會透過網誌來表達我的觀點。

評論 XDite 的四點理由

XDite 提到他不喜歡把「測試」和「TDD」綁在一起的混蛋邏輯，但它反對不管怎樣都要導入 TDD/BDD 的原因，卻又以寫測試案例的「極端」現象來反駁 TDD 的價值，顯得不合邏輯。

在 XDite 寫的四點原因中，除了第二點有明白地表達不該在 startup 前期導入 TDD 之外，其它三點看起來都好像是在批評寫測試程式的問題（還不論是不是先寫測試程式）。因此，這樣看來就很令同人費解；如果真如 XDite 所說的他不喜歡人們把測試和 TDD 綁在一起，怎麼會把寫測試程式出的問題都算在盲目導入 TDD/BDD 的頭上？如果連自己在談 TDD 的時候，都會和寫測試程式的問題牽扯不清，那麼又怎麼能責怪別人把「測試」和「TDD」綁在一起呢？

同人認為在 XDite 所提到的四點原因，它們並非錯誤，而是並沒辦法當作反對不管如何都要導入 TDD/BDD 的原因。雖然在第一點原因中 XDite 並沒有說錯，有些程式像是使用者界面程式的測試程式就很難寫，因此的確不大適合強行對他們進行 TDD。然而，當遇到這種情況的時候，使用者還是可以選擇用 Mock Object 把那些沒辦法寫測試程式的物件區隔起來，然後針對最多部分可測試具有演算邏輯的程式來進行 TDD。

因此，使用者界面程式沒辦法建構 TDD 的測試程式對於 TDD 而言，並不是什麼太大的問題。因為基本上 TDD 不是用來當做測試的工具，而是用來設計可以驗證符合使用者真實需要的工具。所以開發者只要針對可測試、或該測試的部分建構測試案例就夠了。TDD 的目的是要確認花費最小的努力來滿足使用者的需求，測試案例所要求的不是全面的完整，而只是確認達到剛好達到滿足需求的邊界，這將會促使開發者先以界面的思維來整合系統各要件。對 TDD 測試案例比較重要的問題，是如何設計可測元件與非可測模組之間的界面。

至於 XDite 提到對於某些程式沒有必要寫 TDD 的測試程式，同人倒會很好奇有什麼客觀標準、或是有誰可以決定什麼程式沒有建構 TDD 測試案例的必要？在同人導入 TDD 的經驗中，就曾經有開發者要求 Business Object 不要寫 TDD 的測試案例，當時他們的理由是它們沒有什麼太複雜的邏輯、而且不大容易會變動，所以應該不需要為它們建構 TDD 的測試程式。

然而，事實證明，接受開發者這個要求的決定，是整個系統發生苦難的開始。因為所有的問題都從 Business Object 的瑕疵開始引爆，直到把 Business Object 也納入 TDD 測試案例的範圍，系統程式的品質才能達到令人接受的水準。

再來，對於 XDite 唯一有討論到導入 TDD 的第二點，他認為 startup 前期不應該導入 TDD，因為 startup 的成功要素是「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」。然而，同人對此卻認為恰好相反，TDD 正是「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」的利器。

為什麼？不用 TDD，人們多半傾向會以自己所相信的基本假設來解答問題，也就是以自己的經驗或熟悉的事物，從核心出發來發展解決方案，以期待把事情做正確。在這種情境下，人們通常會想得太多，而容易有過度設計（over engineering）的傾向，而 TDD 則可以讓人回歸到從問題來決定系統的邊界，再以最符合經濟效益的方式來解決問題。所以自然能夠以最省時及省力的方式來做正確的事情，更可以在市場上獲得致勝關鍵。

XDite 說他不同意「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」，是「對 TDD 再適合不過」。但同人很清楚這「對於熟悉 TDD 的開發者而言」是很自然的，顯然 XDite 是忽略了我認為這句話成立的前提，在於開發者是否能熟悉使用 TDD 的節奏。

如果開發者熟悉 TDD 的節奏，當他沒辦法寫出測試程式的時候，代表他對系統所要解決的具體問題還不夠清楚。為了要弄清楚他必須更清楚去溝通，而且 TDD 的習慣會促使他傾向以使用者的情境去溝通，而不是拿功能要使用者告訴他該做什麼。只有在開發者瞭解使用者的情境之後，開發者才能具體而正確地寫出驗證程式的測試案例，這說明在 TDD 寫的測試案例不是做測試而是在做設計，而且不可能因為寫 TDD 的測試案例而讓開發者不做溝通。

所以 XDite 提出的第三點和第四點原因，或許對於做測試是可能成立，但在 TDD 的情況下卻是可能性很低。因為除了建構 TDD 的測試案例需要了解使用者情境更需要溝通之外，TDD 的測試案例本身就是有用的溝通工具。TDD 的測試案例是能夠經過驗證的具體規格、同時它也是相關元件、API、或是模組的範例程式。

當然 TDD 更不會有太要求測試程式的完美，而忽略修正 bug 的問題，因為 TDD 的測試案例並不要求完美，而只是夠用就好。而且 TDD 在實際上可以用較低的成本來修正 bug，因為它能夠自動發現錯誤，再加上重構能夠逐漸改善程式碼的品質，TDD 沒辦法確保程式一定不會出現錯誤，但它總是能夠以較低的成本得到較高品質的程式碼。

TDD 必須很「單純」？

XDite 說 TDD 只在某種「單純」（專案成員素質接近一致，沒有 highly dynamic factor，目標單純）的專案、環境、元件下適用。但在同人導入 TDD 的成功經驗中，很不巧就有專案、環境、元件不單純的例子。

在一個國內知名金控公司的銀行外匯系統建置專案，表面上專案的目的是為了建置新一代的外匯系統，而不想受制於舊有系統和廠商的牽制，但實際上客戶高層的想望是要架構能夠整合機構其它系統的基礎建設平台。然而，當詢問客戶高層對系統目標的意見時，他們給的回答竟是「把系統做到令客戶咋舌」這種有說等於沒說的答案。

專案的成員並非來自開發組織的單一部門，而是從各個組織挑選各種經驗和背景的人，雖然有專業能力資深的人，但也有對相關技術不熟悉的成員。可以想見，在專業、技術、能力、背景如此懸殊的情況下，因為「人的問題」而發生團隊衝突是很難避免的，這個專案的團隊衝突的課題，正好提供我碩士論文的研究動機。

當時開發團隊過去沒有接觸過相關問題領域的經驗（事實上是客戶指定不希望找對有金融經驗的人來開發，公司沒有開發過相關領域的專案，而有不錯的系統建置專案，才是客戶會選擇我們的主要原因）、開發環境也是用開發團隊過去完全沒有經驗的技術。

客戶指名這個專案要使用 SOA 架構，由前端 JSF 以 Web service 呼叫到 Application Service，呼叫後端直接存取 POJOs 或是傳送訊息的服務、而中間物件的傳遞則透過 XStream 的序列化以 JAX-RPC 進行遠端傳送、至於元件包括軟體架構也都是從無到有按照系統需求逐漸演化成型。

專案團隊大部分的人都沒做過 TDD，加上這麼多「高度動態的因素」，而導入 TDD 竟然能夠成功，是因為我們運氣好嗎？這麼說必須忽略開發組織守舊勢力對新方法論、架構和技術的反撲，否則就很難解釋公司總經理的質疑和反對。實際的情況是我們不是運氣好，而是用對的方法讓我們做好準備。當公司高層開始質疑的時候，我們早就已經透過 TDD 快速驗證我們的方法沒問題，而讓總經理無法否決我們的設計成果。這讓人目睹 TDD 的真正價值所在，不是確認「程式的正確性」，而是讓人有勇氣並保持簡單的節奏。

同人認為 TDD 的成功並不在 TDD 自動確認「程式的正確性」，而在於TDD 讓人有勇氣把事情做好，讓人遵循良好解決問題的節奏和紀律。那就是：1.確認問題；2.依照問題情境，發展用來驗證方案的標準；3.設計方案並執行驗證，以達符合驗證標準；4.視組織需要改善方案，再次執行驗證以確認符合標準。

依照這樣的節奏和紀律，可以讓人在確認方案做正確之前，已經驗證方案是用來解決正確問題，以避免過度設計和設計不足的兩難。這正是傳統方法很難避免的問題；即使開發者擁有熟練的開發技術，但少了在事情做對之前先做正確事情的紀律，品質問題正是因此而叢生。

現實的真相

XDite 用「理想狀況」來反駁用 TDD 來瞄準、射擊、修正後再射擊的觀念，他說很多時候， Team 裡面有開發者不能強迫導入 TDD 的環節，強行推動只是互相絆倒和拖垮彼此的時程，這是所謂的「現實狀況」。這麼說似乎是意味了 XP 敏捷方法的 TDD 實務無法在「現實狀況」實行，而是「理想狀況」。這種說法對同人其實並不陌生，就像我在〈羅馬不是一天造成的〉這篇文章所提到的情形：

同人偶爾會與 X 君分享我的工作心得，他很羡慕我能夠堅持設計的理想，遵循好的設計原則及開發方法發展出軟體架構，像他就沒有這樣的機會。而和同學分享我的工作成果時，他則認為我堅持設計理念可以成功，是因為我們公司有足夠的資源可以讓我們玩，換成是小公司，就不會有這樣的成功條件。

其實同人在那篇文章所提到的概念、架構和技術的驗證，所用的方法正是 TDD。但同人分享成功經驗看到人們的反應卻發現，除了羡慕和佩服之外，多半是認為我剛好遇到足夠的條件來支持我實踐理想，而他們的「現實狀況」一定不允許他們這樣做。

假如真的是「現實狀況」不允許開發者導入 TDD，那麼面對開發出來的軟體品質不彰，他們採取了什麼行動來面對現實呢？以同人在一家開發軟體產品的 startup 公司看到的「現實狀況」來看，他們只是試著更努力而辛苦地把過去的工作做得更好，可是彷彿都一直不能如願。

同人在那家公司分享過我的 TDD 的經驗，RD 經理認為或許應該要做 TDD，可是因為使用資料庫的關係，會讓 TDD 很難做到或是做了沒有太大的效益。同人並不太瞭解為什麼他會有這種顧慮，因為按照我過去的經驗，資料庫的部分可以用 Mock Object 或是 Hash Map 版本的實作來區隔開來，而且這樣做有優化設計的好處。不過，同人不便公開質疑主管對 TDD 的顧慮，而是選擇尊重他在「現實狀況」下的決定；等到適當的時機再導入 TDD，除了眼下的問題需要被克服之外，還要讓開發者們的步調都能一致。

直到同人離開那家公司之前，TDD 都是一直被人們掛在嘴巴上說，但從來未曾真正去做。然而，隨著需求愈來愈多，程式碼也愈來愈複雜。這時候，關於軟體品質愈來愈殷切的議題便是元件很難被獨立測試，而是必須整塊合在一起才能測試，但這在除錯上很沒有效率。於是各個元件要獨立測試變成一項非常重要的需求，但滿足此項需求最大的問題便是軟體架構需要動大刀，而更緊急的嚴重問題便是有一大堆在客戶端的 P1 和 P2 的 bug 需要解決。

於是在龐大的時程和品質壓力下，常讓 RD 和 QA 沒辦法在時限內產出符合品質要求的軟體。我們用的方法，就是一次又一次的讓 RD 以大規模前置設計（BDUF），然後等程式開發完成之後再 handover 給 QA。雖然表面上公司採用敏捷的開發流程，每天在固定時間召開 Daily Stand-Up Meeting，但是看起來專案管理者的腦袋並沒有換成敏捷的思維，仍然是期待以更精確的預測來改善專案的進展，即使是他們對專案狀況的預估從來沒有準確過。

在這種「現實狀況」下，雖然同人已經提醒 Scrum 偏重管理面而非工程面，但由於 RD 經理對 TDD 仍然有疑慮而不敢貿然採用它來提昇程式的品質。整個開發團隊只是一遍又一遍地用和昨天用過的方法，來試圖解決今天相同的問題，但我發現專案管理者好像不合邏輯地希望得到不一樣的結果。它正符合愛因斯坦對精神錯亂所下的定義：

一遍又一遍做同樣的事，卻期待不同的結果。

同人看到專案管理者對「現實狀況」的理解是，因為開發者在事前（不用心而）想得不夠多，所以不能在一開始就把事情做對，而導致軟體運行發生錯誤。但同人認為「現實狀況」的真相卻是，關鍵在於開發者沒有辦法做正確的事情，在很多時候設想了太多無謂的問題，而把心力分散在處理瑣碎的事情，而無法專注在關鍵問題上思考。

這是因為無法快速驗證方案對解決問題的效果，往往在開發者花費大量心力脫離「焦油坑」之後，才發現真實情況有很多地方是無先無法預料到的。換句話說，這不是開發者做的東西不對或是不好，而是面對適應變化，沒有把握「動作要快、行動要小」^[1]的原則。

當然在「現實狀況」下，導入 TDD 的實務不見得真的能夠有效地解決問題，對於任何一種開發方法論，我們都不應該盲目導入，而是要弄清楚它的適用範圍和限制，TDD 當然也不例子。然而，對於把 TDD 和做測試混為一談，然後藉此推測團隊中「一定」有 TDD 不能強迫導入的環節，強制推行只會互相絆倒和拖垮彼此時程，同人認為這是扭曲 TDD 當成做測試的繆誤。

使用 TDD 來開發軟體，開發者實際花費在測試案例的時間並不會很長。因為程式開發者不可能只寫程式而不驗證自己的程式碼，否則無法確認程式符合規格，就不能認定他已經寫完程式了。既然驗證程式碼是他的責任，那麼測試先行只是確認程式碼符合規格的一種方式，這樣只是把後面應該執行的工作先做好，並不會增加開發者額外的工作量。

因此建構 TDD 的測試案例並不需要額外的工作量、也不大可能會因為執迷於測試而沒有花時間溝通共通架構、或是程式的 debug 時間。又能節省開發者因為想太多而多花費過度設計的時間，而且可以支持驗證程式的重構來加強程式的結構，不會因為增加功能而影響程式碼的品質。

TDD 在開發程式之前先寫測試案例的用意，並不是為了及早自動抓出問題。雖然這通常是採用 TDD 能夠產生的附加價值，但 TDD 先寫測試程式的精神是為了驗證未來方案能夠符合需求，以確認方案是在正確的命題方向上發展。開發者發展解決方案，每前進一小步，都能夠知道這一步離他的目標更接近或是遠離，這讓他可以馬上採取行動來調整方向以減少偏差。於是開發者可以做到真正的面對現實，這正是掌握適應改變行動要快、動作要小的原則。

不理究理者的未嘗知義

採用 TDD 來開發軟體，並不能做到確保程式的正確性、或是降低程式出錯的機率。因為要做到這個目的你就必須「預測」程式會發生問題的一切可能性，並且預先把它們都放到測試案例中，才有可能達到這些目的。然而，事先做預測已經違反了敏捷開發的基本原則，也違反了 TDD 的基本精神，認為 TDD 的目的是為了確保程式的正確性、或是降低程式出錯的機率而把它和做測試混為一談，這只是不明究理的人未嘗知義的偏見。

就像在網路社群中，James O. Coplien 以「宗教信仰」形容 TDD 的迷思算是最典型的代表，它以 TDD 不可能達到測試良好的涵蓋率來批評它的效率不如傳統的軟體工程方法。同人曾經評論過這種觀點的繆誤：

品質的問題並不是測試效率太低；而是開始測試的時間拖得太久，使得分析設計階段的缺陷不斷地擴散而使開發人員窮於應付。例如開發者在設計的過程中有沒有去思考設計驗證的問題，還是把這個責任推給後續的品管作業，例如 code inspection，或是各種形式的審查作業？

這個答案無關乎方法論本身的優劣，而是關乎開發者面對問題的態度，這對品質有著直接而深遠的影響。沒錯，我們需要專注於思考，但思考的重點並不在用那一種檢驗方式比較有效率，因為那樣我們將會落入品質是檢驗出來的迷惘當中。而是應該思考，對這個問題為什麼我會這樣設計？我如何驗證它是可行的？有沒有可能它會無法解決問題或造成其它我沒有想到的問題？

把做測試和 TDD 混為一談的觀點，忽略了 TDD 的價值不在檢驗程式的正確性，而是找出足以解決問題的系統邊界的設計過程、以及面對目標採用有效的節奏把事情做好。對於 TDD 而言，測試不是用來確認程式沒有錯誤的目的，而是定義系統邊界的手段與過程，因為品質的關鍵不在於確認沒有錯誤的程式，而是從程式接口之間發現軟體自然演化的脈絡；學習庖丁解牛的精神，以游刃有餘的技法來體會軟體開發之道。

至於 XDite 在意以「混蛋邏輯」把 TDD 和測試綁在一起，同人覺得根本就是沒有必要地在鑽牛角尖。當程式設計者說他想要寫測試程式來確認程式的品質，並不見得他真的是把測試和 TDD 綁在一起；而且就算是他真的把測試和 TDD 綁在一起，同人也認為無傷大雅。有時候，管理者不見得會瞭解程式開發者所表達 TDD 的正確的觀念，所以開發者必須學會用不太精確但表達到重點的說法對管理者提出需求。

這也就是說，對於程式設計者而言，他所需要的是擁有能夠提昇他程式品質的方案，而 TDD 是他想要可能可以符合需要的候選方案之一。提出測試的附加價值是讓管理者比較能夠接受的說法，當然程式開發者也有可能真的把測試和 TDD 綁在一起，但即使這樣也沒有關係。因為當他實際採用 TDD 開發程式後會發現程式品質的提昇不是測試，而是在系統邊界附近發生自我組織的演化過程。

很多時候，我們真的沒辦法期待人們觀念正確才開始動手執行，因為那樣等於你什麼都不用做，而且軟體開發的重點不是理論怎麼說，而是實務上怎麼做，程式開發者從實務上的執行才能真正瞭解，TDD 不能跟做測試混為一談。

1. 曾昭屏譯（2006年），《溫伯格的系統管理學：系統化思考（第一卷）》，經濟新潮社。

當然，系統發生錯誤的原因，也許真的很可能和方法或技術有關。但是否所謂的方法或是技術，就是一般對系統發生錯誤的評論中經常提到的方法或技術；不是開發者的技術觀念有問題，就是沒有遵照正確的流程及方法來做事？筆者覺得這樣的假設似乎把系統開發看的太容易了。

如果系統失敗的真相，真的是技術觀念、流程、或方法論的問題，那麼只要在系統開發過程中，加強這些因素就可以確保系統開發的成功。但從筆者系統開發的經驗顯示，這些因素雖然很重要，但它們並不是系統開發能得以成功的關鍵，而是要等到逐漸適應系統開發的複雜性之後，才能逐漸地改善增加系統成功的機會。

要認識系統開發的複雜性，這並不是一件很容易的事。不過，忽略它會讓我們和湊熱鬧的外行人一樣，從他人系統失敗的經驗中只能看得到表相；以為這只是犯了離譜的技術或方法論的錯誤。我們應該學習像內行人一樣，從系統失敗的教訓中看到成功的門道，了解到系統開發複雜性本質的真相；不天真地以為技術或方法論可以解決系統失敗，而是深入省思系統開發的複雜性。基於筆者過去對系統失常的觀察及體會，想以這篇文章從公共建設的系統失常看系統開發的複雜性。

從文湖線的系統品質談起

自從捷運文湖線通車之後，筆者就常聽到有人對它的系統品質提出批評的意見。筆者記得以前在上班的途中，在路上遇到同事就曾和他討論到捷運文湖線的系統品質。這位同事林君的看法是以工程技術觀點看待系統失敗的典型，雖然他的觀點並不能夠讓我們看到系統失敗的全貎，但對系統開發的複雜性本質，倒是不失為一個不錯的思考起點。

林君知道筆者平常上下班都是搭捷運文湖線，然後再轉乘公車接駁。當時他問筆者搭乘捷運文湖線的人潮，筆者回答和過去文湖線未通車前搭乘捷運新店線相比，文湖線的人潮似乎並沒有新店線的人那麼多，雖然不見得會有位置坐，但文湖線的擁擠程度確實比不上新店線。林技術長猜測也許是人們對文湖線沒有什麼信心，所以搭乘的人比較少。

林君長年在國外定居和工作，因此以歸國華人的身份看待捷運文湖線的系統品質，會認為人們對捷運文湖線的系統沒信心是很自然的。文湖線在開始營運之初，發生過很多次嚴重的當機事件，因而讓人們覺得系統的品質不佳，這的確是不爭的事實。不過文湖線現在的狀況，確實已經比剛上線的時候要穩定許多。

依據台北捷運公司所提供的資料，文湖線系統可用度與國際穩定度指標 MKBF 的兩項指標，可以客觀地證明，文湖線已是一條符合國際水準的捷運線。以筆者每天親身搭乘的實際體驗，我認為文湖線現在的狀況，其實並沒有像林君說得那麼糟糕。

筆者以過去參與的大型公共建設的系統開發經驗，讓我比較能夠理解文湖線剛開始上線的系統失常，直到後來才逐漸穩定的狀況。以筆者過去的系統開發經驗顯示，很多系統在剛開始上線的時候，總是會碰到一些偶然的意外，讓系統功能無法正常運作。直到專案團隊耗費足夠的時間與心力，找到系統異常的根本原因，才能針對問題對系統改善或調整使其趨於穩定。

因此筆者認為系統從剛開始上線到逐漸穩定，需要足夠的時間。剛開始是由於開發人員經驗不足，以致於不夠了解狀況而難以掌控系統以因應問題。等到開發人員從系統失敗中得到寶貴的經驗及教訓，並努力費心解決問題並改善系統，系統自然就會開始漸入佳境。很多系統並不像捷運文湖線或是高鐵售票系統那樣受到大家的注意，但其實每個系統在上線後，會出現問題的機率都是一樣的。

不過，林君倒是不這樣認為，而是認為由於開發者的觀念錯誤，才導致捷運文湖線的品質不良。以林君長期在國外開發系統的經驗，他很推崇老美做事的方法，按步就班地照著正確的方法來進行開發的工作，不求速成只求「把事情做正確」。反觀在台灣，他認為人人都是為了趕進度而求快速，經常省略了一些不應該省略的作業，為了節省時間，卻得到系統品質不穩定、甚至是系統失敗的代價。

品質就是沒有錯誤？

林君認為開發者為了讓捷運文湖線提早上線，沒有確實地把開發工作做正確，因而使系統品質變得不穩定而不斷發生系統異常的事故，所以應該歸咎於開發過程的觀念錯誤。林君的論點似乎是認為「品質就是沒有錯誤」，但這種觀念必須把系統開發的錯誤當成道德問題，否則它將會造成邏輯推論上的繆誤。

「品質就是沒有錯誤」會造成什麼邏輯推論上的繆誤呢？的確，當系統出現大量的錯誤時，毫無疑問地，不管系統功能如何，人們還是會因為品質缺失而認為它沒有價值可言。但反過來說，即使系統沒有發生任何的錯誤，我們也無法確認它的價值為何。^[1]

事實上，在追求系統不會出錯的完美之外，要讓系統有價值還需要對特定的人有用處。開發者致力於工程技術的完善，開發出不會發生任何錯誤的系統，即使盡到開發沒有瑕疵系統的道德責任，但這並不代表系統能夠為客戶或是使用者產生價值，而能夠贏得他們讚揚的肯定。

這是因為追求系統在工程技術的完美、和系統符合客戶及使用者在問題領域真正的需要，根本就是兩回事。就像系統開發者常會碰到幾種導出使用者需求的障礙。尤其對於大型規模或複雜的系統，客戶和使用者通常要等待較久的時間，才能接觸到實際的系統。經過長時間對環境所產生的變化，加上他們在想法上的蘊釀，讓系統在認知和實際上的差距變大，於是便出現「是的，但是…」症候群的現象。開發者照著客戶或使用者提出的需求來開發系統，但等到系統開發出來之後，他們反而表示「是的，系統功能看起來很酷，但是它不是我想要的功能」。

「是的，但是…」症候群顯示系統開發在導出使用者需求的一種常見障礙；由於系統在被開發出來之前的不可見和不可觸摸性，客戶和使用者在還沒看到和接觸系統之前，根本很難說清楚他們需要什麼，而且有時候連他們都不知道自己要什麼。

除此之外，系開開發在導出系統需求還有兩種常見的障礙，一種是在系統範圍內存在「未發現的廢墟」，當開發者愈深入認識系統，愈會發現很多原來沒有被發現的系統問題；另一種是開發者和客戶或使用者的語言不同，因為彼此背景、專業知識、技能、以及關注的焦點不同，使雙方在溝通上採用不同的方式，增加彼此誤解和衝突的機會。^[2]

由上面幾種導出使用者需求的障礙，我們可以了解僅僅系統開發要把需求弄清楚，就是一項艱鉅的任務。很多時候系統發生錯誤，問題的關鍵並不是開發者開發的系統有錯誤，而是沒有開發客戶或使用者真正需要的系統。因為在具備規模和體制的系統開發專案中，系統不大可能在層層工程驗證和確認過程把關之下，還會發生沒有把事情做正確的繆誤。但倒是很有可能因為系統開發在各種因素交互作用下產生的複雜性，讓人無法在混亂和秩序之間適當地調適而讓情況失去控制。

系統開發的模糊地帶

從工程技術的觀點來看，系統開發應該需要客觀及明確，其中不應該有模稜兩可和高度的不確定因素存在。但實際上在系統開發的過程中，卻讓我們發現要開發被嚴謹定義的系統，處處出現無法具體而明確清楚定義的難題。系統開發顯然存在模糊地帶，只是假設它不存在，更加容易讓人忽略系統的複雜性，而在系統出現混亂的時候無所適從。

系統開發為什麼會存在模糊地帶呢？理論上，只要能夠發展出足夠具體的需求規格，系統應該就不存在任何的模糊地帶才是。然而，即使沒有前面提到導出使用者需求的三大障礙，人也沒辦法藉由發展嚴密的系統規格，讓系統開發過程的模糊地帶因此而消失。

因為雖然定義具體的規格可以用來規範系統的一致性，減少系統發生模稜兩可情況發生的機會，然而，規格所規範的一致性愈高，也就代表系統的完備性愈容易受到限制；在系統規格沒有錯誤的情況下，不可能不出現任何邏輯上的矛盾。

歌德不完備定理已經證明在理性的世界中，沒有任何的公理系統可以表現它的正確性，而在它所涵蓋的範圍中不發生任何的矛盾。只要公理系統所涵蓋的範圍足夠廣大，可以蘊含自然數所定義的成員，那就必然可以找到沒辦法證明也不能夠證否的命題。此外，也沒有任何的公理系統可以證明自己的正確性。

從歌德不完備定理可以讓我們理解系統開發的模糊地帶是必然存在的。對系統運作可能會碰到各種問題，如果開發者對問題領域沒有足夠的經驗，藉由數理公式及邏輯推演，沒有人可以定義出沒有模糊地帶的完備具體系統規格。當規格具有相當的涵蓋範圍，就代表系統存在更多的模糊空間，不然就代表了規格一定存在邏輯上的矛盾。

歌德不完備定理並不是說沒有系統的規格是完備的，而是指只要規格的涵蓋範圍夠廣，就沒辦法透過計算或是推論來證明它的完備性，否則將會以破壞規格的一致性作為代價。當然對於系統運作將來會面臨的某些情境，開發者可以增加規格的細節來擴大規格的完備性，但通常這樣做會影響到系統其它部分的功能，於是還是無法提昇規格整體的完備性，或是因此喪失規格的一致性。

因此，系統開發的模糊地帶是因為人們經驗的侷限，它們讓我們不可能用規格的正確無誤來證明系統對人的用處，也就無法確保系統的價值為何。因為單單要定義什麼是「完全正確無誤」就是個大問題，很多時候人不是不知道應該把事情做對，而是缺乏可以減少或避免犯錯的經驗。

一般而言，系統開發的錯誤包括缺少兩種典型的經驗；第一種錯誤是缺乏問題領域的經驗，使人沒辦法在規格中清楚定義系統，因為不清楚系統未來將面對的情境，沒辦法問正確的問題以做正確的事、第二種經驗則是缺乏工程技術的經驗，使人不了解系統可以採用的技術及方法，沒辦法回答正確的解答來把事情做正確。

工程技術的對策

在工程實務上，面對系統開發的模糊地帶，開發者並非無技可施。要避免沒有問對問題和沒有提供正確解答的缺失，開發者可以透過驗證（Validation）流程來做正確的事情，然後再運用確認（Verification）流程把事情做正確。這是面對系統開發的模糊地帶，工程技術所提供的對策，只是運用工程實務的驗證和確認流程，是否真能有效降低或避免系統開發的模糊空間？

從筆者實際參與系統開發的經驗來看，在系統開發過程中，開發者經常花費很多的心力在系統的驗證和確認上，但實際上它們對降低或避免系統開發的模糊地帶其實非常有限。主要的原因並非開發者的能力或是他們的使用的流程或方法不對，而是開發者終究會發現他們沒辦法完全忽略、或是排除工程技術以外有關人的因素。

筆者再舉另一個著名公共建設發生系統失常的例子。就像在幾年前，通過 CMMI ML3 的神通電腦開發高鐵售票系統，被人們詬病像登機的售票系統是忽視真正的使用者需求。以通過 CMMI ML3 的公司水準來看，人們很難能夠接受他們會開發出這樣的系統，不敢相信他們具有相當的軟體開發能力成熟度。

CMMI 工程領域中的驗證過程，它的目的是為了證實未來的系統，在預期中的環境中運作可以滿足預期的使用者需求，因此如果系統沒有滿足實際使用者真正的需求，很可能是因為開發者並沒有做好需求的驗證，並且以「用廣泛的方式驗證需求」來發展需求。

然而，高鐵售票系統沒有辦法滿足使用者真實需求，原因不盡然是需求驗證的問題。相信有參與過大型軟體系統開發專案經驗的人都會非常清楚，在開發過程中，開發者能夠主導需求方向的能力是很有限的。面對系統的真實情況，開發者並不如其他的利害關係人更能了解需求，可能很難分辨什麼樣的系統擺在預計的環境，才能滿足使用者需求。

當然，開發者可以用各種方法來探索各個候選的系統解決方案，然後運用各種廣泛的方式來確認需求；諸如用展示、雛型、模擬、或概念驗證等技術來驗證使用者需求。然而，除了筆者在前面提到的三大導出使用者需求的三大障礙之外，系統開發還會常碰到其它原因，讓「用廣泛的方式確認需求」也不能獲得使用者的真實需求。

例如負責需求確認的人員，並不是實際操作系統的使用者。他們可能會誤解使用者的需求、或是因為利害關係而忽略使用者的需要，等到系統開發完成後，系統使用者才發現系統不符合他們的需求。

上面的情況在大型的系統開發專案中很常見，開發者經常會碰到提出需求和使用系統並非同一個人的困擾。跟開發者談需求和確認需求的是資訊部門，當開發者把系統開發出來之後，交付使用單位操作以後，使用者卻又表示系統並不符合他們的需求。

為什麼客戶不讓開發者面對使用者直接溝通需求，而要透過資訊部門的中間人的角色？這個問題其實很複雜，很多時候客戶很難找到確切的使用者來讓開發者訪談需求。即使排除像高鐵售票系統的使用者是一般的民眾的狀況，其它企業內部的系統的使用單位，很經常會橫跨多個部門，要找到所有的利害關係人一齊開會，其實是非常不容易的。

其實還有更主要的原因是客戶在策略觀點、和使用者作業觀點的不同調。客戶的決策高層可能不只是希望系統將現行作業自動化提昇效率，他更希望系統能夠運用資訊科技的優勢來改進作業流程，並改變使用者習慣來創造效益。所以並不希望開發者對系統需求的認知，被使用者的作業習慣框住。客戶端高層對系統的看法，經常會與實際操作系統的使用者的需求南轅北轍，很難能夠從當中找到讓每個人都滿意的系統需求，而只能從當中做出某種程度的取捨。

雖然系統開發在驗證和確認流程並不是對人而是應該針對事，可是忽略人的因素就很難能夠得到執行它們應有的成效。記得筆者曾經經歷過系統經過客戶的 Power User 測試需求的系統，最後在系統驗收之前，卻還是被客戶要求變更需求。這對開發者也許是難以理解並接受的情境，但其實這正是系統開發複雜性本質的展現。即使對企業需求更了解的資深使用者也很難發現自己提出的需求是有問題的，更何況有時候需求的變化是來自人力所不能抗力的環境因素所造成的，開發者很難能夠對他們來多加以責難。

社會技術的關鍵因素

因此，從上面工程技術經常碰到的困難我們可以清楚知道，系統開發即使透過嚴謹的工程技術，也不可能忽略人的因素，因為即使工程技術沒有出現錯誤，也不能證明它是對人有用處而展現價值。這正說明了系統開發的複雜性並不是單獨以工程技術的觀點就可以理解，而是更需要正視有關於社會技術的觀點。

社會技術觀點和工程技術觀點最顯著的差異，正是前者並不如後者的客觀，這也代表是非對錯沒有固定不變的標準，常常同一件事在不同的專案或基於人的不同立場而會有不同的結論。其實系統開發的複雜性正是因為無法限定在單一的觀點，而是必須考量各種不同面向的多重觀點。

因此，系統開發需要考量多重觀點，要先從取捨系統需求出發，這代表系統開發者必須做好利害關係人管理，它對系統的成敗具有積極的決定因素。利害關係人管理需要識別出專案的利害關係人，然後挖掘、管理、以及影響他們的需要及期望。專案的利害關係人包括主動參與專案的人員、或是他們所感興趣的事情，會對專案的產出或成敗有影響的個人或組織。

系統開發應該要儘可能地滿足每一位利害關係人的期望和需要，然而，一旦利害關係人之間，彼此意見衝突而且無法協調共識時，那系統就必須要以滿足專案的客戶為主。也就是說要把客戶當成是關鍵的利害關係人，為了滿足他的需要和期望，其他人的需要及期望都可以被放棄。

然而，有些時候系統開發者眼前直接面對的客戶、或是專案的贊助者，他們的意見不見得會讓系統變得更有用處，而且經常還會讓系統變得更不容易使用，反而讓人們沒辦法接受系統。因此，在這種情況下，可能會促使開發者認為應該思考使用者實際的需要，因為可能他們才是最重要的利害關係人，而不以滿足客戶或專案的贊助者的需要和期望為目標。

不過，這種想法的問題是開發者通常沒有能力判斷誰的期望和需要比較重要。當然使用者是直接使用系統的人，他們的期望和需要或許應該優先考慮。但客戶和專案贊助者是真正出錢的人，當他們和使用者的意見不一致、甚至是發生衝突的時候，考量現實的因素，開發者真的很難為了符合使用者的期望和需要，而違逆客戶或專案贊助者的要求。

其實開發者運用他所熟悉的工程技術，通常是不能分辨誰才是真的利害關係人，因為對於客戶所關心的問題領域，有太多他不清楚的事情。有時候，開發者基於工程技術感覺應該是對的事情，往往最後才會發現它可能是錯的。當然，其它像客戶、或專案管理的單方向觀點，可能會受到對解決方案領域的認識有限，也沒辦法分辨誰才是真的利害關係人。當我們聽到有人主張「客戶永遠是對的，所以你應該照我說的這樣做」就會知道這絕對不是真理而是偏見，忽略了系統開發的複雜性來自多重面向。

在混亂中找秩序

既然系統開發的複雜性不能忽略多重面向，那麼我們就不可能在問題領域和解決方案領域之間選擇一邊來強調系統開發的核心思想是什麼，而是應該在各種不同面向觀點的交界之處，去找到適應系統開發複雜性的關鍵所在。換句話說，系統開發必須調合各種陰陽面，從未知和已知之間、混亂和秩序之間、結構和非結構之間，去尋找可以融合各種觀點的最大可能性。

要調合系統開發的各種陰陽面，以融合各種觀點最大的可能性，依複雜適應性系統（complex Adaptive System）的觀念來說，停留在會發生自我組織的混沌邊緣以適應變化，可以從三個方向著手。首先必須要把廣大而無所不包的可能性，限制在一小部分、其次是必須保持允許輕微改變的穩定性、最後是必須要在靜止不動的死寂和過度活動的混亂之間維持平衡。

這三個方向讓我們看到了適應系統開發複雜性的三大重點，那就是系統必須是可測試的、擁有允許改變的彈性、以及必須能夠持續的整合以維持動態的平衡。測試是為了知道系統的邊界在那裡、彈性是為了容納更多需要的變化、整合則是讓演進系統的火光能夠迸現。

於是，面對環境變化的無常，開發者需要自我組織來演化出適應複雜性的能力。筆者認為這種能力才是系統開發品質的關鍵，以工程技術和社會技術之間的調適，來尋求不同領域觀念之間的融合。這樣就能夠使系統在變化的環境中，能夠保持穩定的動態平衡。

就好像《太極拳論》提到「偏沉則隨，雙重則滯」的觀念一樣。工程技術重視規律和秩序，而社會技術則強調適應變化和彈性，兩者各有所長而無法偏廢。在開發過程採用（adopt）、調適（adapt）、並熟練（adept）不同著重點的轉移，是讓人學習在混亂中找秩序的法門與修煉。當然筆者承認這實際做起來真的不大容易，但至少它不會讓人用簡化的思維來看待系統開發。

後記

這篇文章本來是準備投稿 ZDNet Taiwan 的文章，從去年八月和同事的對話引發同人的寫作動機開始，到最近才把整篇文章完成，歷經了將近一年的時間。在寫作過程中，文章經過無數次的修改，希望能夠寫出不同以往談論系統開發複雜性的文章，沒有深澀的術語、也能用非技術專業的觀點來看到我對複雜適應性系統的領會。

這正是同人想突顯和另一篇有關系統開發複雜性的文章〈軟體開發是工藝還是工程〉最大的不同，也算是對我最近兩年在系統開發所行、所思、所得，做一個比較全面的整體論述。系統開發真的需的有效的方法，但沒有任何一套方法可以忽略人的因素而能夠正確無誤地運作。

很多時候，讓人們沒辦法流程把事情做好的原因其實很簡單，但人的情緒卻通常把它變得很複雜。尤其是高階主管的情緒，不去觀察現象來瞭解執行和計劃的落差，以調整計劃來做正確的事情，卻以批評與責難來反應自己的情緒，這正是顯示高階主管在系統開發管理的無能為力。這種無能代表他們除了只會讓人「聽命辦事」之外，其它對管理其實是一無所悉。儘管他們能夠一直用口號來「教育」員工，並藉此檢查工作者的工作態度對不對，但他們的管理能力只能讓他們「簡化」系統開發的複雜性。

這篇文章比〈軟體開發是工藝還是工程〉更擴展它的詮釋領域，系統開發不應該只限制在軟體開發上。雖然軟體的抽象性會增加系統開發的困難度，但系統開發複雜性的本質所在，在於技術和業務觀點相互撞擊而產生各種變化，它不只是存在於軟體開發的系統中，對其它非軟體的系統開發也是相同的狀況。

同人並不想讓這篇淪為整理過去文章的新瓶舊酒，而是以這兩年系統開發實務得到的經驗，融合複雜適應性系統的觀念，內化成系統開發調適變化與紀律的動態平衡之道。雖然這篇文章也許寫了太久，以致於錯過了投稿 ZDNet Taiwan 專欄的時機，但發表在網誌也算是對自己有交待和對喜歡《同人的生活派對》軟體開發和專案管理文章讀者的回饋。讀者的支持是作者寫作最大的動力，不管是在網路專欄或是個人網誌，同人將會持續寫作來分享我在軟體開發和專案管理領域所體會的點點滴滴。

1. 曾昭屏譯（2006），《溫伯格的軟體管理學：第一卷（系統化思考）》，p.294，經濟新潮社
2. Dean Leffingwell & Don Widrig (2003), 《Managing Software Requirements: A Use Case Approach》, Second Edition, Addison Wesley Professional.

我看了很多公司，每一家都宣稱絕對支持 QA 啊！

這句話讓同人心中無限感觸。感觸之一是 satomi 原來就認識同人的許多同事，包括同事丙和同事乙，而且和同事丙一樣，satomi 是非常有經驗的 QA。這當然是我在寫完那篇文章之後才知道的事情，然而現在看這篇文章，感覺像是跟很多老朋友在進行有關品質的對話。

其實還有更大的感觸之二，記得我當初在寫這篇文章的時候，我認為公司的品質文化是重視方法來提昇品質，這是公司高層對品質的承諾。因此，當 satomi 留言回應「QA 應該要可以提昇品質，但是公司從來沒有授予這個 QA 團隊做到這件事的權限」時，同人覺得公司一直給予 QA 足夠的權限而並不認為是如 satomi 說的那樣。

然而，兩年後有機會再回頭看到那篇文章之後，才看到 satomi 留言的先見之明。原來同人當初對公司的品質文化的看法並不正確，即使公司高層宣稱絕對支持 QA，但在行為上的表現卻並非如此，而是並沒有實際賦予 QA 足夠的權限來提昇產品的品質。

當然，同人相信同事丙當初不見得有「認為公司表面上表示絕對支持 QA，但骨子裡卻從來沒有授予這個 QA 團隊做到這件事的權限」。不過我很確信他今天不會認為公司高層的行為真的如其所宣稱，在行動上支持 QA。

否則，原先對公司發展遠景抱持希望和品質管理工作懷有熱情的同事丙，應該不會在同人離開公司之後，選擇在同一個時間點也離開公司。以同人在離職之前對他的觀察，我發現他在會議中相較於以前更少表示他的看法，感覺到他似乎已經不像過去對工作懷抱熱情，即使他還是努力工作為減少公司產品的 bug 而奮鬥不懈。

是什麼東西讓同事丙澆熄他的熱情？從同人後來私下和同事丙的聊天之中，可以確知是和公司高層對開發流程的態度有關。公司高層對品質的觀念和態度很有問題，有問題是指因應公司產品的複雜性和解決客戶問題方面，他們採用了不大適當的產品品質模式；以「照章行事」的方式來進行品質的管控而非「把穩方向」來做正確的事情以提昇品質。

在同人和同事丙共識的兩年中，我曾不只一次看到他和公司高層之間在開發流程的溝通中產生火花。對於高層提出新的開發流程，同事丙為了確認「我們真的要以瀑布法來開發產品嗎？」經常會造成和高層不悅的言語交鋒。在同人眼中看到這一切，我覺得使用「瀑布法」也許並沒有什麼不好，但我發現比較大的問題是高層侷限於自己的眼光，而不能用別人的觀點來看到自己觀點的問題。

同人從另外一件事更顯著地看到高層有這種侷限。有一次，在一個公司高層找同事丙、研發經理研究該如何解決客戶端問題的會議中，同事丙提出對公司高層提出的解決方案的意見。公司高層告訴同事丙，他應該先想好解決方法再提出他的意見。同事丙則不以為然地表示，如果要提意見之前都要先想好解決方案，那麼誰敢提呀！

因此，在公司高層這種態度和形成的公司文化氛圍之下，公司產品最後會變成「把做好的東西丟到牆的那一邊去」就不足為奇了。再加上以西方優越感產生文化的價值批判，在這種情況之下，QA 對產品品質的提昇有多少著力點呢？同事丙的離開做出了最好的回答。結果真的讓 satomi 說對了，公司的確是沒有賦予 QA 足夠的權限來提昇產品品質。

當然，產品品質不能提昇其實不能全怪公司高層。同人相信他絕對是有心要把產品做好，絕對也不是只有口頭上說說而已，但只是他的心智能力和行為沒辦法達成一致，非不為也，實乃不能也。從他老是把「把事情做對」掛在嘴裡，就知道他不知道「做正確的事情」可能才是品質不能提昇的最大瓶頸。去年年底，同人才發現他根本不能分辨工程的驗證（validation）流程和確認（verification）流程的差異，還問我「做正確的事情」是什麼意思，不是「把事情做正確」就行了嗎？

因此，我們真的不能怪罪公司高層只知道「照章行事」而不知「把穩方向」。你可以看到那些沒有辦法改變品質文化的高階主管，他們的無能是來自於無知，所以真的不能太苛責他們。

也許在夜闌人靜中，有心而無力改變的高階主管會反省自己白天錯誤的愚蠢行為，然而，一旦相同情境再度聚合，他們就是無法不在別人面前表現出愚蠢的樣子。這代表他們對於提昇軟體的品質這檔事，知道的很有限，可是又不想讓人知道他們知道的有限，也許需要更多失敗的境遇來磨鍊出成熟的心性，才能走出自己穴居的洞穴，而看到不一樣的世界。

那篇文章認為打擊在房市的投機行為，等於反對投機客投機的自由，但沒有反對其他人在其它領域投機的自由，卻是「雙重標準」。讀完了那篇文章，同人想提出我對那篇文章的看法，談談房市投機的自由。

同人並不贊同那篇文章的論點，因為從文章的論述中可以看到一些明顯的邏輯繆誤。首先那篇文章提到投機客只是反映大多數人對都市房子的需求而已，這種需求，即使沒有投機客也會同樣存在。

投機客只是反映人們對房子的需求的說法，似乎是意味著高房價是因為人們普遍想要買房子的需求，而不能責怪投機客的炒作行為。因為人們都喜歡在都會區買房子，所以市場有足夠的誘因來鼓勵賣方提供房子給買方來滿足需求。投機客以低買高賣的方式來獲取利潤，但買方也買到他們所想要的房子，交易是兩謀其利。因此我們不能憑投機客炒作就否定他們在房市投機的自由，因為買方也有選擇交易的自由，可以自由選擇自己所需要的交易。

然而，買方在市場上是否真的有選擇交易的自由？要談到自由，就不能不思考到平等，因為人們在不平等的狀況下，是很難能夠做出自由的選擇。舉哄抬物價的例子會更清楚，為什麼一般人無法接受炒作房價的投機行為。就像在災害過後的物價哄抬，災民要花費無理高價才能換得基本的生活溫飽。在這種情況下，無理高價反映的不是真自由的交易。

這不是自由市場的正常交易，買家進入市場不是自己甘願，並不是憑藉著供需原則和有意願的賣家談成一個雙方同意的價格。在緊急時期，受迫的買方沒有自由，他們是情非得已才去購買安全住宿這種生活必需的。^[1]

為什麼買方在房市不能自由選擇交易呢？這主要是因為房屋交易的利害關係人的利益不相容、以及買賣雙方在房市的資訊不對稱現象所致。房市出現高房價，對建商、賣方、投機客、仲介有利，但對買方卻不利。再加上買方不容易取得市場資訊，以判斷對自己有利的交易。如此很容易造就建商、投資客、仲介聯合炒作房價的行為，使得房價的推升，往往不是因為供需平衡，而是因為賣方的炒作而誤導買方產生不正確的心理的恐慌所致。

對於一般想買房子自住的人而言，他們買房子是為了滿足安全需求，希望有一個家能夠讓全家人可以遮風避雨，這真的不是什麼了不起的願望，而是基本需求。然而，以市場供需為理由，認同投機客在房市炒作房價的行為，以追求自由經濟的最大效益，這是忽略了在房市炒作高房價帶給大多數人民的痛苦；為了滿足基本需求卻要花費高額的代價，這是不公平而且不正義的事。

其次，那篇文章提到投機客其實是在調節市場的供需，也就是既不讓資源在乏人問津時廢置，在人們想要時，又提供出來給人們使用。文章甚至還提到投機客反而比那些成天只知批評他們的所謂專家和政府官員，更用心的照顧一般人的利益。

假如投機客真的有調節市場供需的功能，也能夠比專家和政府官員更用心的照顧一般人的利益，那麼人們應該會在市場上更歡迎投機客，而不是批評他們對房價的炒作。但事實顯然並不是如此，問題是出在什麼地方呢？

投機客到底是什麼時候開始進入房市？的確，在房價低迷的時候，站在買方可以讓人得到較低的資產購置成本，但相對地，這樣也必須負擔相對的風險。如果有人願意在房市低迷的時候購置資產，以期待將來房市景氣的獲利，人們並不會反對他在房市低迷的時候以低價購置資產，等到房市景氣後再將資產賣出的行為。

因為高報酬相對地必須接受承擔高風險的代價，房市低迷的時候投機客不見得會願意投資，畢竟購置資產的成本不低，若房市短期未見由空轉多的訊息，有多少投資客會真的進場投資房市呢？

因此，真正會在房市低迷的時候買房子，等到人們想要的時候才賣出房子，通常不會是炒短線的投機客，而是傾向在房市長期投資的投資者。而一般人所反對的「投機」，並非在房市空頭時買進房子，等到房市多頭時賣出房子的投資行為；而是在房市多頭時，透過短期高房價的炒作，以增加自己獲得更高利潤的空間。這種投機行為非但對真正的房子買家不公平，對社會經濟也會造成不利的影響。

最後，那篇文章認為「打擊」在房市低買高賣的「投機」，是一種對自由的雙重標準。文章中提到：

事實上人們無時無刻不在「投機」：菜市場的水果攤，用較低價格進貨，用較高價格賣給消費者，這也是「投機」；投資人在股價低時買進，在股價漲時賣出，這也是「投機」；學生在求學時付出較低的代價（學費）來累積專業知識，工作時用較高的代價（薪水）把之前累積的專業知識賣出去，這還是「投機」。

奧地利學派經濟學家米塞斯（Ludwigvon Mises）曾說：「自由是不可分割的。」反對投機客在房市低買高賣的自由，是否也該反對水果攤有低買高賣水果的自由？要不要反對投資人在股市低買高賣的自由？是否也要順便反對一下每個人學成畢業後找高薪工作的自由？如果有人反對投機客在房市投機，卻贊成人們在其他領域投機，這不是「雙重標準」又是什麼呢？

正如同 噗友 Thinker 在看過那篇文章之後，所表達的心得說的好：「買鹽、賣鹽是討生活，買鹽、屯鹽、等到高價才賣，那就是炒作。買賣對社會有貨暢其流的供獻，但炒作顯然不是。怎麼能和在一起做成瀨尿牛丸呢？」把投機客炒作高房價行為背後動機的貪念、與人們為了滿足生存、安全、社會等基本需求相提並論，顯然是那篇文章最大的盲點與偏見。不過，這不代表投機客沒有在房市投機的自由。

其實同人贊成投機客在房市有投機的自由，但這種自由應該是基於平等的自由正義原則。我不認為向投機客徵奢侈稅是所謂打擊投機自由的舉動，而是試圖消弭市場的不平等，讓房市交易儘可能地回歸到「初始正義」。

投機客在房市投機獲得的利潤，向他們徵收額外的稅負以用做住宅政策福利，這是基於平等自由的正義原則。或許奢侈稅會有技術執行細節、或是政治算計利害糾葛的問題，通過的法案可能不盡完美，但同人認為奢侈稅對房屋市場的公平和自由，是一個好的開始。

這正是我在〈公共議題的正義思辨〉對奢侈稅所提到的看法所表達的，徵稅不應視作對房市投機行為的打擊或懲罰，而是為了改善社會契約，不是刼富濟貧，而是鼓勵人們能為擁有自己的家而努力。

1. 樂為良譯（2011），《正義：一場思辨之旅》，p.11，雅言文化。

不同價值觀的對立突顯了效益和公平的不同觀點，然而究竟我們應該選擇公平或是效益來進行公共議題的正義思辨？考慮人在實際狀況遭逢各種情境下的不同決定，最後我們所得到的結論卻可能只有莫衷一是的原則；我們可能在這件事上選擇了追求效益的原則，但對另外一件事卻以突顯公平為原則。

因此，我們到底應該如何決定在公共議題的正義思辨呢？最近同人閱讀了《正義：一場思辨之旅》，覺得這本書深深啟發我對公共議題正義思辨的想法。這本書提供同人討論正義思辨的寫作動機，加上這些公共議題提供了正義思辨的實例，讓同人想以這篇文章探討公共議題的正義思辨。

如何思辨正義

我們該如何思考一件事情是否符合公理和正義呢？在《正義：一場思辨之旅》這本書中，作者舉出物價哄抬是否該禁止、精神受創可否獲頒紫心勳章、紓困金可否用來分紅等在美國實際發生的辯論問題，用來說明通往正義之路的三條出發點：福祉、自由、美德三種理想，各指引出一條正義思考的不同道路。

作者指出上述辯論的癥結，有一些是有關如何增進福祉、尊重自由、培養美德的種種歧見。另一些癥結則涉及不同理想相牴觸時該如何解決。他強調政治哲學不可能把種種歧見一口氣做個解決，但它卻能為辯論付予內涵，並為吾等民主公民所面臨的種種選項帶來清楚的道德條理。

然而要為林林總總的正義觀做評析，就要先確定哲理辯論的形式。作者提到道德哲學和政治哲學都是百家爭鋒的領域，碰到道德或政治上的思考歧見要更小心。歧見經常存在公領域的不同黨派、或不同意見團體之間。有時當棘手的道德難題讓我們不知如何是好，心中充滿矛盾之時，歧見卻是存在於內心。

如此，針對某個具體狀況的判斷要怎麼經過理性思辨，變成一體適用的正義原則，也就是道德思辨應具備何種形式？作者指出要靠著理性思辨，在義與不義、平等與不平等、個人權利與共善之間的紛擾地帶找出一條路，有一種切入點是去注意在道德難題之前，我們是如何自然而然地展開道德思考。接著，遇到違背同一原則的情況而陷入疑惑，並為苦於疑惑的煩憂而自我修正原先判斷，或重新思考原來尊奉的準則。

作者認為隨實際情況經過一再反芻調整原先的判斷和準則，這種真實世界與理性領域之間的來回思考，就是道德思辨的過程。不過他也提到道德省思不可能是一個人孤單追尋，也必須公共參與努力。省思的過程必須要有個叩問者，不管是友人、鄰居、同志、同胞或是出於想像，讓自己與自己辯論。作者提到光從自我內在掏答案，是不可能發現正義真諦或至善人生之道。

從福祉、自由、到美德，作者帶領讀者認識古今不同政治哲學思想家的正義論述的不同面向。在福祉方面談到功利主義強調最多人數的最大幸福。自由方面則談到自由至上主義主張我身我命歸我有、和康德自由主義強調人權是普世價值、羅爾斯的自由主義為底層爭平等。美德方面談到亞理斯多德《正義論》主張適才適性適本質、以及社群主義提到有歸屬就有責任的觀念。這些從不同面向思考正義的論述，足以擴大我們針對公共議題討論的視野與深度。

台灣的反核議題

就拿台灣前一陣子討論熱烈的反核議題來說，日本震災引發核災，突顯核電廠在台灣的安全疑慮。就像張榮發上月 23 日公開反核，認為日本核災殷鑑在前，台灣又位處地震帶，核四應該立即停建，其餘三個核電廠也應廢除，發展風力、火力、水力及天然氣等能源替代。他並批評政府沒這個心，未能及早規畫。

張榮發批評政府未能及早規劃替代能源來取代核能，以達到非核家園的理想。其實這正是基於人民福祉有關功利主義的正義觀點，人們害怕核電廠對環境的污染和造成嚴重災害的風險，加上日本核災的殷鑑更是令人感到惶惶不安。反核與廢核符合台灣全體人民大多數的利益，政府應該努力朝以非核家園的目標而努力，但實際上卻沒有及早規劃與落實，顯然是政府缺乏遠見而沒有及早規劃。

然而，反核與廢核的功利主義正義觀點卻有兩個問題。一個是以犧牲台灣少數人經濟發展的利益，用來換取大多數人不受核災恐懼陰影的威脅，是否真的正義；換句話說，難道少數人的利益真的可以因為多數人的幸福而被犧牲嗎？另一個問題是經濟發展的利益和環境及生態保護的重要性，這兩個不同的東西真的可以放在一起做相互客觀的比較；如果我們不能將它們化成具體客觀的數據來比較，那麼我們怎麼知道應該捨棄經濟發展而選擇環境及生態保護，還是反核或廢核的論調只是將某些人或群體偏好的價值判斷凌駕於其它的價值觀之上呢？

也許多數的人認為環境及生態保護的訴求，比起自由的經濟發展更有道德。但反核與廢核如果不能在理性的層面上溝通，其實並不符合平等自由主義的正義原則。平等自由主義是尊重人是理性思考的獨立個體，而不是強迫其他個體必須接受我們所認定的價值觀。因此以平等自由主義的觀點來看，台灣是否應該反核與廢核的焦點，應該是回到政策理性辯論的層面。

所以有關反核或廢核的討論，應該是從了解我們對能源的需求開始，探討非核能源能不能替代不使用核能的能源供應缺口，還要思考使用非核能源會產生的後遺症及如何解決、以及人民是不是能夠接受不使用核能會導致更高的用電成本，或是造成生活不便的代價。

如果能用更安全又低廉的代價來獲得能源，那當然是最好不過的事情，但如果我們現在做不到，不顧一切的反核與廢核可能會增加更高的碳排放量反而造成更多環境的污染，這對環保來說是本末倒置且不合邏輯的。因此，對於台灣的反核議題而言，應該讓各種不同價值觀的個體有相同的立足點。總之不是為反核而反核，而是在環保和經濟之間符合不同個體的公平和正義。

課奢侈稅抑制房價

政府打算課徵奢移稅抑制房價的議題，也提供有關正義思辨的討論題材。對這個議題，同人和學長 BigNews 在河道上有一些討論。學長認為政府要解決房價的問題，不應該用稅的角度來壓抑房價，而是應該從處理供需問題來解決。對學長的意見，同人提出不一樣的觀點。

同人不認為處理供需問題是解決房價的關鍵，因為房價偏高顯然是存在人為炒作的現象。對於一般勞工和上班族來說，人為炒作房價的投機行為是不道德的，於是政府打算立法課奢侈稅來管束房地產交易的投機行為，以符合買賣雙方在房屋市場交易的公平和正義。

不過學長認為問題並不在立法，因為房屋交易的需求需要被宣洩，而不應該用防堵模式來處理。他認為立法只是在降低房價的多元管道中，成效不彰的一個管道。他擔心房價雖然在短期間能夠被壓低，但卻是不正常的反應。因為整個房屋市場的交易量會下滑。

其實學長的觀念沒有錯，奢侈稅的確可能讓交易量和價格都大幅下降。但我認為看待房市價量下跌的重點應該是，這是由於市場過熱的降溫現象，還是刻意壓制正常的房市交易？同人相信前者的成分居多，畢竟房價一直上漲，不管經濟情勢好或壞，而且房市泡沫化的說法，早就由來以久，開徵奢侈稅有助於紓減房市泡沬化的壓力。

而且如果房價的不合理，確實是因為人為的炒作現象，那立法懲罰貪婪的行為，讓房市回到交易真正的平等和自由，有助於房屋市場和經濟體質的建全，這對房市來說並不見得是壞事。

當然，以自由經濟的觀點來看，房市應回歸市場經濟的價格機制；以供給和需求來預測房價的漲跌，通貨膨脹的心理恐慌和政府干預，既不智也沒有必要。這樣看起來似乎應該政府應該尊重市場的價格機制，朝向調整供給和需求而不要輕易介入干預才是明智之舉。要讓市場有足夠的誘因讓賣方提供買方所需要的房子，如此買賣雙方會因為交易的自由選擇而兩謀其利，並促成社會經濟的良性發展。

然而，房價不斷地攀高真的是求過於供嗎？或許在市場看起來真的是需求比供給還要多，但有多少需求是因為高房價預期心理的催化作用？高房價的預期心理可以催化買屋需求，多數的責任是因為人為因素。利用媒體和廣告炒作高房價，造成人們對通貨膨脹的預期心理，而使房價真的升高。其實物價上漲不一定會讓房價升高，但房價高漲卻會造成通貨膨脹的現象，於是在心理恐慌倒因為果的惡性循環之下，導致房價快速地飛漲。

自由經濟的理想世界是由市場機制來創造社會的經濟效益，基於平等的自由選擇，可以讓人用合理的價格買到他符合需求的商品或服務。然而，在實際的狀況下，人們真的是透過自由選擇來進行交易嗎？

在貧富不均的世界，沒有能力或金錢的人可能很難有自由選擇交易的機會。這不是說交易是在被脅迫的狀況下發生，而是他們會被有能力掌控市場遊戲規則的人宰割，於是付出更高的交易、代理、和機會成本等代價。因此，對大多數的人而言，如果房價的攀升是因為人為炒作，那麼這種行為就是不正義的。

因此，從平等自由主義的正義原則來看，對於非自住需求的短線房屋投資，政府課徵奢侈稅是有其道理的。雖然投資客對房市的投機行為，以道德的層面說他們貪婪其實並不恰當，因為這樣很容易陷入不同價值觀的道德批判，而且他們並不是以非法的手段來獲取利益。然而，他們在投資上的獲利是否完全因為努力，所以應該得到報酬作為獎勵？

當然投資客的獲利絕對有他們努力的部分，但投資客獲利的關鍵因素，還在於他們的努力「剛好」迎合社會的經濟發展。然而，社會經濟發展是全民共同努力的結果，因此基於全民共善原則的社會契約，應該要對投資客在投資房市中的獲利，課徵一部分的稅金以貼補在社會經濟發展沒辦法買到房子的人，因為他們對社會的經濟發展也有一部份貢獻。

同人聽說政府原來打算對房市投資客課徵奢侈稅，是希望能夠用在社會住宅方面的政策。當然，能不能真的課到投資客的稅，這屬於政策上的技術問題，以平等自由主義的觀念來看，對房市的投資客課稅，正是基於全民共善理念的社會契約。也就是說，多賺錢的富人，應該多負擔一些照顧沒有賺錢的窮人，這正是根據收入高低而徵稅。因此，同人認為政府課徵奢侈稅在正義觀念是有其道理，當然在政策執行的技術細節，應該會有相當程度的困難。

大法官和導盲犬

有關馬英九總統提名邵燕玲法官為大法官人選的爭議，同人在噗浪河道上看到一則訊息提到：

我覺得最可憐的是那位被提名的法官！代表法官解釋法律一定要貼近民意，可是這法律是立委設計的，如果設計的不盡民意，到底要遵從立委的設計，還是法官自己取代立委的地位，自行違反人民所付託的立委之意旨，而遵從民意的想法。只是又有二個問題產生，這個改變是真的符合民意，還是符合會大聲的民意？

同人從這則訊息可以感受到作者 JC 鮮師的義憤，只是和所謂「會大聲的民意」不同，看起來他的義憤對象是立法委員和期望扭轉司法判決的民意。後來 JC 鮮師更進一步地以〈馬英九口袋中的大法官〉詮釋他的想法，他認為那位法官很可憐，因為她的宣判不能直接附合民意輿論的想法。然而，法官心中所認知的輿論，其實不是客觀的輿論，而是法官個人心中主觀的輿論。最後他認為馬英九先生的道歉，不應該有責難法官的判決未能符合民意之意味，其道歉的內容應該只設定在向這位法官道歉。

也許 JC 鮮師在這件事政治上的觀察是正確的，政治人物會依照心中認知的民意來決定他的行為。但同人卻以為邵燕玲大法官提名的爭議，問題不在法官的判決違背民意，而是人們對失敗卻受賞的憤怒。法律不能維護公理和正義，即使判決沒錯，獎賞失敗的法官有道德上的問題，尤其是大法官是具有受到一般人尊崇的身份。

當然法官於法，不大可能附著於各種民意來宣判，基於特定的個體或群體，破壞司法體制並不符合平等自由主義的正義原則。但不能破壞體制而引來公憤的例子，前幾年在美國也發生過。

美國國際金融集團（AIG）拿政府的紓困金當紅利犒賞主管，引起人們的憤怒，但執行長不願改變發紅利的決定，提到「如果員工相信他們的報酬能夠由政府隨意的增刪，那公司將留不住一流的人才」。後來在政府的施壓下，才有 3/4 的受賞者自願將紅利繳回國庫讓民怨稍微平復。

如同歐巴馬對華爾街紓困金紅利產生民怨的詮釋：人民不悅的是金融界主管竟然憑其失敗而獲得獎勵，而且還是美國納稅人出的錢。因此大法官提名人爭議的焦點其實並不是判決不能符合民意，而是人們不能接受沒有維護正義成功的法官，能夠受到大法官尊榮地位的獎勵。

至於寄養家庭帶導盲犬被拒絕進行餐廳的紛爭，同人認為這個紛爭明顯是福祉和自由的正義歧見。從導盲犬寄養家庭和巷子義大利麵老闆的互動實錄可以清楚看到，那家店的老闆是以功利主義的思維來與導盲犬寄養家庭溝通。他希望導盲犬寄養家庭不要帶導盲犬進入他的店內，因為這樣可能會讓店內的其他顧客不悅而帶來麻煩。他不能理解為什麼寄養家庭不能接受他認為兩全其美的辦法；寄養家庭可以在門口附近的位置用餐，可以在兩公尺以內的視線中看到導盲犬在門外的狀況，而不要讓牠進入店裡。

然而，店主用功利主義認為合理的事情，在導盲犬寄養家庭和盲人的立場卻不能接受。這明顯是表現店主對盲人和導盲犬的歧視；如果在店內有其他顧客的情況下，導盲犬不能進入店內，那是不是意謂者盲人不可能在店內有其他顧客的情況下，由導盲犬引領盲人在店內的行動。如果這種對待盲人的態度遍及到社會上，就代表社會普遍存在對弱勢者不平等的歧視，即使用看起來禮貌的態度來包裝，有禮貌的歧視還是歧視。

功利主義是追求最多數人的最大幸福，然而為了追求更多的幸福和自由，歧視並排擠弱勢者的生存空間，這種社會是不是我們所希望的呢？或許忽略良知的不安，我們可以回答是來為自己謀求更多的幸福，然而會有那麼一天，不公義和不平等的事情降臨在你身上時，你就會真的會體會到受到歧視的痛苦，並且發現對歧視弱勢的冷漠及忽視，正是社會不公不義的最主要來源。

以羅爾斯（John Rawls）的自由主義會教我們用「無知之幕」的假定來設定我們的社會契約。這種假定是假設大家聚集起來選原則時，都還不知道自己將來在人海中會浮沉出什麼結果。想像大家是在「無知之幕」之後做選擇，大家在幕後不知自己將來是誰。如果大家對自己未來的狀況一無所知，就等於在平等的初始狀態下做選擇。既然沒人具有談判優勢，這樣講好的原則就會符合正義。^[1]

以平等的自由主義的正義觀念來看，歧視弱勢者的社會契約並不符合正義原則。因此導盲犬的寄養家庭為導盲犬和盲人爭平等並沒有錯。雖然網路上有人不滿寄養家庭以錄影蒐證和搬法條拿來壓人的行為，覺得這是存心霸凌店家，也有人以「弱勢暴力」來形容導盲犬寄養家庭的行為是濫用特權。然而同人認為導盲犬寄養家庭只是基於為弱勢者爭平等的義憤，對於弱勢者所遭遇的不平等，不能因為在情感上同情禮貌的態度，就忽略在紛爭背後對歧視真相的理性思考。

此外，導盲犬寄養家庭為盲人爭平等，也不是什麼運用分配正義之外的權力。依照社群主義的正義觀點，導盲犬寄養家庭和盲人有歸屬於同一個社群的關係，所以導盲犬寄養家庭必然負有讓盲人受到社會平等待遇的義務。因此導盲犬寄養家庭為盲人爭平等並非行使分配正義的特權，而是履行和盲人之間因為社群關係而產生的義務。

結語

從《正義：一場思辨之旅》這本書所學習到的正義觀念，讓同人在公共議題的思考中，發現更多不同面向的思考點，並且能夠更深入面對自己邏輯思辨的過程。從過程中體會到理性思考的樂趣，並不是為了說服別人同意自己的價值觀，而是讓理性思辨帶領自己探究真理，不受自己的偏好、刻板印象、感官、和價值觀所侷限。

當然，有時候在思辨過程的討論碰到爭論也是令我蠻困擾的，特別是那些經常習慣對人主觀批評來貶抑他人想法的人。但正義思辨的旅程必然會讓我們收穫豐盛的，它沒辦法讓我們在辯論中贏得勝利，但總是能夠指引我們進行理性的思辨。

1. 樂為良譯（2011），《正義：一場思辨之旅》，雅言文化，p.160。

在這篇文章中提到一個故事：

主角是一個中階主管(A)，另有其他數個中階主管，假設是(B)、(C)。

背景是一個陷入趕工狀態的工程，高階主管(甲)要求各部門的中階主管在不合理的時程內完成工作。

A 主管知道這是個不合理的要求，甚至會引起工程的嚴重瑕疵，提出異議後，換來甲的一陣咒罵。結局是 A 主管按時如質地將工作完成，C 主管在一陣胡亂趕工後，面臨重新再做一次的局面。

這篇文章的作者認為「提出異議是『做對的事情』。已經提出異議無效，仍然按照要求把工作完成，這是盡本分、恪守崗位。將工作『完善』地達成，是堅持把事情做對。這些層次，是工作的原則，是作為下屬的原則，是處事的原則。」

以面對單一事件的行為來看，當工作者對做正確的事情無從選擇的時候，選擇堅持把事情做對當然沒有錯，這代表他是一位盡本分對自己專業負責的工作者。然而，同人以系統思考的觀點來看，如果類似這樣的單一事件經常發生，堅持把事情做對可能就不見得是最正確的行為。因為這樣堅持把事情做對的行為，很可能會造就以後更不可能做對的事情的行為結構，它是一種捨本逐末的行為基本模式。

要理解上面提到面對不合理的工作要求，堅持把事情做對的行為，卻造成以後更不可能做對事情的行為結構，可以思考兩個問題。第一個問題是面對不合理的工作要求，如果堅持把事情做對就可以完成任務，那麼不合理的工作要求，是否在下次不會再出現了呢？答案恐怕多半是否定的，即使指派工作的人會說這次是特殊情況，下不為例。但如果你這次把這麼棘手的特殊情況都成功解決了，下次他當然可以用更特殊的情況來考驗你。

於是這時候第二個問題就出現了，當你面對愈來愈不合理工作要求，有一天恐怕它會不合理到你盡全力都未必能夠解決它，結果你焚油膏以繼晷，以日以繼夜的努力，甚至付出健康的代價都沒辦法完成任務，這樣你的長官是不是就能體恤你的勞苦而不計較你沒有完成工作的責任呢？這恐怕是你要擔負他可能翻臉不認人的風險，一旦如此，你之前的努力都將一切化為烏有。

上面這兩個問題的發生，都是因為人不在及早做對的事情，卻以為只要現在堅持把事情做對就好了。如同下圖所示，以單一的事件來看，對於不合理的工作要求，假如我們無力或不願意反駁，就只能盡全力堅持把事情做對，來解決上面對我們的工作要求。但如果每次上面提出不合理的工作要求，我們都只能堅持做對的事情，而不能質疑工作本身是不是正確的事情，長久下來，我們就會依賴用把事情做對來解決事情，而失去做正確事情的能力。這對於我們工作的處境，只會更加日益艱難，於是不合理的工作要求，便會讓人應接不暇。

因此，堅持把事情做對是一件好事，這是盡到「努力工作」（work hard）的本分，但這絕對並非工作者所必須唯一堅持的工作原則。特別是工作者更應該把堅持做對的事情之原則放在心中，這是身為知識或智慧工作者也必須盡到「用心工作」（work smart）的本分。當然這兩者的交互關係形成某種工作層次的原則，但這樣的原則並不是在爭取做正確的事情無效之後，再堅持把事情做對就夠了，因為對於一再出現不合理的工作要求，這樣的原則是於事無補的。

同人認為真正有用的原則是弄清楚工作過程需要解決的目標是什麼，它是工作的內容或是模式？如果不合理的工作要求並非一而再，再而三地出現，我們當然應該堅守堅持把事情做好的原則。但如果不合理的工作要求已經變成常態，那麼就代表你必須想辦法化解這樣的工作模式。

這時候應該問自己為什麼不堅持做對的事？或許我們該改變自己的工作習慣，也或許我們該更積極而有效地與別人進行溝通、對話、集思廣義來改變我們一直不能做正確事情的困境。否則未來的命運將會變成《易經文言》坤卦所言的：

積善之家，必有餘慶；積不善之家，必有餘殃。子弒其父，臣弒其君，非一朝一夕之故，其由來者漸矣，由辨之不早辨矣。

不良工作模式的形成，在於沒有防微杜漸。當趨勢已經形成，改變就更困難了，這正是沒有在一開始不去辨認到未來會辨認到的後果呀。因此，在工作上要趨吉避凶，應該早一點問一句：為什麼不是堅持做對的事情？

在文章中，喲哪桑提到：

多數人的心態總是：寧可守舊而敗，不可冒險致勝。我分析這背後的想法是，人們會寧願保守地選擇一個舊的、已知的選項，正是因為他們知道、他們曾經做過、他們也知道別人做過；即使他們知道，重覆同樣的事，結果很可能是不成功的，但至少有一個保險分；因此，人們不願意積極地、冒險地嘗試新的東西，可能更成功，但也許會大爆炸的陌生之路。如果他們失敗，他們還可以這樣為自己開脫：別人也是這樣做、別人也失敗，所以我們也一樣。

如果造成「寧可守舊而敗，不可冒險致勝」心態的原因，正是如以上分析所表示的那樣，那麼人們選擇不去冒險致勝，最歸根究底的原因就是恐懼。恐懼什麼呢？從喲哪桑的分析和他所舉出的實例我們知道，人們所恐懼的並不是失敗，而是陷自己於險境的情結。即使很多證據證實，實際上的情形並沒有那麼樣的可怕，但是人們一定都會害怕危險而勝過失敗，尤其是經驗愈多的人愈會害怕。

因此人們不敢冒險致勝，所害怕的正是「恐懼自己的恐懼」。只因為恐懼，所以人們不會有可能得到勝利的想法；只因為冒險不是他們的選項；他們不敢承擔決定冒險所需要擔負的責任，因為他們不相信自己具有創新求勝的能力，成功於是只會距離他們愈來愈遙遠。

所以這就是，愈年輕愈有衝勁去冒險，因為充滿熱情；而愈年長愈不敢去冒險，因為以為失敗與教訓的代價太大，認為自己會輸不起，只好拖辭說「時不我予」，但實際上只是害怕自己的恐懼而自我設限而已。

當然，存在恐懼的情緒並不是壞事，它讓我們更謹慎的行事，才不會因為大意而使自己受到傷害或得到損失。但因為恐懼而固步自封而阻礙創新的可能性，原來只是恐懼提醒我們該謹慎，對它過度反應可就真的變成了「善意的誤導」。

同人知道很多人不相信在現實生活中我們可以隨時召喚小叮噹帶我們去冒險，但這真的並不是太難的事，只要你真的相信你能夠做到冒險致勝，小叮噹就會教你如何累積小成功來創造大成功，這是心想事成的秘密：只要相信的事，就真的可以做得到。