2022年12月13日に開催された開発PM勉強会 vol.16での発表資料です。スクラムを自チームにどう採り入れたらよいか？を実事例を交えて紹介しています。
© DeNA Co.,Ltd. 12022年12月13日株式会社ディー・エヌ・エーデータ本部データアナリティクス部データ活用推進グループKato- 開発PM勉強会 vol.16発表用資料 -スクラムの自チームへの採り入れ方とその効果
View Slide
© DeNA Co.,Ltd. 2自己紹介加藤 大己● 新卒で大手ITベンダーに入社● 当時の新組織立ち上げ当初から参画し、主にメーカーやサービス業のIoTデータを活用した事業創出・課題解決に従事● その後、社外AI/データ活用PJのPjMとして複数案件を提案・推進● 現在はDeNAにて、社内外問わずAI/データ活用案件のPjM/Bizdevを担当● 2022年1月にScrum研修受講。認定スクラムマスター(LSM)DeNA データ本部データアナリティクス部データ活用推進グループ@katodai_aihttps://note.com/katodaiFollow me!
© DeNA Co.,Ltd.1目次スクラムの採り入れ方のコツ採り入れ事例採り入れ効果332
© 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、協業先BizAI PM、分析PM（場合によってはリードデータアナリスト、リードデータサイエンティスト）データアナリスト、データサイエンティストリードデータエンジニア、リード機械学習エンジニア動き方の特徴自部門での役割名称データエンジニア、機械学習エンジニアAI,分析系のタスクを依頼する（複数箇所からの要求・要望が存在）左記の要求、要望を整理するPMが整理したタスクを実行するPMが整理したタスクを更にエンジニアリングタスクに分け整理、実行するエンジニアリングタスクを実行する関係者説明
© DeNA Co.,Ltd. 9スクラム導入前の課題2● プロジェクトを進める上で以下の課題が発生(しつつあった)事業部Biz、協業先BizAI PM、分析PM（場合によってはリードデータアナリスト、リードデータサイエンティスト）データアナリスト、データサイエンティストリードデータエンジニア、リード機械学習エンジニア動き方の特徴自部門での役割名称データエンジニア、機械学習エンジニアAI,分析系のタスクを依頼する（複数箇所からの要求・要望が存在）左記の要求、要望を整理するPMが整理したタスクを実行するPMが整理したタスクを更にエンジニアリングタスクに分け整理、実行するエンジニアリングタスクを実行する関係者説明優先度判断が困難データ整備が不十分でタスクができない背景が理解できないタスクに疲弊、タスクが溜まり完了できない要求、要望のの背景が分からず、エンジニアリングタスクに分解できない依頼が曖昧
© DeNA Co.,Ltd. 10スクラム導入の検討2● まず、現状プロジェクトの役割をスクラムに当てはめてみる事業部Biz、協業先BizAI 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)をする19PBIの見積方法:相対サイズ、ポイントで行う● 時間は見積もらず、タスクの相対的な大きさ(サイズ)を見積もる● これからやろうとする仕事とよく知っている仕事または既に行ったことがある仕事とを大きいか小さいかを比較する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 21Ap.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
dena_tech
kako351
tarao
oracle4engineer
tatematsu_san
shao1555
yayoi_dd
mako5656
takufujii
iseki
harukasakihara
miyakemito
samlambert
michaelherold
jcasabona
sferik
geeforr
rmw
quramy
panda_program
tmm1
colly
caitiem20
chrislema