【FDEの4類型】あなたはどのFDEを目指す？──技術で何を動かすか。4つの難しさが、4つのキャリアを創る

FDEの現場の動きを整理するため、この記事では2本の軸を置く。

念のため先に断っておくと、切り方は無数にある。この2軸が唯一の正解だと主張するつもりはない。ここで示したいのは、この2軸を補助線として置くと、FDEの現場に現れる意味のある差分を説明できるということだ。

1本目の軸：誰の行動を変えようとしているのか

一方には、クライアント企業の従業員／組織がいる。営業担当者、経理担当者、専門職、管理職などが、情報を集め、判断し、業務を実行する方法を変える。

もう一方には、クライアント企業のユーザー（消費者）がいる。商品を探す、比較する、購入する、問い合わせる、手続きを行うといった体験を変えていく。

この軸は、FDEの担う役割が、BtoBになるのかBtoBtoCになるのか、とも表現できる。

ここで注意したいのは、取引先の企業と向き合う営業担当者は「左側」に入るということだ。BtoBビジネスにおける「顧客」は企業だが、その企業と向き合っているのはクライアント企業の従業員である。だから左側になる。

右側が生まれるのは、クライアント企業がその先に消費者を持つとき、つまりFDEがBtoBtoCの構造を担うときだ。

2本目の軸：どちらの利益へ働きかけるのか

企業活動が生む利益は、売上とコストで決まる。だから軸は、売上増加とコスト削減に置く。

コスト削減側では、すでに存在する仕事を、人と同等かそれ以上の品質でAIが担う状態をつくる。申請を処理する、問い合わせに答える、必要な情報を確認する。人が担ってきた仕事を、人の手をできるだけ介さずに完了できるようにする。成果は、処理時間や対応工数の削減として表れる。

売上増加側では、まず、まだ起きていない行動を生み出す。AIを手段として用い、従業員が以前より良い判断をしたり、エンドユーザーが新たな商品と出会いやすくしたりする。だが、それだけでは足りない。その先で、取引先による発注やエンドユーザーによる購入が起き、新たな売上が生まれることで、期待される成果となる。

なお、実際の効果が一方だけに現れるとは限らない。問い合わせ対応を効率化すれば、工数を減らすと同時に、満足度や継続率の向上につながることもある。ただし本記事では、最も重視する目標がどちらにあるかを基準に整理する。波及効果まですべて包含しようとすると、価値の差分がぼやけてしまうためだ。

4つの型

この2軸を掛け合わせ、FastGrow編集部のリサーチと考察から、4つの型として整理した。

取材内容等を基にFastGrowにて作成

下段の2つに「AI」が入り、上段の2つに入っていないのは意図的である。

AI労働力型とAIオペレーター型では、人が担ってきた仕事をAIが引き受けること自体が価値になる。クライアント企業の内側で実務を担うのか、消費者との接点で応対を担うのかによって分かれる。

フロント変革型と顧客体験変革型では、AIは成果を生むための手段だ。現場担当者を通じて売上を伸ばすのか、消費者の体験を直接変えて売上を伸ばすのか。その違いを名称へ反映している。

4象限は、難易度や市場価値の序列を示すものではない。どこに正解があり、何を成果とし、どのように仕事を前へ進めるのかが異なる。それぞれの構造が、別々の難しさと、特有の面白さを定義する。

では、2つの軸を置くことで、具体的に何がわかってくるのか。

先に結論を示す。

FDEの動きを4象限で見たとき、象限によって大きく変わるものが3つある。

担当できる社数が1社なのか8社にのぼるのか。案件が3カ月で終わるのか、終わりを定めないのか。そしてエンジニアとして、何が自分に残るのか。

同じFDEという職種名でありながら、ここまで違う。なおこれらの数値は、構造から導き出せる傾向に合致しつつ、各象限で実際に働くFDEへの取材でも確認できたものだ。

ではなぜ、こう分かれるのか。ここからは「3つの違い」を1つずつ取り上げ、2つの軸から導いていく。どの場合も、見るのは縦軸が何を決めるかと横軸が何を決めるかの2つだけである。

1つ目の違い．1社に注ぐ時間の量は、なぜ分かれるのか（担当社数の差）

◆ 縦軸が決めること：今あるものを「削る」のか、まだないものを「つくる」のか

コスト削減は「今あるものを測って削る」仕事だ。だから、現状のやり方と、それに何時間かかっているのかを精密に把握しないと、そもそも成果を定義できない。削減率は、削減前の実務を具体的に知っている者にしか計算できない数字である。

売上増加は「まだないものをつくる」仕事だ。現状の把握が不要なのではないが、現状をいくら精密に測っても、そこに答えが書かれていない。見るべきものは、過去の数字ではなく、これから起こしたい変化の側にある。

つまりコスト削減側は現状を測ることから始まる仕事であり、売上増加側はまだない未来を描くことから始まる仕事だ。

◆ 横軸が決めること：その「今」は、人から聞き出すのか、データから取り出すのか

従業員の業務は、多くの場合どこにも書かれていない。担当者の頭の中にあり、聞き出すしかない。しかもこれは、時間を短縮できない作業だ。何人もの担当者に順番に話を聞き、実務の動きをその目で確認し、食い違いを確かめ、言葉になっていない判断を引き出す。人を増やしても、そのぶん速くなるとは限らない。

消費者の行動は、データとして既に存在する。取得は非同期でも並列でもできる。その代わり、なぜそう動いたのかという理由は、どこにも書かれていない。大量に手に入るのは行動そのものだけであり、理由は自分で読み解くことになる。

つまり従業員側の「今」は人から聞き出すもの、消費者側の「今」はデータから取り出すものである。

◆ 掛け合わせから導かれる違い：FDE1人あたりの1社に注ぐ時間の量

