内容紹介
「ユーザストーリマッピング」提唱者による書き下ろし!
「ユーザストーリマッピング」は、Jeff Patton氏が提案する計画手法で、顧客の視点からサービスや商品の要件を記述することを特徴とします。XPを実践するためのプラクティスの一つで「ユーザストーリー」があり、これはワークショップ形式で機能を洗い出しながら、インデックスカードに記録して並べ替えていく手法です。
このような方におすすめ
・アジャイル開発、特にスクラムを開発に利用しているエンジニア
・ソフトウェア開発の要件定義に従事している方。特にユーザー調査、ユーザーエクスペリエンスにご興味がある人。ユーザー調査から要件定義までをどのように進めるのかを知りたい人
・通信工学系高等教育機関の教員および学生
目次
詳細目次
日本語版序文
マーティン・ファウラーによる序文
アラン・クーパーによる序文
マーティ・ ケーガンによる序文
まえがき
0章 まず最初に読んでください
0.1 伝言ゲーム
0.2 共通理解の構築は驚くほどシンプルな話だ
0.2.1 完璧なドキュメントを書こうとするのはやめよう
0.3 良いドキュメントはバケーションの写真のようなものだ
0.4 記憶を助けるためのドキュメント
0.5 正しいことについて話そう
0.6 現在と将来
0.7 大切なのはソフトウェアではない
0.8 大切なのは人だけではない
0.9 作るものを減らそう
0.10 恐ろしい「要」で始まる言葉についてさらに
0.11 要するにこれだけだ
1章 全体像
1.1 「ア」で始まる言葉
1.2 書くのではなくストーリーを語る
1.3 全体像を話す
1.4 ゲイリーとフラットバックログの悲劇
1.5 話して記録
1.6 アイデアの枠組みを作る
1.7 顧客とユーザーのイメージを描く
1.8 ユーザーのストーリーを話す
1.9 詳細部分と代替案を探索する
2章 作るものを減らすためのプラン
2.1 マッピングは大規模なグループが共通理解を築く上で役立つ
2.2 マッピングはストーリーの穴を見つけるのに役立つ
2.3 いつでも仕事は多すぎる
2.4 MVPリリースを切り出す
2.5 リリースロードマップを切り出す
2.6 機能ではなく成果で優先順位を付けよう
2.7 本当に魔法のようだ
2.8 私たちはなぜたびたびMVPを話題にするのか
2.9 新しいMVP定義は製品ではない
3章 より早く学ぶためのプラン
3.1 オポチュニティを議論するところから始めよう
3.2 問題の正しさをチェックする
3.3 学びのためのプロトタイプ
3.4 人々が何をほしいと言うかに注意しよう
3.5 学びのために作る
3.6 Viableになるまで繰り返す
3.7 間違った方法
3.8 検証された学習
3.9 実験の規模を最小限に抑える
3.10 復習しよう
4章 時間どおりに終わらせるためのプラン
4.1 チームにプランのことを話す
4.2 良い見積もりのための秘訣
4.3 少しずつ構築するためのプラン
4.4 スライスをいちいちリリースしない
4.5 良い見積もりのためのもうひとつの秘訣
4.6 予算を管理する
4.7 ダビンチならどうする?
4.8 イテレーティブにしてインクリメンタル
4.9 序盤、中盤、終盤の戦略
4.10 マップをスライスして開発戦略を生み出す
4.11 すべてはリスク対策
4.12 次は何?
5章 あなたはもうやり方を知っている
5.1 1度に1ステップずつストーリーを書き出そう
5.1.1 タスクは私たちがしていること
5.1.2 私のタスクはあなたのタスクとは違う
5.1.3 私はちょっと人より細かいだけで
5.2 ストーリーを整理する
5.2.1 見落とした細部を埋める
5.3 別のストーリーを探る
5.3.1 フローを整理し直す
5.4 マップからバックボーンを抽出する
5.5 特定の目標を実現しやすいようにタスクをスライスする
5.6 以上! あなたはすべての重要なコンセプトを学んだ
5.7 家で、または職場で本当に試そう
5.8 これは将来マップではなく現在マップだ
5.9 実際の仕事でやってみよう
5.10 ソフトウェアがからむと難しくなる
5.11 マップは手始めにすぎない
6章 ストーリーについての本当のストーリー
6.1 ケントのとてつもなくシンプルなアイデア
6.2 シンプルは簡単ではない
6.3 ロン・ジェフリーズの3つのC
6.3.1 カード
6.3.2 会話
6.3.3 確認
6.4 言葉と写真
6.5 これですべて
7章 より良いストーリーテリングのために
7.1 Connextraの優れたテンプレート
7.2 テンプレートゾンビとプルークボーゲン
7.3 リアルに迫るために何を話すべきかについてのチェックリスト
7.4 「バケーションの写真」を作ろう
7.5 心配しなければならないことはたくさんある
8章 カードに書かれていることがすべてではない
8.1 異なる人、異なる言い分
8.2 もっと大きなカードが必要だ
8.3 ラジエターとアイスボックス
8.4 ここはツールを使うべきときではない
8.4.1 共通理解を築く
8.4.2 思い出せるようにする
8.4.3 追跡する
9章 カードは始まりにすぎない
9.1 頭のなかに明確な見取り図を入れてソフトウェアを作る
9.2 ストーリーを語り継げるようにする
9.3 仕事の結果を点検する
9.4 これはあなたのためのものではない
9.5 学ぶために作る
9.6 ソフトウェアばかりとは限らない
9.7 学ぶためにプランを立て、プランを立てるために学ぶ
10章 ケーキのようにストーリーを焼く
10.1 レシピを作る
10.2 大きなケーキの分解
11章 岩を砕いていく
11.1 規模はいつも重要だ
11.2 ストーリーは岩に似ている
11.3 エピックは巨大な岩で、ときどき人にぶつけるために使われる
11.4 テーマがストーリーのグループを整理する
11.5 用語のことなど忘れてストーリーテリングに集中しよう
11.6 オポチュニティから始まる
11.7 MVSを見つける
11.8 デリバリーでは個々のストーリーの細部を詰めていく
11.9 作る間も会話を続ける
11.10 個々の部品を評価する
11.11 ユーザーおよび顧客とともに評価する
11.12 ビジネスステークホルダーとともに評価する
11.13 リリースして評価を続ける
12章 岩を砕く人
12.1 価値があって、使いやすく、実現可能な
12.2 ディスカバリーチームが成功するためには多くの他人が必要
12.3 スリーアミーゴス
12.4 プロデューサーとしてのプロダクトオーナー
12.5 これは込み入っている
13章 オポチュニティから始める
13.1 オポチュニティについての会話
13.2 深く掘り下げるか、ボツにするか、再考するか
13.3 オポチュニティという言葉は文字通りの意味でなければならない
13.4 ストーリーマッピングとオポチュニティ
13.5 選り好みをしよう
14章 ディスカバリーを介して共通理解を築く
14.1 ディスカバリーはソフトウェアの構築ではない
14.2 ディスカバリーの4つの基本ステップ
14.2.1 アイデアの枠組みを作る
14.2.2 顧客とユーザーを理解する
14.2.3 ソリューションのイメージを描く
14.2.4 最小化とプランニング
14.3 ディスカバリーの活動、議論、作成物
14.3.1 アイデアの枠組みを作る
14.3.2 顧客とユーザーを理解する
14.3.3 ソリューションのイメージを描く
14.3.4 最小化とプランニング
14.3.5 ディスカバリーの活動、議論、作成物
15章 ディスカバリーによる検証された学習(Validated Learning)
15.1 私たちはほとんどの場合間違っている
15.2 古き悪しき時代
15.3 共感、絞り込み、アイデア創出、プロトタイプ、テスト
15.4 良いものをめちゃくちゃにする方法
15.5 検証された学習の短いループ
15.6 リーンスタートアップ思考は製品設計をどのように変えるか
15.6.1 推測から始まる
15.7 リスクの高い仮定に名前を付ける
15.7.1 小さなテストを設計、構築する
15.7.2 顧客、ユーザーとともにテストを実行して測定する
15.8 ソリューションと仮説を考え直す
15.9 ストーリーとストーリーマップは?
16章 リファイン、定義、構築
16.1 カード、会話、さらにカード、さらに会話
16.2 切って磨く
16.3 ストーリーワークショップを行う
16.4 スプリント、イテレーションのプランニング?
16.5 烏合の衆はコラボレーションしない
16.6 分割とスリム化
16.7 デリバリーでストーリーマップを活用する
16.8 マップを使って進行状況を可視化する
16.9 ストーリーワークショップではシンプルなマップを使う
17章 ストーリーは実際にはアステロイドに似ている
17.1 砕いた岩を組み立て直す
17.2 マッピングをやりすぎないように
17.3 小さなものに無駄な労力を使わない
18章 構築するすべてのものから学ぶ
18.1 チームとしてのレビュー
18.2 社内の他の人々とのレビュー
18.3 十分とは何か
18.4 ユーザーから学ぶ
18.5 ユーザーに対するリリースから学ぶ
18.6 期限が来たときの成果
18.7 マップを使ってリリースの準備ができているか どうかを評価する
19章 終わり? それとも
謝辞
参考資料
監訳者あとがき
索引
続きを見る