2015.7.2 スクラム道関西主催スクラムナイト#7で使用したスライドです。 https://scrumdo-kansai.doorkeeper.jp/events/27350

2. スクラム
道
関西
2
私たちは、ソフトウェア開発における私たち自身の現場をより良くし
たいという想いから、スクラムやアジャイルな開発の知識を相互に共
有し、議論しながら切磋琢磨するために集まった関西のコミュニティ
です。
私たちは開発者のみなさんがいつも笑顔で開発できるような世界を目
指しています。
スクラム道関西
https://www.facebook.com/ScrumDoKansai

3. 自己紹介
スクラム導入コーチ
開発チームの構築・開発戦略コンサルタント
20年勤務したソフトウェア開発企業を辞め、 2014年から独立したアジャ
イルコーチに。
前職では、受託を主とした制御系開発企業で、SI事業(電機メーカー系)の
案件として、設備監視の専門業務システム(通信網・交通網)の開発に従
事
山本 雄一郎
スクラム道関西 メンバー
POMeetup主宰 @u1r_red
u1r.yamamoto

4. 4本日の目的・ゴール
 User Story Mappingを体験する(あくまで活用のひとつ)
 効果を感じ、現場に取り入れる検討材料になる
 手法だけでなく、その背景にあるものを感じてもらって、
開発現場がよくなる何かしらのヒントになるといいなぁ
発見する気持ちを大切に
楽しんでください

5. User Story Mapping
5

6. プロダクトバックログは
どこにいるか見失う
6
（挿絵削除）

7. 7User Story Mapping
A prioritized user story backlog helps to understand what to do next, but is a
difficult tool for understanding what your whole system is intended to do. A
user story map arranges user stories into a useful model to help understand
the functionality of the system, identify holes and omissions in your backlog,
and effectively plan holistic releases that delivery value to users and business
with each release.
“User Story Mapping” Summary (Jeff Patton)
http://www.agileproductdesign.com/presentations/user_story_mapping/

8. 8
まもなく、
日本語版が発売されます

9. 9
ユーザーストーリーマッピングは、開発しとる奴ら
だけやのうて、関係者全員兄弟やさけぇ、ばしっ
と共通認識を持とうや、つうことでジェフ兄ィが日
頃やっとることをまとめた本なんやで。みんな使こ
てるユーザーストーリーについてもな、わかりや
すぅ説明してあって、お得やと思うでぇ。
知らんけど。
『ユーザーストーリーマッピング』監訳者
川口 恭伸
監訳の川口さんからメッセージをいただきました

10. （エクササイズ）
10

11. ストーリーを
マップにしてみる
ユーザーストーリーマッピングの練習
11

12. 12ユーザーの活動を考えてみましょう
 対象となる場面で、あなたがすること(＝活動、タスク)
を書き出してみましょう。
それを行うとき、どんなことをどんな順で進めますか
朝起きてから、それを始めるまでどんなことをしますか
それを終えた後、何をしますか
 各自で１タスクずつ付箋に書いてください。

13. 13ユーザ活動をマップにする
 タスクを持ち寄って、ひとつに統合してください。
 左から右への1列にしてください。
• 人による違いも、それを楽しみながら並べましょう
 グループにして、タイトル(アクティビティ)を付けます。
簡潔な動詞を使って表現します。
「チケット購入の手続き」→「チケットを買う」
time
task
sub-task or
task details
activity

14. time
14
ユーザーのストーリー
「それから」 「それから」
「して、」
「あるいは、」
「して、」
ナラティブフロー（物語の順序）

15. プロダクトを
ユーザーのストーリー
で組み立てる
15

16. 16練習用のお題
（開発のテーマ）
なぜ開発するのか
誰に提供するのか
- [ユーザー]：(製品やサービスを利用する人)
- [顧客]：(製品やサービスに対価を払う人)
何を提供するのか
- Android/iPhoneアプリとして提供
- (ほか、主な機能特徴)

17. 17プロダクトに必要な機能を並べてみる
timeactivity
 アクティビティごとに、ユーザーがアプリ上で行うタスク
を挙げてください。
機能や操作ではありません
「詳細情報を表示する」
⇒〇「詳しい情報を見る」◎「場所を知る(住所を見る)」
ほぼ同時に行なうものや選択肢など、詳細なタスクは下に並べる

