データ分析の目的と事業目的の違い

データ分析においては、よく目的がないままやっても成果が出せないとよく言われます。

すなわち、データ分析はまず最初に目的をきちんと定めることが必要ということのようです。

ただし業務として行っている以上、そもそも目的なく行うということなどあるのでしょうか？

通常の業務は事業目的を達成するために行うものです。

そのためデータ分析業務もその事業目的の達成に直接的でないにせよ、関わっているはずです。

つまり目的なきデータ分析などありえないはずです。

しかしデータ分析の依頼を受けたアナリストは、たびたび目的のないデータ分析はやっても意味がないと不満を持つようになります。

依頼者がただそのデータを見てみたいという思いだけの依頼ならば、事業目的の達成にはおそらく何の関係もないだろう

一応依頼者からすればデータを見たいという目的があるようだが、それも特に意思決定などに関わるものでないならば達成しなくても何も変わらないだろう

まあ気持ちはわからなくもありません。

しかし本当にそうなのでしょうか？

依頼者は暇つぶしをしたわけではないでしょうし、分析者に嫌がらせをしたいわけでもないでしょう。

基本的には事業目的につながるための何かのヒントを得たいとか、考えを整理したい／絞り込みたいという思い（＝目的）があるはずです。

ただ依頼者も説明不足であったり、そうした思いを叶えるデータを適切に依頼できていないだけというケースは非常によくあります。

分析者側もそうした際にそこで思考停止して、納得できる目的を教えてもらえるまでデータを出したくないとか言ってるようではデータアナリストとしてお粗末です。

事業目的とデータ分析の目的に違和感があったり、ギャップがあるのであればそこを一緒に検討するのもデータアナリストの重要な業務です。

経験上、依頼者は次のようなことを調べたいときによくデータ分析の依頼をします。

・何らかの事象の原因を突き止めたい

・次にどうすれば良いか検討したい
　→そのための選択肢を検討したい
　→その選択肢の取捨選択をしたい

データ分析とは、対象の要素を分解して比較し、その違いを明らかにすることです。

そのため、対象の原因調査や対象の要素の良しあしの比較といったことは分析と言えるでしょう。

しかしそうしたことを分析するためにどのようなデータを見れば良いのかまで、依頼者が正しく設計できるとは限りません。

そこで、データアナリストがそうしたデータ分析の設計まで担えると上手く進みやすくなるでしょう。

あともうひとつ、データアナリストの理想形のひとつを紹介したいと思います。

データ抽出・集計の依頼を先回りして、事業目的やKPIとして重要なデータは何かを検討し、それらを自動的に可視化できるデータポータルのような仕組みを作れるのが理想形のひとつだと思います。

そうした仕組みがあれば、依頼されるたびに都度データ抽出・集計をするといった手間もかからず、どのデータを使えば良いかの議論にすぐ入れるので効率的です。

またどのようなデータを見れば良いか、このデータはどう使えば良いかについて、こちらから働きかけられるので議論の主導権も握りやすくなります。

こうしたデータ活用のコンサルティングを進められれば、依頼者のリテラシーも向上し、事業目的と全然関連しないような依頼も減るのではないでしょうか。

データアナリストとしてそうした領域を目指すのもひとつのやり方かと思います。

なお、このデータポータルも一度作成すればそれで終わりというわけではなく、日々改善・改良が必要です。私の実体験ですが運用面でもまた別の苦労があるので、それはまた別の機会にて。

顧客分析の活かし方

データアナリストのほとんどは何らかの顧客分析を行った経験があるかと思います。

しかし、その先につなげられなかったという人も多数いるのではないでしょうか。

・特に意味のある分析結果が得られなかった

・分析をまとめた報告やレポートが特に何も活かされずじまいだった

顧客分析は「目的なき分析依頼」の典型例でもあるので、とりあえずデータをまとめて報告して終わりというパターンに陥りやすいようです。

あるいは分析者が自発的に調べてみようとして顧客分析を行うケースもあるようですが、せっかく労力をかけても単なるデータマイニングで終わってしまいがちなようです。

