データサイエンティス養成読本[ビジネス活用編]を読んで

今回読んだ本：
データサイエンティス養成読本[ビジネス活用編]

読んだ理由

データサイエンス駆け出して、活用シーンはなにか、何を勉強するべきなのか、
全体的にもやっとした感じだったので、
すこしでも解決してくれそうなこの本を読んでみました。
すくなくとも読む前より自分なりの道筋に見通しができた気がします。

そこで本書を読んで気になったことを備忘録として残しました。
どの章も興味深かったですが、特に3章と6章を。

第3章:機械学習プロジェクトの進め方

プロジェクトのビジネスサイクル

ビジネスデザイン

• TODO

  • ビジネス課題の定義
  • 課題を解決するためのUX設計、マネタイズ、マーケティングの設計
  • どのようなサービスを運用・開発するか決める

• 機械学習がボトルネックになるか？

  • 機械学習に依存度が高くなる場合、初期の段階ではフィージビリティが見えにくい
  • PoC(概念検証)を繰り返して、フィージビリティを確認しつつ進めると良い
  • プロトタイプをつくりつつ、検証をすすめる

• 他に解決策がないのか

  • 「やってみないとわからない」状況になった場合、バックアッププランを考えるか、機械学習の不確実性をおさえる
  • プロジェクトの目的が、 ビジネス課題の解決 である異常は、機械学習をつかう意味があるか自問するべき

• 意思決定者と協力体制を気づく

  • モデルを構築する際は、ドメイン知識を使った特徴量エンジニアリングやチューニングが必要にな
  • プロジェクト、学習モデル、難易度などを、意識してビジネスメンバーに伝えないと疎結合になる
  • プロジェクトに関わるメンバー全員が「運命共同体」として、協力を引き出さないと失敗のリスクを高める

• ビジネス価値を定量評価する・評価指標を決める

  • AI導入後に効果が見えないプロジェクトは次につながらない

データ設計・取得

• データは自社で取得できるか

  • 取得できても、取得難易度が低いデータでは優位性は生まれにくい
  • アノテーションする作業や、開発リソースがあるか確認する

• データを継続的に取得できるか

• トレーニングデータは実態を反映しているか

データ分析・モデル作り

• データの前処理(EDA)
• ディープラーニングのような流行りで解くかは、よく考えるべき
  • 推論コスト、チューニング難易度が高いため

システム実装

• 推論をサーバ、クライアント、エッジデバイスを使うか検討が必要
• モデルの更新や、モニタリング、ユーザへの影響範囲を見据えて検討するべき

運用

• モデルに評価指標の監視体制
• データ取得と再トレーニングのスケジュール
• 既存サービスへの影響の有無の判断

プロジェクト成功のために

• ビジネスチームがデータに理解があったり、意思決定者と密な関係にあれば、期待値の調整にかかるコミュニケーションコストは減らせる
• 機械学習プロジェクトにおいては、可能な限り「スーパーマン」を求めない体制づくるが重要

現場との期待値調整

難易度の高い工程になるのは、「アウトプットに対して正しい期待値を持ちにくい」から

• 最初から制度は保証できないこと
  • 事前に機械学習エンジニアは見通しを持つべきだが、難しい
  • プロトタイプをつくって、最低保障のベースラインを気づくと期待値の共有を進めやすい
• プロジェクトを通じて期待値は上下すること
  • 推論コストがかかったり、チューニングにじかんがかかったり、うまくいかない場合がある
  • 事前に「不測の事態があるかもしれない」共通認識をしておくべき

期待値の提示の方法

• 報告には3つのラインを出す
  • 現実ライン：その時点での現実的な着地点
    • 高頻度で合意することで、期待値の幅について共通認識できる
  • 最低ライン：想定通り行かなかった場合の保守的な見通し
    • 仮にうまく行かなかった場合の出口に使われる
  • 理想ライン：プロジェクトの最大限夢をもった場合の見通し
    • プロジェクトメンバーの道標になる

第6章：データ分析のはじめ方

• 前処理後のデータが集まったら問題設定をする
  • 自社のビジネス課題に対して、何らかの示唆を与えられるかどうか
  • 売上の伸長やコストの削減でどのようにビジネス課題に貢献するか
• データ分析は大別すると2つ
  • 探究的分析
    • 仮設がぼんやりしていて、課題が設定されていない場合の分析
    • 基礎集計、散布図、クロス集計、可視化をし仮設を発見する
  • 検証的分析
    • 既にもっている仮設がある場合
    • さまざまな条件を盛り込んで分析したり、A/Bテストをしたり、仮設検定をしたり

探求的分析

1.データ抽出

• データベースの構造を確認
  • 数億レコードのテーブルを全量取得しないように注意
  • select * from hoge limit 5; など
• データのサイズを確認
  • select count(*) .. など

2.基礎統計用の把握

• 平均、中央値、最頻値、最大、最小、偏差などを求める
• 平均値、中央値、偏差などから、データに異常値が潜んでいないか確認

3.問題の設定

• データの傾向をクロス集計などで確認する
• 様々な軸をかけ合わせて、せこ入れが必要そうな箇所をさぐる
• 分析軸はその後の分析に関わりそうなものを優先する

4.散布図

• クロス集計同様、散布図による可視化によって問題設定をする
• 散布図でデータのちらばり具合をみる
• 近似曲線をひくことによって、xとyの関係を数値化する(相関係数)
• 散布図には各データにカテゴリ(色、形)をもたせることにより正確に理解できる
• シンプソンパラドックスに注意
  • 同じデータでも分析の仕方によって全く矛盾したように見える結果が得られること

KPIの設計とモニタリング

• ダッシュボード化して、KPIをモニタリングすることによって、問題設定に適切なアクションができているか、予期しない変化がおきていないか継続的に確認する

自社のセンターピンとなるKPIの決め方

• 経営者層、ディレクター、開発者では指標が違う
• バランスよくダッシュボードに落とし込む必要がある
• KPIを運用する上での注意点
  • 多すぎるKPIは無駄
  • KPIは変化するものである
• 優れたKPIの条件
  • わかりやすく、比較は可能で、変化により行動可能な指標
• KPIを上げだすと、いろんな観点ででてくるため焦点がぼやけがち
• まずはセンターピンになる1つのKPIを設定する
• その後それを保管する、3~4つのKPUを設定する

ダッシュボードの選び方

• ダッシュボードの主な候補
  • 有償：PowerBI, Tabluau
  • 無償：Datastudio, Re:dash, Looker
• 有償はGUIも優れ、サポートもあり、普及までの近道
• 無償はオープンソースが多いため、カスタマイズがきく
• それぞれ、ほかツールとの親和性も考えつつ選定すると良い

ダッシュボードの運用

• 日々のビジネスの変動にあわせて、対応が必要
• ダッシュボードのDAUは日々へっていく
  • サッシュボード利用者のログも取得して集計することも必要
  • 減衰傾向であれば、改善などサポート体制も見直す

チャットでのモニタリング

• 定期的にKPIをSlackなどに通知
  • 些細な変化に気づける
  • 突発的な要因分解にも役に立つ
• 組織内で共有することにより、データリテラシーも上がる