経営陣はどのようにDXに関与すべきか?──継続的イノベーションを支える「ガバナンスのポイント」

はじめに

デジタルトランスフォーメーション（以下、DX）の必要性は広く認知されるようになりました。一方で「DXに成功した」と自他共に求める企業は少ないと思われます。私たちはDXに苦戦しており、その成功要因を探し求めています。

成功のカギの1つは、経営陣が適切にDXに関与することです。では、具体的にどのような点に気をつけるべきなのでしょうか。

本稿では、経営陣の関与のポイントをガバナンスの観点から考察し、「数あるDX施策を取捨選択し、成功施策を生み出す意思決定」と「成功DX施策のサービス信頼性の確保」の2つについて紹介します。

1 そもそもなぜDXに取り組むのか？──DXは変化点でもあり、道のりでもある

DXの目的は時間軸によって異なります。短・中期的な時間軸（例えば3～5年）において、DXの目的は「企業価値向上」です。企業価値向上とはステークホルダーに認められる価値の増大であり、具体的には非財務・財務インパクトの創出です。これらはデータ活用、他社との協創、ビジネスプロセスの再構築等の具体的活動の蓄積によって達成されます。

長期的な時間軸（例えば10年）においては、DXは「生存の前提条件」です。本特集の記事「データ戦略に関する政府の動きとデジタル社会に求められるトラスト」の「1.3 データ戦略のアーキテクチャ」にも見られるように、第四次産業革命によって社会構造は大幅に変わりつつあり、新しいビジネスモデルの登場が不可避です。蒸気機関の出現によって手工業のほとんどが衰退したように、既存のビジネスモデルも破壊的変化の中で衰退していきます。デジタル技術を生かしながらこの変化に適応することがDXの目的です。

DXは短・中期的な非財務・財務インパクトを目指すものでありながら、長期的には「変化への適応を続けるためにイノベーションを継続的に起こす道のり」とも言えます（図表2）。

2 VUCA時代のイノベーションで注意すべきこと──「成功要因が分からない」そして「サービスの信頼性確保が難しい」

長期的な目的を踏まえると、「DXの成功」は以下のように表せます。

不確実性に対応可能な、変化を好む組織文化の獲得
上記に根差した、継続的なビジネスインパクト創出能力の獲得

DXの成功を支えるのはイノベーションの素地であり、この点においてはDX以前の事例からも多くの成功要因を抽出できるでしょう。例えば、フィルムの現像技術を複合機や医療機器などの別の用途に生かすなど、市場が縮小している事業の技術を他分野に活用する事例は過去にも多くあります。こうした事業ポートフォリオ再編の事例には、DXを成功に導く多くのヒントがあります。

一方で、VUCAと呼ばれる現代の状況においては、考慮すべき要素が2つあります。

1点目は「ビジネスの成功要因を予見することがさらに難しくなったこと」です。IT基盤の発展によってサービスのローンチスピードは上がり、顧客にとっての選択の幅は広くなりました。顧客要求はより不透明・不確実・曖昧なものとなり、初期計画に重きを置くウォーターフォールモデルの効果は低くなり、市場から直接フィードバックを得ながら価値創出を目指すアジャイルモデルが重視されるようになりました。

2点目は「事業の信頼性確保がより難しくなったこと」です。デジタル事業を支えるのはIT 基盤です。これらの管理に不備があれば、リスクが顕在化し、サービスに深刻な影響が出ます。さらにIT基盤は「システム・オブ・システムズ（System of Systems）」と呼ばれる複数のシステムの連携によって複雑系の様相を呈しており、それによってリスク管理も非常に困難なものとなりました。

3 ビジネスの成功要因が見通せない環境での取捨選択とは？──ステークホルダーニーズを踏まえて意思決定を主導する

