ユーザーストーリーマッピング

ユーザーストーリーマッピング

ユーザーストーリーマッピングの表紙
ソフトウェア工学 / 設計
著者:
Jeff Patton / 川口恭伸 / 長尾高弘(ジェフ パットン / カワグチ ヤスノブ / ナガオ タカヒロ)
出版社:
オライリー・ジャパン
出版日:
2015年07月24日頃
ISBN:
9784873117324
在庫:
在庫あり
4.17(18 件 / 楽天ブックス)
中級者向け
ユーザーストーリーマッピングアジャイル開発エクストリームプログラミング (XP)要件定義ワークショッププロダクトマネジメントソフトウェア開発顧客視点計画手法インデックスカード

なぜ注目されているか

言及数
77位
総合184位 ↑ 10 ランクアップ 言及 40 件・うち記事 30 件を掲載
03620222023202420252026

書籍紹介

「ユーザストーリマッピング」提唱者による書き下ろし!
「ユーザストーリマッピング」は、Jeff Patton 氏が提案する計画手法で、顧客の視点からサービスや商品の要件を記述することを特徴とします。XP を実践するためのプラクティスの一つで「ユーザストーリー」があり、これはワークショップ形式で機能を洗い出しながら、インデックスカードに記録して並べ替えていく手法です。

技書の森解説

『ユーザーストーリーマッピング』 (Jeff Patton 著、川口 恭伸 監訳、長尾 高弘 訳、オライリー・ジャパン、2015 年 7 月刊) は、ユーザーストーリーマッピングの作者である Jeff Patton が、自ら開発したこの手法について書き下ろした解説書です。原書は User Story Mapping で、ユーザーの行動の流れに沿ってストーリーを並べ、関係者の共通理解を築きながら、最初に作る範囲と後回しにする範囲を切り分ける方法を、概要から実践まで通して扱います。版元はマーティン・ファウラー、アラン・クーパー、マーティ・ケーガンによる序文と、平鍋健児による日本語版まえがきの収録を案内しており、製品開発、UX デザイン、業務要件定義の現場で、使いやすく実現可能なサービスを作りたい人に向けた一冊と位置づけています。

0 章から 19 章まで、マップ作りからディスカバリーとデリバリーへ

目次は 0 章「まず最初に読んでください」から始まり、19 章「終わり? それとも」で閉じる構成です。0 章では、完璧なドキュメントを書こうとするより、記憶を助けるための記録を残して話し合うことの意味が説かれ、1 章「全体像」でフラットなバックログの弊害と、ユーザーのストーリーを語りながら全体像を描く流れが示されます。2 章から 4 章は、作るものを減らすため、より早く学ぶため、時間どおりに終わらせるためという 3 つの目的に沿ったプランの立て方で、MVP リリースの切り出し、機能ではなく成果で優先順位を付ける考え方、マップをスライスして開発戦略を生み出す方法を扱います。5 章はマップを作る手順を一歩ずつたどり直す章で、ここまでで手法の重要な概念が出そろいます。6 章以降は、ロン・ジェフリーズの 3 つの C (カード、会話、確認) に始まるストーリーそのものの理解、大きなストーリーを分割していく考え方、スリーアミーゴスとプロダクトオーナーの役割、オポチュニティから始めるディスカバリーと検証された学習、ストーリーワークショップを含むリファインと構築、そして作ったものから学ぶレビューへと進みます。

平らなバックログが失う文脈とマップの効き目

ユーザーストーリー を優先順位の順に一列に並べたバックログは、個々の項目を管理するには便利ですが、ユーザーがどんな順番で何をしようとしているのかという文脈を落としてしまいます。項目が数百に増えると、一つひとつは妥当でも、通して使える製品になっているかを誰も確かめられなくなります。ストーリーマップは、横方向にユーザーの活動の流れを並べ、その下に細かなストーリーを積んでいくことで、全体の流れと詳細を同時に見渡せる形を作ります。この形があると、横に線を引くだけで最初のリリースで通して使える最小の範囲を議論でき、抜けている手順にも気づきやすくなります。本書の 2 章がマッピングはストーリーの穴を見つけるのに役立つと述べ、MVP リリースやリリースロードマップの切り出しを扱うのは、この性質を前提にしています。アジャイル開発 ではイテレーションごとに少しずつ作るため、全体像を保つ仕組みを別に持たないと、作りやすい順に作った結果として使えない製品が残る危険があり、マップはその歯止めとして働きます。

文書より会話を中心に置く、要件定義との違い

本書が繰り返し強調するのは、ストーリーは書くためのものではなく語り合うためのものだという点です。1 章には書くのではなくストーリーを語るという節があり、6 章ではカード、会話、確認の 3 つの C が取り上げられます。従来の 要件定義 が完成度の高い文書を作って引き渡すことを目標にしがちなのに対し、本書はカードを会話のきっかけと記憶の手がかりとして扱い、関係者のあいだにできた共通理解そのものを成果とみなします。13 章から 15 章のディスカバリーの章では、リーンスタートアップ思考が製品設計をどう変えるかにも触れ、リスクの高い仮定に名前を付け、小さなテストで確かめる流れが説明されています。8 章にはここはツールを使うべきときではないという節もあり、手法の中心は管理ツールではなく人どうしの会話に置かれています。

スクラムなどのアジャイルの用語や、バックログ、イテレーションといった基本を知っていると読みやすくなります。一方で、特定の管理ツールでマップを作る操作手順や、スクラムのイベント運営の手引きを求める人には目的がずれます。また 2015 年刊の翻訳であり、事例はその時点の製品開発の文脈で語られています。バックログが長くなるほど何を先に届けるべきかが見えなくなっているプロダクトオーナーや、開発者とデザイナー、事業側の認識のずれで手戻りを繰り返しているチームにとって、手法の作者自身が考え方の根から説明する本書は、マップの作り方と、作る範囲を減らす判断の両方を一度に手に入れられる一冊です。

言及した記事 (30 件)

この本に興味がある方におすすめ

関連する本

関連記事

関連用語

共有: