分析部門におけるプロジェクトの選択と進め方のお話です

1. プロトタイプで終わらせない
死の谷を超える
機械学習プロジェクトの進め方
@shakezo_

2. 自己紹介
名前：@shakezo_
所属
株式会社リブセンス Analyticsグループ
2014/7入社
職種
データアナリスト
仕事内容
社内データの分析
機械学習・情報検索技術を活用したサービスの企画・開発

3. 運営サービス
アルバイト求人サイト「ジョブセンス」

4. 運営サービス
正社員転職サイト「ジョブセンスリンク」

5. 運営サービス
転職クチコミサイト「転職会議」

6. 所属部門
2014/7に発足した部門横断のアナリティクスグループ

7. 本日のお話し
MLやIRを活用したプロダクト開発と改善をどのよう
に行っているかについての事例紹介
注）具体的なアルゴリズムの話はしません

8. この話が役立ちそうな人々
これからデータ分析部門を立ち上げる人、立ち上げ
たばかりの人
他の会社がデータ分析のプロジェクトをどのように
回してるかが気になる人

9. 機械学習系の
プロジェクトの特徴

10. 機械学習は苦しい
言いたいことは大体ここに書いてあった
機械学習の仕事は研究開発に近い

11. 研究開発とデスバレー
研究開発プロジェクトにおいて、基礎研究から製品化の
間に立ちはだかる障壁のたとえ

12. 機械学習とデスバレー
魔の川
プロトタイプの段階で十分な性能が出なかった
死の谷
プロトタイプがサービスに適用されなかった
ダーウィンの海
サービスインしたが大した効果がでなかった

13. 成果を出すポイント
きちんと成果の出るプロジェクトを選定する
分析・開発プロセスをマネジメントする
運用・改善・施策を打てるような仕組みにする

14. プロジェクトの選定

15. プロジェクト選択の評価軸
開発・サービス化の難易度
・精度要件：誤差はどこまで許容されるのか
・システム開発：テスト環境評価が可能か？現行システムに組み込めるか？
アウトプットの性質
・売上に直接寄与するのものか、ユーザ体験を向上させるものか
成功時の期待リターン
・サービスにどれくらいの影響を与えるのか

16. プロジェクト選択の評価軸
開発・サービス化の難易度
・精度要件：誤差はどこまで許容されるのか
・システム開発：テスト環境評価が可能か？現行システムに組み込めるか？
アウトプットの性質
・売上に直接寄与するのものか、ユーザ体験を向上させるものか
成功時の期待リターン
・サービスにどれくらいの影響を与えるのか
何がベストかは部門や会社の状況に依存

17. 当時の所属グループの状況
出来たばかりでグループとしての実績はない
それなりに期待はされている模様
分析部門はなくても会社は回る
とりあえず１つ実績を作りたい

18. 設定した条件
開発・サービス化の難易度
・低リスク・中リターン
・自部門で独立してプロトタイプの開発・性能検証が可能
・精度要件が厳しいテーマは避ける
アウトプットの性質
・利益に直接寄与するものを選択する
・サービスの本質的価値を向上するものを選択する
成功時の期待リターン
・データ分析すごい！投資する価値がありそうってなりそうなものを選択する
・できるだけ他サービスに横展開できるものを選択する

19. ペイオフマトリクスによる評価
プロジェクト候補をインパクトと難易度の２軸で評価
アトリビューション分析
採用率予測 求人レコメンド
エンジン開発
クチコミ
ネガポジ判定
不正投稿
の自動検出
名寄せ自動化
難易度
インパクト
易難
大
小
パーソナライズド検索
採用
※インパクト・難易度は組織の状況やビジネスモデル、メンバーの得意スキルに依存

20. 求人レコメンド
転職会議/ジョブセンスリンクの求人ページのアクセ
スログをベースにオススメの求人を推薦

21. 選定理由
開発・サービス化の難易度
・精度は重要だが、現状より良い物ができれば良い（100発100中でなくて良い）
・メルマガ配信からスタートすれば、既存システムへの影響が軽微である
アウトプットの性質
・直接的に売上寄与し、貢献度の計測が可能
・マッチングというサイトの本質的な部分に貢献
成功時の期待リターン
・全社売上の数％アップ程度を期待

22. 開発プロセスのマネジメント

