社内勉強会で行ったスクラム勉強会の資料です。 スクラム開発の流れや今までの事例を元にまとめています。

1. teens事業部 Candyグループ 佐藤 慎悟
Nippori Agile
sprint 0

2. WARNING
夜な夜な日暮里で遊び回っているという
事業部に広がる
私、個人に対するデマへの皮肉を込めて
この名前にしただけであって
日暮里とアジャイルは一切関係ありません。
NO日暮里！

3. Me!

5. Nippori Agile sprint 0
本日のメニュー
・アジャイルって何だろう
・スクラムについて
・Candy PC開発でやったこと
・インセプションデッキ

6. アジャイルって何だろう？

7. ・・・その前に

8. サービスを作る上で
本当に大事な事って
なんだろう

9. ・何のために作っているの？
・ユーザーにメリットはあるの？
・それが、ちゃんとユーザーに届
けられているかをこまめに確認！

10. 当初よりも良いアイデアが
出てくれば、それを受け入れて
作る物を変えていく

11. 柔軟な対応が必要
当初よりも良いアイデアが
出てくれば、それを受け入れて
作る物を変えていく

12. ・関係者は目的達成のためにお互いに協
力しながら進める
・利用者の反応や関係者からのフィード
バックを継続的に得ながら、計画を調整
・一度にまとめてではなく少しづつ作る
・出来上がった物が求めている物とあっ
ているかを頻繁に確認する

13. アジャイルって何だろう？

14. アジャイルは
目的を達成するため
の習慣

15. アジャイルをやろう
Doing Agile

16. アジャイルをやろう
Doing Agile

17. アジャイルをやろう
Doing Agile
アジャイルにやろう
Being Agile

18. スクラムについて

19. スクラム Scrum
・アジャイル開発の手法の一つ
・全員が一枚岩となって行う、作業、会
議、成果物を定めたもの

20. スクラム Scrum
・要求を常に順番に並び替えて、その順番にプロダク
トを作る事で成果物を最大化する
・固定の短い期間に区切って作業を進める
・現在の状況や問題点を常に明らかにする（透明性）
・定期的に進捗状況や作っているプロダクトが正しい
のか、仕事の進め方に問題がないかどうかを確認
・やり方に問題があったり、もっとうまく出来る方法
があったりすれば、やり方そのものを変える。

21. 実際の流れはどんな感じ？

22. http://www.scrumprimer.org/

23. スクラムには
ロール（役割）があるよ

24. プロダクトオーナー
・プロダクトの結果責任を取る
・プロダクトバックログの管理者で優先順位の最終決定権を持つ
・プロジェクトに必ず一人必要
・開発チームを活用してプロダクトの価値を最大化する
・開発チームに相談出来るが、干渉は出来ない

25. 開発チーム
・リリース判断可能なプロダクトを作る
・全員揃えばプロダクトを作れる
・上下関係はない
・開発チーム全員で作業を進める自己組織化されたチーム

26. スクラムマスター
・スクラムのプロセスがうまくまわるようにする
・妨害を排除する
・支援と奉仕をする
・教育、ファシリテート、コーチ、推進役

27. http://www.scrumprimer.org/

28. http://www.scrumprimer.org/

29. http://www.scrumprimer.org/
プロダクトバックログ
・実現したい要求をリストにして優先順位で並び変える
・一度作って完了ではなく、絶えず修正されるものなので、
常にメンテナンスして最新に保つ
・プロダクトバックログには作業量を表した値を使う

30. １番目に欲しい
２番目に欲しい
３番目に欲しい
４番目に欲しい
５番目に欲しい
６番目に欲しい

31. http://www.scrumprimer.org/

32. http://www.scrumprimer.org/

33. http://www.scrumprimer.org/
スプリント計画ミーティング
・スプリントで開発をするには計画が必要
・ミーティングは二部制
・プロダクトオーナーは何を欲しいのか（第一部）
・開発チームはどれくらいできそうか（第一部）
➡ストーリーポイントをつけていく
・開発チームはどうやってそれを実現するか（第二部）

34. １番目に欲しい
２番目に欲しい
３番目に欲しい
４番目に欲しい
５番目に欲しい
６番目に欲しい
タスク タスク
タスク タスク
タスク タスク
タスク タスク
スプリント

35. http://www.scrumprimer.org/

36. http://www.scrumprimer.org/

37. http://www.scrumprimer.org/
デイリースクラム
・時間は15分以内
・昨日やった事、今日やる事、問題点を共有
・別途で話が必要な物は後で時間をとってやる
・全員が進捗や問題になっている事を把握できる
・デイリースクラムは開発チームのためのもの
➡特定の誰かへの報告会ではない

38. 時間は大切

39. http://www.scrumprimer.org/

40. http://www.scrumprimer.org/

41. http://www.scrumprimer.org/
スプリントレビュー
・開発チームの成果物をプロダクトオーナーが確認する
・確認するのは動作するプロダクト
・完了しなかった物はプロダクトバックログに戻される
・プロダクトバックログに追加する項目の有無について議論
・現在の進捗を踏まえて、リリース日や完了日を予測する

42. http://www.scrumprimer.org/

43. http://www.scrumprimer.org/

