大手コンサルの Forward-Deployed Engineer（FDE）が半年常駐し、社内 ChatGPT 環境と Copilot 連携を組んでくれた。契約が終わって FDE は去った。導入は済んだはずなのに、社内では相変わらず「AIってどう使うんですか？」の声が消えず、経営会議では「投資対効果は？」と問われる。DX 推進担当のあなたは、去った後の空白を1人で埋める形になっていないでしょうか。
FDE モデルは「作って入れる」までを担うのが仕事です。現場で使いこなされる状態を作るのは、契約の範囲外であることが多いです。ここでは、FDE が去った後の空白を、社内でどう埋めていくかを整理します。
FDE が担う領域と、担わない領域
FDE の役割を正確に理解しておくと、去った後に何が残り、何が残らないかが見えます。
| 領域 | FDE が担う | FDE が担わない |
|---|---|---|
| システム構築 | AI環境の設計・実装・連携 | — |
| データ連携 | API接続、権限初期設計、ETL構築 | 運用中のマスタ更新、業務変更への追随 |
| 初期教育 | 使い方研修、初期プロンプト集の提供 | 現場担当者の習熟、離脱者の再接続 |
| 運用体制 | 初期運用ルールの提案 | 推進担当の育成、部門ごとの浸透管理 |
| 成果追跡 | KPI 指標の提案 | 月次レポート運用、経営層への同期 |
導入プロジェクトが3〜6ヶ月で終わる場合、「作って入れる」までしか進みません。FDE が「システム側は動きます、あとは社内でお願いします」と引き継いだ状態が、多くの企業のスタート地点です。
FDE 引き継ぎで最初に確認する3点
FDE が去る前後で、社内で最初に確認すべきことがあります。契約終了までに揃っていれば理想ですが、抜けている場合はここから作ります。
| 確認事項 | 揃っている状態 | 抜けている場合の初動 |
|---|---|---|
| 運用ドキュメント | システム構成図、権限一覧、API仕様、マスタ更新手順 | 情シスと一緒に3週間で構築 |
| 初期Playbook | 業務別プロンプト集10〜20件、失敗パターン集 | 部門ヒアリングから初版を1ヶ月で作成 |
| 推進体制 | 情シス側の担当、業務側の推進担当、経営スポンサー | 経営から任命、兼任1名なら階層化を早急に |
空白を埋める組織設計：3層の推進体制
FDE が担っていた「日々の質問対応」を情シスの兼任1名で引き取ろうとすると、確実に破綻します。相談が滞留し、現場は諦め、浸透が止まる。これを避ける組織設計が、3層の推進体制です。
| 層 | 担い手 | 責任範囲 |
|---|---|---|
| 第1層 | 部門ごとの社内推進役1〜2名 | 現場の一次対応、プロンプトの初歩相談、業務別Playbook更新 |
| 第2層 | 推進役同期会（月2〜3回） | Playbook共有、成功事例の横展開、共通課題の抽出 |
| 第3層 | 情シスの専任担当 | システム連携相談、権限変更、外部業者との折衝 |
推進役の1層目は「業務が本業、AI推進は兼任20%」でも回ります。ここが手厚くなれば、情シスの負荷は劇的に下がります。多くの企業で情シスが疲弊するのは、第1層が空欄で相談が全部第3層に届いているためです。
Playbook 継承の実務
FDE が残した初期 Playbook を、社内で使い続けるものにするには、更新の仕組みが必要です。放置すれば陳腐化し、6ヶ月後には誰も見なくなります。
| 継承のポイント | 実務 |
|---|---|
| 更新オーナー | 部門ごとの社内推進役を Playbook のオーナーに指名、週次で1件は更新 |
| 成功事例の追加 | 月次同期会で共有された成功プロンプトを、次月の Playbook 初回に追加 |
| 失敗パターンの追加 | 「試したが期待した回答にならなかった」ケースを匿名で共有、原因と回避策を Playbook 化 |
| フォーマット | Notion / Confluence / SharePoint など、貴社の情報共有基盤に合わせる。単発の PDF は避ける |
6ヶ月の引き継ぎロードマップ
FDE が去ってから安定運用まで、標準的には6ヶ月かかります。急ぎたい気持ちは分かりますが、推進役の育成と Playbook の更新サイクルが回るまでには、この程度の時間が必要です。
| 月 | 重点 | ゴール |
|---|---|---|
| Month 1 | 運用ドキュメントの棚卸し、抜けの補完 | システム構成図、権限一覧、マスタ更新手順が揃う |
| Month 2 | 推進役の選任と教育開始 | 部門ごとに1〜2名、経営から公式任命 |
| Month 3 | 3層の相談経路を稼働 | 情シスへの直接相談が半減する |
| Month 4 | Playbook の更新サイクル定着 | 月次同期会が回り、Playbook が週1件更新される |
| Month 5 | 浸透KPI の月次レポート化 | 経営層への月次同期が始まる |
| Month 6 | 自走体制の確立 | 外部の介入なしで浸透が進む状態 |
外部支援を使う場合の判断軸
引き継ぎを社内で完全に閉じるか、外部支援を挟むかは、次の3点で判断します。
| 判断軸 | 社内で閉じる | 外部支援を挟む |
|---|---|---|
| 推進担当の経験 | AI浸透の類似経験がある | 初めての推進、まわりに参考事例がない |
| 経営層の期待値 | 半年〜1年の時間軸で許容される | 四半期ごとに成果を求められる |
| 部門横断の複雑さ | 1〜2部門で完結する | 3部門以上、部門間の力学が複雑 |
経験のある推進担当が1人いれば、外部支援なしで進められます。初めての推進で四半期ごとに成果を問われる状態なら、外部の目を入れる方が短期的な安定性は上がります。
まとめ
FDE が担うのは「作って入れる」まで。去った後の空白を埋めるには、運用ドキュメントの棚卸し、3層の推進体制、Playbook 更新サイクル、6ヶ月の引き継ぎロードマップを持ちます。情シス兼任1名で引き取ろうとすると必ず破綻するので、経営から公式に推進役を任命する動きが、最初にして最重要です。
「うちの場合はどこから手をつけるべきか」の見立てを掴みたい場合は、AI浸透支援 by DE-STKのAI浸透スコア診断（2週間・25万円）が入口として使えます。現状の利用実態、構造的な原因、次に打つべき手の候補まで、社内の投資判断に耐える粒度でお出しします。
あわせて読みたい
- 生成AI導入後の「使われない」を解消する：現場浸透の設計と実装
- 生成AI浸透KPIの設計：アクティブ率・用途分布・成果指標の3層モデル
- AI浸透スコア診断に含めるべき10項目：入る前に確認する優先順位
- Microsoft Copilotが営業部門で使われない典型3パターンと構造的原因
よくある質問
Q. FDE が Playbook を残してくれませんでした。ゼロから作るしかないですか？
A. 完全にゼロではありません。FDE が触ったシステムの設定ファイル、権限一覧、業務別のプロンプト履歴（ChatGPT/Copilot のログ）から、初版の Playbook は復元できます。1ヶ月で20〜30プロンプトの初版を組む、というのが現実的なスコープです。
Q. 推進役の任命は経営から降ろすべきですか？現場から挙手させるべきですか？
A. 経営から公式に任命するのを推奨します。挙手制だと、推進役の「本業との優先度」が下がり、いざというとき手が動きません。経営スポンサーの承認と、業績評価への織り込みが両方あって、初めて推進役は動きます。
Q. 3層の相談経路を組んでも情シスへの相談が減らない場合、どこが原因ですか？
A. 第1層の推進役が、業務の忙しさで一次対応を後回しにしているケースがほとんどです。推進役の週次工数を明示的に確保（週2〜4時間）し、業績評価に反映する仕組みがないと、相談は情シスに集中し続けます。