スクラムについて

1. スクラムについて

2. スクラムの概要

3. スクラムとは
アジャイルな開発
スクラム
Scaled Agile
Framework
Spotify モデル
アジャイルな開発をするためのフレームワークの一つ

4. 3 つの役割といくつかのアクティビティで構成される
役割
● プロダクトオーナー
● スクラムマスター
● 開発チーム
アクティビティ
● デイリースタンドアップ
● グルーミング
● スプリントプランニング
● スプリントレビュー
● スプリントレトロスペクティブ

5. 根底に流れるアジャイルの考え方
● 事前に正しく行うことは不可能だと認める
● できる限り早くフィードバックを得て、改善を繰り返す
○ プロセス、プロダクト どちらも
● これらを活用し、できる限り無駄なく、ユーザーに価値あるものを届ける

6. スクラムにおける役割

7. プロダクトオーナー
● 正しいプロダクトを作ることに集中する人
● 経済的合理性を踏まえた上で、開発方針や内容をコントロールする
● プロダクトバックログのグルーミングを行う
○ グルーミングとはプロダクトバックログアイテムの作成、洗練、見積もり、優
先順位づけのこと
● 何が完了していればタスクを完了とするか定義する
● ステークホルダーと協力する
○ US、CS、マーケ、営業、社長等

8. スクラムマスター
● スクラムがうまく回るように色々考える人
● 教えるのではなく、チームに考えさせる
● チームを外部の妨害から守る
● チームの生産性を妨げる障害を排除する（チームメンバーが排除できない場合）
● 補足：プロダクトオーナーもチームの一員としてスクラムマスターのコーチングを
受ける

9. 開発チーム
● プロダクトを正しく作ることに集中する人々
● 開発チーム内には開発を完了させるための全てのスキルが揃っている必要が
ある
● 各メンバーは T 型スキルを持つ
● メンバーは銃士の姿勢で助けあう
● 透明なコミュニケーション
● 持続可能なペースで仕事をする

10. プロダクトバックログ

11. プロダクトバックログとは
● プロダクトに求められる機能を優先順位をつけてリスト化したもの
● これから何を作るのか、そしてどの順番で作るのかについての認識が一箇所にまと
まり、メンバーがそれを共有できるようになる

12. プロダクトバックログの詳細
● 大きめの PBI の作業をする時期が近づいてきたら、そのストーリーをスプリント
単位での作業に適した小さめのストーリーに切り分ける（グルーミング）
○ 大体 2 スプリント分余分にグルーミングされているのが望ましい
● プロダクトバックログは常に変化していく
● 直近に対応する PBI 以外の見積もりはざっくりとしたもので良い
● 直近の数回のスプリントで対応するアイテムについては優先順位付けが有用だ
が、プロダクトバックログ内のすべてのアイテムに優先順位をつけるのはやりす
ぎだ

13. グルーミングについて
● グルーミングとは以下の 3 つのアクティビティの総称
○ PBI の作成と改良（詳細の追加）
○ PBI の見積もり
○ PBI の優先順位付け
● プロダクトオーナーが主導となり、内外のステークホルダーやスクラムマスター、
そして開発チーム全員が参加する
● 一般論として、開発チームは各スプリントの最大 1 割程度までをグルーミング用
に確保すべき
● グルーミングのタイミングは決まっていない

14. スクラムのプランニングの原則

15. スクラムのプランニングの原則
● 事前にきちんと計画を作れると思うな
● 事前のプランニングのやりすぎに注意
● 計画を守ることよりも、計画の調整や再計画を重視する
○ スクラムでは、事前にきちんとした計画を作れるわけがないと考える。状況
の変化は避けられないのだから、変化に合わせて事前の計画を見直すこと
に重きを置く
● 「森の中で道に迷ったとき、もし実際の地形が地図と違うなら、いかなる場合でも
実際の地形を信じること」
● 早めにリリース、頻繁にリリース
○ そのほうが素早くフィードバックを得られるし、投資収益率も向上する

