© DeNA Co.,Ltd. 1 2022年12月13日 株式会社ディー・エヌ・エー データ本部データアナリティクス部データ活用推進グループ Kato - 開発PM勉強会 vol.16発表用資料 - スクラムの自チームへの採り入れ方とその効果

© DeNA Co.,Ltd. 2 自己紹介 加藤 大己 ● 新卒で大手ITベンダーに入社 ● 当時の新組織立ち上げ当初から参画し、主にメーカーやサービス 業のIoTデータを活用した事業創出・課題解決に従事 ● その後、社外AI/データ活用PJのPjMとして複数案件を提案・推進 ● 現在はDeNAにて、社内外問わずAI/データ活用案件の PjM/Bizdevを担当 ● 2022年1月にScrum研修受講。認定スクラムマスター(LSM) DeNA データ本部データアナリティクス部 データ活用推進グループ @katodai_ai https://note.com/katodai Follow me!

© DeNA Co.,Ltd. 1 目次 スクラムの採り入れ方のコツ 採り入れ事例 採り入れ効果 3 3 2

© DeNA Co.,Ltd. スクラムの採り入れ方のコツ 1

© DeNA Co.,Ltd. 5 スクラムの採り入れ方のコツ 1 ● 全ての要素をそのまま導入しようと思わない ○ (最初から全導入できれば良いが現実はなかなか厳しい、、) ● 自分のチームに採り入れやすいなと思うものをピックアップして、少しずつ導入 してみる 一定期間のスプリントで やるタスクを計画 機能レベルの 優先順位表 Scrum Inc. 認定資格 スクラムマスター研修資料をもとに作成 プロダクト バックログ スプリントプランニング (スプリントバックログ作成) バックログの見直し スプリントの評価 スプリントの振り返り 完成の定義を満たした 成果物の完成 リリース デイリースクラム スプリント (チームで設定した一定期間のサイクル) START GOAL エンドユーザー、 顧客、チーム、ス テークホルダーの インプット

© DeNA Co.,Ltd. 採り入れ事例 2

© DeNA Co.,Ltd. 7 前提①_担当業務の特徴説明 2 ● データ活用推進グループでのプロジェクト推進の特徴 ○ AI開発や分析系のプロジェクトでは、一つのプロダクトビジョンを設定しプロダクトゴール の達成を目指すプロジェクトばかりではない ■ 例：一つの事業領域に対して複数のプロジェクトが走り、分析チームが横断で見てい る（例：ヘルスケア、ライブストリーミングなど） ○ 私が推進しているAI開発や分析プロジェクトも上記に該当

© DeNA Co.,Ltd. 8 前提②_担当プロジェクトの関係者整理 2 ● 私が関わるプロジェクトの関係者を以下に整理 事業部Biz、協業先 Biz AI PM、分析PM （場合によってはリードデータ アナリスト、リードデータサイ エンティスト） データアナリスト、 データサイエンティ スト リードデータエンジ ニア、リード機械学 習エンジニア 動き方の 特徴 自部門での 役割名称 データエンジニア、 機械学習エンジニア AI,分析系のタスクを 依頼する （複数箇所からの要求・要望 が存在） 左記の要求、要望を 整理する PMが整理したタスク を実行する PMが整理したタスク を更にエンジニアリ ングタスクに分け整 理、実行する エンジニアリングタ スクを実行する 関係者説明

© DeNA Co.,Ltd. 9 スクラム導入前の課題 2 ● プロジェクトを進める上で以下の課題が発生(しつつあった) 事業部Biz、協業先 Biz AI PM、分析PM （場合によってはリードデータ アナリスト、リードデータサイ エンティスト） データアナリスト、 データサイエンティ スト リードデータエンジ ニア、リード機械学 習エンジニア 動き方の 特徴 自部門での 役割名称 データエンジニア、 機械学習エンジニア AI,分析系のタスクを 依頼する （複数箇所からの要求・要望 が存在） 左記の要求、要望を 整理する PMが整理したタスク を実行する PMが整理したタスク を更にエンジニアリ ングタスクに分け整 理、実行する エンジニアリングタ スクを実行する 関係者説明 優先度 判断が困難 データ整備が 不十分でタスク ができない 背景が理解で きないタスクに 疲弊、タスクが 溜まり完了でき ない 要求、要望の の背景が分か らず、エンジニ アリングタスク に分解できな い 依頼が曖昧

