FDEのドメイン知識の身につけ方｜5つの手順と習得度の確かめ方

FDEに必要なドメイン知識とは？

FDEに必要なドメイン知識とは、顧客の業務フロー・データ・意思決定の構造を、現場の言葉で説明できる理解のことです。

業界の教科書的な知識とは中身が違います。FDEは「業界に詳しい人」である必要はありません。求められるのは「この顧客のこの業務に詳しい人」になることです。コンサルタントは業界全体の動向を語ることが多い一方、FDEの成果は、プロダクトが現場で実際に使われるかどうかで測られます。そのため、知識の範囲は狭くても、深さと正確さが求められます。

なぜFDEにはドメイン知識が欠かせないのか

FDEは顧客の現場で課題の発見から実装、定着までを担うため、ドメイン知識が技術力と同じくらい成果を左右します。

Forward Deployed Engineer（FDE）は、Palantir Technologiesが広めたとされる職種です。Palantir社内では、FDEに近い役割が「Delta」と呼ばれ、プロダクト開発側の「Dev」と区別されてきました。このことは同社の公式ブログなどで紹介されています。顧客の隣で価値を出すFDEは、顧客の業務を理解していなければ、何を作り、何を優先すべきかを判断できません。本記事では、業界理解を短期間で深めるための考え方と5つの手順を、実務の視点から整理します。

業界知識より「業務とデータの対応関係」が核になる

FDEが最初に理解すべきなのは業界の一般論ではありません。どの業務がどのデータを生み、誰がそれをもとに何を判断するかという対応関係です。

たとえば製造業で「歩留まり」という言葉を知っていても、顧客の工場でどの工程の、どのシステムに、どの単位で記録されているかが分からなければ、データパイプラインは組めません。逆に、業界の歴史や市場規模を知らなくても、業務とデータの対応関係を押さえていれば、最初のプロトタイプは作れます。実務の感覚では、この「対応関係の地図」を早く描けたFDEほど、顧客との会話が速く、具体的になる傾向があります。

ドメイン知識は4つの層に分けて整理できる

ドメイン知識は、規制・業務プロセス・データ・組織の4層に分けると、学ぶ順番と情報源がはっきりします。

4層のうち、FDEが着任直後から手を付けやすいのは「業務プロセス」と「データ・システム」です。「規制・商習慣」と「意思決定・組織」は、時間をかけて現場と関係を築く中で見えてくることが多い領域です。まず手を付けやすい2層から始め、残りの2層は継続的に理解を深めていく、という順番を意識すると学習計画を立てやすくなります。

ドメイン知識はどう身につける？

ドメイン知識は、用語集づくり、業務観察、データ突合、仮説検証、言語化の5手順で、現場と行き来しながら身につけます。

座学だけで得た知識は、顧客との会話で使える形になりにくいものです。FDEの学び方の特徴は、学ぶことと手を動かすことを分けず、プロダクトを作りながら理解を深めていく点にあります。5つの手順を以下にまとめます。

手順1：用語集を初週につくる

最初の1週間でやるべきことは、顧客独自の用語を集め、定義と使われ方を一覧にした用語集をつくることです。

同じ「在庫」という言葉でも、部署によって「帳簿上の在庫」を指すのか「倉庫にある実在庫」を指すのかが違うことはよくあります。エリック・エヴァンスが『ドメイン駆動設計』で提唱した「ユビキタス言語」の考え方は、FDEの現場でもそのまま役に立ちます。用語集は自分用のメモで終わらせず、顧客と共有して誤りを指摘してもらうことが大切です。誤りを直してもらうやり取りそのものが、良い学習の機会になります。

手順2：現場の業務を観察する

業務マニュアルを読むより先に、担当者の隣で実際の作業を見る「シャドーイング」をする方が、理解は速く深まります。

マニュアルには「本来の流れ」しか書かれていないことが多く、現場で実際に時間を取られている例外処理や手作業の回避策は、観察しないと見えてきません。観察中は「なぜその順番なのか」「この作業がなかったら何が困るか」を聞くと、業務の目的が分かりやすくなります。

手順3：データと業務を突き合わせる

観察した業務が、どのテーブルのどの項目として記録されているかを、実データで一つずつ確かめます。

