DX推進を成功に導く「ユーザーPMO」の役割

ユーザーPMOが果たすべき役割

では、ユーザーPMOがプロジェクトで果たすべき役割には何があるでしょうか。ユーザーPMOには大きく2つの役割があると考えます。1点目は、業務変革の旗手としての役割です。つまり、DXのステークホルダーとなる社内外の業務関係者へと粘り強く働きかけながら、目指す姿への変革を推進していくことです。2点目は、システム導入の監督者としての役割です。つまり、ともすればシステム目線での個別最適を選択しがちなシステム導入側を、ユーザー側の観点からDXの目指す到達点へとリードすることです。この2点が同時に達成されることがプロジェクトの成功のための必須要件となるため、ユーザーPMOがうまく機能するかどうかがプロジェクト成功の鍵を握っていると言って過言ではありません。

ユーザーPMOをうまく機能させるためには

それでは、上記2点を加味したときに、ユーザーPMOをうまく機能させるためには何をすべきでしょうか。それはユーザーPMOの体制づくり、役割・スコープの明確化の2点であると考えています。

まず、体制づくりとしては、適任者をユーザーPMOに据えることが何より大切です。ユーザー視点とシステム視点の両視点からビジネスを包括的に捉えることができ、かつ各種関係者との連携を密に行うことのできる人材をユーザーPMOに据える必要があります。またユーザーPMOには、責任と権限を与え、片手間にならないよう十分に関与してもらえるよう調整してアサインすることが肝要です。

適任者がいなければ、外部のコンサルタントを招聘することを検討するのも一案でしょう。コンサルタントを選定する際には、経営層とのコミュニケーションからベンダーとの調整までできる経験値を持っているのか、一般論によらず、企業独自の文化や手法、プロジェクトの状況に寄り添える柔軟性があるのか、そして品質水準を妥協せず引き上げることができるプロ意識を持っているのか、といった点を確認することが肝要です。また、可能であればシステム構築を担当しているベンダー等からではなく、第三者として社外から招聘したほうが成功する確率が高まります。システム側とユーザーとの間には立場上の利益相反となる局面が多々発生するので、システム側に対して第三者として厳しさをもって指摘できる立場であるほうが、プロジェクトにとってより良いユーザーPMOとして機能することを期待できるためです。

そして2点目のユーザーPMOの役割・スコープの明確化をするためには、ユーザーPMOにベンダーPMOと異なる重要な役割があることを認識してもらうことがまず肝要であり、そのうえでユーザーPMOに推進を期待するタスクを明確化しておくことが重要です。ここではまずキーワードレベルで、ユーザーPMOに実行推進が期待されるタスクを、PMBOK（Project Management Body of Knowledge：プロジェクト管理の標準体系）に沿ってご紹介します（図表1）。

※PMBOK 第6版の「知識エリア」を参照し一部順番を入れ替えています

① スコープ管理：変革の目的を明確化

②③ ステークホルダー管理・コミュニケーション管理：プロジェクトメンバー、業務部門、社外関係者ごとにそれぞれ取るべきコミュニケーションをチェンジマネジメントの観点で設計

④ コスト管理：変革の効果を算定。リスク費の運用方法を適切に設定

⑤ リスク管理：稼働直後のリスク低減のための業務施策を企画

⑥ 品質管理：稼働判定項目からバックキャストで品質確認、向上タスクを設定

⑦ スケジュール管理：業務部門の管理はWBSに拘らず適切な方法・粒度で実施

⑧⑨ 資源管理・調達管理：稼働直後の問い合わせ対応の要員調達をあらかじめ計画

⑩ 統合管理：上記ユーザータスクを、あらかじめ計画

上記のタスクはシステムPMOと連携しながら管理を進めるものも多くありますが、そのなかでも特にユーザーPMOが管理主体となるべきものがあります。紙面の都合上、これ以降はユーザーPMOが管理主体となるべき5つのタスクに絞って説明します。

① スコープ管理

ユーザーPMOが行うべきスコープ管理は、ユーザーが納得するシステム導入のスコープを設定して、そのスコープの変更を管理する、というのが一般論ではありますが、見落とされがちだが重要なミッションとして、変革の「目的＝why」の明確化があります。ここで肝となるのが、目的としてWhatやHowを設定してしまわないことです。例えばプロジェクトの目的として「見える化の実現」「データの一元化」や、基幹システムの老朽化対応であれば「新基盤による今後のビジネス変化へ柔軟に対応できるように」などが記載されている事例を目にすることがありますが、これらは「施策＝What、How」であり、「目的＝why」ではありません。いわば手段が目的になってしまっている事例です。このように手段を目的にしてしまっていると、スコープが揺らぎやすいというリスクを抱えます。例えば「見える化の実現」では、どこまで見える化すべきなのかに対する想いが部門・階層によって異なるのでスコープが揺らぎやすく、スコープをとりまとめて合意形成するために、多大な労力と時間がかかる可能性があります。

