ユーザーストーリーワークショップ

ユーザーストーリー
作成ワークショップ
名古屋アジャイル勉強会
分科会開発ツール勉強会第3回 Pivotal Tracker入門
2012年6月30日(土) You&I

Agenda
1. アイスブレーク
2. アジャイル開発のおさらい
3. 共通のお題決め
4. WS：プラグマティック・ペルソナ
5. WS：プロダクトバックログ作成
6. WS：タスク分け

1.アイスブレーク(1/2)
• いきなりガッツリとワークショップを始め
る前に、同じテーブル内の皆さんで仲良く
なって頂きたいと思います。
• 今から以下の内容でワークショップを行っ
て下さい。
• テーブルの皆さんで車の絵を用紙に書いて
下さい。
• 但し、声を出してはいけません。
• 一人の人が全部書いてしまわないように作
業分担して下さい。

1.アイスブレーク(2/2)
• サイレントワークショップは如何でした
か？
• 言葉を使わずにコミュニケーションを取る
事は難しかったでしょうか？
• 今日のワークショップは、言葉を使ってコ
ミュニケーションを取っても難しいかも知
れませんよ？
• 分からない事や疑問があればドンドン質問
したり突っ込みを入れていきましょう！

2.アジャイル開発
のおさらい

2.アジャイル開発のおさらい(1/7)
• 今回の話で言う、アジャイル開発とは
Scrumベースでお話します。
• 厳密に言うとScrumの定義ではアジャイル
という言葉は出てきませんが、今回の勉強
会はScrumの流れで進めていきます。

• 2001年に、アジャイル開発手法を支持する
多くの著名人によって公開された、アジャ
イル開発手法の精神をまとめた文書が、ア
ジャイルマニフェスト(アジャイルソフト
ウェア開発宣言)である。日本語訳の公開は
2010年。
• http://agilemanifesto.org/iso/ja/
• アジャイルマニフェストだけではなく、合
わせて１２の原則も公開されており、これ
らを含めてアジャイル開発の根底を成して
いる。

• アジャイルな開発プロセス
1. Crystal Family(The Crystal
methodology:Crystal Clear, etc.)
2. DSDM(Dynamic Systems
Development Method:反復型開発)
3. FDD(Feature-Driven Development)
4. RUP(Rational Unified Process)/UP
5. Scrum
6. eXtreme Programming(XP)

• アジャイルな開発プロセスで定義されている事
1. ゴール(完了条件)
2. ロール(役割)
3. 見積もり
4. 要件定義(フィーチャー、ユーザーストーリー、
バックログ)
5. タイムボックス管理(イテレーション、スプリ
ント)
6. 製品リリース管理
7. ふりかえり
8. PDCAサイクル(Plan-Do-Check-Act cycle)
9. 見える化

• Scrumは1986年に、野中郁次郎・竹内弘高両氏の論
文にて初めてScrumという名前で紹介された。
• Scrumの名前の由来はラグビーのスクラムによる。
• Scrum Allianceによる7種類の認証制度がある。所
謂スクラムマスター。これはScrumを実施するのに
必須ではない。新たにアジャイル開発を行う上では、
アジャイル開発を理解した人(アジャイルコーチ等)
をチームに入れる事が推奨される。
• Scrumの流れは以下の画像が分かり易い。
http://www.ryuzee.com/contents/blog/4789

•共通のお題決め

•プロダクトオーナーの決定
プロジェクトの
•プラグマティック・ペルソナ
立ち上げ

•ユーザーストーリー作成

•優先順位付け
プロダクトバック
•ユーザーストーリーの作業見積
ログ作成

•ユーザーストーリーのタスク分割

•タスクの作業見積
タスク分割

開発の流れ
•共通のお題決め

•プロダクトオーナーの決定
プロジェクトの
•プラグマティック・ペルソナ
立ち上げ

•ユーザーストーリー作成

•優先順位付け
プロダクトバック
•ユーザーストーリーの作業見積
ログ作成

•ユーザーストーリーのタスク分割

•タスクの作業見積
タスク分割

3.共通のお題決め(1/4)
• 本日のユーザーストーリー作成ワーク
ショップを開催するにあたり、まずは皆さ
んが１つのチームとして何か新規開発する
事を前提にしたいと思います。
• いきなりではありますが、参加者の皆さん
で何か作りたいものや、こういうのは面白
そう。といったものをまずは列挙して頂き、
その中から一つお題として採用したいと思
います。

• では幾つか案を出していきましょう。
• やり方はブレインストーミングでやります。
• ブレインストーミングで大事な事は、あま
り深く考えずに、如何に数多くの案を出す
かです。
• 各自でやりたいと思うお題を付箋紙に書き
出して下さい。他の人と意見がダブっても
問題ありません。まずはドンドン書いてい
きましょう。

