2018年01月24日に開催された『RLSMeetup#7プランナー・サイエンティスト・エンジニア三位一体！年間十数億稼ぐチームの舞台裏』での発表資料です。 十数億円を生み出した案件で、データサイエンスチームがどのように取り組んで成功を収めたのかの裏側を紹介します。 https://recruit-lifestyle.connpass.com/event/74957/ リクルートライフスタイル　大原　一輝

1. 大規模案件で
データサイエンスチーム
を活躍させる取り組み
20180124
1

2. 誰？
• 大原一輝
• 専門：統計学
• 中途入社、ライフスタイル2年目
• ポリシー：起案から基礎調査、モデリング、
運用まで全部できる個人・チームを作る
• データサイエンスチームのリーダー
– 後述する役割でいうとビジネス寄りの人
2

3. 事の始まり
• 大規模案件獲得できた！
• 大規模なのでチーム作って対応するぞ！
• しかしデータサイエンティストでチーム
を作った経験無い…
• チーム戦の知見を貯めつつ、利益を上げ
る取り組みに挑みたい！
3

4. データサイエンスチーム発足
• 体制
– データサイエンティスト8人程度
– 案件的にはプロダクト側やウェブ解析など他
チームも関わってるので、総計すると20人弱
• 定義
– ここでいうデータサイエンティストチームは、
沢山のデータサイエンティストがいて個々人
で沢山の案件こなしてますよってのではなく、
複数人で1つの大規模プロジェクト回すぞっ
て意味でのチーム
4

5. データサイエンティスト
• 様々な人がいる
– 理論寄り、エンジニア寄り、ビジネス寄り
– スキル・興味がレベル・方向性ともに異なる
– 各々得意・不得意な領域を持つ
• どうやって協力していこう？
5

6. 案件概要
• 日次バッチで各商品にレコメンドスコア
を付与し、売上アップを狙う
6

7. まずチームの責任分掌を決める
• ここがフワッとしてるとタスクが宙に浮
くので、案件のタスク洗い出して、デー
タサイエンスチームのポジションと役割
分担を明確にする
• メンバーのタスク割り振りはその後
• 重要なのは後述する具体的なタスクその
ものではなく、やるやらを決めること。
タスク一覧はあくまで参考、案件次第
7

8. チームで何をする？
1. 基礎調査
2. モデリング
3. バッチ開発
4. バッチ基盤開発
5. ABテスト
6. ABテスト振り返り
7. データサイエンスチーム内のPM
8

9. 逆に、何をしない？
1. DWHや基盤エンジニアリング：CET
2. 営業調整
3. カスタマー・クライアント対応
4. サービス側のエンジニアリング
5. フロントエンド
6. 案件全体のマネジメント
7. 経営層報告や事業調整
9

10. 他チーム協業はビジネス系担当
• データサイエンスチーム内では取り組ま
ないものの、案件として取り組むべきタ
スクは幾らでもある。そこを他チームと
協業するパイプ役が必要
• ある程度データサイエンスわかるビジネ
ス系の人がパイプ役になると良い
– [個人的意見]居ない場合は、非ビジネス系
データサイエンティストより、極論データサ
イエンス一切わからないビジネス系人材の登
用が良さそう
10

11. 具体的にどう進める？
• Kaggle的なコンペ形式
– 規定評価指標でモデルを採点して競う方式
– 随時手法公開
– 週一で共有会
– GHEでレビュー、slackで相談を逐次実行
• 複数のABテストスロットに実戦投入
• 上記コンペ→ABを１サイクルとして何度
も回し続ける
11

12. やってみよう！
コンペ→ABサイクル
12

13. AB第1弾の対応を考えてみた
• メンバーによってゴールが全然違う
– ゴール＝何を最適化するか？
– 最初に議論して「何を目的変数にするか」「精度
指標とするか」を合わせ、打ち手や最終目的が異
なっていても、相互レビュー可能なようにする
– 評価指標が統一されてないと、どの打ち手がどの
程度良いのかや取り組みの価値がわからない
• スキルやデータ理解度が違う
– 実務データは複雑かつダーティ
– 得意分野が異なる
13

14. コンペ形式の下準備
• 問題設定
– チームのゴールと指標統一
• マート用意
– データ理解の最低限を担保
• リーダーボード
– スコア確認で自身の手応えを得る
• リポジトリ管理
– コードや手法共有
14

15. 良かった点
• 様々な打ち手が出てきた
– ツリー、強化学習、word2vec、NLP、時系列…
• 手法やデータの知見共有ができた
• 競技的な取り組みで仕事のモチベアップ
• メンバーの相互育成に繋がった
– 中堅→若手：ドメイン知識や実践面の共有
– 若手→中堅：最新の手法や理論面を共有
15

16. 出てきた問題点
1. メンバーのエンジニアスキルが大きく異なる
2. 理論系のメンバーが書いたバッチ、エンジニ
ア的には多大な改善余地がある
3. エンジニアが頑張ってリファクタする
4. →エンジニアが疲弊する
→エンジニアリングレベルを担保しよう！！
16

17. 第2弾の対応策を考えてみた
• エンジニア系メンバーにコード規約や利
用ツール含め、様々なフローを結構細か
く規定してもらった
17

18. 出てきた問題点
• 理論系メンバーがエンジニアリングスキルを
求められる規約に合わせるのは厳しい
– 独自Github flow, Docker, Kubernetes, AirFlow
• 環境制限のため様々な打ち手を阻害する
– XGBoost, NLP, 強化学習, word2vecなど使いたい
– Docker使えば確かに環境切り分けられるけど、
管理が大変になってくる…
• [個人的意見] 多様性を無視し全員にエンジ
ニアリングレベルを求めると、普通のエンジ
ニア集団になる
18

19. 第3弾の対応策を考えてみた
• エンジニア寄りと理論寄りのメンバーでサ
ブチームを構成して相互補完
• これまで各メンバーに時間配分任せていた
が、それだとメンバーによってはモデリン
グだけするなど何かに特化しがちなので、
大まかなスケジュールを設定して臨んだ
– 基礎調査→モデリング→バッチ開発を1～2週間
ずつ
19

20. 結果
• 結論、めちゃくちゃ良かった！！！
• お互いの立場を超えた連携
– エンジニアは理論の、理論系はエンジニアの
知見を協業することで理解できた
– 理論系もエンジニアに負担にならないような
コードを書くという心掛けが真に理解できた
• 各タスクごとに期間を設けたので、おざ
なりになるタスクがなくなった
• 3回目以降はこの形式で運営中
20

21. データサイエンスチーム
ベタープラクティス
1. 最初にデータサイエンスチームのポジ
ションとタスクを明確にする
2. コンペ形式でモデルを磨き込むことによ
り、成果改善とメンバーのモチベ・スキ
ルアップ
3. サブチームを作り、理論系やビジネス系
とエンジニア系を混ぜて相互補完する
4. 各タスクに掛けるリソースとスケジュー
ルを大まかに設定してサブチームに渡す
21

22. まとめ
• サブチーム作ってメンバーのスキルを相互補
完するようにしよう
• コンペ形式はモチベとスキルアップに効果的
• お膳立ては大変だが、成果は上々！！！
• 細々した調整もやるビジネス寄りの人がいる
とデータサイエンスチームの運営がスムーズ
• データサイエンスチーム作りは手探り多いが、
十分なリターンを見込める。挑戦しよう！
22