16. 頻繁なリリースと投資収益率との関係
最小限のコア機能を実装完了後すぐにリ
リースしていった場合
全ての機能を実装完了後にリリースし
た場合
ユーザーが求めている機能
ユーザーが求めていない機能
ユーザーからのフィードバック

17. スプリントプランニング

18. スプリントプランニング
● スプリントを開始する時に開催する
● 2 週間のスプリントの場合、4 時間かける
● 一番重要なインプットはプロダクトバックログであり、事前にグルーミングを行っ
ておく
● プロダクトバックログアイテムを分解してスプリントバックログを作る
○ スプリントバックログとはスプリントの対象となった各プロダクトバックログア
イテムに対してのバックログ
○ タスクに分解し、時間単位で見積もりをしておく

19. スプリントのキャパシティ
● スプリントが 10日間だったとして、その全てをスプリントの実施に使えるわけで
はない
● スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブに 1 日
を確保しておく
● グルーミングに 1 日くらいかかる
● その他の作業に 0.5 日くらい見積っておくと良いかも？
● バッファとして 1 日上積みする
● これを合算すると、10日で 6.5 日、52 時間となる

20. スプリントの実施

21. スプリントの実施
● 理想的には、各人が PBI を並列で対応していくのではなく、1 つの PBI を全員
で（テストも含め）対応していく。これをスウォーミングという
○ https://t-and-p.hatenablog.com/entry/2018/03/11/swarming-what-w
hy
○ リソース効率よりフロー効率を重視する

22. なぜスウォーミングするのか
● 人間は並列作業が増えるごとにパフォーマンスが下がるため、できるだけ一度
に行う作業数を減らす
● スプリント期間中に PBI が一つも完了しなかった、という事態を避けるため
● できる限りフィードバックのタイミングを早めるため
補足
● エンジニアのコアスキルはプログラミング、QA のコアスキルはテスト設計と探索
的テスト。テスト実施はエンジニアと QA のコアスキルではない
● 機能はテストされないと完了しない。チームとしての生産性をあげるには、エンジ
ニアもテストを実施した方が良い（はず）

23. スプリントレビュー

24. スプリントレビューとは
● スプリントの成果物に対して検査と適応を行う
● スプリントレビューは、プロダクト開発のインプットに関わった人に対して、これま
で構築したものについて検査と適応を提供するものである
● 不都合な真実も含めて、現在の状況を透明に見せてくれる。質問をしたり、観察
や提案をしたり、現状を考慮して今後の方針について議論したりする時間であ
る。しかし問題解決の場ではない。それは別のミーティングで行うべきだ
● スプリントレビューには全ての利害関係者が参加すべきである
○ 小規模なリリースデモのようなもの
● 2 週間のスプリントであれば 2 時間以内に終わらせる

25. なぜスプリントレビューを行うのか
スプリントレビューによって、正しいプロダクトを開発していると組織が確信できる
ようになることから、スクラムフレームワークの中で最も重要な学習ループの一
つである。
スプリントの期間は短いので、このループは高速だ。つまり、プロダクト開発を正
しい方向へと頻繁に軌道修正できるのである。
このフィードバックが大幅に遅れ、全てが計画通りに進んでいると思い込んだま
までいれば、いつものように、驚き、失望、不満を抱くことになるだろう。

26. スプリントレトロスペクティブ

27. スプリントレトロスペクティブとは
● レトロスペクティブはチームが自分たちの環境に合わせてスクラムをカスタマイ
ズできる機会を提供する。
○ しかし、「実際の」設計、実装、テストの作業ではないので、過小評価されて
いる
● スプリントレトロスペクティブでは以下のことを話し合う
○ スプリントでうまくいったので、今後も続けたいことは何か？
○ スプリントでうまくいかなかったので、今後は中止したいことは何か？
○ これからやった方が良いこと、改善した方が良いことは何か？
● 2 週間のスプリントで 1.5 時間

28. インサイトバックログ
● レトロスペクティブで発見したが、すぐには解決できない課題はインサイトバック
ログにまとめておく
● 経済的合理性があるインサイトアクションは次のスプリントで行うことになる
○ このとき、アクションの分スプリントのキャパシティは小さくなる