ユーザーストーリー
マッピングを使って
プロダクトバックログを作ろう
ノーストーチ株式会社
伊藤いづみ
@izumii19

今日のゴール
ユーザーストーリーマッピングを体験してみよう
「プロダクトバックログは一体どうやって作るの？ 」という質問を受けることがありま
すが、実際には色々な方法があると思います。
今日はプロダクトバックログを作成する方法としてユーザーストーリーマッピングをやっ
てみましょう。
2

今日のゴール
プロダクトバックログや、これに関連する知識もおさらいしましょう
⚫ プロダクト
⚫ プロダクトオーナー
⚫ プロダクトゴール
⚫ プロダクトバックログ
⚫ プロダクトバックログアイテム
3

おさらい：プロダクト

プロダクト
プロダクト＝顧客へ価値を提供する手段
⚫ ソフトウェアそのものに価値があるわけではない
⚫ 顧客がソフトウェアを利用して問題を解決したり、
ニーズを満たすことができた時に価値は生まれる
⚫ ソフトウェアに加えサービス、サポートなども
価値に含まれる
プロダクト＝ソフトウェア
プロダクト⊃ソフトウェア
5
ソフト
ウェア
サポート
サービス
プロダクト

おさらい：プロダクトオーナー

プロダクトオーナー
(スクラムガイド2020より抜粋)
プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果
に責任を持つ。
組織・スクラムチーム・個人によって、その方法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
プロダクトゴールを策定し、明示的に伝える。
プロダクトバックログアイテムを作成し、明確に伝える。
プロダクトバックログアイテムを並び替える。
プロダクトバックログに透明性があり、見える化され、理解されるようにする。
上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできる。
いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
7

プロダクトオーナー
(スクラムガイド2020より抜粋)
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなけれ
ばならない。
これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能な
インクリメントによって見える化される。
プロダクトオーナーは 1 人の人間であり、委員会ではない。
プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合
がある。
ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する
8

プロダクトオーナー
つまり、プロダクトオーナー(PO)は
⚫ プロダクトの価値を最大化する
⚫ 効果的なプロダクトバックログ (PBL)管理を行う
• プロダクトゴールを策定し、明示的に伝える
• プロダクトバックログアイテム (PBI)を作成し、明確に伝える
• PBIを並び替える
• PBLに透明性があり、見える化され、理解されるようにする
⚫ プロダクトの増加について受け入れるかどうかを判断する
9

POが参加するイベント
10
今日は
ここ

おさらい : プロダクトゴールと
プロダクトバックログと
プロダクトバックログアイテム

プロダクトゴール（PG）とは
⚫ プロダクトバックログに対する確約（コミットメント）
⚫ プロダクトの将来の状態を表しており、スクラムチームの計画のターゲットになる
⚫ プロダクトゴールはプロダクトバックログに含まれる
※スクラムガイド2020のアップデートにてプロダクトゴールが導入された
12
PBL
PG

プロダクトバックログ（PBL）とは
⚫ プロダクトバックログアイテム(PBI)を集めたリスト
⚫ スクラムチームが行う作業の唯一の情報源である
⚫ PBIが優先順の高い順番に並んでいる*1
⚫ 優先順位の高いPBIには詳細な記述が必要
優先順位の低いPBIは曖昧でも良い
（定期的な見直しは必要）
⚫ PBIの並べ替えについてはPOが責任を持つ
*1 一般的にはビジネス価値の高いものが上位に来る傾向にある
13
PBI
PBI
PBI
PBL
PG

プロダクトバックログアイテム（PBI）とは
⚫ プロダクトゴールを達成する「何か（what）」
⚫ POが価値があると判断したものはなんでもPBI
機能タスク／不具合対応／技術改善／ スキルアップ
顧客に見える部分／見えない部分
ソフトウェア以外のもの（インフラとか）
将来の価値をうむもの（検証、学習、実験）
14
PBI
PBI
PBI
PBL
PG

プロダクトバックログアイテム（PBI）とは
⚫ 良いPBIの基準
• 見積もり可能
• 受け入れ基準が明確
• 1スプリント内で終わる大きさ
• デモ手順を決めることができる
• 可能な限り独立
15
PBI
PBI
PBI
PBL
PG

1：PBLの作り方

PBLはどうやってつくる？
⚫ 作り方に決まりはなくやり方は色々あります！
⚫ ユーザーストーリーを書いて作る方法が広く知られている
⚫ 今回は以下の方法でTry！
1. PGを理解する : インセプションデッキ
2. PBLを作成する : ユーザーストーリーマッピング
17

1.プロダクトのゴールを理解する
インセプションデッキ
18
• 我々はなぜここにいるのか
• エレベーターピッチ
• パッケージデザイン
• やらないことリスト
• 「ご近所さん」を探せ
why
• 技術的な解決策
• 夜も眠れない問題
• 期間を明確にする
• トレードオフスライダー
• 何がどれだけ必要か
how
今日はこれ

エレベータピッチ
⚫ ごく短い時間でプロジェクトやアイディアの本質を伝える
⚫ 誰のために何を作るのかを明快にする
(あらゆる人の望みに応えるものを作るわけではない)
19

エレベータピッチ
20