44. http://www.scrumprimer.org/
スプリントレトロスペクティブ
・うまくいった事、今後改善すべき点を整理する
・振り返り（KPT法なんかが分かりやすい）
・次回スプリント以降のアクションプランを決める

45. 定期的な振り返りを

46. http://www.scrumprimer.org/

47. よくある質問

48. Q.スプリントの期間って別にバラバラで
もよくないですか？

49. Q.スプリントの期間って別にバラバラで
もよくないですか？
A.スプリントの期間を固定する事でチー
ムのベロシティを計れるようになって進
捗を把握しやすくなったり、見積もりの
誤差が少なくなるよ。

50. Q.ストーリーポイントって時間とかで予
測したらダメなわけ？

51. Q.ストーリーポイントって時間とかで予
測したらダメなわけ？
A.時間で見積もると人によって見積もり
が違う事がある。あと、チームの成長を
考慮していないのでチームが成長して
いった時に見積もりをやり直さないとい
けなくなるよ。

52. Q.リリース判断可能なポイントってどう
いうこと？

53. Q.リリース判断可能なポイントってどう
いうこと？
A.各ストーリーにおけるゴールを明確に
しよう。何をもってリリースが可能かを
決めないといつまで起っても終わりませ
ん。また、リリース判断ポイントの定義
は品質基準とも言えます。

54. PC版開発時のおもひで

55. いまいちな事もありました

56. PC開発でいまいちだった点①
何？このストーリー…
とても、大きいです…

57. PC開発でいまいちだった点①
タスクは細分化しよう。
冷静な判断も下しやすい。
何？このストーリー…
とても、大きいです…

58. PC開発でいまいちだった点②
ゴールどこ？
どこまで走ればいいの？

59. PC開発でいまいちだった点②
ゴールどこ？
どこまで走ればいいの？
ゴールはちゃんと決めましょう。
スプリントって言ってんのにフルマラソン。

60. PC開発でいまいちだった点③
だからこれは
デザインなのよ！

61. PC開発でいまいちだった点③
だからこれは
デザインなのよ！
デザインはデザイン。
仕様等は別のドキュメントで。

62. だけどいい事もあったんだ

63. PC開発でよかった点①
健やかなる時も
病める時も進捗を把握

64. PC開発でよかった点①
健やかなる時も
病める時も進捗を把握
なんだかんだで
状況を全員が把握出来てた

65. PC開発でよかった点②
あれちょうだい！
はい、これもちょうだい！

66. PC開発でよかった点②
あれちょうだい！
はい、これもちょうだい！
随時テスト出来る状態にして
とにかくテストテスト！

67. PC開発でよかった点③
せっかくなんで
ご一緒しませんか？

68. PC開発でよかった点③
せっかくなんで
ご一緒しませんか？
スプリントレビューに
SEO関連部署の方もご招待

69. PC開発でよかった点④
予定していたよりも
早く完了できましたが何か？

70. PC開発でよかった点④
予定していたよりも
早く完了できましたが何か？
差し込み対応とかもあったけど
チーム力の向上もあって前倒し

71. PC開発でよかった点⑤
振り返ると楽しかった
あの日々

72. PC開発でよかった点⑤
振り返ると楽しかった
あの日々
なんかうるさいとかとも言われたけど
楽しく実りのある開発だった

73. インセプションデッキ

74. プロジェクトの全体像を
端的に伝えるための
ドキュメント
※アジャイルサムライを読んでみてください

75. 1.我々は何故ここにいるのか
2.エレベーターピッチを作る
3.パッケージデザインを作る
4.やらないことリストを作る
5.ご近所さんを探せ
6.解決案を描く
7.夜も眠れなくなる問題はなんだろう
8.期間を見極める
9.何を諦めるかをはっきりさせる
10.何がどれだけ必要なのか
10個の手強い質問

76. エレベーターピッチテンプレート
• [潜在的なニーズを満たしたり、抱えている課題
を解決したり]をしたい
• [対象顧客]向けの
• [プロダクト名]というプロダクトは
• [プロダクトのカテゴリー]である。
• これは[重要な利点、購入への説得力ある理由]
があり、
• [競合サービス名]と違って
• 我々のプロジェクトは[差別化の決定的な特徴]
が備わっている。

77. エレベーターピッチ例：Gunosyの場合
• [自分の知りたい情報を定期的に収集]したい
• [ビジネスパーソン]向けの
• [Gunosy]というプロダクトは
• [キュレーションサービス]である。
• これは[簡単な設定での使用や、アプリで手軽に
アクセス]することができ、
• [Yahooニュース]と違って
• 我々のプロジェクトは[常に自分の興味のある分
野の情報を受動的に手に入れられる気軽さ]が備
わっている。

78. 参考書籍

79. Nippori Agile sprint 0
参考書籍
アジャイルサムライ
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06856-0
SCRUM BOOT CAMP THE BOOK
http://www.seshop.com/product/detail/15395/
リーン開発の現場
http://lean-trenches.com/

80. 最後に

82. アジャイルにやろう
Being Agile

83. ご清聴ありがとうございました

84. 質問タイム

85. Nippori Agile
sprint0
~fin~