ユーザーストーリー駆動開発で行こう。

Toshihiro Ichitani All Rights Reserved.
ユーザーストーリー
駆動開発で行こう。
Ichitani Toshihiro
市谷聡啓
開発を始める前にみんなで理解しておきたい
ユーザーストーリーを用いた開発のお作法

http://about.me/papanda0806
Ichitani Toshihiro
市谷聡啓
@papanda

受託→SIer→サービス→受託→旗揚
関西で組み込み製品のプログラマー→
プロダクトオーナー(企画者)支援
アジャイル開発プロジェクトマネージャ
アジャイル開発コンサルタント
ここまでのあらすじ
「リーン開発の現場」

Copyright (c) 2014 Guild Works Inc.
ユーザーストーリーという言葉は
よく聞くか、たまには聞くかと思いますが
どうですか？

どうですか？
「実際にユーザーストーリーでは開発したことない」
「開発してたけど上手くいかなかった…」
「何が良いのか分からない…」

どうですか？
「実際にユーザーストーリーでは開発したことない」
「開発してたけど上手くいかなかった…」
「何が良いのか分からない…」
気持ちは分かります！
この時間では、ユーザーストーリーを使った
開発の進め方について紹介したいと思います。

そもそも何が課題なの？
ユーザーストーリーを使う！ってことから事を
始めだすとあまり良い結果は期待できかもですね。
ソリューションありきではなくて、何が課題で
適用するのかから考えましょう。
扱う課題は
「何をつくるべきかをどのようにして、関係者の
間で伝え合えば良いか？」ということです。
作ってみて「コレジャナイ」なんてことになった
のは、一度や二度ではないでしょう。

どうやって解決していますか？
扱う課題は

扱う課題は
ドキュメントをゴリゴリと書いて、
書いたらチームにレビューしてもらって…
関係者に確認してもらって…
そうですね、だいたいそうしてきてますよね。

扱う課題は
ドキュメントをゴリゴリと書いて、
書いたらチームにレビューしてもらって…
関係者に確認してもらって…
そうですね、だいたいそうしてきてますよね。
でも、ちょっと大変ですよね。

動くモノを作ってしまって
関係者に確認してもらえれば
良いんじゃないの。

良いね！それが出来たらベストだね！
ただ、その作戦で行く場合気をつけて欲しいことが
あるんだ…

良いね！それが出来たらベストだね！
ただ、その作戦で行く場合気をつけて欲しいことが
あるんだ…
ワークに必要なコスト + 結果認識違いを訂正するコスト
取れる作戦の間でこのコストの比較を
見立ておこう。

動くモノを
作るコスト
認識違いを
訂正するコスト
ドキュメントを
書くコスト
認識違いを
＋＋？
チームとクライアントの状況と作るプロダクトの内容から
どちらの作戦が有利かトータルのコストで判断する

動くモノを
作るコスト
認識違いを
書くコスト
認識違いを
＋＋
？
さらに、ここに動くモノならではの「発見の可能性」と
ドキュメントならではの「見落としの可能性」を加味する
➖
早期に要求を発見
出来る嬉しさ
要求を見落した
ことによる手戻り
＋

動くモノを
作るコスト
認識違いを
書くコスト
認識違いを
＋＋
＜
チーム、クライアント、作るプロダクトを踏まえて、
動くモノでの検証の方が有利ならば動くモノ作戦は有効だ！
➖
出来る嬉しさ
＋
＋

動くモノを
作るコスト
認識違いを
書くコスト
認識違いを
＋＋
＜
動くモノを作るのに相当なコストを要のであれば、または
要求を「発見できる可能性が低い」ならば常に動くモノ作戦が
コスト的に有利なわけではない。
➖
出来る嬉しさ
＋

クライアントの状況によっては、
「認識違いを訂正するコストが大きくなる可能性」
もあるんだ。作るモノへのイメージがクライアント
の中にだけある場合とかね。
そうなると、本当に動くモノベースでいきなり検証
するのが効率的なのかってなる。
じゃあ、やっぱりドキュメント？まずは
ドキュメントの場合何が大変なのか整理してみよう。

ドキュメントによる要件定義の課題
大量の文章や図表を書くコストがとてもかかる。
更新するのにコストがとてもかかる。
※仮説検証的に進めるプロジェクトだと変更が多すぎて手に負えない。
文章ですべてを表現することはできない。
※それはもうコードだ。
書いている方は漸次的だが読む方のバッチサイズ
は大きくなりがちで全体像を理解し難くなる
読み手の読解力に依存するため、憶測や誤解が
生じやすい。会話で文脈の補完が必要になる。
全体を理解しづらいので計画を立てるのも難しい。
そして、誰も見なくなる。

