はじめに

こんにちは。野村総合研究所の廣田です。
前回の記事では、日本企業がDXを推進するときに直面する3つの問題点について説明し、日本流のDX推進の必要性について述べました。

• ①IT部門の視点     ：

  ウォーターフォール型しか採用できない開発プロセス

• ②業務部門の視点：

  業務部門の技術理解度・当事者意識の低さ

• ③経営の視点         ：

  意思決定者が曖昧になってしまうほどの過度な現場主義

こうした問題を解決するために、DX推進における慣習そのものを米国企業並みに変えるという選択肢もあります。ですが、慣習は長年かけて形作られてきたものであり、短期間でそうそう変えられるものではありませんし、また良い面も持っています。今回は、慣習を大きく変えなくても実現可能な、DXの進め方をご紹介します。
DXと言っても、既存業務を革新したり、顧客体験（CX）を大幅に向上したり、全く新しいサービス・事業を生み出したりと、様々なタイプがあります。ですが多くの場合で、データをいかにうまく活用するかがキーになっています。業務やサービスに使うシステムにデータ分析モデルを組み込むことによって、DXの実現によって生み出される価値を高めている例があります。ここからは、システム上へのデータ分析モデルの構築を取り上げ、上記の問題点に悩む日本企業がDXを成功させるために、どの様に進めていけばよいかについて紹介していきます。

執筆者プロフィール

廣田 壮一郎：
2015年NRIに入社。アナリティクス技術を用いた業務変革やデジタルマーケティングを経験。その後、デジタル組織立ち上げやデータマネジメント設計といったコンサルティングに従事。現場の実情に配慮した机上の空論に留まらない実践的なDXプロセスの開発・普及に取り組む。

• プロセス整理の必要性
• PSG-Analyticsの
  3つのフェーズ
• まとめ

プロセス整理の必要性

データ分析を行うには、データ分析モデルをシステム上に構築する必要があります。通常、データ分析モデルはPoCから始めていきます。このPoCの実行までは行えている企業は多いです。課題はPoCを終えた後にあります。一般的なプロセスが整理されていないため、具体的にどう活動を進めてよいかわからず、活動が前に進まないのです。結果としてPoCばかり量産してしまい、いわゆるPoC疲れを引き起こしています。

このプロセスの重要性については、実際に企業側からも重要視する声がでています。以下のグラフは日本情報システム・ユーザー協会（JUAS）と野村総合研究所（NRI）で共同調査した、デジタル化の取り組みに関する企業の意識調査の結果です。グラフの赤枠内を見ていただくと分かる通り、関係各所との合意形成や協力獲得が重要だと感じている企業が増えています。これまで重要視されていた戦略や人材に関するところから、DXを進める際のプロセスに注目が集まってきているのが分かります。

そこで私は、これまでの経験を踏まえて、分析モデル・システムを構築する際のプロセスを纏めた『Prototyping Stage-Gate for Analytics（PSG-Analytics）』というマネジメントプロセスを設計しました。名前からも分かる通り、プロトタイプ型の開発手法とステージゲート法の考え方を取り入れています。このプロセスは以下の通り前述の問題点を解決する様に設計しました。

• ①IT部門の視点     ：

  ウォーターフォール型しか採用できない開発プロセス

• ⇒

  PoCの繰り返しサイクルで表現されがちなプロセスをウォーターフォール型と同様になるべく直線的なプロセスとして定義

• ②業務部門の視点：

  業務部門の技術理解度・当事者意識の低さ

• ⇒

  業務部門をモデルに対する理解を深める・巻き込むためのフェーズとしてプロトタイプの試行を行う業務検証を定義

• ③経営の視点         ：

  意思決定者が曖昧になってしまうほどの過度な現場主義

• ⇒

  各フェーズの節目に意思決定ポイントを定め、Stop＆Goの判断をどの様に行うべきか明示

ここからは、上記工夫を取り入れたPSG-Analyticsの内容について紹介します。

PSG-Analyticsの3つのフェーズ

PSG-Analyticsでは、概念実証（PoC）、業務検証、本番開発・展開という3つのフェーズを定義しています。フェーズごとに、そのフェーズにおける達成すべきゴールと推進主体を定めています。フェーズの切れ目で、次のフェーズに向けて意思決定すべき観点を明確にしています。

