DXに立ち向かうプロジェクトマネジメントの在り方

本コンテンツは、2021年3月24日に開催されたJBpress主催「第８回DX フォーラム」のセッション「DXに立ち向かう、手法としてのプロジェクトマネジメント」の内容を採録したものです。

株式会社マネジメントソリューションズ
PMO ONLINE事業部 事業部長
小宮 啓太郎 氏

DXプロジェクトがうまくいかない理由

　当社、マネジメントソリューションズ（MSOL）は「PMO（Project Management Office）」というプロジェクトマネジメントの実行支援、プロジェクトマネジメントコンサルティング、トレーニングを行っている会社です。「PMO」とは、プロジェクトが円滑に進むように、さまざまな手法を用いて、部署やチームの壁を超えて支援を行う組織のこと。主に、プロジェクトオーナーやプロジェクトマネージャーの意思決定を支援、促進することがミッションとなります。

　ボストンコンサルティンググループが発表した「デジタルトランスフォーメーションに関するグローバル調査」によると、トランスフォーメーションに成功した日本企業は全体のわずか14％。世界各国の平均は30％という中で、とても低い成功率となっていることがわかります。DXに臨もうとプロジェクトを立ち上げてもうまくいかない状況を、まずは何とかせねばなりません。

　DX プロジェクトに取り組む場合、そもそもプロジェクト自体をどのように進めていけばいいのでしょうか。DXだけではなく、日本のITプロジェクトについてもご説明します。

　2018年に「日経コンピュータ」が行った「IT プロジェクト実態調査」によると、プロジェクトの成功率は52.8％。2008年度の調査では、31.1％でした。ITプロジェクトに関わったことがない人であれば、これはかなり低い数値といえるのではないでしょうか。とはいえ、先程のDXプロジェクトの成功率と比較すれば良い数値ですし、2008年から見ても成功率は上がっているように見えます。しかし、現在も半数近くのプロジェクトは失敗しているのが現実です。

　では、なぜプロジェクトは失敗してしまうのか。当社としては次のように考えています。

　まず挙げられるのが「計画そのものがずさんである」という原因です。プロジェクトの工数見積もり自体が雑だったり、詳細スケジュールや各メンバーの役割が明確に決まらないまま進めていたりすることが代表的な例として挙げられます。

　そのままプロジェクトを進めると、次に出てくるのが「状況が見えない」という問題です。計画がずさんなままだと、プロジェクトを進めていくうちに現状の進捗や課題の状況がすぐにブラックボックス化してしまいます。これにより解決すべき問題が埋もれ、意思決定の遅れを生じさせます。

　続いて発生するのは、「問題を解決できない」という状況です。ここでは、そもそも生まれてしまった課題自体に、意思決定者がなかなか気づけません。そればかりか、問題自体も同時多発的に発生すると何から手をつけていいかわからなくなります。解決のために必要な関係者も調整できていないため、専門家の意見も聞けない状況であったりします。結果的に原因がつかめず、意思決定自体ができない状況に陥ってしまいます。

　最終的には、目の前のことばかりに追われる毎日になってしまいます。そういった場合、現状の課題にかかりきりとなり、後発する新たな課題を後手に回すことになってしまいます。

　また、そこで何とかプロジェクトを終わらせようとしても、その時に得た教訓を組織に残す仕組みがないと、次のプロジェクトでまた同じ失敗を繰り返すことになってしまいます。こういった「負の連鎖」がつながると、プロジェクトは容易に失敗をしてしまうと考えています。

DXに立ち向かうための「プロジェクトマネジメント」

　では、負の連鎖を生まないためにはどうすれば良いか。一言で言うと「マネジメントをしっかり機能させること」に尽きます。具体的には以下の通りです。

　まずは、「しっかりとした計画を立てる」こと。例えば「勘と経験だけに頼らない根拠のある工数見積もり」や「統計情報を使った現実的な計画」のことを指します。昨今、そういった情報は独立行政法人情報処理推進機構（略称：IPA）のWebサイトや、インターネット上に多数存在しています。そして、初期のうちにリスクを洗い出し、認識合わせをしていくことも大切です。これによって、リスクに対する先手を打つことができます。

