FDEエンジニアの仕事：AI導入を前へ進める五つの場面

FDEエンジニアの一日は、職務経歴書の一行には収まりません。午前中は利用部門の仕事を見せてもらい、午後はログを調べ、夕方には試作の失敗例を開発チームと確認する。翌日は法務やセキュリティと話しているかもしれません。

仕事が散らかって見えるのは、FDEがAI導入の前後をつないでいるからです。担当範囲が無制限というわけではありません。曖昧な課題をチームが扱える判断に変え、本番で使われるところまで前へ進める。この責任が仕事の軸になります。

ここでは、現場で繰り返し現れる五つの場面に分けて、何を見て、何を残し、どこで立ち止まるのかを整理します。

1. 業務を観察する

最初の仕事は、依頼をそのまま要件にしないことです。「議事録を要約したい」「社内検索を良くしたい」「問い合わせを減らしたい」という言葉だけでは、作るものを決められません。

FDEは実際の画面、資料、引き継ぎ、例外対応を見ます。利用者がどの順番で情報を開き、どこで迷い、何を根拠に最終判断しているかを追います。担当者の説明と実際の手順が違うことも珍しくありません。長く続いた業務ほど、本人には見えない工夫が埋まっています。

観察時に聞きたいのは、抽象的な要望より具体例です。

• 直近で時間がかかった一件を見せてもらえますか
• 迷ったとき、誰に何を確認しますか
• 絶対に自動化してはいけない判断はありますか
• 入力が足りないとき、今はどうしていますか
• この仕事がうまくいったと、何を見れば分かりますか

この段階で残すのは、現状の業務フロー、利用者、入力、判断、出力、例外を一枚にまとめた観察メモです。体裁より、次の確認に使えることを優先します。分からない箇所には、無理に答えを入れず「誰に、いつ確認するか」を書きます。

2. 範囲を設計する

次に、最初の試行で何を扱うかを決めます。AI導入では、対象を広げるほど価値が増えるとは限りません。例外と関係者が増え、結果の理由が読めなくなるからです。

良い試行は、業務の一部分を端から端まで通します。たとえば問い合わせ対応なら、全種類を薄く扱うのではなく、「製品の使い方に関する質問を受け、根拠付きの回答案を作り、担当者が確認して送る」と範囲を切ります。これなら入力、出力、確認者、時間短縮を観察できます。

スコープ資料には、最低限次を入れます。

項目	書く内容
対象利用者	誰が、どの場面で使うか
対象業務	今回通す一つの流れ
対象外	今回は扱わない質問、データ、判断
成功条件	時間、品質、利用率などの観察方法
中止条件	情報漏えい、重大な誤案内、負担増など
判断者	続行、修正、停止を誰が決めるか

対象外を明記するのは逃げではありません。「できないこと」を利用者に伝えないまま公開するほうが危険です。

3. 実装と評価を往復する

試作は、完成品の小型版ではありません。分からないことを減らすための道具です。画面を作る前に検索品質を確かめたい案件もあれば、モデルより入力フォームの使いにくさが問題になる案件もあります。いちばん大きな不確実性から試します。

評価用の例は、成功しやすいものだけを集めません。典型例、難しい例、情報不足、対象外、権限外を混ぜます。問い合わせAIなら、短い質問だけでなく、複数の意図を含む文、古い製品名、返金要求、個人情報を含む相談も必要です。

評価軸も正解率だけでは足りません。

• 根拠は正しく、利用者が確認できるか
• 答えてはいけない場面で止まれるか
• 人への引き継ぎが適切か
• 担当者の確認時間は本当に減ったか
• 出力を直す手間が、新しく増えていないか

平均点が上がっていても、重大な誤りが一件増えたなら公開できないことがあります。逆に、完全自動化できなくても、下書き作成で確認時間が半分になるなら価値があるかもしれません。FDEは数字を並べるだけでなく、その数字で何を決めるのかまで用意します。

失敗例は、原因を切り分けて残します。参照データが古いのか、検索で拾えていないのか、指示が曖昧なのか、画面が必要な情報を集められていないのか。原因によって、戻る場所はモデル、データ、UI、運用ルール、利用者教育に分かれます。

4. 合意をつくる

AI導入には、違う心配を持つ人が集まります。利用部門は仕事が増えないかを気にします。開発チームは変更範囲と保守を見ます。セキュリティ担当はデータと権限を確認し、責任者は費用と事故時の影響を判断します。