(1) 概念実証（PoC）フェーズ

まず概念実証（PoC）では、「投資対効果の概算」がゴールとなります。データサイエンティストが最も活躍するフェーズです。本フェーズでは、モデルを完成させる必要はなく、机上で投資対効果を概算するために必要な最低限のモデルを構築できれば十分です。概算の投資対効果次第では、早々に活動を止める意思決定を促すことができ、止め時が分からなくなってしまうプロジェクトを減らします。

(2) 業務検証フェーズ

PoCの結果、十分な成果が見込めるとなった場合には、次の業務検証のフェーズへと移行します。最初に意思決定者を明確にし、なるべく分析モデルを利用することになる業務部門が確保した予算・策定した計画内で活動します。

このフェーズでは、開発計画を策定するために新業務・システム要件を洗い出すことがゴールとなります。その際、要件を決めるのはデータサイエンティストではなく、業務部門です。そのため、業務部門自身が構築されたモデルの挙動を理解していなければなりません。そこで、業務部門がモデルを実際に使える状態にするため、簡易ツールと呼ぶモデルに最低限のインターフェースを用意しておきます。PythonとExcelを連携させるライブラリを活用し、業務部門が使い慣れたExcelからモデルを実行できる様にした簡易ツールをよく提供しています。

業務部門は簡易ツールを実際に使いながら、モデルの挙動を理解し、要件出しに繋げていきます。業務部門が洗い出した要件を意思決定者が確認し、次の本番開発・展開フェーズへ進んでも良いかどうかについて意思決定します。意思決定者が自身で内容の可否を判断できない場合は、自ら簡易ツールを触るなどして理解を深めるのが重要です。可否が判断できない、簡易ツールを理解しようとしない意思決定者は失格と言ってよいでしょう。（因みに、意思決定者はStop＆Goの意思を持って判断する人と定義しており、いわゆる本部長の様な予算決定者とは分けて考えた方が良いです）

(3) 本番開発・展開フェーズ

業務検証が終われば、いよいよ本番開発・展開のフェーズです。本番開発・展開は文字通り本番システム・ツールの完成がゴールで、業務部門とIT部門が共同で進めていきます。本フェーズまで到達すればある程度要件も洗い出せているため、慣れ親しんだウォーターフォール型で開発を進めても問題無いです。

ここで注意が必要なのは、本番開発・展開が終わった後もモデルの改善業務を継続する必要がある点です。詳細な説明は省きますが、機械学習モデルはリリース後もMLOpsと呼ばれる手法に則った改善を継続する必要があります。アジャイルで進めた方がリリース後の体制に繋げやすい場合もありますが、社内の開発ルール上ウォーターフォールしか選べないケースもあると思います。自社の開発ルールに合った手法を選ぶことがポイントです。

加えて、これまで説明した3フェーズを事前に計画として整理しておき、PoCを始める前から各体制や意思決定者の巻き込みを図っておきましょう。活動が進んでからだと、よく分からない活動に巻き込まれそうだからと避けられてしまうかもしれないからです。

まとめ

2回の記事を通じて、日本企業のDXがうまくいかない問題点と、いかにそれを乗り越えてDXを進めていくかについて説明してきました。

DXは難しいというイメージを持たれているかもしれませんが、進め方さえ間違えなければ成功率をグンと高めることができます。注意して欲しいのは一つ一つの問題点だけを見て改善するのではなく、記事で述べた観点からバランス良く改善していく必要があるという点です。
もちろん進めていく中で一筋縄ではいかないこともあると思います。その際にはぜひともご相談いただければと思います。

関連記事

コラム

日本企業はどうしてDXが下手なのか？～日本に合ったDX推進の必要性～

多くの日本企業がDXを積極的に推進しようとしていますが、上手くやれている企業は下図からも見て取れる様に多くはありません。米国企業に比べて、日本企業はDXが不得意のように見えますが、なぜなのでしょうか。

DXブログ一覧ページへ

システムコンサルティングトップページへ

執筆者情報

• 廣田 壮一郎

  システムデザインコンサルティング部