依頼する側もされた側も疲弊する「技術者任せのデータ分析」　DX推進を難しくさせる、3つの高い“壁”

実務担当者が抱く、DXへの“本音”

古嶋十潤氏：本日はご参加いただきありがとうございます。『DXの実務』著者の古嶋です。このウェビナーでは本書を題材として、DXの実務上重要な観点について、いろいろとお伝えしていきます。

さて、昨今DXのウェビナーはいろんなところで開催されているかと思いますが、よく話題にされる内容としては、「DXとは何か？」、「国内のDXの成功度合いは？」、「DXを取り巻く市場環境は？」みたいな、ややもすると堅苦しい内容が多いのかなと思います。

なので、このウェビナーでは趣向を変えて、DXへの“本音”、『DXの実務』で重要な観点、『DXの実務』で伝えきれなかったこと、の3つについてお話しできればと思います。特にDXへの“本音”については、私がコンサルタントとして色々な企業のDX支援をした中で、実務担当者の方々がおっしゃっていた“本音”や、私自身が実務担当者としてDX推進してきた中で抱いた“本音”を踏まえてお話ししたいと思っています。

では、さっそくDXへの“本音”について、私の個人的な見解を述べていきたいと思います。

DXの難しさの3つの原因

プレスリリース等で成功事例として挙げられているDXの取り組みは、非常にきれいにまとめられていることが多いですが、私の経験上、なかなかそんなにうまくはいかないと考えています。私自身現職でデータやAIを使う会社に勤め、前職では多くの企業とDX戦略構築やDXの実務の支援をさせていただいていたんですけど、過去も現在も本当に苦労する毎日です。

このDXの難しさの原因が何にあるのか？ というのは、今一度考える必要がありますし、そこを考えることによって打開策が見えてくるのかなと、個人的には思っています。

本日お集まりいただいたみなさまも、日々、DXの実務に取り組んでいらっしゃると思いますが、なかなかうまくいかないことが多いのではないでしょうか。

本書では、その難しさの原因を3つ挙げています。1つ目は「膨大な変革スコープ」、2つ目は「各種技術の理解・実装・運用・改善の遂行」、3つ目は「DX人材への要求水準」。この3つが、実はとてつもなくハードルが高いのではないか、というのが私の考えです。

DXの対象領域は、企業活動と顧客行動のクロスする部分

どういうことか、1つずつご説明します。まずは、変革のスコープ。この図は縦軸に企業活動、横軸に顧客体験を示しています。企業活動というのは、要はバリューチェーン。「マーケティング」の部分から「調達／開発」「製造／物流」「広告」「店頭販促」「CRM」みたいな、企業活動の流れです。

この企業活動がなぜ存在するかというと、「顧客を獲得するため」ですよね。顧客はいきなり獲得できるわけではなくて、顧客にはそもそも「行動」がある。商品とか会社を「認知」する、個人情報を「登録」する、「来店」してくれる、商品を「購入」して、「評価」をしてくれる、という流れがある。

ここで重要なのは、企業活動と顧客行動のクロスする、このマス1つずつがDXの対象領域だということを、認識することだと思っています。

どういうことか。DX推進には、大きく3つのパターンがあると私は考えています。例えば、最近よく見られる、店頭に来店したりWebページに訪問した時に、SNSやアプリなどで広告がプッシュ通知されるような仕組み。それは「広告」という企業活動と、顧客の「来店」という行動がクロスする、このマスに対してDX施策がされているということです。

他にも、顧客情報の登録時点でクーポン贈呈、といったこともよくありますよね。Web会員登録してくれたら、Amazonギフト券を進呈、みたいな。これは「販促」活動とユーザーの「登録」活動、この交差する部分でDX施策をやっているということです。

いきなり「全方位的に施策を展開」しようとするからハードルが高い

これがうまくいくと、第②のパターンとしてこの活動を“水平展開”していくわけです。例えば、決済アプリ。PayPayとかAmazon Payのような決済アプリを開発し、施策としてうまくいった後に広告機能を搭載すると、もともと買おうと思っていた商品以外のものに対して顧客の意識が働いて、それも買うかもしれない。これは「広告」という活動が、ユーザーの行動に対してより広く、“水平に”広がって施策が打ち込まれているということですよね。

このような過程を経て、最終的にはパターン③のように全方位的に施策を展開していく。こういった流れがあるべき進め方なんじゃないかと、私は考えています。

