FDE・業務改善 / 公開 2026-07-14 / 更新 2026-07-16 / 約14分
FDEとは?現場に入り、業務改善を「提案」で終わらせないエンジニア
FDEは、きれいな提案書を作って帰る人ではありません。現場で仕事の流れを見て、職員と一緒に小さく試し、実際に使える仕組みとして残すエンジニアです。病院の事務業務を例に、その仕事をできるだけ具体的に説明します。

FDEとは、現場で「使えるところ」まで作るエンジニア
FDEは、Forward Deployed Engineer(フォワード・デプロイド・エンジニア)の略です。直訳すると「前線に配置されたエンジニア」。開発会社の中だけで仕様書を待つのではなく、顧客の現場に入り、まだ言葉になっていない問題を見つけ、試作し、実装し、仕事の流れとして定着するところまで関わります。
この役割を広めた企業としてよく知られているのがPalantirです。現在はPalantirだけでなく、OpenAIやAWSなどもFDEの採用・組織化を進めています。AWSの公式発表では、顧客の実際の制約下で共同開発し、支援終了後に顧客が自走できる状態を目指すことが説明されています。
ただ、肩書きを覚えることはそれほど重要ではありません。FDEを一言で表すなら、相談と開発の間に残っていた距離を埋める人です。
「何か効率が悪い。でも、何をどう頼めばよいか分からない」。そんな曖昧な状態から仕事を始められることが、FDEの大きな特徴です。
病院では、システムが入った後にも事務作業が残る
私は病院のシステム管理室で約10年、院内SEとして働いてきました。電子カルテの導入や運用保守、レセプト・PACS周辺のデータ連携、部署ごとの業務アプリ開発などに関わっています。
そこで何度も見たのが、システムは入っているのに、仕事は十分に軽くなっていないという状態でした。
電子カルテに入力した情報を、別のExcelにも転記する。CSVを出して、毎月同じ形に整える。紙の依頼書を見ながら台帳へ入力する。問い合わせのたびに、詳しい職員を探す。報告書の数字は集計できても、説明文は毎回ゼロから書く。
どれも、一つだけ見れば小さな作業です。けれど、10分の作業が1日20回あれば200分になります。複数の職員が同じ確認をしていれば、組織全体ではさらに大きな時間です。
ここで大事なのは、「人件費削減」をすぐ人員削減に置き換えないことです。病院で先に減らしたいのは、残業、二重入力、差し戻し、確認待ち、担当者探し、専門職が本来業務以外に使っている時間です。採用が難しい状況では、今いる職員が無理なく仕事を続けられる余白を作ることにも意味があります。
FDEは、実際にどのような流れで業務改善を進めるのか
業務改善と聞くと、最初にAIツールや製品を選ぶ姿が浮かぶかもしれません。実際には、道具を選ぶのは少し後です。先に見るのは、人、情報、判断、例外がどの順番で動いているかです。
1. 経営上の困りごとを聞く
最初に確認するのは、「AIで何ができるか」ではありません。残業を減らしたいのか、採用難を補いたいのか、入力ミスを減らしたいのか、締め処理を早くしたいのか。経営側が解決したい問題を明らかにします。
2. 現場の職員に、普段どおりの仕事を見せてもらう
マニュアルだけでは、実際の仕事は分かりません。紙に書かれたメモ、担当者しか知らないExcel、月末だけ発生する例外、確認のための電話。こうした「書かれていない手順」を見つけます。
現場の方には、改善案を用意してもらう必要はありません。「ここで毎回待つ」「この数字だけ怖い」「あの人が休むと止まる」といった言葉の方が、改善の入口になります。
3. 現在の業務フローを図にする
誰が、何を受け取り、どこへ入力し、誰が確認するのか。通常処理だけでなく、差し戻しや例外も含めて図にします。部署ごとの認識が違うときは、この段階で初めて違いが見えることもあります。
4. 件数・時間・ミス・待ち時間を測る
月に何件あるのか。1件に何分かかるのか。差し戻しは何件か。改善前の数字がないと、導入後に「少し楽になった気がする」で終わってしまいます。
5. 効果、難易度、安全性から優先順位を決める
時間がかかっている業務が、必ず最初の対象になるわけではありません。患者情報の有無、既存システムへの接続方法、判断の複雑さ、失敗したときの影響も見ます。効果が大きく、手順が比較的決まっており、安全に切り出せる業務から始めます。
6. 一部署・一業務で小さく試す
いきなり院内全体へ展開しません。ダミーデータや個人情報を除いたデータを使い、画面や自動処理を小さく作ります。現場の職員に触ってもらい、「この確認は消してはいけない」「この順番なら使える」といった意見をもらいます。
7. 本番の運用まで設計する
動くプログラムだけでは、業務改善は完成しません。権限、ログ、エラー時の連絡、人の最終確認、バックアップ、手順書、担当者変更時の引き継ぎまで決めます。
8. 効果を測り、次の改善を決める
作業時間が減ったか。差し戻しは減ったか。職員が実際に使っているか。想定外の手作業が増えていないか。数字と現場の声を見て、直すか、広げるか、やめるかを判断します。
この流れは一本道ではありません。試作して初めて分かる例外もあります。FDEは観察、試作、検証を短く往復しながら、現場に合う形へ近づけます。
具体例:月次集計を改善するなら、どこまで見るのか
たとえば、医事課や管理部門で毎月行う集計を考えてみます。
改善前は、複数システムからCSVを出し、ファイル名を変え、Excelへ貼り付け、前月との差を確認し、上司向けの報告文を書く。担当者は慣れているので作業できますが、その人が休むと手順が分かりません。
ここで「CSVを自動で結合すれば終わり」と考えると、うまくいかないことがあります。出力日によって列が変わる、再請求分だけ扱いが違う、締め後の修正は別表に入れる、といった例外があるからです。
FDEは、例外を含む現在の流れを見たうえで、自動化する場所と人が確認する場所を分けます。
| 改善前 | 改善後 |
|---|---|
| 担当者が複数のCSVを探す | 決めた場所から対象ファイルを読み込む |
| Excelへ手作業で転記する | 形式をそろえて集計表を作る |
| 前月差を目で探す | 大きな差や欠損を確認候補として出す |
| 報告文を毎回書く | 数字を基に報告文の下書きを作る |
| 手順が担当者の記憶にある | 処理ログと手順書を残す |
| 最後まで人が作業する | 数字の確定と送信は人が行う |
AIを使うなら、異常値の理由を勝手に断定させるのではなく、「確認した方がよい差」を挙げる、報告文の下書きを作る、といった補助から始めます。数字の責任までAIに渡さないことが大切です。
FDEとSES、社内SE、コンサルは何が違うのか
よく聞かれるのが、「客先に来るならSESと同じでは」「院内SEがいれば不要では」という疑問です。
違いは、職種の優劣ではありません。何を目的に置き、どこまで責任を持つかです。
| 役割 | 主な目的 | 得意な場面 | 業務改善での関わり方 |
|---|---|---|---|
| FDE | 現場課題を見つけ、動く仕組みとして定着させる | 要件がまだ曖昧、既存業務に合わせた試作が必要 | 課題発見から実装・定着・効果測定まで関わる |
| SES | 必要な技術者・稼働を提供する | 必要な役割や作業が明確、人員を補いたい | 契約された業務範囲を担う |
| 社内SE | 組織のITを継続的に支える | 日常運用、問い合わせ、ベンダー調整、全体最適 | 内部事情を理解し、改善後も運用を守る |
| コンサル | 課題整理、構想、意思決定を支援する | 全社戦略、制度や組織を含む大きな論点 | 分析・計画・実行支援を中心に担う |
病院では、FDEが社内SEを置き換える形より、事務長、現場責任者、院内SE、FDEが一緒に動く形が現実的です。院内SEは既存システムやベンダーとの関係、変更時の影響をよく知っています。FDEは、日常運用で手が回りにくい業務観察や短期試作を担当する。役割を分けた方が安全です。
一般的なFDEは、自社プロダクトを持つ会社のエンジニアが顧客現場で製品を適用し、得た知見を製品へ戻すモデルを指すことが多くあります。Eighgentは現段階で、特定製品だけを入れる会社ではありません。Excel、既存SaaS、AI、ワークフロー、Webアプリを組み合わせる、FDE型の現場実装パートナーという位置づけです。この違いは曖昧にせず、依頼前に説明します。
病院では、まず事務から始める方がよい
電子カルテとの連携は、業務改善の効果を大きくできる可能性があります。一方で、患者情報、ベンダー仕様、ネットワーク分離、権限、監査、障害時の診療への影響など、考えることが一気に増えます。
だからEighgentでは、最初から電子カルテの中へ深く入ることを前提にしません。
第1段階:患者情報を扱わない事務業務
院内規程の検索、公開情報の整理、個人情報を含まない月次集計、問い合わせ受付、会議資料の下書きなどです。まず、Eighgentの進め方と成果物の品質を見てもらいます。
第2段階:匿名化・限定データを使う部署業務
サンプル帳票、匿名化した業務データ、一部のCSVなどで検証します。現場の確認方法、権限、ログ、エラー対応を固めます。
第3段階:電子カルテの外側で安全に連携する
電子カルテから正式に出力されたCSVや帳票、参照用データを使い、集計や文書下書きを支援します。最初からデータベースへ直接書き込むのではなく、読み取り・下書き・人の確認から始めます。
第4段階:必要性が確認できた範囲だけ接続を深める
効果、責任分界、ベンダーとの調整、院内の承認がそろった場合に限り、APIやデータ連携を検討します。技術的に可能であることと、病院として実施すべきことは同じではありません。
厚生労働省は、医療DXの目的の一つに医療機関等の業務効率化を挙げています。同時に、医療情報を扱うシステムでは医療情報システムの安全管理に関するガイドライン 第7.0版を踏まえ、組織、運用、技術、委託先を含めて考える必要があります。
「クラウドAIは全部危険」でも、「契約したサービスなら何を入れても安全」でもありません。扱うデータ、利用目的、保存、学習利用、権限、ログ、責任分界を一つずつ確認します。
FDEに向いている課題、別の依頼先が向いている課題
FDEが力を発揮しやすいのは、困りごとはあるものの、まだ仕様書になっていない仕事です。
- 同じ情報を紙、Excel、システムへ何度も入力している
- 一人の職員しか分からない集計や確認がある
- 新しいシステムを入れたが、周辺の手作業が残っている
- AIを試したが、実際の業務へ組み込めていない
- 大規模投資の前に、一部署で効果を確認したい
- 現場、管理職、院内SE、ベンダーの間を整理する人が必要
反対に、仕様が完全に決まった大規模パッケージ導入、24時間365日の保守要員、単純な人員補充、診断・治療判断をAIへ任せる開発は、Eighgentの初期支援には向きません。必要に応じて、既存ベンダーや専門事業者と役割を分けるべき領域です。
Eighgentが病院事務のFDEを目指す理由
病院の社内SE時代、改善相談は「システムを作ってほしい」という形で来るとは限りませんでした。「この集計が毎月大変」「患者さんを待たせすぎていないか分からない」「この確認を見落とすのが怖い」といった、現場の言葉から始まります。
その話を聞き、電子カルテやレセプト、PACS周辺のデータを確認し、Excelマクロや業務アプリへ落とし込む。導入後に現場から修正点を聞き、運用できる形に直す。今振り返ると、この仕事の進め方はFDEにかなり近いものでした。
ただし、過去に院内SEとして改善した経験があるからといって、別の病院でも同じ方法がそのまま使えるとは考えていません。病院ごとに規模、システム、職員配置、規程、ベンダー契約が違います。だから、製品を先に決めるのではなく、まず現場を見る必要があります。
Eighgentが提供したいのは、「AIを入れましょう」という提案ではありません。
今の仕事のどこが重いのかを一緒に見つけ、安全に切り出せる部分を小さく作り、現場が使い続けられる形にすること。
それが、病院事務におけるFDEの役割だと考えています。
相談前に用意するものは、一つだけでよい
要件書も、使いたいAI製品の一覧も必要ありません。
「毎月つらい作業」「特定の人しかできない作業」「ミスが怖い作業」のどれかを、一つ挙げてください。そこから、誰が関わり、何件あり、どこで待ち、何を確認しているかを整理します。
最初のゴールは、院内全体を変えることではありません。一部署・一業務について、改善する価値があるか、安全に試せるか、どの数字で効果を見るかを判断できる状態にすることです。
FDEについてよくある質問
FDEは病院へ常駐しないと成立しませんか?
常時常駐が必須とは限りません。ただし、業務観察や関係者との認識合わせは、現地でなければ分からないことがあります。初期観察や重要な検証は訪問し、設計・開発・資料作成はリモートで進めるなど、業務に合わせて組み合わせます。
FDEとAIエンジニアは同じですか?
重なる部分はありますが、同じとは限りません。AIエンジニアはAIモデルやAI機能の開発を中心にする場合があります。FDEはAIを使うかどうかにかかわらず、顧客の業務課題を見つけ、既存システムや運用へ組み込み、使われる状態まで進めることに重点があります。
社内SEがいる病院でも依頼する意味はありますか?
あります。社内SEは日常運用、障害対応、アカウント管理、ベンダー調整など多くの仕事を抱えています。外部FDEが業務観察や短期試作を担当し、院内SEが既存環境と運用の観点を確認する分担が考えられます。院内SEを飛ばして進めるべきではありません。
最初から患者情報や電子カルテへ接続しますか?
原則として、最初から深い接続はしません。患者情報を扱わない事務業務、ダミーデータ、匿名化データ、正式に出力されたCSVなどから始めます。必要性と安全性が確認できた後に、院内承認やベンダーとの調整を含めて次の段階を検討します。
人件費削減の効果はどう測りますか?
削減人数だけでは測りません。作業時間、残業時間、外注費、差し戻し件数、入力ミス、締め処理までの日数、問い合わせ件数、特定職員への集中などを改善前後で比べます。削減できた時間を、患者対応や経営管理など本来業務へ戻せたかも確認します。
導入後、Eighgentがいないと動かない仕組みになりませんか?
属人化を別の属人化へ置き換えないことが重要です。処理ログ、設定、手順書、エラー時の対応、責任分界を残し、院内担当者が状況を確認できる形を基本にします。継続支援が必要な場合も、依存させることを目的にはしません。