DX推進にPMOが不可欠な理由｜体制の作り方と内製・外部支援の使い分け

経営から「DXを推進せよ」と指示が降りてきて、気づけば自分が推進担当になっていた。プロジェクトは立ち上がったのに、半年経っても目に見える変化が出ない。会議の数は増えるのに、決まることは一向に増えない——「DX PMO」と検索している方の多くは、そんな状況にいるのではないでしょうか。先に結論を言うと、DXが進まない原因の大半はツールでも技術でもなく経営と現場の「間」にあり、その間を埋める機能こそがPMOです。僕は受注側のPMとしても、大手外食チェーンのCIOアシスタントという発注側の立場でも、プロジェクトに関わってきました。この記事では、両側から見えたDX停滞の構造的な原因、DX推進におけるPMOの役割、体制の作り方、内製と外部支援の使い分けまでを順に整理します。

うまく進んでいないDXプロジェクトには、驚くほど共通したパターンがあります。経営は「なぜ進まないのか」と苛立ち、現場は「通常業務で手一杯なのに、これ以上何をしろと言うのか」と疲弊している。どちらも真剣です。真剣なのに、噛み合わない。

僕が大手外食チェーンのCIOアシスタントとしてIT戦略に関わっていた頃、痛感したことがあります。経営が見ているDXは事業構造の変革で、現場が受け取るDXは新しいツールの導入。同じ「DX」という言葉を使っているのに、見ている景色がまったく違うんです。経営の意図を現場が動ける粒度に分解し、現場の制約を経営が判断できる形に整理する——この工程を省略したDXプロジェクトは、ほぼ例外なく迷走します。

停滞の構造を分解すると、次の4つに整理できます。

1. 経営の意図が、現場の動ける粒度に翻訳されていない

「デジタルで事業を変える」という方針自体は間違っていなくても、現場にとっては「で、明日から何をすればいいのか」が分からない。方針と作業の間にあるべき「誰の、どの業務を、どう変えるか」という業務設計が丸ごと抜け落ちているのが、最も多いパターンです。

2. 現場の制約が、経営の判断材料になっていない

現場は「今の業務ルールではできない」「繁忙期は止められない」といった制約を知っています。ところがそれが「だから、AとBのどちらを取るか判断してほしい」という形に整理されず、単なる抵抗や反対意見として処理されてしまう。結果、意思決定が止まります。

3. 部門横断なのに、優先順位を決める機能がない

DXは営業・製造・管理と部門をまたぎます。ところが推進担当の多くは既存部門との兼務で、部門間の利害が衝突したときに「どちらを先にやるか」を決める場も、決めるための基準もない。誰も悪くないまま、すべてが「調整中」で止まる。

4. ゴールが「ツール導入」にすり替わる

本来のゴールは業務や事業が変わることのはずが、進捗として見えやすい「システムの導入完了」がいつの間にか目標に置き換わっていく。導入した瞬間にプロジェクトが解散し、変化は起きないまま終わる。

注目してほしいのは、4つとも「人の能力」ではなく「構造」の問題だということです。炎上プロジェクトにおけるスケジュール遅延が症状にすぎないのと同じで、「DXが進まない」も症状です。手を入れるべきは、症状ではなく構造のほうです。なお、DX停滞の代表格であるレガシーシステムの刷新（進まない原因と7ステップの進め方）については、別記事で詳しく整理しています。

DXの文脈でPMOと聞くと、進捗管理や会議調整をしてくれる事務局を思い浮かべる方が多いと思います。ただ、先ほどの4つの原因を見れば分かるとおり、DXで本当に必要なのは進捗を記録する機能ではなく、経営と現場の間に立って双方向の翻訳をする機能です。

翻訳には2つの方向があります。

• 下りの翻訳: 経営の「DXで事業を変える」という意図を、「誰の、どの業務を、いつまでに、どう変えるか」という現場が動ける粒度に分解する
• 上りの翻訳: 現場の「できない」「難しい」を、「選択肢はAとBで、それぞれのトレードオフはこうです。どちらにしますか」という経営が判断できる材料に組み替える