23. ステージゲート法の概念を活用
プロジェクトを4ステージに分割し、ステージごとに評価
分析企画
プロトタイプ
開発
ユーザ
テスト
システム
開発
ゲート1 ゲート2
ゲート3
そもそもサービス運営を
している事業部からみて需要
はあるか
バックテストで十分
な性能がでているか
サービスとしての
価値が出せるか

24. 目的のすり合わせの実施
対象サービスのプロダクトマネージャーに話を通す
開発内容に加えて、提供するサービスの内容につい
ての合意もとり、目的の共有化と互いの部署で発生
する作業についての共通認識をつくる
共同プロジェクトにすることが重要

25. プロトタイプの開発
CRISP-DMによる開発マネジメント
・データの確認
・必要なデータはあるか
・sparsityは問題ないか
・文献調査
・手法の検討
・実装
・バックテストによる定量評価
・人の目による定性評価

26. ユーザテスト実施
分析部門内で簡易的なメルマガ配信システムを開発
サービス部門の負荷を極力減らしてテスト開始
メルマガをテスト配信して実際のユーザの反応をみ
て評価・修正
最終的にCVRが従来メルマガの2.5倍となり、本番運
用が決定

27. クソコード問題の発生
試行錯誤の結果が残るぐちゃっとしたコード
当然テストコード書いていない
例外処理もかなり適当

28. 対処法
機械学習がある程度わかるエンジニアを分析チーム
内で抱える
分析者と機械学習エンジニアが協力してプロダクト
を完成させる
お互いの得意な部分を活かしてカバーしあう

29. プロジェクトの役割分担
役割
スキル
• システムしてきちん動くものにする
• サービス運用部門のエンジニアとの
技術的な部分の諸々の調整
データ分析者 機械学習エンジニア
• ビジネス構造を把握してビジネス
課題を分析課題に落とし込める
• 学術論文の参照して適切な手法を
選択できる
• プロトタイプ実装・評価ができる
• ROIの見積もりとプロジェクト選定
• 分析プロセスのデザイン
• プロトタイプの開発
• 機械学習の基本的な知識がある
プロトタイプの中身を理解できる
• プロダクトレベルの実装ができる
• クソコード耐性に加え仕様変更に
対する柔軟性と曖昧さ耐性がある
分析者とエンジニアを事業部から分離されたチームに
置くことで利害の不一致を防ぐ
※今回プロジェクトの役割分担であってプロジェクトごとに流動性を持つ

30. 運用・改善・施策を
実行可能にする

31. 分析部門と事業部の連携
レコメンドエンジンをAPI化して担当範囲を明確化
分析部門
・レコメンドの性能の保証と改善
事業部
・レコメンドサーバのデータを
自由に取り出してサービスに活用

32. 運用改善プロセス
事業部間で協力してプロダクトを改善
分析者
機械学習エンジニアサーバサイドエンジニア
ディレクター
ロジック検討、改善施策の検討・実施
システム実装プロダクション反映
事業部サイド 分析部門
開発
企画
役割
所属

33. リリース後の施策
応募完了画面で応募求人と類似求人推薦
求人詳細画面への組み込み
紹介案件数が少ないメルマガの補足求人施策
タイトル・文面のABテスト
メルマガ配信のテスト（週次配信・日時配信・応募翌日配信など）
ログの利用期間の変更とテスト
ログの種類による重み付け（閲覧・応募・お気に入り）
その他社外秘施策もろもろ

34. レコメンド経由の応募が
転職会議経由の全応募数の25％にまで増加

35. 現在の取り組み
レコメンドの
他サービスへの展開
広告効果の分析 採用率予測
レコメンドエンジンの改善
リスク 高低
インパクト
大
小
プロダクトのポートフォリオをリスク・リターンの観点で分散させて
取り組み範範囲を拡大

36. まとめ
研究開発プロジェクトの手法を用いて企画からプロ
トタイプ開発、本番化までを進めた
API化することで精度改善とサービスの改善を切り
分け、サービス運用部門で自由に活用してもらう形
にしたら、色々活用してくれた

37. 分析を支える環境
部門横断組織で通常のイテレーションとは別に時間を
かけて試行錯誤できた
最初に取り組んだ転職会議は、機械学習やレコメンド
に好意的で結果が出る前から期待していただいていた
会社がデータ分析に理解がある
良いものはどんどん使おうという全社的な文化

38. FIN