受託開発の世界では、検収が通った日がひとつの区切りになります。
ところが FDE（Forward Deployed Engineer）の求人票を読むと、成果の物差しとして「本番で使われているか」という言葉が真っ先に出てくるのです。
私も FDE を学んでいる途中なので、公開されている求人票や解説をたどって、何をもって成果とみなすのかを3つの視点に分けて整理してみました。
納品したのに、それだけでは成果と呼ばれない働き方に、戸惑いを覚える人も多いのではないでしょうか？
「納品した」が成果の区切りにならない理由
FDE の成果を考えるときは、先に比べる相手を置いておくと見通しがよくなります。
プロダクト開発の考え方を発信している SVPG（Silicon Valley Product Group）のマーティ・ケーガン氏は、記事「Forward Deployed Engineers」で受託型の代表として Accenture の進め方を取り上げました。
顧客が仕様を出し、価格に合意し、頼まれたものを作るという流れです。
この形では解決策が顧客に指定されているため、成果（アウトカム）までは約束できない、というのが同記事の指摘でした。
対照的に Palantir は、顧客の課題を解けることに賭けてアウトカムを引き受ける側に回ったと説明されています。
Palantir 自身も FDE にあたる職種の成功を「顧客のゴールへのインパクト」で測ると書いていて、その背景は別の記事にまとめました。
つまり仕様どおりに作ったかではなく、顧客の状況が変わったかで評価されるのが、FDE の前提です。
求人票に書かれた3つの物差し
成果の中身をもっとも具体的に書いているのは、OpenAI の求人票でした。
東京拠点の募集要項「Forward Deployed Engineer – Tokyo」には、成功を測るものとして3つが並んでいます。
本番環境での利用（production adoption）、測定できる業務への効果（measurable workflow impact）、製品やモデルのロードマップを変える評価ベースのフィードバックの3つです。
私はこれを、現場・顧客の業務・自社の製品という3つの視点に対応させると読みやすいと感じました。
- 現場の視点：作ったものが本番で使われ続けているか
- 顧客の視点：業務の数字が動いたか
- 製品の視点：現場の学びが製品と次の案件に還ったか
Anthropic の募集要項「Forward Deployed Engineer」も、同じ方向を向いています。
役割の説明は、顧客の中に直接入り込んで AI の導入（adoption）を進めることから始まり、納める成果物も「本番のワークフローで使われるもの」と書かれていました。
さらに、繰り返し使える導入パターンを言語化し、学びを製品・エンジニアリングチームへ還すことも責務に含まれます。
作って渡した瞬間ではなく、使われ、効き、還った時点で成果が確定するという設計なのですね。
「定着」を数字にするときの考え方
3つのうち、いちばん数字にしにくいのが「使われ続けているか」かもしれません。
ここで参考になるのが、Google の研究者が CHI 2010 で発表した論文「Measuring the User Experience on a Large Scale」の HEART フレームワークです。
HEART は Happiness（満足）、Engagement（関与）、Adoption（導入）、Retention（継続）、Task success（タスク達成）の頭文字です。
このうち Adoption は一定期間に新しく使い始めた人の数、Retention はある期間の利用者のうち後の期間にも残っている人の数として説明されています。
面白いのは、何をもって「使った」とみなすかは製品ごとに決めてよく、重要なタスクを完了した人だけを導入済みと数える方法も挙げられていたところです。
FDE の現場に当てはめるなら、ログイン数ではなく「対象の業務が新しい仕組みで最後まで回った件数」を数える、と整理できそうです。
同じ論文は、ページビューの増加が本当に人気なのか、分かりにくい画面で迷っているだけなのか区別できないという例も挙げていました。
利用回数が増えたという数字だけでは、定着の証拠になりません。
論文が勧めているのは、目標（Goals）を先に言葉にし、達成が表れる行動（Signals）を考え、最後に指標（Metrics）へ落とす順番でした。
測り方を間違えると起きること
物差しの選び方は、FDE の振る舞いそのものを変えてしまいます。
a16z のジョー・シュミット氏は論考「Trading Margin for Moat」で、導入担当に営業ノルマを持たせると逆効果の振る舞いにつながりうると指摘しました。
代わりに、サービスを原価で提供できる報酬設計にし、契約規模が大きくなるほど「重要なのは成功（と継続）だけ」になると続けています。
もうひとつの落とし穴は、FDE がいないと回らない状態を「定着」と取り違えることです。
Palantir のブログ記事「Dev versus Delta」では、現役の FDE が、顧客が自分たちで改善し続けられる長期的な仕組みを作る点を、コンサルタントとの違いに挙げていました。
先ほどの a16z の論考が、将来パートナーへ引き継ぐ前提ですべてを文書化しておくよう勧めているのも、担当者が抜けても回る状態を重んじる考え方でしょう。
3つ目は、一社ごとの成果だけを見て、製品への還元を数えないことです。
SVPG の記事は Palantir の強さを、FDE の学びを抽象化し、次の顧客で同種の作業を大幅に速くする製品機能に変えるところに見ていました。
一社で作り込んだものが、次の顧客の初期値になったかも、れっきとした成果のひとつです。
製品へ還す流れそのものは、FDE の進め方を扱った記事で詳しく整理しました。
最後に
FDE の成果は、現場で使われ続けているか・顧客の業務の数字が動いたか・学びが製品と次の案件に還ったかの3つで見ると整理できます。
どれも納品の時点では測れず、時間をおいて確かめるしかない指標ばかりです。
数える単位を「作った機能」から「回った業務」に置き換えるところが、受託開発の感覚からいちばん遠い部分なのかもしれません。
FDE を目指すなら、自分の仕事を定着の言葉で説明する練習から始めたいと感じています。
以上です。
コメントを残す