ビジネス(の人)的に嬉しい コンペ開催のやり方 CyberAgent Dynalyst 金子 雄祐 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
 

自己紹介 3 ● Kaggle Master ○ 金: 1 銀: 4 銅: 1 ○ 基本チームメイン ○ テーブル&Simuation 

今日の話 4 ビジネス的に意義のあるデータ分析コンペを主催するには？ 

主催側的な価値 5 3. 宣伝 ブランディング etc 2. 採用 強い人を採る 1. 課題解決 課題解決の外部委託 

6 俺，開催側に回らないし この話関係ある? 

参加者が開催側のことを知るメリット 7 1. コンペ設計 = 仕事で価値を出す分析課題を作ること ○ これを知ることで分析でビジネス価値を出すこととつながるはず 2. 企業としてデータ分析コンペを開催する意義を認識できる ○ 開催するには稼働時間などなどのコストがかかる ■ 「やる意味ある?」という問いに答えるには? ○ なんのために企業として主催し，なにが達成されれば成功なのか? ○ ここで価値を出せればDSとしての価値が追加され得る 3. いざ開催するとなった時にノウハウが知れる ○ (後述するが)中々開催側の話が知れる機会はない 4. ビジネス職と企画運営をする際のDSとしての動き方の参考になる 

atma社との開催経験 8 ● atma社と2回コンペを開催 ○ 2020/01 CA atma cup(中途向け) ○ 2020/09 CA Tech Challenge(新卒向け) 

設計側の話 9 2020/07 atma山口さんの発表: コンペ設計側の話 2020/11 今日: コンペ主催側の話 

なぜ主催側の話が出てこないのか? 10 1. そもそもプレイヤーになるより主催者になる機会の方が圧倒的に少ない ○ KaggleやSignateはハードルが高い 2. タスク内容は基本的に外部に公開できないので話しづらい ○ どうしてもタスクに触れない話になると内容がふんわりしがち 3. このような発表だとプレイヤーとしての技術の話のほうが求められる ○ 基本的に主催になることはないので 

今日の話 11 1. コンペ開催とKPI 2. 成功のための役割分担 3. 過去2回の事例の話 4. おわりに & 宣伝 

1. KPIのはなし 12 

そもそもデータコンペとは? 13 出題者が出すデータ分析タスクを 参加者が解いて精度を競う 上位者は賞金やメダルを獲得 プラットフォーム 海外: Kaggle / 国内: Signate 1. 課題設計 2. 課題とデータ提供 3. モデルを提出 4. ランク付け 

コンペにおける4種のプレイヤー 14 現場のDS 目標: 課題解決 ビジネス職 目標: 「いい人」を採る 競技参加者 目標: fun & win atma 目標: ブランディング 全員が幸せになるために達成すべき要件は?
 

「良い」コンペ 15 ● atma山口さんの発表スライドより ○ 非DS，特にビジネス職にとっても良いコンペは嬉しいものなのか? 

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

2. 役割分担の話 17 

「良い」コンペを作るには 18 1. コンペに適した課題設計 a. 実際に課題解決に繋がる 2. 参加者が楽しく，結果に納得できる a. 普段触らないデータや課題設計 b. 運ゲーにならない ● 上記の要件を適切に解決するには色々な障害が存在している ● これを解決するために現場のDS/ビジネス職/atma でどのように動けるといいのか? ● まずはこの実現のための障害の例を挙げる 

「良い」コンペを作るための障害 19 ● 提供できないカラムや匿名化などの存在 ○ コンペの面白さとビジネスリスクのトレードオフ ○ PMとの交渉コストや，DS&atmaによる落とし所の調整が必要になる ● 課題設定の困難さ ○ 1日/1週間/2週間という期間で適切なデータサイズかつ解決可能な課題はそんなにない ○ 上の期間で解決できるならコンペの開催コストを考えると非効率では? ● 蓋を開けてみれば運ゲーになる可能性がある ○ 事前検証やleak検証などのコストはかなり大きい ● 人を集めたりシステムを準備するのが大変 ○ 基本的には人を集めたほうが盛り上がるがそこの広報などもちゃんとやらないといけない 現場のDS/ビジネス職/atmaがこれらの困難さにどうcommitできるか? 
 