なるべくそうならないようにしたいものかと思いますが、なかなか厳しいようです。

以前の記事でも書きましたが、そもそも顧客分析とは顧客を複数のセグメントに分けてその違いを明らかにするものです。

ただいくつかのケースを見ていると、このセグメント間の違いをどのようなデータで調べるかが結構行き当たりばったりになっているように感じます。

例えば、優良顧客と非優良顧客の違いを分析する際に性年代データを見てみるとかですね。

こうした分析は通常は非優良顧客を優良化するにはどうすれば良いかを明らかにするために行うものです。

そのため分析した結果が、仮に優良顧客には女性が多く非優良顧客には男性が多かった場合、男性を女性にするための施策が必要ということになってしまいます。

当然ながらそうした施策は実施できないので、分析結果もそれ以上活かされることなく「あっそう」で終わってしまいがちです。

基本的に顧客分析の次には顧客の行動を変えるための施策を行うことになるので、見るべきデータも顧客の行動履歴を主としたものでないとなかなか活かしづらいでしょう。

ありがちですが、一定期間に何回以上来店すれば常連化しやすいことが分かれば、インセンティブをつけてその条件をクリアさせることを促せるようになります。

また単価アップさせたいならば、一定額以上の購入でプレゼントを与えるなどの施策もコンビニなどではよくやってますね。

むしろ施策案などから分析すべきデータを検討するほうが効果的なのかもしれません。

ありもののデータをそのままクラスター分析にかけるなどのやり方はあまり効率的ではないでしょう。（ひと昔前にはそうしたやり方も散見されましたが、あまり使えないということで今ではあまり見られなくなりました）

ただ、今は顧客の多様化やライフスタイルの変化も進んでいるので、今後はどういった行動履歴データがどこまで収集できるかも重要になってくると思われます。

顧客分析を活かすには、その後の施策の実現可能性を念頭において分析対象データをいかに揃えられるかがキーになるのではないでしょうか。

あと参考までに過去の顧客分析関連の記事も紹介しておきます。（↓）

custle.hatenablog.com

custle.hatenablog.com

DXで本当に変えるべきモノとは

DX記事の第4弾です。

なぜDXが必要なのか　～2025年の崖～

古い既存システムをそのまま使い続けた場合、システム担当者の引退、既存ソフトウェアやハードウェアのサポート切れなど様々な問題が今後起こってくることが想定されています。

これらの課題を放置したままでいると、トラブルやセキュリティのリスクも高まりそれらの対策やシステムの保守などで想定以上の費用がかかってくると言われています。

2025年以降それらが一気に経済損失として膨れ上がっていく（最大で現在の約3倍、年間12兆円）というのが「2025年の崖」とのことです。

www.meti.go.jp

経産省もこのように警鐘を鳴らして、今のうちにDXを推進しよう！と叫んでいます。

なぜDXが必要なのか　～世の中の急速な変化～

AIなどの技術はどんどん進歩しています。先進企業はそれらを率先して活用あるいは自ら研究開発してビジネスに活かしてきます。

それらは世の中に大きなインパクトを与え、人々のライフスタイルや価値観にさえ影響を及ぼします。

そうした中でいつまでも旧態依然としたビジネスモデルやシステムで戦っていけるだろうか、新しい技術を取り入れないと時代に取り残されていくのではないか、などの不安を感じている人も少なくないでしょう。

DXは実現できなくても問題ない？

DXに取り組む理由がこのような不安感や危機感からのものであっても、最終的に当初描いていたTOBE図が実現できれば問題ないのかもしれません。

しかし動機が不安感や危機感の解消である場合は、最終的にDXが進まないままでもそれらが解消されればそこで終わりということも十分ありえます。

例えば、

・競合他社もDXの取り組みが進んでいないから取り残される不安が薄れた

・現状特に影響もなくこのままでも問題ないんじゃないかと思うようになった

・DXとはまた別に課題や優先事項が生まれてそちらに注力するようになった

こうした状況からDXプロジェクトが停滞したまま新たに動き出さないという企業もあるのではないでしょうか。

DXで本当に変えるべきモノ