2.ユーザーストーリーマッピング
やり方
1. ユーザストーリーを書く
2. ナラティブフローを作る
3. 別のストーリーを探る
4. ナラティブフローを整理する
5. バックボーンを抽出
6. MVPリリースを切り出す
7. リリーススライスを引く
21

2-1. ユーザーストーリーを書く
⚫ 顧客が実現したいと思っているフューチャー*1
⚫ 書き方に決まりはない（よく使うテンプレはあるよ）
*1 フューチャー＝顧客の価値。お金を払ってでも欲しいと思えるもの
*2 こういうのも顧客の価値。テンプレにこだわらず価値であれば書き出しておく
22
ストーリーカード
［ユーザーの種類］として
［達成したいゴール］をしたい
なぜなら［理由・目的］だからだ
制約*2
○秒以内に
表示できること
ストーリーカード
［一般ユーザー］として
［買った本を簡単に管理］したい
なぜなら
［同じ本をダブって買いたくない］
からだ

2-2. ナラティブフローを作る
⚫ ユーザーストーリーを並べて物語を作る
⚫ マップの左から右へ向かうフロー
⚫ 「まず私はこれをした」「” それから私は”これをした」
23
制約
ストーリー
カード
ストーリー
カード
ストーリー
カード
ストーリー
カード
これは
置いといて
・・・
まず私は
これをした
それから私は
これをした
それから私は… それから私は…

2-3.別のストーリーを探る
⚫ ナラティブフロー以外のバリエーション
• ユーザー別
• シチュエーション
• 詳細、代替え、制約、例外など
24
制約
詳細
詳細
制約 制約
ナラティブフロー
新規登録者
一般ユーザー
A-1
A-2
ユーザーに
よる違い
非機能っぽい
やつとか
大きい
ストーリーの
分割
新しく
出てきた
ストーリー
例外
Sign in

2-4.ナラティブフローを整理
⚫ 別なストーリーを探っている中で出てきたストーリー、レベル合わせ
⚫ 順番の見直し
25
制約
制約 制約
ナラティブフロー
新規登録者
一般ユーザー
A-1
A-2
追加
入れ替え レベル合わせ
Sign in
例外

⚫ 共通の目標に向かうタスクを集約する（アクティビティの作成）
2-5.バックボーンを抽出
26
制約
制約 制約
ナラティブフロー
新規登録者
一般ユーザー
A-1
A-2
ユーザーは
使用する
準備を行う
ユーザーの
情報を
管理する
本の情報を
管理する
アプリの
使い方
を知る
バックボーン
Sign in
アクティビティ
例外

⚫ Minimum Viable Product(MVP:望まれる成果を実現できる最小の製品)
2-6. MVPリリースを切り出す
27
制約
制約 制約
ナラティブフロー
新規登録者
一般ユーザー
A-1 A-2
ユーザーは
使用する
準備を行う
ユーザーの
情報を
管理する
本の情報を
管理する
アプリの
使い方
を知る
バックボーン
Sign in
MVP
最初のリリース！
例外

⚫ 特的の目標を実現しやすいようにタスクをスライスする
2-7.リリーススライスを引く
28
ナラティブフロー
A-1 A-2
ユーザーは
使用する
準備を行う
ユーザーの
情報を
管理する
本の情報を
管理する
アプリの
使い方
を知る
バックボーン
Sign in
リリース１
制約
制約 制約
例外
やらない！
リリース2
リリース3
MVP
新規ユーザー向け
機能
操作性の向上

2-8.ユーザーストーリーマップ完成
29
ナラティブフロー
（物語）
A-1 A-2
ユーザーは
使用する
準備を行う
ユーザーの
情報を
管理する
本の情報を
管理する
アプリの
使い方
を知る
バックボーン
(骨格)
Sign in
リリース１
MVP
制約
制約 制約
リリース3 例外
リリース2
優先順位

PBLにする
30
1 2
4 5
リリース１
MVP
リリース3
…
8
リリース2 7
各リリースの中でも
優先順位をつける
PBL
PG
1
2
4
5
7
…

この形に近づけよう
⚫ 優先順位の高いPBIには詳細な記述が必要
⚫ 優先順位の低いPBIは曖昧でも良い
⚫ 見積もり可能
⚫ 受け入れ基準が明確
⚫ 1スプリント内で終わる大きさ
⚫ デモ手順を決めることができる
⚫ 可能な限り独立
良いPBIになっているか確認
31
PBL
PG
1
2
4
5
7
…

ユーザーストーリーマッピングの良いところ
1. プロセス：３つのC
Card:カードに書く、Conversation:会話する、Confirmation:確認する
2. 全体像を把握しやすい
3. ユーザー視点でストーリーを語ることができる
4. 追加、削除、入れ替えが容易なので最新を保ちやすい
5. ストーリのレベル・粒度を揃えやすい
6. 言葉が消えていくを防ぐ
大切なのはドキュメントを書くことではなく
会話から生まれる共通理解
32

大切なのは
会話から生まれる共通理解

Enjoy ユーザーストーリーマッピング！

参考資料
⚫ ユーザーストーリーマッピング
⚫ SCRUM BOOT CAMP THE BOOK
⚫ アジャイルサムライ−達人開発者への道−
⚫ 5分で分かるスクラム用語集
⚫ プロダクトバックログ項目の明確化の必要性
インセプションデッキのテンプレート
⚫ 簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story
Mapping)
35

おまけ：実際にやってみたマップ
36