ですが、いきなり「パターン③」からやろうとしているケースが、本当に多いと思います。よくよく考えると、それって相当難しいことをやろうとしている。

パターン③とはつまり、このマスを数多く包含するDXのレベルの取り組みだ、ということです。それってとてつもなくハードル高いですよね。なので、順々に「パターン①」から、しっかりと地に足をつけて進め、徐々に領域を広げていくという方法が、うまくいくためには重要なんじゃないでしょうか。

一連のシステムを作るには、関係者が多くなるのが必須

続いて、各種技術の理解・実装・運用・改善の遂行です。例えば、Webサービス。ECサイトでも何でもいいんですけど、そこにAIを実装する場合を想定します。例えばAmazonみたいなECサイトに、自動的にそのWebページに訪問した人に適切な商品をレコメンドするAIを作ろうと思うと、簡単に図示するだけでも、このくらいの必要な要素があります。

Webページ上に訪問したユーザーのデータをログサーバに集めて、集まったデータはそのままじゃ使えないので、データレイク、データウェアハウス、データマートなどに順次変換・格納していく。次いで、変換・格納したデータを使って、機械学習システムを作っていこうとすると、AIの予測モデルを作る必要があります。

集まったデータをデータサイエンティストが分析したり、いろいろとモデル検証してテストして、そのテストがうまくいったと判断されたら、本番環境にデプロイされる。継続的なデプロイ、運用には、モデルを実装する機械学習システムのエンジニアが必要だったり、保守・運用するエンジニアが必要だったり、モデルの開発そのものはデータサイエンティストが作ったりというように、一連のシステムを作ろうと思ったら、関係者が非常に多くなります。

さらに、このケースはECサイトを想定しているので、Webエンジニアも必要ですし、サーバサイドのエンジニアも必要ですし、本当に多岐にわたる関係者が必要です。

データ分析だけでも、工程が「ブラックボックス」する技術的な壁

一方で、もっとシンプルな「データ分析を依頼する」ということだけでも、実はけっこう難しいシーンがあるのかなと思っています。簡単なExcel分析くらいだったらまだ進めやすいですが、データサーバ上にある半構造化データみたいなものを、SQLとかPythonを使って分析しようと思ったら、事業側の人ではできる人って稀ですよね。

だから、技術者側にお願いすることになるんですけど、その依頼のやり取りでけっこういろんなことがある。事業担当者側は、データ関連の技術を扱うことができないので、技術者に依頼するしかない。その後も、技術者側の業務詳細が理解できないので、どのくらいお願いしたことが進んでいるかわからない。結果、分析結果のアウトプットが出てくるまで、工程が「ブラックボックス」になってしまう。

一方で、技術者からすると、説明を受けてもなかなか課題がちゃんと理解できず、言われるがままの場当たり的な分析がどうしても起きてしまう。また、アウトプットを出してみると「お願いしたことと違う」と言われてしまって、また同じことの繰り返しで疲弊してしまう、といった場面は決して珍しくないと思います。

このあたりの技術的な壁が、DXの実務ではたくさん存在しているのではないでしょうか。

「やってみないとわからないことばかり」のハードルの高さ

3つ目は「DX人材への要求水準」です。データ分析に始まり、いろいろとステップアップしていって、最終的に大きなDXを実現しようと思ったら、ここまで述べてきたようなことは、一つずつ克服しなければ実現は難しいのではないでしょうか。

しかも、DXの取り組みってほとんどが新しい内容なので、うまくいくかどうかも事前にはわからないケースばかりだと思うんです。非常にハードルが高い。

こういった理由から、DXってとてつもなく難しいチャレンジだと考えています。まさにこのことが、私が本書を書こうと決心したきっかけです。

そういったところを解消するために、本書『DXの実務』の目次はこのような設計になっています。Part1からPart3は変革のスコープに対応するもの、part4からpart5については実務の部分に対応しており、人材要件の部分はPart6と整理しています。

今日、これらをすべて解説することは時間的制約上できないので、特に重要な「フレームワーク」の部分に焦点を当てて、『DXの実務』で重要な観点、『DXの実務』で伝えきれなかったこと、この2点についてご説明していけたらと思っています。

『DXの実務――戦略と技術をつなぐノウハウと企画から実装までのロードマップ』