翻訳と言っても、資料をきれいに作り直すことではありません。経営会議の資料から「現場が来月やるべきこと」を取り出し、現場ヒアリングのメモから「経営に判断してもらうべき選択肢」を組み立てる。この往復を毎週回し続けることです。僕自身、CIOアシスタント時代にこの翻訳の重要性を何より痛感しました。派手な戦略立案よりも、はるかに泥臭い。でも、DXプロジェクトが動くか止まるかは、この翻訳が回っているかどうかでほぼ決まります。

通常のシステム開発プロジェクトのPMOと比べると、求められるものの違いがはっきりします。

もう一つ。僕は開発プロジェクトの7割は上流工程で決まると考えていますが、DXはその最たるものです。「そもそも何をやるか」の質がほぼすべてを決める。走り出してから管理だけを強化しても、間違った方向に速く進むだけです。だからDX推進のPMOは、管理部隊である前に、上流の設計に関与する翻訳部隊であるべきなんです。

では、具体的にどう体制を組むか。僕が勧めるのはシンプルな3層構造です。

体制図を描くこと自体は誰でもできます。この3層構造を実際の図に落とす実務はPMO組織図の書き方と配置パターンにまとめていますが、問題は図が描けるかではなく機能させられるかどうかで、僕なら次の5点を確認します。

機能する推進体制のチェックリスト

• 経営層に「個人名の入った」オーナーがいるか（○○本部という組織名は不可。組織は判断しない）
• 意思決定の場の開催頻度と、そこで何を決めるかが明文化されているか
• 各部門から「業務を語れる人」が体制に入っているか（役職ではなく、実務の解像度で選ぶ）
• 推進層に、業務設計と翻訳を担う専任リソースがいるか（全員兼務なら、ほぼ確実に止まる）
• 部門間で優先順位が衝突したとき、誰がどの基準で決めるかが事前に合意されているか

特に効くのは3つ目です。DXの成否は、経営と現場の間に業務設計ができる人がいるかどうかでほぼ決まる、というのが両側を見てきた僕の実感で、ツール選定やベンダー選定よりも先に、この「人の配置」を設計すべきです。

推進層のPMOが日々やることも、具体的に挙げておきます。意思決定の場に上げる論点の整理と事前配布。部門横断の課題一覧を維持し、期限を過ぎた判断を督促する。施策ごとの優先順位案も作ります。そして各会議の設計——誰が出て、何を決め、何を持ち帰るのか。どれも地味です。ただ、この地味な機能が止まった途端、DXは「全員が忙しいのに何も決まらない」状態に逆戻りします。

なお、基幹システム・ERPの導入を含むDXではデータ移行やベンダー管理といった別の論点が加わり、レガシーシステム刷新にも固有の手法論があるため、本記事では推進体制の設計に絞って話しています。

体制の話をしたところで、少し先の話もさせてください。PMO自身の仕事も、生成AIによって中身が変わりつつあります。これからDXの推進体制を作るなら、この変化は織り込んでおいたほうがいい。

僕はYouTubeで、生成AIがシステム開発をどう変えるかについて話したことがあります。スタンスはこうです。

format_quote

僕は、生成AIがシステム開発の仕事を完全になくすなんてことはありえないけれども、かなり大きな変化を呼ぶという風に思っています

議事録の作成、メールの下書き、調べ物。プロジェクト内の庶務的な業務は、生成AIで大幅に効率化できるようになりました。それ自体は歓迎すべき変化ですが、裏返すと厳しい現実もあります。同じ動画で、僕はこうも話しました。

format_quote

簡単な実装作業を行っているだけのエンジニアですとか、庶務作業をやっているPMO的な人とか、こういった人たちは仕事を奪われる可能性が結構高いかなという風に思います

会議調整と議事録作成が仕事の中心になっている、いわゆる「議事録係」のPMO。その価値はこれから急速に下がります。一方で、コーディング作業そのものは開発労力の30%前後にすぎず、自動化が進むほど人間の付加価値はBPR・業務フロー策定・合意形成・対人交渉といった上流にシフトしていく、というのが僕の見立てです。つまり、ここまで述べてきた「翻訳」と「業務設計」の価値は、AI時代にむしろ上がるということです。

format_quote

将来的にどういった人材が必要になるかというと、ざっくり言うと、企画人材とかマネジメントできる人材というのが非常に重要になってくるわけですよね

これからPMOを立てる、あるいは外部に頼むなら、この変化は選定基準に直結します。庶務を肩代わりするPMOではなく、翻訳と判断支援ができるPMOを選ぶこと。生成AIがシステム開発をどう変えるのか、動画で詳しく知りたい方は、以下もあわせてご覧ください。