© DeNA Co.,Ltd. 10 スクラム導入の検討 2 ● まず、現状プロジェクトの役割をスクラムに当てはめてみる 事業部Biz、協業先 Biz AI PM、分析PM （場合によってはリードデータ アナリスト、リードデータサイ エンティスト） データアナリスト、 データサイエンティ スト リードデータエンジ ニア、リード機械学 習エンジニア 動き方の 特徴 自部門での 役割名称 Scrumの 考え方での 役割名 エンドユーザー、顧 客、チーム、ステーク ホルダー プロダクトオーナー 開発者① 開発者② / スクラムマ スター 開発者③ データエンジニア、 機械学習エンジニア AI,分析系のタスクを 依頼する （複数箇所からの要求・要望 が存在） 左記の要求、要望を 整理する PMが整理したタスク を実行する PMが整理したタスク を更にエンジニアリ ングタスクに分け整 理、実行する エンジニアリングタ スクを実行する 関係者説明 プロダクトバックログにリレー ションした形でエンジニアリング タスクを整理。スプリントプラン ニングを作成 プロダクトバックログの作成 カンバンの導入

© DeNA Co.,Ltd. 11 導入例 2 ● 下記のようにタスク(PBI)をカンバン管理（※実際の管理ツールから抜粋） エンジニアリングタスクは このタスクを親として リレーションし別ページで管理 データアナリストタスクは こちらのカンバンで管理 ※ツールはNotionを利用しています。プロジェクト管理ツールのテンプレ作っているのでよかったら下記見てみてください。 　（少々古いので近々アップデート予定） https://note.com/katodai/n/n8b27ca0c7070 スプリントプランニング(週次)で管理

© DeNA Co.,Ltd. 採り入れ効果 3

© DeNA Co.,Ltd. 13 採り入れ効果 3 ● コミュニケーション負担の減少 ⇨ 工数削減効果 ○ あれどうなってるけ？がなくなる ○ この要件ってどういうことだっけ？がなくなる ● ドキュメントに残す文化の醸成 ⇨ 引き継ぎリスクの削減 ○ タスク遂行でのコミュニケーション負荷が下がると（空いた工数で）ド キュメント作成機運が高まる（気がしている） ○ 好循環かも

© DeNA Co.,Ltd. 14 まとめ（というより冒頭スライドの再掲） ● スクラムの採り入れ方のコツは全ての要素をそのまま導入しようと思わないこと ○ (最初から全導入できれば良いが現実はなかなか厳しい、、) ● 自分のチームに取り入れやすいなと思うものをピックアップして、少しずつ導入 してみる 一定期間のスプリントで やるタスクを計画 機能レベルの 優先順位表 Scrum Inc. 認定資格 スクラムマスター研修資料をもとに作成 プロダクト バックログ スプリントプランニング (スプリントバックログ作成) バックログの見直し スプリントの評価 スプリントの振り返り 完成の定義を満たした 成果物の完成 リリース デイリースクラム まずは計画部分だけ、、とかでも(私個人としては)良きと思います。 課題に合わせてカスタマイズしてみましょう！ スプリント (チームで設定した一定期間のサイクル) START GOAL エンドユーザー、 顧客、チーム、ス テークホルダーの インプット

© DeNA Co.,Ltd. 15

© DeNA Co.,Ltd. スクラムの好きな考え方 -脈絡なく、個人的に好きな考え方を紹介します- Appendix1