一般に「DXプロジェクトの7～8割は失敗する」と言われています。中でも新規ビジネス創出プロジェクトの成功率は特に低くなります。しかし、個別の失敗は必ずしもDXの道のりの失敗を意味しません。失敗を伴う挑戦の試行回数は持続的イノベーションの素地だからです。ただし、大きすぎる失敗は挑戦する財務的体力と意欲を奪い、DXを断念する事態を招きかねないため、個別の失敗は小さいものでなければいけません。

そのため、失敗の影響を許容可能な範囲に限定しつつ、失敗を織り込んだ試行回数を増やし、成功につなげていく意思決定の仕組みが必要です。この仕組みは、事業開発で重要視される「リーンスタートアップ」と「ステークホルダー利害を調整するガバナンス」によって説明できます（図表3）。

リーンスタートアップは、仮説による初期計画、最小限プロダクトのリリース、効果計測、計画見直しを何度も繰り返し、価値を「探索し発見する」フォワードキャスティング型の手法です。

例えば、初期事業案では特定の用途の動画のみを共有するサービスを想定し、最小限プロダクトとして限定的な動画共有機能をリリースしたところ、想定以外の用途での動画共有に大きなニーズがあることが分かり、事業方針をピボットしたことで著しい成長を遂げたといった事例があります。

このように、最小限の製品あるいは施策をリリースし、施策への反応を受けて計画を修正・中止する「探索と発見」は、不確実性が高い領域でのプロジェクト進行に有効です。一方で、継続・中止判断・ピボットの意思決定は、実行に移そうとすると非常に複雑です。組織の状況・背景により「目指す成功像」も「許容可能な失敗の水準」も異なり、継続・中止・ピボットの判断基準をKPIのみでは表せないからです。ここに複数ステークホルダーの期待値を調整するガバナンスの重要性があります。

ガバナンスの観点では、以下のような問いかけを行います。これは、自社の存在価値からバックキャスティング的にプロジェクトを見極めることを意味します。

当プロジェクトは当社のDXの道のりにどのようなベネフィットを及ぼすか？
ベネフィットは企業理念やパーパスの達成にどのように関連するか？
ベネフィットの価値を投資家・債権者等はどう解釈しているか？
ベネフィットの価値を、関連コミュニティ（地域社会、労働組合等）はどう解釈しているか？
ベネフィットの価値について経営陣で共通認識を持てているか？
プロジェクトの推進者が目指す価値創出と、経営陣が考える価値は整合しているか？
当プロジェクトの方策は企業のフィロソフィーに合っているか？

上記の問いを突き詰めるためには、必ず経営陣の強い関与が必要になります。ガバナンスが不足すると、以下のような状態に陥ります。

経営陣それぞれの考えていることが微妙に異なり、推進者に異なるメッセージが伝わっている
経営陣がDX推進状況を適切に把握しておらず、プロジェクト推進者との間に温度差がある
DXの価値を利害関係者に認められない

これらはDX推進に蓄積的なダメージを与え、DXの道のりは失敗する可能性が高くなるでしょう。

ガバナンスを高度に実践するには、外部の第三者を利用してステークホルダーニーズに応じた対応となっているかチェックすることも有用です。

例えば、アジャイルツールを全社的に導入するプロジェクトにおいて、事前検証とベンダーとのコミュニケーションが十分でなく、期待過多の状態でプロジェクトが本来の目的に適さない方向に進んでいたため、経営がプロジェクトを止める判断を行ったといった事例があります。

企業理念や顧客、投資家、経営陣の期待を横断的に視野に入れ、現場の状況を評価することは、社内だけでは実施が難しい場合があります。そういった混沌とした状況を客観的目線から評価、アドバイスできるのは第三者評価機関の強みです。

変革の実践は大きな投資を伴うものであり、意思決定にはガバナンスが必要です。また、ガバナンスの在り方にもさまざまな試行が必要とされるため、変革を目的とする環境（「実験環境」や「サンドボックス」と呼ばれる）を用意し、その領域で試していくという工夫も必要でしょう。

4 成功施策の信頼性を確保しつつ事業を拡大するには？──リスク対応に積極的に関与する

