データ分析ダンジョンに潜む魔物

まずは、過去の失敗事例からお伝えしたいと思います。

とある特殊な見積作業に対して、その誤りを見つけるAIを開発する仕事をしたことがありました。業種・業務共に絞り込まれたニッチながら市場もあり、複数の会社でニーズが顕在化していたので力を入れて取り組んでいました。

その見積は専門職による作業で、滅多なことでは誤りが起きないとされるものでした。しかし、ひとたび誤りが発生してしまうと大きな金額的な損失が発生するため、ダブルチェックは欠かせないのだそうです。それでも稀に誤りが発生してしまうため、AIで万全の体制をしこうというアイデアでした。

「誤りを見つける」というタスクはデータサイエンスの世界でいうと「異常検知」ということになります。稀に発生する誤りをデータを用いて検知し、手戻りを防ぐというアプローチです。

このようなプロジェクトでは、以下2つの点をクリアしなくては実用になりません。

• 技術的に実現可能か。（データ品質とアルゴリズムの検証）

• システム化まで含めたときに費用対効果はあるか。

そこで、PoC（概念実証）という形で必要最小限のコストで上手くいくか試すのが定番のアプローチとなっていました。

一般的に、異常検知は正解データ（見つけるべき誤り）が少ないため、難易度が高いタスクとなります。

もし、潜在的な誤りの発生確率が1%、つまり100回に1回の割合で起こるものだったとすると、システムから見ればすべて「異常でない」と判断してしまえばトータルで結構あたってしまうことになります。そこで、異常検知では、異常を異常であると捉えられる精度と、正常を正常であると捉えられる精度をそれぞれ評価し、実オペレーションにフィットするモデルを作る必要があります。

もちろん、データだけで異常が分からない、言い換えると人の判断がデータの外に及んでいることがあると大変になってきます。これは事前ヒアリングで十分にわかる場合もあるのですが、たいていはPoCをやってみてわかることが多く、四苦八苦することになります。

また、仮に実用的な検知精度のモデルができたとしても、そのシステム化に費用を投じる意味があるのか？ということも問題になります。極端な話、現在のオペレーションで十分リーズナブルな場合も多く、見積を出してはじめて「なんでこんなにかかるんだ」という話になることもしばしばあります。

したがって、データを使った取り組みに限らず、BPRをもくろむDXプロジェクトでは、PoCで技術とビジネスの両面から妥当性を把握しなくてはなりません。

このプロジェクトでは幸いなことにデータもそろっていて、PoCによって技術的・ビジネス的な課題をクリアすることができました。つまり、以下のような判断のための情報が集まったということになります。

• オペレーション改善に繋がる異常検知モデルを作ることができる。

• システム化コストと誤り発生時の損失コストを見ても投資した方がよい。

ここまでたどり着く異常検知プロジェクトは珍しく、とてもうれしくなったのを覚えています。この検証には数々の技術的課題があり、定番のアルゴリズムを適用するだけでは上手くいきませんでした。技術開発とビジネス検証に要した期間は1年半程度だったと思います。ここまでくれば後はシステム化に進むだけという状態になりました。

しかし、顧客判断でこのプロジェクトは中止になりました。しかも同時並行で進めていた複数の見込み顧客すべてでストップがかかったのです。元々のニーズは顧客から出てきたものでしたし、プロジェクト期間中も間前向きな雰囲気だったので本当に驚きました。ROI的にも問題ないはずなのに…。

ストップになった直接の要因は予算が出なかった、つまり事業判断でNoGOとなったということでした。ROI的にも問題ないのになぜ？ということで探っていくと、意外なことがわかりました。

それは、そもそも対象業務は「誤りを発生するようなオペレーション許さない」ものであるため、自組織のオペレーションミスをカバーするためにAIやシステムにお金をかけることは通らないという判断だったのだそうです。そもそも誤りが発生するような作業をしている方がおかしいという理屈です。

客観的に考えると、この取り組みはオペレーション全体で見れば従来のチェック作業が手厚くなるだけに見えます。しかし、仕組上、オペレータの誤りそのものをなくすわけではありませんでした。これは組織文化の問題にも見えますが、他の企業でも同様の判断がなされてストップがかかったため、業界の慣習と特性を読み誤ったということなります。

こうした失敗はよくある話ですが、1年半後にこれが分かったというのは手痛い失敗でした。

当時はあまりのショックに冷静な振り返りができませんでしたが、今考えると課題の捉え方に問題があったと言わざるを得ません。もし、見積作業全体の高度化を目指し、それを実現すべく誤りの発生メカニズムを類型化し、オペレーターの育成やオペレーションの仕組みを改善する仕事と捉えていたなら、結果は違っていたかもしれません。これは事業や組織課題の捉え方のミスでした。

