顧客にいちばん近い職種はどれか、と問われたら、プロダクトマネージャーの名前が先に挙がると思います。
ところが FDE（フォワードデプロイドエンジニア）の求人票を読むと、同じように「顧客のそばで問題を掴む」と書かれています。
どちらも顧客の声を拾う仕事なのに、拾った声の行き先がまるで違います。
声をロードマップに畳むのが PdM、声をその場で動くものに変えるのが FDE、という対比で整理できました。
PdMが持つのは「価値」と「事業として成り立つか」
プロダクトマネージャーの責任範囲は、製品づくりのリスク分担として語られることが多いです。
Marty Cagan は製品開発の risk を4つに分け、それぞれの持ち主を明示しています。
Silicon Valley Product Group「The Four Big Risks」
買ってもらえるかを問う価値、使いこなせるかを問うユーザビリティ、作れるかを問う実現可能性、商売として回るかを問う事業実現性の4つです。
このうち価値と事業実現性の2つを持つのがプロダクトマネージャーで、使いやすさはデザイナー、作れるかどうかはエンジニア側が引き受ける、という分け方になっています。
ここから、PdM の仕事は多くの顧客の声を集約して、製品に入れないものを決める側にあると分かります。
一社の要望をそのまま製品へ通してしまえば、他の顧客にとっての価値が薄まります。
「聞いた声を全部は実装しない」という判断が、職務の中心に置かれているわけですね。
FDEは一社の中で「動くところまで」を持つ
一方 FDE は、顧客の現場に入って、そこで動くものを自分で作ります。
Palantir の Forward Deployed Software Engineer は、技術的なディスカバリーから本番投入後の修正までを一人称で持つ役割として説明されてきました。
対比としてよく引かれるのが、一社のために多くの機能を作る FDE と、多くの顧客のために一つの機能を作る従来型エンジニアという構図です。
この役割そのものの成り立ちは、別記事で整理しました。
PdM が「作らない」を決める側だとすれば、FDE は目の前の一社に必要なものを、今週動く形にする側に立ちます。
要件が固まる前でも手を動かし、動かしたもので要件を確かめにいく進め方も、この役割の特徴でした。
同じ「顧客の声」でも置き場所が違う
両者の違いは、拾った声をどこへ置くかで考えると分かりやすいです。
PdM が置く先はロードマップで、声は集約されて優先順位という形に変わります。
FDE が置く先は目の前の環境で、声はその週のうちに実装やデータ連携へ変わります。
時間軸も違っていて、動く単位は片方が四半期、もう片方が日です。
そして FDE の側には、現場で分かったことを製品へ戻す経路が別途必要になります。
戻す経路がなければ、その学びは一社の中だけで消えてしまいます。
PdM は集約する人、FDE は個別解を作る人、そして両者をつなぐのが製品への還流という三角形で捉えると、役割の重なりが整理できました。
FDE の現場チームで、問題とデータの在り処を探るデプロイメント・ストラテジストとエンジニアがどう仕事を分けているかは、FDE チームの組み方を扱った記事で整理しました。
混ざりやすい場面と、線の引き方
現場では「FDE が要件も決めているなら、それは PdM では」と見える場面が出てきます。
線を引く目安は、製品に何を入れるかの決裁を持っているかどうかです。
顧客の中で優先順位を決めていても、製品本体のバックログを決める権限がなければ、それは FDE の仕事の範囲です。
逆に、一社の事情を製品の意思決定へ持ち込める立場なら、肩書きが何であれ PdM 側の責任を担っています。
兼務そのものは起こり得ますが、一社最適の要望が製品の方向を曲げる危険はついて回ります。
求人票を読むときも、この視点で見ると中身の判別がしやすくなりました。
「顧客の現場で作る」と書かれていれば FDE 寄り、「ロードマップとバックログの責任」と書かれていれば PdM 寄りです。
最後に
FDE とプロダクトマネージャーは、どちらも顧客の声から始まる職種でした。
違いは声の行き先で、PdM は集約して製品の優先順位へ、FDE は個別の現場で動くものへ変えていきます。
そして FDE の学びを製品へ戻す経路がないと、会社としては受託開発に近づいてしまいます。
私自身はどちらの役割も未経験なので、公開されている求人票と一次情報を読みながら輪郭をなぞっている段階です。
現場で得た知見を製品へ戻す仕組みは、FDE の仕事の進め方を整理した記事の後半で扱っています。
以上です。
コメントを残す