DX推進チームの立ち上げ方｜3つの組織パターンと必要スキルの全体設計
株式会社TIMEWELLの濱本です。
「DX推進の専任組織を作れ」。経営トップからこの指示を受けたCTOやCDO、あるいは経営企画の方は少なくないはずです。ただ、「組織を作れ」と言われても、何人で、どんなスキルを持った人材を、どう配置すればいいのか。設計図がなければ、形だけのチームになって終わります。
IPAの「DX動向2025」によれば、日本企業の85.1%がDX推進人材の不足を感じている。米国の23.8%、ドイツの44.6%と比べると圧倒的に足りていません。経済産業省は2030年までに最大79万人のIT人材が不足すると推計しています。外から人を採ってくるだけでは解決しない。社内の人材を育てながら、外部の知見も取り込む組織設計が求められます。
DX推進チームの3つの組織パターン
組織形態は大きく3つに分かれます。自社の規模、DXの成熟度、経営の優先度に応じて選んでください。
パターン比較表
| 項目 | 集約型（CoE） | 分散型 | ハイブリッド型 |
|---|---|---|---|
| 体制 | 経営直下に専任チームを設置 | 各事業部にDX担当者を配置 | 中央チーム＋各事業部の兼任者 |
| 人数の目安 | 5〜15名（専任） | 事業部あたり1〜2名（兼任含む） | 中央3〜5名＋各部1〜2名 |
| 意思決定 | 中央集権的、トップダウン | 各部門で自律的に判断 | 方針は中央、実行は部門 |
| 推進スピード | 速い（全社横断で動ける） | 部門ごとにばらつきあり | 中程度（調整コストが発生） |
| 現場との距離 | 遠くなりがち | 近い | 中程度 |
| ナレッジ共有 | チーム内で完結しやすい | 部門間で分断されやすい | 中央が横串で共有を促進 |
| 適する企業規模 | 大企業（従業員1,000名以上） | 中堅企業、事業部制の企業 | 中堅から大企業 |
| 適するDX成熟度 | 初期から中期 | 中期から成熟期 | 初期から成熟期 |
| リスク | 現場と乖離する「象牙の塔」化 | 全社統制が効かず品質がばらつく | 役割分担が曖昧になる |
集約型（CoE）
経営直下にDX推進の専任組織を設置し、全社のDX施策を一元管理するモデルです。Center of Excellenceの略でCoEと呼ばれます。
向いている企業は、DXの初期段階で全社的な方針統一が必要なケース、経営トップが強いコミットメントを持っているケース、デジタル人材が限られており集中配置したいケースです。
気をつけたいのは、現場の業務を知らないメンバーだけで構成しないこと。そうなると「机上の空論」で終わります。現場経験のあるメンバーを必ず含めてください。事業部門から「あの部署は何をやっているのか」と思われた時点で、推進力は半減します。
分散型
各事業部門にDX推進の担当者を置き、部門ごとに自律的にDXを進めるモデル。
向いているのは事業部門の独立性が高い企業、各部門が独自の業務課題を抱えている企業、DXの成熟度がある程度進んでいる企業です。
ただし、全社で統一すべきルールは中央で策定しなければなりません。セキュリティポリシー、ツール選定基準、データガバナンスの3つは最低限。各部門が好き勝手にツールを導入すると、セキュリティリスクやコストの無駄が発生します。
ハイブリッド型
中央にコアチームを置きつつ、各事業部門にDX推進の兼任者を配置するモデル。私は多くの企業にとって、最もバランスが取れた選択肢だと考えています。
向いているのは、部門横断の施策と部門固有の施策を両方進めたい企業、中央チームの人数に限りがある企業です。
注意点は1つ。中央チームと事業部担当者の役割分担を明文化すること。「誰がどの意思決定をするのか」が曖昧だと、責任の押し付け合いか、逆にどちらも手を出さない空白地帯が生まれます。
必要スキルマトリックス
DX推進チームに必要なスキルを、経済産業省とIPAの「デジタルスキル標準」を参考に整理します。
人材類型と必要スキル
| 人材類型 | 主な役割 | 必要スキル | 社内調達 | 外部調達 |
|---|---|---|---|---|
| ビジネスアーキテクト | DX戦略の立案、業務設計 | 経営戦略の理解、業務プロセス設計、ステークホルダー調整 | 経営企画や事業企画出身者 | 戦略コンサル |
| プロジェクトマネージャー | 施策の推進管理 | プロジェクト管理、リスク管理、ベンダー管理 | IT部門やPMO出身者 | PM専門人材 |
| データサイエンティスト | データ分析、AI活用 | 統計解析、機械学習、ビジネスインサイト抽出 | 分析部門出身者 | データ分析会社 |
| ソフトウェアエンジニア | システム構築、ツール連携 | クラウド、API連携、セキュリティ | 開発部門出身者 | SIerやフリーランス |
| UXデザイナー | ユーザー体験の設計 | ユーザーリサーチ、プロトタイピング | デザイン部門出身者 | デザイン会社 |
| チェンジマネージャー | 組織変革の推進 | 社内コミュニケーション、研修設計、抵抗管理 | 人事や広報出身者 | 組織コンサル |
スキルの優先順位
すべてのスキルを初日から揃える必要はありません。立ち上げ期に最低限必要なのは3つ。
- ビジネスアーキテクト。何をやるかを決める人。DX戦略と業務課題をつなげられる人材
- プロジェクトマネージャー。やると決めたことを推進する人。スケジュールと品質を管理する
- チェンジマネージャー。変革に対する現場の抵抗を管理し、社内の巻き込みを推進する人
技術系の人材、つまりデータサイエンティストやエンジニアは外部パートナーで補完できます。ビジネス側の人材は社内から出さなければ機能しません。自社の業務と組織を理解している人間でなければ、現場に刺さる施策は設計できない。ここは妥協しないでほしい。
チームメンバーの選定基準
「誰をアサインするか」は、DX推進チームの成否を決める最大の変数です。
選ぶべき人材の特徴
| 特徴 | 理由 | 見極め方 |
|---|---|---|
| 現場経験がある | 業務課題を肌感覚で理解している | 直近3年以内に現場業務に従事した経験 |
| 部門横断の調整ができる | DXは複数部門にまたがる | 過去に部門横断プロジェクトに参加した経験 |
| 変化を恐れない | 前例踏襲では変革は起きない | 新しい取り組みを自ら提案・実行した実績 |
| 学習意欲が高い | 技術は常に進化する | 自主的に勉強会や資格取得に取り組んでいる |
| 経営視点を持っている | DXは経営課題 | 事業のP/Lや競争環境を語れるかどうか |
避けるべきアサインパターン
ここは辛口で書きます。
「余剰人員の受け皿」にするのは最悪の選択です。「手が空いている人」を集めてもDXは進まない。それならチームを作らないほうがまし。
IT部門だけで構成するのも失敗の典型。技術視点に偏り、ビジネス成果につながりません。
兼任比率が高すぎるのも問題。本業が忙しくなるとDXが後回しになる。最低でもリーダーは専任にしてください。
12か月の立ち上げロードマップ
DX推進チームの立ち上げから成果創出までの12か月を、4つのフェーズに分けます。
Phase 1：準備期（1〜2か月目）
| タスク | 担当 | アウトプット |
|---|---|---|
| DX戦略の策定 | 経営層＋ビジネスアーキテクト | DX方針書（3〜5ページ） |
| 組織形態の決定 | 経営層 | 組織図、レポートライン |
| メンバーの選定とアサイン | 人事＋経営層 | チーム編成表 |
| 外部パートナーの選定 | PM | 契約書、SLA |
| 現状分析（業務課題の棚卸し） | 全メンバー | 課題一覧と優先順位表 |
ゴールは、チームの体制が確定し、最初に取り組むテーマが決まっている状態です。
Phase 2：実証期（3〜5か月目）
| タスク | 担当 | アウトプット |
|---|---|---|
| PoCテーマの選定と設計 | ビジネスアーキテクト＋PM | PoC計画書 |
| PoCの実施 | 技術メンバー＋現場担当 | 検証結果レポート |
| 効果測定と判断 | PM＋経営層 | Go/Stop判断資料 |
| 社内への中間報告 | チェンジマネージャー | 報告資料、社内広報 |
| 第2テーマの検討開始 | ビジネスアーキテクト | テーマ候補リスト |
ゴールは、最低1つのPoCが完了し、本番導入の判断ができている状態。
Phase 3：展開期（6〜9か月目）
| タスク | 担当 | アウトプット |
|---|---|---|
| PoCで検証済み施策の本番導入 | PM＋技術メンバー | 運用マニュアル、導入完了報告 |
| 対象部門への研修と説明会 | チェンジマネージャー | 研修資料、FAQ |
| KPIモニタリングの開始 | PM | 月次レポート |
| 第2テーマのPoC開始 | 全メンバー | PoC計画書 |
| 成功事例の社内共有 | チェンジマネージャー | 事例集、社内メディア |
ゴールは、1つ目の施策が本番運用に入り、2つ目のPoCが進行中であること。成功事例が社内に共有されている状態です。
Phase 4：定着期（10〜12か月目）
| タスク | 担当 | アウトプット |
|---|---|---|
| 年間成果の集計と報告 | PM | 年次報告書 |
| 次年度DX計画の策定 | ビジネスアーキテクト＋経営層 | 次年度計画書 |
| チーム体制の見直し | 経営層＋人事 | 改定組織図 |
| ナレッジの体系化 | 全メンバー | DXプレイブック |
| 社内人材育成プログラムの設計 | チェンジマネージャー | 育成計画書 |
ゴールは、初年度の成果が定量的に報告され、2年目の計画と体制が承認されている状態。ここまで来れば、チームの存在意義は社内に認知されているはずです。
立ち上げ時のよくある壁と乗り越え方
壁1：「DXって何をすればいいのか分からない」
DX推進チームに配属された直後、メンバーの多くが感じる不安です。
対策はシンプルで、最初の2か月で具体的なテーマを1つ決め、小さな成果を出す。大きなビジョンは後から語ればいい。「これをやりました、こう変わりました」という実績が、チームの自信とモチベーションを生みます。
壁2：「現場から協力が得られない」
DX推進チームが現場に「新しいツールを使ってください」と依頼しても、「忙しいのに余計な仕事を増やすな」と拒否される。よくある話です。
乗り越え方は2つ。1つは、現場が感じている困りごとを起点にすること。「このツールを使え」ではなく「この困りごとを解決するためにこういう方法がある」というアプローチに変える。もう1つは、協力的な部門から始めること。全部門を同時に動かそうとせず、味方になってくれる部門で成果を出し、それを横展開するほうが現実的です。
余談ですが、私がこれまで見てきた中で、現場の協力を一番うまく引き出していたDX推進リーダーは、元営業部長の方でした。「数字で語れる」「現場の痛みが分かる」「人脈がある」の三拍子が揃っていた。技術力よりも、こうした現場との接点を持つ人がリーダーに向いていると思います。
壁3：「経営層の関心が薄れる」
立ち上げ時は注目されていたのに、半年も経つと経営会議でDXの話題が出なくなる。
対策は、月次で定量的な進捗を経営層に報告すること。「何件のPoCを実施し、何時間の業務削減を達成し、次は何に取り組むか」を数字で示す。報告がなければ関心は薄れます。毎月具体的な数字を出し続ければ、経営層の支援は継続する。報告書を作る手間を惜しんではいけません。
まとめ
DX推進チームの立ち上げで考えるべきことは多いですが、最初の一手は組織パターンの選定です。集約型、分散型、ハイブリッド型のどれが自社に合うかを決めてください。迷ったらハイブリッド型から始めるのが無難です。
組織パターンが決まったら、ビジネスアーキテクト、PM、チェンジマネージャーの3名を確保する。技術は外部で補える。この3名の質がチームの命運を握ります。
12か月で最低1つの本番導入と成果報告を達成すること。それがチームの存続と2年目以降の予算確保を決めます。DX推進チームは「作って終わり」ではなく、成果を出し続けることで社内での存在意義を証明する組織。最初の1年が勝負です。
TIMEWELLのWARPでは、DX推進チームの立ち上げから運用まで、組織設計、人材育成、施策推進を一気通貫で支援しています。元大手企業でDXやデータ戦略を推進してきた専門家が、御社の組織状況に合わせたチーム設計と立ち上げロードマップを一緒に作ります。組織形態の選定で迷っている、メンバーのスキル要件を整理したいといった段階から、お気軽にお問い合わせください。