経産省のDX解釈が、結構痛烈で面白いから読んでほしい
こんにちは。Co-Liftのミドリです。
突然ですが、
「DX」
というと何を思い浮かべますか?
DX = Digital Transformation の略というのはご存知の方も多いと思います。
でも、DXとは?と言われると、「何らかのプロセスをデジタル化したもの」くらいのフワッとしたイメージを抱かれることも多いのではないでしょうか。
ほら。こんなイメージ。
デジタルっぽい画像に、DXって書けばそれらしく見えちゃう。
でも、イメージだけでは話が進まないので、ちょっとDXの定義について考えてみましょう。
経済産業省のDXの定義
経済産業省では、DXを以下のように定義しています。
少し整理するとこうなります。
↓↓↓↓↓↓↓↓
要は、「データとデジタル技術を活用して、競争上の優位性を確保する」ことが出来れば、WHATは何でもアリなのかなと。
「競争上の優位性を確保」出来ているというのが、ミソかもしれないですね。さらっと書いているけど、実はこれが一番難しいですからね。
この経産省の『「DX推進指標」とそのガイダンス』の冒頭部分でも触れられているのですが、多くの日本企業で、デジタル部門が設置される動きはあるものの、実際のビジネス変革には繋がっていないと痛切に書かれています。
経産省も指摘している「これじゃダメだよDX」
これが、経済産業省が指摘しているダメDXの例です。
結構痛烈で面白くないですか?
ひとつ一つを、Co-Liftなりに解釈していきましょう。
1) 顧客視点でどのような価値を創出するか、ビジョンが明確でない
よくあるのが、HOWだけ先に決まっちゃうパターン。
ペーパーに書かれているように「AIを使ってやれ」と言われるのはまだ良い方で、下手すれば「DXやれ」の号令のみの場合も。
こうなるともはや指示でも何でもなくて、ギャグにしか聞こえないレベルなんですが、たまにあるから恐ろしい。
2) 号令だけでは、経営トップがコミットメントを示したことにならない
1)にも関連しますが、結局経営トップがコミットしないことにはDXは進められません。
・トップの号令でDX組織を作ったが、予算が十分にない
・必要な人材の採用・育成が行われていない
など、パッと思いつくだけでも、陥りがちなDXの課題はたくさんあります。
でも、実はもっと根深い課題として「失敗の許容」があるのではないかなと考えています。
以前もこのnoteで「デジタル・プロダクト開発の多くは、課題のゴールをあらかじめ決めることが難しいオープン・エンドな課題」であると触れました。
記事はこちら。
DXはまさに、オープン・エンドな課題。
・あらかじめゴールを決めることができない
・ゆえに、緻密に計画を立てることは有効ではない
・顧客のフィードバックを得ながら、仮説検証を繰り返す
上記の「仮説検証を繰り返す」ということ。
さらっと書いていますが、実はこれが企業文化によっては非常に難しかったりするんですよね。
DX推進するためには、一回の試行錯誤で成功するわけもなく、何回も失敗してはまた仮説を立てて試行して・・・を繰り返すことになります。
また時には、既存のサービスやプロダクト、組織の存在を脅かすようなデジタル・サービスを創出しなくてはならない場合もあるでしょう。
例えば、日本の伝統的な生命保険会社は、大きな営業組織を持ち、顧客に寄り添った細やかな営業によって業績を伸ばしてきた経緯があるわけですが、そうした伝統的な会社が「提案→検討→クロージング→契約」に至るすべての工程をデジタル化して、新しい顧客価値を創造するにはどうしたらいいでしょう?
DX推進部の部長が頑張れば良いという話ではありません。
DX推進部だけが頑張っても、既存の営業組織からの反発が起こるのは必須。ユーザー調査、商品開発もなかなか一筋縄にはいかないことが想像できます。
じゃあ、誰が頑張ればいいか?
いや、誰が頑張らないと進められないのか?
答えは明白ですよね。
そう、経営トップです。
トップがコミットし、それを推進するためのリソース(ヒト・モノ・カネ)をしっかりと確保し、さらに失敗を許容する企業文化を醸成しない限り、DXはうまく行かないと考えています。
3) DX による価値創出に向けて、その基盤となる IT システムがどうあるべきか、認識が十分とは言えない
この3つ目の課題に対して、経産省のペーパーではこれまた辛辣な一言。
「IT システムの話になると、経営者は IT 部門に任せてしまう」と、わざわざフォントをボールドにして訴えてます。
めっちゃわかるーーー!!!
と、頷きすぎて首もげそうになる人、結構いるんじゃないですか?
DX推進による価値(To-Be)を創造するためには、当然、その基盤となるシステムがどうあるべきかを定義しなくてはなりません。
そして、その定義をシステムベンダーやIT部門に丸投げするのではなく、DX推進する主体(時には経営トップ)も、どんなシステム基盤でなくてはならないかの認識を揃える必要があると示唆しています。
ここで、
「よっしゃ!じゃあここは一発、ビジネス側のやりたいこと(To-Be)をシステム的に書いたりましょ!!!」
とビジネスサイドが描きがちなポンチ絵がこちら。
よく見ますね。
閲覧・購入データを元に、MAツール使ってパーソナライズ 的な。
でも、これじゃダメなんです。
なんでダメかって言うと、
システムを開発する際に、決めなくてはならない重要な論点が、全くこれだけでは分からないからです。
例えば、閲覧履歴。
・そもそも閲覧履歴って、どんな情報をどうやって取るの?
・1回サイトから離れて、30分後にまたサイトに戻ってきた人の訪問回数は、1回とカウントするの?それとも2回?
・閲覧履歴と購買履歴は同じシステムで取るの?別々ならどうやって統合するの?
・どんなデータマート(人や別システムが利用しやすい形式に変換されたデータ)が必要なの?
などなど。
こうした論点は、一見、システム固有の細かい情報にも思えるのですが、実はビジネス意思決定に大きな影響を及ぼします。
例えば、商品ページの閲覧履歴を取得したい時。
閲覧ページ上に含まれる情報(画面に表示されている情報)だけでは、あるユーザーが数日後にどんな商品を買ったのか、そもそもどんな属性か(年齢、居住地域など)、その商品の画面に表示されていないメタ情報(仕入情報のような内部的な管理情報)といった情報と紐づけることは出来ません。ユーザーIDや商品IDのような紐付けるためのIDを元に、内部のデータベースを参照するといった機能が必要になるかもしれません。
もしくは、商品の価格が日々動的に変わる場合、ユーザーが閲覧したタイミングで表示されていた価格まで管理していないと、「どの価格帯の時が一番売れるか」といった分析が出来なくなります。
上記はほんの一例ですが、こういった論点は、日々ビジネスの現場に接していて、今後どのように展開していきたいのかという仮説と、その仮説検証に責任を持っている立場の人でないと解を出せないことが多々ありますし、そもそも論点として見落とされることも多々あります。
また、オープンエンドな課題では、全てを事前に計画して作ることは不可能で、仮説検証に必要なものから最小限のモノを素早く作って市場に問うことになるため、作るモノやその優先順位の不確実性が高く、解像度の高い意思決定が随時求められることになります。
だから、システムに係る重要な論点は、システムベンダーやIT部門任せにせず、ビジネスサイドもしっかりと解像度高く、認識を揃えておかないとならないのです。
じゃあ、システムに係る解像度を高くするってどう言うこと?
「システムに係る解像度を高くする」というと、大半のビジネスサイドの人は「開発の専門知識を学ばないとダメなのか」と尻込みしてしまいます。
そして、頭の中でこう考えます。
「開発の専門知識を今から学ぶなんて無理」
「会社のIT部門に任せよう」「開発ベンダーに任せよう」
でも、そうではないんです。
IT部門や開発ベンダー任せにしてしまったら、結局、DXに必要な重要論点が、ビジネスサイドによって議論されずに終わってしまいます。
でも実は、システムの専門知識をみっちり仕込まなくても、システムに係る解像度を高めることは可能です。
高度な専門知識は必要ないものの、大変な作業であることは間違いないので、Co-Liftでは演習も含めた研修パッケージをご用意しています。
手前味噌ではありますが、Co-Liftの研修は結構好評をいただいておりまして、「難しいけど理解が進んだ」「自分がこんなに出来ないとは思っていなかった」と、受講した方に心地よいショックを与える内容となっております。
noteでは、その研修のプロローグをお伝えできればと考えています。
ご期待ください!
この記事が気に入ったらサポートをしてみませんか?