PMに求められる「高度な6つのスキル」とは？　3つの事例に見る、DX推進に立ちはだかる壁の乗り越え方

事例に見る「最適な顧客体験を設計するには？」

小國晴郎氏：ここからは「最適な顧客体験はどのようにしていけば、設計していけばいいのか？」というところを、ケーススタディとともにお話をしていきます。

この事例でお話する領域は、理想的な顧客体験を定義し、既存の顧客体験におけるGAPを抽出していく部分になっております。

この企業は、はじめにビジョンとして顧客の探索行動だったりとか、比較行動というのが急激にデジタルシフトをしているため、事業の成長にはデジタルでのコミュニケーション強化が必須で、積極的に投資をしていきたいとおっしゃっておりました。また、なんとなくDXで顧客体験を向上させたいということもおっしゃっておりました。

課題としては、みなさんも感じたのかなと思うんですけれども、明確な経営レイヤーにおけるDXって、実現したい顧客体験上の向上が明文化できていないだったりとか、わからないということがあります。

また、我々が現場にヒアリングしていく中で見えてきたのが、ISSUEドリブンではない目的だったりとか、効果検証の伴わない競合他社の追従タスクに追われているということもございました。

これに対して私たちのソリューションは、直近の課題解決のためのアジャイル的DX推進と、中長期的なDX VISIONを顧客体験発想で策定していくということでありました。

目下の強豪に追いつけというのはよくわかるんですけれども、顧客体験とそのビジネスへの貢献を無視して、ある意味、闇雲にリソースを使うのは非常にもったいないかなと思っております。

素早いビジネス貢献を実現するための優先度評価と、実行施策の評価を高速で回すデータドリブンな顧客体験最適化プロジェクトを、アジャイル的な進め方でサポートさせていただきました。

多くの課題の優先順位を正しく評価し、スプリントを回して、2週間に1度のリリースポイントを設け、実行した施策の評価も含めてスピーディに施策を展開していきました。

そして、経営の中長期的なDX VISIONがないということに対しては、先ほど申し上げた顧客体験発想でのDX推進でサポートいたしました。顧客一人ひとりを徹底的に分析する、カスタマードリブンでの顧客体験設計を提供したということになっております。

これら2つのプロジェクトは、相互に連携することでよりよい化学反応を生むことができました。アジャイルプロジェクト側では、実際に施策を実行した結果や顧客の反応をレポーティングし、中長期的な顧客体験プロジェクトに反映させたり、中長期的な体験設計プロジェクトのユーザー調査の中で生まれた仮説を、実際の顧客接点チャネルで実証実験して結果を分析したりですと、両プロジェクトにとって有益な連携を実現していきました。

データドリブンな顧客体験最適化を進める上でのポイント

データドリブンな顧客体験最適化を進める上での、重要なポイントです。2つあるかなと思っているんですけれども、1つ目は、アクションの優先度評価は、ビジネスインパクトと開発だったり制作工数を数字化して、誰が見ても判断できるような状況にしていくことが重要かなと思っております。

また2つ目なんですけれども、実行したアクションというのはそのままにせず、ビジネスへの貢献を評価するために、事業のゴールからブレイクダウンされたKPIツリーを策定し、どのフェーズのどこに実際に効果があったのかを、正しく把握して評価をしていくことだと思っております。

顧客体験設計を通してDX VISIONを策定していくというプロジェクトは、先ほどご説明した顧客体験設計の基本フローに則って行っていきました。

このプロジェクト、最終的にどうなったのかと申し上げますと、顧客体験設計プロジェクトで描いた最適なシナリオというところを、実際のその顧客接点上で実行していくというところにありました。

理想的な顧客体験を実現するためには、CDPを使ったデータマネジメントだったりですとか、そのデータを各チャネルにマーケティングデータとして連携させ、最適なオファーを提供していく一連の流れを、マーケティングシステムを導入しながら実現をしていきました。

当社では、こういったDXを計画するための顧客体験設計だけではなく、マーケティングシステムを使ったシナリオの実行までサポートさせていただくことが可能となっております。

実例に見る「どんな組織体制でDXを推進すべきか？」

続いて「どのような組織体制でDXを推進すればいいのか？」という、プロジェクトマネジメントの領域についてもお話を進めてまいります。

このお話は、経営レイヤーでのDX VISIONを、ビジネス要件定義などを経由して具現化するということだったりとか、それを実現するための部門横断でのプロジェクトマネジメントを実現していくということでございます。

この企業は、ヴィジョンとして店頭での顧客体験の変革。例えば、店頭のショールーミング化であったりとか「試着プロセス自体のリモート化などやりたい」とおっしゃっていたりとか。初回購入時の履歴、例えばサイズ情報だったりとか色みの情報だったりとか、そういったものを活用して、再購入はECサイトをメインにしたいと。　

