名古屋アジャイル勉強会 分科会『スクラムを活用したアジャイルなプロダクト管理』読書会 #1の発表資料。

1. 「スクラムを活用したアジャイルな
プロダクト管理」を読み解く為の
「スクラム入門」入門
名古屋アジャイル勉強会 分科会
『スクラムを活用したアジャイルなプロダクト管理』読書会 #1
http://goo.gl/m9SwO
2013/04/17(水) You&I

2. はじめに・・・
 書籍『スクラムを活用したアジャ
イルなプロダクト管理』(原題
『Agile Product Management with
Scrum』)(以降APMS本と表記)には
以下の一文があります。
 APMS本 P.xv
本書は、あなたがスクラムを理解し、
プロダクトマネージメントについて
の知識を持っている事を前提として
います。
2

3. はじめられるか？
 前提からしてハードル高い！？
 まずはスクラムの部分について、
PDFで無料公開されているドキュ
メントの『スクラム入門』(以降
PRIMERと表記)を元に解説し、
APMS本を読みやすくしようとする
のが本ドキュメントの目的です。
 http://bit.ly/scrum-primer-ja
3

4. ジコ、ショウカイ。
 H/N：You&I(読み：ユーアンドアイ)
 SNS：@you_and_i
 出身：生まれも育ちも名古屋市
 年齢：30代中盤
 本職：商学部出身の職業プログラマ
 言語：C++, C#, VB6.0, 日本語COBOL
 所属：プログラミング生放送 名古屋支部
 名古屋アジャイル勉強会
 わんくま同盟 名古屋勉強会
4

5. スクラム入門について
5

6. スクラム入門について(1/2)
 原題：Scrum Primer
 認定スクラムマスター講習などを
行っているScrum Allianceにて公
開されていた資料。
 現在は下記サイトに移行中？
http://www.scrumprimer.org/
 今回の対象の日本語版はVersion
1.2。上記サイトでは2012年末にリ
リースされたVersion 2.0が公開さ
れています。
6

7. スクラム入門について(2/2)
 Scrumに関する無料の日本語資料
のまとめ
http://www.ryuzee.com/contents/b
log/5707
 上記サイトでドキュメントの書か
れた経緯なども紹介されています。
 このドキュメントを題材にした理
由は、色々なドキュメントを読ん
でみてこれが一番読みやすかった
からです。
7

8. 従来のソフトウェア開発と
スクラム
8

9. 従来のソフトウェア開発とスクラム
 従来のやり方の問題点
アイデアを最初に計画に組み込む必
要がある。そしてアイデアはソフト
ウェアを動作させた時にまた新たな
アイデアが出てくるが、時期的・ソ
フトウェアの構造的に変更が難しい
状態になっている。
情報伝達手段としての文書。誤解を
生まないように詳細に書こうとすれ
ばページ数が多くなり読まれない。
 これらを解決しようという所から
生まれたのがスクラム。
9

10. スクラム概要
10

11. スクラム概要 (1/5)
 スクラムは、1986年に野中＆竹内
両名により発表された論文にて、
日本の製造業における新製品開発
の流れをラグビーのスクラムに例
えられた事にその名前は由来する。
The New New Product Development
Game
http://hbr.org/1986/01/the-new-
new-product-development-
game/ar/1
11

12. スクラム概要 (2/5)
 1993年に先の論文を受けて、Ken
Schwaber と Jeff Sutherland博士
によってスクラムは形式化されて
今に至ります。
 因みにアジャイルマニフェストが
制定されたのは2001年である。
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/
12

13. スクラム概要 (3/5)
 スクラムは、スプリントと呼ばれ
る固定化された作業期間の周期的
繰り返しで開発を行います。
 スクラムのテーマ
1. 検査
成果物や進捗の有効性確認
2. 適応
プロダクトのゴールとプロセスを調整
3. 透明性 ※PRIMERでは明記されず
関係者が共通見解を持つよう見える化
13

14. スクラム概要 (4/5)
1. スプリントの開始時に、チームは
作業リストから顧客の要求項目を
選び、スプリント終了までに選ん
だ項目を完了させる事を製品の責
任者と約束します。
2. スプリントの期間中には要求項目
は変更しません。
3. スプリントの期間中は、毎日チー
ムは集まって手短に進捗確認を行
い、当日の作業内容を調整します。
14

15. スクラム概要 (5/5)
4. スプリント終了後に、利害関係者
と共にスプリントで作成された製
品の差分を用いてスプリントを検
査します。
5. チームは、スプリントの検査から
次のスプリントに向けてのフィー
ドバックを得ます。
6. チームは、必要に応じてレトロス
ペクティブ(ふりかえり)を行いプ
ロセスを改善します。
15

16. http://www.scrumprimer.org/#animeCreative Commons Attribution-NoDerivs 3.0 Unported License
16

17. スクラムチームの役割
17

18. スクラムチームの役割 (1/6)
 スクラムチームは7±2人で構成さ
