アジャイルプラクティス ユーザーストーリー

Yasuyuki Fujikawa

アジェンダ• （要件の）文書化の難しさ

• そこでユーザーストーリーですよ

• よく書けているユーザーストーリーとは？

• ワークショップ開催！

（要件の）文書化の難しさ

（要件の）文書化の難しさ

顧客は自分たちの欲しいものを 手に入れることはほとんどない。

（要件の）文書化の難しさ

開発チームは求められたものを 構築しきれない。

（要件の）文書化の難しさ

ものすごい時間とエネルギーが 文書化のために費やされる。

• 何を成し遂げるべきか話し合うためじゃない。• 何を文書に書くべきかを話しあうことに費やされる。

（要件の）文書化の難しさ

文書に頼りすぎることの 弊害は、他にもある。

• 変化に対処できない。 • 顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる。

• 下手な推測や誤った前提を招き寄せる。 • 多くの時間を無駄にする

（要件の）文書化の難しさ

アジャイル開発の原則情報を伝えるもっとも効率的で効果的な方法

フェイス・トゥ・フェイス で話すことです。

そこでユーザーストーリーですよ

インデックスカード（情報カード）

そこでユーザーストーリーですよ

そこでユーザーストーリーですよ

• 簡潔にしか記述しない • 詳細は顧客のところへ出向いてじかに会話することを促進する

そこでユーザーストーリーですよ

要求を事細かに聞き出さないのはなぜ？

そこでユーザーストーリーですよ

要件を思いついたばかりの時点ではそれが本当に必要になるかどうかはわからない。

そこでユーザーストーリーですよ

その要件を実装するのは何ヶ月も後かもしれない。きっとその頃にはいろいろと変わっているはず。

そこでユーザーストーリーですよ

検討する時間とエネルギーを節約しておく。ほんとうに必要になったらそのときに一度、

詳細に突っ込んで取り組めるようにしておけばいい。

そこでユーザーストーリーですよ

ユーザーストーリーを「会話の約束」だと考えよう。

そこでユーザーストーリーですよ

しかるべき時が来たら詳細に検討するが、 それが本当に必要だという核心を持てるようになってからの話。

よく書けているユーザーストーリーとは？

よく書けているユーザーストーリーとは？

1. 顧客にとって何かしらの価値が書かれていること。

2. エンドツーエンドになっていること。

3. 独立していること。

4. 交渉の余地がある。

5. テストできる。

6. 小さい、見積もれる。

よく書けているユーザーストーリーとは？

1. 顧客にとって何かしらの価値が書かれていること。

　　→自分のお客さんが対価を払ってもいいと

　　　思えるものが価値。

　　→ユーザーストーリーはビジネスの

　　　観点から評価出来なければダメ。

　　→お客さんに理解できるシンプルな言葉づかいで

　　　ユーザーストーリーを書く

よく書けているユーザーストーリーとは？

2. エンドツーエンドになっていること。

　　→ユーザーインターフェース、

　　　ビジネスロジック層、永続化層となっていること。

よく書けているユーザーストーリーとは？

3. 独立していること。

　　→プロジェクトには変化がつきもの。

　　　ユーザーストーリーがお互いに密接に

　　　絡みあっていたとしたら、

　　　トレードオフを判断するのも難しくなる。

よく書けているユーザーストーリーとは？

4. 交渉の余地がある。

　　→ストーリーの実現方法は様々である。

　　　ものすごく高機能にできたり、

　　　簡単にすることだったできる。

　　　予算の範囲内に収まるように、ある程度

　　　融通が利くようにできる

よく書けているユーザーストーリーとは？

5. テストできる。

　　→ユーザーストーリーのテストを書くことで、

　　　開発チームにとっては、作業時間と

　　　仕事の完了基準が明確になる効果もある。

よく書けているユーザーストーリーとは？

6. 小さい、見積もれる。

　　→ストーリーを小さく（1～5日で完了できる

　　　サイズに）しておけば、１週間や２週間と

　　　いったイテレーションの範囲に

　　　収まりそうか確実にわかる。

よく書けているユーザーストーリーとは？

1. 独立している（Independent）

2. 交渉の余地がある（Negotiable）

3. 価値のある（Valuable）

4. 見積もれる（Estimable）

5. 小さい（Small）

6. テストできる（Testale）

先の6つの要素を表す、便利な略語はINVESTと呼ぶ。

よく書けているユーザーストーリーとは？

要求の収集をユーザーストーリーでやる場合と文書でやる場合で比較を行う。

ユーザーストーリー 要件定義書と仕様書

無駄がない、正確、必要な分を必要なときに 重厚、不正確、最新じゃない

対面でのコミュニケーションを促す 憶測や誤った前提を招き寄せる

計画がシンプルになる 計画が複雑になる

低コスト、素早い、手軽 コストがかさむ、遅い、時間がかかる

最新の情報が反映されている 情報が古くなったまま放置される

チームが学習するということを踏まえている チームが学習するということを考慮しない

フィードバックを即時反映できる フィードバックを即時反映できない

見積り制度の高低を当てにしない さも見積もり制度が高いかのように取り繕う

チームの協調作業や新しい取り込みを歓迎する オープンな協調作業や新しい取り組みを 歓迎しない

ワークショップ開催！

やあ、優秀なエンジニア諸君

君たちに折り入って 頼みがあるんだ。

実は、いいビジネスを思いついて Webサイトを作ろうと思っているんだ。

リアルタイムでわかる 図書館のシステムを作ろうと思う。

具体的にやりたいことは こんな感じだ。

あ、助手のFくん 諸君に説明を頼むよ。

私は忙しいからね！はっはは！！

まず、公共の図書館のホームページと一線をなす ウェブサイトにしてほしいね。老若男女問わず見やすい ホームページがいい。あ、サイトの表示も早くないといけないな。昔、依頼したところが遅いものを作ったんだよね。 !そーだなぁ・・・うちのサイトを見れば、本の保有数や貸出の状況、置いてある場所がすぐわかるようにしたいね。 !あ、会員登録をしてもらって会員の好みや動向を 知りたいね。データなんとかって最近流行ってるんだろう？ あれをやりたいね。 !おっと、後、図書館でイベントもやりたいから イベントの登録やイベントの告知、ホームページに 表示できるようにもしたいね。告知の内容？まだ決めてないよ。 !忘れてた！もうガラケーの時代は終わって、今の時代に合う素晴らしいスマホサイトも作りたいね。スマホからも貸出情報やイベントの確認、会員登録もできるようにしたいね。

<ユーザーの種類>として <達成したいゴール>をしたい なぜなら<理由>だからだ

ユーザーストーリーのテンプレート

「誰の」ためのストーリーで 「何を」したいのか 「なぜ」そうしたいのか

参考文献

次回

工数ってなに・・・？

見積りってKKDでしょ？

OK, OK

みんなで見積もろう。

ポーカーやります。

To be continued…