数字を聞くようにすれば、データを見るクセはついてくる
堅田洋資氏：さて、後半戦にいきましょう。問いの量を増やすにはどうしたらいいのか。これは精神論というわけじゃないんですけれども、マネジメント層のみなさんへのお願いも少し入っています。
データを活用する文化をつくるには、上司から問いを出してもらう必要があるんですが、上司は「それをデータで示してほしい」と言ってもらうようにする。これが一番効果的だと思っています。
現場でいくら分析をしても、それを上司が「こんなのどうでもいいよ」という感じで扱うと、当然現場はデータ分析をしなくなってしまいます。
逆に「データを見たい」と上司が日頃から言っていれば、だんだんデータを見ないといけない感じになってくるものです。なので、上位者の方は「データで示してね」と興味を持って言う。「これは何パーセントなの？」と聞くようにすれば、部下のみなさんもデータを見るクセは自然とついてきます。
我々もプロジェクト系の研修をやるときには、最後の成果発表の際にあえて上司の人たちに来てもらって、「それは何パーセントあるの？」とか突っ込んでもらうようにしているんですね。そして、それを実務でもやってくださいねという感じで研修しています。
「わからない」というリスクを受け入れる
もう1つ、データ分析には厄介なところがあって、「やってみないとわからない」んですよ。一番厄介なのは精度です。「AIの予測の精度は何パーセントほしい」とよく言われるんですが、それができるかはデータ次第ですし、分析者の腕次第でもある。
つまり不確実要素が多すぎて、わからないというリスクは常にあります。なので、そのリスクを抑えるために「ゲート」制を入れましょうと言っています。ここまでやって期待する成果が出なかったら一旦ストップするという感じで、都度判断を入れていくというのがリスクを抑えるポイントだと思います。
私が以前レコメンデーションエンジンを作っていた時には、手元のデータによるシミュレーションを行って、一定の精度が出なかったら継続しないことにしていました。
それがうまくいったら、数日間だけA／Bテストという実験をやってみる。そこでもうまくいったら、長期のテストに入りましょうという感じで、だんだんスケールアップさせていくような段取りにしていました。
そうすると、ビジネス側の人からも無駄なお金とか無駄な時間を使わなくていいし、データ分析する側も「なんとしても何パーセントの精度を出さないといけない」という、実は出すのが難しいことに時間を使いすぎなくて済みます。これでいけるかの率直な議論を行う場があるといいかと思います。
データの民主化はトレーニングしないとできない
さて、次はデータサイエンスの民主化という話題です。これも最近わりとよく聞かれるようになりました。これには「データの民主化」、「実験の民主化」、「機械学習の民主化」の3つがあると言われています。
特にデータの民主化が重要で、これはデータを集めた後に適切な権限管理をした上で、必要な人がちゃんと見れるような環境を作れているかどうか。分析でわからないことがあったら、相談できる窓口をつくれるといったことも大事かなと思っています。
今日は個々の話はしませんけども、いろんな人がデータに触れる機会を作っていくというのが大事で、これはトレーニングなしにはできないことです。
わりと有名な例なのかなと思うのが、Airbnbですね。Data universityという社内の仕組みを作ってデータ教育を行っています。「Data education will help drive data-informed decision making」、つまり「データのエデュケーションこそがデータを使った意思決定を助ける」いうことで、データエデュケーションは1つの大事な要素だよと言っているんですね。
そのためのツールを揃えたり、データにみんなアクセスできるようにするのはもちろん、民主化という意味で大事ですけども、データ教育をちゃんとやっていくというのも大事な要素ですね。
分析プロジェクトを支えるビジネストランスレーター
教育だけではなく、人事や組織的な体制のところについても少しお話しします。
一昔前というほどでもないですが、「データサイエンスのプロジェクトをやりましょう」となった時、私のようなデータ分析側の人がビジネスサイドの人と話をする際に、なかなか噛み合わないということがあります。
ビジネスサイドからは売上を上げたいという話しか出てこないし、こちらからの最新の手法を使いたいという話も通じない。断絶が起きているわけですね。
そういったことを防ぐために、間にビジネストランスレーターと呼ばれるような翻訳家の方を育成するというのをおすすめしています。
これは研修でもよくお伝えしているんですけども、ビジネスサイドのことがわからないと、最終的にどう意思決定するのか、業務にどうやって組み込んでいくのかの話ができないんですね。外部にまるっと頼りきりというわけにはいかないので、業務に詳しい人にデータ分析の素養を身につけてもらうのが早いと私は思っています。
この人と一緒に分析のプロジェクトを回していくとスムーズに動くことが多いので、トランスレーターを育成するのをおすすめします。
データサイエンスチームの構成
ここで、冒頭のDXの話に出てきた課題発見とAIに戻ってくるんですけども。一番最初にどういう課題を解くのかについては共通なのですが、ちょっと下のアプローチが違います。
課題発見と解決型のデータ分析だと、ビジネストランスレーターのスキルレベルにもよりますが、ExcelやTableauと呼ばれているBIツールなどの基本的なツールを使いこなせるのであれば、ビジネストランスレーターとデータエンジニアという布陣でもある程度いけるかなと思います。場合によってはデータサイエンティストも必要かもしれません。
ただ、AIを使った開発となると、これだけでは技術的にやや苦しくなってくるパターンも増えると思っています。ビジネストランスレーターだけではなくて、データサイエンティストも入っていかなければならない。なので、技術的な難易度にあわせてチームの部分を変えるのは大事かなと思っています。
これを実際に組織でやる場合にどういう配置になるかというと、大きく2パターンあります。
1つはCoEモデル。データ分析ができる人たちを1ヶ所に集めておいて、各事業部にサービスを行うというやり方です。もう1つは部門内モデルで、特定の部門の中にデータチームを作って、部門の問題を解決するというやり方です。
最近クライアントで多いのは、CoEモデルを採用した上で「全社向けに研修をやりたいんだよね」という相談です。ただ最初から難しいことをやって挫折してしまうと困るから、どういうカリキュラム設計にしましょうかといった話になるんですね。
一昔前は、特定の部門の中で特定のデータ分析ができる人を育てようという話題が多かったように思います。2〜3年前まではそうだったという印象なのですが、我々のクライアントの中ではCoEモデルからの相談が増えています。
両方ともやるというのがハイブリッドモデルです。事業部内にもあるし、全社共通のデータチームもある。技術的難易度が低いものは事業部で、高度な分析や基礎研究はDX推進部にあるようなデータチームがやりましょうと棲み分けながらやっている会社も、少なからずあるという状態です。
もちろんデータ分析的にはハイブリッドモデルがいいよねとなるんですけれども、当然人の数はたくさん必要になってきますので、試行錯誤しながらやっている会社さんが多いのではないかなと思います。
ということで、「問い」の量を増やす方法についてお話ししてきました。ポイントとして、一番やってもらいたいのは、上司の方から「データを見せてほしい」とちゃんと言ってくださいということですね。
そして「やってみないとわからないこと」を受け入れないといけないのですが、そのためにリスクコントロールはちゃんとしましょう。期待値のコントロールもそうですね。
あとは社内の体制づくりです。ツールの整備もそうですし、データの民主化もそうです。そして社内のデータ教育体制を構築すること。これで量を増やせます。
そうなると、みんなデータ分析がある程度できる状態なので、この2つの組み合わせで全社的にデータを使っていけるようになります。結果的に、問いが解けている中での価値の総量が出てくるよということです。
データは統合することで価値が生まれる
さて、最後です。競争優位性をもたらすものはなんでしょうか。
突然ですが、1つのサービスに関する大量のデータか、結合可能な複数サービスにまたがるデータ、どっちが良いと思いますか？
一昔前だと、データの量がたくさんあることが大きな価値になっていました。しかし今は、先ほどの新型コロナの話もあって、以前のデータの傾向が使えないということが起きています。なので、後者の結合可能なデータのほうが価値が出てくる時代なのかなと思います。
そうなった時、問いのレベルを上げた際に解きたい問題の複雑度がこちらのバーだとしましょう。データの処理は本来このくらいの量がなければいけないんですけど、最初はありません。だとすると、解ける問題のレベルも低い状態なので、概念的にはデータの種類を増やしていきたいわけです。
複数のサービスをくっつけられるようにするとか、他社からデータを購入する、Web上のデータを収集する、センサーデータで追加で収集するといったかたちで、意図的にデータを集めていく必要があります。例えばサービスを複数展開して、同じデータをキーにしてIDを振って連結できるようにすれば、データを統合するのに非常に有効です。
ということで、この4つをバランスよく伸ばしながら、問いの価値の総量を増やしていくのが大事になっていくのがわかるかと思います。なかでも、データを積極的に集めていって、結合できるように工夫しながら取っていくというのが重要だと考えています。
「問い」を持てるかどうかがデータサイエンスの第一歩
ということで、まとめに入ります。お伝えしたかった4つのファクターとは、「データ」「技術」「文化」「民主化」ですね。どれも欠かせないと思います。
（スライドを指して）特にマネジメントの方は右側が気になると思いますし、分析をやっているという方は左側が気になると思います。どちらも大事なんですけども、この4つをバランスよく上げていくというのがとても大事ですよということが、お伝えしたかった内容です。
データを意識的に取りにいくのは大事なんですけども、顧客や業務に関する問いを持てるかどうかという点について、5年近くデータサイエンスの教育事業をやってきて思うのは、やはりかなり難しいことだと感じています。
顧客や業務の理解から始まるわけですが、もう当たり前になっていることからは、なかなか問いも出てきません。「なんでだろう」と思えなくなっている。なので意識的に問いを持つ機会、課題を感じる機会を作れるかどうかがとても大事だなと思っています。
逆に、問いさえあれば、後はデータを見にいけるか、環境があるか、その技術があるか、それが会社として奨励されているのかどうか、このあたりが大事になってきます。問いを持てるかどうかが最初の一歩かなと思いますということで、私からご説明差し上げたかったことは以上です。
身近な関心から「問い」を見つける
事前にアンケートでご質問をいただいていたので、そちらの話にいきたいと思います。
「学び方がよくわからない」とのことですね。データサイエンスを学ぶのはすごく難しいんです。なぜかというと、データ分析は営みであり、ただ個別のスキルを学ぶこととは少し違うからです。
例えば、ExcelやTableauの使い方とか、Pythonなどプログラミングの技術を学ぶことはできます。しかし、大事なのは「問いを持つこと」なんですね。もちろん、プログラミングや統計学やAIの知識やスキルを学びつつ、それらを統合して、「問いをどうすれば持てるか」について、かなり工夫して研修をやっているつもりです。
もう少しいうと、スキルは簡単に教えられるんですけども、そのスキルを使って問いを明確にした上で、解明して初めてデータサイエンスになるので、「スキルだけは教えます、後は知りません」だとデータサイエンスにならないんですよ。それはプログラミングの使い方がわかった、Excelの使い方がわかったというだけなので。なので「問いはなんですか」と「何を知りたいんですか」というところが大事なポイントだなと思っています。
学び方という観点でいくと、「Excelもプログラミングもまったくできません」だとデータを使えなくなっちゃいます。Excelでもプログラミング言語でもなんでもいいんですけど、データを使えるツールを学びつつ、「気になるな」と思えるものを探すことですね。
例えば受講生にテニスがすごく好きな人がいて、その人はジョコビッチとフェデラーの2人の過去のスタッツ、過去の戦歴を全部可視化して、どういう違いがあるかをつぶさに見ていました。そんなのでぜんぜんいいんですよ。そこから「こんな傾向があるんだ」という発見につながって、「分析っておもしろいな」と感じはじめたりするものです。
また気象予報士の受講生は、卒業プロジェクトで成田空港の霧の予測をしていました。成田空港に霧が出るとダイバート（注：航空機等の運航において当初の目的地以外の空港等に着陸すること）が発生して、茨城空港とか千歳空港に降りることが多いということで、それが問題だなと思っていたらしいんですね。
それで実際に予測モデルをつくったと。そんな感じで、身近な問題で「なんでだろうな」と思うこととセットで勉強すると、データサイエンスの世界をおもしろく感じていただけるんじゃないかなと思います。
困っていることを可視化して、データ分析の価値を示す
2つ目は「アドホックな分析ばかりで、長期的な分析にはなかなかたどり着けない」というご質問です。組織的にデータを活用しようという気運が高まらないと、「ふーん、おもしろかったね」となって終わってしまうんですね。
私もコンサルティングをやっていて、レポートを作ってお出しして、それが果たして実行されたのかどうか気になるものなんですけども。これはかなり覚悟を持って現場に展開していただかないと厳しいと思います。
なので、どういう視点で取り組んだらいいのかという観点から言えるのは、まず壮大にしないことですね。すごく簡単な問題だけにするのが大事だと思います。
おすすめとして、クライアントさんがやっていてすごくいいなと思ったのが、自分が分析するときにまわりを巻き込もうという作戦です。長期的な取り組みをするために、まずまわりの人が困っていることを可視化するんですね。
まずは週次で、Excelか何かでグラフ化したものを配信しはじめて、それを見て「いいね」と言ってくれる人が増えてくる。すると、だんだん長期的な打ち手とか、少しシステム的にも規模が大きいような話につなげていけると。そういった取り組みにトライしている人がいます。それもやり方の1つですね。
指標は同じで数値が違うダッシュボードの乱立問題
3つ目は「TableauなどのBIツールを利用して可視化させていくときに、データマートをどう管理するか」。これはわりと悩みが深いなと思っています。
まずTableauなどのBIツールを作った時にありがちなのが、社内でTableauのダッシュボードが乱立するという状態ですね。
知らない間にダッシュボードが100とか200ありますみたいな会社さんがたまにいて、「えっ、そんなにいっぱいあるんですか」と驚きました。しかも困ったことに、同じ指標名だけど数字が違うダッシュボードがあって混乱してしまったりすると。
これに関しては、ちょっと私が聞きかじったところで申し訳ないんですけど、ある海外企業のAIのディレクターの人が講演しているのを聞いて「なるほど」と思ったことがあります。
まず一括管理をするんですね。この数字だけは中央集権的に管理しますという指標を決めて、それを上司にレポートする時には必ず入れるとおっしゃっていました。
これはデータ分析というより、数字の見せ方のテクニックみたいなところですが、上手だなと思いましたね。「これは全社的に共通化したい」という数字は、ある程度中央で管理したほうがいいのだろうなと思います。
データマートもデータベースを使えるような人が何人もいると、どんどん増えていくことがあると思います。私のクライアントさんだと、データチームがマートの管理をしっかりやって、自由に作らせないようにされていました。逆に「こういうマートがほしいんだよね」と言われたら、それを作って管理するという運用方法で対応されていましたね。
AIを使うなら、閉じて安定した問題を
次は「AIでデータ分析すべき課題なのか、もしくはAIデータ分析で即応性が得られるのか、費用対効果が得られるか」。これについては「やってみないとわからない問題」がありますので、費用対効果を測るのはまず難しいと思います。
「AIでデータ分析すべき課題なのか」についてですが、これはいい質問ですね。先ほど申し上げたとおり、AIでデータ分析すべき課題の条件は安定しているということなんですね。
過去が再現されるという前提を成し得ないと、AIや機械学習は使いにくいと思います。なので先ほど申し上げたとおり、人を検知するとか、猫や犬を区別するとかはいいんです。ただ需要予測などをこれでやりはじめると、ほとんど新型コロナ前のデータは使えなくなるんじゃないかと思っています。
なので複雑で因果関係が絡み合った社会現象になればなるほど、今のAIでは解決しにくいかなと思いますし、逆に閉じた問題や安定した問題であればAIで解決できると考えていいと思います。
最後です。「課題に対してどんなことをしたいとわかっていて、かつ打ち手もわかっているが、ゴールまで到達する応用部分がわからない」。これはアプローチが難しいということですね。
「ゴールまで到達する応用部分がわからない」の「応用部分」がどういうイメージかによると思うんですけれども、技術的なものであれば可視化するとか、こういうAIを作りたいけど納得が得られない、難しい、うまくいかないということであれば可視化のレベルに戻すとかですかね。そういったシンプルな問題に落とすようなことをやるのかなと思います。
もし応用部分が適用の問題、現場への落とし込みという観点であれば、結局誰かが責任を持って組織の中に埋め込んでいくということをやらなければいけないので、そういう人を育成する、もしくはそういうチームをつくる、ゲリラ戦で戦うみたいな感じになるんじゃないでしょうか。
ということで、少しでもヒントになったらうれしいなと思ってお話ししました。今日はこれで以上となります。ありがとうございました。
