[DevDojo] 成功するスクラムチームとは

メルカリのプロダクト開発に取り入れられているスクラム開発 (Scrum) とはアジャイル手法のひとつで、少人数のチームに分かれ短期間の開発サイクルをくり返し行うフレームワークです。このコンテンツでは、基本的なスクラムの考え方と、メルカリにおける開発プロセス、そしてその目的を解説しています。

Transcript

1. 1 Successful Scrum Team at Mercari Shohei Kikuchi Mercari Recommendation ML Team / Software Engineer
2. この研修のGoal 「次のメルカリを担うメンバーとして組織の成長/繁栄に貢献可能になる」 • 組織の成長/繁栄とは ◦ (最重要)お客様に価値を届けること ◦ 競争力や生産性を向上させること ◦ メンバー間、チーム間の協力を強化すること etc..
3. この研修のGoal そのために… • メルカリの開発プロセスとその目的を理解する ◦ 配属後、仕事の大部分を開発に占める事になり、同時に多くの不満も抱える可能性がある ◦ プロセスと目的を理解すると、論理的に開発活動を観察 /解釈できる ◦ 観察を基に建設的な FBと行動することで、あなたがチーム /組織を変えるための影響を持てる • 開発に関わる関係者が何に責任を持っているか理解する ◦ あなたの協働するメンバーは敵ではない ◦ 共存共栄のために互いの役割と期待値を理解し、 All for Oneに成功に向かう
4. この研修のNon-Goal 個別の開発プロセスにおけるベストプラクティスについて取り扱う事 • チームは生き物 ◦ 問題をチームで認知する事、チームと共に行動を起こす事、行動を振り返る事に価値がある ◦ 他の組織/チームで上手くいくことが自分のチームで機能するとは限らない 個別のToolに関しての説明をする事 • 過去のスライドを参照してください • Toolは手段であり目的ではない
5. メルカリ内の開発プロセス メルカリはスクラムフレームワークを採用している スクラムはアジャイルソフトウェア開発と呼ばれるものの実践手法の一つ • プロセスやツールよりも個人と対話を • 包括的なドキュメントよりも動くソフトウェアを • 契約交渉よりも顧客との協調を • 計画に従うことよりも変化への対応を 価値とする。すなわち、左記のことがらに価値があることを認めながらも、 私達は右記のことがらにより価値を置く 『アジャイルソフトウェア開発宣言』
6. なぜスクラムに取り組まねばならないのか A. 複雑な問題を解き、お客様に価値を提供し続けなければならないから
7. なぜスクラムに取り組まねばならないのか A. 複雑な問題を解き、お客様に価値を提供し続けなければならないから スクラムの定義 • スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、 チーム、組織が価値を生み出すための軽量級フレームワーク である。 『2020 Scrum Guide』
8. なぜスクラムに取り組まねばならないのか 複雑な問題 = 本質的に不確実かつ予測不可能 問題の解決に寄与する変数は無数にある • e.g.)お客様が欲している(と予測される)機能のリリース ◦ Goal: お客様が価値を享受できる ◦ 寄与しそうな変数: ▪ ユーザニーズの”正確”な理解 ▪ チームへの適切な権限と支援 ▪ 機能リリースのための十分なスキル ▪ 既存のコードベースへの十分な理解 ▪ etc… https://scrumreferencecard.com/scrum-reference-card/
9. なぜスクラムに取り組まねばならないのか 複雑な問題 = 本質的に不確実かつ予測不可能 問題の解決に寄与する変数は無数にある • e.g.)お客様が欲している(と予測される)機能のリリース ◦ Goal: お客様が価値を享受できる ◦ 寄与しそうな変数: ▪ ユーザニーズの”正確”な理解 ▪ チームへの適切な権限と支援 ▪ 機能リリースのための十分なスキル ▪ 既存のコードベースへの十分な理解 ▪ etc… https://scrumreferencecard.com/scrum-reference-card/ 複雑な問題の場合、 すべての変数を事前に把握して論理的に推論するのは難しい
10. 複雑な問題は経験に基づいて立ち向かう • スクラムは、経験主義とリーン思考に基づいている ◦ 経験主義 ▪ 「経験」から知識を開発する ▪ 意思決定は「観察」に基づく ▪ 試行錯誤を通じて、失敗から新たな知識を獲得し、改善策を発見する ▪ 反復学習を通じて、継続的に経験を獲得していく ◦ リーン思考 ▪ ムダを排除し、効率性を最大化し、顧客価値を向上させることを目指す
11. 経験主義と理性主義 • 引き合いに出される考え方として「理性主義」がある ◦ 「考えうる変数/前提」から演繹的に知識を開発する ◦ ウォーターフォールは「理性に基づき設計主義的にソフトウェアを開発することが可能である」と いう前提に基づいたプロセス とも考えられる • 主な差分 ◦ 知識源: 経験や観察(経験主義) vs 理性や論理的思考(理性主義) ◦ 推論: 帰納(経験主義) vs 演繹(理性主義) ◦ 知識の確実性: 不確実or変更の余地あり(経験主義) vs 普遍的かつ必然的(理性主義) スクラムを実施することが目的ではない 状況や解くべき課題に応じて柔軟に手法を選択する必要がある
12. なぜスクラムに取り組まねばならないのか A. 複雑な問題を解き、お客様に価値を提供し続けなければならないから スクラムの定義 • スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、 チーム、組織が価値を生み出すための軽量級フレームワーク である。 『2020 Scrum Guide』
13. 適応(Adaptation)とは? • スクラムにおいては、「現状」と「目標」を踏まえてその差分を 埋め続けている状態を示す • 差分を埋め続ける状態が経験の獲得に直結する 現状 目標 現状と目標の差分を 埋め続けている状態
14. 適応するには何が出来れば良い? • 下記を満たすとき、検査(Inspection)をすることで適応できる ◦ 自分たちの目標が明確 ◦ 目標に対して、自分たちの現状が明確 現状 目標 現状と目標の差分を 把握し続けている状態 GAP
15. 検査をするには何が出来れば良い? • 透明性(Transparency)が担保されているとき検査可能 現在の正しい情報が一箇所に 集められ、次に起こすべき行動が誘 発され続けている状態 ❌ ✅
16. スクラムの3本柱 ✅ 現状 目標 GAP 現状 目標 Transparency Inspection Adaptation 3本柱を実践し、この経験から次の意思決定を行う
17. Scrum framework • Scrumはその概要を4つのルールでまとめられる ◦ Time ◦ Event ◦ Artifact ◦ Role Daily Scrum Meeting Review Retrospective Incremental Sprint Backlog Sprint Planning Meeting Team selects How much to commit Team Product Owner Scrum Master Input from End-Users and other stakeholders 1 2 3 4 Product Backlog
18. Time Time = ある定められた期間のこと • スクラムではSprintと呼ばれる期間でチームは開発サイクルを回している ◦ 期間は通常1w-1mで常に固定長である ◦ 後述する全てのEventはSprint内で行われる • 期間に応じてEventの時間も可変になる(Daily scrumを除く) • Sprintの期間が長くなればなるほど予測の失敗確率が増えリスクが高まる
19. Event Event = 検査と適応のための活動のこと • Sprint Planning ◦ Sprint期間中に何が出来るのか、どんな価値を届けるのかチームで議論する ◦ Sprint Goalを決定し、目標を明らかにする ◦ どのような作業をもって価値を生むのか計画する (Sprint Backlog) • Daily Scrum ◦ Sprint Goalに向けた現状の差分を明らかにする ◦ Goalへの作業経過/阻害要因を検査する ◦ 検査を基に適応する ▪ POと相談 ▪ スコープの調整 ▪ 阻害要因排除のためのさらなる議論 ▪ etc…
20. Event • Sprint Review ◦ Sprint Goalを満たす成果物(Increment)を明らかにする ◦ 成果物を踏まえて、Product Goal(OKR/Visionなど)に対する現状を検査する ◦ 検査を基に適応する ▪ スケジュールの見直し ▪ 優先順位の再考など • Sprint Retrospective ◦ チームの経た経験を明らかにする ◦ 個人/チーム/プロセスなど、開発に関するあらゆる活動に関して様々な Goalとの差を 検査する ◦ Goalとの差を埋めるための最も役立つ行動を次のサイクルで適応する
21. Artifact Artifact = スクラムにおける作成物(作業や価値)のこと • Product Backlog ◦ Product Goalを達成するために必要な Itemを優先度順に並べたリスト ◦ 各ItemはSprint Planningで選択可能な状態(価値提供のための透明性が担保されている ) • Sprint Backlog ◦ Sprint Goal, Sprint Goal達成のために選択された Product Backlog Item, 実行計画で 構成される ◦ 開発者のための計画であり、開発者が Goal達成に必要な作業を可視化するためのもの • Increment ◦ Goal達成のための成果物の提供可能単位の総称 ◦ 下記がセットで提供可能でなければならない ▪ サービス提供者が提供時に 担保しなければならないモノ (品質や安全) ▪ 提供したい価値が実現されていると判断可能な基準
22. Example • Product Goal: 競合優位なケーキ屋を開業する • Sprint Goal: ショートケーキが競合優位か確認する • Sprint Backlog ◦ ショートケーキを提供するための要素を分解し計画 • Increment ◦ 下記をセットで提供する ▪ 競争優位な • いちごの品質/安全 • 生クリームの品質/安全 • スポンジ生地の品質 /安全 生クリームだけはショートケーキのインクリメントにならない ケーキの美味しさが判断可能なコンポーネント要素を満たす必要 がある
23. Role Role = スクラムにおけるチーム内の役割であり、説明責任の所在 • Product Owner (PO) ◦ Scrum teamのROIを最大化する • Developers ◦ Scrum teamのOutcomeを最大化する ▪ (厳密にはProductivityであるが、私達はOutcomeを最大化すべき) • Scrum master (SM) ◦ Scrum teamが実現したいことの実現確率 を最大化する
24. Product Owner • ROI(Return on Investment)の最大化 ◦ 人やモノや時間など、仮説を実施するコストに対して得られるリターンを最大化する ◦ 営利企業であるならば、リターンは結果的に金銭的な利益につながる必要がある ◦ What/Whyを常に考える • ROIを最大化するために考慮すべきこと ◦ 活動が計測可能であるか ◦ 戦略的であるか ◦ 組織的な制約を把握しているか ◦ ステークホルダーと交渉可能であるか ◦ Developersの能力を考慮できているか
25. Developers • ProductivityとOutcome ◦ 狭義のProductivity = Produce(生産する) + ivity(性質/状態を表す接尾辞) ▪ 生産活動の度合いそのもの ▪ どれだけ効率的に Outputを生み出せるかの指標 ▪ Outputが高くても、お客様が価値を享受出来ていなければ意味がない … ◦ 広義のProductivity = Product(提供する事で価値を認めてもらえると考える仮説の総称) + ivity ▪ 価値を認めてもらえるモノを生み出す活動の度合い ▪ どれだけお客様が価値を認めて利用してもらえているかの指標 ▪ お客様への価値提供が出来ており、ゴールの実現に直接寄与している = 成果(Outcome)
26. Developers • ProductivityとOutcome 🫧 Resources Output Outcome 狭義の生産性 広義の生産性👍 OutputをOutcomeに繋げる ことに集中する必要がある • Output: 大, Outcome: 小 -> 無駄を大量生産 • Output: 小, Outcome: 大 -> 成果にコミットしている 何ら悪い状態ではない
27. Developers • Outcomeの最大化 ◦ お客様への価値提供が出来ており、ゴールの実現に直接寄与している = 成果(Outcome) ◦ 効率的にたくさん機能を作る事は目的 ではない ◦ Outcomeを高めるための手段として Outputを改善する活動をすることもあるが、 Outputを 高めたからと行ってOutcomeに100%貢献するわけではない • Developersは「POが考えたモノを作る人達」ではない ◦ 指示されたモノを開発し続けていれば良いわけではない ◦ Outcomeの最大化に繋がると信じるものがあるのであれば POと交渉する必要がある • Outcomeの最大化のために考慮すべきこと ◦ 開発がどのようにOutcomeに結びつくのか ◦ どのように開発のOutcomeを計測するのか ◦ どの時間軸でのOutcomeを狙うのか
28. Scrum master • Teamが実現したいことの実現確率の最大化 ◦ チームにスクラムフレームワークを押し付けるのが仕事 ではない ◦ チームの活動を観察し、活動の質を変える事で チームの日々の習慣を変える その成果として実現確率の最大化を狙う • 活動そのものに対して分析/評価する ◦ スクラムマスターの分析対象は活動 ◦ 活動の結果を予測して、どんな行動変容を促せば習慣が変わるのか考えて提案する • 実現確率の最大化のために考慮すべきこと ◦ チームの「権利と責任」が担保されているか (担保するための交渉をする ) ◦ 各メンバーがそれぞれの責任を果たせているか (責任に関与するための交渉をする ) ◦ 組織とチームが共存共栄出来ているか (共存共栄するための交渉をする )
29. ここまでのまとめ • メルカリでは複雑な問題を解き、お客様に価値を届けるためにスクラムのフレー ムワークを採用している • 複雑な問題に対して適応するには透明性・検査・適応が出来る事が大前提 • これらを満たす事が可能なイベントがフレームとして定義されている • チームには役割と責任があり、各メンバーは責任を果たす必要がある ◦ Product Owner ▪ Scrum teamのROIを最大化する ◦ Developers ▪ Scrum teamのOutcomeを最大化する ◦ Scrum master ▪ Scrum teamが実現したいことの実現確率 を最大化する
30. Scrum Values スクラムの成功は5つの価値を発揮できるかに依存する • Commitment ◦ ゴールの達成のために互いにサポートすることを確約する • Focus ◦ ゴールに向けて前進するために、必要なことに集中する • Openness ◦ ゴール達成のために作業や課題を公開する • Respect ◦ 互いに能力のある独立した個人として尊敬し、同じように自身も尊敬される • Courage ◦ 正しいことをする勇気や困難に立ち向かう勇気を持つ
31. 役割と責任 • 特にPOとDevelopersは対立するように設計されている ◦ お互いの立場が明確化していないと、現状を把握する事が困難になる ◦ 衝突があることで問題の輪郭がハッキリする ◦ 正しい衝突が透明性を生む • 対立を乗り越えるためにScrum Valuesが大事になる ◦ 互いを受け入れてチームが健全な FBを実行できる事が成功につながる ◦ 健全なFBが出来ない関係性のチームは個人の集合体に成り下がってしまう • スクラムは失敗を早期発見し学習するためのフレームワーク ◦ プロジェクトの現状やチームの課題が嫌でも明らかになる ◦ 複雑な問題に向き合う以上、失敗するのは当たり前 ◦ 「経験」から知識を開発する
32. この研修のGoal 「次のメルカリを担うメンバーとして組織の成長/繁栄に貢献可能になる」 • 組織の成長/繁栄とは ◦ (最重要)お客様に価値を届けること ◦ 競争力や生産性を向上させること ◦ メンバー間、チーム間の協力を強化すること etc.. そのために… • メルカリの開発プロセスとその目的を理解する ◦ 配属後、仕事の大部分を開発に占める事になり、同時に多くの不満も抱える可能性がある ◦ プロセスと目的を理解すると、論理的に開発活動を観察 /解釈できる ◦ 観察を基に建設的な FBと行動することで、あなたがチーム /組織を変えるための影響を持てる • 開発に関わる関係者が何に責任を持っているか理解する ◦ あなたの協働するメンバーは敵ではない ◦ 共存共栄のために互いの役割と期待値を理解し、 All for Oneに成功に向かう GLHF 👍
33. 33 Thank you!