■ 本文推薦給這樣的人
- 在績效面談中曾被說過「我知道你有在努力啦……」的人
- 擔心自己的成長方向是否正確的人
- 想從沒有實務經驗的狀態，成為能被評價的工程師的人
- 剛開始站在支援團隊成員成長的立場的人
- 想要除了「衝勁」和「毅力」之外的武器的人
■ 這篇文章能帶給你的收穫
- 你將能用「數字」來描述自己的工作
- 你將能區分「變數」與「定數」，把注意力集中在該投入的地方
- 你將獲得提升成長速度的具體行動指引
- 你將理解成為「會被評價的人」的「型」
- 你將能從短期與長期兩種視角思考職涯
■ 參考書籍
- 安藤廣大《數值化之鬼──與「會做事的人」共有的、唯一一種思考法》
- https://www.amazon.co.jp/dp/B09PV144BN/
■ 相關文章
同一位作者撰寫的《總之先建立制度化》和《領導者的面具》也已整理在下方文章中，如果有興趣，歡迎參考。
1. 結論
如果你想成為會做事的人，先把所有事情一律轉換成「數值」來思考。就這麼簡單。
「提升英文能力」不是目標。「TOEIC 考到 800 分」才是目標。
「提升程式碼品質」不是目標。「將 Code Review 指正件數從每月 20 件降到 5 件」才是目標。
能不能理解這兩者的差異，成長速度會有驚人的差別。
因為，沒有數值化的目標，無法被評價，也無法被改善。
不知道自己目前在哪裡、距離終點還有多遠，就一直跑下去，和沒有羅盤就出海航行一樣。
而且，數值化的本質不是「被嚴格管理」。
它是讓你客觀檢視自己的行動，並持續修正到正確方向的工具。
2. 實際要做的事
■ ① 在日常對話中加入數字
NG 例：
「這次的重構，我覺得有變得相當好了！」
OK 例：
「這次重構後，該模組的圈複雜度從 32 降到 11。也新增了 8 個測試案例。」
■ ② 不是「熱忱 → 數字」，而是以「數字 → 熱忱」的順序表達
NG 例：
「這個技術超讚的，我想導入！我真的超有興趣！」
OK 例：
「目前建置要花 8 分鐘，而我們一天平均建置 12 次，等於每天損失約 96 分鐘。照這個架構，估計可縮短到 2 分鐘左右。請讓我挑戰看看。」
■ ③ 不要在 P 上花太多時間，盡快進入 D
NG 例：
一直煩惱「怎樣成長才是最短路徑」。比較技術書、看學習路線圖、反覆修改讀書計畫。一個月過去了，實際寫出的程式碼還是零
OK 例：
先決定「每天先做出一個功能」，今天就開始。邊做邊發現不足，再修正計畫
■ ④ KPI 要限縮在「已數值化」且「自己能控制」的項目
NG 例：
KPI：團隊的障礙發生件數為零（依賴他人行為，無法控制）
OK 例：
KPI：維持自己負責的 PR 測試覆蓋率在 80% 以上
■ ⑤ 不要只用「機率」來評價自己
NG 例：
「這個月我送出 5 個 PR，5 個都合併了。通過率 100%。」
OK 例：
「這個月我送出 40 個 PR，32 個合併，通過率 80%。從沒通過的 8 個 PR 中，我學到了……」
■ ⑥ 區分「變數」與「定數」
NG 例：
「因為 legacy code 很糟，所以做不出成果」「主管不懂技術」（＝在抱怨定數）
OK 例：
「在 legacy code 中，先從自己最常碰的這 3 個檔案開始寫測試」（＝專注變數）
■ ⑦ 將他人的建議與書籍內容，一律視為「假說」
NG 例：
因為「某某說過」或「那本書上這樣寫」，就停止思考
OK 例：
先試著照某某的方法做兩週，效果評估指標是這個。如果沒有效，再找別的變數。
■ ⑧ 不要讓變數越來越多，並定期捨棄
NG 例：
KPI 有 12 個，而且全部都做得不完整
OK 例：
KPI 最多保留 5 個。每一季重新檢視，把沒有效果的變數淘汰掉
3. 各項說明
■ 為什麼需要「數字」
書中開頭談到的是公平性。
- 營收是多少
- 改善行動有幾次
- 期限守住了多少次
如果這些都模糊不清，評價就會靠「印象」決定。聲音大的人、和主管關係好的人就會得利。
反過來說，數值化也是保護你的武器。
很多「明明有努力卻沒被評價」的情況，原因其實只是努力沒有被可視化。
■ 「會做事的人」的定義
本書中的定義很簡單：
能從評價者那裡獲得評價的人
這句話聽起來可能有點冷酷，但其實非常實用。
如果一直用每個人都不同的定性印象來談「會做事」，就無法建立通往那裡的路徑。
而且，商業世界重視的是「結果」而不是「過程」。方法可以自由發揮，所以才更需要能通往結果的「型」。
■ 將行動量（D）提升到極限
識學的觀點認為，不要在 P 上花太多時間，盡快進入 D。
這裡要避免誤解的是，增加行動量並不等於加班、拉長工時。
換成工程師的情境來看：
❌ 錯誤的增加行動量方式
- 工作到晚上 10 點把任務消化完
- 把「花了多少時間動手做」當成果
✅ 正確的增加行動量方式
- 把驗證循環從一天 3 次增加到 10 次
- 將 PR 切得更小，增加 Code Review 次數
- 把本地驗證需要 30 分鐘的流程自動化，提高試行次數行動量指的是「試行次數」，不是「被綁住的時間」。
■ KPI 的兩項規則
KPI 是為了達成目標而數值化的指標，規則只有兩條。
規則說明工程師的例子明確數值化任何人都能看出是否達成「每週送出 5 個 PR」自己能控制不依賴他人或運氣「在 24 小時內回覆 Review」而在追蹤 KPI 時，最需要注意的陷阱是 「KPI 達成本身變成目的」。
KPI 只是達成 P（目標）的手段。
如果為了「每週送出 5 個 PR」而開始量產沒有意義的零碎 PR，那就本末倒置了。
所以識學規定目標最多只能有 5 個。如果不是你隨時都能記住的數量，就無法真正意識到它。
■ 「成約率 80%」的陷阱
書中最讓人有感的，就是第二章的這個比喻。
人物行動數成果數機率A 10 件 8 件80%B 100 件 50 件50%如果只看機率，A 贏了；但成果的絕對量，B 卻是 A 的 6 倍以上。
而最可怕的是，在以機率評價的組織裡，挑戰反而會變成吃虧的事。
工程師的世界裡也完全一樣。
開始用機率保護自己的人，會出現的症狀
- 只接不太可能失敗的任務
- 不再提新技術的建議
- 只送出「一定會過」的 PR
- 不再發問（怕被覺得自己不懂）經驗越多，就越容易害怕失敗。也因為這樣，才更需要有意識地把分母做大。
■ 辨識「變數」與「定數」
這是本書的核心。
- 變數 ＝ 應該思考的事、可以改變的事
- 定數 ＝ 想也沒用的事、無法改變的事
工作中最重要的，就是分辨這兩者，並且只專注在變數上。
如何找出變數
- 先自己提出假說並進行驗證
- 將工作細分，把「行動（D）」縮小到一個，並集中投入
- 確認結果變化；若成果不大，就改變「行動（D）」
也就是說，把「流程」拆開、把「數字」數出來、反覆追問「為什麼？」。
這對應到 PDCA 裡的 C 和 A。
工程師平常應該也很常做，這和效能調校的思路很像。
改善緩慢的 API（＝找出變數）
1. 拆解流程 → DB 連線 / 查詢執行 / 序列化 / 網路
2. 數據量測 → 分別是 5ms / 1200ms / 30ms / 15ms
3. 反覆追問為什麼 → 查詢很慢 → 為什麼？ → 沒有索引
⇨ 真正的變數是「索引」本書主張的，就是把這件事套用到自己的職涯與工作方式上。
「別人說的話」也全部視為假說
書籍、前輩的建議、這篇文章，全部都不是絕對成功法則。
先把它們當成「假說」來做行動（D），並驗證是否能讓目標達成出現變化。
自己的成功經驗也應該積極分享，但前提永遠是要記得：它們只是 「有可能有幫助」。
不存在為了成功而存在的絕對法則。
■ 變數如果放著不管，就會持續增加
持續改善下去之後，變數和 KPI 也會越來越多。
變數太多，對執行者和管理者來說都會增加管理成本，並成為成果半吊子的原因。
所以需要定期做「捨棄」的判斷。
專注於「真正重要的事」——這句話人人都會說，但實際做得到的人少得驚人。
管理者的角色
本書在第 4 章明確定義了管理者的工作。
- 檢查部屬設定為 KPI 的「變數」
- 減少不必要的「變數」，讓對方注意到重要的「變數」
接著書中還寫道：
不放任錯誤的努力，並讓對方認知到它，這才是真正的回饋。
出於體貼而視而不見，並不是回饋。
■ 短期與長期，兩種視角
第 1 章到第 4 章談的都是「短期」成長。到了第 5 章，視角切換了。
也就是「短期看似吃虧，但長期會有好處」的觀點。
工程師應該都很有感。
短期吃虧長期有利寫測試的時間能對變動有韌性的程式碼寫文件的時間提升整個團隊的生產力在 Code Review 中仔細指正成員成長學習新技術選擇變多而當成果是以長時間尺度來判斷時，「行動實績」與「具體成果」應該分開評價。
只看「行動實績」會導致「先做先贏」。
反過來，如果只看成果，會扼殺那些正在累積正確行動的人。
管理者所需要的勇氣與覺悟
第 5 章最後以對管理者的訊息作結。
- 即使目標尚未達成，只要判斷「行動」是正確的，就要有勇氣去鼓勵對方
- 即使最後沒有成果，也要對自己指示對方持續做下去這件事，承擔責任
數值化不是用來把成員逼上絕路，而是為了守護正確的行動。這是本書我最喜歡的部分。
總結
- 先把所有事情一律「數值化」來思考。模糊的詞彙無法被評價，也無法被改善
- 「會做事的人」＝ 能從評價者那裡獲得評價的人。不要用定性印象來談
- 不要在 P 上花太多時間，盡快進入 D。行動量是試行次數，不是被綁住的時間
- KPI 只保留同時符合「數值化」與「可控制」兩條件的項目
- 用機率保護自己會讓挑戰停滯。要有意識地把分母做大
- 分辨變數與定數，只專注變數。拆解流程、數數字、反覆追問為什麼
- 別人的建議與書籍內容都只是假說。不存在絕對成功法則
- 變數會持續增加。要定期捨棄，目標最多 5 個
- 短期的吃虧可能換來長期的收益。行動實績與具體成果要分開評價
那到底該做什麼❓
從明天開始，照這個順序做。
【今天之內要做】
- 把目前自己的目標寫到紙上。將不是數值化的項目標記出來
- 把所有有標記的項目，全部改寫成數值表達（例：「提升程式碼品質」→「每月 review 指正降到 5 件以下」）
【本週內要做】
3. 把改寫後的目標中，「自己無法控制」的部分刪掉
4. 將剩下的項目收斂到最多 5 個。拿出捨棄第 6 個以後項目的勇氣
5. 把自己現在正在煩惱的事情分成「變數」與「定數」。從今天起，停止抱怨定數
【每週要做】
6. 在週末實際數一次 KPI 的數字（不要只憑感覺，要用實測）
7. 確認與目標的差距，連續問「為什麼？」3 次
8. 至少提出 1 個新的假說，並在下週驗證
【每季要做】
9. 盤點 KPI。把沒有效果的變數淘汰掉
10. 回顧自己是否有在投資「短期吃虧但長期有利」的事情
第一步只要做「① 把目前的目標寫出來」就好。5 分鐘就能完成。
能不能不逃避，並從這一步開始數值化，就是讀完這本書的人和只看完的人之間的分界線。
株式會社 xincere
株式會社 xincere 正在招募沒有實務經驗的工程師，以及學生工程師實習生，並與他們一同工作。
※ 關於 xincere 的工作方式，請參考這裡
在 xincere，每年約有 100 位沒有實務經驗的人申請並接受技術面試。
透過這些經驗，這裡會介紹希望實務未經驗者務必要掌握的技術能力（語法）。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
