/**第三部**

# 第6章 アジャイルな計画づくり

---

## 6.1 ユーザーストーリーを集める

### 文書化の難しさ

#### 文書に頼りすぎることの弊害

- 変化に対処できない
- 顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる
- 下手な推測や間違った前提を招き寄せる
- 多くの時間を無駄にする

### ~~もっと文書を増やしたらいいんじゃない？~~

**問題の本質は文章量じゃなくてコミュニケーションの問題**

- 私は彼女がお金を盗んだとは言ってない。
- **私は**、彼女がお金を盗んだとは言ってない。→私は言っていない
- 私は彼女がお金を盗んだ、**とは**言っていない。→他のことなら言ったかも…
- 私は、**彼女が**お金を盗んだとは言っていない。→他の誰かが盗んだのかも
- 私は彼女がお金を、**盗んだ**とは言っていない。→ただ使っただけかも
- 私は彼女が、**お金を**盗んだとは言っていない。→そう。彼女が盗んだのは…私の心です。

> **アジャイル開発の原則**
>
> **情報を伝える最も効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです**

---

### コラム「その要件はほんとに『必要条件』なの？」

要件とは？

辞書では → 必要条件、必須のもの

要件という用語が間違っている。

要件定義書の20%程度の機能を顧客に届ければ、実はそれがシステム全体で想定していたビジネスの利益の殆どを提供していることに気づく。

じゃぁ他の80%の"要件"は？

要件じゃない → 必須でも必要条件でもない

---

自分たちに必要なもの → **顧客が本当に欲しいと思っているものはなんなのか**

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

ユーザーストーリーとは　→ 顧客がソフトウェアで実現したいと思っているフィーチャを完結に記述したもの

- ユーザーストーリーはインデックスカードに書く
- インデックスカードにはキーワードのみ書き留めておく

## 6.3 よくかけているユーザーストーリーとは

### どっちのレストランで食事したいと思うだろうか。

> **アーニーのテックデザイナー**
>
> - C++ ...3日
> - システムをC++で実装する。
> - コネクションプーリング...2日
> - 全てのデータベース接続はコネクションプール経由で行う。
> - MVCパターン...5日
> - システムはビジネスロジックとプレゼンテーションロジックを分離する。

> **サムのビジネスパンケーキハウス**
>
> - ユーザーアカウントを作成する...3日
> - ユーザーは、システムにログインするために個人ごとにパーソナライズされたアカウントを使う。
> - 新規物件が投稿されたらメーリングリストに通知される...2日
> - マーケットに新しい物件が登録されたらメーリングリストに通知される。
> - メーリングリストの購読を停止できる...1日
> - メーリングリストに投稿されるメールには必ず購読停止のリンクを埋めておく

- 顧客にとって何かしらの価値が書かれている
- ユーザーストーリーはビジネスの観点から評価できなきゃいけない
- 顧客に理解できるシンプルな言葉遣い
- エンドツーエンドになっている
- 入口から出口までしっかり書かれている

### よくかけているユーザーストーリーの6つの特徴

- ストーリーが独立している
- プロジェクトの変化に対応できるように、一つ一つのストーリーをなるべく独立させておく
- モジュール化に似ている(？)
- 交渉の余地がある
- 予算内に収まるよう、ある程度の融通が効くように
- テストできる
- テストをちゃんと組み込んでおく
- 作業範囲と仕事の完了基準が明確化される
- ゴールが明確になる
- 小さい、見積もれる
- 各ストーリーを小さくすることで(1~5日以内とか)、イテレーションの範囲でできるかどうか判断できる。
- そのくらいのサイズであれば見積もれる

### 実際にユーザーストーリーを書いてみる

#### ビッグウェイブ・デイブのサーフィンショップへようこそ

> 顧客の代わりにストーリーを書いたって構わない

重要なのは、顧客が積極的に要求収集のプロセスに参加してくれていることと、彼らが求めているものをちゃんと理解し、カードに書かれていること。

##### デイブのニーズを探る

ストーリーを書いてみる

- 次回のセール品一覧
- 地元のサーフィン大会の結果の掲載
- 今後のイベントやサーフィン大会の一覧
- ウェブカメラでビーチの様子を配信する
- サーフィンレッスンとその料金を表示する
- 中古のボードや装備の販売コーナー
- ウェブサイトはサクサク表示して
- デザインはまじかっこよく！

最後の2つは漠然としている。→何がゴールなのか

- ウェブサイトはサクサク表示して→サイトのページはどれも2秒以内に読み込めること

これだとテストができる。

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

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

## 6.4 ストーリー収集ワークショップを開催しよう

### ステップ1: 大きくて見通しの良い部屋を用意する

### ステップ２: 図をたくさん描く

- ペルソナ: 顧客像
- フローチャート
- シナリオ
- システム概要図
- プロセスフロー
- コンセプトデザイン
- 絵コンテ
- ペーパープロトタイプ
- オリジナルのなにか

### ステップ3: ユーザーストーリーをたくさん書く

ステップ2でできた色々な図から、ユーザーストーリーを抽出する

### ステップ4: その他諸々をブレインストーミング

### ステップ5: リストを磨き上げる

文書そのものが悪いわけではなく、いらない文書を作ることが問題

マスターストーリーリストを作るに当たり、文書を作ったほうが効率化が図れるのであれば使えばいい

重要なのは、どうするのが最も効率的な情報共有手段なのかということ