監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
DXプロジェクトマネジメントは、デジタル技術の導入そのものではなく、それを使った業務や事業のやり方の変更を目的に据えて進める、プロジェクトマネージャーの仕事の進め方を指します。システム開発に加えて、業務プロセスの作り直しや現場の運用定着までを対象に含めるため、通常の開発案件より関係者が広く、ゴールが数値だけでは測りにくい点に特徴があります。計画・合意形成・進捗管理を、変化への抵抗を織り込みながら回していく役割になります。
DXプロジェクトマネジメントで最初に決めるのは、何を変えたら成功と言えるかという目的です。ここを「新しいシステムを入れる」で止めると、稼働はしたのに現場の仕事は前のまま、という結果になりやすくなります。主語を業務や顧客体験の変化に置き直すと、必要な作業の範囲が見えてきます。
PMが具体的にやることは、経営層や業務部門と一緒に、変更後の業務の姿を言葉と図で固める作業です。現状の業務フロー、変更後のフロー、その差分でなくなる作業・増える作業を洗い出し、プロジェクト憲章や企画書の形で合意を取ります。成果物としては、課題設定の資料、変更後業務の設計、投資の判断材料になる効果の見立てが並びます。
つまずきやすいのは、効果を金額だけで語ろうとして根拠が持てず、話が前に進まなくなる場面です。出典のない試算に頼るより、どの作業が減るか、誰の手戻りがなくなるかを言葉で具体的に示したほうが、関係者の納得を得やすい場合があります。
進め方の軸は、企画フェーズ、開発・導入フェーズ、定着フェーズを分けて考えることです。この三つは必要なスキルも関わる人も違うため、ひとつの計画に押し込むと、どこかが手薄になりがちです。
企画フェーズでは、PMが業務部門とともに課題と優先順位を決め、何から着手するかを選びます。開発・導入フェーズでは、要件定義、設計、テストといった開発側の工程を管理しつつ、ベンダーや情報システム部門との調整を担います。ここはウォーターフォールでもアジャイルでも進められますが、業務の作り直しを伴う場合は、小さく試して反応を見ながら広げる進め方が選ばれることが多いようです。
定着フェーズでは、マニュアル整備、研修、運用ルールの決定、効果の振り返りを行います。見落とされやすいのがこの定着で、稼働を納期のゴールにしてしまうと、PMの関与がそこで切れ、現場が使いこなす前に支援が止まってしまいます。定着までを計画とマイルストーンに含めておくことが、成果につながるかどうかの分かれ目になります。
DXプロジェクトマネジメントの難しさは、技術よりも人と組織の側に表れやすい傾向があります。軸は、ステークホルダーの広さと、現場の抵抗への向き合い方の二つです。
一つ目は、関わる人が多いことです。経営層、業務部門の責任者、現場の担当者、情報システム部門、外部ベンダーが同じプロジェクトに並びます。それぞれが見ている利害が違うため、PMはRACIのような役割分担の整理や、ステアリングコミッティでの意思決定の場づくりを通して、決める人と相談する人を明確にしておく必要があります。これを曖昧にすると、終盤で「聞いていない」という手戻りが起きます。
二つ目は、変化への抵抗です。業務のやり方が変わると、慣れたやり方を手放す負担が現場に生じます。これは怠慢ではなく自然な反応なので、頭ごなしに進めると定着しません。PMは、変更管理の視点で、なぜ変えるのかを繰り返し伝え、現場の懸念を設計に反映する余地を残すことが求められます。導入後の問い合わせ対応の体制まで決めておくと、抵抗がやわらぐことがあります。
言葉が似ている概念と並べると、DXプロジェクトマネジメントの輪郭がはっきりします。軸は、対象範囲と、PMに期待される役割です。
DX推進は、組織全体でデジタル変革を進める取り組み全体を指す広い言葉です。その中には複数のプロジェクトが含まれます。DXプロジェクトマネジメントは、その一つひとつのプロジェクトを計画どおりに前へ進める、より手を動かす側の営みと位置づけられます。推進が方針や体制の話を多く含むのに対し、こちらは個別案件の進捗・品質・コスト・納期の管理に軸足があります。
通常のシステム開発のプロジェクトマネジメントとの違いは、業務の作り直しと定着まで責任範囲に入るかどうかです。決まった要件をQCDの枠で作り切るのが開発寄りの進め方だとすれば、DXでは要件そのものが業務変更とともに動くため、要件の揺れを前提に合意を取り直しながら進める姿勢が要ります。この違いを理解しておくと、自分がどちらの働き方を求められているかを見極めやすくなります。
DXプロジェクトマネジメントの経験は、開発の工程管理に加えて、業務を理解し組織の合意を動かせる人という評価につながりやすい領域です。システムを作り切る力だけでなく、現場の抵抗を織り込みながら変化を定着させた実績は、職務経歴書でも具体的に書きやすい材料になります。
書き方としては、どんな業務課題に対して、誰を巻き込み、どの工程を管理し、稼働後にどう定着させたかを、作業と役割の形で示すと伝わりやすくなります。開発寄りのPMから業務変革に関わるPMへ、あるいは上流の企画や推進側へと、キャリアの幅を広げる足がかりにもなり得る経験だと考えられます。
DXプロジェクトマネジメントと通常のプロジェクトマネジメントは何が違いますか
基本の管理手法は共通しますが、DXでは業務のやり方の変更や現場への定着まで対象に含める点が異なります。要件が業務変更とともに動きやすく、関わる人も経営から現場まで広がるため、合意形成と変化への配慮に多くの時間を割くことになります。
DXプロジェクトマネジメントに特別な資格は必要ですか
必須の資格が決まっているわけではありません。PMBOKなどの体系的な知識は土台として役立ちますが、より重要なのは業務を理解し、関係者の合意を取りながら変化を進めた経験です。開発の工程管理と、業務部門との対話の両方を扱えることが問われます。
DXプロジェクトがうまくいかない典型的な原因は何ですか
システムの稼働をゴールにしてしまい、現場での定着まで設計できていない場合が目立ちます。あわせて、関係者の役割分担が曖昧なまま進み、終盤で意思決定が滞ることも起きがちです。目的を業務の変化に置き直し、定着まで計画に入れておくことが対策になります。