しかし、クライアントサイドも技術者である我々も、このミスに気づけなかったのです。

この事例のように、データアナリストやデータサイエンティストにとって「間違った課題に取り組む」ことほど辛いことはありません。

これこそ、データ分析ダンジョンに潜む魔物です。宝物があるふりをして全くないというわけです。目的にぐわないダンジョンを探索することほど疲れることはありませんよね。

この事例を裏返して考えると、データ分析プロジェクトに取り組むときには、その組織や事業にとって重要な課題に取り組むことが大切だといえます。間違った課題、解くべきでなかった課題に取り組んでも意味がないからです。

こうした経験を持つデータアナリストは、新しい依頼が来るたびにデータ分析の目的やビジネス課題を確認するようになります。

「データ分析」という仕事が組織の業務プロセスに上手く溶け込んでいる場合はこうした問題は起きにくいのですが、新設された分析チームや受託系のお仕事をされている場合は注意しなくてはなりません。

このレベルで課題が間違っていた場合、それが露見するのは大抵は最終報告会の時です。最終報告会に出席する上級幹部から厳しい指摘があり、それは報告者であるデータアナリストに刺さります。このとき、データ分析という手段が目的にすり替わったプロジェクトでは悲惨なことなります。恥ずかしながら私はそういった場面を何度も経験してきました。

したがって、データ分析を意義ある活動にするためには、意味のある課題を選定しなくてはなりません。これがデータアナリストや分析チームにとって究極的な壁になるでしょう。

この教訓は言葉にすると「なんだ、そんなことか」と感じるかもしれませんが、とても厄介な問題です。その発生パターンは無数にあるからです。例えば、

• 依頼者が現場課題を捉えていなかった。

• 業務部門と経営層の意識にずれがあった。

• データアナリストが課題認識を誤った。
  

• データ分析組織が「なんでいいからやらせてほしい」といった。

• DX案件の積み増しのためのジャストアイデアだった。

• 情報収集の一環で外部のデータ分析リソースを使ってみた。

• 競合他社もデータ分析をやっているからやってみた。

というような要因があると考えらえます。しかも、これらの要素が複数に絡み合うとなかなか難しいことになります。

極論すると、どこかで経営課題につながる取り組みであれば、少なくとも課題選定を間違うことはありません。しかし、データアナリストから「このテーマは経営課題とどのようにリンクしていくでしょう？」とストレートに問いかけても、答えを得ることは難しいでしょう。クライアントからするとデータアナリストに話を持ち掛けた時点で、データ分析の議論をするモードになっているわけですから。

データ分析プロジェクトが成功するかどうかは、ビジネス的に意義ある課題を設定できるかどうかにかかっています。

取り組むべき課題を見つけるための典型的にアプローチは、そのビジネスのあるべき姿(To Be)と現状(As Is)とのギャップを探ることです。ロジカルシンキングの教科書や、経営コンサルタント本によく出てくる話ですね。

このアプローチを成功させるためには、どこかでトップダウン的なアプローチをとらざるを得ません。ボトムアップでもやれなくはありませんが、冒頭に述べた失敗事例のように、現場サイドが経営課題の優先順位を認識できているとは限らないからです。おそらく経営コンサルファームの方でしたら、こうしたアプローチを死守することでしょう。逆にいうと、経営層とコミュニケーション取れないような案件は手を出さないはずです。

その一方で、データアナリストやデータ分析チームが置かれた状況は様々です。特に、組織内のデータ分析チームは、公式には経営判断のもとで組織が設置されており、それは経営方針に沿ったものと考えるの一般的です。

この場合、データ分析チームの活動目的やクライアントからのリクエストは経営方針に沿ったものだと考えがちです。しかし、新設のデータ分析チームは、具体的な活動テーマが決まっていないことがしばしばあります。また、ステークホルダー（クライアント）も特に要望を持っていないこともあるのです。そうなると、データ分析チームが自分自身で事業に意義のあるデータ分析テーマを発掘していかなくてはなりません。

そこで、データ分析テーマを募集しますと広告しても、なかなか集まらないか、ジャストアイデアリストになってしまいます。改善のために「お困りごとを教えて」「あるべき姿は？」「重要課題は？」とヒアリングしても、なかなかよいテーマが集まらないこともあります。

ここでは組織内のデータ分析チームをイメージして書きましたが、受託系のプロジェクトも同様です。委託元のIT部門や企画チームのポジショニングによっては、分析者が社外になるだけで同じような状況が発生するからです。

データ分析を事業に取り込むことが当たり前になっている分野では、こうしたことは起きにくい傾向にあります。業界に前例がある場合も同様です。有名なところでは、生産品質管理、Webマーケティング、金融商品のリスク管理、SaaSサービス開発、コールセンター効率化などでしょうか。

