想定読者
AIや業務アプリの導入を進めたいのに、「作る人」と「現場の困りごとを理解する人」の間が埋まらず、話が前に進まない中小企業の経営者・DX担当者・情シス兼任者の方です。
外部パートナーへの依頼や、社内人材の育成を検討している方にも向けています。
要点
- FDE（Forward Deployed Engineer）は、顧客や社内の現場に入り込み、課題の整理から開発・導入・定着までを一貫して担う技術者です。AIで「作る作業」が速くなるほど、「何を作るか」を決める役割の価値が高まります。
- 中小企業では「内製・伴走支援・外注」を業務ごとに使い分けるのが現実的です。FDE的な役割を誰が担うかを決めておくと、導入が止まりにくくなります。
- FDE的な人材は、課題発見・要件整理・AIと開発・セキュリティ・定着支援の5つの力で見極め、小さな業務から育てられます。
FDEとは何か｜現場に入り込んで課題から動くものまで運ぶ人材
FDEは「Forward Deployed Engineer」の略で、日本語にすると「前線に配置された技術者」といった意味です。
顧客や現場に入り込んで課題解決にあたる技術者を指す言葉です。
製品を売って終わりにせず、顧客の現場で業務を観察し、その場で必要なものを作り、使われるところまで見届けるのが特徴です。
大切なのは肩書きよりも役割です。社外の専門家でも、社内の情シスや現場リーダーでも、「現場に入り込み、課題から動くものまで運ぶ」ことを担っていれば、FDE的な役割を果たしていると言えます。
従来のSE・コンサルタント・社内情シスとの違い
似た役割は昔からありますが、重心が少しずつ違います。
- SE（システムエンジニア）：決まった要件をもとに、システムを設計・開発する役割です。要件が固まっていれば強い一方、現場の曖昧な困りごとを要件に落とす部分は、別の人が担うことが多くなります。
- コンサルタント：課題を分析し、方針や提言をまとめる役割です。提言と実際に動くものとの間に距離が残りやすく、「資料は立派だが、現場では何も変わらない」という状態も起こり得ます。
- 社内情シス：社内のIT全般を支える役割です。中小企業では1人で兼任していることも多く、日々の問い合わせ対応で手一杯になりがちです。
FDE的な役割は、これらの間をつなぎます。現場の言葉で課題を聞き取り、自分で試作し、現場に使ってもらって直し、運用に乗せるまでを一人、または少人数のチームで回します。
分担を細かく切るほど、受け渡しのたびに「現場の文脈」が抜け落ちます。その抜け落ちを最小にするのが、FDE的な動き方の価値です。
AIで開発が速くなった今、なぜ「何を作るか」を決める人が求められるのか
AIの支援によって、画面や簡単な業務アプリを作る作業はこれまでよりずっと速くなりました。作るコストが下がると、ボトルネックは「作ること」から「何を作るか決めること」へ移ります。
たとえば、ある中小企業の経理業務を考えてみます。「請求書の処理を楽にしたい」という依頼があっても、実際に困っているのは入力作業なのか、承認の待ち時間なのか、取引先ごとの書式の違いなのかで、作るべきものは全く変わります。
ここを聞き違えると、速く作れるぶん、「使われないアプリ」も速く量産されてしまいます。
つまり、AIで開発が速くなるほど、現場で課題を見極め、優先順位をつけ、定着まで責任を持つ人の重要性が増します。
開発の進め方そのものの詳細は別の記事に譲り、本稿では「その役割を誰が担うか」に絞って整理します。
中小企業にとってのFDE｜内製・伴走支援・外注をどう使い分けるか
中小企業が「FDEを雇う」のは現実的ではないことが多いでしょう。そこで、役割を誰が担うかという観点で、3つの進め方を使い分けます。
3つの進め方の比較
| 項目 | 内製 | 伴走支援 | 外注 |
|---|---|---|---|
| 主な担当者 | 社内の担当者 | 社内＋外部の専門家 | 外部の開発会社 |
| 得意な場面 | 日々変わる現場業務 | 初めての導入・育成期 | 仕様が固い定型案件 |
| 現場理解 | 深い | 共に深める | 伝える工夫が必要 |
| 立ち上げ速度 | 経験次第 | 比較的速い | 速い |
| 注意点 | 属人化・負荷集中 | 依存し続けないこと | 丸投げと保守の空白 |
| 知見の残り方 | 社内に残る | 社内に移していく | 残りにくい |
内製は、現場に近く修正も速い反面、担当者1人に負荷が集中しやすい進め方です。伴走支援は、外部の専門家が現場に入りながら、社内担当者へ進め方を移していく形です。
外注は、仕様が固まっている定型的な案件では効率的ですが、現場の文脈を渡しきれないと、完成後に使われない危険があります。
どれが正解というわけではなく、業務ごとに選びます。毎週のように手直しが入る現場の集計作業は内製、初めてAIを業務に組み込む案件は伴走支援、仕様が明確で変更が少ない基幹寄りの仕組みは外注、というのが一つの目安です。
内製化を目指すときに、最初から全部を自社で抱えない考え方
「内製化」と聞くと、すべてを自社だけで作る姿を想像しがちです。
しかし、最初から全部を抱えると、担当者が疲弊して止まります。
現実的なのは、段階を分ける考え方です。最初は「課題の整理と優先順位づけ」と「現場での試用・改善」を自社が持ち、難しい部分（設計の勘所、セキュリティの確認など）は外部に補ってもらいます。
経験が溜まるにつれて、自社で持つ範囲を広げていきます。QuadComでも、内製化を支える伴走では、「できあがったものを渡す」よりも「自社で回せる状態に近づける」ことを重視しています。
伴走支援で任せる範囲と、自社に必ず残す範囲
伴走支援を使う場合でも、自社に残すべきものがあります。
- 業務判断：何を優先し、何をやめるかの決定は、現場と経営が持ちます。
- データ：業務データの保管場所と管理者は、自社が把握します。
- 権限：誰にどの権限を渡すかの決定は、自社が持ちます。
逆に、設計の相談、試作の支援、技術的な選択肢の整理、レビューなどは外部に任せやすい部分です。「判断・データ・権限は自社、技術の補強は外部」という線引きを、依頼の最初に言葉にしておくと、後でもめにくくなります。
FDE的な人材に必要な5つの力と、見つけ方・育て方
課題発見・要件整理・AIとアプリ開発・セキュリティ・定着支援の5つの力
FDE的な人材には、次の5つの力が求められます。1人がすべて完璧である必要はなく、チームや外部との組み合わせで補えます。
- 課題発見力：現場の作業を観察し、「本当に困っていること」を見つける力です。依頼された内容をそのまま受け取らず、背景を尋ねられるかがポイントです。
- 要件整理力：曖昧な困りごとを、「誰が・何を・いつ・どうしたいか」という具体的な条件に直す力です。
- AIとアプリ開発の力：AIの支援を使いながら、小さく試作して動かす力です。完璧な設計より、まず動くものを見せて意見をもらう姿勢が大切です。
- セキュリティの感覚：扱うデータの重要度を見分け、渡してよい権限や情報の範囲を判断する力です。
- 定着支援力：使い方の説明、現場の声の収集、改善、運用ルールづくりまでを担う力です。作って終わりにしない粘り強さとも言えます。
社内の情シス・現場リーダーから育てる方法（小さな業務改善を1本任せる）
育成の近道は、研修よりも「小さな業務改善を1本任せる」ことです。情シスは技術面に強く、現場リーダーは業務の文脈に強いため、2人を組ませると5つの力のバランスが取りやすくなります。
最初に任せる業務は、次の条件で選ぶと失敗しにくくなります。
- 毎週・毎月など、繰り返し発生している
- 困っている人がはっきりしていて、声を聞ける
- 扱うデータが、機密性の高いものではない
- うまくいかなくても、事業への影響が小さい
- 効果が「時間が減った」など、目に見える形で確認できる
たとえば、会議資料の定型集計、問い合わせ内容の分類、日報の要約といった業務が、最初の1本に向いています。
基幹システムや、顧客の個人情報を大量に扱う業務は、慣れてからにします。
伴走パートナーを選ぶときの確認点と、質問の具体例
外部パートナーを選ぶときは、技術力だけでなく「現場に入り込む姿勢」と「自社に力を残す姿勢」を確かめます。
次のような質問が役に立ちます。
- 「最初の打ち合わせで、現場の作業を見せてもらうことはできますか？」（現場に入り込む姿勢の確認）
- 「完成したものを、私たちだけで修正・運用できるようにする計画はありますか？」（依存を避ける姿勢の確認）
- 「作ったアプリの管理者と保守担当は、誰になる想定ですか？」（保守の空白の確認）
- 「AIに入力してはいけない情報について、どんな線引きを提案しますか？」（セキュリティ感覚の確認）
- 「うまくいかなかった案件で、どこを見直しましたか？」（失敗から学ぶ姿勢の確認）
答えが具体的で、自社の状況に合わせて説明してくれるかを見ます。「何でもできます」という返答よりも、「ここまでは任せてほしい、ここからはそちらで決めてほしい」と線を引いてくれる相手のほうが、安心して頼めます。
導入の進め方｜最初の90日のスケジュール例
「何から始めるか」が決まらないと、検討だけで数か月が過ぎます。90日を4つの段階に分けて進める例を示します。
| 期間 | 段階 | やること |
|---|---|---|
| 1〜3週目 | 業務の選定 | 候補を出し1本に絞る |
| 4〜6週目 | 試作 | 動く小さなものを作る |
| 7〜10週目 | 現場で試す | 少人数で使い改善する |
| 11〜13週目 | 運用ルール化 | 管理者・手順を決める |
業務の選定（1〜3週目）では、現場の担当者に「いま一番時間がかかっている作業」を聞き取り、候補を5〜10個ほど挙げます。
前述の条件に当てはめて、1本に絞ります。このとき、現場の作業を実際に横で見せてもらうと、聞き取りだけでは出てこない手戻りや例外処理が見つかります。
試作（4〜6週目）では、完成度を求めず、「入力して結果が出る」最小限の形を作ります。AIの支援を使えば、比較的短い期間で形になることもあります。
大切なのは、早く現場に見せて意見をもらうことです。
現場で試す（7〜10週目）では、2〜3人の協力者に実際の業務で使ってもらいます。使いにくい点、想定外の入力、手作業に戻ってしまう箇所を記録し、毎週直します。
運用ルール化（11〜13週目）では、誰が管理者か、困ったときの連絡先、データの置き場所、見直しの時期を決めて文書にします。
ここまでやって初めて「定着した」と言えます。
権限・データ・AIに渡す情報｜セキュリティの線引き
現場に入り込む人ほど、多くの情報や権限に触れます。便利さと引き換えにならないよう、導入の最初に線引きを決めます。
開発者や外部パートナーに渡す権限・データ
- 最小限の権限から始める：必要な作業に足りる範囲だけを渡し、広い管理者権限は渡しません。
- 期間を区切る：作業が終わったら権限を外す日を、最初に決めておきます。
- 本番データは慎重に：試作段階では、実際のデータの代わりに、架空のサンプルデータを使います。
- 個別のアカウントを使う：共有のIDとパスワードを使い回さず、誰が何をしたか分かる形にします。
AIに入力してよい情報の線引き
AIに情報を入力する際は、社内で次の3段階のように分けておくと判断しやすくなります。
- 入力してよい：公開済みの情報、一般的な文章、架空のサンプルデータ
- 確認してから入力する：社内限りの資料、取引条件など
- 入力しない：顧客の個人情報、パスワードや認証情報、契約上の秘密保持の対象になる情報
利用するAIサービスによって、入力内容の扱いは異なります。契約や設定を確認し、迷うものは「入力しない」側に倒すのが安全です。
作ったアプリの管理者と保守担当
作ったアプリには、必ず管理者（誰の持ち物か）と保守担当（壊れたときに直す人）を決めます。担当者が異動・退職したときの引き継ぎ先も、あわせて決めておきます。
ここが空白のままだと、数か月後に「誰も触れない謎のアプリ」が残ります。
属人化と丸投げを防ぐ記録と引き継ぎ
内製でも外注でも、うまくいかなくなる原因の多くは、属人化と丸投げです。
属人化を防ぐには、作業の記録を「あとで読む人」のために残します。最低限、次の4点を1枚にまとめるだけでも効果があります。
- 何のために作ったか（目的と対象業務）
- 誰が使うか、誰が管理するか
- どのデータを、どこに置いているか
- 困ったときの直し方と連絡先
丸投げを防ぐには、外部に頼む場合でも、週に1回など定期的に進み具合を見て、自社の判断が必要な点をその場で決めます。
「完成したら教えてください」という頼み方は、現場とのずれを最後まで放置する原因になります。
まとめ｜自社のFDE的な役割を確認する
FDEの本質は、特別な肩書きではなく、「現場に入り込み、課題から定着までを運ぶ」という役割にあります。
AIで作る作業が速くなった今、その役割を誰が担うかを決めておくことが、導入を止めないための近道です。
内製・伴走支援・外注は、業務ごとに使い分けます。判断・データ・権限は自社に残し、技術の補強は外部の力を借りる。
最初は小さな業務を1本任せ、90日で「試して、直して、運用に乗せる」流れを一度経験することで、社内に力が溜まります。
最後に、自社の現状を確かめるチェックリストを用意しました。いくつ当てはまるかよりも、空白になっている項目を見つけることが目的です。
自社のFDE的な役割の確認チェックリスト
- [ ] 現場の困りごとを聞き取り、課題として整理する担当者を決めている
- [ ] 最初に任せる小さな業務改善を、1本に絞っている
- [ ] 内製・伴走支援・外注のどれで進めるかを、業務ごとに決めている
- [ ] 業務判断・データ・権限を自社に残す範囲として言葉にしている
- [ ] 開発者や外部パートナーに渡す権限の範囲と期限を決めている
- [ ] AIに入力してよい情報としてはいけない情報を、一覧にできる
- [ ] 作ったアプリの管理者と保守担当を、アプリごとに決めている
- [ ] アプリの目的・データの置き場所・連絡先を、1枚の記録にまとめている
- [ ] 試作を現場で試し、意見を集める少人数の協力者を決めている
- [ ] 運用が始まったあとの見直しの時期を決めている
QuadComがクライアントのかゆいところまで手が届くサービスを提供できるのは、CEOがまさにFDE的な人物だからだと思います。
究極を言えば、経営者や管理職がそういう人材であれば、エンジニアの雇用は最小限でいいことになります。