深く知る必要があり、しかもその情報が人の頭の中にしかないなら、1社に膨大な時間を注ぐしかない。逆にその必要が薄く、しかもデータで見えるなら、1社にかける時間は短く済む。

取材内容等を基にFastGrowにて作成

左下が最も少なく、右上が明らかに多い。そしてこの時間の量は、現場に身を置く長さとしても表れる。左下では、知るべき「今」が従業員の頭の中にも多く隠れているため、会って、見て、聞き出すしかない。数カ月から数年単位で現場に常駐する例があるのはそのためだ。右上では、その必要が薄く、しかもデータとして手元に届く。訪問規定を置かず、フルリモートのメンバーがいる企業もある。

担当できる社数と、常駐の必要度合いは、別々の話ではない。どちらも「1社に注ぐ時間の量」という同じものの、2つの表れ方である。

そしてこの違いが、1社に深く潜る面白さと、複数社を横断して見る面白さに分かれる。

2つ目の違い．1つの案件の伴走期間は、なぜ分かれるのか

◆ 縦軸が決めること：成果に天井があるのか、青天井か

コスト削減には天井がある。人がやっている業務をAIが完全に引き受けたとして、削減率100%。それ以上の数字は原理的に出ない。その代わり、目指すべき地点が最初から見えている。いま払っているコストが、そのまま目標の最大値になる。

売上増加には天井がない。成果の大きさは、打ち手の側で決まる。その代わり、どこまで行けば十分なのかを、誰も教えてくれない。目標は自分たちで置くしかない。

つまりコスト削減の上限値は過去の数字から逆算できるもの、売上増加の値は自分たちでつくり出すしかないものである。

◆ 横軸が決めること：相手が一様なのか、多様なのか

従業員の数は、数人から数千人だ。そして重要なのは、役割や手順が決まっているので、担当者ごとの違いも大きくは出ないということ。だから一度その業務を最適化すれば、しばらくはその状態が保たれる。「この業務がこうなれば完了」という到達点を、あらかじめ定義できる。その代わり、定義した範囲の外へは広がらない。次を求めるなら、別の業務の案件へ移ることになる。

一方で消費者は、数万人から数千万人になる。そして2つの意味で、その属性や心理は多様だ。

1つは、一人ひとり置かれている状況が違うということ。契約の状態も、これまでの利用履歴も、いま何を求めているかも、人によって違う。だから問いが同じでも、最適な答えが人によって変わる。

もう1つは、その顔ぶれ自体が常に入れ替わっていくということ。去年の購入者・来店者が今年も来るとは限らない。加えて一人ひとりの心情も、競合の状況も動き続ける。だから同じ問いに、何度でも戻ってくることになる。

つまり従業員側の相手はそろって同じ方向を向いているもの、消費者側の相手は一人ひとり違い、しかも入れ替わり続けるものである。前者は一度解けば落ち着き、後者は解いても解いても次が来る。

◆ 掛け合わせから導かれる違い：1つの案件の伴走期間

天井があれば、1つの案件はおのずと成果に到達して終わる。そして相手が一様なら、一度その状態をつくれば、しばらく保たれる。次を求めるなら、別の対象へ移ることになる。

取材内容等を基にFastGrowにて作成

4つのセルのうち、天井がなく、しかも相手が多様なのは右上だけだ。だから右上だけが、案件の期間をあらかじめ定めない。「終わりのない伴走」がこの象限に固有なのは、感覚ではなく構造の帰結だ。

そして下段では、終わることそのものが正しい。人手を減らすために入ったのに、こちらの人手が張り付き続けているなら、それは目標を達成できていないということだ。案件が延びるのは、成功ではなく未達のサインである。

なお、ここで扱っているのは1つの案件の長さであって、クライアント企業との付き合いの長さではない。左下の企業が同じクライアント企業に数年関わっている例はあるが、それは1つの案件が数年続いているのではない。1つの業務を解き終えて次の業務へ移っているから、関係が続いている。この2つを分けて見ないと、この象限の時間の使い方は理解できない。

そしてこの違いが、やり切る面白さと、走り続ける面白さに分かれる。

3つ目の違い．磨かれる力は、なぜ分かれるのか

◆ 縦軸が決めること：ニーズが顕在化しているのか、潜在しているのか

コスト削減では、ニーズがすでに顕在化している。問い合わせをした消費者は解決したいし、経理の担当者もその手間をなくしたい。相手はもう困っていて、それを自覚している。だから正解は現場のどこかに実在していて、見つけ出せば手に入る。

売上増加では、ニーズが顕在化していない。「買わなくていい」を「買いたい」へスイッチさせなければ、成果は出ない。そして潜在ニーズは、いくら観察しても表に出てこない。相手自身も、まだそれを欲しいと気づいていないからだ。だから正解は、こちらが仮説として持ち込むしかない。

つまりコスト削減は顕在ニーズを解消する仕事、売上増加は潜在ニーズを掘り起こす仕事である。

◆ 横軸が決めること：検証を大きく深く回すのか、小さく速く回すのか

従業員を相手にする側は、対象となる一人ひとりが同じメンバーの状態が続くため、定性的な振り返りをじっくり聞き続けることで、より深いインサイトを得て、良い検証を進めることができる。見えた数字だけに囚われることなく、使っている人たちに話を聞き、現場を見て、管理職の関わり方まで確かめる。その結果として1周に時間はかかるが、回し終えたときには「なぜそうなったのか」まで手元に残る。

消費者を相手にする側は、そもそも対象の母数が桁違いに多い。大量のデータで、小さく速く回せる。出して、数字を見て、次を出す。何が起きたかは正確にわかる。だが消費者本人も、なぜそれを選んだのかを正確には答えられない。なので、理由は自分で読み解くことになる。

つまり従業員側は大きく回して、深く理解していく検証。消費者側は、小さく速く回して、広く把握しに行く検証。回せる数と、1周で手に入る情報の濃さが、ちょうど裏返しになっている。