現場のDSの強みと弱み 20 強み: ● 実際のプロダクトのデータや課題への理解 ● (ある人は)Kaggleなどのコンペ形式への理解 弱み: ● ビジネス的な事務手続き ○ コンペ開催に伴う費用など ● 開催で生じる運営企画広報の巻き込み力 

ビジネス職の強みと弱み 21 強み ● 運営，広報などの事務手続き能力 ● 採用周りのノウハウ ○ 採用できればビジネス的に意味が生まれる 弱み ● コンペの設計はできない ● コンペでは参加者の人柄までわからない ○ コミュニティに属していない 

atma社の強みと弱み 22 強み: ● コンペ設計実績(設計能力/ブランド価値) ● 優秀なシステムの提供 ● Kagglerのコミュニティへの知見 弱み: ● 課題の価値までは現場のDSじゃないとわからない ● 持ってこられるタスクはコントロールできない ○ 無理ゲーを持ってこられる可能性もある ○ ブランド毀損のリスク 

それぞれの価値提供 23 適切な課題の持ち込み 落とし所の交渉 検証/システムコスト削減 コンペ開催の設計 働きたい人の話の共有 運営，広報コスト削減 ブランド価値の提供 コミュニティ情報共有 広報，事務手続き 採用によるビジネス価値創造 

それぞれの価値提供のために 24 基本的にはそれぞれのKPIを達成しやすくなるようにタスクを振る ● DS ○ コンペ設計周り ○ atma社とのコンペ設計交渉に注力できるように ● ビジネス職 ○ 採用事務広報周り ○ いい人が多く集まり，いい人を採りやすくなるように ● atma ○ コンペ開催支援 ○ 現場のDSと密にコミュニケーション取れるように 

3. 実際の事例 25 

26 ● 事例その1 ● 第1回 CA X atmaCupの話 

ビジネスリスクを誰が引き受けるのか? 27 ● 第1回 CA X atmaCupでは絶対に失敗できないという制約があった ○ leakや設計のミスは絶対起こせない ○ 当時は外出しできる最適なタスクを金子が持っていなかった ● 社内コンペの流用という形で別プロダクトからデータを持ってくる事に決定 ● しかし炎上リスクの問題でデータ匿名化の部分が揉めに揉めた ○ 別プロダクトの人はコンペ特にやりたくないので炎上リスク0にしたい ○ 意味不明なデータを提供してコンペ開催しても燃えるのでやりたくない ● プロダクトが潰れた場合は誰が責任を取るのか? 

ビジネスリスクを誰が引き受けるのか? 28 ● 交渉の結果，燃えにくいかつコンペとして開催できる形には落とし込めた ○ 燃えた場合は結局誰が責任を取り切れたのかは不明 ○ 結局参加者FBでは「これ本当に解きたかったの?」ということも ● 教訓 ○ DSとして本当に解決できたら嬉しいタスクをちゃんと投げる ■ やる気も出ないし参加者も嬉しくない ■ 他プロダクトのことはやっぱり責任取りきれない ○ 無理して開催しない ■ 課題がない場合は無理してやらない 

29 ● 事例その2 ● CA Tech Challengeの話 

採用KPIの存在 30 ● 新卒採用という文脈だったので，全社の採用人事が関わる話だった ● 一点「コンペを通じて人格評価をどうすればいい?」という疑問が出た ○ コンペから「素直でいいやつ」をどう判断する? 

採用KPIの存在 31 ● KPIとしてデータ分析コンペでどこまで見られるかということをfix ○ 採用コンペでは「能力」しか見ない ○ 面接などを通してその他の部分は判断する ● 能力を適切に判断するためにどうするかを決めた ○ discussion機能が欲しかったのでatmaと組むことを即座に決定 ○ チーム戦はやらない ● 教訓: ○ コンペで判断できること/できないことの限界をすり合わせる ○ これで失敗したら撤退する 

4. さいごに 32 

やります 33