不過度道歉的藝術

在開發現場，「對不起」這句話往往不自覺地變成口頭禪。
你是否有這樣的經歷呢？我有....笑

當提交資料稍微延遲時、在會議的開頭、或者在被他人指出問題時、向其他團隊提出請求時。
這種 「反射式道歉」 是否真的是出於謙虛呢？
還是說，它已經變成了一種保護自己的便利工具？

越是認真的工程師越容易陷入這種「作為工具的道歉」，而這不僅僅是一個溝通上的問題。

過度的道歉會導致：

無法拒絕過度的要求，變得接受要求的能力過強。
被視為「道歉的人」，專業工程師的意見被輕視
（作為專業人士的話語權下降，被隨波逐流）。

結果，不僅損害了自身的信任感，還導致團隊（自家）的信任感降低，承擔不合理的任務量，成為不健康的專案經營的原因之一。

本文將深入探討過度道歉所帶來的負面影響和現場具體的課題。
同時，我也會撰寫關於如何作為技術人員（不論任務領域）贏得信任的「不過度道歉的技巧」所帶來的價值。

2. 「道歉的成本」：自我評價與信任的降低

輕易的道歉會無意識地降低自身對自己的評價以及他人對你的評價。

2-1. 內部問題：自身作為工程師的「自我效能感」降低

自我效能感是指「我有能力達成目標」的信心，它與面對挑戰時的解決能力相關。

然而，當出現與自己技術能力或判斷無關的事件（換句話說，自己不是問題根源的時候），例如「突如其來的要求變更」或「規格的變更」，若不斷重複「道歉」，大腦會漸漸重複錯誤的學習「問題的根源＝我自己」。

這種學習會導致自我評價的慢性降低，進而降低自己挑戰的意願。
最終形成促使慢性倦怠症的心理基礎，並且自己縮小了職業的發展空間。

ref: https://studyhacker.net/albert-bandura

2-2. 外部問題：他人的「根本原因歸因」及影響力的喪失

根據溝通中的歸因理論，他人會將事件的原因歸結為「內部因素（個人的能力或努力）」或「外部因素（環境、運、難度）」。

輕易道歉的行為，會讓對方把問題的根源視為 「內部因素（從對方的視角看是對自身能力的不足）」 的風險。

即便問題是由技術限制或規格的模糊性造成的，自身的意見也會被視為「能力低下者的解釋」。
結果，作為專業工程師的意見被輕視，而「這在技術上是困難的，因此下一步再提議」或「這個限制應該要接受」等 「我們想要傳達的事情」將無法被接受。
這樣一來，即使實際上想解決的問題也無法對其進行正確的處理，反而助長了「這個人不可協商」的錯誤印象，即使他所說的事實上是正確的，也會阻礙專案的進行。

ref: https://daredemotukaeru.web.2nt.com/51.html

3. 過度道歉所引發的具體團隊問題

心理成本在開發現場會具體化為負債。
這導致了自身作為參與者的疲憊及專案管理的失敗。

3-1. 聽取要求過多：範疇擴大的發生

道歉無意識地向對方傳遞「我處於弱勢地位」「你的要求我會全盤接受」的訊息。
這種態度會讓客戶產生「這個人不會拒絕」的期待與認知偏誤。
此外，由於自己缺乏自信，還會對自己產生「對方所說的才是正確的」的偏見。

在現場，當接近截止日期時，有人問「這個功能能加嗎？」如果你說「對不起，這很困難」，對方則會解讀為「儘管說困難，但因為道歉了，所以會接受，錯在對方，因此也只能接受」。

這會招致範疇擴大，最終導致團隊成員的疲憊與專案的失敗。
健康的專案與團隊經營需要專業人士說出「不」，並承擔這一責任。

若勉強回答「是」，最終無法實現的情況下，想要提供價值的客戶便無法獲得任何回報，
更糟的是，會讓團隊成員感到疲憊，生出讓任何人都不快樂的狀況。

3-2. 道歉的「自我保護」延遲了NA的進行

當會議中出現問題時，道歉有時會作為「減輕當下緊張，避免追究的自我防禦/保護手段」而出現。
通過道歉使自己情緒平靜，放棄本質的討論的情況隨之而生。

例如，假設負責的任務延遲了，而延遲的原因是突如其來的變更要求或是利害關係人的決策速度過慢。
即便是如此，若你最後卻以「對不起，我延遲了，真的非常抱歉....」作為結束，
延遲的根本原因雖然不同，但原本的問題（突如其來的變更要求或利害關係人的決策速度慢）卻無法涉及 「為什麼？」 的討論。

結果，會議的結論只會留下「稍後確認」或「再考慮」等不具結論的NA。
問題的根本解決受到阻礙，最終什麼也沒有進展。

為了自我保護而道歉不僅僅是將問題先延後，實際上即便自己不是問題的根源，也會最終成為延遲原因的一部分。

3-3. 無法進行本質討論：隱瞞風險與限制

專業的責任是明確揭示技術限制與風險，並提出解決方案。
然而，習慣道歉的人在傳遞負面信息時，總是先以道歉開頭。

道歉的先行使得想要傳達的重要限制與風險信息，被視為單純的 「無法的藉口」，因而無法引起認真的討論。

與其說「對不起，這個設計有比較高的安全風險」，不如說「若採用此設計，安全風險會提高。我建議採用替代方案A」，能讓信息的分量增強。
道歉會成為削弱技術主張分量的因素之一。

3-4. 報告不是「懺悔」：信息的扭曲與延遲

重複道歉導致問題報告的心理門檻上升，報告本身便會變成「接受責備的事件（懺悔）」的負面行為。

出於「不想被罵」的動機，工程師往往會延遲報告直到情況惡化，或將報告內容自我扭曲。
如此一來，利害關係人無法準確掌握情況，失去適當的決策時機，問題則可能發展成致命傷。

4. 今天開始改變！將「道歉」轉換為「共感・事實・提案」的技巧

我認為專業的對話應當以情感的道歉為動力，而應以共感、事實（證據）和行動（提案）為組成。
透過這三位一體的框架，建立平等的關係。

避免道歉的場景	壞例（情感道歉）	好例（共感・事實・提案）	目標與目的
納期延遲的風險	「非常抱歉，比預期來得晚」	共感：「未能滿足您的期待我感到抱歉，」<br>事實：「目前，在實作〇〇功能時發現了設計上的預想外複雜性。」<br>提案：「請問您是選擇B案（減少功能）保障期限，還是 A案（保持品質）延長到X天？」	專業的主導權掌握：促進基於情感和目前事實與提案的討論，而不單是追究自身（團隊）的錯誤，展現客觀的事實。
對困難要求的拒絕	「對不起，這很困難......」	共感：「我理解您的需求背景。」<br>事實：「在與現有功能協作的過程中，實作此功能會改變根本要求。」<br>提案：「由於最初的需求變更，我希望能先理清需求後，再就實現的可能性進行討論。」	主張專業性：不僅僅是拒絕，而是透過展示替代方案（或實現替代方案的方式）來推進問題的解決，確立專業地位。
他人失誤引起的延遲	「對不起，聯繫延遲了」	事實：「XX部門的聯繫出現延遲。」<br>提案：「為了避免今後再發，提議將聯繫期限設定為〇日。」	平等的關係與再發防止：不過度承擔責任，專注於建設性改進方案。<br>※如果對方是客戶等情況，則內部情況無關，仍需誠實道歉。<br><br>道歉本身不是壞事，但如果道歉就結束了，就無法生產出任何東西。