[読書メモ] データ分析失敗事例集
zukako
- 大学でDSを専攻していたが結局DSになることもなくクラウドエンジニアの道を選んだので、非常にリアリティのあるシナリオで語られていて面白い
zukakoPart 1 「えーあい」で何とかして
最近はあまりこういった話は聞かなくなったものの、「えーあい」に対する期待値のみが先行していた2018-2020あたりのシナリオが主な感じがした。多くの事例において、DS側の機械学習を適用する対象となるデータ・産業・機械学習モデルの使われ方といったビジネス側面を蔑ろにしていることが原因。データに対して予測精度が高くても、そもそもその予測ってオペレーション上必要なんだっけ？とかそういうところ。それもまぁ「えーあい」に取り組んでいますというブランディングの元で霧に包まれてしまっていたそんな時代背景もある。そんで、DS側としては人事評価の基準が難しくて、そのプロジェクトの難易度とかを測れる人がマネジメント側にいないとただえげつないプロジェクトに巻き込まれてうまくいかなかっただけで評価が下がるとか、そういう話になってしまう。お客さんのお気持ちを優先としつつも、言いなりになってそのまま実装するのではなくて、できることできないことを伝えながら過度な期待をさせない期待値コントロールをすること、そしていきなりAIに取っかかるのではなくて仕組みづくりと可視化で対応できるところはするという姿勢も大事。
zukakoPart 2 翻弄されるデータサイエンティスト
- 効果検証には気を付けた方がいい。実施したキャンペーンが有益であったことをもちろんクライアントは証明したがるため、それを支持する結果を出した分析が採用されるに決まっている。それがデータ分析として正しくはないにしろ見せかけに騙されがち
- 勝手に分析手法が決められていることもある
- 自社サービスをよく使っている＝自社サービスのみを使っていて競合は使っていない、わけではない
- メルカリのヘビーユーザーはヤフオクもラクマも使うだろう。みたいな話
- 社内政治的な力が働くことで”正しい”データ分析を行ったところでその結果が軽視され、権力者に都合のいいようにモデルが操作される可能性もある
- 人的リソースのかけ方としては、結局のところお客さんの要望・じゅようをじゅうぶんにはあくすること以上に大事なことはなく、分析がいくら素晴らしくてもお客さんとして使い物にならなければ意味がないし、需要があれば単なる集計だとしても価値があることになる。
- 機械学習の出力が”人間が解釈できないもの”は売れない。クラスタリングは様々な変数からクラスタを作るが、クラスタに対して人間が解釈できる意味づけができなければ商品としては成立しない。
zukakoPART 3 その失敗を超えて行け
- 小売店にデータサイエンスを当てはめる際（よくあるのが在庫予測）には季節性のあるものが要注意であり、必ず一定の日・一定の期間しか販売しないものがある。これらを予測モデルに含めるとノイズになる可能性が高い。そして、小売りについては発注がロット単位であることが多いため、いかに精緻に予測したところでそのロット分は精度がぼやける。なので、個数単位の予測は意味がないかも。この辺の所感はデータを管理している人に聞くか、実際の運用から組み込むシステムをクリアにしておく必要がある。
- 受託会社と発注元の間での認識のずれが多き名失敗を読んでいるケースが多い。教師データの恣意性については合意を取らないと。成功判定の要件定義・イメージのすり合わせ・データの背景確認・フィールドワーク。
- 現状のシステムの挙動を精緻にするために機械学習を利用するのではなく、利用者にとって最善になるようなシステムフロー自体の変更も一考すべき
- 共感したポイント
- 違和感を大事にする：違和感は自分か減少のどちらかに異変が起きている可能性が高い
- 業界感のある人に確認：先達の知恵を借りれるなら借りよう
- データの発生源について深堀する
- 知識の共有：社内チャット、外部問わず知識を共有して晒すことで一定のレビューがかかった情報として残すことができる
- スコープが定まっていない案件は断る勇気も大事。もしくは自分でその言語化のコストを払えるか否か。
- ステークホルダを買いかぶらないこと、言葉の定義1つとっても解釈が異なる可能性がある。
- 最終的な目的を確認すること
zukako締め部分と全体感想
若干古風な手法を用いて実施されてきた機械学習プロジェクトの顛末を、雰囲気だけでも感じ取れたので学生時代そのままDSになっていたらこんな案件に巻き込まれていた可能性が高いのかなと思いをはせた。古風とは言いつつも、枯れた手法なので現在も多くのプロジェクトと共通する部分はありそう。
エピローグ、発注者として「分析者をうまく使うには責任を負わせないこと」は大共感。発注側の目的としてはコスト削減したいとか売上伸ばしたいとかあるのかもしれないが、そもそもそれができるかの確認を含めて行うべきであり、そこのKPIの達成は発注側の責任。自分たちの責任を転嫁したうえでYes/Noだけを見ていると、分析者の試行錯誤から少なからず得られる知見を無碍にしてしまうことになる。それだけは避けるべき。何かが得られたのであれば、それは「失敗」ではないはず。
zukakoデータ分析に仕事でかかわり始める人は一回読んでおいて損はない