讓FDE成立的訪談技巧｜從現場引出真正洞察的聽法

大家好，我是株式會社TIMEWELL的濱本。

我們是一家工程師的公司。每個人都對開發如飢似渴，恨不得馬上做出能運作的東西。正因如此，以FDE（Forward Deployed Engineer）的身分進入客戶現場時，我們最留意的不是「不要太早動手做」，而是「動手做之前要問什麼」。我在之前的文章寫過，FDE的價值不在寫程式的速度，而在從現場引出真正需求的技術。這次把範圍縮小到訪談，整理我們的工程師在外部訓練學到的、在現場實際使用的，以及不順利的部分。

這是深入探討FDE實務系列的第一篇。FDE這個職種本身，以及我們採取FDE風格的理由，寫在什麼是FDE；與AI陪跑支援的差異寫在另一篇文章。這裡談的是更後面的事：在現場坐下之後，該怎麼開口。想先了解讓工程師團隊具備這種現場能力的方案，可以先看WARP的頁面。

工程師為什麼要學訪談。規格書會說謊

先說工程師為什麼要特地學提問的技術。理由只有一個：規格書會說謊。不是惡意的謊言，而是寫規格書的人，沒辦法把自己的工作說成規格。

現場工作的大部分都沒有化為文字。便利貼上的例外規則、Excel裡隱藏的欄位、為了向主管確認而另外開的畫面。當事人每天都在做這些，但被要求「請說明貴部門的業務」時，說出來的是應該有的流程，而不是實際的流程。這不是當事人的能力問題，而是人類記憶的性質。使用者研究的實務長期以來就指出，人無法正確回想自己的行為，往往用意見或一般論來回答¹。

豐田的現場有「現地現物」這句話，大野耐一則說「凡事問五次為什麼」。根據豐田自己的說明，問題的本質與解決方法會在反覆追問的過程中逐漸清楚²。我認為這正是工程師該學訪談的理由本身。需求不是別人給的，而是在現場挖出來的。挖的工具是提問，挖的地點是現場。

這也是Palantir的FDE實際在做的事。根據一位在該公司擔任FDE八年的前員工回憶，入職時發的書裡，包含使用者訪談的實務書《Interviewing Users》，以及即興劇場的理論書《Impro》。背後的判斷是：要進入客戶的現場並取得信任，需要提問的技術，也需要讀懂現場氣氛的技術³。一家工程師的公司，發給新人的不是程式的書，而是訪談的書。

而挖出來的東西怎麼用，是FDE的特色。顧問把挖到的東西寫成報告，FDE則在當天做成能運作的東西，放到當事人面前。看到能運作的東西，當事人會開始說出面對白紙時說不出口的話。所以FDE的訪談不是「問完就結束」，而是「問、做、再問」的來回。這個來回的速度，是我們敢說能最快實作的依據的一半。另一半留到別的文章寫。

和委外開發的需求訪談，目的不同

這裡先把一件事說清楚。FDE的訪談，和委外開發的需求訪談目的不同。只看「進入現場、提問」這個動作會覺得一樣，所以用表格列出差異。

觀點	委外開發的需求訪談	FDE的訪談
提問的目的	把需求固定下來，作為報價與驗收的依據	找到能達成成果的最短「可運作之物」
範圍	以合約固定，變更就追加費用	符合客戶使命的擴大表示歡迎，違反產品原則的分枝則說明理由後拒絕
產出的歸屬	客戶的資產	通用的型回流到自家產品的標準功能，客戶專屬的分枝當作分枝管理
工時	營收，做得越久越好	投資，每位客戶的工時越少越好
結束方式	驗收後撤離	客戶自行運作，並橫向展開到下一位客戶

委外開發的訪談，是為了之後不起爭議而問。所以聽到的內容會固定成規格書，變更成為追加費用。在這種結構下，當事人看到能運作的東西後說「其實不是這樣」，並不受歡迎。FDE的訪談正好相反，是為了盡早引出「其實不是這樣」而問。曾領導Palantir商用部門的人把FDE稱為「沒有權限的CEO」，不是把客戶的要求縮小到產品現況的角色，而是對客戶的事業成果負責的人；他也寫道，只要客戶的使命需要，就歡迎範圍擴大，但不偏離產品的原則⁴。