れる。諸説あるが基本は10名未満。
 チームメンバーはずっと同じメン
バーで作業を行い、変更は避ける。
 スクラムチームの構成
1. プロダクトオーナー(PO)
2. 開発チーム ※PRIMERではチーム
3. スクラムマスター
18

19. スクラムチームの役割 (2/6)
1. プロダクトオーナーの役割
スクラムチームに必ず１人置く。
製品特性を特定する事により、投資
収益率(ROI)を最大化する事に責任が
ある。※売上に対してではない
プロダクトバックログの優先順位付
けを継続的に見直し、次のスプリン
トの為に、どのプロダクトバックロ
グ項目(PBI)が上位にあるべきかを決
めて、リストを洗練します。
スプリントの成果であるインクリメ
ントを受け入れるかどうか判断する。
19

20. スクラムチームの役割 (3/6)
2. 開発チームの役割
自己組織化された集まりで自律的に
行動する。
多能工として職能上の枠を超えて作
業に取り組む。
POが求める製品を実現する為の最適
な方法を決めて、製品を作成する。
20

21. スクラムチームの役割 (4/6)
3. スクラムマスターの役割 (1/2)
スクラムチームに１人置く。
POと開発チームがうまく仕事をこな
す為のサーバントリーダー(奉仕者)。
外部の干渉からスクラムチームを守
る役目を負う。
POと開発チーム、そして組織がスク
ラムを正しく理解し、実践する事を
支援します。
POとスクラムマスターは兼任しては
いけません。
21

22. スクラムチームの役割 (5/6)
3. スクラムマスターの役割 (2/2)
スクラムマスターは、 POと開発チー
ムに対して、プロジェクトの問題や
スクラムチームの問題について監視
を行い、スクラムチームに直接言う
のではなく、異常について気づかせ
ます。
スクラムマスターは、特別な権限は
持ちません。それなので直接指示を
出したり、作業割当を行ったりはし
ません。
22

23. スクラムチームの役割 (6/6)
 「鶏と豚」でのたとえ話
 http://d.hatena.ne.jp/kaorun55/20110328/1301284585
 鶏：顧客、豚：スクラムチーム
 最近は「海賊と忍者」(アジャイルなゲーム開発より)
 http://en.wikipedia.org/wiki/Pirates_versus_Ninjas
23

24. スクラムの成果物
24

25. スクラムの成果物 (1/10)
 スクラムの成果物には以下の３つ
のものがあります。
1. プロダクトバックログ
2. スプリントバックログ
3. プロダクトインクリメント
25

26. スクラムの成果物 (2/10)
1. プロダクトバックログ (1/7)
プロダクトバックログとは
製品のロードマップを示す。
POによって継続的に更新される作業項
目のリスト。作業項目はプロダクトバッ
クログ項目(PBI)と呼ばれる。スクラム
チームの誰もがPBIを追加する事が出来
る。
PBIには優先順位が付けられている。PO
のみが作業の優先順位を変更する事が出
来る。
26

27. スクラムの成果物 (3/10)
1. プロダクトバックログ (2/7)
プロダクトバックログとは(続き)
PBIはその作業規模がスクラムチームに
よって見積もられている。
近々のリリースに向けてのバックログは
リリースバックログと呼ばれます。
POは、リリースに近いPBIほど情報が詳
細化・細分化されるように準備・調整し
ます。
27

28. スクラムの成果物 (4/10)
1. プロダクトバックログ (3/7)
PBIとは
PBIには顧客要求(顧客に価値をもたらす
作業内容)が含まれる。改善目標や調査
事項、不具合情報等は含まれない。
スクラムでは、PBIの表記方法、見積方
法、優先順位の決定方法については定義
をしていない。各スクラムチームで自由
に決めて良い。
PBIの表記方法には様々なものがあるが、
ユースケースやユーザーストーリーで表
現される事が多い。
28

29. スクラムの成果物 (5/10)
1. プロダクトバックログ (4/7)
PBIとは(続き)
PBIは通常ストーリーポイントという単
位で相対的に作業規模が見積られます。
相対見積を行うのは手早くそれなりの精
度で結果を得る為です。
開発チームが１スプリントでこなす事が
出来るストーリーポイント数の平均値を
ベロシティと呼び、見積の基準として利
用します。
PBIにはDoneの定義を行い、作業完了の
条件を明確にします。
29

30. スクラムの成果物 (6/10)
1. プロダクトバックログ (5/7)
ユーザーストーリーとは
eXtremeProgrammingのプラクティスの
１つで、顧客要求について「事の発端か
ら価値の提供」までの流れをEnd-to-End
で記述したもの。
通常はアナログに紙ベースでストーリー
の管理を行う。１枚のメッセージカード
に１つのストーリーを記述する。
30