きなこもちさんによる写真ACからの写真

DXの定義（経産省のガイドライン）を再掲します。

企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること

最近、実はこの企業文化・風土の変革というのが一番大事なのではないかという考えも芽生えてきました。

というのも、顧客や社会のニーズは不変ではなく、DXも一度デジタル化（システム化）すればそれで終わりとはならないでしょう。

企業がこれから先も生き残っていくためには、引き続き顧客や社会のニーズの変化に応じて、サービスやビジネスモデルなどを絶えず変革し続けることが必要と思われます。

そう考えると、いかにリスクを恐れずスピード感を持って新たなチャレンジを繰り返していける組織・企業であるかが必要条件になってくると思います。

そのような企業文化・風土でなければ、常に保守的な考えや現状維持バイアスの方が優先されてしまい、変革が実現しないといったケースが多くなるのではないでしょうか。

ではどうすればそうした組織・企業に変わっていけるのか。

組織・企業の文化や風土はそこで働く人々によって醸成されていくものではありますが、とにもかくにもその中で経営層の影響は非常に大きいはずです。

経営層は企業のビジョンやミッションを定めて、さらにあるべき価値観や行動指針などを整え、それらを従業員に浸透させることに尽力します。

いわば企業文化・風土の基盤作りを行います。

ただしそれらの内容が経営側にとって都合がいいだけのものや、対外的に聞こえの良いメッセージだけで実体の伴わないものであれば、従業員にはただのきれいごととしか思われずほとんど浸透しないことでしょう。

当然それらは形だけのものではなく、従業員みなが納得して実践できるように実際の制度や環境なども整えられたものでなければなりません。

DXというシステム的な改革をきっかけに、それを支える企業文化・風土といった基盤も改めて見直してみるべきかもしれません。

難しい課題ではあるのでしょうが、高成長や先端事例として紹介される企業では、優れたコアバリューやユニークな社内制度・文化なども併せて紹介されたりしています。

参考１：「経営者目線を持て」

結構有名な言葉かと思いますが、この言葉を乱発して一般従業員から冷めた目線を向けられるという話もよく聞くのではないでしょうか。

「自分はただのいち従業員で経営者じゃないから必要ないよ」

「やりがい搾取か！？」

などのような感想を持つ人も多いでしょう。

ただ、実はこの言葉が指す経営者とは「その会社」の経営者ではなくて、「今の自分の仕事を行う会社」の経営者のことを指すようです。

つまり、今の仕事を主力事業とする企業の経営者になったとしたらどう考えるか、ということです。

よって、今の会社の経営者のために滅私奉公せよということではなく、今の立場で自己の利益を最大化するためにはどうすれば良いか考えろ、ということでもあります。

とはいえ、そのためには実際にある程度の権限や予算を持たせてもらうなど経営者としての武器を用意してもらえないとどうしようもなかったりするでしょう。

誤解を生みやすいメッセージであったり、誤解を誤解のまま放置するようなら従業員の意識の変革は厳しいでしょう。

参考２：Zapposの事例

ZapposはAmazonがどうしても欲しがった企業として買収され有名になりましたが、そのコアバリューも事例として色々なところで紹介されています。

全部で10個ありますが、そのうちのふたつを紹介します。

Embrace and Drive Change
変化を受け入れ、その原動力となれ

Be Adventurous, Creative, and Open-Minded
リスクを恐れず、創造的で、オープンマインドであれ

これらのコアバリューを実践できるように、Zapposでは社員に大きな裁量権を持たせ、評価や採用基準とも強く結びつけているようです。

DXシリーズまとめ

第1弾　DX（デジタルトランスフォーメーション）の第一歩

第2弾　DXの最初の壁を乗り越えるには

第3弾　DXのロードマップの作り方

DXのロードマップの作り方

DXは小さく始めるべきか、大きな絵を描くべきか

前回はDXのTOBE像を構築するためのヒントを考えてみました。

custle.hatenablog.com

今回はTOBE像構築後のそこに至るためのロードマップの作成について検討してみたいと思います。

