FDEは現場で何をする人材か

FDEは「Forward Deployed Engineer」の略です。顧客の現場で業務を理解し、課題の発見、解決策の企画、システム開発、運用定着を一続きで担います。依頼された機能を作る前に、どの業務に負担があり、何を変えるべきかを確かめる役割です。

たとえば、複数の部署で同じ情報を転記しているなら、単に入力画面を追加するだけでは負担が残ります。どこで情報が生まれ、誰が使い、どのシステムへ渡すかを調べたうえで、改善方法を比べる必要があります。これはFDEの役割を説明するための例であり、導入実績ではありません。

アンドドットでは、現場にいるFDEをSuccess PartnerとExpertが支える「FDU」という体制を採っています。Success Partnerは目的と優先順位をそろえ、Expertは専門的な判断が必要な場面で加わります。FDE一人に、課題発見から専門判断までを抱え込ませない設計です。

FDEによる改善はどう進むか

アンドドットの公式ページでは、改善を「課題の発見」「解決策の選定」「実装」「運用定着」の4段階で説明しています。各段階で確認することが違うため、成果を急いで機能開発だけを先行させないことが重要です。

1．現場の課題を特定する

まず、現場の担当者に業務の流れを聞き、実際の作業を確認します。「システムが使いにくい」という依頼でも、原因が入力項目なのか、承認の順番なのか、部署間の情報共有なのかで解決策は変わります。

この段階では、困りごとを作業単位で記録し、どの問題を先に解くかを関係者とそろえます。着手前の時間や件数も測っておくと、後で変化を確かめられます。

2．解決策を比べて決める

課題が分かったら、複数の方法を業務への効果、実装の難しさ、運用負荷で比べます。新しいシステムを作る以外に、既存の運用やシステム間の連携を変える方法も候補です。

何を採用し、何を今回は見送るかを明確にすると、期待する成果と作業範囲がずれにくくなります。アンドドットの体制では、Success Partnerが目的と優先順位を定期的にそろえます。

3．現場で使える形にして確かめる

決めた解決策を小さく形にし、実際の担当者が業務で使えるかを確かめます。画面や機能が動くだけでは完了とはいえません。入力の手間、例外処理、既存システムとのつながりまで確認します。

アンドドットの公式ページは、この段階を現場を巻き込んだ開発として説明しています。ここでの確認結果を次の改善へ戻すことで、作ったものと実務のずれを減らします。

4．運用を定着させる

担当者が使い続けられるよう、運用方法と改善の窓口を決めます。利用が止まった箇所や新たに見つかった負担は、次の改善候補として扱います。

導入事例を読む際にも、公開時点で機能が完成したかだけでなく、運用が続き、何が変わったかまで確認することが大切です。

公式LPの想定ユースケースから分かること

アンドドットの公式ページには7つの業務改善例があります。以下はそのうち3つを、導入時に確認したい点とともに整理したものです。いずれも想定イメージであり、実際の顧客案件や導入成果ではありません。

総務：システム間の転記を減らす

公式ページは、部門の転記業務を洗い出し、システム間の転記を自動化する例を示しています。自社で検討するなら、転記する情報の発生元、入力先、例外処理、承認者を確認します。削減時間は、着手前の作業件数と1件当たりの時間を測ってから判断します。

情報システム・総務：定型の問い合わせに答える

社内文書を参照して、定型の問い合わせへAIが回答する例です。対象となる質問、参照資料の更新方法、誤回答時に人へ引き継ぐ条件を決める必要があります。問い合わせ件数だけでなく、担当者が回答に使う時間も比較の候補です。

営業：情報を一つの基盤にまとめる

顧客情報、案件の進捗、議事録などをまとめる例もあります。既存システムのどの機能を残すか、移行する情報は何かを整理し、営業担当者が実際に使えるかを確かめます。既存SaaSの費用削減を見込む場合も、契約や移行費用を含む自社の条件で試算します。

ほかの4例と想定の数値は、常駐型FDEの公式ページで確認できます。実案件の事例を掲載するには、社名、成果、算出方法、公開許諾を別途確認します。

事例を読むときに確認する四つの問い

元の業務はどう進んでいたか

改善後の数字だけでは、同じ方法が自社に合うか分かりません。対象部署、担当者、月間の件数、例外処理、既存システムとの関係を確認します。最初の負担が異なれば、同じ仕組みでも効果は変わります。

FDEと顧客は何をそれぞれ決めたか

FDEが課題を見つけて提案した内容と、顧客が優先順位や運用変更を決めた内容を分けて読みます。アンドドットの社内資料が示すように、現場と推進側の目的がずれると、良い機能でも利用につながりません。どの段階で誰が合意したかが重要です。

実際に使われた期間と母数は何か

試作時の見込み値、導入直後の結果、継続利用での実測を分けます。作業時間の比較には、改善前後の同じ作業、実際に使った件数、測定期間が必要です。想定ユースケースの数字を実績として扱わず、算出条件の確認できる数字だけを採用します。

支援後に誰が改善を続けるか

導入時の成果があっても、問い合わせ、権限変更、例外対応の担当が決まっていなければ続きません。運用手順と改善を選ぶ責任者、FDEが離れた後の支援範囲を確認します。事例の価値は完成物だけでなく、次の改善を社内で選べる状態にあります。

導入効果は何を見て判断するか

FDEの成果は、開発した機能の数だけでは判断できません。対象業務と、着手前の状態を定め、その後に同じ数え方で変化を測る必要があります。

アンドドットの効果確認では、改善前後の1件あたり作業時間の差に、改善後の仕組みを実際に使った件数を掛けます。たとえば転記業務なら、未利用の処理まで削減対象へ含めず、確認や手戻りで増えた時間も別に記録します。開始前の基準値、対象者、利用開始後の期間をそろえて比較し、空いた時間をそのまま現金支出の削減とみなさないことも重要です。

また、削減時間が「実測」なのか「試算」なのかを区別してください。アンドドットの公式ページにある業種別の削減時間は、実案件の実績値ではなく想定イメージです。数字だけを自社への導入効果として受け取らず、前提条件と算出方法を確かめる必要があります。

導入前に確認したい3つの点

対象業務と判断者を決める

最初から全社の課題を一度に解こうとすると、何を優先するかが曖昧になります。対象業務、関係部署、判断を担う人を明確にし、最初の改善テーマを絞ります。

現場の協力と必要な情報を整理する

現場の業務を理解するには、担当者への聞き取りや、既存の手順・システムの確認が必要です。どの情報を誰が共有できるかを先に整理すると、着手後の待ち時間を減らせます。

成果の測り方を着手前に合意する

「効率が上がった」という感覚だけでは、改善の価値を判断しにくくなります。対象作業、測定期間、件数、作業時間などを、着手前と後で同じ定義にそろえます。成果が出なかった場合も、何が障害だったかを振り返れるようにします。

まとめ

FDEは、現場で課題を見つけ、解決策を選び、開発と運用定着まで進める役割です。導入事例を判断する際は、作ったシステムだけでなく、対象業務、導入前の状態、効果の測り方、運用後の変化まで確認しましょう。

事例を自社の判断に生かすには、導入の進め方だけでなく、費用と投資対効果をどう見るか、稟議で何を示すかも整理しておくと役立ちます。次の3点セットには、その検討に使える資料をまとめています。