FDEの要件定義の進め方は？現場で決め切る5ステップと落とし穴

FDEの要件定義は通常の要件定義と何が違う？

FDEの要件定義は仕様書を作る作業ではなく、顧客の業務現場で動く仮説を作り、検証まで一気に進める点が違う。

Forward Deployed Engineer（FDE）は、Palantirが自社の導入モデルとともに広めた職種で、エンジニアが顧客の現場に入り込み、業務そのものを作り替えるところまで責任を持つ。だから要件定義も「顧客が言ったことを漏れなく書き取る」工程ではなく、「顧客がまだ言語化できていない判断のボトルネックを見つけて、動くもので示す」工程になる。

「仕様を固める」ではなく「業務の意思決定を変える」ことがゴール

FDEが最初に定義するのは機能一覧ではなく、誰のどの判断を、どれだけ速く正確にするかという成果の定義である。

従来型の要件定義では、まず業務フロー図を描き、画面一覧と機能一覧に落とし、承認を取る。FDEの場合はここが逆になりやすい。最初に問うのは「この業務で、誰が、いつ、何を根拠に決めているか」であり、その判断が遅い・外れる・属人化しているポイントを特定できた時点で、要件の骨格はほぼ決まる。

実務の感覚として言えば、機能要望のリストは長くなるほど価値が薄まる。逆に「毎朝8時の配車判断を、経験10年の担当者以外でも同じ精度で下せるようにする」といった一文が置ければ、その後の設計判断はほとんど自動的に決まっていく。

納品物はドキュメントではなく、動くワークフローとオントロジー

要件定義の成果物は分厚い仕様書ではなく、実データで動く試作と、合意された運用ルールの二つになる。

FDEの現場では、要件定義フェーズの終わりに「読んで承認する資料」ではなく「触って承認する画面」が置かれることが多い。文章で合意した要件は解釈がずれるが、実データが流れている画面の前では、ずれがその場で露見する。

この表の右列は、いわゆるプロダクトマネジメントに近い。ただしFDEはPdMと違い、自分でデータパイプラインを書き、権限設計まで踏み込む。要件定義とプロトタイピングが分離していないことが最大の構造的差分だと考えてよい。

FDEの要件定義の進め方は？基本ステップはどう組む？

FDEの要件定義は、現場観察・判断の特定・データ実査・試作・運用移管の5ステップで組むと崩れにくい。

5ステップの全体像（現場観察から運用移管まで）

5ステップは順番が価値で、データ実査より先に試作を始めると後戻りが最も大きくなりやすい。

1. 現場観察：会議室ではなく業務が起きている場所に行き、実際の作業を横で見る。
2. 判断の特定：観察から「意思決定の瞬間」を抜き出し、頻度・所要時間・誤りのコストを整理する。
3. データ実査：その判断に必要な情報が、実際にどのシステムに、どの粒度・鮮度で存在するかを自分で開いて確認する。
4. 試作：判断を支える最小の画面またはワークフローを作り、現場担当者に触ってもらう。
5. 運用移管：誰が更新し、誰が壊れたときに直すのかを決め、責任の所在を文書化する。

期間はあくまで小規模案件での目安であり、対象部門の数やデータ連携の難易度で大きく変動する。重要なのは絶対値ではなく比率で、実務では「データ実査と試作に全体の6割以上」を置く配分が機能しやすい。

各ステップで「決め切る」ための時間の使い方

決め切るコツは会議で結論を出すことではなく、次の打合せまでに動く画面を持っていく運用にある。

FDEの要件定義が速いのは、判断のサイクルが短いからだ。週1回の定例で議論を積み上げるのではなく、同席した翌日に試作を見せ、その反応で要件を確定させていく。「持ち帰って検討します」を減らす設計そのものが、要件定義のプロセス設計になる。

一方で、短周期は万能ではない。データの権限申請やセキュリティ審査は顧客側の稟議に依存し、こちらの速度では動かない。そこで実務では、待ち時間が発生する作業（権限・アカウント・データ提供依頼）を初日に着手するのが定石になる。ここを後回しにすると、試作フェーズで丸ごと空転する。

顧客の業務課題はどうヒアリングして構造化する？

業務課題は「困りごと」を聞くのではなく、判断の瞬間・使う情報・判断後の行動の順で構造化する。

質問は「業務プロセス」ではなく「判断の瞬間」から入る

最初の質問は「昨日いちばん迷った判断は何でしたか」で、抽象的な課題ヒアリングより情報量が多い。

「課題は何ですか」と聞くと、返ってくるのは既に社内で言語化済みの一般論になりやすい。「人手が足りない」「データがバラバラ」といった答えは正しいが、そのままでは設計に落ちない。

代わりに、直近の具体的な一日を再現してもらう。「昨日の朝、最初に開いたシステムは何か」「その画面を見て何を決めたか」「決められなかったときは誰に聞いたか」。この粒度まで下ろすと、Excelの手作業や、電話での確認といった、フロー図には現れない実態が出てくる。FDEが現場に行く価値の大半はここにある。