• まず今出して頂いた案を、同じ系統なもの
をまとめましょう。
• ではその中から一つ選び出しましょう。

• お題として決まった製作物の責任者を決め
たいと思います。アジャイル開発では「プ
ロダクトオーナー」と呼ばれる役割の人で
す。
• プロダクトオーナーは、通常は自社内の人
間または顧客の代表者が担当します。プロ
ダクトオーナーは製品に関する最終的な判
断を行う権限を持ちます。

4.プラグマティック・ペル
ソナワークショップ

4.プラグマティック・ペルソナ(1/7)
• ペルソナ法とは、アラン・クーパー氏の著
書『コンピュータは、むずかしすぎて使え
ない!』や『About Face 3 - インタラクショ
ンデザインの極意』等で紹介された要件定
義の手法です。
• http://www.amazon.co.jp/dp/488135826X
• http://www.amazon.co.jp/dp/4048672452
• 製品のユーザーを詳細な仮想ユーザー『ペ
ルソナ』として厳密に設定し、そのペルソ
ナをターゲットに分析を行う方法です。

• 一口に製品のユーザーといっても、年齢・
性別といったものや運用管理・利用者と
いった立場によって複数のアクターが存在
します。
• これらの複数のアクターについて、
• それぞれについて精査を行い
• そこから共通性を発見し
• 抽象化を行い
• 最も中心的となるペルソナを導出する
• これにより製品の方向性を決めます。

• ペルソナ法のフィードバックループ
1. ペルソナ法を利用して仮説を立て
2. それを元に製品開発を行い
3. 顧客に製品をデリバリーし
4. また１に戻る
• このフィードバックループを繰り返す事に
より、製品を作り込んだり完成度や理解度
を高めていき、不確実なものを確実にして
いくやり方です。

• プラグマティック・ペルソナ
• ペルソナ法には色々なやり方がありますが、
プラグマティック・ペルソナは、チームメ
ンバーのユーザーイメージを元に(厳密な
データ取り等は行わない)仮説を立てて、
短時間で検証・確認・軌道修正していくや
り方です。
• 用紙に、ペルソナの名前、顔のイラスト、
属性、行動特性(コンテキスト) 、プロダク
トの価値を書きましょう。

先程選んだお題で実際にやってみましょう。
• 一番上：名前(年齢、性別も)
• 左上：顔のイラスト
• 右上：属性(about)
• ペルソナの個人情報・特徴
• 左下：行動特性(コンテキスト)
• プロダクトをどう使うか、困り事等。
• 右下：プロダクトの価値
• 製品にどんな価値があると嬉しいか

名前、年齢、性別