大変すぎる！

大変すぎる！
そこで、ユーザーストーリーですよ。

大変すぎる！
そこで、ユーザーストーリーですよ。
というと、万能的に聞こえちゃうから、急いで
補完するとドキュメントを書かなくて良いという
わけではないのだよ。
ユーザーストーリーはユーザーがやりたいことを
簡潔にまとめつつ、詳細を補完するためにその後
の会話を約束するための道具なんだ。

ユーザーストーリーはドキュメント
なのか？
分かりやすいので、つい要件定義書と比較して
しまいがちなのだけど、ユーザーストーリーは
ドキュメントと思わない方が良い。
要求をまとめるやり方の選択肢が1つ増えたと
捉えた方が良いんじゃないかな。
作って欲しい人と
隣同士で逐次会話
しながら作る
ドキュメントで
つくりたいものを
定義してから作る
ユーザー
ストーリーで
駆動する開発
どのやり方が絶対的にダメって話じゃない。状況に応じて使い分けよう。

では、ユーザーストーリーとは
どういうものなのか、具体的に
みていくことにしよう。

どう書くの？三段構成
＜ユーザー／顧客＞として
＜XXXを達成＞をしたい
なぜなら＜理由＞だからだ
<Who>として
<What>をしたい
なぜなら <Why>だから
別の表現としては
ユーザーストーリーとは？
<30代の求職者>として
<年収で仕事を探>したい
なぜなら<仕事選びで年収の優先度が
高い>だから
たとえば
とも言える。
という感じで書く。

ユーザーストーリーには
Howを書かないんだね。

ユーザーストーリーには
Howを書かないんだね。
そうだね。
ユーザー(Who)の望みは、理由(Why)から出てきて
いるんだ。Whyを実現する手段(How)はむしろ、
開発チームが腕を振るうところだ。
例えばさっきの例「年収で仕事を検索したい」
そのために検索エンジンを使うのか、SQLで直接
頑張るのか、どんな手段を取るかは求職者にとっては
関係ないよね。もちろん手段選択による実害があったら困るよ。

対象者にとって、理解できる・評価できる内容に
なっていること！=対象者にとって価値がある
…それって機能のこと？

対象者にとって、理解できる・評価できる内容に
なっていること！=対象者にとって価値がある
…それって機能のこと？
ユーザーストーリーは機能ではない。
対象者にとっての価値をあらわすものなんだ。
その価値をもたらすための手段が機能になる。
機能に始まり、機能で終わると、目的を見失う可能性
が高くなる。機能をただつくることが目的ではないよ。
目的は対象者に価値をもたらすこと。利用者に価値を
届けるソフトウェアを作ることが僕達の仕事だ。

ユーザーにとって理解できること…
それって、どんな文章なの？

ユーザーが理解できる言葉を用いる必要があるね。
ただ、あいまいな文章にしてもダメだ。どうなれば
そのストーリーが出来たと言えるのか判断できない
からね。

ユーザーが理解できる言葉を用いる必要があるね。
ただ、あいまいな文章にしてもダメだ。どうなれば
そのストーリーが出来たと言えるのか判断できない
からね。
「完成の条件」が言えないとダメだ。
「何が出来ないければいけないのか」の定義だね。
これがはっきりしないようなら、ストーリーとして
まだ、練り込みが甘いってことだ。

ねえ、ストーリーを書きだしていると
30も40にもなって、何が何だか
わからなくなってきたよ！

ユーザーのやりたいこと構造的に捉えるために、
エピックとストーリーを使い分けよう。

ユーザーのやりたいこと構造的に捉えるために、
エピックとストーリーを使い分けよう。
特に、開発の初期段階ではやりたいことがまだ
もやっとしていることがよくある。最初から答えが分
かっているなんてことはあまりない。
エピックというのはやりたいことを大きな粒度で
捉えるためのものだ。

エピックとストーリーの例
<求人を検索>したい
なぜなら<自分にあった求人に応募し
たい>だから
<採用企業に問い合わせ>したい
なぜなら<求人内容についてより深く
聞きたい>だから
<求人に応募>したい
なぜなら<選考をすすめたい>だから
ユーザーは求人に応募
することができる
エピック
ストーリー
やりたいことは初めはエピックレベルかもしれない
だから関係者と会話して詳しくしていくんだ。

よし、いっぱいストーリーが書けた。
さあ、つくるぞー！

