第61回名古屋アジャイル勉強会「どう書くの、ユーザーストーリー？」のワークショップ資料 http://blogs.yahoo.co.jp/nagoya_agile_study_group/38303993.html

1. どう書くの、ユーザーストーリー？
第61回 名古屋アジャイル勉強会
2014/03/28 You&I

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

3. ATTENTION
本資料は名古屋アジャイル勉強会
のブログにて公開致します。
資料の内容について全ての
メモを取る必要はありません。
ワークショップ内容に集中して
頂ければ幸いです。
3

4. AGENDA
1. テーマについて
2. ユーザーストーリーの背景
3. ユーザーストーリーの本質
4. ユーザーストーリーを書いてみよう
5. まとめ
4

5. 1.テーマについて
5

6. 1. テーマについて (1/6)
皆さん
ユーザーストーリー
書いてますか？
6

7. 1. テーマについて (2/6)
ユーザーストーリーとは顧客に価値をもたら
す何らかのフィーチャー(目玉・特徴点)を表
します。
アジャイル開発においては、ユーザーストー
リーはとても重要な要素で、ユーザーストー
リーが起点となって開発に関する物事が進
んでいきます。
7

8. 1. テーマについて (3/6)
Scrumにおいては、ユーザーストーリーは
プロダクトバックログ項目(PBI:Product
Backlog Item)に位置づけられており、開
発チームとプロダクトオーナー、顧客やその他
利害関係者との意思統一やコミュニケーショ
ンを取る為のツールとなります。
8

9. 1. テーマについて (4/6)
ユーザーストーリーの優先度を決めたり、作
業規模を見積もったり、分類する手法として
は、以下のような手法が良く使われます。
• プランニングポーカー
• 狩野モデル
• ユーザーストーリー・マッピング
これらは今回のテーマからは外れますので、
詳細については説明を行いません。
9

10. 1. テーマについて (5/6)
皆さん
ユーザーストーリー
「ちゃんと」
書けていますか？
10

11. 1. テーマについて (6/6)
ユーザーストーリーを分類する前に、そもそも
ユーザーストーリーが「ちゃんと」書けていない
と分類がうまくいかないと思います。
今までのワークショップでは流れを優先した
為、ユーザーストーリーをどう書くのかに重き
をおいておりませんでしたが、今回はこの
「ちゃんと」の部分をテーマとして取り上げます。
11

12. 1. テーマについて：確認
ここまでの説明はご理解頂けましたでしょう
か？
表明じゃんけんで理解度をお知らせ下さい
• グー
●お前は何を言っているんだ？
• チョキ
●大体理解した。次に進めてOK。
• パー
●全て理解した。
12

13. 2.ユーザーストーリーの背景
13

14. 2.ユーザーストーリーの背景 (1/5)
ユーザーストーリーは、顧客の視点からサー
ビスや商品といったプロダクトの動作を記述
したものです。
通常はインデックスカード等の紙に書いて管
理します。
14
＜役割＞として、
＜活動＞を行う事ができる。
それにより＜ビジネス価値＞
がもたらされる。

15. 2.ユーザーストーリーの背景 (2/5)
ユーザーストーリーとは、XP(eXtreme
Programming)で取り入れられたアジャイ
ルプラクティスの一つであり、同じくXPのプラ
クティスである１週間サイクルと組み合わせ
る事で、アジャイル開発の特徴である反復
型開発を進めていく上でとても重要な要素
です。
15

16. 2.ユーザーストーリーの背景 (3/5)
XPは1999年に Kent Beck氏 の著書
「eXtreme Programming
explained」 (日本語訳：XP エクストリー
ム・プログラミング入門)としてまとめられたア
ジャイル開発手法の一つです。
16

17. 17
http://www.extremeprogramming.org/map/project.html

18. 2.ユーザーストーリーの背景 (4/5)
先程のプロダクトバックログの例のように、XP
から生まれたユーザーストーリーは、現在のア
ジャイル開発手法の主流であるScrumにも
取り入れられています。
アジャイル開発手法やアジャイルプラクティス
と呼ばれているものの中には、先人の成果を
取り入れたものもあります。そのルーツを知る
事で目的や背景の理解が深まる事もありま
す。
18

