DXにおけるプロジェクトマネジメントの重要性と特殊性

DXを推進するに当たっての特有の悩みがあります。それが、プロジェクトマネジメント体制の構築の仕方です。

DXプロジェクトのスタートライン

重要なのは、推進メンバーが「DXプロジェクトに従来プロジェクトとの違いがある」点を正しく認識し、意識統一をすることです。また、最初にどれだけ作りこんでいても、プロジェクトが走っていく中でどうしても人の意識や感覚はずれていくものなので、定期的にしつこい程「共通認識」を確認することも重要です。どちらにしても「戻るべきスタート地点」が重要になります。

プロジェクトオーナーはもちろん、プロジェクトマネージャー、プロジェクトメンバー全員が「これまでとは違う運営の仕方が必要になる」という認識を共有し、「従来通りのスキームがそのまま当てはまらない」ということを理解することが、DXプロジェクトマネジメントの第一歩になります。

プロジェクトマネジメントにおける重要な視点

DX推進プロジェクトマネジメントが立ち上がる場合のテーマは、戦略やデータ収集・分析の手法、ユーザー接点のUIが焦点となります。その中でDX特有の「柔軟さ」が求められるのですが、プロジェクトを適切に立ち上げ、その後結果が出るまでを適切にモニタリング管理する観点においては、プロジェクトマネジメント体制が有効かつ重要です。

DXプロジェクトマネジメントの特殊性や違いを確認するためにも、従来型のプロジェクトマネジメントの原則を確認しましょう。

プロジェクトマネジメントに必要な要素

●目的とゴールの設定
●全体スケジュール、マイルストン設定
●体制構築、リソース計画
●アクションプランの設定と実行

それぞれブレイクダウンして見ましょう。

●目的とゴールの設定
- 何を成すためのプロジェクトか（目的）
- 何が達成できればプロジェクトの成功か（ゴール設定）

●全体スケジュール、マイルストン設定
- どんな期間で実行するのか＋重要なマイルストン（スケジュール）
- 逆算に基づく各タスクの開始タイミング・開始要件（タスク設計）
- スケジュール計画とリソース計画の紐付け（必要なリソース・タイミングの整理）

●体制構築、リソース計画
- 目的とゴールの達成に必要なリソース設定
- アサイン・プロジェクト体制の構築
- プロジェクト達成のために使ってよい人、金、その他資産の設定

●アクションプランの設定と実行
- 目的からリソース計画を実際に実行するためにやるべきタスク設計

当たり前の事柄ですが、通常のIT開発などのプロジェクト管理の場合は、当初計画がリソースプランを含めて適切に設計されていた場合は、いかにそれらに沿って実行していくかを管理することで成果が出る構図になっています。

また、大きなマイルストンに対してテスト計画が紐づく形で存在するため、これらの依存関係やそのタイミングで必要なリソース（開発者、テスト実行者、発注管理工数、紐づく金額）の設計については、経験もさることながらプロジェクトマネジメントのベストプラクティスと呼べる「お作法」が存在します。

しかし、DX推進では必ずしも従来のプロジェクトマネジメントの「お作法」がそのまま装着できない場面があります。

DX推進における特徴

DXプロジェクトと従来型IT開発との大きな違いが2つあります

● プロジェクト成功後のUXやワークフロー設計を固めづらい
● 当初設計した目的やリソースの柔軟な変更を求められる

どちらも先ほど見てきたプロジェクトマネジメントのお作法の真逆です。

ゴール設計や目的、リソースプランを「変更しないために」進捗管理して着地させることが求められていたはずなのに、DXプロジェクトではゴール設計やリソースプランも「変更しながら」走ることが成功の秘訣だと言っているわけです。

なぜこのような逆転現象が起こるかというと、DXが目的として掲げる、データ分析やAI技術の特性から生まれるものと言えます。これらの技術は移り変わりが早く、既存サービスとの組み合わせで計画より早く実現することもあれば、想定された精度が出ずに改善や原因追及に時間を要する場合もあるからです。

そのため、従来の「事前に何をやるかを明確に決定し、手順通りに行う」手法ではなく、より短い期間で区切り、計画変更を含めてプロジェクトを進める必要がある点が最も大きな違いです。

計画変更がある前提でのプランニングという発想

「やってみるまでわからない」領域が残るのがDXのため、当初見込みと乖離することを織り込む方が、きちんとリソースプランを設計するよりも重要です。逆説的ですが、「計画は変わる」として計画を設計することで、バッファとしての「再検討時間」をプロジェクト内に仕込むことができます。

当初決めた目的と要件に対して必要なリソースをより正確に見積もりアサインするのではなく、大きなビジョンの元でスクラム開発するために、一定リソースを先に確保しプロジェクトを進める。必要なタイミングで要件の見直しを行いながら、当初決めた目的に近づいていく……という「余白」の設計こそがDXプロジェクトで重要なプロジェクトマネジメント観点です。

また、特性上確定したゴールを作ること自体がが難しくなります。プロジェクトメンバーと同じ方向を向いて走るために何をゴールとするのか？というと、ゴール後に「どうなっている状態にするべきか」のイメージ共有です。従来のゴールのさらに先、「あるべき未来の姿」共有が必要な点も、DXプロジェクト特有と言えます。

曖昧さを織り込みながら設計し、変えたい姿に近づけるという点がDXプロジェクトの難しく、面白い点だと思います。

本日お話した個別プロジェクトとしてのマネジメントとは別に、事業目線でのDXプロジェクトの立ち上げ・追加投資・撤退の意思決定等の話は、また別の機会に触れようと思います。

Header: Management Vectors by Vecteezy