◆ 掛け合わせから導かれる違い：エンジニアとして磨かれる力

ここが、この記事でいちばん伝えたい部分だ。

そしてここは、これまでの2つとは表れ方が違う。この2つが組み合わさると、エンジニアとして磨かれる力が、4象限それぞれで異なる方向へ伸びる。

取材内容等を基にFastGrowにて作成

誤解のないように書いておくと、これは難しさの大小ではない。難しさの所在が違うということだ。そのため、FDEとして身につけられる力が異なってくる。その4つの力を1つずつ見ていく。

AI労働力型で磨かれるのは「業務の骨格を掘り当て、本質にたどり着く力」だ。請求書処理も契約審査も、表面の手順はまるで違うのに、分解すれば似た骨格を持っている。その骨格を見抜く力は業界を超えて効くので、どの現場に立っても、最短距離で本質に手が届くようになる。

フロント変革型で磨かれるのは「技術で人と組織を動かす力」だ。検証は大きく回すことになるので、学びは数値だけでなく、現場で見聞きした事例と判断の蓄積として溜まっていく。だから場数を踏めば踏むほど、どの現場でどこから手をつければ人が動くかが読めるようになる。技術者でありながら、組織を動かせる人間になる道である。

AIオペレーター型で磨かれるのは「何が来ても、仕組みで受け止める力」だ。世界中からどんな入力が飛んできても倒れない構造を、どう設計するか。本番で起きた1つの想定外は、次からは想定内になる。予測不能なものを1つずつ制御下に置いていく仕事であり、壊れないシステムを任されるエンジニアになる道である。

顧客体験変革型で磨かれるのは「答えのない問いに、自分で答えを出す力」だ。人がなぜその商品を選ぶのかは、誰もわかっていない。だから曖昧な直感も含めて多くの仮説を構築し、本番環境で決着のつく実装に進め、外したり当てたりしながら正解をあぶり出していく。打席が異常に多いこの象限では、同じ1年でも10回試した人と100回試した人とでたどり着く場所が違う。経験年数ではなく、回した回数がそのまま実力になる。

どれも「強くなる」。だが、強くなる方向が違う。そして4つとも、他の象限にいては手に入らない強みになる。どの力を磨きにいくかを選ぶことが、そのままどのFDEを選ぶかということでもある。

なぜ2軸なのか

ここまでの整理は、この2軸が便宜的なものではないことを示している。

縦軸だけでは、コスト削減側であるAIオペレーター型が、常駐の必要性は小さい一方で、担当社数がAI労働力型よりも多いことを説明できない。消費者応対の「今」は、消費者との過去応対データが蓄積されていたり、トークスクリプトやFAQとして既に文書化されていたりするからだ。これは横軸から導かれる。

横軸だけでも不十分だ。どちらも従業員に働きかけるAI労働力型とフロント変革型の間に、案件の区切り方の差があることを説明できない。前者は3カ月から1年で終わり、後者は目標に届くまで続く。これは縦軸から導かれる。

この2軸の掛け合わせでこそ、FDEの実装現場における違いを説明できる。だからこの4象限を、理解の補助線として置く。

ここまでは、いわば"地図"である。地図だけを眺めても、その土地に立ったときに何が見えるかまではわからない。ここから1つずつ、順に歩いていく。

4象限のなかで、AI活用の入口として比較的理解しやすいのが、AI労働力型FDEだ。人がやっていた作業をAIが引き受けること自体が、提供価値になる象限である。

この象限の固有チャレンジは、人の仕事を代替するために、その人以上に企業の仕事を理解し、全体最適へ踏み込むことにある。

取材内容等を基にFastGrowにて作成

どのような現場に、何を実装するのか

文書を探す。複数の資料を読み比べる。申請内容を確認する。契約や規程と照合する。判断材料をつくる。人が時間をかけてきた処理をAIが担うことで、業務時間を短くし、既存の人員で扱える仕事の量を増やす。

一見、従来から続く業務効率化の延長に見える。しかし、実装対象となる仕事の性質は変わっている。

従来の自動化では、入力形式や処理手順をあらかじめ定めやすい業務が中心だった。現在は、形式の異なる文書を読み、複数の情報源を参照し、案件ごとに異なる状況を解釈しながら判断材料をつくる仕事まで、対象になり始めている。

だからFDEは、業務マニュアルを受け取ってそのまま自動化するのではない。担当者へ話を聞き、実際の資料と操作を見て、書かれていない判断や基準も見つけて拾っていく。どの情報を根拠にするのか。何を見落としてはいけないのか。どの条件ならAIへ任せ、どこで人へ戻すのか。AIの振る舞いと業務の流れを、同時に設計する。

この象限の構造

セクション2による整理からも、構造的な特徴を捉えやすい。「今どうなっているか」を深く知る必要があり、しかもそれが担当者の頭の中にしかない。そのため、4象限のうち、1社に注ぐ時間が最も長くなる。一方で成果には天井があり、対象者の属性は一様だ。だから1つの案件が長く続くことなく成果に到達して終わり、次の業務へ移る。

この構造は、各社の体制にも表れている。1社に専任のFDE/DSのペアを置く例、DSとFDE2人の計3人組が1社に約3カ月フルタイムで張り付く例、数カ月から数年単位の常駐を掲げる例。いずれも1社への投下量が突出している。ただし常駐が必須というわけではなく、「常駐はごく一部にとどまる」と明言する企業もある。長いのは物理的な滞在時間だけではない。1社に注ぐ思考の総量そのものが大きいのである。

国内では、LayerXが『Ai Workforce』で、ディグルが予実管理クラウド『Diggle』で、そしてログラスがLLM基盤チームを軸に、この象限で実装を進めている。いずれも、クライアント企業に深く入り込んで経理や法務、経営管理といったバックオフィスの業務フローを丹念に読み解きながら、人がやってきた実務をAIが担い切れる状態をつくっていく構造だ。