DXを推進し、有望な事業を育てたとします。その事業は高度にデジタル化され、IT環境を基盤としているはずです。IT環境に何らかの不備があり、社会的影響を及ぼす事故が発生した場合、せっかく育てた事業の拡大は停止し、致命的なダメージを被る可能性もあります。したがって新規事業の拡大期には、IT環境のリスクを適切に管理していく必要があります。

一方で、闇雲に既存のリスク管理のルールを当てはめたり、ルールを厳しくしたりするのは得策ではありません。IT環境で発生するリスクは多様で、それらの発生可能性や影響度、特徴に応じた対応が必要なためです。そうした考慮が足りない場合、開発の柔軟性を失われ、ビジネススピードを損なう恐れがあります。

「ビジネススピードに直結する開発の柔軟性を維持しつつ、事業の信頼性を確保する」。この難問を解決するには、ステークホルダーニーズを意思決定に含めるガバナンスが重要になります。例えば、以下のような問いが有用でしょう。

事業における事故が発生した場合、誰に被害が及ぶか？
その被害はどの程度深刻なものであるか？自社にどの程度の影響を及ぼすか？
利用者の事業への期待値はどのようなものか？

こうした問いかけを行っていくことで、事業の信頼水準を定め、適切な内部統制を構築できます。これは事業に責任を持ち、ステークホルダーのニーズを見渡すことができる経営陣が関与してこそ実現できます（図表4）。

ここで、事業の信頼性と拡大を両立しつつ、内部統制を構築する場面をケースとして紹介します。

ある事業では、AIを用いた革新的ソリューションを顧客に提供しています。開発部は、「DevOps（デブオプス）」という先進的開発運用手法を採用し、エンジニアがチーム一丸となって、運用業務で得た顧客フィードバックを開発作業に生かすことで、質の高い改善を高速で実装し顧客価値を実現しています。事業拡大のフェーズに差し掛かり、リスク管理部門が当事業部にIT管理ルールの適用を迫りました。具体的には、システムの一般的な信頼性確保の仕組みとして、開発保守業務と運用業務の職務を分離することが求められました。

しかし、これでは開発部の最大の強みである「質の高い改善を高速で実装し、顧客価値を実現」できなくなります。そこで「顧客価値とは何か」「事業リスクは何か」「IT環境に適した内部統制の在り方は何か」といった問いを、事業責任者も含めて部門横断で検討することで、当初のIT管理ルールを見直し、開発チームのコアコンピタンスであるスピードを失うことなく適切な内部統制を構築できました^※1。

ビジネススピードと信頼性を両立すべき場面は今後一層増えてくるでしょう。その際は闇雲に対応するのではなく、①ステークホルダーニーズに基づいて信頼水準を決定し、②その信頼水準を満たす内部統制を現場との協働で構築することが重要になります。

5 最後に

本稿ではDXの目的に立ち返り、成功要因を高めるガバナンスに言及しました。DXは破壊的な変化に対応し続けるジャーニーです。個別施策の成功率を高める方策も重要ですが、ステークホルダーニーズを踏まえて意思決定をし、信頼性を高めていくためのガバナンスも重要です。

本稿で述べた「ステークホルダーニーズを踏まえた意思決定を主導する」「リスク対応に積極的関与をする」という観点が、長期的なDX推進の取り組みの中で少しでも参考になれば幸いです。

※1 なお、本事例についてケーススタディを含む記事を公開しています。コードも含めた詳細事項を取りまとめているので参考にしてください。PwC「トラストをともに駆ける――DevOpsにおけるコンプライアンス対応の要所」2022–03–04
https://www.pwc.com/jp/ja/knowledge/thoughtleadership/dev-ops220228.html

執筆者

PwCあらた有限責任監査法人
システム・プロセス・アシュアランス部
パートナー宮村和谷

PwCあらた有限責任監査法人
システム・プロセス・アシュアランス部
シニアアソシエイト小田切洋介