カスタマーコンサルティングチームの小谷 将来です。
前回までは、プロジェクトマネジメントの実践という観点から、業務遂行における汎用的なスキルについて、お話しさせていただきました。誰しもが実践できるスキルではありますが、日々の業務の中で如何に意識的に行動ができるかが問われるものと考えます。
プロジェクトマネジメント実践(1)
プロジェクトマネジメント実践(2)
プロジェクトマネジメント実践(3)
一方で、昨今のプロジェクトを鑑みると、DX*1という言葉がよく聞かれると思います。様々な企業がDXにチャレンジし、実にその70%が失敗*2をしているとされており、国内ではさらに高い比率で頓挫していると聞きます。私からは、いわゆるDX案件のプロジェクトは従来型のプロジェクトと何が違うのかを明らかにし、それらを成功に導くためのいくつかのトピックを数回にわたり、プロジェクトマネジメントの観点から、お伝えしていければと思います。
DXプロジェクトの特色
DXプロジェクトを成功に導くための１つのポイントは、従来型のプロジェクトとの違いをしっかりと認識することにあると考えます。（ここで述べる、”従来プロジェクト”は”ウォータフォール型のプロジェクト”を指します。）過去の成功体験からの脱却、既存の知識・スキルからの飛躍がDXを成功させるための鍵であると考えてます。私見ではありますが、従来プロジェクトとDXプロジェクトの違いをプロジェクトマネジメントの観点から、以下にまとめてみました。
上記、違いをもう少し深掘りしていきたいと思います。
DXプロジェクトは価値重視
従来型のプロジェクトは、計画段階で要求事項が明確であるため、その時点でビジネス価値は一定明確になってきます。そのため、如何に予定している計画をコスト内で収めるかが重要になってきます。
一方でDXプロジェクトでは、計画段階で要求事項が全て明確に洗い出されているわけではなく、プロジェクトを進めていく中でビジネス価値を模索していきます。プロジェクトオーナーは、実施すべき作業の優先順位や、価値を向上するための顧客との協働に注力し、プロジェクトのビジネス価値を高めることが重要になります。
計画は全体を精緻に、個別を流動的に
計画を立てる段階において、重要なGOALとなる要求事項は、DXプロジェクトにおいて、明確に定まっていないケースがほとんどかと思います。これはDXプロジェクトの性質においては、ごく自然です。むしろ、明確に定めれば、後々に無理が生じ、計画が破綻する可能性があります。そのうちの１つの要素としては、DXプロジェクトで扱う技術は、企業にとって挑戦的であり、不確実なリスクを多分に孕んでいるからになります。いくら綿密に計画を立ててもその通り行かず、計画倒れになり、間に合わせの結果は価値を創出できていないということがあり得ます。
そのため、計画を立てる際は、予め流動的であることを認めたプロセスにすることが重要になります。大きな計画（リリース計画）はしっかりと期限を定め、従来型のプロジェクトのように管理するも、各機能を作り上げる段階においては、何を作るのかも含め、先々までは予定し過ぎず、一定のサイクルを反復実行することがリスクを最小限にする手法になります。一般的にいうアジャイル手法がまさに該当します。
また、品質面においても既存の品質保証プロセスから異なる手法が求められます。上記のような反復実行をする上では、繰り返しの回数が多くなり、既存のような時間とコストがかかる品質確認は非現実的になるからです。ここでは、如何に顧客と協働し、品質を高めていく活動をしていくかが重要になると考えます。
実行段階における迅速な情報共有
実行時では、コミュニケーションの取り方が、正確さから迅速さにシフトチェンジしていくと考えます。DXプロジェクトでは、チームの自己組織化が強く求められる傾向にあります。理由としては、価値創出をメインとするPJにおいて、最もビジネス価値の創出を期待できるからになります。任されているというモチベーションの向上、各チームとの積極的なコラボレーション、スキル習得の早さ等、様々な効果があると言われています。とはいえ、簡単に自己組織化が出来るわけではなく、そういった人材を育てることが企業としての重要課題だったりします。
上記のような自己組織化がなされたとしても、コミュニケーションは常に問題になりがちです。自分が何をやっているのか、隣のチームは何をやっているのか、プロジェクト全体ではどのような状態になっているのか等、情報を自らが率先して、共有・取得していく流れを作ることが求められます。
従来型のプロジェクトでも同様、情報共有・取得は当然のように行いますが、伝えるべき相手は上司であったり、会議の場で丁寧に誤解なく、伝えることが重視されます。故に迅速さより、正しく適切であることが求められます。
プロジェクト監視は顧客価値を注視
従来型のプロジェクトは、一定のマイルストーン、チェックポイントに従い、計画時に定めれた通りに、QCDの観点からプロジェクトの健康状態を把握します。DXプロジェクトでも、一定の期間で横断的な状況把握をすること自体は変わらないですが、その時の観点は計画時に必ずしも定められいるわけではありません。価値重視であるDXプロジェクトは、どれだけ価値あるものを創出しているのか、が判断の基準であり、その基準は顧客の要求事項にあります。しかしながら要求事項が曖昧であるため、実際に顧客に結果をデモで見ていただきフィードバックを求める等の対応が求められます。
品質をチェックする上においては、顧客と協働し、品質保証のプロセスに組み込むことが重要になってきます。また、その活動の中で作業の優先順位を柔軟に組み替えながら、より価値を出せるプロジェクトに変化させていくことが課せられていると考えます。
反復実行による改善はDXプロジェクトの要
PDCAのサイクルを回し、プロジェクトを成功に導いていくことは、両プロジェクト共に同じであるものの、PJサイクルの早さ、プロセスの改善、柔軟な計画の変更は、DXプロジェクトに求められる要件になります。反復実行によりリスクを極小化しながら、より高い価値を創出するための小さい機能を積み上げ、最終的な成果物を作り上げていく一連の流れが、DXのプロジェクトマネジメントの要であり、プロジェクトの成功に繋がると考えております。
まとめ
私見ではありますが、従来型のプロジェクトとDXのプロジェクトの違いから、考慮すべきポイントを列挙させていただきました。どうしても、従来型でのプロジェクトマネジメントでの成功体験に引きずられ、プロジェクト進める中で元の従来型に戻ってしまい、結果、サイクルだけが早いミニウォーターフォール型になってしまうケースを見てきてました。
DXでは、今までのやり方に囚われず、まっさらな気持ちで企業全体が臨み、「企業がデジタルを扱う」のではなく、「企業がデジタルそのものになる」必要があるのではないでしょうか。次回以降は、DXプロジェクトの進め方として、重要なアジャイル手法について、少し深掘りした話をしたいと思います。
*1 DXの定義…「デジタル・データ活用人材に求められる素養」を参照
*2 DXの失敗要因…「DX推進が上手く進まない(頓挫する)プロジェクトの特徴とは」を参照