逆にいうと、私が専門とするピープルアナリティクスやかつて取り組んでいた防災分野のSNS活用など、黎明期であればあるほどテーマの収集に苦労することになります。

このような状況では、いかにしてクライアントサイドのペインポイントにアクセスできるかが重要になります。ペインポイントとは、クライアントが「お金を払ってでも解決したい」と考えている悩みです。クライアントや市場のペインポイントを外から捉えることは容易ではありません。KGI/KPIの設計ができている組織体であれば楽ですが、そうでない場合も多いのが実情です。

ペインポイントを見つける方法は、データ分析チームのポジションや組織状況、コンテクストによって大きく変わります。これをすれば見つかるという絶対的な方法はありません。

例えば、ざっくりと業種・業務を並べただけでも、このような違いがあります。

• 製造分野：オペレーションやサプライチェーンの全体像をおさえることが重要になります。また、経営的に生産管理、在庫管理、流通管理、人的管理、または売上・原価などどこに焦点が当たっているか同時に確認する必要があるでしょう。その上で全体最適につながる取り組みであるかがポイントになります。

• 公共分野：対象業務の前提となる法制度やその改正をまず理解する必要があります。その上で、関連省庁の重点施策、有識者会議の議論、予算配分を見ていきます。民間企業の感覚で業務効率化や意思決定のロジックを出してもまず通りません。

• マーケティング：当該マーケティング部門が対象とする事業の売上を筆頭に、すでに設定されているKPIをまず確認します。もしKPIが不明であれば、売上などの指標と施策の関連性を明らかにしていくべきでしょう。

• 人事分野：人的資本経営のKPIを起点に考えるのが理想ですが、まだそういった議論にはなりにくい状況です。採用、配置、育成、労務管理など業務別に課題を発見していなくてはなりません。これらの人事業務の横断的なディスカッションによって課題が見えることもあります。

• 医療分野：医療といっても幅が広く、大学、規制当局、医療機関、健診機関、メーカー、製薬企業などステークホルダーも多岐にわたります。データ分析チームのポジショニングと対象ビジネスによって課題の捉え方が全く変わってきますので、プロジェクトが立ち上がるまでに時間がかかる傾向にあります。業務課題をストレートに捉えるだけでなく、有識者や法規制、ステークホルダー間の力関係をおさえなくてはなりまえせん。

このように、データアナリストの立ち位置によって、ペインポイントを見つけるための視点が変わってきます。Webマーケティングや生産管理のように、データ分析の歴史があればわかりやすいのですが、そうでない場合にペインポイントを探るには何らかの工夫が必要と考えるべきです。

現場レベルでの工夫点はいくつかありますが、課題を発掘するためのコミュニケーションが最も重要だと考えています。話さないことには本当の課題を見つけることができません。

コミュニケーションといっても、ヒアリングリストを用意して機械的に聞くというのでは上手くいかないでしょう。分析チームとビジネス部門が一体となる必要があるからです。そのためには、信頼関係を得るための対話が欠かせません。いきなりやってきた第三者に自分たちが抱える問題点をペラペラとは話さないものです。第三者でなくプロジェクトメンバー＝仲間だと認知されて初めてスタートラインに立てるのです。

また、暗黙的な課題を捉えるにも対話が重要です。人は他者の状況を客観的に捉えるのは得意ですが、自分のことは分かっているようでわからないものです。これは組織も同じです。

このように、課題と本音にアクセスするためにはコミュニケーションが大切ということになります。

また、「誰と話すのか」というのも重要です。

例えば、生産オペレーションの効率化を目指した分析であれば、そのオペレーションを実際に担当している人と話すのは必須として、管理者や事業責任者の意見も聞いてみるべきでしょう。

このように書くととても当たり前に感じるかもしれません。しかし、場合によっては、DX系部門や品質管理部門など、分析対象の周囲にいる部門が主導してプロジェクトを引っ張ることもあり、またごくまれに現場との会話を飛ばして「とにかくデータを持ってきたら分析して成果を出してほしい」という要望がでることもあります。この場合、中間に挟まった部門がよほど現場と連携して課題を捉えていなければ、おおよそ失敗してしまいます。

組織や業務ごとに話すべき人はかわってきますので、プロジェクトごとに注意深く考える必要があります。

このレターでは、データ分析ダンジョンに潜む魔物ということで、プロジェクトでデータアナリストに立ちはだかる最大の壁について考えてみました。

今回は特に注意すべき点について取り上げましたが、データ分析プロジェクトでは大小さまざまな壁が出現します。あなたはプロジェクトでどんな壁にであったことがありますか？ コメントで教えていただけると嬉しいです。

ではまた次回。