© DeNA Co.,Ltd. 17 スクラムを導入したときのチームの高揚度変化 Ap.1 ● PHASE1.最初はカンバンによってタスクが見える化され、導入のメリットを実感 ● PHASE2.徐々に見える化の副作用が、、「なんであいつ出来ないん？」 ● PHASE3.出来ないではなく、助け合う風土の醸成 ● PHASE4.カスタマイズによる更なる効率化 Scrum Inc. 認定資格 スクラムマスター研修資料をもとに作成 【Phase-1】 カンバンによる見える化 【Phase-2】 見える化の副作用 【Phase-3】 助け合う風土の醸成 【Phase-4】 カスタマイズによる 更なる効率化 高 揚 度 経過時間

© DeNA Co.,Ltd. 18 良いプロダクトバックログアイテム(PBI)の条件 “INVEST” ● プロダクトバックログ(機能や改善が必要なものについて優先順位をつけ、記述した積み残しの リスト)のアイテムを記述する条件は “INVEST”であるべき Scrum Inc. 認定資格 スクラムマスター研修資料をもとに作成 Immediately actionable ただちに着手できる ● 独立して提供できるか？ ● 外部要因で進まなくなったりしないか？ Negotiable 交渉できる ● チームの会話と議論を促進できるか？ ● 目的は明確でありながら実現方法には幅があるか？ Valuable 価値がある ● 顧客ビジネスによって目に見える価値があるか？ Eatimable 見積もれる ● チームが見積もれるくらい明確になっているか？ Sized to fit 適正な大きさ ● 1スプリントで終わるくらいの適切な大きさになっているか？ Testable テストできる ● 明確な受け入れ条件がわかっていて「過不足ない」と判定できるか？ Ap.1

© DeNA Co.,Ltd. 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 19 PBIの見積方法:相対サイズ、ポイントで行う ● 時間は見積もらず、タスクの相対的な大きさ(サイズ)を見積もる ● これからやろうとする仕事とよく知っている仕事または既に行ったことがある仕事とを大きい か小さいかを比較する Scrum Inc. 認定資格 スクラムマスター研修資料をもとに作成 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 〇〇(Who)の ために△△と いう目的 (Why)で✕✕ (What)をする 1 タスクの 大きさ 2 3 5 8 13 21 Ap.1

© DeNA Co.,Ltd. 機械学習プロジェクトとの相性 Appendix2

© DeNA Co.,Ltd. 21 相性○：不確実性とスプリント ● モデル作成の繰り返しプロセスと、スプリントの繰り返しプロセスは相性抜群 ● 繰り返すだけではNG。レトロスペクティブ(振り返り)をして改善していくプロセスである ⇨スクラムはその大事なプロセスをフレームワーク化してくれてる データ 収集 前処理/ 特徴量 設計 モデル 作成 評価 Ap.2

© DeNA Co.,Ltd. 22 相性○：”やり過ぎ”を防げる ● モデル作成は無限に試行錯誤してしまいがち ● 完璧に近いモデルを目指すのではなく、最低限モデルのブラッシュアップが大事 ○ スプリントの限られた期間でスプリントゴールを定め、PBIを選択することにより上記が (半強制的に)実現される https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp より引用 Ap.2

© DeNA Co.,Ltd. 23 相性△_INVEST:”E”のしずらさ ● 経験のないタスクに対して工数を見積づらい機械学習は、INVESTの”E”の条件を満たさない ケースが多い ● “E”を満たそうとすると、”V”が満たせなくなる、、、 特徴を認識し、機械学習スクラムを推進しましょう！ Immediately actionable ただちに着手できる ● 独立して提供できるか？ ● 外部要因で進まなくなったりしないか？ Negotiable 交渉できる ● チームの会話と議論を促進できるか？ ● 目的は明確でありながら実現方法には幅があるか？ Valuable 価値がある ● 顧客ビジネスによって目に見える価値があるか？ Eatimable 見積もれる ● チームが見積もれるくらい明確になっているか？ Sized to fit 適正な大きさ ● 1スプリントで終わるくらいの適切な大きさになっているか？ Testable テストできる ● 明確な受け入れ条件がわかっていて「過不足ない」と判定できるか？ トレードオフ の関係 Ap.2

© DeNA Co.,Ltd. 24