「DXを進めたいが、任せられる人がいない」。いろいろな企業で耳にする悩みです。社内を見渡しても、要件をまとめ、ベンダーを動かし、現場を巻き込んで前に進められる人がなかなか見つからない。そもそも、どんな人を採ればいいのかもはっきりしない。技術より先に、人と体制でつまずく。DXがうまくいかない理由は、案外そこにあります。

カギになるのが、PMとPMO、そしてITコンサルという三つの顔ぶれです。名前は聞いたことがあっても、何がどう違うのかは意外と説明しづらいのではないでしょうか。この三つの線引きがついていれば、自社にいま足りない役割も、社内で育てるか外部から借りるかも、ずいぶん考えやすくなるはずです。経済産業省やIPAの定義が、その手がかりになります。

DX推進で人材の見極めが難しい理由

人材は、まず数が足りていません。IPAの調査「DX動向2025」では、DXを推進する人材が足りないと答えた日本企業が、8割を超えました。やや不足と大幅に不足を合わせた数字です。

この不足は、待っていれば解消する類いのものでもありません。経済産業省の試算によれば、IT人材の需給ギャップは2018年の約22万人から年々開き、2030年には約45万人に達する見通しです(労働生産性が年0.7%上昇する中位シナリオ。需要の伸びが大きい場合は約79万人とも試算されています)。採用も育成も追いつかないうちに、必要な量だけが先に膨らんでいく。そういう状態が続いています。

ただ、DXの人材難は数だけの話ではありません。もうひとつ、やっかいな壁があります。そもそも、どんな人がほしいのかを自分たちでも言葉にできていない、という壁です。DXは、経営の判断と、業務の作り直しと、ITの実装が一本につながって、ようやく前に進みます。戦略を描く人、計画を回す人、現場を支える人、実際に手を動かす人。求められる顔ぶれは、場面ごとに違います。

ここでよく起きるのが、役割をあいまいにしたままDXに強い人をひとまとめに探してしまう失敗です。戦略を描いてほしかったのに、手を動かすタイプが来た。仕切ってほしかったのに、評論で終わってしまった。人の力量ではなく、何をしてほしいかを言語化しきれていないことから、ずれは生まれます。

裏返せば、最初の一歩はシンプルです。PMとPMO、ITコンサルが何者なのかを、いちど腰を据えて見分けておく。ここをきちんと押さえられるかどうかで、その後の打ち手が変わってきます。

PM・PMO・ITコンサルの違い

三つの違いは、船の上で考えると見分けがつきます。航路を示す水先案内人がITコンサル。船を前に進める船長がPM。その航海をうしろで支えるチームがPMO、といった具合です。

PM、つまりプロジェクトマネージャーは、現場の総責任者です。IPAの定義では、企画から立ち上げ、計画、実行、監視、終結まで、すべての工程に責任を負う立場とされています。期日も予算も品質も背負い、関係者をまとめ、メンバーを率いて、計画どおりに進める。最後に腹をくくって決めるのがPMだ、と言ってもいいでしょう。

PMO、プロジェクトマネジメントオフィスは、そのPMを支える組織的な機能です。上司でも部下でもなく、横で支える関係にあります。進め方をそろえ、進捗や品質を見える化し、関係部署と調整し、会議体を回し、ガバナンスを整える。PMが判断と統率に集中できるよう、足場を組むのが役目です。プロジェクトが大きくなって案件やベンダーが増えるほど、この支えがあるかないかで結果が変わってきます。DX推進の現場でPMOに求められる役割がどう広がっているかは、DX時代のPMOに求められる役割を扱ったコラムでも具体的に整理しています。

ITコンサルは、経営の課題をITの目で読み解き、進む方向を示して、その実行を後押しする役割です。出番は上流に厚く、現状の整理から、あるべき姿の設計、両者の差を洗い出すところまで。何をすべきかがまだ固まっていない段階で、道筋を描くのが得意分野になります。

違いを表にすると、こうなります。