「ChatGPTなどの生成AIがシステム開発を変える理由3選」

最後に、推進層のPMOを自社人材で立てるか、外部支援を使うかの判断です。結論から言えば、これは二者択一ではなく、フェーズの問題です。DXの立ち上げ期に必要な「推進の型と経験」と、軌道に乗ってから必要な「自社業務への深い理解」は、性質がまったく違うからです。

立ち上げ期と立て直し期は、外部の型を借りるのが早い

DX推進のPMOには、会議体の設計、課題管理の仕組み、意思決定プロセスの明文化といった「型」が要ります。これをゼロから手探りで作ると、型ができる前にプロジェクトの熱が冷めます。システム開発の成功率は3割と言われるほど失敗の多い世界で、初めての型作りを独学でやるのは分が悪い勝負です。

ただし、外部に頼む場合でも、業務の中身を知っているのは常に自社の人間です。外部PMOに丸投げして機能する体制は、まず成立しないと僕は考えています。自社側に「業務を語れる人」と「決められる人」を必ず置き、外部支援はその間の翻訳と型の提供に使う。この役割分担が、外部活用が機能する条件です。将来的にPMO機能を内製化するにしても、この分担で自社側に経験が残っているかどうかが効いてきます。内製に軸足を移すための具体的なロードマップは、PMO内製化を進める5ステップを参考にしてください。

外部PMO支援の選定ポイント4つ

1. 業務設計まで踏み込む提案か。 進捗管理と会議運営だけの提案は、庶務型PMOと同じ末路をたどりやすい。「誰のどの業務をどう変えるか」を一緒に設計する姿勢があるかを確認する
2. 経営と現場、両方の言葉を話せるか。 経営層への報告経験と、現場への落とし込みの経験。面談で両方の具体例を聞けば、すぐに分かります
3. 特定のツールやベンダーから中立か。 商材ありきの「DX支援」は、ゴールがツール導入にすり替わる構造的リスクを最初から抱えています
4. 卒業させる設計になっているか。 型やドキュメントを自社に残す前提か。「ずっといないと回らない」状態は、支援ではなく依存です

• DXが停滞する原因の大半は技術ではなく、経営と現場の断絶という構造問題
• DX推進のPMOの中心価値は進捗管理ではなく、双方向の「翻訳」と業務設計の支援
• 体制は意思決定層・推進層・実行層の3層で設計し、「業務を語れる人」を必ず入れる
• 生成AI時代、庶務型PMOの価値は下がり、翻訳と判断支援の価値はむしろ上がる
• 内製か外部かはフェーズで判断する。立ち上げ期は外部の型を借り、業務の主導権は自社に残す

DXが止まっているとき、責めるべきは現場のやる気でも経営の理解不足でもなく、「間を埋める機能を誰も設計していなかった」という事実です。裏を返せば、そこを設計すれば動き出す。推進担当のあなたが次にやるべきことは、新しいツールの比較表を作ることではなく、自社の体制図に「翻訳者」の席があるかどうかを確かめることだと思います。この「間を埋める機能」を外部から取り入れる選択肢を検討する場合は、PMO支援サービスの内容と導入の流れもあわせてご覧ください。

---

DX推進のPMO体制にお悩みの方へ

「DXプロジェクトが1年近く止まっているが、何から手をつければいいか分からない」「推進室を作ったものの、経営と現場の板挟みで疲弊している」「外部PMOを入れたいが、庶務型ではない支援会社の見極め方に自信がない」——DXの推進体制では、こうした悩みがほぼ必ずと言っていいほど出てきます。

僕自身、受注側のPMと発注側のCIOアシスタント、両方の立場でプロジェクトに関わってきました。株式会社クリエイティブテックスタジオでは、経営と現場の翻訳から推進体制の設計まで、DX推進のためのPMO支援を提供しています。サービスの詳細はPMO支援サービスをご覧ください。

とはいえ、外部PMOを入れるべき段階なのか、まずは社内の体制整理が先なのかは、状況次第です。お話を伺ったうえで率直にお伝えしますし、他社のサービスが適していればその旨も正直にお伝えします。まずは無料相談から、いまの状況をお聞かせください。