再購入はECサイトをメインにしていくことで、今からECサイトの売上を今と比べて10倍にしていきたい、みたいなことを掲げていらっしゃいました。課題としては、経営の指示というのがビジネス要件だったりとか、スコープ、あとはステークホルダーの整理がなされずに、自社の開発部門に、ある意味、直接降り掛かっているということでした。

また、現場の方々のヒアリングをする中でわかったことは、部門横断での細かいタスクだったりとか、課題管理ということを行っておらず、スケジュールを一旦切ったとしても、それがスケジュールどおりに公開されることのほうが少ないぐらいな管理体制というところも、課題として挙げられました。

これに対して私たちのソリューションは、一言で言えば、PMO組織を設置するということでサポートさせていただきました。

具体的には、PMO組織のミッションを経営戦略のアジャイル化と、DXの実行管理。経営アクションを具現化すること、部門横断でプロジェクトマネジメントをすることと定めて、チームを作りました。

経営戦略のアジャイル化とDXの実行管理では、旧来のウォーターフォール的な戦略設計からの具現化ではなくて、アジャイル型で小さい単位で顧客体験の変革を実行していきます。

経営アクションの具現化では、まず、その経営側からヒアリングをして、何をしたいのかというところをスタートにしますけれども、それを実際にどう実現するのかだったりとか、どのインターフェースで、どのシステムで実現するのかといった、ビジネス要件整理をするとともに、事前に実行していくためには、どの部門の誰がいつまでに動いていかなくちゃいけないのかという、プロジェクト計画というところを中心に行うことで、既存の業務部門だったりとかIT部門が、それぞれのミッションに集中できるような状況を作っていきました。

プロジェクトマネージャーに求められる、6つのスキル

そして最後に、部門横断でのプロジェクトマネジメントです。ISSUEやリスク管理、WBSと書いてしまうと簡単なんですけれども、多くのプレーヤーが関わるDXプロジェクトでは非常に複雑で、正確にISSUEやリスクを管理していくことが求められます。

実際には、経営企画部門の中にDXを推進していくPMOチームを設置いたしました。このメンバーは、クライアント様と当社からコンサルタントを派遣させていただきまして、設置しました。経営レイヤーと現場の連携であったりとか、現場同士の連携といった重要なハブ機能として機能していきました。

前半でもプロジェクトを推進していくことが一番大変だと、少し言及させていただいたんですけれども。まさに組織の中心となってくるプロジェクトマネージャーには、たくさんの高度なスキルが求められるかなと思っております。

DX推進には、PMだったりとか、PMOに属する人間の人選というのも非常に重要かなと考えております。今、映しているスライドは、当社のプロジェクトマネージャーの、スキルセットを簡単にまとめたものでございます。

例えば、複数部門にまたがる人的リソースの工数消化の状況管理だったりとか、不足があった時の問題提起、リソース追加をするぞといった解決策の検討ができるような、いわゆるリソース管理能力。

QCD（Quality,Cost,Delivery）のバランスを取りながら、必要な品質計画を推進するとともに、品質コントロールを推進していく品質コントロールの力。あとは、リスク、ISSUEの定義について正しくもちろん理解し、適切に管理をして解決方法を検討することができたりとか。適切なタイミングで上層部へ報告ができるようなリスク、課題管理能力。

あとは、経営レイヤーから各事業部門へのキーパーソンと、いわゆるコンセンサスを適切に取ったりとかしながら、プロジェクトの全体のマネージ、進行ができるプロジェクト全体の統治力。あとは、経営が求めるロードマップに対して、複数の部門のスケジュールをWBSまで分解して、それを管理していくスケジュール管理能力。

最後は、要件定義ではじめに決められたコスト計画に対して、消化状況だったりとか、不足があった場合の問題提起などを実行していくコスト管理能力。主にこの6つの能力というのが、必要なのではないか考えております。

必ずと言っていいほど直面する「システムの課題」

最後です。DXを推進する上で、我々、たくさんの企業様とやり取りさせていただくんですけれども、必ずと言っていいほど直面するのが、この「システムの課題」というところです。こちらは、とある企業の事例を元に、どういうふうにシステムの課題について回避していったのかというところについて、事例とともにお話をしていきたいなと思っております。

この事例で話す領域は、顧客接点であるインターフェースだったりとか、オペレーションを支えるシステムのブラックボックス化だったりとか。属人化と言われるものに対してどうすれば課題を解決できるのか、回避をできるのかという領域でございます。

この企業はヴィジョンとして、代理店からの紹介だったりとか、いわゆるフィールドセールス、営業マンが実際に現場に行ってというところですね。そういったところを中心とした営業活動を中心に、今まで事業を展開してきたんですけれども、それをデジタル中心の営業活動に変革したいぞということをおっしゃっていたり。