その前に、AI導入ではスモールスタートで小さな成功を積み重ねる方が最終的に近道であるという意見を耳にすることがあります。

DXも同じようにまずは小さな成功を重ねていくやり方が良いのでしょうか。

実現できるかどうかわからない大きなTOBEを描いてしまうと、途中でプロジェクトが頓挫してしまう可能性が高くなるのでしょうか。

結論としてはある意味どちらも正解だろうと思います。

ただ、DXの場合はAIのようにシステムのいち機能だけでなく、業務システム全体や広範囲に影響を及ぼすことが多いので、スモールスタートがしにくい面もあるかと思います。

特にシステムの導入や改修となると高額な予算や時間も必要となります。

最初からそうした部分も計画に盛り込んでおかないと、途中で気づいてなんとかしようとしてもなんとかなる可能性は非常に低いです。（私も実際経験しました）

DXのロードマップの作り方

oldtakasuさんによる写真ACからの写真

DXの実現方法は最終的にシステム導入や改修になることが多いので、ロードマップ作成もシステム開発につながるようなものになります。

そのため一般的なシステム開発時の流れとそれほど差がないかと思います。

ざっくりいうと、まずは業務要件を定義してそこからシステム要件に落とし込み実現方法を設計し、開発・テストと進んでいきます。

業務要件の定義は、まずTOBEを元に大きな粒度での業務フローを設計し、そこから現場レベルでの業務フローとデータの流れを確認しながら詳細設計に落とし込んでいくことになると思うので、結構大変です。

さらにこれまでに経験のない全く新しい業務などがある場合は、後で想定外や考慮漏れのプロセス等が発生する可能性も高くなるので、最初に手運用もしくはプロトタイプシステムでのPoCなどを実施して業務要件のチェックをしてみるのも必要かと思います。

一部の業界・業種では結構前から業務パッケージの開発・販売がなされており、ある程度業務フローもテンプレートが用意されているので、そうしたものをベースにするのもありかもしれません。こうした業務パッケージの開発は今後さらに進むかもしれませんね。

次のシステム要件をまとめる段階では、既存システムの扱いをどうするかも悩みどころでしょう。

新しい業務要件が既存システムで一部カバー可能なら、丸ごとリプレースではなく、既存システムの一部継続利用も考えられます。

ただし、一部継続利用するならば新しく必要な機能をどう実装するのか、インターフェースやデータなどの連携をどうするか、既存業務に影響が出ないようにするにはどうすればよいかなど、なるべくコストがかからないやり方とリスク面の両方を踏まえて検討する必要があります。

プロジェクト体制も、DX推進を任された担当者だけでなく、対象業務の現場の担当者からシステム担当者など多くの人を巻き込んで歩調を合わせて進める必要があります。

場合によっては外部のコンサルやベンダーも関わるでしょうし、少なくとも数十人の規模にはなるのではないでしょうか。

以上のことを考慮して、DXシステムの導入計画、もといDXのロードマップを作り上げる必要があります。

さらにもちろんシステム導入「後」の運用やリスクと期待効果などについても事前に考えておかなければ、稟議は通らないでしょう。

プロジェクトを失敗させないためには

私の経験した失敗事例です。↓

・TOBEやロードマップがないままプロジェクトが開始され、現場担当者間では何をすべきかまとまらず時間切れ。

・TOBEやロードマップがないままプロジェクトが開始され、一部の業務でそれらを整理してPoCまでは成功しつつも、予定にないシステム予算の追加や既存システム改修が認められなくて断念。

繰り返しますがDXでは大体のところシステム開発や改修といった落としどころになると思われますので、AIやデータ活用といったキーワードを伴うからといってデータサイエンティストやデータアナリストだけで進めるのはおそらく厳しいでしょう。

またDXのようにゴールイメージがあいまいなものは、プロジェクトを見切り発車させずに、時間がかかっても最初にTOBEとロードマップを備えるのはやはり必要でしょう。

その際にもなるべくなら現場の業務担当者やシステム開発プロジェクトの知見のある人たちにも加わってもらった方が良いと思います。