18. time
18
ストーリーになっていますね？
「それから」 「それから」
「して、」
「あるいは、」
「して、」
ナラティブフロー（物語の順序）

19. Incrementと
リリース計画
19

20. スクラムにおけるincrement
スプリントでできあがるもの
プロダクトバックログの完成を含んだもの
動く(実行可能な)ソフトウェア
 POと開発チームが合意できる完成 (完成の定義)に達したもの
 リリース可能な単位(顧客やユーザーが満足するかたまり)より小
さい
20increment

21. 21
完成したUser Story Mapを
スライスに切ってリリースロードマップにできる

22. 22スライスを分ける視点
 達成したい成果(outcome)に注目する
そのリリースで何を獲得したいか
 顧客セグメントで分ける
市場価値の高いユーザーからリリースる
リーンスタートアップ風に、アーリーアダプター向けに市
場リスクの高いフィーチャーから優先的にリリースする
市場投入の価値があるもの
Minimal Marketable Feature

23. 23小さな部品よりも、少しずつ明確に
 小さな部品に分割して、ひとつずつ作る
精緻で確定的なゴールが必要
 ラフスケッチから細部に進める
不確定なものを確かめながら徐々に明確に

24. やってみましょう
24

25. 25ユーザーでスライスを分ける
1. ユーザーを細分化する
2. 商用価値の順番をつけて縦に並べる
3. そのユーザーにふさわしいタスクを並べる
(その他)

26. 26サンプル：通りすがりのユーザー
 始めてダウンロードしたユーザー
今すぐ目的を達成したい
(xxxをしたくてアプリ紹介サイトで発見した)
どう使えばいいか、まだ知らない
１分以内に目的を達成できそうかどうか判断したい
(該当しないタスク)

27. 27ここからの進め方
1. プランニング[5分]
ユーザーストーリーマッピングを修正し
どのユーザータスクから実装するか決める
2. ペーパープロトタイピング[15分]
みんなで実現
3. レビュー[5分]
 １人がユーザーになる
 他の１人または複数が実行環境になる

28. 28プランニング [5分]
どのユーザーストーリーから実装するか、
相談して決めてください
ユーザータスクやストーリーを修正して構いません
目的は明確ですか？
実現イメージは湧きますか？
個々の実装サイズは適切ですか？

29. 29実装 [15分]
うまく作れるかな
ハサミやカッターによるケガに注意してください
カウボーイプログラマになってませんか
品質も、きちんと作りこみましょう
テスト(合わせてみる、動かしてみる)も忘れずに！

30. 30レビュー [5分]
１人がユーザーになって操作します
他の人は、ユーザーの操作に応じて画面
を動かしてください
プロダクトがユーザーに指図してはいけません
ちゃんとストーリーは成立していますか？
ユーザーにとって邪魔な操作や足りないものはあり
ませんか？

31. まとめ
31

32. 32User Story Mapの利点
 ワークフローやバリューチェーンを表現できる
 全体的なストーリーが見える
 バックログの完全性を確認するのに役立つ
 優先順位づけに有用なコンテキストを提供する
 完全で価値のある機能スライスのリリースを計
画する
ともかく、
簡単で、難しい技術や概念を抜きに議論できる

33. マップのうえで結論を出さない
“You Are Not Your User”
The Design of Everyday Things(日本語訳：誰のためのデザイン) D.A.ノーマン
参考
- 52 WEEKS of UX(6)
http://52weeksofux.com/post/385981879/you-are-not-your-user
- さらなる“ユーザー中心設計”を目指すために(樽本 徹也)
http://web-tan.forum.impressrd.jp/e/2009/06/18/5497
マップを作るのが目的ではない
 実現可能性や実装に必要な時間を考慮する
 適切なサイズ、実現可能な仕様、受け入れ基準、を満たす
33注意すべきところ

34. 理解共有と洗練の事例 34
Sprint
“User Story Mapping”
Product Backlog
コンセプトと
プロダクトの洗練・検証
ゴールと手段の
共有と洗練
実装による
検査と洗練
“Paper Prototyping”
“Vision Board”
(Roman Pichler)
“Lean Canvas”/”Business Model Canvas”

35. 35
結果(output)を小さくしつつ
成果(outcome)と効果(Impact)を最大に