「目的＝Why」をあらかじめ明確にしておくことによって、そういった事態を回避することができます。例えば「見える化」であれば、案件別の収支を正確に細かい粒度で見えるようにすることによって、販売部門が適正価格を設定できるようにし、価格競争力を上げて案件拡大することを目指す、といった具合です。こうした「目的＝Why」をあらかじめ明確化しておけば、例えば原価明細別のコストはその目的にとって必要なのか、必要であったとして優先度は高いのか低いのかを、プロジェクトのメンバーが高い確度で判断できるようになり、合意形成にかかる工数を下げることができます。

②③ コミュニケーション管理・ステークホルダー管理

見落とされがちですが、ユーザー側のPMOが行うべきこととして、チェンジマネジメントのためのコミュニケーションをあらかじめ設計しておくこと、という点があります。プロジェクトに関係するステークホルダーを社外関係者を含めて洗い出し、どのタイミングで何を、どういったルートでコミュニケーションすべきかを事前に定めておきます。その際、社内外のステークホルダーを層別したうえで組織の規模やプロジェクトによる影響度などを考慮し、プロジェクト活動と連動させて設計することがポイントです。

なお、ステークホルダーのなかで当事者となる業務部門メンバーの巻き込みは特に重要です。社外関係者との窓口は通常業務で対面している業務部門メンバーが担当するでしょうし、部門内への情報の落とし込みや各種調整の実施など、ユーザーとしてだけでなく業務側の窓口（代表）の役割も担ってもらうことになります。業務部門メンバーに“自分事”として取り組んでもらうためには、個人の力量・裁量だけだと限界があり、マネジメント層の理解・協力が必要不可欠となります。業務部門のマネジメント層に対する意識醸成を図り協力体制を構築できるかどうかも、プロジェクトの成否に関わる大きなポイントとなります。

④ コスト管理

ベンダーへの発注管理・システムライセンス費用の管理などがメインであり、ベンダーの見積の妥当性をユーザー側で確認する、というのがユーザーPMOのタスクです。ここでも見落とされがちだがユーザーPMOがコスト管理として行うべき大きなミッションとして、リスク費（予備費やコンティンジェンシー費とも呼ばれる）の運用を決めておく、というものがあります。特に大規模プロジェクトでは、プロジェクト全体で一つのリスク費では運用が難しくなる可能性があります。リスク費の取り崩し申請がユーザーPMOに上がってきても、プロジェクトの規模が大きいと、ユーザーPMOがその妥当性を判断できないことが多いのです。その結果、リスク費の運用が「ザル」になってしまい、変革に必要ない機能まで盛り込んでリスク費をすぐに使いきり、プロジェクトコストの増加になってしまう事態に陥る可能性があります。逆にリスク費の使用を過度に控える、あるいはリスク費の承認に時間がかかりすぎることによって、変革に本当に必要な機能に必要なタイミングで投資できない事態に陥る場合もあります。そうした事態を避けるためには、例えばリスク費をプロジェクト内の各チームに分配し、チームリーダーにリスク費に対する責任と権限を負わせ、実態に即したリスク費の管理を行わせるなどのスキームを検討する必要があり、それはユーザーPMOの仕事になります。

また、コスト管理そのものとはすこし離れますが、ユーザーPMOがコスト管理の文脈で担うべき大きなミッションとして、変革がビジネスに与える効果の算定があります。

効果を適切に算定し、そのコストが妥当であることを社内の経営層に説明してプロジェクトを前進させることは、ユーザーPMOが行うべきことの一つです。企業によって投資する際にはルールとしてその対効果の算出が求められる場合とそうではない場合がありますが、ルールで求められない場合であっても経営層から問われる場面は多々あります。また定量的な効果をプロジェクト指標の一つとすることで、プロジェクト内でさまざまな判断を行う際の明瞭な基準として利用することも可能となります。これらの観点を踏まえ、ユーザーPMOは効果算定のための適切なフレームを用意し、適切な関係者を巻き込んだ算定を推進する役割を担います。

⑤ リスク管理

新しいシステムを稼働させる前後に発生するリスク管理においては、②で触れた主にシステムに関するコスト面のリスクだけではなく、業務側のリスク低減に関してもユーザーPMOが主体的に主導すべきです。例えばシステム稼働直後に発生するリスクとしては、データ移行が終わらず稼働できない、システムが想定以上の処理量によりダウンする、データ移行が正しく行われない、担当者が業務を回せるほど新システムに習熟していない、などが考えられます。それらのリスクが発現してしまったとしてもビジネスを継続できるように、リスク低減策を講じておく必要があります。リスクの洗い出しはDXの対象によってさまざまなアプローチがありますが、例えば図表2のようにバリューチェーンに照らし合わせるという方法で網羅的に洗い出すというのも一つのアプローチです。

このようにして洗い出したリスクに対して、業務側で、例えば経理DXであれば、システム稼働後最初の決算日程や予算編成日程をあらかじめ通常よりも長く設定して経営層と合意しておく、生産・物流に関わるようなDXであれば、稼働前後は在庫を積み増しておくことによってシステムが動かなくてもビジネスを継続できるようにしておくなどの策を、ユーザーPMO推進のもと、事前に企画・実行する必要があります。