「AIで問い合わせ対応を楽にしたい。でも、何をどう作ればいいのか、社内では決めきれない」
そんなとき、詳しい人が自社の仕事を見て、必要な仕組みを作り、社員が使えるところまで一緒に進めてくれたら助かりますよね。
FDEやRDEは、こうした現場での実装を担う人材を説明する際に使われる言葉です。
ただ、名前を聞いただけでは、提案をしてくれるのか、実際に作ってくれるのか、その後の運用まで見るのかは分かりません。
この記事では、FDEやRDEの支援を頼むと何が進むのか、自社の社員には何が求められるのかを、経営者の視点で説明します。まずは、自社で支援が始まったときの様子から見ていきましょう。
支援を頼んだ後に進める仕事
問い合わせ担当者が、社内マニュアルや過去のメールを探して回答している会社を考えてみます。資料の置き場所がばらばらで、慣れた社員に聞かないと答えられない質問もあります。
目指すのは、AIが社内の情報を参照して回答案を作り、担当者が根拠を確認してから送れる状態です。
まず、担当者と一緒に仕事を見る
支援者は、問い合わせの受付から回答まで、社員が実際にどう動いているかを確かめます。
時間がかかっているのは、文章を書くところでしょうか。それとも、正しい資料を探したり、上司の確認を待ったりするところでしょうか。
ここが分かれば、作るべきものも変わります。資料探しに困っているなら、きれいな文章を作るだけのAIでは、負担が残ってしまいます。
社員には、よくある質問や、判断に迷った問い合わせを見せてもらいます。支援者はそれをもとに、最初に扱う質問、AIに任せる部分、人が判断する部分を具体化します。
この段階では、対象にする業務と今回どこまで改善するかについて、自社と支援者で合意します。「問い合わせを全部AI化する」といった大きすぎる目標を、試せる範囲まで絞ります。
必要な情報をつなぎ、使える仕組みを作る
次に、回答の根拠にするマニュアルや過去の回答を整理し、AIが参照できるように設定・開発を進めます。
たとえば、実装担当者は、質問を入力すると回答案と参照した資料が表示される画面を作ります。必要なら、普段使っている問い合わせ管理の仕組みとも接続します。
その際、古いマニュアルを使ってよいか、顧客ごとの契約情報を誰が見られるか、といった判断は自社側にも必要です。支援者が技術的な設定を引き受けても、会社としての判断まで任せきりにはできません。
ここでようやく、社員が実際に触って試せる仕組みができます。
社員が使い、困ったところを直す
試作品を担当者に使ってもらうと、想定していなかった問題が見つかるかもしれません。
「回答案は出るけれど、根拠の資料が古い」
「契約条件が違うお客さまにも、同じ回答を作ってしまう」
支援者は、こうした問題を社員と確認し、参照する情報や回答の作り方を直します。答えが分からない質問は、無理に回答せず、適切な担当者へ回せるように手順も整えます。
成果を見るときも、回答案が出る速さだけでは足りません。担当者が確認・修正する時間まで含めて、以前より仕事が進めやすくなったかを確かめます。
実際の問い合わせで試し、使いにくいところを直す。この繰り返しに誰が関わるのかが、依頼するときの大事な確認点です。
使い続けるための役割を決める
運用を始めた後も、マニュアルや契約条件は変わります。
資料の更新は社員が行うのか。AIの動きがおかしくなったら、誰に相談するのか。設定変更は自社でできるのか、外部に依頼するのか。日々の役割を決め、手順や変更内容を共有しておきます。
支援を受ける場面での役割は、たとえば次のように分けられます。
| 担当 | 問い合わせ対応の例で担うこと |
|---|---|
| 支援側の実装担当 | 業務の調査、仕組みの設計・設定・開発、不具合や使いにくさの修正 |
| 自社の現場担当 | 実際の質問や例外の説明、回答の正しさの判断、試して分かった問題の共有 |
| 自社の責任者 | 対象業務と優先順位の決定、情報利用や手順変更の承認、担当者の時間の確保 |
一人がすべての専門知識を持つ必要はありません。支援側も必要な専門家と組み、自社側も小さな会社なら同じ人が複数の役割を兼ねます。作業を進める担当者と、必要な判断をする責任者が分かっていることが大切です。
助言・研修・開発との違い
では、従来のコンサルや開発会社へ依頼する場合と、何が違うのでしょうか。
同じ「問い合わせ対応をAI化したい」という相談でも、依頼する範囲によって、進むところが変わります。
| 依頼する範囲 | 進めることの例 | 自社が担うこと |
|---|---|---|
| 方針や助言まで | 対象業務やツール、導入の進め方を整理する | 実装する人を決め、設定や開発を進める |
| 社員への研修 | AIで回答案を作る操作や、確認の仕方を練習する | 日々の仕事に取り入れ、必要な手順を整える |
| 仕様を決めたうえでの開発 | 決めた機能を作り、仕様どおり動くか確認する | 現場で評価し、追加の変更を判断する |
| 課題の整理から実装・試行まで | 現場を見て作るものを決め、社員と試しながら修正する | 業務の情報、評価する時間、必要な判断を出す |
FDE・RDEの支援を検討するときに確かめたいのは、課題の整理から実装・試行まで、何を作るかが固まっていない段階から、実際に使う段階まで関われるかです。
コンサルティング会社や開発会社が、この範囲まで引き受けることもあります。呼び名だけで違いが決まるわけではありません。
一方、自社ですでに仕様を決められるなら、必要な開発を依頼する形が合うこともあります。社員が使い方を学べば進む状況なら、研修から始められます。自社が止まっているところを説明して、必要な仕事を頼むのが出発点です。
Palantirとアクセンチュアが示す考え方
ここまでの支援の流れを踏まえると、FDE・RDEの元の考え方も理解しやすくなります。
FDE：顧客の現場で製品を役立てる
FDEは「Forward Deployed Engineer」の略です。Palantirでは「Forward Deployed Software Engineer」と呼んでいます。同社では、顧客の重要な課題に合わせて自社のソフトウェアを導入・調整し、顧客の目標達成に貢献する役割と説明しています。生成AIブーム以前からある職種です。
原型にあるのは、既存の製品を、顧客の業務で役立つ形にする仕事です。毎回、独自のシステムをゼロから作ることだけを指すわけではありません。
さらに、現場で見つかった不足や改善点を、中核製品のコードの改善にも反映するという特徴があります。
問い合わせ対応の例でいえば、ある会社で見つかった権限管理の問題を、その会社だけの対応で終えず、製品の共通機能の改善につなげるイメージです。現場での経験を、製品を良くするためにも使います。
依頼する側から見れば、困りごとが見つかったとき、個別の設定を変えるのか、製品側の改善が必要なのか、その判断や対応をつなげられる体制があるかを確かめたいところです。
RDE：業務の変え方と実装をつなぐ
RDEは「Reinvention Deployed Engineer」の略で、アクセンチュアが示す人材像です。同社は、経営課題の分析から、AIを使った仕組みの実装、現場での定着、成果までをつなぐ役割として説明しています。また、複数の職種に共通する将来の到達像としています。
問い合わせ業務でも、AIの画面を作るだけでは解決しない場面があります。回答を承認する人を変える、部門ごとに違う手順をそろえるなど、仕事の進め方の変更が必要になる場合です。
そうした業務の判断と、技術による実現をつないで進めると考えると、RDEの目指す働き方を捉えやすくなります。
FDEとRDEには、現場で実装を進める役割として重なる部分があります。どちらの名前を使っていても、自社の案件で誰が何を担うかを確認する必要があります。
支援内容を見極めるポイント
「現場に入り、AIの実装まで伴走します」
その説明を聞けば、社員と一緒に作り、試し、直すところまで期待するかもしれません。ところが、実際には定例会議で助言を受けるだけで、設定や開発をする人が決まっていなかったらどうでしょうか。計画ができても、使える仕組みは増えません。
こうした呼び名と役割のずれには、提供側の当事者からも疑問が出ています。営業技術職やコンサルタントを単にFDEへ呼び替える動きに対し、顧客の成果と、現場の学びを製品へ返す開発のあり方を重視する批判が示されています。
経営者にとって問題なのは、新しい名前を使うこと自体より、期待した仕事を誰も引き受けていないことです。ここまでの問い合わせ対応の例でも、次のようなずれを確認できます。
実装まで頼んだつもりが、提案で止まる
業務を整理し、方針を決める支援には価値があります。ただ、実装を頼みたいなら、設定・開発を担当する人まで確かめる必要があります。
提案に来た人と、実際に手を動かす人が別の場合もあるでしょう。「その人はいつから関わり、何を作るのか」まで聞けば、実装を含む支援なのかが分かりやすくなります。
デモはできても、社員が使えない
サンプルの質問に答えられても、顧客情報の扱いや閲覧権限が決まっていなければ、本番の問い合わせには使えません。
試作品を作る契約なら、そこまでが今回の成果です。日々の業務で使うところまで期待するなら、実データでの確認、利用の承認、間違った場合の対応を、誰が進めるかも合わせて決めておきます。
支援者が離れると、誰も直せない
支援者だけが設定や変更方法を知っている状態では、マニュアルを更新しただけでも、外部の返事を待つことになりかねません。
社員が変更できる部分と、専門家に任せる部分を分け、手順を共有しておきたいところです。外部に保守を任せ続ける方法もあります。FDEという名前だけで完全に内製化できると考えず、支援後に自社と外部がそれぞれ何を担うかを確認しましょう。
また、顧客に手順書を渡すことと、Palantirの原型にある製品の改善は、それぞれ別の仕事です。自社への引き継ぎに加え、製品側に直してほしい問題をどう伝えるかも確認します。
会議や作業時間だけで、成果を判断する
「毎週会議をした」「一定の時間を使った」ことは活動の記録です。問い合わせ対応なら、担当者の確認や修正も含めて、仕事の負担がどう変わったかを見たいところです。
支援時間と合わせて、何を確かめたら次の段階へ進むのか、改善が見られなければ何を見直すのかを決めておきます。
相談時に聞きたい7つの質問
支援会社の説明を、自社の一つの業務に当てはめてもらいましょう。
| 質問 | 問い合わせ対応の例で聞くこと |
|---|---|
| ① 誰が作りますか？ | 回答案の仕組みを設計・設定・開発する人と、その人が関わる範囲 |
| ② どこまで使えるようにしますか？ | 試作品までか、社員が実際の問い合わせに使うところまでか |
| ③ 自社は何を準備しますか？ | マニュアルや過去の回答、情報利用の承認、社員が試す時間 |
| ④ 成果はどう確かめますか？ | 回答の正しさと、確認・修正を含む作業時間をどう比べるか |
| ⑤ 導入後の変更は誰に頼みますか？ | 情報の更新、誤回答、不具合への対応と、追加費用が発生する範囲 |
| ⑥ 改善点はどう共有されますか？ | 自社に残る設定・運用資料と、製品側へ改善を伝える方法 |
| ⑦ 支援を終える条件は何ですか？ | 社員が担える状態、引き継ぐもの、継続して外部に任せる仕事 |
自社に必要な支援の選び方
ここまで読んで、「うちは、そこまで作り込む必要があるだろうか」と感じた方もいるかもしれません。
まずは既存のAIツールを社員が使えるようになりたい、という段階なら、業務に合わせた研修や設定支援から始める方法があります。社員が自分で回答案を作り、人が確認するだけで、目的に近づけるかもしれません。
一方、社内の情報や既存システムとの接続が必要で、何を作るかも一緒に決めてほしい。使い始めた後の問題にも、技術と業務の両面から対応してほしい。その場合は、課題の整理から実装・改善まで関われる体制を確かめる意味があります。
経営者が用意したいのは、対象業務を知る社員、試すための時間、情報利用や手順変更を決める人です。誰かが空いた時間に対応するつもりで始めると、支援者が作業を進めたくても、必要な判断が止まってしまいます。
最初の相談では、改善したい仕事を一つ選んで、こう伝えてみましょう。
「この仕事について、どこまで一緒に進めてもらえますか。うちの社員は何を担当し、支援が終わったときには何が使えるようになっていますか」
その答えが具体的なら、自社が求める支援と、提案された支援との違いを確かめられます。
ミチガエルへのご相談でも、社員の状況や現在の仕事をもとに、研修や活用支援のどこから取り組むかを整理します。何を外部に頼みたいかが、まだ固まっていなくても構いません。
参考・出典
この記事の執筆・監修
執筆
山下 敏樹IT企業勤務。Web制作会社で社内業務改善・DX推進に携わり、code4bizで学んだAIコーディングを活用してさまざまな業務を自動化。半年間の取り組みで、年間約2,500時間相当の業務削減を実現。その後、IT/AIコンサルタントへ転身。DX現場での経験をもとに、AI活用・業務改善・DX・システム開発に関する知識やノウハウを、読者の成果につながる形で発信しています。
生成AI業務整理DX
