背景
会社が大きくなるに連れ、社内の各チームに溜まっているデータを活用したいという要望が出てきつつあります。それに伴い、私達エンジニアチームに対して、データ分析が求められる場面が増えてきました。しかし、現状のチームメンバーには十分なデータ分析の知識が備わっておらず、手探りで進めるしかない状況のため、誤った分析手法・データに基づいて、誤った判断を下してしまうリスクがありました。
輪読会を実施した目的
この課題に対処するには、具体的な分析手法の勉強をする以前に どういうパターンで分析を進めると失敗するかを知る必要がある と考えました。そこで、私たちはデータ分析失敗事例集 の輪読会を開催することにしました。この輪読会では、実際のデータ分析の失敗事例を知ることで、「この進め方は危ないな」と直感的に判断できる力を養い、分析手法や仮説に過度に固執せず、柔軟な思考を持つことを目指しました。
選定した本
データ分析失敗事例集
輪読会の進め方
この書籍は3章+コラムの構成で、データ分析の失敗事例の背景や結果がまとめられています。輪読会では、節毎に内容をまとめ、メンバーで輪読した後、感想を出し合い、議論を行いました。
その結果を踏まえて、書籍の内容を参照しつつ、チームのデータ分析の掟を作成しました。
チームで作成した掟の紹介
本書籍の各章のタイトルは 『「えーあい」でなんとかして』、『翻弄されるデータサイエンティスト』、『その失敗を超えてゆけ』 となっています。
各章を輪読し、議論することで、得られたチームの掟は下記の画像の通りです。
チームで作ったデータ分析の掟（1章）
チームで作ったデータ分析の掟（2章）
チームで作ったデータ分析の掟（3章）
各章の掟を簡単に要約しますと、1章の掟は「AIや機械学習といった手法に過度に依存しないように、業務の進め方を考えようという」内容。2章の掟は「分析結果を歪めない」という内容。3章の掟は「データ分析は要件を詰めてから始めよう」というような内容です。
次の章では、本書で紹介されていた事例を紹介しながら、チームで合意した主な掟を3つ紹介します。
掟1: 「AI」「データ分析」は銀の弾丸ではない！
データ分析と言われて、まず何を思い浮かべるでしょうか？ 最近は機械学習やデータサイエンスが台頭している関係で、まず思い浮かぶのはこれらのツールで、「とりあえず、今流行のAIを使ったり、データ分析をすれば、今抱えている会社の問題は全部解決するんでしょ？」と思っている人もいるのではないでしょうか？
ですが、いくら一流の道具・料理人を揃えたとしても食材が腐っていると美味しい料理を作ることは出来ない ように、データ分析においても良い手法と素晴らしい人材を揃えたとしても、問題設計、データ等に問題があれば、失敗します。
この章では、ツールに過度に依存しすぎたために起きた失敗事例を3つ紹介します。
失敗事例1: データが取られた背景も重要
誤ったデータ分析を行わないためには、分析スキルだけではなく、受け取ったデータがどういう形で取られたかという背景情報やドメイン知識も必要になります。
本書ではそのような事例として、「頑張って予測していたのは」が紹介されていました。この事例は小売業において、過剰発注を防ぐために、商品の販売数を基に機械学習モデルを構築しようとしたが、失敗したという内容です。
今回の事例で与えられたデータが販売数だけではなく、発注数も得られていれば、100個仕入れて100個売れたのか、1000個仕入れて100個売れたか判別が付きます。前者ならば需要過多なので、追加発注。後者なら供給過多なので、発注数を減らすという判断が付くため、機械学習モデルを実務で使われた可能性はあると思われます。しかし、今回得られたデータは商品毎の売れた個数のデータのみでした。
分析者はその点に気付けなかったため、商品に対する顧客の需要予測を行うつもりが、店舗の発注数を予測してしまい、商品の欠品が相次いでしまいました。結果として、従来の経験則で商品の発注数を見積もる形に戻す必要が生じ、モデル構築の費用が無駄になってしまいました。
この事例では分析者が貰ったデータに関するドメイン知識を持たないにも関わらず、データの提供者と相談等の連携を十分に取らなかったのが大きな問題です。分析者はデータを分析するだけではなく、データの生成過程を直接見に行く、気になる点はデータ提供側に確認するという姿勢も重要です。
失敗事例2: 仮説が間違っていることは普通
分析を行うにあたり、まず仮説を立て、それを踏まえて分析手法を考えたり、データ収集を行うのが一般的です。しかし、いくら尤もらしく思えたとしても、仮説はあくまで仮説であり、分析をするに連れ、誤っている事に気づく事もあります。
本書ではそのような事例として、「本当に季節性はありますか」が紹介されていました。この事例はネジや軍手等の業務用の商品を販売するB2Bプラットフォームにて、商品のおすすめをするアルゴリズムの作成を試みたが、失敗したという内容です。
このプロジェクトでは購入される商品には季節性が存在すると仮説を立て、分析を開始しました。
その結果として、軍手等の商品に関してはある時期になると売れたり、うれなくなったりする傾向（季節性）が見られましたが、ボルト等の機械の部品に関しては季節性が見られませんでした。その結果をプロジェクトの担当者が納得できなかったため、無理矢理全ての商品に季節性があるように分析結果の見せ方を変更しました。
この事例では、仮説が100％正しいと考え、その仮説に反しないデータの選定、見せ方の変更をしたのが問題です。仮説はあくまで仮なので、分析途中に誤っている事に気づく場合も多々あります。その場合、間違っている事を含めて報告し、軌道修正を行う事も重要です。そのためには分析の失敗を100%分析者に押し付けないという会社の分析に対するスタンスも重要にはなります。
失敗事例3: 機械学習モジュールを作った意味
近年はAI、機械学習、データ分析というような言葉がネット上に溢れています。加えてこれらの言葉は非常に魅力的なので、これらのツールは無条件で他のツールと比べて優位性があるとみなされがちです。
しかし、目的や仮説をしっかり立て、コストや時間をかけて検証した結果、従来の手法のほうが良い場合もあります。
本書ではそのような事例として、「機械学習モジュールの寿命」が紹介されていました。この事例では個人間売買プラットフォームで詐欺行為を未然に防ぐため、トラブルのあった取引データを基に、詐欺の可能性が高い取引を事前に検知するモデルを作成したが、失敗したという内容です。
このプロジェクトでは、機械学習モデルを作成したものの、3ヶ月後にはトラブル関連のデータが十分に溜まったため、トラブルのパターン化が可能になりました。そのため、このモデルは本番環境から削除されてしまいました。
この事例では機械学習に過度にこだわらず、運用が楽な手法を選択したという観点からは成功事例とも言えます。しかし、機械学習モデルの作成には工数がもちろんかかります。そのため、まず機械学習モデルの作成ではなく、パターン化等、機械学習に頼らず、簡易的な方法で問題解決が出来ないかを確認したうえでタスクを進める というのも重要です。
私たちはどうすべきか
上記の3つの事例から言える事は 「機械学習やデータ分析といったツールを盲信しすぎない事」 です。
これらのツールはゴミを入れても、素晴らしい結果を返してくれるような変換器ではありません。 ゴミを入れた場合、ゴミが帰ってきます(Garbage in , Garbage out)。加えて、従来の経験則やパターン化と比べて、必ずしもこれらのツールが優位性を持つわけではありません。
例えば、失敗事例1のように求めたい結果にそぐわないデータを選んでしまうと、いくら高度なツールを使ってもうまくいきません。失敗事例2のように仮説が誤っている場合、データが適切でも分析はうまくいきません。失敗事例3のように高度な機械学習モジュールよりも、簡易的なパターン化の方が良い場合もあります。
自チームで行う分析において、プロジェクトの発足理由やプロジェクト管理者が妄信的に「AI、機械学習を使えば問題は解決できます」という思考になっていた場合は危険信号です。分析が失敗するリスクを下げるために、定期的に 「本当にこの分析方法で良いか」 と自問自答したり、疑問に思うことは重要です。
掟2: 想定通りの分析結果にならなくても許容せよ！
データ分析の結果、社内で推し進めたいプロジェクトやPOの考えた仮説にとって、不都合なデータが出る等、想定通りの結果にならないことがあります。そのため、都合の良い結果が出るようにデータの改ざんや分析方法を恣意的に変更されてしまう事例もあります。
この章では、特に 「社内政治」 と 「データ数不足」 によるデータ改ざんが行われたために起きた失敗事例を2つ紹介します。
失敗事例1: 社内政治によるデータの改ざん
データ分析の結果を受け入れられないステークホルダーがいると、データ分析は歪められてしまう可能性があります。本書ではそのような事例として、「政治的な数字の応酬」が紹介されていました。この事例では分析手法の妥当性ではなく、POの肌感覚と合うかどうか が結果の妥当性を決めるという誤ったデータ分析文化が形成されてしまったという内容です。
このプロジェクトでは、各部門へのヒアリングをもとに作成された機械学習モデルをもとに広告予算の適切な活用を試みたところ、一部の部門に対して 大幅な予算削減が必要 という結論が出ました。
しかし、削減対象となった部門から強い反発があり、分析者は 分析結果を調整（改ざん）せざるを得ない 状況に追い込まれてしまいました。その結果、分析の妥当性を考慮されることはなくなり、出席者（ステークホルダー）の肌感覚と合うデータ分析は正しいデータ分析、そうでないデータ分析は誤ったデータ分析と認識されるようになりました。
この経験を経て、プロジェクト内では 「自分たちの意見を通すためにデータやストーリーを調整する」 という誤ったデータ分析文化が根付いてしまいました。
この事例から学べることは、 「ステークホルダーの意向に沿わない分析結果は排除される」 という現実があるということです。
失敗事例2: データ不足による独自解釈の追加
次に、分析に必要なデータが不足している場合に、分析者が 独自のデータを補完してしまう というケースです。本書ではそのような事例として、「取ってびっくり、使えるデータはこんなに少ないのか」が紹介されていました。この事例では、分析期限等の分析に関する問題に苛まれた分析者が、機械学習モデルに使うデータを恣意的に操作 した結果、失注につながったという内容です。
このプロジェクトでは、製薬会社がSNSデータを活用したニーズ分析を行うために、発注側の指示に従い、特定のキーワードで分類するモデルを構築していました。しかし、残りの納期が2週間、発注担当者は長期休暇中で問い合わせもできない状態になっている状態で、突然絞り込みキーワードの変更が発生しました。
その結果として、変更後のデータは想定以上に減少し、分析者はやむを得ず、選別される前のデータ群から 影響が少なそうなワードを追加 してモデルを再構築しました。
なんとかモデルを構築したところ、発注側から 「モデル構築に恣意的なデータ操作が含まれているのでは？」 と指摘され、適切に説明できなかったため、後続のプロジェクトは 発注取り消し となってしまいました。
この事例から学べることは、 「データ量に対する見積もりの甘さが悲劇を招く」 ということです。
（もちろん、今回のケースでは 他にも多くの改善点があった とは思いますが……）
私たちはどうするべきか？
今回の2つの事例から、「結果が想定通りにならないことを許容する」 ことが重要だと感じました。
そのためには、想定外の結果を受け入れ、また 「意図的にデータを歪める行為を指摘しやすいチーム文化」 を作ることが不可欠です。
私たちは、データを 分析する立場 であると同時に、分析結果を判断する立場 にもなります。その際、適切な知識がなければ、結果が妥当かどうかを判断することはできません。
「正しい知識を正しく使うこと」 で、データ分析の誤りや捏造を防ぎ、健全な意思決定を支えることができると考えます。
掟3: 手段と目的を履き違えるな！
データ分析はあくまで問題（目的）を解決するための 手段 であり、データ分析自体が 目的 にはすべきではありません。
例えば、ある店舗の売上が悪く、その原因究明の手段として、データ分析を使うのであれば、手段は目的化していません。
一方、AIやデータ分析を使いたいがために、それにあったデータや問題設計をしてしまう場合もあります。この場合は先程の例とは異なり、手段が目的化してしまっています。
この章では、手段が目的化してしまったために起きた失敗事例を2つ紹介します。
失敗事例1: 目的不在のプロジェクト
近年はAIやデータ分析という言葉を見かけることが増えてきました。その関係で、「最先端な技術を使いたい」という声も生まれやすくなってきています。しかし、そのような突発的なアイデアから目的のない プロジェクトが始まってしまう場合もあります。
本書ではそのような事例として、「最先端アピールの最先端プロジェクト」が紹介されていました。この事例では最先端技術を使うことを目的としてしまったがために、問題が発生しても軌道修正ができず、プロジェクトが遅延してしまいました。その結果、最先端でも何でも無く、使われないモデルにコストと時間を浪費したという内容です。
このプロジェクトは、幹部が当時の最先端技術であるBERTに強く惹かれ、会社が最先端技術を使った分析をしていることを社内外にアピールするために発足しました。
しかし、データ準備の段階で、データの数が極端に少なく、粒度もバラバラであることが判明しました。そのため、最先端の機械学習モデルBERTを使用した場合でも、比較的単純な機械学習モデルと精度が変わらないことがわかりました。それにもかかわらず、最先端技術を使うこと自体が目的 となってしまっていたため、モデル変更等の方向転換ができませんでした。
結果として、プロジェクト発足から1年後にようやくモデルが完成したものの、その時点ではBERTはすでに流行を過ぎていました。加えて、特に何かを解決するという目的もなかったため、作成されたモデルは実用化されませんでした。
失敗事例2: 曖昧な動機による失敗
AIやデータ分析等が流行っている関係で、「とりあえずAIがあれば何か出来る」 と考えている方もいると思います。しかし、このような課題解決よりも新技術を使いたいという憧れが先行した、目的が存在しないプロジェクトは失敗してしまう場合があります。本書ではそのような事例として、「AIという言葉の曖昧さ」が紹介されていました。この事例ではコスト面や費用対効果を考えず、AIを使うことだけしか決まっていなかったため、プロジェクトを始めると実現が困難になり、プロジェクトが頓挫したという内容です。
このプロジェクトでは、節電をテーマとして、その解決にAIを使うという事だけが決まっていました。そのため、AI導入のビジネス的な費用対効果や、開発後のメンテナンスコストなどを十分に検討せずに進められました。加えて、AIやDXの経験者が不足していたため、「AI」・「DX」という言葉の意味が人によって異なる 状況でした。それにより、プロジェクト内で認識のズレが生じていました。
その結果、AIを使うこと自体が目的 となってしまい、本来1～2千万円のPoCで済むはずだったコストが、数倍から十倍に膨らんでしまったため、プロジェクトは頓挫し、方向転換を余儀なくされました。
私たちはどうするべきか？
この2つの事例から言えることは、「プロジェクトの目的を明確にし、手段が目的化しないようにすること」 です。
最先端技術やAIの導入は、それ自体が目的ではなく、解決すべき課題があって初めて必要になるもの です。
プロジェクトを進める際には、まず 「何が問題なのか？」 「それを解決することでどんな価値が生まれるのか？」 を明確にし、その目的に対して適切な手段を選択する必要があります。
また、「AI」や「DX」といった曖昧な言葉に頼らず、具体的な施策やアプローチに落とし込む ことで、チーム内の認識のズレを解消し、適切な意思決定を行うことができます。
このようにデータ分析を成功させるためには、データ分析の目的を定めた上で、「手段を目的化させない」 ことが不可欠であると考えます。
輪読会を通じて得られた主なアクション
- 思うような結果が出なかったとしても、結果や仮説を歪めない
- シンプルな方法で課題が解決できないかまず模索し、機械学習のようなツールを使うことを目的化していないか確認する。
- ビジネスチームと連携を密に行い、目的を見失なわないようにする
- 分析中に違和感を感じた場合、無視して進めず、相談や深堀りをする
感想
本書籍はデータの品質や解釈ミス、プロジェクト進行の落とし穴など、実務に直結する内容が多い点が魅力でした。特に成功事例が着目される中で、失敗事例にフォーカスしている点は、「分析をする際に同じ過ちをしないようにする」という目的に合致しており、輪読会の書籍に選んで良かったと改めて感じました。
加えて、この本を通じて議論することで、チーム内の共通認識が得られたことも大きな成果となりました。
まとめ
本記事では、データ分析における失敗事例をもとに、分析の落とし穴や注意点について考察し、チームで掟を作成しました。
以下、本記事の簡単なまとめです。
- 「AI」「データ分析」は銀の弾丸ではない: データ分析や機械学習は万能ではなく、誤ったデータや仮説のもとでは正しい結果を得られない。
- 想定通りの分析結果にならなくても許容せよ: データや結果の改ざんを防ぎ、正しい知識をもとに健全な意思決定を行う文化が重要。
- 手段を目的化しない: AIやDXなどの技術導入が目的ではなく、解決すべき課題を明確にし、適切なアプローチを選ぶことが大切。
これらのポイントを意識し、より良いデータ分析を実践していきたいと思います！
ブログ協力者
本記事は以下のメンバーで執筆を行いました！
Discussion