FDEチームは最初何人から始めればいいですか？

2〜3人が現実的な出発点です。1人では属人化リスクが高く、5人以上だとパイロット案件の前に予算承認が長期化します。2人でも、コードを書けるFDE1名と事業側との調整を担う1名がいれば、最初のプロジェクトを動かせます。

FDE人材は外部から採用するべきですか、社内から育てるべきですか？

最初の1名は外部採用が有効です。社内育成だけでは立ち上がりに6か月以上かかるため、即戦力の外部採用1名を軸に、周囲の社内人材を育てていく形が現実的です。

FDEチームの年間予算はどのくらいかかりますか？

2〜3人のチームで年間2,000〜3,500万円が目安です。人件費が大半を占め、ツール費は月10〜30万円程度に収まります。ただし外部ベンダーへの依存度によって幅があります。

既存のIT部門やDX推進部門とどう役割を分けますか？

IT部門はインフラ・セキュリティ・ガバナンス、DX部門は全社標準化・研修を担います。FDEチームはその中間に立ち、特定の業務課題を現場で解決することに専念します。ポイントは『インフラを管理しない、研修もしない』と明確に線引きすることです。

社内にFDEチームを作る方法：体制・採用・予算の実際

結論：2〜3人から始め、90日で1案件を完遂する

FDEチームは最初から大きく作らなくていい。2〜3人の少人数で立ち上げ、最初の90日でパイロット案件を1つ完遂することが、社内での信頼と予算の獲得につながる。

逆に言えば、人員を揃えることより「一つ動くものを作り切ること」のほうが先だ。チームへの投資は成果を見せた後に追加されるのが通常の流れであり、立ち上げ段階で5人以上を要求すると予算承認が長期化して、着手前に立ち消えになるリスクが高い。

この記事では、FDEチームを社内に設置する手順を、ミッション設定から採用・予算・最初の90日まで具体的に解説する。FDEとは何かという基礎は別記事で確認してほしい。

FDEチーム設置の前に決める3つのこと

ミッションを1文で書く

FDEチームが失速する理由の多くは、ミッションが曖昧なままスタートしたことにある。「AI活用を推進する」では目的が広すぎて、何をすべきか何をすべきでないかが判断できない。

ミッションは1文で書ける粒度まで絞る必要がある。たとえば「特定の業務部門が抱えるボトルネックをAIで解決し、現場が自走できる状態に引き渡す」のように、対象・手段・完了条件が入っていれば判断の軸になる。この1文がないと、チームはすぐにヘルプデスク的な雑用を引き受け始める。

報告ラインはどこか

FDEチームの報告先は、IT部門・DX推進部門・事業部門のいずれかになることが多い。この選択はチームの動きやすさを大きく左右する。

IT部門傘下に置くと、セキュリティ承認や調達プロセスが義務になりやすく、現場対応のスピードが落ちる。事業部門に入れると特定の部署利益に引っ張られる。最も機動的なのは、経営直轄か事業部門を横断するCOO・CDO直下の配置だ。ただしどこに置くにしても「インフラ管理はしない、研修も主業務ではない」という境界を最初に明文化することが重要だ。

KPIを3つ以内に絞る

多くの指標を設定するほど、FDEチームは評価に振り回される。立ち上げ段階では3つ以内に絞るべきだ。たとえば「導入した業務の処理時間削減率」「パイロット案件数」「対応した部署の数」といった形で、数値で追えるものを選ぶ。KPIはスポンサーとなる役員と合意しておくことで、予算更改の際の根拠にもなる。

最初のチーム構成：2人と3人の違い

2人構成の場合

最小構成は2人だ。1人は実装を担当するFDE本体、もう1人は事業部門との調整・要件整理・プロジェクト進行を担う人材だ。

2人構成の弱点は、FDE本体が実装と折衝の両方を兼ねることが増え、作業負荷が集中しやすい点にある。それでも2人いれば「いま何をやっているか」を互いに確認できるため、属人化による停止リスクはゼロより大幅に下がる。

3人構成の場合

3人にするなら、FDE本体2名と調整担当1名が理想的だ。FDE2名がいると、技術的なレビューが内部でできるようになり、コードや設計の品質が安定する。

FDEに必要なスキルセットでも触れているとおり、FDEには開発力と業務理解の両方が必要だが、その比率は人によって異なる。データ処理系に強い人とAPI連携・フロント実装が得意な人を組み合わせると、対応できる案件の幅が広がる。

FDE人材をどこから調達するか

外部採用

最初の1名を外部から採用することが、立ち上げ速度を高める最短ルートだ。社内の人材を育てるより即戦力になるまでの時間が短く、チーム発足直後の成果を作りやすい。

採用市場でFDEという肩書きを持つ人材はまだ少ない。探す際は「エンジニアリングコンサルタント」「ソリューションエンジニア」「テクニカルプロジェクトリード」などの職歴を持ち、クライアント現場での実装経験が1年以上ある人材を候補にするといい。

採用する際に重視すべき点は、特定のフレームワークや言語への習熟よりも、「初対面の業務担当者からヒアリングして要件に落とし込み、動くものを2週間以内に見せられるか」という実行力だ。面接より実技課題で判断したほうが精度が高い。

社内転籍

社内に「業務経験があってコードも書けるシステム担当者」が存在する場合、転籍が最もリスクの低い選択肢になる。現行業務を知っているため現場からの信頼を得やすく、社内の調整コストも低い。