さらにシステム導入まで含めると時間も人手もそれなりに必要なので、そのための体制・予算・スケジュールもあらかじめ確保しておく必要があるでしょう。こうした準備体制を整えておくのもプロジェクト成功のためには非常に重要だと思います。

スモールスタートのDX

DXを進めるに当たって、全ての業務をデジタル化するとか、現在のシステム基盤をデジタル化のために全て刷新するとなると、どれだけ時間や費用がかかるだろうかと途方に暮れてしまうかもしれません。

冒頭でも述べましたが、まずは身近なところでできそうなことからやってみるという考えも間違いではありません。

幸いにもDXは定義こそありますが、具体的でなく拡大解釈が可能なので、これがDXだ！と言い切れば通じると言えなくもありません。（AIも同じかも。。）

業務の一部のみシステム化を行ったり、新たにちょっとしたスマホアプリを開発したり、とりあえず何らかの形ある実績作りを優先してスモールスタートさせることも可能です。

AI導入のケースでいうと、多くはAIによって何かを変えようというよりむしろ「AI導入そのものが目的」であったりします。（PRになるので）

であれば小さく始めた方が成功しやすいのは自明です。それに小さなプロジェクトであってもAI導入の実績ができれば、それを元に周りの人々が感じているAIの敷居の高さや苦手意識を払拭させて、より広められやすくなる土壌も醸成できるようになるかもしれません。

DXも同じようにまずは小さくても実績を作ることを優先するやり方もあります。

ただし、TOBE像とロードマップがないとそれで終わってしまってそれきり続かないということも珍しくありません。

途中で目的がすり替わるパターン（DX推進がいつの間にかアプリユーザ何万人を目指そう！とか）も見たことがあります。

ロードマップの終着点はなるべくブレないようにはしたいですね。

DXシリーズは次回でひとまず最後となります。

custle.hatenablog.com

DXの最初の壁を乗り越えるには

DXの最初の壁

bBearさんによる写真ACからの写真

前回はDXの最初の壁とそれを避けて第一歩を踏み出してしまった場合の末路（！）について紹介しました。

custle.hatenablog.com

DXを進めるにはまず最初にASIS（現状の姿）とTOBE（あるべき姿）を定めます。そして次にそのためのロードマップを作成します。こうした準備を整えてようやくプロジェクトが開始できるようになります。

しかし兎にも角にもプロジェクトを始めることを優先してしまうと、手段ありきで進んでしまい大抵がPoCの段階で次にどうすれば良いかわからなくなってしまうという事例が多発しています。

今回はまずDXを成し遂げた先にあるTOBE像を描くにはどうしたら良いか、何かヒントのようなものはないかを考えてみたいと思います。

自社以外はどう変わっているか

Transformation（変革）の主語について考えてみましょう。

DXの定義にあったのは、「製品やサービス、ビジネスモデル、業務や組織、プロセス、企業文化、風土」などですが、どれも「自社」目線のものです。

ここでもう少し視野を広げて3C視点で考えると、「競合」や「顧客（マーケット）」の変革にも目を向けられます。

例えば世の中では、シェアリングエコノミーが流行しています。

UberやAirbndなどに代表される新興企業が提供したサービスによって、消費者の間ではモノを買うよりもシェアしようという意識の変化が顕著に表れてきています。

またそうした流れからか、所有するよりも定額で使い放題という利用権の方を好む人たちに応じたサブスクリプションビジネスも広がりを見せています。

他にも未来の都市構想のスマートシティを実現するために、IoTや次世代通信システムなど様々な先端テクノロジーを活用に関する々ニュースは時々目にします。

労働力不足の解消や様々な都市問題の解決のために、自動運転カーや無人店舗、ロボティクス、キャッシュレスなどの実証実験や取り組みが様々な企業で進められています。

さらに昨今の新型コロナの影響もあって、様々な業務やサービスのオンライン化も急速に進んでいますね。会議、営業、教育、商談、飲み会、イベントなどなど。

オンライン会議ツールを提供する企業はもちろん、それらを活用してサービスを持続的に提供できる仕組みやサポートを行う企業も業績を伸ばしているようです。

