アジャイルサムライ 6章　ユーザストーリーを集めるのまとめ。

1. 六章：ユーザストーリーを集める
アジャイルサムライ横浜道場
2014/09/09
@trtraki

2. 自己紹介
@trtraki
Sierからweb系エンジニアへ転職
横浜道場へはここ最近から参加

3. アジェンダ
6.1 文書化の難しさ
6.2 そこでユーザーストーリーですよ
6.3 よく書けているユーザーストーリーとは
6.4 ストーリー収集ワークショップを開催しよう

4. 6.1 文書化の難しさ

5. 文章で、全ての仕様を表現するのは難しい
例えば・・・

6. 確かに仕様書にもそう書
いたわよ！
でも、それって古い仕様
書の内容じゃない！！！
変化に対処しずらい

7. このUIだと使いにくいけど、
仕様書に書いてあるから、
問題ないだろう・・・。
顧客の欲しいものに合わせるのではなく、!
仕様に合わせて作る事になる…。

8. 等々、色々不都合があります。
解決策として…。

9. もっと綿密な仕様書を作ればいいじゃん！

10. そう考えた方は、
次のスライドをご覧ください。

11. 私は彼女がお金を盗んだとは言っていない
私は、彼女がお金を盗んだとは言っていない。
私は彼女がお金を盗んだ、とはいっていない。
私は彼女がお金を、盗んだとは言っていない。
私は彼女がお金を盗んだとは言っていない。
!
!強調する場所によって、随分印象が変わっ
てくる。
文章だけで説明するのは危険。

12. 6.1のまとめ
全ての情報を文章で伝えるのは難しい。
情報を最も効率的で効果的な方法は
フェイス◦トゥ◦フェイスで話をする事です！

13. 6.2 そこでユーザストーリですよ

14. ユーザストーリーを書く時のコツ
一言で言うと
簡潔に書く！
これだけです。

15. なぜ、簡潔に書くのか？
要求の本質だけをキーワードとして残し、
後で詳細を話し合う時のきっかけとする。

16. なぜ、詳細は後で話すのか？
要求を出しときには有効だったが、実装す
るときには話し合った詳細が無駄になる事
が多い為。
(アプリの旬が過ぎてしまった等々)

17. 6.2のまとめ
1. ユーザストーリーは簡潔に。
2. 詳細は必要な時(多くは実装直前)に詰める。

18. 6.3 よく書けているユーザーストーリーとは

19. 良いユーザストーリの条件
1. 顧客が理解しやすくビジネス的価値が書かれている事。
2. エンドツーエンドになっていること。
3. 独立していること。
4. 交渉の余地がある。
5. テストできる。
6. 小さい、見積もれる。

20. 顧客が理解しやすくビジネス的価値が書かれている事
分かりやすく価値が判定できないと、顧客もそ
のストーリーが本当に必要か判断できない事。
（理由：顧客が分かりやすくするため）

21. エンドツーエンドになっていること
特定のレイヤの変更に着目したものでなく、三
つのレイヤを横断的に変更されている事。
（理由：顧客が分かりやすくするため）
※特定のレイヤ：ユーザインターフェース、ビジネスロジック層、永続層

22. 独立していること
ユーザストーリー同士が疎結合であること。
（理由：柔軟にスコープを変更できるため）

23. 交渉の余地がある
交渉が出来るようにある程度曖昧に書く。
（理由：ある程度融通を聞かせられるようにするため）

24. テストできる
テスト出来るような文章として書くこと。
（顧客側理由：理解しやすくするため）
（開発側理由：作業範囲と仕事の完了基準の明確化）

25. 小さく見積もれる
1～5日程度で完成するサイズで見積もる
!
（理由：見積もりに自信と確実性を求めるため）

26. 略語
1. 独立している（Independent）
2. 交渉の余地がある（Negotiable）
3. 価値のある（Valuable）
4. 見積もれる（Estimable）
5. 小さい（Small）
6. テストできる（Testale）
!
略語はINVESTと呼ぶ。

27. とは言え、このままだと初心者には、
少し使いにくい状態だと思います。

28. そんな時は・・・。

29. テンプレート
＜ユーザの種類＞として
＜達成したいゴール＞をしたい
なぜなら＜理由＞だからだ

30. 例えば、図書検索システムだった場合
＜図書を借りにきた短気なユーザ＞として、
＜目的の図書をすぐに検索＞したい
なぜなら＜あるかも分からない図書を探して迷うの
は時間の無駄＞だからだ

31. テンプレートの利点
メリット：状況を明確に出来る。
デメリット：少し冗長

32. これがシンプルなユーザストーリだったら
図書を検索する

33. 結局、シンプルなユーザストーリーと
テンプレートを使用したユーザストーリーは
どっちがいいの？

34. どちらでもいいそうです。
自分に合った考え方で、ユーザストー
リーを作成すればOKです。

35. 6.3のまとめ
1. ストーリーは、INVESTに則って書く
2. 書く時は、自分に合った方法で書く

36. 6.4 ストーリー収集ワークショップを開催しよう

37. ストーリー収集ワークショップとは
開発チームと顧客が一緒にユーザストーリを出
して行く事。

38. ストーリー収集ワークショップの目的
多くの要求を話し合い皆が全体像を把握する事。

39. ストーリー収集ワークショップの基本
お客さんと一緒に図を書いたり、ストーリーに
関して議論をする。基本はこれだけです。

40. ストーリー収集ワークショップのコツ
1. 大きくて、見通しの良い部屋を用意する
2. 図をたくさん描く
3. ユーザーストーリーをたくさん書く
4. その他もろもろをブレインストーミングする
5. リストを磨き上げる

41. 大きくて、見通しの良い部屋を用意する
1. アイデアを壁にはったりして、アイデアを沢
山だす。

42. 図をたくさん描く
1. ペルソナ・フローチャート等なんでもOK
2. 幅広く要求を抽出する為に、図の粒度は粗く
する

43. ユーザーストーリーをたくさん書く
1. 前説で出した図を元にウォークスルーを実施
2. 大きなストーリーはエピックとして扱う
3. エピックは着手する時に細かいストーリーに
分ける。

44. その他もろもろをブレインストーミングする
1. 図から漏れたものを書き出す。例えば、デー
タ移行や負荷テスト等々。
2. プロジェクトが上手くいく為に必要なものを、
このタイミングで再確認する。

45. リストを磨き上げる
1. 少し時間を取って、漏れや被りがないか確認
する
2. グループ分けできるか、顧客に価値を届けら
れるか、良いToDoリストになっているかも
確認。

46. 6.4のまとめ
1. 顧客と良いストーリーをたくさん出す事に
よって、全体の共通認識を合わせる

47. 個人的な全体まとめ
1. ストーリーは、INVESTに則って書く
2. 顧客と良いストーリーをたくさん出す事に
よって、全体の共通認識を合わせる

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