そして、この象限の時間の使い方には特徴がある。1つの案件は、短く深く終える。

1つの業務をAIへ任せきったら、そこで区切りが来る。そこで関係が終わることもあれば、経理から法務へ、情報検索から文書作成へと、同じクライアント企業の別の業務にて、新しい案件へと続いていくこともある。どちらになるかは、企業によって変わる。

だがどちらに転んでも、一つひとつの案件は深く短く区切られていく。それがこの象限の宿命である。深く潜ることと、長く居続けることは別なのだ。

難しさと、それゆえの面白さ

◆ 言葉になっていない判断を、実行できる構造へ変える

担当者に「どう判断していますか」と聞いても、多くの場合、そのまま自動化すれば良いと言える基準は返ってこない。本人にとって当たり前の前提が多く存在し、それらをAIに理解させる言語化の必要性を感じることがなかったからだ。しかも部署をまたげば、同じ業務の説明が食い違う。一見無駄な二重チェックが、過去の事故の再発防止策として不可欠になっていることもある。

だからこそ、FDEがその道の専門家として実情を聞き終えたときに手に入るものが大きい。部門をまたいだ業務の全体像が、FDEの手元にだけ組み上がる。担当者は自分の担当範囲しか知らない。管理職は現場の細部を知らない。数カ月潜ったFDEだけが、その業務全体に通底する前提や注意点を言語化できている状態になる。

これは他の3象限では構造的に難しい。他の3つは複数社を並行して担当することが多いため、1社への潜り込みの深さに時間の上限がかかりやすい。1社に数カ月フルタイムで居ることを許されるのは、この象限だけだ。

◆ 相手の仕事のやり方を書き換えながら、業界を超えて効く型を掘り当てる

この象限の実装は、誰かの手順を書き換えることでもある。良かれと思ってつくったものが、その人が長く続けてきたやり方を消していく。技術的に可能であることと、組織・個人が受け入れられることは同じではない。カルチャーを理解し、必要なら根回しをしながら、移行手順を探ることになる。

その手間をかけて実装した中で得た知見・経験が、次の案件やクライアント企業での実装において、共通プラットフォームとしてスタートを加速させる。請求書処理はどの業界でも請求書処理であり、承認フローの詰まり方にも共通の型がある。1社目で数カ月かけて見つけた型が、2社目ではその分だけ短い時間で立ち上がる。

この両立が起きるのは、この象限の構造が特殊だからだ。潜ることが必須でありながら、対象が業界横断で同型である。消費者に働きかける象限では、そもそも潜る必要が薄い。深さと汎用性が両立するのは、ここだけだ。

◆ 成果に上限があるからこそ、つくりきって引き渡せる

どれだけうまくやっても、削減率100%が理論上の天井になる。成果は、増えた数字ではなく減らせた数字で表される。上へ伸ばしていく仕事ではなく、ゼロへ近づけていく仕事である。積み上げた先に青天井の数字が待っているという種類の高揚は、この象限にはなく、モチベーションを高く保ち続けるのが難しいと感じる人もいるかもしれない。

その代わり、到達できる。削減率が目標に達し、クライアント企業の担当者が自走できるようになる。そこで手を離し、次の業務へ移る。立てた目標に対して、やり切れる。始まりと終わりのあるひとまとまりの仕事を、キャリアのなかで何度も完遂できる。しかも、実装スピードをどんどん速めていくことができる。その積み重ねによって生み出せるインパクトが、右肩上がりに大きくなっていく。

また別の言い方をすれば、この象限では、案件を終わらせることが正しい。人手を減らすために入ったのに、自分がいなければ回らない状態が続いているなら、それは目標を達成できていない。最短で終わらせ切ることが、そのまま成果になる。引き際が早いほど、良い仕事をしたということだ。

成果に天井があるから到達でき、対象が数えきれる範囲だから次は別の業務になる。構造的に「完了」を持つのは、この象限だけである。

向かない人

1社に数カ月潜ることが苦痛な人。複数社を俯瞰して見たい人、多くの現場を渡り歩きたい人にとって、この密度は重い。

1つのクライアント企業と、ずっと同じ方向を向いて走り続けたい人。この象限の仕事は、終わることがあらかじめ運命づけられている。しかもうまくいくほど早く手を離すことになる。長く肩を組み続けたいという願いとは、構造的に相容れない。

そして、相手の仕事のやり方を変えることに、ためらいがある人。誰かの手順を書き換えることに正面から向き合う覚悟が要る。

AIオペレーター型FDEによって実装されるAIは、クライアント企業の外へ出て動く。ここもAIそのものが提供価値になる象限だ。

この象限の固有チャレンジは、何が来るか選べない要求に、企業を代表して応え切ることにある。

取材内容等を基にFastGrowにて作成

どのような現場に、何を実装するのか

契約内容を確かめたい。予約を変更したい。返金条件を知りたい。商品が届かない。消費者は、企業が用意した順序や言葉で問い合わせてくれるとは限らない。説明の途中で意図が変わり、複数の用件が混ざり、必要な情報が欠ける。

回答文を生成するだけなら、高度な検索やチャットボットで足りる場面もある。だが起こる問題の多くは、情報を伝えるだけでは解決しない。

返金条件を確認し、実際に返金処理を行う。「答える」と「解決する」の間には、企業のシステムを実際に動かすという段差がある。ここで実装されるAIは、単なる会話の画面ではない。消費者との対話を入口として、企業のサービス提供を実行するソフトウェアである。

だから成果は「何件答えたか」ではなく「何件解決したか」で測られる。解決率、自動完了率、人間への引き継ぎ率、一件あたりの対応時間、処理の正確性。

この象限の構造

