Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ビジネス(の人)的に嬉しいコンペ開催のやり方

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.
Avatar for Yusuke Kaneko Yusuke Kaneko
November 13, 2020

 ビジネス(の人)的に嬉しいコンペ開催のやり方

Discovery DataScience Meet up (DsDS) #1 での発表です.
atma社と共同で行ったデータ分析コンペから生じた知見やデータ分析コンペを開催することによるビジネス的価値の話をしました.

Avatar for Yusuke Kaneko

Yusuke Kaneko

November 13, 2020
Tweet

More Decks by Yusuke Kaneko

Other Decks in Business

Transcript

  1. 自己紹介 2 金子 雄祐(28) 職業: AI事業本部 Dynalyst データサイエンスチームリーダー 経歴: 2018年:

    東京大学大学院経済学研究科統計学コース卒(修士) 2018年: CyberAgent 新卒入社 2019年: Dynalyst異動 やってるタスク: 予測モデル開発, クリエイティブ評価&最適化改善, チームマネジメント paper: Kenshi Abe, Yusuke Kaneko: “Off-Policy Exploitability-Evaluation and Equilibrium-Learning in Two-Player Zero-Sum Markov Games” twitter: @coldstart_p 
 kaggle:
 @ykaneko1992

  2. 自己紹介 3 • Kaggle Master ◦ 金: 1 銀: 4

    銅: 1 ◦ 基本チームメイン ◦ テーブル&Simuation
  3. 参加者が開催側のことを知るメリット 7 1. コンペ設計 = 仕事で価値を出す分析課題を作ること ◦ これを知ることで分析でビジネス価値を出すこととつながるはず 2. 企業としてデータ分析コンペを開催する意義を認識できる

    ◦ 開催するには稼働時間などなどのコストがかかる ▪ 「やる意味ある?」という問いに答えるには? ◦ なんのために企業として主催し,なにが達成されれば成功なのか? ◦ ここで価値を出せればDSとしての価値が追加され得る 3. いざ開催するとなった時にノウハウが知れる ◦ (後述するが)中々開催側の話が知れる機会はない 4. ビジネス職と企画運営をする際のDSとしての動き方の参考になる
  4. コンペにおける4種のプレイヤー 14 現場のDS 目標: 課題解決 ビジネス職 目標: 「いい人」を採る 競技参加者 目標:

    fun & win atma 目標: ブランディング 全員が幸せになるために達成すべき要件は?

  5. 「良い」コンペの再定義 16 1. コンペに適した課題設計 a. 実際に課題解決に繋がる 2. 参加者が楽しく,結果に納得できる a. 普段触らないデータや課題設計

    b. 運ゲーにならない DS: コンペを通じて課題設計に寄与できて嬉しい 競技参加者: 適切に実力が反映され,コンペを通じてしか触れないデータや課題に取り組めて嬉しい atma: 「良い」コンペを開催することでプラットフォームとしての信頼が増して嬉しい ビジネス職: コンペを通じて適切に「スキルがある人」がわかって嬉しい 結局は「良いコンペ」を作って開催しましょうという話

  6. 「良い」コンペを作るには 18 1. コンペに適した課題設計 a. 実際に課題解決に繋がる 2. 参加者が楽しく,結果に納得できる a. 普段触らないデータや課題設計

    b. 運ゲーにならない • 上記の要件を適切に解決するには色々な障害が存在している • これを解決するために現場のDS/ビジネス職/atma でどのように動けるといいのか? • まずはこの実現のための障害の例を挙げる
  7. 「良い」コンペを作るための障害 19 • 提供できないカラムや匿名化などの存在 ◦ コンペの面白さとビジネスリスクのトレードオフ ◦ PMとの交渉コストや,DS&atmaによる落とし所の調整が必要になる • 課題設定の困難さ

    ◦ 1日/1週間/2週間という期間で適切なデータサイズかつ解決可能な課題はそんなにない ◦ 上の期間で解決できるならコンペの開催コストを考えると非効率では? • 蓋を開けてみれば運ゲーになる可能性がある ◦ 事前検証やleak検証などのコストはかなり大きい • 人を集めたりシステムを準備するのが大変 ◦ 基本的には人を集めたほうが盛り上がるがそこの広報などもちゃんとやらないといけない 現場のDS/ビジネス職/atmaがこれらの困難さにどうcommitできるか? 

  8. ビジネス職の強みと弱み 21 強み • 運営,広報などの事務手続き能力 • 採用周りのノウハウ ◦ 採用できればビジネス的に意味が生まれる 弱み

    • コンペの設計はできない • コンペでは参加者の人柄までわからない ◦ コミュニティに属していない
  9. atma社の強みと弱み 22 強み: • コンペ設計実績(設計能力/ブランド価値) • 優秀なシステムの提供 • Kagglerのコミュニティへの知見 弱み:

    • 課題の価値までは現場のDSじゃないとわからない • 持ってこられるタスクはコントロールできない ◦ 無理ゲーを持ってこられる可能性もある ◦ ブランド毀損のリスク
  10. それぞれの価値提供のために 24 基本的にはそれぞれのKPIを達成しやすくなるようにタスクを振る • DS ◦ コンペ設計周り ◦ atma社とのコンペ設計交渉に注力できるように •

    ビジネス職 ◦ 採用事務広報周り ◦ いい人が多く集まり,いい人を採りやすくなるように • atma ◦ コンペ開催支援 ◦ 現場のDSと密にコミュニケーション取れるように
  11. ビジネスリスクを誰が引き受けるのか? 27 • 第1回 CA X atmaCupでは絶対に失敗できないという制約があった ◦ leakや設計のミスは絶対起こせない ◦

    当時は外出しできる最適なタスクを金子が持っていなかった • 社内コンペの流用という形で別プロダクトからデータを持ってくる事に決定 • しかし炎上リスクの問題でデータ匿名化の部分が揉めに揉めた ◦ 別プロダクトの人はコンペ特にやりたくないので炎上リスク0にしたい ◦ 意味不明なデータを提供してコンペ開催しても燃えるのでやりたくない • プロダクトが潰れた場合は誰が責任を取るのか?
  12. ビジネスリスクを誰が引き受けるのか? 28 • 交渉の結果,燃えにくいかつコンペとして開催できる形には落とし込めた ◦ 燃えた場合は結局誰が責任を取り切れたのかは不明 ◦ 結局参加者FBでは「これ本当に解きたかったの?」ということも • 教訓

    ◦ DSとして本当に解決できたら嬉しいタスクをちゃんと投げる ▪ やる気も出ないし参加者も嬉しくない ▪ 他プロダクトのことはやっぱり責任取りきれない ◦ 無理して開催しない ▪ 課題がない場合は無理してやらない
  13. 採用KPIの存在 31 • KPIとしてデータ分析コンペでどこまで見られるかということをfix ◦ 採用コンペでは「能力」しか見ない ◦ 面接などを通してその他の部分は判断する • 能力を適切に判断するためにどうするかを決めた

    ◦ discussion機能が欲しかったのでatmaと組むことを即座に決定 ◦ チーム戦はやらない • 教訓: ◦ コンペで判断できること/できないことの限界をすり合わせる ◦ これで失敗したら撤退する