ちょっとまった。最初に言ったことを思い出そう。
簡潔にまとめつつ、詳細を補完するためにその後の
会話を約束するための道具なんだ。

ちょっとまった。最初に言ったことを思い出そう。
簡潔にまとめつつ、詳細を補完するためにその後の
会話を約束するための道具なんだ。
関係者との会話は十分にできているかな？
ストーリーだけ書いて作れるほど、おそらく甘く
はないよ。

でも、ユーザーストーリーを書けば
他のドキュメントはいらないんでしょ

でも、ユーザーストーリーを書けば
他のドキュメントはいらないんでしょ
例えば、何らかのビジネス・ルールがあるとして
抜け漏れがないかどうやって、確認する？
UIのイメージは関係者とあっている？イメージを
すりあわせるためにラフなスケッチくらいは
書かないといけないんじゃない？
目的に応じて、その手段を検討するべきだ。

わかった。では、ストーリーとしては
どういうのがよく書けていると言えるの？

完成の条件が言えるストーリーというのが良い
ストーリーの条件と言えるね。
他にもいくつか特徴があるんだ。次の6つだ。
I ‒ Independent (独立して優先順位がつけられる)
N ‒ Negotiable (何をつくるかの案が調整可能である)
V ‒ Valuable (価値のある)
E ‒ Estimable (見積り可能である)
S ‒ Small (チームで扱いやすい手頃なサイズである)
T ‒ Testable (テストできる)
頭文字をとってINVESTと呼ぶよ。
わかった。では、ストーリーとしては
どういうのがよく書けていると言えるの？

独立して優先順位がつけられる
ストーリーの間で強い依存関係があると
スコープが調整しづらくなるし、完成の状態が
あいまいになってしまうね。このストーリーは
完成しているように実はあっちのストーリーが
終わらないと終わりにはならない…とかね。

何をつくるかの案が調整可能である
やりたいことを実現する手段(How)が調整可能
でなければ、相当しっかりと計画を組み立てる
ことが求められているのと同じことになる。
最初に言ったとおり、Whyを実現するための
一番良いところのHowはチームから提示しよう

価値のある
これはもう説明がいらないかな。僕達の目的はユー
ザーに価値をもたらすソフトウェアを作ることだ。
一つ一つのストーリーがユーザーにとって価値を
もたらすものになっていなければそれを積み重ね
ても目的にはたどり着けない。おそらく関係者が
理解できる内容にもなっていないだろう。

見積可能である
見積ができるということは、やりたいことへの
実現手段がはっきりとしているということだ。
逆にまだ見積ができないなら、関係者との会話が
不足していそうだ。

チームで扱いやすい手頃なサイズである
ストーリーを小さくできると、見積がしやすくな
る。何日もかかるような壮大なストーリーは見積
もったところで凄くブレが生まれる可能性が高い
よね。それに小さくないと１回のイテレーション
の中で終わらなくなっちゃうからね。

テストできる
テストができるようになっているということは、
ソフトウェアがどう動けば良いか分かっている
ということだ。つまり、完成の条件が明確に
なっているということだね。

ストーリーはオブジェクトに似ている
高凝集
!
!
疎結合
1つのストーリーには必ず1つの価値がある
十分に小さいこと
ストーリーは可能な限り独立していること
単体で完成することができる
高凝集、疎結合でなければ、ユーザーストーリーだけでは
プロダクトとプロジェクトの状況を把握するのが難しい

実は、ストーリーが足りてない
気がするんだ…

ユーザーストーリーはやりたいことを簡潔に
まとめるための道具だ。
ストーリーを洗い出すための手法は別
に必要だ。
いろいろなやり方があるよ。やり方は1つでは
ない。いろいろと試してみよう。
実は、ストーリーが足りてない
気がするんだ…

やりたいことを洗い出す
さまざまな手段が取れるし、組み合せよう。
・ペルソナ
・インセプションデッキ
・UIイメージのスケッチ
・ドメインモデル
・ユーザーの要望、インタビュー結果
そして、ユーザーストーリーマッピングも。

54
ユーザーストーリーマッピング
ユーザーストーリーマッピングとは、時系列にユーザー行動を洗い出し、
行動に基づいて要求を見立てる手法。
関係者が集まり、付箋や模造紙を用いてワークショップ形式で行なう。
参加者の知見を活かして、要求を発見・洗い出す。また、優先度付けを行
うことでスコープ(範囲)を短時間で特定することもできる。
ユーザーストーリーマッピングのイメージ