另一方面，也不是什麼都照單全收。a16z在2026年1月整理「Palantir化」的文章中，列出分辨真正FDE型態的三個壓力測試：成熟客戶的工時是否在減少、能否對客製化說「不」、超過50家客戶後是否還能運轉⁵。用我們的話說，就是每週五帶回公司分辨「型還是分枝」的判斷。是型就回流到產品，是分枝就盯著別讓它增生，違反產品原則的分枝就說明理由後拒絕。少了這個判斷，就會落入a16z在2025年警告的「服務陷阱」：沒有產品骨幹就派人進去，最後變成單價很高的委外開發⁶。

進入2026年，這個型態也擴散到大型企業。OpenAI在5月成立擁有約150名FDE的實作專門公司，把典型的做法說明為：診斷價值所在、與經營層及現場共同選出少數優先工作流程、在組織內部設計、建構與部署⁷。AWS在6月投入10億美元成立FDE組織，把結束時客戶能自行運作，也就是留下可運作的系統、文件與受過訓練的內部人員，放在設計的核心⁸。在日本，Accenture於4月成立FDE專門組織⁹，大型顧問公司與雲端業者相繼跟進，甚至有人公開了FDE提供企業的產業地圖，名稱擴散到這個程度。名稱越是擴散，說明與委外開發有何不同的責任，就越落在使用這個名稱的一方。所以這篇文章才會把問法寫到細節。

FDE的訪談有三種。依目的改變問法

進入現場的第一週，我們會區分使用三種訪談。混在一起就會失敗。

種類	目的	主要提問	產出
發現	畫出業務的地圖	「昨天下午做了什麼」「接下來呢」	業務流程、名詞與動詞清單
深掘	蒐集例外與困擾	「上個月最棘手的一件事是什麼」「最後怎麼處理」	例外筆記、最先要做的功能候選
驗證	取得對能運作之物的反應	「哪裡不一樣」	修正清單、下一個版本

發現訪談在第一天和第二天。目的是畫出業務的地圖，涵蓋範圍比正確性優先。這裡重要的是不要說「請說明業務」，而是問「昨天下午做了什麼」。昨天的事想得起來。「接下來呢」「那個畫面在哪裡」，照時間順序追下去。追的同時，把那家公司的名詞與動詞原封不動記下來，不翻譯成系統用語。「分配」和「保留」是不同意思，就是在這個階段知道的。還有一件在發現階段一定會問的事，是資料的持有者。「那個數字來自哪個系統」「那個系統的管理者是誰」。Palantir的前FDE舉例說，曾有8到12週的試行案幾乎全部花在資料存取的交涉上，障礙不是技術而是組織政治³。第一天就找出資料的持有者，第二週就不會卡住。

深掘訪談從第三天開始。目的是蒐集例外。日常業務已經由既有系統運轉，FDE能介入的空間在例外。這裡用的是後面會說明的關鍵事件法。「上個月最棘手的一件事是什麼」「那件事最後怎麼處理」「知道那個處理方式的是誰」。答案是只存在於那個人腦中的規則。

驗證訪談從有東西能動的那一刻開始，快的話是第一天傍晚。把不完整的東西放下，只問「哪裡不一樣」。問「你覺得怎麼樣」，會被稱讚然後結束；問「哪裡不一樣」，對方會開始找差異。這個技巧我移植到新事業的顧客訪談，在即時模型的文章裡寫了步驟。

區分三種的理由，是提問的性質不同。發現是時間順序，深掘是以事件為基礎，驗證是以差異為基礎。混在一起，當事人會不知道該回答什麼，逃向一般論。

提問設計的原則。過去的具體、行為、例外

提問的做法有訓練能教的原則。把我們的工程師在外部訓練學到的型，用我的話整理成三點。

第一，問過去的行為，不問未來的意見。「如果有這個功能，你會用嗎」這種問題，幾乎所有人都會出於禮貌回答「會」。新創顧客訪談的經典《The Mom Test》反覆強調的也只有一點：問對方生活中的具體事實，不要問對方對你的點子有什麼意見¹⁰。在FDE的現場，我們把它變成「上次做那項作業是什麼時候，當時發生了什麼」。

