CyberAgent AI Lab研修 / Social Implementation Anti-Patterns in AI Lab

株式会社CyberAgentの研究組織AI Labの研修コンテンツ、「社会実装におけるアンチパターン」の資料です

Transcript

1. 社会実装における アンチパターン Yuki Iwazaki@chck | AI Lab AI Lab Skill Up Onboarding 2025
2. 社会実装とは 研究成果を" 社会" に" 実装" すること 実装実験（PoC ）で終わらせず、社会システムとして根付かせること（内閣府） 開発技術が生産現場で広く使われ、社会に根付いていること（農研機構） 新たなサービスを通じて知を社会に還元すること（産業技術院） 製品の販売により、企業の売上に貢献すること（経産省） ここでは「研究成果をシステムに組み込み、プロダクトに貢献すること」とする
3. Yuki Iwazaki @ chck 2014 … Backend Engineer in Ad Platform 2017 … ML / DS in Ad Platform 2018 … Research Engineer in AI Lab @chck chck.dev Research Engineer | Applied ML
4. 社会実装経験について 2017 … OpeTech ：Twitter 広告の検索キーワード推薦 2018 … 極AI ：プロダクト立ち上げ 2019 … 極LP ：Landing Page の効果推定 2020 … MG-DX ：ML 推論基盤立ち上げ 2022 … 極AI ：グラフィックデザインのLayout 生成 2023 … 小売DX ：共通データセット基盤立ち上げ 2025 … Abema ：推薦システムリアーキテクチャ
5. 社会実装は難しい プロダクト経験を含むManagement ・Engineering スキルの不足（AI Lab Matching 事後アンケートより抜粋）
6. 社会実装≒ML Project のはじめ方 1. 問題を定式化する 2. 機械学習をしないで良い方法を考える 3. システム設計を考える 4. アルゴリズムを選定する 5. 特徴量、教師データとログの設計をする 6. 前処理をする 7. 学習・パラメータチューニング 8. システムに組み込む 1. （有賀 康顕ほか『仕事ではじめる機械学習』オーム社, 2021 ） [1] AI Lab への相談はこの範囲が基本となるが 常にそうとも限らない
7. ML Project の理想的な役割分担 ML Project が成功するチーム構成 プロダクトに関するドメイン知識を持った人 統計や機械学習に明るい人 データ分析基盤を作れるEngineering 能力のある人 失敗しても構わないとリスクを取ってくれる責任者 1. （有賀 康顕ほか『仕事ではじめる機械学習』オーム社, 2021 ） 2. （データエンジニアの私が機械学習・データサイエンスでオススメしたいスキルマップと本まとめ Lean Baseball, 2020 ） [1] 機械学習エンジニアのスキルマップ を参考に作成したML PROJECT SKILLMAP [2]
8. まえがき 発表者の10 年以上の経験に基づいて社会実装にはどんなアンチパターンがあるのか、 つよつよ人材の採用以外にどのような解決方法があるのかを言語化する 「AP 」はアンチパターン、 「R 」は解決策の略 本稿で出てくる登場人物 ①プロダクトのビジネスメンバー・②ML/DS 職 ③AI Lab のResearch Engineer (RE) ・④Research Scientist (RS) 1. 本稿では簡略化のためまとめてDS と称す [1]
9. 先に結論 事業部と関わる以前の話 誰に相談したらいいかわからない・相談が来ない 社内の人脈を広げる 横のつながり（他プロダクトの同期・横軸プロジェクト繋がり） イベント参加（AI Fes, Developer Conference, Monthly LT, etc. ） 定期的に相談できる流れを作る 1 回で終わるSpot 相談と、効果改善など定期的な相談がある 一度作った繋がりから続けて相談できる環境を作る 結局は人と人なので、新しい相談先を探索する 事業部と関わって以降の話 相談までは進んだが、実際にシステム実装までが難しい 基本的にはアルゴリズムに集中してQA を回しながらサンプルコードを渡せばOK それ以外の細かい実装はDS とRE の仕事 困ったらチームのRE やApplied ML チームに相談を これ以外の細かいテクニックがたくさんある（今日はこれがメイン）
10. 社会実装における アンチパターン
11. AP1: 連携先の固定化 連携先を精査できているかという話 事業部連携において 特定プロダクトとだけ深めるか 引き続き深い議論ができればもっと大きな成果に繋がる可能性がある 新しい相談先を広げるか 新しい研究の応用先の潜在層にリーチできる可能性がある 会社が期待している部署 × Lab の関係値が作れているというバランス感覚
12. R1: 時には相談を断る 相談されると社会実装事例にもなるし頼られているので、つい引き受けてしまう -> その気持ちをグッと抑え、定期的に連携先の棚卸しをする 相談の上手な断り方： 「別の事業部からの相談も来ているので本件終わりで一旦締めさせてください。 手を動かす系でなければいつでも相談ください」 コスパの良い捌き方： 過去の連携事例から似たようなコードを使い回して対応する（経験が増えるほど強い） 連携先の固定化の解決策
13. R1: 人脈を広げる 人脈を広げる上で一番効く方法は、 「人脈作り」自体にばかり専念するのではなく、 とにかく他のチームのメンバーと一緒に長い時間を過ごすこと 横軸施策や人伝で仲良くなる Slack のtimes に入る 連携MTG でよくみかける人（キーマン）をチームランチに誘う 1. （Gergely Orosz 『ソフトウェアエンジニアガイドブック ― 世界基準エンジニアの成功戦略ロードマップ』O’Reilly Japan, 2025 ） 連携先の固定化の解決策 [1]
14. AP2: キーマンを押さえない リソースをかけて事業部に返したのに期待する実績に繋がらないパターン そのアウトプットは責任者レイヤーで本当に求められているのか？現場のN=1 ニーズではないか？ 相談時点では両者やる気満々だが、 「進めてもらって悪いですがやっぱ要らなくなりました」 「上長確認が通りませんでした」と現場から返されることもある
15. R2: 動く前にキーマンに当てる 事業課題の精度はシニアほど高いので、その事業の責任者レイヤーを巻き込んで話を進める 必ずしも定例に責任者を入れる必要はない 始める前に「こういう話を現場から頂いていてこんなやり方でいつくらいまでに進める予定ですが、問題ありませんか？」 と当てるか、キックオフだけ参加してもらう 責任者と一度やりとりしたことがあってお互い顔見知りである、という実績自体も非常に重要 「新しい相談に乗ってもらっていいですか？以前のあのスピード感でいいので」という関係値を作る キーマンを押さえないの解決策
16. R2: 相談に即レスしないで一度持ち帰る リーダーや全体チャンネルで既に取り組んでいるか訊いてしまう 「この相談に似たタスクを既にやってるチームあったりしますか？」 大きい組織ほど縦割りなので隣のチームがどこと連携してどんなタスクをしているか 詳細に把握できていないことが多い Product A の推薦タスクをLab のTeam B とTeam C でそれぞれ取り掛かっていた、なんてこともある 過去に躓いた際の対処方法や既に進んでいるプロジェクトが巻き取るなどの対応ができる 再発明上等とはいえ連携できるところはしたほうが組織として効率的 キーマンを押さえないの解決策
17. AP3-1: デッドラインを引かない いつまで（Deadline ）に誰がやるか（Resource ）を決めないと 進捗責任のない定例MTG がだらだらと続いてしまう（Endless PoC ） 相談する側とされる側で期待するゴールやスピード感が違うことがある Product ： 「なるはやでKPI （ex: 売上・ユーザ数）を上げたい」 AI Lab ： 「願わくは論文化したい」 ここを早めに握っておかないとズレた方向に進んでしまう 「うまくいったら論文化したいですね」 -> 「 （あとから発覚）IP モノなので実験データ公開できないです」 プロジェクトの責任境界
18. R3-1: デッドラインと成果の方向性を決めておく 相談する・される側で想像しているゴールやスピード感をすり合わせる ゴール： キックオフの段階で「いつまでに何を誰がやりきるか」と 撤退ライン「◯ヶ月で□% のAccuracy を達成できなければやめる」を雑でいいので決めておく スピード感： プロダクト所属と異なり、100% のリソースをそのプロダクトに使えないことを断っておく 朝会ほど干渉できないことを伝え、定例の頻度も自身の使えるリソースと相談しつつ隔週くらいが望ましい 「別件を既に抱えていて本件の手を動かせるのは週1 くらいになりそうなので、 定例を組むなら隔週くらいがありがたいです」 デッドラインを引かないの解決策
19. AP3-2: リソースを折半しない Applied ML チーム鉄の掟「ローンチまでは手伝うが運用・メンテ責任は持たない」 リソースは有限なのでここを押さえないとプロジェクトが手離れせず、メンテまで任されることになる -> プロダクト側の理解負債になってしまう 研究リソース+ 新規に来る相談を受けるリソース < 自分が過去に作ったシステムメンテリソース 登場人物によって4 パターンに分けられる プロジェクトの責任境界
20. AP3-2: リソースを折半しない タイミングや実装難度的に調査や開発に手を動かせるメンバーがいない 課題感の共有で終わる事が多い 「最近どうですか？」と落ち着いたときに聞いてみると良いかも a) 相談する側・される側共にリソースがない（難）
21. AP3-2: リソースを折半しない プロジェクトは進むが、手離れできないのでそのままローンチするとメンテ責任が付いてくる Lab 側の社会実装スキルが上がることで受け入れ難度は下がる（メンテほぼいらないシステム作れるようになったり） b) 相談する側にリソースがない・される側に開発リソースがある（難）
22. AP3-2: リソースを折半しない コンサルからローンチまでのマネジメント力と相談元のドメイン練度が試されるが、a,b よりはうまくいく c) 相談する側にリソースがある・される側にリソースがない（並）
23. AP3-2: リソースを折半しない お互いに相手がメンテまでやってくれるだろうと想像して走り出すことがある -> どちらがどれくらいのリソースを出すかを決めてやりきる（プロダクトにメンテ全任せする着地を目指す） プロダクトからはドメイン知識を、Lab からは専門知識を補完し合う d) 相談する側・される側共にリソースがある（易）
24. R3-2: お互いのリソースを事前に把握しておく リソースにどれくらい余裕があるか・手を誰がどれくらい動かすのかをはっきりさせておく -> 最初のMTG の時点で先程の4 パターンのどれに該当するかでアクションを決められると良い ここの交渉を間違えると期待値のズレが生じる -> 長期的には属人化をなくして引き継ぐ未来を考えながら進める 自身やチームの開発スキルが上がる -> 開発リソースにも余裕ができる -> 高難度の相談に取り組めるようになる そういう意味で開発力のスキルアップに投資する意味があるが、座学で学ぶのは限界がある ストレッチでこちらが開発をある程度持つようなプロジェクトで経験を積むのが一番早い リソースを折半しないの解決策
25. AP4: 自分がボールを持ち続ける 自分がそのタスクをやらないと他のメンバーに待ちが発生しないかを考える ex) Slack の返信、成果物のレビュー、MTG の調整、etc… 責任感を持って仕事をやりきれるかという信頼残高にもつながる
26. R4: とにかくボールを回す 自分一人の仕事を止めてでもプロジェクト全体の流れを意識してとにかく回す 仕事はチームプレー、自分がボトルネックになる時間を最小限にする 優先度：自分が止めたら他のメンバーの手が止まる仕事 > 自分一人で進められる仕事 Slack の返信は最長でも4 時間以内、成果物のレビューは24 時間以内に返すことを心がける 相談相手ボールのまま流れてしまうことがある。こちらが手を動かせそうな前日までにはリマインドする 「そろそろ手が動かせそうなんですが、あれって結局どうなりましたか？」 議事録ないしネクストアクションをメンション(@) 付きで必ず残す 誰が担当なんだっけ？の確認になる 自分がボールを持ち続けるの解決策
27. まとめ プロダクトからの相談を受けるためには： 「自分は◦◦が専門なので□□の相談とかいつでもしてほしいです」と普段から社内営業しておく うまくいく社会実装とは： 数々の相談というパイの中から自分と相手のリソース等から難易度を見極め、 （事業部DS がやる仕事を）どこまで巻き取って何を断るかを判断するゲーム 時には相談を断り人脈を広げ(R1) 、 動く前に相談を一度持ち帰りキーマンに当てつつ(R2) 、 リソースを折半した上で(R3-2) いつまでに誰が何をやるかを決め(R3-1) 、 とにかくボールを回す(R4)
28. Appendix: 社会実装相談 Yes/No フローチャート No Yes No No Yes No Yes Yes No Yes 新規開拓優先 お得意様優先 Yes Yes No No 相談開始 Q0. 決裁者は 握れているか？ (AP2) 一度持ち帰り 上長確認を促す (R2) Q1. 相談元に 開発リソースがある？ (AP3-2) Q2. 運用するリソースと 覚悟( メンテ責任) がある？ (AP3-2-b の壁) パターンA ( 難) 課題共有のみでステイ ( 今は時期尚早) Q3. Lab 側に 開発リソースがある？ Q4. 戦略的判断 (AP1) Q3. Lab 側に 開発リソースがある？ パターンC ( 並) コンサル・技術支援 サンプルコード提供まで 新規性/ 潜在層への リーチはあるか？ より深い成果に 繋がるか？ パターンB ( 難) Lab が開発を主導 ※要メンテ引継ぎ計画 (R3-2) パターンD ( 易) 理想的な共同開発 役割分担を明確化 今回はお断りする (R1) Generated by Gemini
29. References 仕事ではじめる機械学習★ 社会実装の次のステップに進みたい方は必読 論文読み会 / Socio-Technical Anti-Patterns in Building ML-Enabled Software: Insights from Leaders on the Forefront 機械学習プロジェクトの社会実装におけるアンチパターンの紹介 データエンジニアの私が機械学習・データサイエンスでオススメしたいスキルマップと本まとめ - 2020 年版 ML Project で必要なスキルとそれを補う書籍のまとめ ソフトウェアエンジニアガイドブック ― 世界基準エンジニアの成功戦略ロードマップ★ エンジニア脳にするための考え方からステークホルダーの巻き込み方まで 実践MLOps 作って理解する機械学習システムの構築と運用 ML Engineer が行っているタスクを手を動かして体系的に学べる プロトタイプで終わらせない死の谷を超える機械学習プロジェクトの進め方 PoC やコンサルの先へ進めない方へ
30. Thank you for listening! Questions?