この手順は、エンジニア出身のFDEがいちばん力を発揮しやすいところです。項目の欠損や値の揺れ、更新タイミングのずれは、入力担当者の違いや締め処理のタイミングといった業務側の事情を反映していることがよくあります。データの「汚れ」は、業務を知るための手がかりとして読むのが実務的です。

手順4：小さな仮説をプロトタイプで検証する

理解が不完全なままでも、小さなダッシュボードやツールを作って現場に見せると、知識の抜けを素早く見つけられます。

「この画面で毎朝の判断ができそうですか」と見せると、現場からは「この数字は前日分では遅い」「この区分けは実態と違う」といった具体的な指摘が返ってきやすくなります。ヒアリングだけでは出てこない暗黙知を引き出せる点が、プロトタイプ検証の利点です。

手順5：学んだことを言語化して共有する

最後に、学んだドメイン知識をドキュメントにまとめ、チームや後から参加する人と共有できる状態にします。

FDEの仕事では、知識が個人の頭の中に溜まりがちです。言語化はチームのためだけでなく、自分の理解の穴を見つけるためにも役立ちます。説明しようとして言葉に詰まる箇所は、たいてい理解が浅い箇所です。

未経験の業界でも短期間で追いつける？

未経験の業界でも、対象業務に範囲を絞って学べば、顧客と最初の議論をするのに必要な理解は比較的短期間で得られます。

ただし、短期間で届くのは顧客と会話を始められる水準までです。現場のベテランと同じ判断ができる水準ではありません。この違いを自覚しておくことが、顧客の信頼を損なわないためにも大切です。

「全部知る」ではなく「対象業務の深さ」で勝負する

未経験者が追いつく近道は、業界全体を広く学ぶことではありません。担当する業務の一点を深く掘ることです。

業界の全体像は、業界団体の公開資料や入門書で大まかに押さえる程度で十分なことが多いです。残りの時間は、担当業務の観察とデータの確認に集中させます。実務の感覚としては、顧客の担当者に「その業務についてはこの人に聞けば分かる」と思ってもらえる領域を一つ早めに作れると、その後のヒアリングや合意形成が進めやすくなります。

前職の経験を転用できる領域を見極める

前職の業界が違っても、業務の構造が似ている領域があれば、それまでに得た知識の多くをそのまま使えます。

たとえばVACANのように、店舗や施設の現場から生まれるデータを扱う事業では、IoTやリアルタイムデータを扱った経験が、業界が違っても活かせる場面があると考えられます。転用できる部分とできない部分を最初に分けておくと、学習の優先順位をつけやすくなります。

未経験者がつまずきやすい3つの落とし穴

未経験者によくあるつまずきは、知ったかぶり、一般論への依存、一人の話し手への偏りの3つです。

ドメイン知識の習得度はどう確かめる？

習得度は、顧客の担当者に説明が通じるか、例外ケースを予測できるかといった、行動で確かめられる基準で測ります。

ドメイン知識の習得度は、資格試験のように点数では測れません。そのため、自分で判断できる基準と、顧客から返ってくる反応の両方を使って確かめるのが現実的です。

セルフチェックの5段階で現在地を把握する

自分の現在地は、「用語が分かる」から「顧客に提案できる」までの5段階で判断すると把握しやすくなります。

段階1〜3はプロジェクトの序盤に、段階4〜5は継続的に関わる中で到達していく水準です。段階を一つずつ上げていく意識を持つと、焦りすぎずに済みます。

顧客の反応を定期的に確かめる

自己評価だけに頼らず、顧客の担当者の反応を定期的に振り返ると、理解のずれに早く気づけます。

分かりやすいサインは、顧客から受ける質問の中身が変わることです。最初は「これは何ですか」という説明を求める質問が中心だったのが、「この場合はどう処理すべきですか」という相談に変わってくれば、ドメイン理解が信頼され始めた証拠と考えられます。週次の定例などで「認識が違っている点はありませんか」と明示的に聞く習慣も有効です。

ドメイン知識は顧客ごとに更新し続ける

FDEにとってドメイン知識は一度身につければ終わりではありません。顧客が変わるたびに更新し続ける資産です。

用語集、業務観察、データ突合、仮説検証、言語化の5つの手順は、担当する顧客や業界が変わっても同じ形で繰り返せます。手順を繰り返すうちに、特定の業界知識だけでなく、どの業界でも通用する「学び方そのもの」が身についていきます。