こんにちは、株式会社TIMEWELLの濱本です。
当社はエンジニアの会社です。全員が開発に飢えていて、動くものを作りたくて仕方がありません。だからこそ、FDE（Forward Deployed Engineer）として顧客の現場に入るときに、いちばん気をつけているのは「すぐに作らないこと」ではなく、「作る前に何を聞くか」です。FDEの価値はコードを書く速さではなく、現場から本当の要件を引き出す技術にある、と以前の記事で書きました。今回はその技術のうち、インタビューに絞って、当社のエンジニアが外部の研修で学び、現場で使い、うまくいかなかった部分も含めて整理します。
この記事は、FDEの実践を掘り下げるシリーズの1本目です。FDEという職種そのものと、当社がFDEスタイルを取る理由はFDEとは何かに、AI伴走支援との違いは別の記事に書いています。ここではその先、つまり現場に座った後に、口をどう開くかの話をします。自社のチームがAIを使って現場の要件をどこまで扱えているかを先に確かめたい方は、AIリテラシー診断を使ってください。
なぜエンジニアがインタビューを学ぶのか。仕様書は嘘をつく
最初に、なぜエンジニアがわざわざ聞く技術を学ぶのかを書きます。理由は一つで、仕様書は嘘をつくからです。悪意の嘘ではありません。仕様書を書いた人が、自分の仕事を仕様として語れないのです。
現場の仕事の大半は、言葉になっていません。付箋に書かれた例外ルール、Excelの隠し列、上司に確認するために開く別の画面。担当者は毎日それをやっていますが、「うちの業務を説明してください」と言われると、あるべき手順を話します。実際の手順ではなく。これは担当者の能力の問題ではなく、人間の記憶の性質です。ユーザーインタビューの実務でよく指摘されるとおり、人は自分の行動を正確に思い出せず、意見や一般論で答えてしまいます1。
トヨタの現場には「現地現物」という言葉があり、大野耐一氏は「なぜを5回問え」と言いました。トヨタ自身の解説によれば、問題の性質と解決策は、なぜを繰り返すうちに明らかになる、というのが趣旨です2。私はこれを、エンジニアがインタビューを学ぶ理由そのものだと思っています。要件は与えられるものではなく、現場で掘るものです。掘る道具が質問で、掘る場所が現場です。
これはPalantirのFDEが実際にやってきたことでもあります。8年間FDEとして働いた元社員の回想によれば、入社時に配られた本の中に、ユーザーインタビューの実務書『Interviewing Users』と、即興演劇の理論書『Impro』が入っていました。顧客の現場に入って信頼を得るには、聞く技術と、部屋の空気を読む技術が要る、という判断です3。エンジニアの会社が、コードの本ではなくインタビューの本を新人に渡していたわけです。
そして、掘ったものをどう使うかがFDEの特徴です。コンサルタントは掘ったものを報告書にします。FDEはその日のうちに動くものにして、担当者の前に置きます。動くものを見た担当者は、白紙の前では言えなかったことを言い始めます。だから、FDEのインタビューは「聞いて終わり」ではなく、「聞いて、作って、また聞く」の往復です。この往復の速さが、当社が最速で実装できると言っている根拠の半分です。残りの半分は別の記事で書きます。
受託開発のヒアリングとは、聞く目的が違う
ここで一つ、はっきりさせておきます。FDEのインタビューは、受託開発の要件ヒアリングとは目的が違います。現場に入って聞く、という動作だけを見ると同じに見えるので、違いを表にします。
| 観点 | 受託開発のヒアリング | FDEのインタビュー |
|---|---|---|
| 聞く目的 | 要件を固めて、見積と検収の基準にする | 成果に届く最短の「動くもの」を見つける |
| スコープ | 契約で固定し、変更は追加費用 | 顧客のミッションに沿う拡大は歓迎、製品の原則に反する枝には根拠を示して断る |
| 成果物の帰属 | 顧客の資産 | 型は自社製品の標準機能へ返す、顧客固有の枝は枝として管理する |
| 工数 | 売上。長く続くほど良い | 投資。顧客あたりの工数が減るほど良い |
| 終わり方 | 検収して撤収 | 顧客が自走し、次の顧客へ横展開 |
受託のヒアリングは、後で揉めないために聞きます。だから、聞いた内容は仕様書に固め、変更は追加費用にします。この構造では、担当者が動くものを見て「実は違った」と言うことは、歓迎されません。FDEのインタビューは逆で、「実は違った」を早く引き出すために聞きます。Palantirの商用部門を率いた人物は、FDEを「権限ゼロのCEO」と呼び、顧客の要望を製品の現状に縮める係ではなく、顧客の事業成果に責任を持つ人だと書いています。顧客のミッションが求めるならスコープの拡大を歓迎する、ただし製品の原則からは逸脱しない、とも4。
一方で、何でも聞き入れるわけでもありません。a16zが2026年1月に整理した「Palantir化」の論考は、FDEの型を見分ける圧力テストとして、成熟した顧客で工数が減っているか、カスタマイズに「No」と言えるか、50社を超えても回るか、の三つを挙げています5。当社の言葉にすると、金曜に持ち帰って「型か枝か」を分ける週次の判断です。型なら製品に返し、枝なら増えすぎないよう見張り、製品の原則に反する枝には根拠を示して断ります。この判断を怠ると、a16zが2025年に警告した「サービスの罠」、つまり製品の背骨がないまま人を送り込む単価の高い受託になります6。
2026年に入って、この型は大手にも広がりました。OpenAIは5月に約150人のFDEを擁する実装専門会社を立ち上げ、典型的な進め方を「価値の診断、経営と現場で選ぶ少数の優先ワークフロー、組織の中での設計と構築と展開」と説明しています7。AWSは6月に10億ドルを投じてFDE組織を作り、終了時に顧客が自走できる状態、つまり動くものと文書と訓練された社内人材を残すことを設計の中心に置きました8。日本でも、アクセンチュアが4月にFDEの専門組織を設けたのを皮切りに9、大手コンサルティング会社やクラウド事業者が相次いでFDE組織を作り、FDEを提供する企業を一覧にしたカオスマップが公開されるほど、名前が広がっています。名前が広がるほど、受託との違いを説明する責任は、FDEを名乗る側にあります。だからこの記事は、聞き方の細部まで書いています。
FDEのインタビューは3種類ある。目的で聞き方を変える
現場に入って1週目に、私たちは3種類のインタビューを使い分けます。混ぜると失敗します。
| 種類 | 目的 | 主な質問 | 成果物 |
|---|---|---|---|
| 発見 | 業務の地図を作る | 「昨日の午後、何をしましたか」「その次は」 | 業務の流れ、名詞と動詞の一覧 |
| 深掘り | 例外と困りごとを集める | 「先月いちばん困った件は」「最後にどう処理しましたか」 | 例外ノート、最初に作る機能の候補 |
| 検証 | 動くものへの反応を取る | 「何が違いますか」 | 修正リスト、次の版 |
発見インタビューは、初日と2日目です。目的は業務の地図を作ることで、正しさより網羅を優先します。ここで大事なのは「業務を説明してください」と言わないことです。代わりに「昨日の午後、何をしましたか」と聞きます。昨日なら思い出せます。「その次は」「その画面はどこにありますか」と、時間の順に辿ります。辿りながら、その会社の名詞と動詞を、システム用語に翻訳せずに書き留めます。「引き当て」と「確保」が別の意味だと分かるのは、この段階です。もう一つ、発見の段階で必ず聞くのが、データの持ち主です。「その数字はどのシステムから来ていますか」「そのシステムの管理者は誰ですか」。Palantirの元FDEは、8〜12週間のパイロットのほとんどがデータへのアクセス交渉に費やされた例を挙げ、障害は技術ではなく組織政治だったと書いています3。データの持ち主を初日に特定しておくと、2週目に止まりません。
深掘りインタビューは、3日目以降です。目的は例外を集めることです。普段の業務は既存のシステムで回っているので、FDEが入る余地は例外にあります。ここで使うのが、後で説明するクリティカル・インシデント法です。「先月いちばん困った件は何でしたか」「その件は最後にどう処理しましたか」「その処理を知っているのは誰ですか」。答えは、その人の頭の中にだけあるルールです。
検証インタビューは、動くものができた瞬間から始まります。早ければ初日の夕方です。不完全なものを置いて、「何が違いますか」とだけ聞きます。「どう思いますか」と聞くと、褒められて終わります。「何が違いますか」と聞くと、違いを探し始めます。この技術は、新規事業の顧客インタビューに移植してライブモックの記事で手順を書きました。
3種類を分ける理由は、質問の性質が違うからです。発見は時間順、深掘りは出来事ベース、検証は差分ベースです。混ぜると、担当者は「何を答えればいいのか」が分からなくなり、一般論に逃げます。
質問設計の原則。過去の具体、行動、例外
質問の作り方には、研修で学べる原則があります。当社のエンジニアが外部の研修で学んだ型を、私の言葉で3つにまとめます。
第一に、未来の意見ではなく、過去の行動を聞くことです。「こういう機能があったら使いますか」という質問には、ほぼ全員が「使います」と答えます。礼儀として。スタートアップの顧客インタビューの定番書『The Mom Test』が繰り返しているのも、相手の人生の具体的な事実を聞け、自分のアイデアについて意見を求めるな、という一点です10。FDEの現場では、これを「その作業を最後にやったのはいつですか。そのとき何が起きましたか」という形にします。
第二に、出来事を聞くことです。1954年にジョン・フラナガンが『Psychological Bulletin』で体系化したクリティカル・インシデント法は、人の行動を直接観察できる形で集める手続きで、具体的で重要な出来事に絞って、何が起きて、どう対処して、結果どうなったかを聞きます11。もともとは第二次大戦中の航空心理学の研究から生まれた方法ですが、ユーザー体験の調査でもいまも使われています12。FDEにとってこの方法が効くのは、例外が出来事の形で記憶されているからです。「例外ルールを教えてください」では出てきませんが、「先月いちばん困った件」なら出てきます。
第三に、なぜを重ねることです。ただし、なぜを5回繰り返すと、相手を追い詰めることがあります。「なぜその手順なんですか」「なぜですか」「なぜ」。3回目あたりで、相手は責められていると感じます。トヨタの5回のなぜは、問題に対して問うものであって、人に対して問うものではありません2。当社では「なぜ」を「何が」に言い換えます。「その手順を変えられないのは、何が引っかかっているからですか」。同じ深さに、人を責めずに降りられます。
言い換えの例を表にしておきます。左がやりがちな質問、右が現場で機能した質問です。
| 避けたい質問 | 置き換えた質問 |
|---|---|
| この機能があれば便利ですか | その作業を最後にやったのはいつで、何分かかりましたか |
| 業務の流れを教えてください | 昨日の午後、最初に開いた画面は何ですか |
| 困っていることはありますか | 先月いちばん時間を取られた件は何でしたか |
| なぜその手順なんですか | その手順を変えると、何が困りますか |
| データはきれいですか | 空欄になっていることが多い項目はどれですか |
右側に共通するのは、具体的な時間、具体的な画面、具体的な項目を指していることです。相手が答えるために思い出す対象が決まっている質問です。左側は、相手が何を思い出せばいいのかが決まっていません。
聴き方の技術。沈黙、オウム返し、二人一組
質問が良くても、聴き方で台無しになります。ここは研修で学び、現場で何度も失敗したところです。
沈黙を待つこと。質問の後に3秒、相手が答えた後にさらに3秒、黙ります。エンジニアはこれが苦手です。空白を埋めたくなり、自分で答えの候補を言ってしまいます。「つまり、承認が遅いということですか」。言った瞬間に、相手はその候補に乗ります。乗られた答えは、相手の答えではなく、こちらの仮説です。黙っていると、相手は言い足します。言い足した部分に、例外が入っています。
オウム返し。相手の言葉を、そのまま返します。「引き当てが二重になる、と」。言い換えてはいけません。「在庫の重複ですね」と言い換えると、相手の言葉が消えます。その会社の名詞と動詞を辞書にしていく作業は、オウム返しから始まります。返した言葉が違っていれば、相手が直してくれます。直された言葉が、その会社の正しい用語です。
二人一組で入ること。一人が聞き、一人が記録します。聞く人はメモを取りません。メモを取ると、目線が下がり、相手の表情と手元の画面が見えなくなります。記録する人は、発言を逐語で残し、相手が画面を指した、付箋を見た、隣の席に確認した、という動作も書きます。この動作の記録が、次の記事で扱う観察法への入口です。一人で入るときは、同意を取って録音し、聞くことに集中します。
「見せてください」と言うこと。説明が長くなったら、「その画面を見せてもらえますか」と切り替えます。説明では出てこなかった手順が、画面には全部あります。インタビューと観察の境目はここで、コンテクスチュアル・インクワイアリーと呼ばれる手法は、まさに相手の作業の場に行き、作業しているところを見ながら聞く、という設計になっています13。私たちは、インタビューは観察の前座だと考えています。
三層を分けて聞くこと。経営、事業部長、現場は、同じ案件について違うことを望んでいます。同じ会議室に集めると、経営の声だけが残ります。この点は前の記事で書いたので繰り返しませんが、聴き方として一つ足すなら、現場の担当者に聞くときは上司を同席させないことです。上司がいると、担当者はあるべき手順を話します。
研修で身についたこと、現場でしか身につかなかったこと
正直に書きます。当社のエンジニアは、現場に入る前にインタビュー技法の研修を受けています。研修は役に立ちました。誘導質問を避ける、過去の出来事を聞く、沈黙を待つ、記録と聞き役を分ける。これらは型で、型は教わればできます。研修を受けた後、質問の作り方は変わりました。
一方で、研修では身につかなかったものがあります。担当者の説明と、実際の画面のずれに気づく力です。「いつも承認は課長がします」と言われた直後に、画面で係長の名前が承認欄に入っているのを見て、「あれ」と思えるかどうか。この「あれ」を言葉にして、「係長が承認することもあるんですか」と聞き返せるかどうか。この力は、動くものを置いて反応を取る経験を重ねないと育ちませんでした。違和感の言語化について書いた記事で、AIが文脈に引きずられて抽象化できないときに人が気づく能力が要る、と述べましたが、インタビューでも同じです。研修は「聞く型」を与え、現場は「ずれに気づく目」を与えます。
もう一つ、研修と現場で違ったのは、時間です。研修では60分のインタビューを設計しますが、現場の担当者は忙しく、まとまった60分は取れません。取れるのは、作業の合間の10分と、動くものを見せたときの5分です。だから当社のインタビューは、短く、何度も、になりました。1回で全部聞こうとせず、動くものを置くたびに5分聞く。この形のほうが、60分のインタビューより多くの例外が出てきました。担当者が、動くものを見て思い出すからです。
AIの時代のインタビュー。記録はAIに、場は人に
最後に、AIをどう使っているかです。
録音と文字起こしは、AIに任せています。同意を取って録音し、逐語録を起こし、名詞と動詞を抜き出して辞書の下書きを作る。ここまでは機械のほうが速く、正確です。ただし、要約はさせません。AIの要約は、毎回起きる普段の業務を残し、月に一度の例外を落とします。FDEにとって価値があるのは例外のほうなので、逐語録から人が拾い直します。要約は便利ですが、便利な分だけ、いちばん大事なものが消えます。
AIに任せられないものが三つあります。沈黙、言いよどみ、そして「見せてください」と言ったときに出てくる画面です。文字起こしには、相手が3秒黙った理由は残りません。「えっと、まあ、基本的には」の後に来る「ただ」は、文字にすると平坦ですが、その場では例外の合図です。画面に至っては、そもそも音声に乗りません。だから、聞く場と見る場は人が持ち、記録と分類はAIに渡す、という分担にしています。
この分担は、次の記事で扱う観察法と、その先のビデオ撮影とAI分析につながります。現場を撮らせてもらい、後からAIで分析する方法を当社は使い始めていますが、そこでも同じで、撮る前の同意と、撮っているときに人が見ているものが、分析の質を決めます。
まとめ
FDEを成立させるのは、コードの速さではなく、聞く技術です。仕様書は嘘をつくので、要件は現場で掘ります。掘り方は3種類で、発見は時間順に、深掘りは出来事ベースで、検証は動くものへの差分で聞きます。質問は、未来の意見ではなく過去の行動を、一般論ではなく具体的な出来事を、なぜではなく「何が」を聞く形にします。聴き方は、沈黙を待ち、オウム返しをし、二人一組で入り、説明が長くなったら画面を見せてもらいます。
研修で身につくのは型で、現場で身につくのはずれに気づく目です。当社のエンジニアはその両方を持って現場に入り、聞いたことをその日のうちに動くものにして、また聞きます。この往復が、私たちの実装の速さの半分を作っています。
エンジニアのチームに現場で聞く力をつけたい方、あるいは自社の現場にFDEを受け入れる準備を整えたい方は、WARPのプログラムをご覧いただくか、個別相談でお話ししましょう。次の記事では、聞くことの先にある観察法、シャドーイングとコンテクスチュアル・インクワイアリーを扱います。
Footnotes
-
User Interviews: How, When, and Why to Conduct Them（Nielsen Norman Group）。人は自分の行動を正確に自己申告できない、という指摘は同記事による ↩
-
Ask 'why' five times about every matter（トヨタ自動車 Toyota Traditions） ↩ ↩2
-
Reflections on Palantir（Nabeel S. Qureshi、2024年10月15日）。入社時に配られた本、FDEの常駐頻度、1〜2週間で使えるものを出す慣行、データアクセス交渉の逸話は同稿による ↩ ↩2
-
Sorry, that isn't an FDE（Ted Mabrey、2024年9月21日）。「権限ゼロのCEO」、スコープ拡大の歓迎、製品原則からの不逸脱は同稿による（筆者訳） ↩
-
The Palantirization of everything（Marc Andrusko、a16z、2026年1月16日）。三つの圧力テストは同稿による ↩
-
Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups（Joe Schmidt、a16z、2025年6月） ↩
-
OpenAI launches the OpenAI Deployment Company（OpenAI、2026年5月11日）。典型的なエンゲージメントの進め方、Tomoro買収による約150人のFDEは同発表による ↩
-
AWS invests $1 billion to embed AI forward deployed engineers with customers（Amazon、2026年6月30日） ↩
-
マイクロソフトの協力のもと、AIの迅速な全社展開を支援する「フォワード・デプロイド・エンジニアリング」専門組織を設立（アクセンチュア、2026年4月16日） ↩
-
The Mom Test（Rob Fitzpatrick）。相手の人生の具体的な事実を聞き、自分のアイデアへの意見を求めない、という原則は同書による ↩
-
Flanagan, J. C. (1954). The critical incident technique. Psychological Bulletin, 51(4), 327–358. PubMed ↩
-
The Critical Incident Technique in UX（Nielsen Norman Group） ↩
-
Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context（Nielsen Norman Group） ↩