今、少ないんだけれども、Webサイト経由での年間契約者数というのを、5年で5倍にしていきたいぞということだったりとか。あとは、社のシステムの柔軟性を向上させて、経営課題としてやりたいDXタスクをどんどん実行していく。いわゆるDXプロジェクトをどんどんドライブさせていきたい、ということを掲げていらっしゃいました。

システムのアウトソース化は、なぜすぐにできない？

我々、ヒアリングする中でわかってきた課題としては、既存システムの課題はもちろんいろいろあるんですけれども。IT人材の不足みたいなところから、なかなか物事がスピーディに公開されていかないということでしたり。日々の運用業務というのがかなりリソースを逼迫していて、経営側がいうDXのタスクというところに、時間がなかなか割けないみたいな課題があったりですとか。

あとはそういったリソースを強化していくために、アウトソース化していきたいんだけれども、（スライドを指して）ここに書いてあるとおりで、ドキュメントがなかなかないことにより、外部ベンダーへのアウトソース化が実はできなかった。みたいな問題を抱えていらっしゃいました。

これに対して私たちのソリューションは、リバースエンジニアリング、マネジメントルールの向上、IT資産の整理を実施し、システムの柔軟性を向上させていくということでありました。

1個前のページで、社内のリソースを確保するために、アウトソース化を考えたとありましたが、なぜ、このシステムのアウトソース化ってすぐにできなかったのでしょうか。それは、既存システムのドキュメント不足による、中身の機能だったりとか、その仕様が不明になる状況にあることが大きな理由でした。

この状況では、既存の保守、運用はもちろんアウトソースすることは難しいですし、例えば、何かしら新規領域のシステムの構築をしたとしても、必ずと言っていいほど既存のデータ連携みたいなことを発生していきますので、必然的に既存のシステムとの連携が必要になっていきます。

また、自社のエンジニアを増員したとしても、仕様がわからないので。ドキュメント化されてなくて仕様がわからないので、教育コストに非常に時間がかかってしまったりですとか。結果、その期待されるリソース強化というのは実現されないと考えております。　

これもよくありがちなんですけれども、けっこう経営者の方で「うちのシステム、本当にブラックボックスなんで、全部1から作り直してくれませんか」みたいなことをはじめにオーダーされる方もいらっしゃいます。これもしかしながら、現状のシステムも正しい挙動とか仕様というのがわからないので、正確に作り直すことさえ難易度が高くなると言えます。

2つの課題とその対策

つまりはDXの推進には、こういったテクノロジー領域の人材のリソース確保というのは早急に必要にはなるんですけれども。自社のシステムの可視化だったりとか、ドキュメントの整備ということができていないと、アウトソースへのリソース確保はもちろん難しいですし。自社リソースを強化したとしても、期待される効果がなかなか得られないということに陥りがちだと考えております。

この時は、DXが進むにつれて起こるシステムが複雑になることと、ドキュメント不足によって引き起こされるシステムのブラックボックス化が1つ目の課題で。2つ目が、ドキュメントの管理体制がないことと、今後起こりうるIT人材不足から引き起こされるシステムの属人化。この2つの課題を、大きく指摘させていただきました。

対策としては、ブラックボックス化に対しては、既存の仕様書とプログラムソースを解析して実現するシステムの可視化。これを我々、リバースエンジニアリングと呼んでいるんですけれども、そのリバースエンジニアリングを。

属人化に対しては、ドキュメント管理が、ある意味、形骸化しないマネジメントの向上を目的としたルールと運営書の策定というのを進めていきました。

また、システムが、ドキュメントの整理によって可視化されていきましたら、このタイミングで今後のさらなるDX推進を想定して、既存のIT資産の整理というところも実施をさせていただきました。社内でリソースを使って、保守すべき領域と外部システムだったりとか、外部ベンダーにアウトソースしてしまったほうがいいような領域を定めました。

社内のリソースはなるべく顧客体験の変革だったりとか、ビジネスの貢献につながるようなプロジェクトに充て、日々の細かい運用だったりとかオートメーション化、自動化できるようなマーケティング施策などは、どんどんオートメーション化していくということをさせていただきました。

（スライドを指して）こちらは参考までになんですけれども、このプロジェクトのロードマップでございます。はじめにプロジェクトの計画をして、スコープだったりとかスケジュールというのを決めていきます。

その後にまず、システムのドキュメントを掘り起こすためのリバースエンジニアリングを実施し、外部設計書と呼ばれるものだったりとか、内部設計書、運用保守定義書、機能要件仕様書などを整備していきました。

システムの可視化、ドキュメントが整備できた後には、IT資産を整理して、さらなるDX推進に耐えうる柔軟性のあるシステムの構成、アウトソース耐異性を検討すると同時に、ドキュメンテーションが形骸化しないためのマネジメントルールを策定していきました。

これらを経て、外部ベンダーへのアウトソース化だったりとか、外部のSaaS活用だったりなどを実現していきました。