議事録を構造化する3つの型（意思決定・データ・制約）

議事メモは意思決定・データ・制約の三列に割り振ると、そのままオントロジー設計の下書きになる。

• 意思決定：誰が、いつ、何を決めるか。頻度と、誤ったときの損失。
• データ：その判断に使っている情報。所在システム、更新頻度、信頼度。
• 制約：法令・社内規程・労使ルール・既存システムの契約など、動かせない条件。

制約列を最初から作っておくのが実務上のコツになる。制約は後から出てくると設計をひっくり返すが、初期に列挙しておけば「その制約下で最善は何か」という建設的な議論に変わる。特に個人情報の取り扱いと権限分離は、後出しされると試作をほぼ作り直すことになる。

要件をオントロジーとデータ設計にどう落とし込む？

要件は、オブジェクト・プロパティ・リンク・アクションの4要素に分解するとデータ設計へ直結する。

Palantirの製品思想における「オントロジー」は、業務上の概念（人・設備・注文・案件など）と、その関係、そして実行できる操作を、システム横断の共通モデルとして定義するものだ。FDEの要件定義は、最終的にこのモデルを描く作業に収束する。ここはPalantir公式ドキュメントで公開されている考え方に基づいており、同種のモデリングはPalantir製品を使わない場合でも有効に働く。

オブジェクト・プロパティ・リンク・アクションの4点で書き出す

業務用語をそのままオブジェクト名にし、動詞をアクションにすると、顧客と共通言語で会話できる。

ここで重要なのは、社内用語をむやみに正規化しないことだ。現場が「号機」と呼んでいるものを勝手に「設備マスタ」と言い換えると、レビューの場で認識がずれる。業務用語をそのまま使うほうが、結果として設計の合意速度は上がる。

データ品質の“実物確認”を要件定義の中に入れる

要件定義の期間内に実データを開き、欠損・重複・更新頻度を目視で確認しないと後段で必ず破綻する。

「そのデータはあります」という回答と、「使える状態である」ことは別物だ。実務では、日次更新と聞いていたテーブルが実際には週次だった、マスタに同一設備が表記ゆれで複数行あった、といった事象が普通に起きる。

確認すべき最低限は次の4点になる。

1. 鮮度：最終更新はいつか。バッチの実行時刻はいつか。
2. 欠損：判断に使うキー項目の欠損率はどのくらいか。
3. 一意性：業務上の同一物が、複数レコードに割れていないか。
4. 権限：本番で同じデータに、同じ粒度でアクセスできるか。

リアルタイム性の高いデータを扱うサービス、たとえばVACANのような混雑状況を扱う領域では、鮮度と欠損の扱いがそのままユーザー体験の質を決める。要件定義の段階で「データが遅延したときにUIは何を表示するか」まで決めておくと、後工程の手戻りが減る。

要件定義でつまずく典型パターンと回避策は？

つまずきの多くは要望の全部盛り、PoCの孤立、決裁者不在の三つで、初期の設計で回避できる。

「関係者全員の要望を集める」で沈む

関係者の要望を平等に集めると優先順位が消え、誰の判断も速くならない汎用ツールに着地する。

要望を集める行為自体は関係構築に効くが、集めた要望をそのまま要件にすると失敗する。実務では、集めた要望を「今回の対象判断に効くか」の一軸で仕分けし、効かないものは削除ではなく「次フェーズ候補」として可視化するのが穏当な進め方になる。削除ではなく保留にすることで、政治的な摩擦を避けつつ範囲を守れる。

「PoCが本番に繋がらない」で止まる

PoCの段階から本番データと権限設計に触れておかないと、成功しても本番移行で作り直しになる。

サンプルCSVで作った試作は速いが、本番のデータ量・更新頻度・アクセス制御に載せた瞬間に前提が崩れることがある。特に権限設計は後付けが難しく、「誰がどのオブジェクトのどの行を見られるか」を要件定義の段階でモデルに含めておく必要がある。

決裁者と運用主体が最後まで現れない

現場の合意だけで進めた案件は、予算と運用の担当が現れた段階で要件が大きく揺れる。

FDEは現場に密着するがゆえに、現場の声だけで要件が閉じてしまうリスクを抱える。ステップ2で対象判断を定義したタイミングで、決裁者に「この判断が速く正確になれば投資に値するか」を確認しておくと、後半の巻き戻しがかなり減る。あわせて、運用を引き取る部門を早期に特定しておくことが、ステップ5の成否を分ける。

参考（一次情報）：Forward Deployed Engineerという職種名と導入モデルはPalantir Technologiesが公開している職種紹介・技術ブログに基づく。オントロジー（オブジェクト／プロパティ／リンク／アクション）の構成はPalantir Foundryの公式ドキュメントで公開されている定義を参照した。本稿の進め方・期間の目安・落とし穴は、これら公開情報と一般的なエンタープライズ導入の実務知見を踏まえた整理であり、特定案件の実績値ではない。

姉妹メディアの関連記事