自社単独で変わろうとするのではなく、これら世の中の既に変わりつつある動向やキーワードを元に、自社ならどう関われるか／どういった立ち位置にあるべきかといったTOBEイメージを具体的に考えてみるのもひとつのヒントになるかもしれません。

小売業界の変革

ちなみに私が案件等で携わった経験の多い小売業界の変革というと、やはりオンライン化の進展でしょうか。

スマホの普及等により消費者がオンラインで過ごす時間が増えたことで、オンライン上もマーケットの場として注目されるようになりました。

Amazonや楽天といった巨大なECプラットフォームも誕生し、オンラインでのモノやサービスの流通はますます盛んになっています。

扱う商品やサービスも増加の一途をたどり、おそらくもうAmazonさえあれば生活するのに困らないという人もたくさんいることでしょう。

小売業からするとこうした風潮は大変な脅威です。

そのためコンビニなどの小売業者もオンラインでのマーケティング活動にも力を入れており、アプリ等を使っていかに自らの店舗に呼び込むかというO2O（Online to Offline）施策を繰り広げています。ポイントでの還元やクーポン発行などが代表的ですね。

また店舗を商品やサービスを販売する場ではなく、ブランディングの場として活用しようということでショールーム化を進めているところもあります。

家具・家電のモデルルームを設置したり、体験型のサービスを提供したり、インスタ映えする店舗作りを行ったりして、顧客を店舗へ誘致する施策が行われています。

さらに小売業は足元では人手不足の影響を大きく受けている業界の一つとして騒がれています。その解決のためにセルフサービスの導入や、業務の自動化・省力化などの研究開発も着々と進められています。

3C観点で代表的な課題をまとめると以下のような感じでしょうか。これらの課題に対してデジタルを含む様々な取り組みが進められているのが実情です。

【Competitor】
Amazonのような巨大プラットフォームの競合にいかに打ち勝つかあるいは協調するか

【Customer】
オンラインとオフラインをいかに活用して顧客とのリレーションを強化するか

【Company】
人手不足の解消と人件費削減をいかに進めるか

まずはこのように自社を取り巻く環境を網羅的に分析し、その上で自社が目指すべき方向や注力すべき課題を定めることが、DXを進めた先のTOBE像を具体化する上では必要なのではないかと思います。

次回はDXのロードマップの作り方を紹介します。

custle.hatenablog.com

DX（デジタルトランスフォーメーション）の第一歩

DX（Digital Transformation）とは

今回はDXについて書いてみようと思います。

fujiwaraさんによる写真ACからの写真

ちなみに経産省のガイドラインでは、DXとは「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」と定義されています。

www.meti.go.jp

この定義には主に2点の変革について書かれています。

・製品やサービス、ビジネスモデルの変革

・業務や組織、プロセス、企業文化、風土を変革

ただし、変革といっても具体的にどのように変わることがDXなのかは書かれていません。

それがDXがなかなか進まない大きな原因ではないかという気がします。

DXを進める最難関の壁

「変革」という言葉だけでは前に進めないので、まずはその前後の姿であるASIS（現状の姿）とTOBE（あるべき姿）を具体的にすることから始める必要があるでしょう。

ASISとTOBEを定められれば、そのギャップをどのように埋めていくべきかというロードマップやプロセスの議論に入ることができます。

それらがないままプロジェクトを進めることは出口のないトンネルを延々と掘り続けるようなものです。

まず、ASISに関してはDXの定義の中で主な対象種別（製品、サービス、ビジネスモデル、業務、組織、ビジネスプロセス、企業文化や風土）が例示されています。

ここから自社の環境に照らして対象を選択するのはそう難しいことではなさそうです。

しかし、TOBEに関しては「顧客や社会のニーズを元に」とか「競争上の優位性を確立」などの補足的な言葉しかなく、ちょっとイメージしにくいのではないかと思います。

おそらくここが大多数が行き詰まってしまう最初にして最大の壁なのではないでしょうか。

DXの最初の壁を避けて第一歩を踏み出すと