セクション2の構造で見ると、この象限は、「何をつくるか」で迷わない位置にある。「今どうなっているか」を深く知る必要はある。消費者に応対しているオペレーターの仕事を理解しないと実装できない。しかし、その「今」は既に文書化されている。トークスクリプトもFAQも、応対フローも、多くの場合すでに存在する。

つまり、AIによる業務代替の要件定義を、データや資料からスピーディーに考えやすい。

理由は、この象限が向き合う現場の性質にある。コンタクトセンター、問い合わせ窓口、FAQ対応。いずれも、これまでも徹底的な仕組み化が志向されてきた現場だ。オペレーターの入れ替わりが激しいため、誰が入っても同じ品質で応対できるよう、フローもスクリプトも文書として整備されている。

だからそこへ入るFDEは、ゼロからフローを聞き出す必要がない。渡された文書を読み込めば、背景や狙い、課題などを効率的に把握して始められる。

そしてこれが、働き方にそのまま表れる。コスト削減系でありながら、現場への訪問は1～2カ月に1回程度にとどまる。担当社数は2〜5社。現場に張り付かずに、深いところまで手が届くのだ。

国内では、Gen-AXが自律型AIオペレーター『X-Ghost』を、RightTouchがAIコンタクトセンター基盤『QANT』を軸に、そしてHelpfeelがAIナレッジデータプラットフォームを軸に、この象限で実装を進めている。いずれも、クライアント企業ごとの業務プロセスと対話フローを読み解きながら、AIが消費者と直接やり取りする状態をつくり、届いた問い合わせを企業の顔として解決し切っていく構造だ。

もう1つの特徴は、ニーズが完全に顕在化していることだ。問い合わせを行うに至った消費者は、既に解決したいという思いを抱いている。そこで、何を望んでいるかを探る必要はない。何をつくれば良いか、最初から明確である。

明確でないのは、そのつくったものがどこまで通用するか、だけだ。母数は多いので検証は小さく速く回せる。出して、返ってきたものを見て、対応できる範囲を広げる。つくるべきものが明確だからこそ、あとは強度を上げていく作業に集中できる。何をつくるかで悩まず、どこまで耐えられるかに向き合える象限なのだ。

そしてこの象限では、自分の実装が、そのまま企業の顔として応答する。誤った案内をすれば、それはクライアント企業が言ったことになる。担当者を経由しないので、途中で誰かが止めてくれることもない。書いたものが、そのまま企業の言葉として外へ出ていく。これが、この象限の実装に固有の重さである。

難しさと、それゆえの面白さ

◆ 網羅が不可能な世界で、壊れないものをつくる

事前にどれだけテストデータを想定しても、常にそれを上回る事象が起きる。曖昧な表現、入力ミス、複数の要望、途中で変わる意図、ポリシー変更、接続先システムの障害。

本番初日、「あー、えっと、昨日の、いや違う、先週頼んだやつ」といった問い合わせが来る。説明している最中に「いや、それ違う、やっぱりこっちがいい」と割り込まれる。チャットであれば、要領を得ない長文が一度に投げ込まれることもある。

要は、消費者の自由な言葉による入力に対応することが必須の現場なのだ。マーケティング用語を使うとわかりやすくなる。同じ右側の象限でも、顧客体験変革型はプッシュ型で行動を促す形、このAIオペレーター側はプル型つまり問い合わせに対応する形だ。ちなみに、左側の象限で起きる問い合わせは従業員からのものになるため、相対的には対応しやすいものばかりになる。

だからこそ、設計対象が変わる。「想定できる入力」ではなく、「想定できないことが前提の入力」を扱うことになる。テストケースを網羅するのではなく、網羅が不可能な世界で壊れない構造をつくる。エンジニアリングの難所が、機能の実装から堅牢性の設計そのものへ移る。

何を、どんな形で言ってくるかわからない相手と正面から向き合う難しさとやりがいは、この象限だけの特徴である。

◆ ハルシネーションから逃げられないからこそ、設計で越える最前線に立てる

生成AIは確率的に言葉を選ぶ。だから間違える。この性質は、モデルが賢くなっても完全には消えない。そしてこの象限では、その1件の間違いがブランド毀損へ直結する。誤った案内、権限のない変更、不適切な返金。目先の売上がなくなるどころではない、取り返しのつかない損失になり得る。

だから、どこまでをAIに委ね、どこで人へ引き継ぎ、何を絶対にさせないのかを、構造として組み上げることになる。権限の設計、ガードレール、確認の挟み方、引き継ぎの条件……と、検討対象は多岐にわたり、複雑だ。

ではその中で、何が面白いのか。AI時代の最大の弱点を、設計で乗り越える最前線に立てることだ。モデルの性能が上がるのを待てば解決するという類いの課題ではない。だから、いまある性能のままでも長く実運用に耐えるものを組み上げる。ここで積み上がる知見は、AIを事業に載せようとするあらゆる場面で効く。

AIが企業の外へ出て、リスクの大きな現場で消費者と直接対話するから、この難しさが最も鋭い形で現れる。失敗のコストが最も非対称な象限である。

◆ 誰も気づかない設計だからこそ、技術だけが問われる

うまく設計するほど事故は起きず、誰もその設計に気づかない。つくった機能の数では測れない価値を扱うことになる。

その代わり、成果を決める要素の大半を技術が占める。AIが手続きを完了させれば成果になる。担当者が使ってくれるかどうかにも、誰かが買う気になるかどうかにも左右されない。責任の所在がはっきりしていて、技術で解けたのか解けていないのか、それだけが問われる。

自分の腕がそのまま成果になり、その成果が消費者の体験として返ってくる。4象限のなかで、技術ともっとも真っすぐ向き合える位置である。

向かない人

「できることを増やす」のが好きで、「やってはいけないこと」を決める仕事に意味を感じられない人。この象限では、つくらない判断のほうが重い場面が少なくない。