第二，問事件。1954年John Flanagan在《Psychological Bulletin》系統化的關鍵事件法，是一套以可直接觀察的形式蒐集人類行為的程序，聚焦在具體且重要的事件，問發生了什麼、怎麼應對、結果如何¹¹。這個方法源自二次大戰期間的航空心理學研究，至今仍用於使用者體驗研究¹²。它對FDE有效，是因為例外是以事件的形式被記住的。「請告訴我例外規則」問不出東西，「上個月最棘手的一件事」就問得出來。

第三，反覆問為什麼，但要小心。連續問五次為什麼，會把對方逼到牆角。「為什麼是那個步驟」「為什麼」「為什麼」。問到第三次，對方會覺得被責備。豐田的五個為什麼是對問題問的，不是對人問的²。我們把「為什麼」換成「是什麼」。「無法改變那個步驟，是卡在什麼地方」。可以在不責備人的情況下，降到同樣的深度。

把改寫的例子列成表。左邊是容易問出口的問題，右邊是在現場真正有效的問題。

想避免的問題	替換後的問題
有這個功能會方便嗎	上次做那項作業是什麼時候，花了幾分鐘
請說明業務流程	昨天下午最先開的畫面是什麼
有什麼困擾嗎	上個月最花時間的一件事是什麼
為什麼是那個步驟	改變那個步驟的話，會有什麼困擾
資料乾淨嗎	最常空白的欄位是哪一個

右邊共通的是指向具體的時間、具體的畫面、具體的欄位。對方為了回答而要回想的對象是確定的。左邊則沒有確定對方該回想什麼。

聽的技術。沉默、複述、兩人一組

提問再好，聽法不對就全毀了。這是在訓練中學到、也在現場失敗過很多次的地方。

等待沉默。提問之後等三秒，對方回答之後再等三秒。工程師不擅長這件事。想填補空白，就自己說出答案的候選：「也就是說，核准太慢對吧」。一說出口，對方就會順著這個候選走。順著走出來的答案，不是對方的答案，而是我們的假設。保持沉默，對方會補充。補充的部分裡，藏著例外。

複述。把對方的話原封不動說回去。「分配會重複，是這樣」。不能換句話說。說成「就是庫存重複吧」，對方的用語就消失了。把那家公司的名詞與動詞做成辭典的工作，從複述開始。說回去的話如果錯了，對方會糾正。被糾正後的用語，才是那家公司正確的用語。

兩人一組進場。一個人問，一個人記錄。問的人不做筆記。做筆記視線會往下，就看不到對方的表情和手邊的畫面。記錄的人逐字記下發言，也記下對方指了畫面、看了便利貼、向隔壁座位確認等動作。這些動作的記錄，是通往下一篇要談的觀察法的入口。一個人進場時，取得同意後錄音，專注在聽。

說「請給我看」。說明變長時，就切換成「可以讓我看那個畫面嗎」。說明裡沒出現的步驟，畫面上全都有。訪談與觀察的分界就在這裡，被稱為脈絡訪查（contextual inquiry）的方法，設計上正是走到對方工作的場所，一邊看對方工作一邊問¹³。我們認為訪談是觀察的暖場。

分層聽。經營層、事業部主管、現場，對同一個案子的期望不同，聚在同一間會議室只會留下經營層的聲音。這點在之前的文章寫過，就不重複，若要在聽法上補一點，就是訪談現場人員時不要讓主管同席。主管在場，當事人說的會是應該有的流程。

訓練學到的，和只有現場才學得到的

坦白說，我們的工程師在進入現場前接受了訪談技巧的訓練，而且訓練有用。避免誘導式提問、問過去的事件、等待沉默、把記錄與提問分開。這些是型，型教了就會。訓練之後，我們設計提問的方式改變了。

另一方面，有些東西訓練學不到。察覺對方的說明與實際畫面之間落差的能力。被告知「核准一向是課長做的」之後，馬上在畫面上看到核准欄填的是股長的名字，能不能覺得「咦」。能不能把這個「咦」化為語言，反問「有時候是股長核准嗎」。這種能力，不反覆累積把能運作的東西放下、觀察反應的經驗，就養不出來。我在談把違和感化為語言的文章裡提過，AI被脈絡拖著而無法抽象化時，需要有人察覺；訪談也一樣。訓練給的是「問的型」，現場給的是「察覺落差的眼力」。