19. 2.ユーザーストーリーの背景 (5/5)
Scrumは、 1993年に Ken Schwaber
博士 と Jeff Sutherland博士 によって体
系化されたアジャイル開発手法の一つです。
Scrumの起源を含めたお話は、チェンジビ
ジョンの平鍋さんと野中先生による著書「ア
ジャイル開発とスクラム」を読んでみて下さい。
19

20. 20http://scrumprimer.org/jp/anime

21. 2.ユーザーストーリーの背景：確認
ここまでの説明はご理解頂けましたでしょう
か？
表明じゃんけんで理解度をお知らせ下さい
• グー
●お前は何を言っているんだ？
• チョキ
●大体理解した。次に進めてOK。
• パー
●全て理解した。
21

22. 3.ユーザーストーリーの本質
22

23. 3.ユーザーストーリーの本質 (1/13)
先程以下のように説明しました。
ユーザーストーリーは、顧客の視点から
プロダクトの動作を記述したものです。
XPとScrumとでは誰が書くのか？が異なり
ます。それ以外の部分は同じです。
• XP
●顧客
• Scrum
●プロダクトオーナーや開発チーム
23

24. 3.ユーザーストーリーの本質 (2/13)
ユーザーストーリーの記述方法について、こ
れまた先程以下のように説明しました。
この記述方法は、ユースケース記述の書き
方と似ています。但し、ユースケースとユー
ザーストーリーはまた別な概念です。
24
＜役割＞として、
＜活動＞を行う事ができる。
それにより＜ビジネス価値＞がもたらされる。

25. 3.ユーザーストーリーの本質 (3/13)
 ＜役割＞
• プロダクトの利用者
• 人ではなくシステムの場合も
 ＜活動＞
• プロダクトの動作(=フィーチャー)
 ＜ビジネス価値＞
• 顧客や利用者がどのような利益を得るのか
 (例)
• ＜書籍の購入者＞として、＜ISBNで書籍の検索を
行い＞たい。それは＜探している書籍を素早く見つける
＞為だ。
25

26. 3.ユーザーストーリーの本質 (4/13)
ユーザーストーリーは要求・要件ではない
• 「えっ」と思う人もいらっしゃるかも知れません。
• ユーザーストーリーでは、プロダクトの動作は詳
細には書かれません。但しプロジェクトの進行と
共に詳細・明確に書き換えていきます。
• フィーチャーをどのように実現するのか(How)は
書きません。
• 顧客には無価値な非機能要件も書きません。
26

27. 3.ユーザーストーリーの本質 (5/13)
なんだか難しそう・・・。じゃあユーザーストー
リーはどう書けば良いの？
ちゃんと指針があります！
• 3C
• フィーチャーの粒度
• ストーリーへの分割
• INVEST
27

28. 3.ユーザーストーリーの本質 (6/13)
3C
1. Card(カード)
●意図を要約する
2. Conversation(会話)
●意図を実装する為の聞き取り調査
3. Confirmation(確認)
●DONEの定義、受け入れテストの実施。
http://xprogramming.com/articles/expcardconversationconfirmation/
※カードは裏側も使います。裏面には主に受け入れテスト内容を記述します。
28

29. フィーチャーの粒度 (1/3)
• 先程から出てきているフィーチャーって何でしょ
う？先程以下のように説明しました。
●プロダクトの目玉・特徴点
●プロダクトの動作
• 皆さんが思い描くフィーチャーってどんなイメージ
でしょうか？
29
3.ユーザーストーリーの本質 (7/13)

30. フィーチャーの粒度 (2/3)
• 私のイメージではこんな感じです。
30
3.ユーザーストーリーの本質 (8/13)
顧客のやりたい事・ビジョン
エピック
エピック
サーガ
エピック
エピック
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー

31. 3.ユーザーストーリーの本質 (9/13)
フィーチャーの粒度 (3/3)
 サーガ ＞ エピック ＞ フィーチャー の順に作業規模は
小さくなっていきます。
 ユーザーストーリーは、最終的にはフィーチャーの粒度
か、もう一段分割された大きさになります。
 最初に書かれたユーザーストーリーはサーガの粒度になるか
も知れません。
 そこから顧客との会話を経て、作業の優先度の高いものか
らエピックやフィーチャーの粒度に分割していきます。
31

32. 3.ユーザーストーリーの本質 (10/13)
 ストーリーへの分割 (1/3)
 エピックからフィーチャー、更にストーリーへの分割を行う場
合には、End-to-Endに垂直分割する事が望ましいです。
http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html
 小さく分割したユーザーストーリーは、同じようなストーリー
をまとめて一つのストーリーに統合する事もあります。
 ストーリーを分割する10のパターンを紹介します。
32

33. 3.ユーザーストーリーの本質 (11/13)
 ストーリーへの分割 (2/3)
1. ワークフローステップ
●処理の流れに沿って分割
2. ビジネスルールのバリエーション
●複雑なビジネスルールを分割
3. 大半の労力
●一つ目は時間が掛かるが、それ以降は楽になるケース
4. 単純/複雑
●最もシンプルなケースから手を付ける
5. データのバリエーション
●多言語対応や、複数RDBMS対応等。
33

34. 3.ユーザーストーリーの本質 (12/13)
 ストーリーへの分割 (3/3)
6. データ入力方法
●シンプルなUIから実装を始める
7. システム品質を後回しにする
●性能、セキュリティ、可用性などで分割する
8. 操作(CRUD)
●生成・破棄、読み書きの操作で分割する
9. ユースケースシナリオ
●シナリオ単位で分割する
10.スパイクを始める
●リスクや不確実性をプロトタイプ作成等により取り除く
34

35. 3.ユーザーストーリーの本質 (13/13)
 INVEST
• Independent
● 他のストーリーからの独立性があるか
• Negotiable
● ガチガチに決めすぎず、交渉の余地を残しているか
• Valuable
● 顧客にとって価値があるか
• Estimable
● 見積り可能か
• SizedRight / Small
● 適切な大きさか
• Testable
● 受け入れテスト可能か
35

36. 3.ユーザーストーリーの本質：確認
ここまでの説明はご理解頂けましたでしょう
か？
表明じゃんけんで理解度をお知らせ下さい
• グー
●お前は何を言っているんだ？
• チョキ
●大体理解した。次に進めてOK。
• パー
●全て理解した。
36

37. 4.ユーザーストーリーを書いてみ
よう
37

38. 4.ワーク1：自己紹介 (1/3)
早速ユーザーストーリーを書いてみましょう。
手始めに、自分の願望・欲望・目標などを
インデックスカードに書いてみましょう。
• 例)１旅行者として、湯布院で温泉に浸かり
たい！それにより癒やしがもたらされる。
何枚書いてもOKです。
38
＜役割＞として、
私は＜活動＞を行う事ができる。
それにより＜ビジネス価値＞がもたらされる。
時間：5分間

39. 4.ワーク1：自己紹介 (2/3)
今書いて頂いたストーリーを使って自己紹
介を行いましょう。
自己紹介内容
1. お名前
2. 書いたストーリー紹介
1人2分以内でお願いします。
39時間：8分間

40. 4.ワーク1：自己紹介 (3/3)
書いて頂いたストーリーは「ちゃんと」ストー
リー(物語)になっていましたか？
今書いて頂いたように、ユーザーストーリーは
顧客が自分の要望を書いたり、プロダクトオ
ナーが顧客の要望を文字列化したものと考
えてみると書き方について理解が進むかも知
れません。
40

41. 4.ワーク2：ストーリー作成 (1/3)
今回は各テーブルで共通のお題に基づいて
ユーザーストーリー作成を行って頂き、テーブ
ル毎にどのような違いが出たかを見てみたい
と思います。
41

42. 4.ワーク2：ストーリー作成 (2/3)
お題：サーカス団
• 皆さんは、今からそれぞれとあるサーカス団の
一員です。
まずはサーカス団の名前を決めましょう。
• じゃんけん・多数決等決め方はお任せします。
• 名前が採用された方が団長となります。団長
は最終決定権を持ちます。
• 付箋紙などに団名を書いておいて下さい。
42時間：3分間