1件の事故が許されない緊張に、長く置かれたくない人。本番は24時間動いていて、想定外はこちらの都合に関係なく飛んでくる。夜間や早朝の待機が必要になる場面もある。

そして、自分の仕事が目に見えることを求める人。静かであることが成果という状態を、正しく誇れるかどうか。

ここからは上段に入る。AIが提供価値そのものではなく、人と体験を変えて売上をつくる象限である。

フロント変革型FDEが目指すのは、クライアント企業の売上増加だ。ただし直接働きかける相手は、その先にいる消費者ではなく、クライアント企業においてその先の顧客と向き合う従業員となる。

営業だけではない。マーケティング、カスタマーサクセス、そしてクライアント企業内のコンサルタント部隊まで含まれる。共通しているのは、その人たちが取引先や消費者と向き合い、売上をつくっているという点だ。

この象限の固有チャレンジは、担当者と取引先という2人の判断を越えて、技術から売上を生むことにある。どちらもこちらの手では動かせない。

取材内容等を基にFastGrowにて作成

どのような現場に、何を実装するのか

どの企業へ接触すべきか。誰が意思決定へ影響するのか。過去のやり取りから、どのような課題が見えるのか。次に何を確かめ、何を提案すべきか。

フロントに立つ従業員は、これらをCRMやSFAだけで判断しているわけではない。メール、会議記録、提案資料、取引先の公開情報、過去の事例、社内の人脈などを組み合わせながら、次の一手を決めている。

だがこの状態をロジカルに説明し切れる企業はほとんどない。多くは担当者一人ひとりの経験に依存している。

そこでFDEは、散在したデータを有機的につなぎ、AIが示唆や次の行動を提案できる状態をつくる。ただし、メール文面や提案資料の作成を速くするだけでは足りない。時間が短くなっても、接点の数が増えず、提案の質が変わらず、成果につながらなければ、業務効率化にとどまる。

この象限で問われるのは、AIによって変わった担当者の行動によって、新たな売上が生まれたかどうかである。

この象限の構造

セクション2の構造で見ると、この象限は独特な難しさを抱えている。「今どうなっているか」を知る必要は薄い。だから、業務を精密に把握し終える前に実装を進められる。

一方、ニーズは潜在している。担当者の行動と、その先の取引先の意思決定という、二重の心情を動かさなければ成果にならない。そして相手が従業員なので、検証は大きく回すことになる。数字だけでは判断できず、使っている人に話を聞き、現場を見て確かめる。1周に時間はかかるが、なぜそうなったのかまで手元に残る。

そして天井がないので伴走は続く。ただし相手は一様なので、一度その状態をつくれば、しばらく保たれる。どこかで区切りが生まれ、次の対象へ移っていく。

そしてこの象限には、担当社数の上限がある。同時に2社、多くて3社。理由は明快で、FDEが単なる導入支援ではなく、クライアント企業の事業目標そのものに入り込む役割だからだ。社数を増やせば関与が浅くなり、成果が出せなくなる。

期間の考え方も特徴的である。「何カ月」で区切るのではなく、設定した目標を達成するまで伴走する。結果として1年以上に及ぶこともある。

同じ左側でも、AI労働力型が「案件を長期化させない」ことを意識するのに対し、こちらは「完了の区切りを設けない」。縦軸の違いが、そのまま時間の設計の違いになって表れている。

国内では、Sansanが『Sansan AIエージェント』で、ナレッジワークが営業組織向けのAIエージェント構築ソリューションで、この象限に位置づく実装を進めている。いずれも、蓄積された接点データや企業データベースを読み解きながら、AIエージェントがフロントに立つ従業員の判断を支え、その人がより顧客への価値創出に集中できる状態をつくっていく構造だ。

難しさと、それゆえの面白さ

◆ 使われない壁を、人を動かして越える

技術的には完璧に動くものをつくった。しかし現場が使わない。理由は「そもそもそのツールを開く習慣がない」といった、技術と無関係なことだ。フロントに立つ人の多くは属人的な進め方を持っており、そこへ新しい動きを差し込むのは至難の業になる。

導線を変える。置き場所を変える。業務フローに組み込む。まず1人に成功体験をつくらせる。上長が使っている状態をつくる。そうした試行錯誤の先で、ふとログを見ると、利用率が跳ねている。そんな進行になる。

何が面白いのか。成果がゼロか100かを決めるのが、技術的完成度ではなく人の習慣であることだ。これはエンジニアが最も苦手とする種類の問題で、だからこそ乗り越えたときに「技術以外の武器を手に入れた」実感が残る。

その手応えは、数字だけではなく言葉で強く返ってくる。「これは助かる」「ここが使いにくい」。フィードバックが、統計ではなく人格を持って返ってくるのだ。

動かすべき心情が二重にあり、その1つ目が「担当者が使う気になるか」だから、これが起きる。消費者に働きかける象限では、相手が勝手に動く。AI労働力型も、業務プロセスそのものに組み込めば使われる。使った本人から、最も強い感情が乗った言葉で良し悪しが返ってくるのが、この象限の特徴だ。

◆ 言葉になっていない「勘」を、扱える形に翻訳する

成果を出す人の判断には、言葉になっていない知見が含まれる。表情や言葉の変化、過去の経緯、組織内の力学から、今は提案すべきではないと察することもある。それを単純なルールへ置き換えれば、かえって判断を損なう。

エンジニアが、クライアント企業における顧客との接点に立ち会い、担当者が「この相手の温度感が読めない」と言う瞬間を見る。その属人的な勘を、扱えるデータと判断ロジックへ翻訳する。

何が面白いのか。属人的で、本人にも説明できない判断を、扱える形に分解できることだ。観察し、条件とデータに落とし、再現できる形にする。技術者の仕事の対象が、システムから人の判断そのものへ広がっていく。