TOBEのイメージが構築できないとそこに至るためのロードマップを作成することもできず、プロジェクトがいつまでたっても開始できないまま時間だけが経過してしまいます。

その状態でずっと悩んでいるわけにもいかないので、先に手段（技術）を決めてとにかくスタートしてしまおうというパターンもよく聞きます。

ここで採用される手段とは高い確率で「AI」です。

これまで自社の業務やサービス等では取り入れていなかったAI技術を使えば、それイコール変革ではないかとの考えでDXプロジェクトがとりあえずスタートされます。

本来TOBEのようなゴールや目的、それに至るロードマップもないまま手探りでプロジェクトを進めても成功確率は低いはずなのですが、AIの活用事例などが世の中に広まりつつあるので、AIを使えばなんとかなるだろうという期待感が先行してしまっているのかもしれません。

しかし、残念ながらPoCまで実施したところで次に何をして良いのか再びわからなくなり、再度DXの推進が停滞してしまうというのもよく聞く話です。

PoC以降に進めない原因については、色んなところで議論されています。主には経営層の無理解、リーダーシップ不足、戦略丸投げといったものから、現場の抵抗、データが不十分、導入や運用体制が整わないなどでしょうか。ただ突き詰めればやはりTOBE像とロードマップの準備が不十分であることに帰着するような気がします。

しかしなかなかそれらの課題を克服した成功事例が増えてこないのも厳しいところですね。それだけ最初の壁が高いのか、それとも他にもつまづくポイントがあるからなのか。。。

DXの最初の壁を乗り越えるには

DXの最初の壁を避けてプロジェクトを進めようとすると失敗の可能性が高くなるので、やはり最初の壁を乗り越えることは避けて通れないのではないでしょうか。

次回はどうすればこの壁を越えられるのか考えてみたいと思います。

custle.hatenablog.com

データ活用とは具体的にどうすれば良いのか

データ活用の失敗パターン

データ活用とはデータ「を」効果的に使うことですが、あくまでデータは主体ではなく別の何かのために補助的に使うことを指します。

しかしこの「別の何か」が暗黙の了解とされてしまったり、あるいは省略されてしまうということが頻繁に起こります。

そのためにデータ活用の対象や目的が関係者間でも統一されず、何らかの分析を行ったとしてもそれが実際に役に立ったのかどうかの評価も定まらないということに陥ってしまいます。

そうなると結果的に成果が挙げられていないと判断され、失敗とみなされることが多くなります。

まずはデータを活用する対象である「別の何か」を明らかにし、それによって期待される「効果」を具体的にイメージすることがデータ活用の第一歩ではないでしょうか。

データ活用を行うための前提条件

私はこれまで色々なデータ分析の仕事をしてきました。

KPIの設計とモニタリング、仮説の検証、今後の見立てや見積もり作成、施策の分析と改善、リソース配分の最適化、KPI増減の原因調査。。。

ここから考えると、常に何らかの業務ありきでデータ分析を行ってきたといえるのではないかと思います。

もちろん特定の業務とは関係なしにただ単にデータを見せてくれとか、何らかの示唆を出してくれという依頼もありました。

しかし当然ながらそうした依頼で次のステップに進んだということはほとんどなく、振り返るとおそらくそれらはやらなくても問題ない依頼だったのではないかと思います。

ただ、業務ありきといっても最終的にその業務に何らかのフィードバックができる形にもっていけないと、データ分析を行った意味がありません。

おそらくここがデータ活用と呼べるかどうかの境目のような気がします。

つまり、データ活用を進めるにはまず「対象となる業務が定量的に評価可能な状態にあること」を満たし、実際のデータ活用とは「その業務の評価、改善、フィードバックといったPDCAを回すこと」ではないかと思います。

この前提部分があいまいだとまずもってきちんとデータ活用の「評価」ができなく、そうすると当然期待される効果である「業務の改善」もできたかどうか不透明ということになります。

データ活用はこの前提部分が非常に大事なのではないかと思われます。

逆にいえば、この前提部分がしっかりできていればあとはデータを見てどこに手を打つべきかを判断するだけで、それほど難しいことではないといえるのかもしれません。

