前言
我成為工程師已經第 4 年了。
在第 1 年的時候，我曾經實作過某個批次處理。
當時的估時是 1 週，但實際上卻花了 3 個月才完成。
原因並不是技術上有多困難。
而是我陷入了「不知道要做什麼」「甚至不知道自己不知道什麼」的狀態，結果就卡住了。因為不知道從哪裡下手，回過神來，1 週、2 週就這樣過去了。
我是在回顧當時的經驗時，讀了牛尾剛先生的《世界一流工程師的思考法》。
這篇文章與其說是摘要，不如說是對照書中的內容，整理當時的自己到底缺少了什麼。
※僅代表個人解讀。
1. 沒有整理「不懂」的部分
現在回想起來，那個批次案件最糟糕的地方，就是我把「不懂」放著不管，一直獨自扛著。
即使看了規格也抓不到全貌。看既有程式碼也不知道彼此之間是怎麼關聯的。即便如此，我也沒有把「不懂」具體說出來，只是想著先動手做做看，假裝自己懂了。結果只是反覆讀同一段內容，完全沒有前進的感覺。
讀完這本書後，最有感的是先把「哪些已經懂了、哪些還不懂」寫出來的重要性。
例如當時的批次處理，應該可以這樣切分：
- 輸入資料格式：懂
- 輸出規格：懂
- 既有的哪些處理應該重用：不懂
- 異常狀況的處理方式：不懂
光是做這件事，就能把「全部都不懂」這種模糊的不安，轉換成「還要確認 2 件事」這種具體工作。
那 3 個月，最大的原因大概就是我一次都沒有做過這種整理。
2. 我以為一定要全部理解之後才能開始
另一個原因，是我想把那個批次所依賴的既有系統「全部理解之後再開始實作」。
我一股腦地讀所有可能相關的程式碼，一個函式一個函式地追，結果一直不知道到底要理解到什麼程度才能開始實作，時間就這樣流走了。
書中寫到，真正需要的是「先理解現在要用的部分」。
能使用 → 能說明 → 能切分問題 → 能追到內部實作
這些是不同層次，並不需要一開始就追求最深的那一層。當時的我，最需要的是先有能做出可運作成果的最低限度理解。至於內部細節，放在後面再理解也可以。
3. 連查資料的方法也沒有整理
每次遇到不懂的地方，我都只是零散地搜尋。像是搜尋「〇〇 錯誤」，讀一篇看起來像的文章，接著又冒出別的疑問，再繼續搜尋。因為沒有留下查了什麼、弄懂了什麼的紀錄，所以有些內容甚至會重複查第二次。
先整理錯誤內容、發生條件、以及前一個改動的地方，再開始查詢。只要多做這一步，就能判斷找到的文章是不是真的跟自己的情況相同。
當時少了這一點，所以就算一直查，也完全沒有接近解決問題的實感。
4. 如果是現在，我大概會這樣做
如果同樣的案件再來一次，我第一步要做的應該不是實作，而是整理。
- 寫出已經知道的事和還不知道的事
- 把不知道的事分成「確認就能知道的」和「不實際動手就不知道的」
- 既有程式碼不要全部讀完，只理解這次變更相關的範圍
- 卡住的時候，先把卡住的內容具體說清楚再去查
我想這樣一來，原本花了 3 個月的案件，大概能縮短到 1 個月左右。
總結
那個批次案件最痛苦的地方，與其說是技術難度，不如說是「連自己不知道什麼都不知道」這種狀態本身。
讀了這本書之後，我才明白，要解決這件事靠的不是衝勁或熟練，而是「整理不懂的地方」這種具體工作。
如果你也有過類似卡住的經驗，不妨試著先把「現在自己到底不懂什麼」寫下來，或許就能重新動起來。
JISOU 招募成員中！
在程式設計教練 JISOU，我們正在招募新成員。
想在日本第一的輸出型社群中提升職涯嗎？
有興趣的人，請務必到官網看看！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
