LASSIC Media らしくメディア
DX推進組織(CoE)の作り方と役割
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- DX推進を現場任せにすると部門横断の意思決定が滞り、取り組みが属人化しやすくなります。
- CoE（推進組織）は経営層直下に位置づけ、ミッション・権限・人材・予算をセットで設計する必要があります。
- 立ち上げ期は内製人材の確保と外部の伴走支援を組み合わせる進め方が現実的な選択肢になります。
目次
DX推進に専任組織が必要な理由 — 部門横断・全社最適・属人化回避
DX推進組織（CoE）とは、全社のDXに関する意思決定と実行を横断的に担う専任チームを指します。IPA（情報処理推進機構）の調査では、経営者・事業責任者・技術者が集まって迅速に結論を出す体制の重要性が示されています*1。
DX推進を特定の部門やプロジェクトチームの片手間業務として進めると、部門をまたぐ課題への対応が遅れやすくなります。営業部門とシステム部門で優先順位が異なれば、どちらの意見を採るかを決める場が必要になるはずです。
専任組織を置かない場合、DXの知見が特定の担当者に集中しやすい点も見過ごせません。担当者が異動や退職をすると、それまでの検討経緯やベンダーとのやり取りが引き継がれず、取り組みが停滞するおそれがあります。
全社最適の視点も重要な論点です。各部門が個別にツールを導入すると、データ形式やシステム基盤がばらばらになり、後から統合しようとした際に大きな手戻りが生じかねません。部門横断で標準化を担う組織があれば、この種の重複投資を防ぎやすくなるでしょう。
CoEとは何か — DCoE・CCoEとの違い
CoE（Center of Excellence、センターオブエクセレンス）とは、特定分野の知見・人材・ノウハウを組織横断で集約する専門組織を指します。全社への展開を担う役割を持つ点が特徴です。DXの文脈では、経営戦略とIT実行の橋渡し役として位置づけられることが一般的です。
DX領域のCoEはDCoE（Digital Center of Excellence）と呼ばれることがあります。全社のデジタル戦略の立案・推進・標準化を担う組織という意味合いで使われる呼び方です。
クラウド活用に特化した組織はCCoE（Cloud Center of Excellence）と呼ばれます。クラウド基盤のガバナンス・セキュリティ基準・コスト管理を専門に扱う組織を指す言葉として使われています。
DCoEとCCoEは、扱う範囲の広さが異なると整理できます。DCoEは事業戦略や業務改革まで含めた全社のDXを扱う一方、CCoEはクラウド利用に関する技術的なガバナンスに範囲を絞る組織という違いです。自社の課題が経営戦略レベルなのか、クラウド運用の標準化レベルなのかによって、どちらの機能を優先するかが変わってくるでしょう。
CoEを検討する際の視点として、戦略・技術・人材という3つの軸で整理する考え方があります。戦略軸は全社のDX方針との整合、技術軸は基盤・ツールの標準化、人材軸は育成と配置を指す考え方です。3つの軸を一つの組織にどこまで統合するかは、自社の規模や既存体制によって判断が分かれる部分と言えます。
CoEが担う5つの役割 — 標準化からガバナンスまで
CoEの役割を整理すると、標準化・ナレッジ集約・人材育成・伴走支援・ガバナンスの5つに大別できます。それぞれの役割が独立しているのではなく、相互に関連しながら機能する点が特徴です。
標準化 — ツール・プロセスの重複投資を防ぐ
標準化とは、各部門が個別に選定しがちなツールや業務プロセスを、全社共通の基準に揃える活動を指します。同じ機能を持つツールを部門ごとに契約する事態を避け、コストと運用負荷の両面を抑える狙いがあります。
ナレッジ集約 — 部門間の知見を横展開する
ある部門で得られたDX推進の知見やベンダー選定の経験を、他部門にも展開できる形で蓄積する役割です。成功事例だけでなく、うまくいかなかった取り組みの背景も含めて記録しておくと、同じ失敗の繰り返しを防ぎやすくなります。
人材育成 — 事業部門のデジタル人材を底上げする
CoE自体が全社のDX案件をすべて実行するわけではありません。各事業部門がある程度自走できるよう、研修や実践機会を通じてデジタル人材を育成する役割も担います。
伴走支援 — 現場のプロジェクトに寄り添う
事業部門が個別のDXプロジェクトを進める際、CoEが企画段階から実行段階まで並走して支援する役割です。専門知識を持つCoEメンバーが加わることで、プロジェクトの立ち上がりを後押しできます。
ガバナンス — 全社基準の順守を担保する
セキュリティ基準やデータ管理ルールなど、全社で守るべき基準が現場のプロジェクトで守られているかを確認する役割です。スピードを優先するあまり基準が形骸化しないよう、事後確認だけでなく企画段階でのチェック機能を持たせる必要があるでしょう。
CoEの作り方 — 経営直下の設置からステップで整理
CoEを実際に立ち上げる際は、経営の位置づけを固め、ミッションを定義し、人材をアサインする順序で組み立てると進めやすくなります。そのうえで権限と予算を与え、事業部との連携モデルを決める流れが現実的です。
ステップ1：CIO・CDXO直下に位置づける
CIO（情報システムを統括する役員。Chief Information Officer）、あるいはCDXO（DXを統括する役員。Chief Digital Transformation Officer）が該当します。こうした経営層がトップダウンで推進する組織づくりが肝心だとされています*1。CoEを特定の事業部門の配下に置いてしまうと、他部門への働きかけに際して調整コストが発生しやすくなるためです。
ステップ2：ミッションと対象範囲を定義する
次に、CoEがどこまでの領域を担うのかを明文化します。全社のDX戦略立案まで担うのか、特定システムの標準化に絞るのかによって、必要な人員規模も変わってくるはずです。ミッションが曖昧なままでは、事業部門との役割分担で摩擦が生じかねません。
ステップ3：事業と技術の両面から人材をアサインする
要素技術については外部ベンダーを活用してもよいとされています。一方、事業を推進するアプリケーション開発は内部メンバー中心の体制にすると、組織の戦略や外部環境の変化に迅速に対応しやすくなります*1。CoEについても同様に、事業側の知見を持つ人材と技術側の知見を持つ人材の両方を組み込む設計が有効だと考えられます。
ステップ4：権限と予算を持たせ事業部との連携モデルを決める
CoEに意思決定権限と予算枠を持たせなければ、提案止まりの組織になってしまいます。各事業部門のプロジェクトに対してCoEがどこまで関与し、どこから先は事業部門の裁量に委ねるのかという連携モデルも、この段階で取り決めておく必要があります。
連携モデルには、CoEが主導してプロジェクトを直接推進する形と、事業部門が主導しCoEは標準化・審査で関与する形があります。全社共通のシステム基盤に関わる案件はCoE主導、個別業務に閉じた改善は事業部門主導というように、案件の性質で使い分けると運用しやすくなるでしょう。どちらの形を取るかを事前に基準化しておかないと、案件が発生するたびに調整コストが発生しかねません。
CoEが機能しない3つの失敗パターン
CoEを設置しても機能しない企業に共通するパターンとして、現場任せで経営が関与しない、権限が伴わない、評価制度が整っていないという3点が挙げられます。
失敗1：現場任せで経営層が関与しない
CoEの立ち上げを情報システム部門に一任し、経営層が方針を示さないまま進めてしまうケースです。この状態では、他部門への協力要請に説得力を持たせにくく、活動が形だけのものになりやすいでしょう。IPAの調査でも、経営層がトップダウンで推進する組織づくりの重要性が指摘されています*1。
失敗2：権限のない組織になってしまう
CoEを設置したものの、意思決定権限を持たせず提言機関にとどめてしまうパターンです。提言を事業部門が採用するかどうかは任意という状態では、標準化やガバナンスの実効性が乏しくなります。
失敗3：評価制度が未整備のまま活動を求める
CoEメンバーの人事評価が従来の部門評価のままで、横断活動の成果が正しく反映されない状態も失敗要因の一つです。評価制度が伴わなければ、優秀な人材がCoEへの異動を敬遠する事態にもつながりかねません。
内製化と外部活用を組み合わせる進め方
CoEの立ち上げ期には、社内に十分なDX人材が揃っていないという状況が珍しくありません。要素技術に関しては外部ベンダーを活用してもよいという考え方は*1、CoEの立ち上げ支援そのものにも当てはめて検討できるはずです。
CoEを内製だけで立ち上げる場合、DX戦略の設計・システム基盤の標準化・複数の事業部門との調整という異なる専門性を同時に確保する必要があります。専任メンバーを一から社内公募し育成する進め方は、成果が出るまでに一定の時間を要すると考えられます。
ここで外部の伴走支援を組み合わせると、標準化のノウハウや他社での知見を早い段階で取り込みやすくなります。立ち上げ期は外部パートナーと協働し、軌道に乗った段階で内部人材へ知見を移管していく進め方が現実的な選択肢の一つと言えるでしょう。
内製と外部活用の切り分け方については、事業を推進するアプリケーション開発は内部メンバー中心、要素技術は外部ベンダー活用という整理が一つの参考になります*1。CoEにおいても、全社の意思決定や事業部門との調整といった中核機能は内製で担うと考えやすくなります。システム基盤の設計・構築といった実装領域は、外部パートナーと分担する形が検討しやすいはずです。
外部パートナーを選ぶ際は、単発のシステム開発だけでなく、標準化の考え方や複数部門にまたがる調整の経験を持つ相手かどうかを確認する視点が欠かせません。CoEの立ち上げは一度きりのプロジェクトではなく継続的な活動であるため、長期的に伴走できる体制を持つパートナーかどうかも判断材料になるはずです。
まとめ：CoE設計で経営が握るべき3つの判断軸
本稿では、DX推進組織であるCoEの作り方を経営視点で整理しました。要点を3つに集約すると次の通りです。第一に、CoEはCIO・CDXOなど経営層直下に位置づけ、トップダウンで推進する組織づくりが肝心です。第二に、標準化・ナレッジ集約・人材育成・伴走支援・ガバナンスという役割を明確にし、権限と予算を伴わせなければ機能しません。第三に、立ち上げ期は内製人材の確保と外部の伴走支援を組み合わせることで、知見の蓄積を早めながら体制を軌道に乗せやすくなります。
よくある質問
CoEはどの部署の配下に置くのが適切ですか。
特定の事業部門の配下ではなく、CIOやCDXOなど経営層の直下に位置づける形が適切だと考えられます*1。事業部門の配下に置くと、他部門への働きかけに調整コストがかかりやすく、全社横断の機能を果たしにくくなるためです。
CoEとDX推進部の違いは何ですか。
呼び方の違いであり、明確な定義の線引きがあるわけではありません。CoEは特定分野の知見を横断的に集約する組織形態を指す一般的な用語で、DX推進部という名称の組織がCoEの機能を担っているケースも多く見られます。重要なのは名称よりも、権限・予算・ミッションが伴っているかどうかです。
CoEの立ち上げは何人規模から始めればよいですか。
公表されている一律の基準はなく、自社のミッション範囲と事業規模によって必要な人数は変わります。まずは事業側と技術側の両方の知見を持つ少人数のコアメンバーで発足し、活動範囲の拡大に応じて増員する進め方が検討しやすいでしょう。
CoEの活動を内製だけで完結させるのは難しいですか。
立ち上げ期は難しい場合が多いと考えられます。DX戦略の設計・システム基盤の標準化・複数部門との調整という異なる専門性が同時に求められるためです。要素技術は外部ベンダーを活用し、事業を推進する中核部分は内部メンバー中心で進める組み合わせが一つの考え方です*1。
CoEを設置しても失敗する企業に共通する点はありますか。
経営層が関与せず現場任せになっている、CoEに意思決定権限がない、評価制度が横断活動の成果を反映していないという3点が共通しやすい要因です。設置そのものより、権限と評価の仕組みを伴わせることが機能させるうえでの前提になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（情報処理推進機構）DX SQUARE「DXを推進する体制とは？先進企業の6つの事例から学ぶDX推進の体制づくり」https://dx.ipa.go.jp/dx-organization
