尾花山ら「データ分析失敗事例集: 失敗から学び、成功を手にする」読んだ

データ分析失敗事例集: 失敗から学び、成功を手にする

著者から恵贈いただきました．

タイトルの通り，この本ではデータ分析業務において誰もが一度は経験したことのある失敗事案が大量に (25件) 書かれています．

• 冒頭でプロジェクトの利害関係者が整理されているので話に入りやすい
  • 分析プロジェクトにおいては受発注，親会社・子会社，協業などの様々な関係が入り乱れることが常です
  • 自分がなんらかのプロジェクトに関わる場合にも，このあたりの関係を把握しておくとプロジェクトにおける力関係が把握できて良いと思います
• どの事例も非常によくある
  • 「目的より技術が先行してしまう」「思い込みばかりが先行してしまう」「意地やメンツを優先するあまり引き返せなくなってしまう」「意見の妥当さよりパワーバランスが優先されてしまう」など，非常にありふれた原因による失敗がこれでもかと網羅されている
• 振り返りが良い
  • インターネットで注目を集めるデータ分析失敗事例は往々にして「技術を理解しない営業・経営者が全部悪い」に落ち着きがちですが，本書はそのような安易な振り返りでは終わりません
  • ここが本書の良い点だと思います
• 一方で，あとがきにもあるように「成功を手にする」は難しい
  • なぜなら「こうすると失敗する」というのはアンチパターンであって，それを避けたらじゃあ上手くいくのかというとそういうわけでは無いことに注意が必要です
  • 「野菜の皮は剥く」「じゃがいもの芽には毒があるから外す」「煮込む時は焦がさないように弱火でかきまぜる」を守っても，まずいカレーは回避できるかもしれませんが美味しいカレーができるわけではないからです
  • とはいえここまでいくと「成功」の定義は何かという話になるわけですが
• 以下に書くように議論が盛り上がると思います．会社で本書を使って読書会をするのが良いのでないでしょうか

ここからは個々の事例で気になった点を書きます．

• 「1. UI を統一して UX が破綻する」
  • 深く掘られてはいませんが，本書においてこの事例が最も困難だと思います
  • おそらく現実的な選択肢は「良くも悪くもゴリラのように超人的な腕力と根性を持つ一人の PM が解決する」か「個別のダッシュボードを大量に乱立させて蠱毒のように生き残るまで待つ」の二択
  • もし自分ならば「会社・チームにデータを見る文化・価値観を根付かせる方が先」と考えて後者を選びたい
    • ものを作るより文化や価値観を作る方が難しい
    • もし個別のダッシュボードを作ってそれが全て終わってしまったら，それまでということで
• 「4. 本当に季節性はありますか」
  • 「担当者の思い込みが原因」とで終わる話ではないと思う
  • なぜなら「季節性があると信じるに至った理由」が何かしらあるはずで，時に人はそれをドメイン知識と呼ぶのではないでしょうか
  • 一歩間違えると「データだけを見てドメイン知識を取り入れなかったデータ分析担当者が原因で失敗した」という事例にもなりうる
  • 「現場の人が言うことは正しく，間違っている」の気持ちが大事だとは思うが，とはいえ実際には難しい
• 「7. ほとんど故障しない製品の故障予測」
  • 登場人物の「関連会社研究所のデータサイエンティストR氏」を見て「これはR氏がデータを見ずに最先端の論文を振りかざして大失敗する話だ」と予測したら外れた
  • 話は良かったですね
• 「10. 成功した報告しか聞きたくない」
  • この事例の議論には違和感があり，そもそもB社のマネージャーY氏目線なのか，データサイエンティストT氏目線なのかで話が変わる
  • マネージャーY氏目線
    • 効果検証ではなく事業提携について検討するための分析であるならば，Y氏がT氏に適切にそれを説明すべき
    • そもそもT氏を暴走させるあたりY氏が何もしていないように見える
    • Y氏が最終報告会の前に最低限B社関係者に「A社の分析が妥当ではないこと」を根回しするのが落としどころでは
  • データサイエンティストT氏目線
    • 「X氏の誘導する意思決定は避けられない」ならば，T氏にできることは可能な限り速やかに手を引く，または退職することでしょう
      • 今後業務提携が進んだ場合，A / B 社は適切なパワーバランスではなく，X氏による支配は避けられず，同様の事例が発生し続けることが目に見えており明らかにT氏の精神衛生に悪い
      • マネージャーのY氏がこれまでと同様に今後何もしないことも目に見えている
• 「17. いくら分析したところで，売れないものは売れない」
  • そこまで分析失敗の事例とは思えません
  • 孫請けのデータ分析会社のZ氏について「不良在庫を抱えることになってしまった原因は，契約上の責任はさておき， 技術倫理の立場で言えば，そこを押し切られてしまったZ氏にあると言っても過言ではないでしょう」は言い過ぎ
    • 商品設計を失敗したことの方が問題で，Z氏ではなく，発注元A社やウェブ開発会社B社の責任を問うべきでは
  • 僕はもっとポジティブで，「黎明期にどのように売り物にしていいかわからない時代にあってもどうにか売上が出ていたのだな」という気持ちです
    • これの事案についてはそもそも「我々はインターネット広告が商品として完成した世界に慣れすぎてしまっている」という，後付の理屈があるようにも思いました
• 「25. 機械学習モジュールの寿命」
  • とても良い話
  • の一方で，そこまで (中長期的に) 成功したのかというといくつか疑問が残ります
    • どのような犯罪行為であって，行為の検知やその対応をどのように行っているのか
      • これは詳しく書けない領域だとは思いますが
      • これによって機械学習を用いるかどうかが変わってくるように思います
    • MLOps の維持コストよりもカスタマーサポート側の人的コストの方が高いのではないか
    • 悪意を持ったユーザ / システムがルールを回避しようといたちごっこが発生するのが想定される (だからこそクレジットカード会社や SNS などはここにコストを払う) わけですが，その度にルールを書き換えるのか
      • どのように?
      • いたちごっこに対応するには「ルールの整備」というコストが発生し，それは機械学習モジュールをメンテナンスし引き継ぐコストと同等になるのではないか
        • 落とし所としてはパイプラインそのものを維持し続けるのではなく，定期的なモデルの再学習を行うのではないでしょうか
    • どれだけ本気で犯罪行為に対応したいのか
      • 極端な話，不正検知を取りこぼしたとしても「ごめんなさい」で済むのならばルールすらもいらない可能性がある
        • ユーザやカード会社から問い合わせがあった場合のみ対応すればいい
      • このあたりの費用対効果の話になると「技術倫理」という単語から「フォード・ピント事件」を連想するわけですが