　次にやらねばならないのは「状況の可視化」です。現在の進捗や課題の状況を常に可視化しておくことで、問題の早期発見を促します。それらの仕組みが定着してくると、迅速な問題解決が可能になってきます。初期に洗い出したリスクの対策によって、関係者を事前に巻き込むことができていれば、専門的な解決が必要な場合にも後手に回ることなく対処できます。こうすることで、スピード感を持ったプロアクティブな意思決定をしやすくなります。

　プロジェクトがうまくいった場合、それで終わりにしないことも重要なポイントです。うまくいった点・うまくいかなかった点をしっかりと振り返り、教訓として抽出し、組織として保存することが大切です。それだけではなく、管理する部署をしっかり設け、責任を持って次のプロジェクトへその教訓を渡します。そうすることで、新たに始まるプロジェクトは、過去の教訓を生かすことができます。これがプロジェクトを成功させるために必要なマネジメントです。

無理のない、プロジェクトマネジメントの進め方

　次に、具体的な進め方についてご説明します。プロジェクトの進め方は、大きく分けると2つあります。一つは「ウォーターフォール型」の開発、もう一つは「アジャイル型」の開発です。

　ウォーターフォール型の開発とは、開発を各工程に分け、開発手順を一つずつ確認しながら工程を進めていく手法のことです。一方、アジャイル型の開発とは、「仕様や設計の変更は当然起こりうる」という前提に立ち、初めから厳密な仕様は決めず、おおよその仕様だけで小単位での実装とテスト実行を繰り返し、徐々に開発を進めていく手法です。

　ウォーターフォール型の開発は、基幹システムの構築など、確立された業務のシステム化をすることに適しています。しかし、DXのようなプロジェクトの場合、ビジネスの変化するスピードに対応しきれない弱さがあります。そのため、DXプロジェクトを進めようとする場合は、アジャイル型の手法を使い、臨機応変に対応していくことが求められます。

　しかし、私が見聞きしてきた企業様の多くでは、アジャイル型の手法があまりうまくいっていない印象です。その主たる要因の一つが、スケジュールのコントロールが難しい点にあると思われます。これまで企業のIT部門は、ウォーターフォール型の開発でプロジェクトを進めてきました。そのため、アジャイル型で進めるにしても、しっかりとしたノウハウを持った方がマネージをしないと、結果として臨機応変な対応ができない、ということが起きていると考えています。

　そこで当社は、既存のウォーターフォール型の開発に慣れたIT部門でも、極力無理なく進められる開発手法を日々検討しています。具体的には、次の図のように、案件のタイプによって開発のプロセスを２つのパターンに分けていきます。

　パターンA（開発前要検証）では、不確実性の高い要件の場合に、ビジネス側でしっかりとした企画やPoCを行います。その上で、業務要件定義とシステム要件定義を経て、システム側でプロトタイプなどの検証を実施。こうすることで、ある程度の完成イメージをつかんだ状態で要件を確定させることができます。

　パターンB（即開発）は、通常通りの開発です。例えば、業務の単純な変更や法改正の対応などにより、システムの修正が必要になった場合が該当します。どちらのパターンも、要件が確定してからはウォーターフォール型の開発を行います。これにより、既存のIT部門は全ての案件に対して、俯瞰してコントロールがしやすくなります。

　一方、全体の取り組みを上手くコントロールすることも重要になります。この場合は、各工程にチェックポイントを設け、プロジェクトがうまく進んでいるかどうか、確認を行う仕組みを取り入れています。チェックを行うチームは、プロジェクトを担当している部署とは別の部署です。例えば、全社的なPMO組織や品質管理部門などが担います。各工程に確認すべき観点を設け、それらについて客観的に評価を行います。プロジェクトの状況によっては、支援メンバーを投入して正常化させるなど、案件全体の品質に対してのコントロールを実施します。

テレワークにおける
プロジェクトマネジメント