観点ITコンサルPMPMO
主な役割課題分析と方向性の提案プロジェクト全体の遂行責任PMと全体の支援・統制
立ち位置経営・戦略の視点現場の実行責任者仕組みづくりと横断調整
関与フェーズ上流(構想〜企画)が中心立ち上げ〜終結まで通し立ち上げ〜運用、横断的
主な成果戦略・実行計画期日・品質・予算の達成標準化・可視化・調整
ひと言で進む道を描く船を前に進める航海を支える

もうひとつ、見落としやすい点があります。経済産業省とIPAの「DX推進スキル標準」を開いても、PM・PMO・ITコンサルという呼び名は、独立した職種としては載っていません。ビジネスアーキテクトをはじめとする人材の型のなかに、機能として溶け込んでいます。だから、肩書きで人を探すより、自社のプロジェクトでどの機能が欠けているのかを起点に考えるほうが、的を外しにくいのです。

どんな課題なら、誰を入れるべきか

役割がわかったら、自社の悩みと重ねてみます。

何をやるかが、まだ定まっていない。経営からDXの号令はかかったのに、目的も打ち手も具体化していない。現状の業務やシステムが入り組んでいて、どこから手をつけるかも見えない。この段階で頼りになるのがITコンサルです。現状を解きほぐし、目的を定め、打ち手に優先順位までつけてくれます。ここを飛ばして開発に走ると、あとで大きく巻き戻すことになりがちです。

やることは決まったのに、進める人がいない。計画はあるのに会議が空回りし、決めごとは先送りになり、納期だけが近づいてくる。ここで要るのはPMです。判断を引き取り、課題をつぶし、関係者を巻き込んで、計画を動きに変えます。

規模が大きくて、統制が効かない。複数のプロジェクトやベンダーが並走し、PMひとりでは抜けが出る。進捗の粒度もそろわず、全体像がつかめない。そんなときはPMOの出番です。やり方をそろえ、見える化で束ね、PMが判断に専念できる状態をつくります。

作ったのに、現場で使われない。システムは入ったのに定着せず、いつのまにか元のやり方に戻ってしまう。ここは、PMOによる定着の後押しと、現場を巻き込む変革のかじ取りが要になります。

自社の状況入れるべき役割
目的・打ち手が定まっていないITコンサル(構想・戦略)
計画はあるが推進役がいないPM(実行・統率)
複数案件・ベンダーで統制が難しいPMO(標準化・横断調整)
導入したが現場に定着しないPMO＋定着・変革支援

気をつけたいのは、ひとつの悩みにひとり当てはめて終わり、にしないことです。たいていのプロジェクトでは、これらの悩みが時間差で次々に顔を出します。いまの課題を見極めつつ、この先で必要になる役割まで見通しておく。体制づくりは、そこから始まります。

社内で育てるか、外部のプロ人材で補うか

足りない役割が見えたら、社内で育てるか、外部のプロ人材に業務委託で入ってもらうかを決めます。といっても、どちらか一方に振り切る必要はありません。むしろ組み合わせたほうが現実的でしょう。ずっと必要になるコア機能は社内に置き、立ち上げや専門性が要る場面、人手が一気に要る時期を外部で補う。この線引きを最初にしておくと、判断が揺れません。

社内で育てる強みは、知見が組織に残ることです。正社員として中核を担ってもらえば、プロジェクトで得たノウハウが社内にたまり、やがて文化として根づいていく。中核の機能や、ずっと使い続ける役割は、社内で持つほうが、長い目では分があります。弱点は、立ち上がりの遅さでしょう。PM・PMO・ITコンサルといった手練れは採用市場でも奪い合いで、採って育てるには時間がかかる。待ったなしのDXでは、この時間差がじわじわ効いてきます。

外部のプロ人材は、ちょうどその弱点を埋めてくれます。中小企業庁の資料でも、社内での育成が難しい場面で外部の即戦力を活用する選択肢が示されています。必要なスキルを、必要な時期だけ、変動費として使える。立ち上がりも速い。外部のPMO人材にかかる費用の水準は、PMOの単価相場を扱ったコラムで把握できます。ただ、気をつけたいこともあります。人の出入りが増えると、知見が個人について回ったまま、外に流れて消えてしまうおそれがある。だから外部に入ってもらうなら、ドキュメントや引き継ぎをはじめから設計に組み込み、知見を社内に残すところまで一緒に走ってくれる相手を選びたいところです。

