FDEのワークショップ進め方とは？顧客課題を引き出す設計と運営の手順

FDEのワークショップは、顧客と一緒に現場の業務を分解し、「何を解くべきか」と「次に何を検証するか」を関係者で合意するための作業の場です。報告や仕様の確定を目的とする通常の会議とは、ゴールがはっきり違います。この記事では、設計から運営、PoC（概念実証）への接続までを実務の手順に沿って整理します。

FDEのワークショップとは？目的と通常の会議との違いは？

FDEのワークショップは、顧客の現場業務を一緒に分解し、解くべき課題と検証範囲を合意するための作業の場です。

FDE（Forward Deployed Engineer）は顧客の現場に入り込み、課題の発見から実装までを一気通貫で担う職種です。その最初の山場がワークショップです。ここで課題の解像度が上がらないと、後工程のPoCや実装は「作ったが使われない」に陥りやすくなります。

ワークショップの目的は「課題の特定」と「合意の獲得」

目的は、顧客自身もまだ言葉にできていない業務課題を特定し、次に何を検証するかを関係者で合意することです。

顧客が最初に口にする要望は「AIで業務を効率化したい」「ダッシュボードが欲しい」のように、手段の形をとることが多くあります。FDEの仕事は、その要望の裏にある業務上の詰まりを見つけることです。誰が、どの判断で、どれだけ時間を取られているのかを具体的に掘り下げます。現場の感覚としては、要望をそのまま受け取らずに「その画面ができたら、誰の何の作業が減りますか」と問い直すだけで、議論の質が大きく変わる場面が多いと感じます。

通常の定例会議・要件定義との違い

定例会議は情報共有、要件定義は仕様の確定を目指します。FDEのワークショップが目指すのは、課題仮説の検証です。

いちばん大きな違いは「実物を前に話す」ことです。帳票、業務システムの画面、Excelの集計表などを画面に出し、現場の担当者が普段どう触っているかを見ながら議論します。

Palantirの「AIP Bootcamp」に見る原型

Palantirは自社のAIP（Artificial Intelligence Platform）の導入で「Bootcamp」と呼ぶ短期集中の実践型セッションを展開しています。FDE型ワークショップの代表例と言えます。

Palantirは2023年以降、顧客企業の実データを使ってユースケースを短期間で形にするAIP Bootcampを、決算説明や公式発表のなかで顧客獲得の主要な手段として紹介しています。机上の要件整理ではなく「その場で動くものを見せて合意する」という発想は、規模の大小を問わずFDEのワークショップ設計の参考になります。

ワークショップの進め方は？準備から合意形成までの手順は？

進め方は「事前準備→現場理解→課題の洗い出し→優先順位付け→合意と次アクション」の5段階で設計すると安定します。

当日の進行力よりも、事前準備の質が成果を左右します。準備が8割と考えても大げさではありません。

事前準備で決めておくべき5項目

事前準備では、ゴール・参加者・持ち込む実物・仮説・成果物の型の5項目を、開催前に顧客と合意しておきます。

初期仮説は外れても構いません。仮説があることで、顧客は「そこではなく、実はこっちが問題で」と反応しやすくなります。白紙で「何かお困りごとは」と聞くより、はるかに情報が出てきます。

当日の標準タイムテーブル（半日版の例）

当日は半日（約3時間）を目安に、前半で現場を理解し、後半で課題を絞り込む構成にすると進めやすくなります。

1. 導入（15分）：ゴールと進め方、当日の成果物を共有する
2. 業務の再現（45分）：現場担当者に実際の画面や帳票を操作してもらい、業務の流れを追う
3. 課題の洗い出し（45分）：業務フローの各ステップで「時間がかかる」「判断に迷う」「やり直しが起きる」箇所を付箋やホワイトボードに書き出す
4. 休憩（10分）
5. 優先順位付け（40分）：インパクトと実現しやすさの2軸で課題を並べる
6. 合意と次アクション（25分）：PoC候補、担当、期限を決めて読み上げる

時間配分はあくまで一例です。業務が複雑な場合は「業務の再現」だけで1回を使い、2回に分けて開催するほうがうまくいくこともあります。

合意形成と記録の残し方

合意は口頭で終わらせず、その場で画面に書き、読み上げて確認したうえで当日中に共有するのが原則です。