訓練與現場另一個不同是時間。訓練會設計60分鐘的訪談，但現場人員很忙，湊不出完整的60分鐘。能拿到的是作業空檔的10分鐘，以及展示能運作之物時的5分鐘。所以我們的訪談變成短而頻繁。不試圖一次問完，每放下一個新版本就問5分鐘。這種形式比60分鐘的訪談問出更多例外，因為當事人看到能運作的東西會想起來。

AI時代的訪談。記錄交給AI，場合交給人

最後是我們怎麼使用AI。

錄音與逐字稿交給AI。取得同意後錄音，做出逐字稿，抽出名詞與動詞做成辭典草稿。到這一步為止，機器比人快也比人準確。但我們不讓它做摘要。AI的摘要會留下每天發生的日常業務，丟掉一個月一次的例外。對FDE有價值的是例外，所以由人從逐字稿裡重新撈。摘要很方便，而方便到什麼程度，最重要的東西就消失到什麼程度。

有三樣東西無法交給AI：沉默、支吾，以及說「請給我看」時出現的畫面。逐字稿不會記錄對方沉默三秒的理由。「嗯、這個嘛、基本上」之後接的「只是」，寫成文字很平淡，但在現場那是例外的信號。至於畫面，根本不會出現在聲音裡。所以我們的分工是：聽的場合與看的場合由人負責，記錄與分類交給AI。

這個分工延伸到下一篇要談的觀察法，以及再之後的現場錄影與AI分析。我們已經開始請客戶讓我們錄影、事後用AI分析，那裡也是同樣的道理：錄影前的同意，以及錄影時人在看什麼，決定了分析的品質。

總結

讓FDE成立的不是寫程式的速度，而是聽的技術。規格書會說謊，所以需求要在現場挖。挖法有三種：發現依時間順序問，深掘以事件為基礎問，驗證以能運作之物的差異問。提問要問過去的行為而非未來的意見，問具體事件而非一般論，問「是什麼」而非「為什麼」。聽法是等待沉默、複述、兩人一組進場，說明變長時就請對方給你看畫面。

訓練學到的是型，現場學到的是察覺落差的眼力。我們的工程師帶著兩者進入現場，把聽到的當天做成能運作的東西，再問一次。這個來回，構成我們實作速度的一半。

想讓工程師團隊具備在現場聽的能力，或想為自家現場迎接FDE做好準備的人，歡迎參考WARP的方案，或透過個別諮詢和我們聊聊。下一篇文章談的是聽之後的觀察法：跟隨觀察與脈絡訪查。

Footnotes

1. User Interviews: How, When, and Why to Conduct Them（Nielsen Norman Group）。人無法正確自我陳述行為的指摘依該文 ↩

2. Ask 'why' five times about every matter（豐田汽車 Toyota Traditions） ↩ ↩²

3. Reflections on Palantir（Nabeel S. Qureshi，2024年10月15日）。入職時發的書、FDE的駐點頻率、一到兩週內交出可用之物的慣例、資料存取交涉的軼事依該文 ↩ ↩²

4. Sorry, that isn't an FDE（Ted Mabrey，2024年9月21日）。「沒有權限的CEO」、歡迎範圍擴大、不偏離產品原則依該文（筆者譯） ↩

5. The Palantirization of everything（Marc Andrusko，a16z，2026年1月16日）。三個壓力測試依該文 ↩

6. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups（Joe Schmidt，a16z，2025年6月） ↩

7. OpenAI launches the OpenAI Deployment Company（OpenAI，2026年5月11日）。典型的合作流程、收購Tomoro帶來約150名FDE依該發布 ↩

8. AWS invests $1 billion to embed AI forward deployed engineers with customers（Amazon，2026年6月30日） ↩

9. 在Microsoft協助下成立支援AI快速全公司導入的「Forward Deployed Engineering」專門組織（Accenture日本，2026年4月16日，日文） ↩

10. The Mom Test（Rob Fitzpatrick）。問對方生活中的具體事實、不問對你點子的意見，這項原則依該書 ↩

11. Flanagan, J. C. (1954). The critical incident technique. Psychological Bulletin, 51(4), 327–358. PubMed ↩

12. The Critical Incident Technique in UX（Nielsen Norman Group） ↩

13. Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context（Nielsen Norman Group） ↩