DX内製化の進め方|FDE型で内製チームを立ち上げる5段階と失敗回避の実務

- 1. 対象業務の特定全社ではなく、繰り返し発生し数値で効果を測れる業務を1つ選ぶ
- 2. データと権限の整備対象業務のデータ所在・更新責任・アクセス権限を自社側で定義する
- 3. 小さく作って現場で使う現場担当者が実業務で触れる範囲まで作り、使われるかを短期で検証する
- 4. 成果指標の合意工数削減・リードタイム・エラー率など、経営と現場が同じ指標で評価する
- 5. 型化と横展開作り方・運用手順・レビュー基準を文書化し、次の業務領域へ再利用する
- 要件が頻繁に変わり、現場と対話しながら作り替える業務
- 自社の競争優位に直結する業務ロジックやデータの扱い
- 運用開始後も継続的な改善が前提になる仕組み
- 仕様が固まり、変更が少ない定型システムの構築
- 自社に知見がなく、短期で立ち上げが必要な専門領域
- 一過性の移行作業やピーク時の増員が必要な工程
DXの内製化とは何で、なぜ今その進め方が問われるのか?
DX内製化とは、要件定義から運用までの意思決定を自社に取り戻す組織設計であり、外注ゼロを意味しない。
内製化は「外注ゼロ」ではなく判断の所在を移すこと
内製化の本質は、変更のたびに外部見積もりを待たず、自社で判断して直せる状態をつくることにある。
内製化を「開発リソースを社内に持つこと」と定義すると、採用と要員数の話に矮小化されやすい。実務上の分かれ目は人数ではなく、誰が仕様を決め、誰が直すかを決められるかにある。コードを外部に書いてもらっていても、業務仮説と優先順位を自社で持ち、修正の是非を自社で判断できていれば、内製化の実質は成立している。逆に、社内にエンジニアが十数名いても、要件を業務部門が固めて渡すだけの体制なら、意思決定は外注時代と変わらない。
経済産業省「DXレポート」(2018年)が提起した「2025年の崖」以降、レガシー刷新と人材配置の議論は続いてきた。IPA「DX白書」でも、日本ではIT人材がユーザー企業側より外部ベンダー側に偏っている構造が繰り返し指摘されている。この偏りが、意思決定の外部依存という形で残り続けているのが現状の課題である。
なぜ2026年時点で「進め方」が問われるのか
背景は生成AIによる開発速度の変化と、外注前提では業務変更に追従できないという現実の二つにある。
生成AIによってコード生成の速度は上がったが、上がったのは「作る速度」だけである。何を作るべきかを決める速度、作ったものを業務に組み込む速度は、業務知識を持つ人がどれだけ手を動かせるかに依存する。つまり、実装コストが下がるほど、ボトルネックは業務理解と意思決定に移る。ここが内製化の進め方が改めて問われている理由だ。
現場の感覚として、生成AIを導入した組織で最初に露呈するのは「作れるが決められない」状態である。プロトタイプは週内に出るのに、それを本番業務に載せる判断が数か月止まる。この非対称を解消する設計が、内製化の実務的な目的になりつつある。
FDE型という選択肢は何が違うのか
FDE型は、顧客の業務現場に入り込み、要件定義から実装・運用までを一人称で担う働き方を指す。
FDE(Forward Deployed Engineer)はPalantir Technologiesが広めた職種概念で、エンジニアが業務側に前方展開し、業務理解と実装を分離せずに担う点が特徴である。従来の内製化が「発注側の要件定義力を上げる」方向だったのに対し、FDE型は要件定義と実装の境界そのものを消すアプローチだと整理できる。DX内製化の文脈では、この境界の消去が意思決定の速度に直結する。
DX内製化の進め方は、どの順番で何をすればよいのか?
内製化は「棚卸し→試作→標準化→運用移管→自走」の5段階で進め、各段階に出口条件を設けるのが要点となる。
5段階の全体像と出口条件
5段階は暦の期間で区切らず、次に進んでよい出口条件を満たしたかどうかで判定するのが実務的だ。
| 段階 | 名称 | 中心となる問い | 出口条件(例) | 目安期間 |
|---|---|---|---|---|
| 1 | 課題の棚卸し | どの業務の変更頻度が高いか | 対象業務3〜5件を影響度と変更頻度で順位付け | 2〜4週 |
| 2 | 最初の一本 | 自分たちで直せる実感が持てるか | 1業務で本番稼働し、社内メンバーが修正を1回完遂 | 4〜8週 |
| 3 | 型の標準化 | 二本目を安く作れるか | 環境・認証・データ接続が再利用可能な形で共通化 | 2〜3か月 |
| 4 | 運用移管 | 障害対応を自社で回せるか | 運用手順・監視・当番が社内に存在し外部待ちがゼロ | 2〜3か月 |
| 5 | 自走 | 依頼がなくても改善が回るか | 業務部門起点の改善が月次で継続的に発生 | 継続 |
第1〜2段階:棚卸しと「最初の一本」
最初の2段階の目的は成果ではなく、社内に「自分たちで直せた」という実感を残すことにある。
第1段階では、業務を「変更頻度」と「業務知識の密度」で並べる。ここで全社の業務地図を描き切ろうとすると数か月が溶けるため、対象は3〜5件に絞るのが現実的だ。第2段階の題材選定では、次の3条件を満たすものを選ぶ。
- 業務担当者が同席できる:週1時間でも定例で捕まる相手であること
- 成否が数字で見える:処理時間、手戻り件数、問い合わせ数など既存の指標があること
- 止まっても業務が死なない:初回は必ず想定外が出るため、代替手段が残る領域を選ぶ
現場で最も効いたのは3番目の条件だという印象がある。基幹の心臓部を最初の一本に選ぶと、障害を恐れて意思決定が外部レビュー待ちに戻り、内製化の学習が起きない。
第3〜5段階:標準化・運用移管・自走
後半の3段階は、一本の成功を再現可能な型にし、運用と改修の責任を自社側へ移していく工程である。
第3段階では、二本目の立ち上げコストを一本目の半分以下にすることを目標に置く。認証、データ接続、デプロイ、監視といった非機能部分をテンプレート化し、業務ロジックだけを書けば動く状態をつくる。第4段階では運用当番と障害対応手順を社内に移す。ここを飛ばすと「作るのは内製、直すのは外注」という中途半端な構造が固定化する。第5段階の判定基準は、依頼票なしで改善が起きているかの一点に集約できる。
内製と外注はどう使い分けるべきか?
内製と外注は「変更頻度」と「業務知識の密度」で切り分け、判断が要る領域だけを自社に残すのが原則だ。
判断軸は変更頻度と業務知識の密度
変更頻度が高く業務知識の密度も高い領域は、外注では往復コストが利益を食い潰しやすい。
外注が非効率になるのは、単価が高いからではなく確認の往復が発生するからである。仕様が固まらない領域では、1回の変更に見積もり・承認・実装・検収の4往復が乗る。月に何度も変わる業務でこれを続けると、実装工数より調整工数が大きくなる。この構造を数える指標として、「1変更あたりの意思決定待ち時間」を測っておくと使い分けの判断がしやすい。
外部調達のほうが合理的な領域
認証基盤や監視、汎用SaaS連携のように仕様が安定した領域は、外部調達のほうが合理的になりやすい。
| 領域の性質 | 推奨 | 理由 |
|---|---|---|
| 業務ロジック・データ定義・優先順位づけ | 内製 | 変更頻度が高く、暗黙知が仕様に直結する |
| 現場ヒアリングと業務設計 | 内製 | 外部化すると解釈のズレが仕様に埋め込まれる |
| 認証・監視・CI/CDなど共通基盤 | 外部調達(SaaS優先) | 仕様が安定し、自作の差別化余地が小さい |
| 大規模なデータ移行・一時的な負荷 | 外注 | 期間限定でスキルの常時保有が不要 |
| 専門領域(法規制対応・高度セキュリティ) | 外注+社内窓口 | 常時稼働の専門人材を抱えるコストが見合わない |
契約と知識移転をどう設計するか
外注を使う場合も、成果物にドキュメントとレビュー参加を含め、知識が社内に残る契約設計にする。
具体的には、①設計判断の理由を記した文書を成果物に含める、②社内メンバーがコードレビューに参加する、③運用手順の引き継ぎ会を検収条件にする、の3点を契約に書き込む。「動くもの」だけを成果物にすると、契約終了時に判断の根拠が社外に残り、内製化が一段階戻る。
内製化を支える組織と人材はどう設計するのか?
組織設計の要は、業務に踏み込む「FDE型」と共通基盤を守る役割を分け、責任の重複をなくすことにある。
必要な3つの役割
内製チームには、業務に入り込むFDE型、意思決定を担う責任者、基盤を整える担当の3種が必要になる。
- FDE型エンジニア:業務現場に常駐的に関与し、ヒアリングから実装・改修まで担う。内製化の速度はこの役割の人数と稼働率でほぼ決まる
- プロダクトオーナー(業務側):優先順位と「やらないこと」を決める。ここが空席のまま進むと、要望リストが際限なく伸びる
- プラットフォーム担当:認証・環境・監視・データ基盤を整える。第3段階以降の再現性を支える
初期に人数が足りない場合、FDE型とプラットフォーム担当の兼務は一時的に成立するが、プロダクトオーナーの兼務は避けたほうがよい。決める人が手を動かし始めると、決定が後回しになる。
採用と育成の二経路
人材は外部採用だけに頼らず、業務を知る社内人材にエンジニアリングを足す経路も同時に開くとよい。
FDE型に必要なのは、業務理解・実装力・対話力の3点である。外部採用では実装力を持つ人を採って業務理解を足す経路、社内育成では業務理解を持つ人に実装力を足す経路になる。後者のほうが立ち上がりが速いケースは少なくない。業務の勘所と社内の人間関係は、外から短期間では獲得しにくい資産である。
育成では、講座受講よりペア作業のほうが効果が出やすい。実際の業務課題を題材に、経験者と2人で1つの改善を最後まで通す形式が、最初の一本を教材化する最短経路になる。
評価とキャリアパスをどう置くか
評価は納品量ではなく、業務指標の改善幅と、他部署へ再利用された資産の量で測る設計にしたい。
FDE型は「業務側に貢献したが、技術的には地味」という成果を出しやすく、通常のエンジニア評価軸では過小評価されがちである。逆に、業務に踏み込むほど技術キャリアから遠ざかるという不安も生じる。評価軸に「業務指標の改善」と「再利用された共通資産」を明記し、専門職としての昇進ラインを技術職と同格に置くことが、離職を防ぐ実務的な手当てになる。
DX内製化はなぜ失敗するのか、どう防げばよいのか?
内製化の失敗は技術力不足より、目的の曖昧さと人の張り付け不足という体制側の問題から起きやすい。
典型的な5つの失敗パターン
典型的な失敗は、目的不明・兼務過多・属人化・PoC止まり・運用放置の5つに分類できる。
| 失敗パターン | 現場に出る兆候 | 打ち手 |
|---|---|---|
| 目的が曖昧 | 「DX推進」が目標のまま、成功指標が言語化されない | 対象業務の既存指標を1つ選び、改善幅で合否を定義する |
| 兼務過多 | 内製メンバーの実稼働が週1〜2日に留まる | 最低でも稼働の5割を確保。確保できないなら着手を延期する |
| 属人化 | 1人しか触れない仕組みが増える | レビュー必須化と、他者が1回改修する運用を出口条件に置く |
| PoC止まり | 検証は成功するが本番に載らない | 着手時点で本番移行の承認者と条件を確定させる |
| 運用放置 | 稼働後の改善が止まり、Excel運用に戻る | 運用当番と月次の改善枠を業務側の工数に組み込む |
このうち実務で最も多いと感じるのは兼務過多である。予算も承認も通っているのに、担当者が既存業務を抱えたまま週半日だけ動く体制になり、学習が積み上がらない。技術的な難易度よりも、稼働の確保が成否を分けている印象が強い。
先行指標で早期に検知する
失敗は結果が出る前に、レビュー滞留や質問数の減少といった先行指標に現れることが多い。
監視すべき先行指標は次の4つである。①内製メンバーの実稼働時間、②業務部門からの質問・要望の件数、③レビューの平均滞留日数、④外部への確認待ち件数。とくに②が減り始めたときは注意が要る。要望が来ないのは満足の証ではなく、業務側が期待を諦めた兆候であることが多い。
続けるか畳むかの基準を先に決める
続けるか畳むかは着手前に基準を決め、成果が出ない場合の縮小手順まで合意しておくのが安全だ。
第2段階の終了時点で、①本番稼働したか、②社内メンバーが単独で1回修正できたか、③業務指標が動いたか、の3点を判定する。3つとも未達なら、対象業務の選定か稼働確保のどちらかに問題がある。撤退基準を先に決めておくと、「投資したから続ける」という判断のこじれを避けられる。内製化は一度で完成させるものではなく、対象を替えて再挑戦できる形に設計しておくことが、長期的な成功確率を上げる。
(本稿は現場実務者の観察に基づく草稿であり、公開前に監修者の確認を経ています。制度・統計に関する記述は経済産業省「DXレポート」およびIPA「DX白書」の公開情報に基づきます。)





