FDEの業務は「作る前」から「使われた後」まで続く
FDE（Forward Deployed Engineer）は、企業の現場に近いところで課題を捉え、解決策を決め、仕組みを実装し、運用に根づくまで関わる役割です。アンドドットの常駐型FDEの案内も、この一連の流れを説明しています。担当業務を開発作業だけで捉えると、着手前の判断や導入後の利用確認が抜け落ちます。
アンドドットが整理するDXの停滞点は、目的のずれ、課題の優先順位不足、解決策の選び違い、開発中の手戻り、成果の測定不足です。FDEは機能を作る前に、いまどこで止まっているかを現場の作業と判断の流れから確かめます。目的と問題を分けて共有できれば、必要な解決策を比べるところへ進めます。
課題発見で担う業務
依頼内容と実際の問題を分ける
「入力を自動化したい」という依頼があっても、実際の負担は入力前の情報収集や入力後の承認にあるかもしれません。FDEは対象業務の開始から終了までを追い、担当者、使う情報、例外処理、待ち時間を確かめます。現場の声を一つだけ採用せず、業務に関わる人ごとの見え方も照合します。
この段階の成果は、技術案ではなく、対象業務と問題の説明です。関係者が同じ業務を指し、「なぜ今変えるのか」を説明できる状態を目指します。
改善候補に優先順位を付ける
見つかった困りごとをすべて同時に扱うと、対象が広がり過ぎます。発生頻度、影響を受ける人、品質や時間への影響、変更の難しさを並べ、最初に試す範囲を絞ります。測れていない数字は推測として区別し、必要なら着手前に記録方法を決めます。
優先順位はFDEだけでは決められません。事業上の目的や現場への影響を、企業側の責任者とすり合わせる必要があります。
解決策の設計で担う業務
複数案を業務の使い方で比べる
解決策は新規開発とは限りません。手順の変更、既存システムの設定、情報の整理、小さなツールの追加などを候補にし、どれが問題に合うかを比べます。機能の多さだけでなく、利用者が続けられるか、誰が管理するか、どの情報を扱うかを確認します。
アンドドットの公開案内では、課題発見に続いて解決策を検討し、顧客との合意を置いています。実装前に「何を試すか」「何を作らないか」「うまくいったと判断する条件」を決めることが、期待のずれを早く見つける方法です。
担当と判断の境界を決める
FDEが設計を担っても、現場の業務判断やデータ利用の許可まで代わりに決められるわけではありません。業務責任者、利用者、情報管理担当、実装担当の役割を分けます。承認が必要な情報やシステムへの接続は、作業に入る前に確認します。
実装で担う業務
動くものを現場で確かめる
実装では、決めた課題と利用場面に合う最小の仕組みを作り、現場の手順に置いて試します。アンドドットの公開案内は、短い開発の区切りで利用者を巻き込みながら進める方法を示しています。画面が動くことと、担当者が日常業務で使えることは別の確認項目です。
試行時には、通常の処理だけでなく、入力が不足した場合、担当者が不在の場合、判断を保留する場合も見ます。そこで分かった手戻りを次の改善に反映します。
仕様と現場のずれを調整する
開発中に現場から新しい要望が出た場合、言われた順に機能を追加するのではなく、最初に合意した問題に照らして必要性を判断します。対象業務、利用者、成果指標への影響を示し、優先順位を更新します。これにより、完成した仕組みが当初の目的から離れるのを防ぎます。
運用定着で担う業務
使われているかを確認する
利用開始後は、操作説明をして終えるのではなく、対象者が実際に使っているか、旧手順へ戻っていないかを確認します。想定した利用回数や作業時間と実績を分け、使われなかった理由を調べます。小さな範囲の試行で見えた効果を、全社の確定成果として扱わないことも大切です。
担当者が回せる形で残す
運用手順、問い合わせ先、例外時の判断、変更の記録を企業側と整理します。FDEが離れた後に、誰が改善を判断し、誰がシステムを管理するかまで決まって初めて、継続的な運用に近づきます。必要な引き継ぎの範囲は、支援を依頼する際に確認してください。
FDEを支えるチームの業務
目的と優先順位をそろえる役割
アンドドットはFDE一名だけでなく、Success PartnerとExpertを組み合わせたFDU体制を公開しています。Success Partnerは目的や優先順位をそろえる役割を担います。現場の改善案と経営・推進側の期待が離れた場合、そのずれを確認する場が必要です。
専門論点を補う役割
セキュリティや業界特有の要件など、現場担当だけでは判断しにくい論点にはExpertが加わると説明されています。ただし、すべての案件で同じ専門家が同じ時間だけ関与するとは限りません。個別の体制と責任範囲は提案時に確認します。
自社でFDEの担当範囲を決めるときの確認項目
最初に変えたい業務と、今困っている場面は何か
現場と推進側のどちらが、優先順位を決めるか
課題整理、解決策の合意、実装、運用のどこまで依頼するか
データ利用とシステム接続の判断者は誰か
試行後に、利用状況と成果をどう確かめるか
この五つが曖昧なまま人数や期間を決めると、依頼した業務と期待した成果が食い違います。FDE導入の準備と、FDE自身が担う業務を分けて整理してから相談すると、提案の比較もしやすくなります。
四段階で残すべき判断と成果物
課題の段階：基準値と対象を固定する
「忙しい」という声だけでは投資判断ができません。対象業務の開始と終了、処理件数、所要時間、手戻り、関係者を定義し、実測できるものと未測定のものを分けます。FDEは現場の作業を整理し、事業責任者はどの問題を優先するかを決めます。この段階で残すのは、改善対象の業務フローと、後で同じ方法で測れる基準値です。
解決策の段階：選ばなかった案も記録する
業務手順の変更、既存機能の活用、新しいツールの導入を同じ目的で比べます。採用案だけでなく、採用しなかった理由、扱うデータ、想定する利用者、評価項目を記録します。後で現場から別の要望が出たとき、判断をやり直す材料になります。
実装の段階：例外を含めて受け入れる
通常の処理が動いても、入力不足、権限不足、担当者不在、結果の誤りに対応できなければ業務には置けません。現場担当者が実際の手順で試し、情報管理担当が接続と権限を確認します。FDEは問題を修正し、試した条件と残る制約を説明します。
運用の段階：実利用に基づき次を決める
対象者のうち何人が使ったか、何件の処理で使われたか、旧手順がどれだけ残ったかを確認します。時間短縮を示す場合は、導入前後の一件あたりの差に実利用件数を掛け、確認・保守で増えた時間を差し引きます。得られた余力と現金の削減は区別し、拡大、修正、終了を判断します。
業務DXで起きやすい三つの手戻り
現場と推進側の目的がずれる
推進側が導入件数を追い、現場が作業の減少を期待していると、同じ成果を見ているつもりでも評価が食い違います。最初に「誰のどの作業を変えるか」を合わせ、途中の振り返りでも確認します。
企画と実装の担当が分断される
企画資料に書かれた用語が現場の判断と異なると、完成後の手戻りになります。FDEが現場の試行と実装を往復し、変更理由を残すことで、ずれを小さい段階で見つけます。
導入後の測定担当がいない
導入時に一度効果を測っても、利用が減れば成果は続きません。運用担当が指標を引き継ぎ、現場の負担や品質の変化を定期的に確認できる形にします。
まとめ
FDEの業務は、課題を見つける、解決策を合意する、現場で使える形に実装する、運用を回せるようにする、という流れです。各段階で企業側の判断とFDE側の作業を明確にし、実際に使われたかまで確認することが重要です。具体的な体制はアンドドットの常駐型FDE案内で確認できます。
各段階の担当と判断を整理できたら、導入に必要な費用と投資対効果、社内での合意方法まで具体化します。次の3点セットには、FDEの進め方から稟議・発注までを検討する資料をまとめています。