43. 4.ワーク2：ストーリー作成 (3/3)
サーカス団でどんな出し物をするかをユー
ザーストーリー形式でインデックスカードに書
き出して下さい。
例)ライオンとして、火の輪くぐりが出来る。そ
れにより観客に驚きを与える事が出来る。
43
＜役割＞として、
私は＜活動＞を行う事ができる。
それにより＜ビジネス価値＞がもたらされる。
時間：10分間

44. 4.ワーク3：ストーリー確認 (1/3)
例として出した、
• ライオンとして、火の輪くぐりが出来る。それによ
り観客に驚きを与える事が出来る。
このストーリーには、実装部分の記述があり
ません。
• ライオンにどのように芸を仕込むのか？
• ライオンの檻やえさ代は？
あとユーザー価値の部分がイマイチかも・・・。
44

45. 4.ワーク3：ストーリー確認 (2/3)
先程書いて頂いたストーリーについて
• 3CやINVESTを満たしているか確認しましょう。
• 受け入れテスト条件を考えてみましょう。
●実装(出し物の準備)で何が必要か
受け入れ条件は、インデックスカードの裏側
に書いて下さい。
• 意見がまとまらない時は団長が決めて下さい。
45時間：10分間

46. 4.ワーク3：ストーリー確認 (3/3)
どんなサーカス団になったのか、テーブル間で
共有したいと思います。
発表テーブルの団長は、以下の内容を説
明して下さい。
• サーカス団の特徴・売りなど
• 代表的なストーリーを３つ
お手数ですが、発表するテーブルの周りにお
集まり下さい。
46

47. 4.ユーザーストーリーを書いてみよう
今回のお題としたサーカス団ですが、以下の
狙いが有りました。
• 大体の人がサーカスを知っており、「出し物」に
より観客を満足させるという構図
• アジャイル開発書籍でも良く紹介される、内製
開発やサービスの提供側の集団
• 出し物の長さは大体同じ位なのでストーリーの
大きさも同じになりそう
47

48. 4.ユーザーストーリーを書いてみよう
Scrumにおいては、ユーザーストーリーに対
して、作業規模の見積と優先順位を付与
したプロダクトバックログが成果物に位置づけ
られています。
今回は、規模見積や順位付けは行いませ
んでしたが、成果物になりそうなストーリーは
書けましたか？
48

49. 5.まとめ
49

50. 5.まとめ (1/4)
 お疲れ様でした。
 どうですか「ちゃんと」ユーザーストーリーは書けま
したか？
 3CやINVESTを意識して書く事はできました
か？
• サーカス団の出し物だとテーマ性を決めてなけれ
ばストーリー間の依存関係は少なくなりそうですね。
 ここでちょっとユーザーストーリーを書いた後の話
をしたいと思います。
50

51. 5.まとめ (2/4)
完了したユーザーストーリーのインデックス
カードは破棄出来ます。
• とあるカード(Card)のストーリーについて、会話
(Conversation)を持って調整されたフィー
チャーは、受け入れテストを持って実装内容が
確認(Confirmation)されます。
• つまり、ユーザーストーリーの価値は、実装され
たフィーチャーだけでなく、制約等を確認する受
け入れテストとして実装される形でも残ります。
51

52. 5.まとめ (3/4)
とは言っても、インデックスカードを破棄してし
まうのは怖いですね。
完了したユーザーストーリーの内容はもう変
更される事がありませんので、課題管理シス
テム(ITS)等に登録して、永続化＆検索し
やすくするなどの対応が１つ解かも知れませ
ん。
52

53. 5.まとめ (4/4)
やはりユーザーストーリーは書いてなんぼです。
書いた数だけ、より良いストーリーが書けるよ
うになると思います。
今後も名古屋アジャイルではユーザーストー
リーを使ったワークショップは開催していきます
ので、是非ご参加下さい。
53

54. 5.まとめ：確認
今回のワークショップについてご理解頂けまし
たでしょうか？
表明じゃんけんで理解度をお知らせ下さい
• グー
●お前は何を言っているんだ？
• チョキ
●大体理解した。復習しつつ実践に繋げたい。
• パー
●全て理解した。明日から実践する。
54

55. 参考資料等
書籍「アジャイルソフトウェア要求」
• ISBN：9784798135328
• http://books.shoeisha.co.jp/book/b
165406.html
55