ワークショップ後に「そういう意味で言ったのではない」という認識のズレが起きるのは珍しくありません。対策は、FDEか書記役が議論をリアルタイムで共有画面に書き、最後に決定事項・保留事項・次アクションを読み上げることです。当日中に送るまとめは、決定事項を冒頭に置き、議事の詳細は後ろに回すと読まれやすくなります。

顧客の業務課題を引き出すファシリテーションのコツは？

コツは、意見ではなく事実を聞くこと、実物を一緒に触ること、決める人と現場の声を同じ場に揃えることの3点です。

「どう思うか」より「最後にどうやったか」を聞く

課題を引き出すには、意見や希望を聞くより、直近の具体的な業務行動を時系列で聞くほうが正確です。

「何が不便ですか」と聞くと、一般論や他部署への不満が返ってきやすくなります。「先週その集計をしたとき、最初に何を開きましたか」と聞けば、実際の手順と詰まりが見えてきます。

数値はその場で正確に出てこなくても構いません。「だいたい半日」「月末に2日」といった概算でも、優先順位付けの材料には十分なります。

画面共有と実データで「一緒に触る」

業務システムやExcelを実際に操作してもらいながら議論すると、口頭では出てこない例外処理や暗黙のルールが見えてきます。

現場担当者は自分の作業を「普通のこと」と捉えていて、説明から抜け落ちる手順が少なくありません。操作を見ていると「ここで別のファイルを開いて目視で突き合わせています」といった工程が出てきて、それが自動化の本命になることもあります。FDEは、気づいた点をその場でメモし、「今の突き合わせは毎回発生しますか」と確認していきます。

発言の偏りと「決める人の不在」を防ぐ

役職者の発言に場が引っ張られないよう、まず個人で書き出してから共有する進め方を取り入れると効果的です。

付箋や共有ボードに各自が黙って書き出す時間を5分ほど取るだけで、若手や現場担当者の視点が出やすくなります。一方で、最終的な優先順位を決める場面には決裁権を持つ人が必要です。現場と意思決定者の両方が揃わない場合は、開催日をずらしてでも揃えるほうが、結果的にPoCまでの期間は短くなりやすいというのが実務上の実感です。

ワークショップの成果をPoCや実装へつなげるには？

成果をPoCへつなげるには、課題を1枚の課題記述書にまとめ、成功基準と撤退基準を開始前に合意することが鍵です。

成果物を「課題記述書」と「PoCスコープ」に落とし込む

ワークショップの成果は、課題記述書とPoCスコープの2つの文書にまとめ、顧客の意思決定者の承認を得ます。

課題記述書には最低限、次の項目を入れます。

1. 対象業務と担当者：どの部署の誰の、どの作業か
2. 現状：手順、所要時間（概算）、発生頻度
3. 課題：時間・品質・判断のどこに問題があるか
4. あるべき姿：解決したら誰の何が変わるか
5. 使えるデータ：所在、形式、アクセス権限の有無

PoCスコープでは「やること」と同じくらい「やらないこと」を明記します。範囲を絞らないと、PoCが途中で要件定義のやり直しに変わってしまうためです。

成功基準と撤退基準を先に決める

PoCを始める前に「何が確認できれば本番に進むか」「何が起きたら止めるか」を数値や条件で合意しておきます。

具体的な目標値は業務ごとに異なるため、ワークショップで聞き取った現状値をもとに顧客と決めます。根拠のない目標値を置くと、PoCの評価そのものが揉める原因になります。

導入を検討する企業側が準備しておくこと

FDEを受け入れる企業側は、現場担当者の時間確保、データへのアクセス権限、意思決定者の参加の3点を事前に整えておくと効果的です。

ワークショップの質は、FDE個人のスキルだけでは決まりません。現場担当者が業務を中断して参加できるか、サンプルデータを事前に提供できるか、その場で優先順位を決められる人がいるか。こうした受け入れ側の準備によって、短期間で成果が出るかどうかが大きく変わります。エンジニア個人がFDEを目指す場合も、この「顧客側の準備を引き出す段取り力」は、技術力と並んで評価される力だと考えられます。

出典・参考

• Palantir Technologies, Investor Relations（2023年以降の決算説明資料におけるAIP Bootcampへの言及）
• Palantir Technologies 公式サイト「AIP」製品ページ

姉妹メディアの関連記事