スクラム道

関西

2

私たちは、ソフトウェア開発における私たち自身の現場をより良くし

たいという想いから、スクラムやアジャイルな開発の知識を相互に共

有し、議論しながら切磋琢磨するために集まった関西のコミュニティ

です。

私たちは開発者のみなさんがいつも笑顔で開発できるような世界を目

指しています。

スクラム道関西

https://www.facebook.com/ScrumDoKansai

自己紹介

スクラム導入コーチ開発チームの構築・開発戦略コンサルタント

20年勤務したソフトウェア開発企業を辞め、 2014年から独立したアジャ

イルコーチに。

前職では、受託を主とした制御系開発企業で、SI事業(電機メーカー系)の

案件として、設備監視の専門業務システム(通信網・交通網)の開発に従

事

山本雄一郎スクラム道関西メンバー

POMeetup主宰 @u1r_red

u1r.yamamoto

4本日の目的・ゴール

User Story Mappingを体験する(あくまで活用のひとつ)

効果を感じ、現場に取り入れる検討材料になる

手法だけでなく、その背景にあるものを感じてもらって、

開発現場がよくなる何かしらのヒントになるといいなぁ

発見する気持ちを大切に

楽しんでください

User Story Mapping

5

プロダクトバックログはどこにいるか見失う

6

（挿絵削除）

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

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

9

ユーザーストーリーマッピングは、開発しとる奴ら

だけやのうて、関係者全員兄弟やさけぇ、ばしっ

と共通認識を持とうや、つうことでジェフ兄ィが日

頃やっとることをまとめた本なんやで。みんな使こ

てるユーザーストーリーについてもな、わかりや

すぅ説明してあって、お得やと思うでぇ。

知らんけど。

『ユーザーストーリーマッピング』監訳者

川口恭伸

監訳の川口さんからメッセージをいただきました

（エクササイズ）

10

ストーリーをマップにしてみる

ユーザーストーリーマッピングの練習

11

12ユーザーの活動を考えてみましょう

対象となる場面で、あなたがすること(＝活動、タスク)

を書き出してみましょう。

それを行うとき、どんなことをどんな順で進めますか

朝起きてから、それを始めるまでどんなことをしますか

それを終えた後、何をしますか

各自で１タスクずつ付箋に書いてください。

13ユーザ活動をマップにする

タスクを持ち寄って、ひとつに統合してください。

左から右への1列にしてください。

• 人による違いも、それを楽しみながら並べましょう

グループにして、タイトル(アクティビティ)を付けます。

簡潔な動詞を使って表現します。

「チケット購入の手続き」→「チケットを買う」

time

task

sub-task ortask details

activity

time

14

ユーザーのストーリー

「それから」 「それから」

「して、」「あるいは、」

「して、」

ナラティブフロー（物語の順序）

プロダクトをユーザーのストーリー

で組み立てる

15

16練習用のお題

（開発のテーマ）

なぜ開発するのか

誰に提供するのか

- [ユーザー]：(製品やサービスを利用する人)

- [顧客]：(製品やサービスに対価を払う人)

何を提供するのか- Android/iPhoneアプリとして提供

- (ほか、主な機能特徴)

17プロダクトに必要な機能を並べてみる

timeactivity

アクティビティごとに、ユーザーがアプリ上で行うタスク

を挙げてください。

機能や操作ではありません

「詳細情報を表示する」

⇒〇「詳しい情報を見る」◎「場所を知る(住所を見る)」

ほぼ同時に行なうものや選択肢など、詳細なタスクは下に並べる

time

18

ストーリーになっていますね？

「それから」 「それから」

「して、」「あるいは、」

「して、」

ナラティブフロー（物語の順序）

Incrementとリリース計画

19

スクラムにおけるincrement

スプリントでできあがるもの

プロダクトバックログの完成を含んだもの

動く(実行可能な)ソフトウェア

POと開発チームが合意できる完成 (完成の定義)に達したもの

リリース可能な単位(顧客やユーザーが満足するかたまり)より小

さい

20increment

21

完成したUser Story Mapを

スライスに切ってリリースロードマップにできる

22スライスを分ける視点

達成したい成果(outcome)に注目する

そのリリースで何を獲得したいか

顧客セグメントで分ける

市場価値の高いユーザーからリリースる

リーンスタートアップ風に、アーリーアダプター向けに市

場リスクの高いフィーチャーから優先的にリリースする

市場投入の価値があるもの

Minimal Marketable Feature

23小さな部品よりも、少しずつ明確に

小さな部品に分割して、ひとつずつ作る

精緻で確定的なゴールが必要

ラフスケッチから細部に進める

不確定なものを確かめながら徐々に明確に

やってみましょう

24

25ユーザーでスライスを分ける

1. ユーザーを細分化する

2. 商用価値の順番をつけて縦に並べる

3. そのユーザーにふさわしいタスクを並べる

(その他)

26サンプル：通りすがりのユーザー

始めてダウンロードしたユーザー

今すぐ目的を達成したい

(xxxをしたくてアプリ紹介サイトで発見した)

どう使えばいいか、まだ知らない

１分以内に目的を達成できそうかどうか判断したい

(該当しないタスク)

27ここからの進め方

1. プランニング[5分]

ユーザーストーリーマッピングを修正し

どのユーザータスクから実装するか決める

2. ペーパープロトタイピング[15分]

みんなで実現

3. レビュー[5分]

１人がユーザーになる

他の１人または複数が実行環境になる

28プランニング [5分]

どのユーザーストーリーから実装するか、

相談して決めてください

ユーザータスクやストーリーを修正して構いません

目的は明確ですか？

実現イメージは湧きますか？

個々の実装サイズは適切ですか？

29実装 [15分]

うまく作れるかな

ハサミやカッターによるケガに注意してください

カウボーイプログラマになってませんか

品質も、きちんと作りこみましょう

テスト(合わせてみる、動かしてみる)も忘れずに！

30レビュー [5分]

１人がユーザーになって操作します

他の人は、ユーザーの操作に応じて画面

を動かしてください

プロダクトがユーザーに指図してはいけません

ちゃんとストーリーは成立していますか？

ユーザーにとって邪魔な操作や足りないものはあり

ませんか？

まとめ

31

32User Story Mapの利点

ワークフローやバリューチェーンを表現できる

全体的なストーリーが見える

バックログの完全性を確認するのに役立つ

優先順位づけに有用なコンテキストを提供する

完全で価値のある機能スライスのリリースを計

画する

ともかく、

簡単で、難しい技術や概念を抜きに議論できる

マップのうえで結論を出さない

“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

Sprint

“User Story Mapping”

Product Backlog

コンセプトとプロダクトの洗練・検証

ゴールと手段の共有と洗練

実装による検査と洗練

“Paper Prototyping”

“Vision Board”(Roman Pichler)

“Lean Canvas”/”Business Model Canvas”

35

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