FDEは論点を同じ机に載せ、関係者が判断できる状態を作ります。ここで役立つのが、短い意思決定メモです。

1. 何を決める必要があるか
2. 分かっている事実は何か
3. まだ分からないことは何か
4. 選択肢ごとの影響は何か
5. 誰が、いつ決めるか

合意とは、全員が同じ意見になることではありません。今決めること、試してから決めること、最終判断者が共有されている状態です。議事録には会話の要約より、決定、保留、担当者、期限を残します。

安全面では、データの出所と利用権限、ログに残す情報、削除方法、問題時に止める手順を確認します。「人が確認するから安全」という説明も十分ではありません。確認者が何を見て、何秒使い、見逃した場合にどう検知するかまで設計します。

5. 定着を見届ける

公開してからが運用の始まりです。既存の手順から遠い、入力が面倒、例外時の相談先がない、更新担当が決まっていない。こうした理由で利用が止まることがあります。デモでは見えにくい問題です。

導入後は、利用回数だけで判断しないようにします。対象者のうち何人が使ったか、どの場面で離脱したか、人へ引き継いだ割合、修正にかかった時間、同じ失敗が繰り返されていないかを見ます。利用率が低いときは「現場が変化を嫌っている」と決めつけず、使わないほうが合理的な理由を探します。

定着に必要なのは、豪華な研修より、日常の仕事に近い支援です。最初の利用場面を一つ決める。よくある失敗を短いガイドにする。相談先を画面から見える場所に置く。週に一度、実際の例を見ながら改善を決める。こうした小さな運用が続くと、利用者の声が単なる要望ではなく、次の設計材料になります。

五つは往復する

五つの場面は、順番どおりに一度だけ通る工程ではありません。評価中に業務の前提が違うと分かれば観察へ戻ります。セキュリティ確認で扱えるデータが減れば、範囲を切り直します。公開後の失敗例から、評価データを更新することもあります。

FDEが進行役として価値を出すのは、この戻りを失敗扱いしない点です。早く戻れば、手戻りは小さく済みます。問題は、戻った理由を残さず、同じ仮説を何度も試すことです。

一週間の動き方

案件の初期なら、FDEの一週間は次のように動きます。

月曜日は利用者の仕事を観察し、実例を集める。火曜日は業務フローと対象外を整理し、責任者と試行範囲を決める。水曜日は小さな試作を動かし、評価例を追加する。木曜日は利用者に触ってもらい、迷った箇所と失敗例を記録する。金曜日は結果を開発、運用、責任者と読み、続けるか、直すか、止めるかを決める。

実際には会議や障害対応が入り、きれいには進みません。それでも、週の終わりに「何が分かり、次に何を判断するか」が残っていれば、案件は前へ進んでいます。

成果をどう示すか

FDEの成果を、書いたコード量だけで測るのは難しいでしょう。見るべきなのは、案件が判断可能になったか、利用者の仕事が変わったか、学びが次へ残ったかです。

ポートフォリオを作るなら、完成画面だけでなく過程を見せます。どんな業務を観察し、どこまでを対象にし、何をもって成功と決めたか。どんな失敗が起き、どの判断で設計を変えたか。公開後に何を測り、次の改善へどうつないだか。機密情報を伏せても、この構造は説明できます。

良い事例には、派手な成功だけでなく、止めた判断も含まれます。試行の結果、確認負担が増えたため導入を見送った。それでも、どの条件なら再検討できるかを残した。その判断は、無理に公開するより価値があります。

最初の30日で試すこと

FDEの仕事へ近づきたいなら、最初の30日で一つの小さな案件を端から端まで追ってみてください。

最初の週は観察に使い、具体例を十件集めます。二週目は対象と対象外、成功条件、中止条件を一枚にします。三週目は最小の試作を作り、正常例と失敗例で評価します。四週目は利用者に試してもらい、結果と次の判断を短いレポートにします。

必要なのは大規模なシステムではありません。小さな業務でも、観察、範囲設計、実装、評価、導入判断を一周できれば、FDEの仕事が具体的に見えてきます。学習コースでは各段階を順に確認でき、オンライン試験では実務シナリオに対する判断を練習できます。

FDEエンジニアの仕事は、万能な人になることではありません。現場と技術の間にある不確かさを、チームが扱える問いと記録に変えることです。次の案件では、解決策を話す前に「いま、何を判断できていないのか」を一行で書いてみてください。そこから仕事の輪郭が見えてきます。