働きかける相手が「顧客と向き合う従業員」だから、対象の職能が対人職になる。AI労働力型が扱うバックオフィス業務は手続き的で、対人的な勘の翻訳という要素が薄い。消費者向けの象限では、そもそも職能の翻訳という問題が発生しない。

◆ 成果が自分に帰属しないからこそ、人の「できること」が増えるのを間近で見られる

売上が増えても、それが自分の実装のおかげだと言い切れる場面はほとんど来ない。担当者の力、管理職の支援、価格、競合、市況。複数の要因が重なる。手柄は、現場で動いた人のものになる。

その代わり、目の前の人の「できること」自体が増えていくのを、間近で見られる。

AI労働力型やAIオペレーター型では、AIが人の作業を引き受ける。人がやらなくなることが成果だ。しかしこの象限では、AIは人の判断を強くする。担当者が、以前より良い判断をできるようになることが成果である。

経験の浅い担当者でも、過去の成功例を踏まえて提案できる。情報収集に追われていた人が、相手を理解し、次の一手を考えることへ時間を使える。そして売上には天井がないので、「効率化して終わり」にならず、同じ現場に対して「もっと売れるように」を追い続けられる。

従業員に働きかけながら、売上という天井のない成果を追う。この組み合わせを持つのはこの象限だけであり、だからこの手応えもここにしかない。

向かない人

技術的完成度のみで評価されたい人。ここでは、完璧に動くものをつくっても、使われなければ成果はゼロになる。

成果が自分に帰属しないことに耐えられない人。数字で自分の貢献を示したい人には、この曖昧さは重い。

そして、人と向き合う時間の長さを負担に感じる人。実装よりも、話を聞き、様子を見に行き、説得する時間のほうが長くなることがある。それを準備ではなく仕事の本体だと思えるかどうかで、続くかどうかが決まる。

顧客体験変革型FDEが直接働きかけるのは、クライアント企業の商品やサービスを利用するユーザー（消費者）である。

この象限には、難しい前提がある。クライアント企業が長い時間をかけて築いてきた顧客との接点、それも売上が生まれるまさにその場所を、任せてもらわなければならないという点だ。

この象限の固有チャレンジは、正解も要望もない状態から、まだない需要を掘り当て、売上として実現させることにある。

取材内容等を基にFastGrowにて作成

どのような現場に、何を実装するのか

商品を見つける。違いを理解する。自分に合うものを選ぶ。購入を決める。関連する商品を追加する。再び購入する。FDEが中心的に見るのは、消費者のこうした一挙手一投足である。

たとえば、閲覧履歴や購買履歴から商品を推薦する。そのために最も重要なのは、当然消費者の行動データだ。しかしデータから一律の答えが常に見つかるわけでもない。何を「良い推薦」とするかは、商品数、利益率、ブランド戦略によって変わる。

この象限には、他の3つと決定的に違う点がある。正解を言葉にできる人が、どこにもいないということだ。仕様書の中にはない。クライアント企業の担当者も知らない。そして消費者自身も、自分が次に何を欲しくなるかをわかっていない。だから、つくって、出して、反応を見るしかない。

本番データを用いて施策を設計し、実際の環境へ展開し、A/Bテストによって効果を確認する。そして、そのために必要になった機能を、共通プラットフォームの能力として積み増していく。

この象限の構造

セクション2の構造で見ると、この象限は他の3つと対照的な位置にある。「今どうなっているか」を知る必要は薄く、必要な場面があっても、データとして手元ですぐに確認可能だ。そのため、1社に注ぐ時間が最も短い傾向がある。成果には天井がなく、しかも相手が一様でない。一人ひとり違い、その顔ぶれも入れ替わっていく。そしてニーズは潜在しているため正解が現場になく、試して反応を見るしかない。だが相手の数が多いぶんデータも大量に集まるので、答え合わせは回り続ける。

クライアント企業のオフィスに身を置く必要性が薄いことも、ここから来る。ただしそれは、責任が軽いという意味ではない。入り込む場所として重要なのが、オフィスではなく、クライアント企業が自ら運用してきた本番環境そのものだからである。

なお、1施策の検証には1カ月ほどかかるが、複数の施策を並行して走らせられる。左側は組織の合意形成が必要で並行できず、右下は事故リスクから慎重にならざるを得ない。単位時間あたりの検証回数が4象限で最も多いのは、この象限である。

国内では、InsightXがBtoC企業のECへのCX変革プラットフォーム『InsightX』で、プレイドが『KARTE』シリーズを軸に、この象限で実装を進めている。いずれも、消費者の行動や購買のデータを読み解きながら、レコメンドや検索などによるECサイトの最適化から、メールやアプリ、LINEを含めたあらゆる接点を、一人ひとりに最適な体験へ変えていく構造だ。

FDE1人が担当するのは4社から8社。出社規定を置かない企業もあり、フルリモートで働くメンバーもいる。それでも、扱っているのはクライアント企業の売上が日々生まれている本番環境である。

なお2社とも「一人ひとりに」という点を軸にしているが、これは偶然ではない。相手が一様でないなら、全員に同じものを出すという解が原理的にありえない。初めて訪れた人と何度も買っている人では、次に見せるべきものが違う。パーソナライズがこの象限の中心にあるのは必然なのだ。

難しさと、それゆえの面白さ

◆ 終わりが来ないからこそ、肩を組んだまま走り続けられる

到達点が動き続けるので、誰も「終わり」を教えてくれない。どこまでやったら次に進むのかを、自分で決められない人には苦しい構造である。

その代わり、目指す方向が最初から最後までずれない。

売上には天井がないので、「ここまで達成したので完了」という地点が存在しない。そしてクライアント企業の側にも、ここまで増えれば十分という上限がない。コスト削減であれば、削減しきった時点で役割は終わる。関係は薄まり、次の業務を探すことになる。だがここでは、成果が出れば出るほど、次にやるべきことが増えていく。

