初次見面。我是 PRUM 株式會社的工程師人見。
我平常會整理並分享，在程式學習與實務工作中容易卡住的點，以及工作上常發生的「落差」。
如果能幫助到任何人，我會很高興。
1 成受信賴的工程師會實踐的「提問題的方法」
前言
剛入行的時候，越是發生問題，往往越容易沉默。
- 再多查一下之後再問吧
- 可能得靠自己解決才行
- 還不到需要諮詢的程度
- 對方看起來很忙，之後再說吧
就這樣，最後一個人把問題扛下來。但在現場，這其實相當危險。
因為在團隊開發中，真正可怕的不是「不知道什麼」，而是「卡住這件事沒有被共享」。
現場最可怕的回報
現場很常見這樣的對話。
「現在進展如何？」
接著得到的回答是：
「其實從昨天開始就卡住了……」
這其實很可怕。因為比起問題本身，
更可怕的是「已經卡住的時間」存在著。
如果昨天那時候就有共享，
- 也許別人可以看
- 也許可以改變方針
- 也許可以調整優先順序
但如果自己一直扛著，團隊就無法掌握狀況。
也就是說，判斷本身會延遲。 這才是最危險的地方。
把問題藏起來，團隊就無法做判斷
當然，自己先思考是很重要的。
- 看 log
- 讀錯誤訊息
- 整理原因
- 建立假設
這種態度是必要的。不過，真正的問題在於，
「持續把它扛在自己身上」。
剛入行的時候，常常會覺得：
「還不到可以諮詢的程度。」
但在現場，延遲諮詢反而更危險。因為一旦把問題悶著，團隊就無法做判斷了。
受信賴的人會提出「問題 + 假設 + 判斷依賴」
如果問題能在早期就被共享，
- 也許可以改變方針
- 也許別人可以支援
- 也許能在還小的時候修正
但如果悶著不說，問題就會在看不見的情況下持續往前走。
所以越是值得信賴的人，越不會隱瞞問題。不只是單純丟一句
「我遇到困難了」，而是會先整理狀況再共享。
現在發生了這樣的問題。
我認為原因是 ○○。
我想往 △△ 的方向修正，這樣可以嗎？
也就是說，能夠把
「問題 + 假設 + 判斷依賴」 一起提出來。
升級回報不是「輸了」
剛入行的時候，很多人對升級回報會有抗拒感。
- 好像是自己能力不足
- 好像會造成麻煩
- 好像會被罵
很容易這樣想。但升級回報本來就是
「為了避免團隊發生事故的行為」。
登山也是， 把危險天候隱瞞下來還繼續前進更危險。
航海也是， 不回報航向偏移更危險。
那麼，開發呢？
當然也是一樣。
如果有問題，越早共享越好。
這樣才能夠做出以下判斷：
- 增加人手
- 改變方針
- 調整時程
- 切換到其他方案
「能早點提出問題的人」會讓人安心
在團隊開發裡，說到底「安心感」其實非常重要。
- 有危險時會說
- 卡住時會共享
- 覺得不行時會提早諮詢
這種人會讓合作變得很順。
相反地，最可怕的是：
- 一直沉默到最後一刻
- 一直說沒問題
- 扛著不說，然後停住
這種狀態。
所以在現場，比起「不會出問題的人」，
「能夠及早把問題提出來的人」 更受信賴。
結語
工作上，發生問題本身是無法避免的。
重要的不是「不要發生問題」，而是「怎麼處理問題」。
- 不要自己一個人扛
- 一開始卡住就共享
- 覺得有風險就先提出來
- 需要判斷時就提早諮詢
只要做到這些，團隊的運作就會有很大的不同。
而且我想，受信賴的工程師
並不是「什麼都能自己解決的人」，
而是「能正確把問題帶到外部的人」。
PRUM 的工程師中，有 95% 以上是從零經驗錄用的。
我們也經營著一個整理了
想從零經驗朝工程師邁進的人，以及工程師本人都能派上用場的文章網站。
如果有興趣，歡迎看看。
【推薦文章】
從銀行行員、公務員到 Web 業界。從不同產業轉職的人，為何會對工程充滿「沉浸式投入」？
原文出處：https://qiita.com/hitomin_poke/items/48b1eca9c48f05839692
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