転籍の候補は、事業系システム担当・情報システム部門のリード・社内DXプロジェクトの担当者などだ。ただし現業務から完全に切り離せない場合、兼務状態になってFDEとしての稼働が半減する。転籍する場合は現業務との切り離しを人事・上司と合意してから動かすことが条件になる。

社内育成

長期的には社内育成が必要になるが、立ち上げ段階の主力にするのは難しい。開発経験のある社員をFDE化するには、実務プロジェクトへのアサインを繰り返しながら6〜12か月の育成期間を見るのが現実的だ。

育成を加速させる方法の一つは、外部採用したFDEと組ませることだ。プロジェクトを並走しながら実装・折衝・振り返りを繰り返すことで、教室での研修より速く実力がつく。AIを社内に浸透させる30日計画のような段階的な推進手順と組み合わせると、チーム全体の底上げにつながる。

既存IT部門・DX部門との役割分担の整理

FDEチームを設置する際に最も摩擦が起きやすいのが、既存部門との役割の重なりだ。「それはうちの仕事では？」という反応は、事前の役割分担の合意がないと必ず出てくる。

3部門の役割を一覧にする

役割	IT部門	DX推進部門	FDEチーム
インフラ・セキュリティ	担当	関与しない	相談する
全社AIツールの標準化	調達を担う	方針を決める	関与しない
社員向けAI研修	環境整備	企画・実施	必要に応じ協力
特定業務への実装	要件が来たら対応	事例収集	主担当
現場ヒアリングと要件定義	関与しない	全社方針のみ	主担当

この表の核心は「特定業務への実装と現場ヒアリングはFDEチームが主担当になる」という一点だ。IT部門は要件をもらって動く形であり、FDEチームが上流から関与することが他部門との差別化になる。

最初の合意は役員を交えて取る

役割分担の合意は、チームメンバー同士ではなく、スポンサーとなる役員を含めた場で取ることが重要だ。現場レベルでの合意は、後から「そんな話は聞いていない」という状況になりやすい。役員が立ち会った場で役割を明文化しておくことで、後々の摩擦が大きく減る。

予算の目安と調達方法

2〜3人チームの年間予算

2〜3人のFDEチームで年間2,000〜3,500万円が目安だ。内訳は以下のとおり。

費目	目安（年間）
人件費（2〜3人）	1,600〜2,800万円
AIツール・SaaS費	120〜360万円
外部委託・スポット支援	200〜400万円
その他（機器・研修等）	50〜100万円
合計	1,970〜3,660万円

人件費の幅は採用方法と職種レベルによる。外部からシニアFDEを採用する場合は年収800〜1,200万円の水準になることが多く、社内転籍なら現行水準をベースに調整する形になる。

ツール費は生成AIのAPIアクセス・プロトタイプ開発環境・デプロイ用クラウドなどで月10〜30万円程度が一般的だ。ただし本番環境での運用が始まると、API利用量によってはこの数倍になることもある。

予算取りのタイミングと方法

立ち上げ費用を経営会議で承認を取る際、最も通りやすいのは「パイロット3か月で効果検証」というフレームだ。年間予算を一括で求めるより、最初の3か月分だけを申請して成果を示し、追加予算を確保する形のほうが承認されやすい。

3か月のパイロット予算は400〜600万円を目安にする。この金額なら事業部門の年間予算で吸収できる規模であり、IT投資の意思決定を待たずに動けるケースも多い。

最初の90日間でやること

パイロット案件の選び方

最初の案件選びは、チームの存在意義を証明するうえで最も重要な判断だ。成功しやすい案件には4つの条件がある。

担当者が「困っている」と言葉にして言える業務であること
現状の処理時間や件数が数値で測れること
90日以内に動くものを見せられるスコープであること
成果が外から見えやすいこと（担当者以外にも影響が伝わること）

この4条件を満たす業務は、多くの企業で「データの転記・集計」「繰り返し発生する文書作成」「社内問い合わせ対応」などに見つかりやすい。複数の案件候補があれば、担当者が最も積極的に協力してくれそうな案件を選ぶ。協力的でない現場では、どれだけ技術的に優れた解決策を作っても定着しない。

日本でFDEが求められる理由でも指摘しているとおり、日本の現場では「現場が使いやすいか」という観点が定着を左右する最大要因だ。FDEチームの最初のプロジェクトでは、技術的な挑戦より使われる確度を優先したほうが、後の展開が速くなる。

90日の行動計画

期間	主な活動
1〜4週目	案件選定・現場ヒアリング・要件定義・プロトタイプ着手
5〜8週目	プロトタイプ完成・現場フィードバック・修正・本番環境への移行準備
9〜12週目	現場での運用開始・効果測定・次案件の候補選定

4週目の時点でプロトタイプが動いていない場合は、スコープを削る判断が必要だ。「動くもの」が存在することが信頼の源泉であり、完璧に作ることより早く見せることを優先する。

12週目に向けて準備すべきは、効果の数値化と次案件の候補リストだ。「処理時間が週あたり何時間削減できたか」「担当者の残業時間は変化したか」を数値で示せれば、次の予算申請と案件拡大の根拠になる。

まとめ

FDEチームの立ち上げは段階的な積み上げで進む。最初から完全な体制を作ろうとすると承認が通りにくくなり、完璧なツール環境を整えようとすると本来やるべき現場作業が後回しになる。

2〜3人で始め、90日でパイロット案件を完遂し、数値で成果を示す。この一連の流れを最初のサイクルとして回せれば、チームへの投資は自然と拡大していく。FDEチームが社内で信頼を得るのは、プレゼンテーションではなく動くものを見せた瞬間からだ。