属性
顔のイラスト
(about)
(´・ω・`)
ペルソナの個人情報・特徴

行動特性
プロダクトの価値
(コンテキスト)
製品にどんな価値があると嬉し
プロダクトをどう使うか
いか
プロダクトで解決したい困り事

• 出来上がったペルソナについて、テーブル
内で一人ずつ順番に紹介して下さい。
• そして各テーブルでこの人の為に製品を作
るという人を選び出して下さい。ここで選
んだペルソナが以降のワークショップでの
指針・指標となります。
• プロダクトのゴールは、ここで選んだペル
ソナが代弁していますか？実際のプロジェ
クトではチームの意識はこのペルソナを満
足させる方向に向かって行きます。

5.プロダクトバックログ
作成ワークショップ

5.プロダクトバックログ作成(1/13)
• プロダクトバックログとは、いわゆるToDoリス
トの事。
• 単なるToDoリストと異なる点は、
• プロダクトオーナーが管理する。
• チームとしてプロダクトで顧客への価値を生
み出す為のユーザーストーリー(後述)を集め
たもの。
• リスト内容のユーザーストーリーは優先順位
付けされる。
• プロダクトバッグログは、イテレーション(スプ
リント)事に内容の見直しや棚卸しを行う。

• ユーザーストーリーは、通常インデックス
カードという付箋紙大のメッセージカード1
枚につき１つのストーリーを記述して管理
します。
• 記述例
• オンラインショップの利用者として、ブラ
ウザで商品の注文を行いたい。
• オンラインショップの利用者として、商品
カートの内容を編集したい。

• ユーザーストーリーの記述内容は、
• 顧客視点で、顧客への価値を提供する内容
を書く。
• 主語と述語をはっきり書く。誰が何をどう
やってどうするのか。
• あまり細かく書かない。バックログの時点
では不要な情報は邪魔になる。見積に必要
な情報を記述する。
• 機能縦断的にストーリーを書く。
• 裏書きにそのストーリーのゴール・完了条
件を記述する場合もあります。

ユーザーストーリー作成時の６ポイント
• INVEST(頭文字を取って)
• Independent (独立性がある)
• Negotiable (交渉の余地がある)
• Valuable (価値がある)
• Estimable (見積り可能)
• Small (サイズが小さい)
• Testable (テスト可能)
• End to End(機能縦断的)での確認。

では早速、ユーザーストーリーの作成を行っ
てみましょう。
ユーザーストーリーの作成は、ブレインス
トーミングで行います。選んだお題につい
て必要となるフィーチャーについて、１付
箋紙に1ストーリーで記述を行っていきま
しょう。
ブレインストーミングの目的は数です。先の
ルール(記述方法、６つのポイント)を守りつ
つ沢山のユーザーストーリーを書いていき
ましょう。

ユーザーストーリーの洗い出しが出来たら、
次はユーザーストーリーのカテゴリ分けを
行います。
同じ系統のストーリーに分類しましょう。同
じ内容のものは付箋紙を重ねてまとめま
しょう。

• ユーザーストーリーの洗い出しが完了した
ら、次は、そのストーリー群の優先順位付
けを行います。
• プロダクトオーナーが中心となって、どの
作業から取り組むべきか相談し、付箋紙を
上から順に並べ替えて下さい。
• 並べ替えにおいて、優先順位が同列となる
ものは設定しないようにして下さい。必ず
一意になるようにして下さい。

• プロダクトバックログ時点において、全体
の作業量を大まかに把握する為にユーザー
ストーリーの見積を行います。
• プロダクトバックログのユーザーストー
リーの見積は、プロダクトオーナーとチー
ムメンバーで行います。

• ユーザーストーリーの作業見積では、相対
見積で見積を行います。
• 相対見積を利用するのは、厳密な見積は必
要ないが、それでもある程度の精度を確保
する為です。
• 一般的に、見積において10倍を超える規模
の差が出ると、見積の精度が悪くなります。

• 相対的な作業見積で利用するのがプランニ
ングポーカーです。
• ポーカーと名前が付いていますが、揃える
のは自分の手札ではなく、チーム全体の手
札を同じ値になるようにするワークショッ
プです。

• プランニングポーカーは、フィボナッチ数
の値になっています。1・2・3・5・8・13・
20・40・・・。
• それ以外に、自分の意思表示を行う目的の
カードがあります。
• ?,∞：見積もれない・判断できない
• 0：作業としては発生するが別計上だった
り、本当に作業量しては些細なもの。
• ポーカーの値がそのままストーリーポイン
トです。ポイント２に対して、ポイント5の
作業量は2.5倍の規模がある事を示します。

• プランニングポーカーの進め方
1. 各ストーリーにどのようなタスクが含まれ
るか話し合って、コンテキスト合わせ。
2. 基準(3ポイント)となるストーリーを決める。
3. 各自がそのタスクが「ストーリーポイン
ト」幾つになるかを考えてカードを出す
4. 大きくずれてたら、なぜそうしたかなどを
両端の人に聞いたりして調整、見積の視点
についてコンテキスト合わせ。
5. ポイント確定
6. 全部終わったら今回のイテレーションでど
こまでを消化するか予定を決める。
• 実際にやってみましょう。

• プランニングポーカーで見積もったポイン
トがチームの開発速度の指標になります。
• これがベロシティと呼ばれます。ベロシ
ティは、チームがあるイテレーションで完
成させたユーザーストーリーのポイント数
の合計になります。
• ベロシティはチームのメンバーの変更に
よって値が変わる為、チームメンバーの変
更は行われない事が前提です。

6.タスク分割
ワークショップ

6.タスク分割(1/3)
• イテレーションを始めるにあたっては、ま
ずプロダクトバックログから、今回のイテ
レーションで行う作業(スプリントバックロ
グ、イテレーションバックログ)を作成しま
す。
• このスプリントバックログの作成はチーム
メンバーで行います。
• 各ストーリーについてタスクを洗い出し、
各タスクについて、理想日による見積(実際
の作業時間での計上)を行います。

• タスクの作業見積でもプランニングポー
カーを使ったりします。
• イテレーション中にプロダクトオーナーは、
状況を見てプロダクトバックログの見直し
を行ったりします。プロダクトバックログ
に上げたものも確定ではなく流動的なもの
です。
• アジャイル開発の肝は流動的である事です。
従来のやり方では、すべき事を先に固定化
する事で作業に集中させますが、そのすべ
き事に変更が入ると問題になっていました。

• アジャイル開発で良く紹介されているタス
クボードは、このタスク作業の進捗状況を
視覚化するものです。
• タスクボードのタスクカードもユーザース
トーリーのインデックスカードと同様の記
述方法を行います。

ユーザーストーリーワークショップ

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to ユーザーストーリーワークショップ

Similar to ユーザーストーリーワークショップ (20)

Recently uploaded

Recently uploaded (8)

ユーザーストーリーワークショップ