31. スクラムの成果物 (7/10)
1. プロダクトバックログ (6/7)
ユーザーストーリーとは(続き)
INVESTを意識して記述する。
31
Independent
ストーリー同士が独立しているか？
優先順位を自由に入れ替え可能か？
Negotiable
交渉の余地はあるか？
最初から詳細に書きすぎていないか？
Valuable 顧客にとって価値のある内容か？
Estimable 見積可能であるか？
Sized Right/Small
作業規模が大きすぎないか？
適切な作業規模か？
Testable テスト可能か？

32. スクラムの成果物 (8/10)
1. プロダクトバックログ (7/7)
バックロググルーミング(見直し)
スプリント中や任意のタイミングで、ス
クラムチームによりプロダクトバックロ
グに手入れを行います。
PBIについての要求分析、大きい項目の
細分化、新しい項目の追加、既存項目の
再見積などを行い、１つ又は２つ先のス
プリントに向けて準備をします。
32

33. スクラムの成果物 (9/10)
2. スプリントバックログ
スプリント計画ミーティングでの成
果物となる。
スプリントバックログの項目は、タ
スクと呼ばれ、PBIの項目を具体的な
作業タスクに分割したものとなる。
１タスクは大体１作業者の１日分の
作業規模となる。
PBIが相対見積だったのに対して、タ
スクは理想時間で見積を行う。
33

34. スクラムの成果物 (10/10)
3. プロダクトインクリメント
開発チームによるスプリント作業の
成果物となる。
この製品の”差分”を受け入れるかど
うかの判断はPOが行う。
プロダクトインクリメントは、スプ
リント期間にテストまで行われてい
る。”差分”とはいっても、テスト内
容はこれまでの機能に影響がないか
回帰テストも行われる。
34

35. スクラムのイベント
35

36. スクラムのイベント (1/6)
 スクラムには５つのイベントがあ
ります。
1. スプリント
2. スプリント計画ミーティング
3. デイリースクラム
4. スプリントレビュー
5. スプリントレトロスペクティブ
36

37. スクラムのイベント (2/6)
1. スプリント
１スプリント＝１～４週間の固定化
された作業期間であり、スプリント
は周期的にこれを繰り返し行う。
スクラムチームはスプリント期間内
で終わらせる事のできるベロシティ
内に収まる量の作業項目を選び実施
する。
スプリントの期間中には要求項目は
変更しません。変更を受け付けませ
ん。
37

38. スクラムのイベント (3/6)
2. スプリント計画ミーティング
第1部と第2部の2部構成。
第1部では何をするかを決める
POと開発チームとで、プロダクトバッ
クログを元に今回のスプリントで行う
PBIについて内容やDoneの定義を確認し、
実施するPBIの合意を取ります。
第2部ではどのようにやるかを決める
基本的に開発チームのみで、PBIをタス
クに分割し、理想時間でタスク作業量を
見積もり、スプリントバックログを作成
します。
38

39. スクラムのイベント (4/6)
3. デイリースクラム
いわゆる朝礼。朝会とも呼ばれる。
毎就業日の定刻に定位置で開発チー
ムの全員が参加し、立ったままで行
う10数分の打ち合わせ。
スクラムチーム外の人の立ち会いは
認めるが発言権は認めない。
3つの事について話し議論はしない。
1.前回から何が完了したか、2.次までに
何を完了させるつもりか、3.何か障害に
なっている事はあるか。
39

40. スクラムのイベント (5/6)
4. スプリントレビュー
POと開発チームとでスプリントの成
果物であるプロダクトインクリメン
トについて、Doneの定義を満たして
いるか検査を行う。
POがプロダクトインクリメントを受
け入れるかどうか判断し、拒否され
た場合は、開発チームはタスク内容
についてどこまで出来ているのか確
認して、未完了分の見積を行い、プ
ロダクトバックログに差し戻す。
40

41. スクラムのイベント (6/6)
5. スプリントレトロスペクティブ
開発チームは、スプリントのふりか
えりを行い、プロセスややり方につ
いて改善を行う。PDCAサイクルの
Check/Actionの部分。
ふりかえりのやり方としては、デル
タ＆プラス、KPT(Keep/Problem/Try)
などの継続項目と改善項目を挙げる
プラクティスが使われる事が多い。
41

42. スプリントの進捗確認
42

43. スプリントの進捗確認 (1/3)
 通常はタスクボードで作業状況を
見える化します。デイリースクラ
ムをこのボードの前で行うと効果
的です。
43
http://oblog.objectclub.jp/mieruka-guide-2

44. スプリントの進捗確認 (2/3)
 タスクの消化状況は、スプリント
バーンダウンチャートで見える化
します。
44
http://www.flickr.com/photos/kakutani/2761992149/

45. スプリントの進捗確認 (3/3)
 タスクボードやバーンダウン
チャートの更新は、開発チームの
メンバーの誰かがデイリースクラ
ムのタイミングなどで行います。
 これらのタスクボードやバーンダ
ウンチャートはスクラムチームメ
ンバーの目にとまる場所に貼り出
しておき、いつでも最新の状態を
確認出来る状態を保ちます。
45