しかも終わらない理由は、同じ改善を繰り返しているからではない。そもそも最適な体験というものが、1つに定まらないからだ。

消費者は一人ひとり置かれている状況が違うので、全員に当たる正解が存在しない。そのうえ消費者の心理は変わり、競合も進化し、顔ぶれ自体も入れ替わっていく。去年の正解は、今年の正解ではない。たとえば数年単位の長期間伴走しているクライアント企業でも、去年勝った施策をそのまま進めるのではなく、さらに上を狙うことになる。

クライアント企業と肩を組んだまま、その先にいる消費者へ、いつまでも向き合っていける。1つのクライアント企業との関係が、年を追うごとに浅くなるのではなく深くなる。

天井がなく、しかも相手が一様でない。この条件が揃っている唯一の象限だから、これが成立する。

◆ 大半が外れる前提だからこそ、負けても資産になる

誰も答えを知らない問いに答えを出しにいくのだから当然だが、打った施策の大半は外れる。しかも答えが出るまで少なくとも1カ月はかかり、そこでようやく外したとわかる。負けを見続けながら、次の仮説を立て続けることになる。

その代わり、失敗のコストが構造的に抑えられている。新しい施策は、はじめからすべての消費者へ出すわけではない。一部に絞って出し、効果を見ながら広げていく。だから失敗しても、影響は試した側だけに閉じる。そして負けた施策も、何が効かなかったのかという学びとして残る。

このように、現場での実験装置を「安全に失敗する装置」にすることで、思い切った仮説を打てる。

これはAIオペレーター型と正反対である。同じ消費者向けでも、あちらは誤答1件がブランドに直結するので、「安全な失敗」を設計できない。消費者に向き合う2つの象限は、失敗の扱いにおいて対極にある。

◆ 1社への時間が短いからこそ、複数社を横断した実験知が溜まる

1社に深く潜れないことを、物足りなく感じる人もいるだろう。

その代わり、複数社を横断できる。A社で効いた切り口をB社で試す。複数社分の実験結果が1人の頭に蓄積され、「この属性にはこの切り口」という勘が育つ。

BtoCの事業会社1社の中で働く限り、構造上得られない横断的な実験知が自分に溜まる。その1社の中では、自社が抱える消費者の数と、自社で打てる実験数が上限になる。クライアント企業を跨ぐからこそ、数千万から数億人規模の消費者へ、インパクトが積み上がる。

1社に注ぐ時間が最も短いのは、この象限である。他の3象限は1社への投下量が大きく、複数社を跨いで同じ問いを試し続けること自体が構造的にできない。

向かない人

案件の区切りや達成感が欲しい人。終わらない改善に意味を感じられない人。1社に深く潜りたい人。

答えのない問いに、向き合い続けるのが苦手な人。ここでは、何が効くかを事前に知っている人が誰もいない。自分の見立てを持っては出し、数字に確かめてもらい、また立て直す。確信を持ってから動きたい人には、この不確かさが重くのしかかる。

そして、手応えを人の言葉で受け取りたい人。ここで返ってくるのは数字である。誰が喜び、どこで迷ったのかは、行動ログの向こう側にいて見えない。「これは助かる」と言ってもらえることを支えに走りたい人には、この静けさはつらい。

ここまで見てきた4つの象限は、扱う技術が違うから分かれているのではない。1社への入り込み方、案件の区切り方、そしてエンジニアとして磨かれる力が、違うのだ。そしてその違いは、誰の行動を変えるのかと、売上とコストのどちらを動かすのかという2つの軸から、すべて導き出せる。

ここから先は、優劣の話ではない。面白さが交換できない、という話である。

1社に数カ月潜り、その組織の誰よりもその業務に詳しくなりたいなら、AI労働力型だ。そのかわり、多くの現場を見ることは諦めることになる。

想定できない入力に耐える設計そのものを主題にしたいなら、AIオペレーター型だ。そのかわり、1件の事故も許されない緊張が、常につきまとう。

技術だけでは絶対に動かない人を、それでも動かして強くしたいなら、フロント変革型だ。そのかわり、成果が自分に帰属しにくいことは、構造上避けられない。

クライアント企業と同じ方向を向いたまま、際限なく走り続けたいなら、顧客体験変革型だ。そのかわり、たくさんの失敗に向き合わなければならない。

どの面白さも他では味わえない。そして、どれも他では味わえないぶん、他では手に入らないものを諦めることになる。

選ぶために必要なのは、FDEという職種の定義ではなく、自分がどの報酬に反応する人間なのか、これからどのような力を磨いていきたいのか、という自己認識である。

次の記事では、顧客体験変革型の現場に入る

次の記事で扱うのは、4象限の右上に位置する、顧客体験変革型FDEである。

理由は単純だ。この象限が、4つのなかで最も情報が出ていないからだ。

特に注目したい特徴が3点ある。需要を新しく生み出すこと、その差分を事業成果として確かめること、エンタープライズ企業において非常にセンシティブなユーザー接点に入り込むこと。この3点が重なる現場を詳しく知ることで、FDEというキャリアの難しさと面白みを、より深く理解できるようにしたい。

特に、売上が減る／増える、まさにその場所を任せてもらう必要があるため、そこに立てる企業はそう簡単に増えないだろう。だから実際にどう動いているのかが、ほとんど外へ出てこない。担当社数も、施策の打ち方も、外れたときの立て直し方も、まだ情報が少なく、今後も少ない可能性がある。

クライアント企業の事業仮説を、消費者の購買体験としてどう実装するのか。それを本番環境で動かし、売上によってどう検証するのか。外れた仮説から何を学び、それをどのように共通プラットフォームの次の能力へ変えるのか。そうした詳細を追っていく。

まだ誰も詳細に書いていない現場へ、入っていく。InsightXにおける顧客体験変革型FDEの実践から、その具体像を見ていきたい。