業務とデータのリンク

そうした状態になっていないということは、この前提部分に問題があるということになります。

例えば「営業」であれば、目標売上ｘｘ円という定量的に評価可能な指標を設けているところはほとんどだと思います。

現状の売上がデータで評価可能な状態で、もし予定と進捗に乖離がある状態がわかれば何らかの改善が必要ということで、次の手を打つべしという判断が下せます。

ここで終わると基本的なデータ活用例として成功ですね。

しかし、実際にはこの「次の手を打つ」の内容が定まっていないと、結局営業担当者にハッパをかけて危機感を煽るなど「本当に効果的かどうかわからない手段」しか取れず、とたんにデータ活用から遠ざかってしまいます。

もし営業担当がサボっていることが判明しているならハッパをかけるでも良いのかもしれませんが、そうでないなら別の手段をとらなければ問題解決につながりません。

上記で述べた「対象となる業務が定量的に評価可能な状態」は業務のざっくりとしたレベルだけで終わらず、どの手を打つべきかといった判断が必要な粒度まで対象とできるかどうかでデータ活用可能な範囲も決まってきます。

そのため各業務におけるKPIの設計が重要となります。

そのKPIは当然ながらデータとして計測可能なものでないといけないので、その元となる業務ログをデータとして取得する仕組みも必要になります。

そうして業務とデータがリンクできた状態を構築できれば、データ活用によって業務状態の正しい評価を行い、適切なタイミングで改善を図ることも可能になるというわけです。

データ活用を進めやすい業務

主にバックオフィス系の業務は、ある程度マニュアル化が進んでいて、業務内容も標準化されていたり業務ログも収集されていたりするので、データ活用しやすい環境にあるのではないかと思います。

そうした業務ではサービスレベルの一定品質を担保するためにワークフローを可視化して、ボトルネックを検知したり必要に応じてリソースの再配分を行えるように調整することも可能でしょうし、さらなるコスト削減を目指して業務プロセスを分析して効率化や省力化・自動化といった改善を施すなどのデータ活用イメージが想像できます。

データ活用を進めにくい業務

一方でなかなかデータ活用が進まない業務の代表は、営業やマーケティングなどでしょうか。

これらの業務は、顧客や市場といった移り変わりの激しいナマモノを相手にするため、たびたび柔軟で臨機応変な対応が求められることが多いようです。

特にベテランの人間などはこれまでそれでうまくいってきたとか、そうした環境だったからこそ成長してきたと主張するかもしれません。

そのためなかなか自動化・定型化するといったことも難しく、結果として各担当による属人的な業務に陥ってしまいがちです。

実はこれはこれで間違ってなくて、個人的には営業やマーケティングのような業務は全てをガチガチに自動化・定型化させるまでは必要ないかもしれないと感じています。

もちろん自動化・定型化はコスト削減や品質の安定化にはつながるので、ある程度は進められるとそのメリットを享受できるでしょう。

しかし、そうしたシステマチックな業務からは、新たな知見・ノウハウ・クレーム（顧客の課題やニーズ）といった業務改善のヒントも得られにくくなるのではないかとも思います。

もちろん現場が完全に担当任せになっていても、そうした新たな知見やノウハウはせいぜい個人やチームの中くらいで閉じてしまうので同じようなものかもしれません。

現場の知見やノウハウを正しく評価し、効果的と見なされればそれを全体に共有・実践・管理する仕組みがあるだけでも業務の改善が進みやすくなるかと思います。

そのときにデータ活用の出番も出てくるでしょう。

データ活用のかたち

一例として、バックオフィス系業務と営業・マーケティング業務でのそれぞれのデータ活用の形を紹介しましたが、決まった正解があるわけでもないのでこれで全てでもないと思います。

一方で、上記で紹介したデータ活用の前提条件や業務とデータのリンクなどはデータ活用を進めるために欠かせないポイントだと思うので、抑えておいてほしいところです。

なお、データ活用を進めるにはさらに大きな壁（社内の抵抗勢力や予算交渉など）がまだありますが、それらの乗り越え方はいずれまた。。。