　次に、テレワークで在宅業務を余儀なくされた場合、どうすればプロジェクトはうまく進められるでしょうか。まず、テレワークにおける主な問題から見ていきましょう。

　1つ目の問題は、セキュリティです。2020年に最初の緊急事態宣言が出されたころは、「社用PCを持ち出せない」「社外から社内ネットワークに接続できない」といった問題が顕在化したはずです。これらについて、当社では次のように取り組みました。

　まずは、「VDI」（仮想デスクトップ）の導入です。こうすることで、セキュアな状態を保ったまま、自宅でもPCの環境を用意することができます。次に、クラウド環境の強化。こうすることで、「社内ネットワークや社内の物理的な機器に接続しなければ仕事ができない」という状況を極力排除しました。

　2つ目の問題は、コミュニケーションです。「各メンバーの動きや顔が見えない」「ちょっとした意思疎通ができない」という問題があったはずです。当社では、在籍管理システムを導入し、チームメンバーの顔を積極的に出し合うことで、「今、忙しそうかな？」と伺うことができる状況を作り出しました。また、Slackなどのチャットツールで何気ない日常会話ができるチャネルを作成。雑談を推奨するルールを設けながら、積極的にコミュニケーションを取るように促しました。

　そして最後は、プロジェクトマネジメントについてです。当社でも、前述したような問題が起因となり、プロジェクトの進め方やルールの曖昧さが露呈しました。また、各チームの状況が容易にブラックボックス化したこともありました。そこで当社が取った対応策は、原則として「基本に立ち返る」こと。これも前述したように、しっかりとしたプロジェクト計画や状況の可視化、そのために必要なプロセスの整備を行うことで、迅速な問題解決を図ることができました。

　テレワークになっても、やるべきことは基本的に変わりません。問題はテレワークという環境よりも、プロジェクトマネジメント自体をしっかりと行えているかどうか。この点に尽きると思います。

プロジェクトを横断的に見る
「PgMO」の必要性

　今後は、個別のプロジェクトを成功させるだけでなく、その成功の仕組みを組織として継続的に実施し続けることが重要になってきます。そのためには、プロジェクトを横断的に見ていく全社的なPMOが必要です。当社では、それを「PgMO（プログラム・マネジメント・オフィス）」と呼んでいます。

　上図は、PgMOとなる部署を立ち上げて、各プロジェクトに対して4つの機能を持たせた例です。4つの機能は、プロジェクトへナレッジや教訓提供を行う「標準プロセスチーム」、PMOとして現場支援を行う「PM支援チーム」、プロジェクト監査を行う「監査チーム」、社員教育を行う「教育チーム」となります。これらのチームをプロジェクトに対する“権限の強さ順”に並べたものが下図です。

　下に行けば行くほど、その権限が強くなります。プロジェクト品質のばらつきを抑えるために、標準プロセスや過去の教訓を提供することからスタートし、必要に応じて社員への教育も行います。また、現場にマネジメントのリソースが不足すれば、支援のためのメンバーを派遣。一定期間でプロジェクトの監査も行い、万が一プロジェクトが立ち行かなくなった場合は、リリースを延期するよう進言なども行います。こうすることによって、プロジェクトの品質を底上げし、一定以上に保つことで、組織としての勝ちパターンを構築していきます。

　こういったPgMO組織は、大企業ではすでに設置されていることが多いようです。しかし、弊社が各現場にヒアリングした結果、「評論家は不要。もっとプロジェクトに入るべき。PgMOは現場状況を分かっていない」「PgMOには柔軟性がない。現実問題として工程を止められないので、無理に説明をつけてでも前に進めたい」といった声も多く聞かれます。今後の課題として、PgMO自身も過去のやり方にとらわれず、これまで以上に変化への対応スピードや柔軟性、先進技術やノウハウの習得をしていかなければなりません。

　弊社では、PMOサービスを最低週1回から利用できる「PMO ONLINE」、独自開発した成功確率予測ツール「PROEVERマネジメントスコア」をご用意しています。DXの成功に向けたプロジェクトマネジメントにお悩みの方は、お気軽にご相談ください。

＜PR＞