観点社員採用外部のプロ人材(業務委託)
立ち上がりの速さ採用・育成に時間がかかる即戦力ですぐ着手できる
コスト構造固定費必要な期間だけの変動費
専門性育成が前提高度スキルをピンポイントで
知見の蓄積組織に残りやすい個人に帰属。移管の設計が必要
向くケース中核・継続的な機能立ち上げ・専門領域・ピーク対応

とくにDXの出だしでは、社内で採れるのを待つより、経験を積んだPM・PMO・ITコンサルにいったん外から入ってもらい、走りながら社内へバトンを渡していく。立ち上がりの速さと、知見が手元に残る安心感。その両方を取りにいく考え方です。

プロジェクトフェーズ別の最適体制

最後は段取りの話です。経済産業省の「DX支援ガイダンス」も、DXは構想から運用・改善まで段階を踏んで進めるものだと示しています。段階が変われば、厚くすべき役割も入れ替わります。おおまかに、構想・企画、PoC・要件定義、本開発・実装、運用・定着の四つに分けて考えてみます。

構想と企画の時期は、ITコンサルやビジネスアーキテクトの出番です。経営の狙いを言葉にし、現状を読み解き、戦略とビジネスモデルを描く。ここで方向を定められるかどうかが、あとあとの成否を大きく左右します。

PoCと要件定義に入ると、PMとPMOが加わってきます。何を検証するのかを絞り、要件を整理し、本開発に進むかどうかの線引きをそろえる。ふわっとした構想を、動く計画に翻訳していく工程です。

本開発と実装の時期は、PMとPMOが舵を握り、エンジニアが手を動かします。進捗、品質、課題をさばき、ベンダーが何社も絡むなら全体を束ねる統括PMOを立てることもあります。規模が大きいほど、横串を通すPMOがものを言います。

運用と定着の時期は、PMOと運用チームが主役に回ります。現場にシステムを根づかせ、効果をはかりながら改善を回していく。ここを軽く見ると、せっかく作ったものが使われないまま終わってしまいます。

フェーズ中心となる役割主にやること
構想・企画ITコンサル・ビジネスアーキテクト目的設定、現状分析、戦略・モデル設計
PoC・要件定義PM・PMO・ビジネスアーキテクト検証、要件整理、本開発への移行判断
本開発・実装PM・PMO・エンジニア進捗・品質・課題管理、ベンダー統制
運用・定着PMO・運用チーム定着支援、効果測定、改善とガバナンス

ここから見えてくるのは、ひとりを最初から最後まで貼り付けておけばいい、という話ではないということです。段階ごとに必要な役割の重みが移っていく。だからこそ外部のプロ人材も、通しでひとり、ではなく、その時期にいちばん効く役割を充てる使い方が向いています。構想ではITコンサルを、実装ではPMOを厚くする、といった具合に。

まとめ

DX推進に必要な人材をそろえるうえでつまずくのは、人が足りないからだけではありません。どの役割が欠けているのかが見えていない、というところに本当の壁があります。PMが実行を背負い、PMOがそれを支えて束ね、ITコンサルが上流の絵を描く。自社の悩みがどこにあるかで、入れるべき人は変わります。中核は社内に置き、立ち上げや専門の場面は外部のプロ人材で補い、段階に合わせて体制を組み替えていく。それが、いちばん無理のないやり方だと思います。

自社のDXに、いま足りていない役割はどれでしょうか。それは社内で育てるべきか、それとも外部のプロ人材で素早く埋めるべきか。迷ったときは、いまある課題とこの先のフェーズを、いちど一緒に並べて整理してみるのが近道です。offeeerでは、PM・PMO・ITコンサルをはじめとするプロ人材を、いまのフェーズと課題に合わせて、必要な期間だけ起用できます。立ち上げを外部で速め、知見を社内に残す引き継ぎまで含めて、体制づくりをご一緒します。現状の課題を整理するところからご相談いただけます。企業向けの相談フォームからお問い合わせください。

いますぐ案件にエントリー
▶ 簡単！30秒で登録


出典・参考文献