時
系
列
定
点
感情ベース行動ベース
ユーザーのインサイトに踏み込むための道具
エクスペリエンスマップユーザーストーリーマッピング
共感マップ
http://www.amazon.co.jp/gp/product/toc/4621088068/

ユーザーストーリーで開発を駆動する
ユーザーストーリーだと、やりたいことの全体像を
捉えやすくなる(重厚なドキュメントだとまず
読み込むだけで相当なコストがかかる)。
全体像が捉えられると、計画が立て
やすくなる。
全体として何をやらなければならないかの把握が
しやすくなるからね。
そして、ユーザーストーリーが中心の開発だと
ユーザーストーリーの開発状況を押さえることで
プロジェクト全体の状況も理解できるようになるんだ

では、ユーザーストーリーを
つかった開発の流れを具体的に
追ってみることにしよう。
!
※この例ではPivotalTrackerを使うよ
https://www.pivotaltracker.com/

①ユーザーストーリーを洗い出す

②洗い出したストーリーをPivotalに登録する
ひとまずiceboxに登録する。
登録したら関係者でiceboxを
眺めて抜け漏れをチェックしよう
!
ラベルをつけて管理しやすく
しよう。Pivotalだとラベルを
エピックにしてエピックとして
ストーリーをまとめて管理する
こともできる。
!
Whyまで書くと長くなるので
descriptionに書くと良い

③ストーリーの完成の条件を定義しよう
何ができればこのストーリーは
終わるのか？条件が定義できるまで
関係者と話し合う。
内容は、descriptionに書いておく
!
開発が進む中で新たに分かった
ことが出てくればdescriptionに
残していく

④ストーリーをチームで見積もろう
各ストーリーの規模をチームで
見積もる。POINTSに見積った
ポイントを入れていく。
※ポイントの単位は設定で変えられる
!
見積りはプランニングポーカーが
わかりやすくて手軽でオススメ
※やり方は書籍「リーン開発の現場」に詳しい
!
相対的に見積もる。基準となる
ストーリーを決めて、それの
何倍くらいの規模になるかを
みたてる

⑤ストーリーの順序付けを行なう
iceboxからbacklogレーンに
持って行き順序付けする
関係者といっしょにやろう
!
チームのベロシティに基づき
どのストーリーがどこの
イテレーションになるかは自動的
に決まる
※チームのベロシティは倒したポイントの
実績値で決まる。初期ベロシティは設定から
変更できる。これまでいっしょにやってきた
チームなら過去のプロジェクトのベロシティ
を一旦参考にしても良し。

⑥プロジェクト開始！
イテレーションの計画ミーティングとイテレーションレビュー
のタイミングを決めておこう。
!
計画ミーティング … そのイテレーションでどのストーリーを対象に
するか決める
必要に応じて作れるようにするために、
更にストーリーを詳しく理解する
イテレーションレビュー … 開発したストーリーを動くモノにて関係者で
確認する
!
例えば毎週金曜日はイテレーションレビューを実施してから
次のイテレーションの計画ミーティングも行なう、といったよ
うに。

⑦着手するストーリーを決めて開発を始める。
担当するストーリーの
Startボタンを押すと
Finishに変わる。
!
開発を終えたときにFinish
を押そう。ボタンはDeliver
になる
!
デモ環境に対象ストーリーを
上げたらDeliverボタンを
押す。AcceptとRejectの
ボタンが表示される

⑧イテレーションレビューで完成を判断する
イテレーションレビューで関係者に対象ストーリーを
デモ環境で動かしながら確認してもらおう
完成しているならばAccept、まだ完成の条件を達成
していないならばReject。Rejectはストーリーとして
残り続ける。
!
計画ミーティングで次の開発対象を確認しよう。
ストーリーが積み残っていくと、すべてのストーリーが
完成する着地点が変わっていくことになる
※Pivotalのバーンダウンチャートで適宜確認し、必要な手を打つ
!
このサイクルを繰り返していく！

最後にまとめておこう
ユーザーストーリーとは、
・やりたいことをまとめる手段であり、
計画を立てるための材料であり、
実績を測るための対象である。
・ユーザーストーリーとは
「プロジェクトの中心にあって(無くてはならない)
開発を駆動する手段であり(すべてストーリーから始まる)
目標になる存在である(ストーリーが完了しないと終わらない)」
すべてはストーリーから始まる！

ユーザーストーリー駆動開発で行こう。

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ユーザーストーリー駆動開発で行こう。

Similaire à ユーザーストーリー駆動開発で行こう。 (20)

Plus de GuildWorks

Plus de GuildWorks (15)

ユーザーストーリー駆動開発で行こう。