正式タイトル : ユーザーストーリーマッピング

原著 : User Story Mapping: Discover the Whole Story, Build the Right Product

著者 : Jeff Patton

ユーザーストーリーマッピングについての書籍

日本語版序文 (平鍋健児)

ユーザーストーリーマップは、漂流アジャイルにならないための海図の役割

そのためにアジャイルチームが全員で作成、修正していく活動こそがユーザーストーリーマッピングの本質

大きな要件の塊を小さなチャンクに分割する考え方はアジャイルソフトウェア開発の普及でよくなったことのひとつ

ただし、ソフトウェアシステムが何をすべきかの全体像が見えづらくなった

ストーリーマッピングは、全体像を提供するための技法

機能をひとつずつ作ってソフトウェアをくみ上げるのは妥当だが、ふるまいや製品の全体像の設計でも同じ手法を用いると、フランケンシュタイン的な怪物プログラムが生み出されかねない

開発者とインタラクションデザイナーは共通の言葉を持っていないので、コラボレーションが難しい

ユーザーストーリーマッピングという手法が両者をつなぐ

アジャイル開発はデザインツールとしては役に立たない

本書は、チームのコラボレーション、コミュニケーションのあり方、優れたデザインを作り上げる方法の核心に触れる

優れたチームとダメなチームの重要な違い

ユーザーストーリーマッピングがこれらに関わる

ストーリーマップという単純な実践ではあるが、意味は深く精緻

ストーリーについても改めて説明する

ストーリーで苦しんでいる人にうってつけの本

対象職種

市販製品のプロダクトマネジャーやユーザーエクスペリエンス (UX) 担当者

IT 企業のプロダクトオーナーやビジネスアナリスト、プロダクトマネジャー

アジャイル、リーンプロセスの指導者

それ以外の全ての人々

この本で最も重要なこと

ストーリーを使う目的は、良いストーリーを書くことではない → 本当の目的は共通理解をつかむこと

要件を形式に落とし込むためのものではないし、ストーリーは要件ではない

製品開発の目標は、製品を作ることではない → 本当のあなたの仕事は世界を変えること

より早く、より多くのソフトウェアを生み出すことではない

やるべきことは要件を満たすことではなく、世界を変えること

共通ドキュメントは共通理解ではない

議論して共通理解を得た内容をドキュメントに書くことで、共通理解をした当人たちが思い出せる

アジャイルプロセスでもたくさんのメモやスケッチを書く

一番大事なことは思い出せること

世界を変えるということ

アイデアとデリバリーの間の全てがアウトプット

本当に欲しいものは成果 (outcome) : 世に出た (come-out) ときに結果として現れるもの

人々が目的を達成するために実際にやり方を変えられたか？ 生活が良くなったか？

ストーリーについて話すときには、誰のためか、なぜなのかも話す

顧客やユーザーが欲しいものを手に入れられない限り、会社も欲しいものを手に入れられない

売上の増加や経営コストの削減、顧客満足度の上昇やマーケットシェアの拡大など

人々の生活をより良いものにすると同時に、会社が健全性を保つ ← インパクト (優れた成果を上げた結果として長期的に起きること)

作るべきものは我々が持っている時間・リソース以上に存在する

「アジャイルソフトウェア開発宣言」 には改めて触れないが、読んでいないなら読むこと

ストーリーがストーリーと呼ばれるゆえんは、何を書くべきかではなく、それをどのように使うべきかだから

ストーリーマッピングは、会話しながら大きなストーリーを小さなストーリーに分割するためのパターン

話して記録 : ストーリーを話しながら、カードかポストイットに考えていることを書き出して思考を表出化

会話しているときにせっかくのアイデアが蒸発することは避けるべし

他人の話を聞いているときにアイデアを思いつくことがある → 忘れないようにポストイットに書き留める

アウトプットではなく目指したい成果から会話

成果のカードの並び順をあえて適当にすることで、本人に並び替えてもらう (本人が考える優先度を知る)

誰に届けたいかも同様

まずは全体 : ユーザーのある 1 日をイメージして、製品がどう使われるかをストーリーで話す

これにより共通理解を作っていく

全体を考えるストーリーマッピングにより、思考の穴が見つかりやすくなる

1 つのストーリーを掘り下げる前に、まずは全体 : 深さ 1 cm、幅 1 km のことを考える

ストーリーマップの幅の後に深さ : 詳細と代替案を探索

個々のステップで次のことを考える

ここでユーザーが行うことは具体的には？

他に代替案としてできることは？

何があったら 「これはかっこいい」 と思える？

おかしくなったときにどう対処する？

常に、我々が持つリソース (時間や資金など) 以上に作るべきものが存在する

複数チームにまたがる製品のリリースでは、依存関係明確化のためにマップを作る

複数のチームで協働

それにより穴が見つかりやすい (他のチームが担当すると思っていたが浮いていたものや、システム間連携など)

古いソフトウェア開発のやり方ではスコープクリープと言ったりするが……

スコープが知らぬ間に増えることはなく、単に理解が進んだだけ (そしてマップ作成で理解が進むことは良いこと)

マップの背骨を見ると、システムに関わる全ての人々が目的達成のために作業をするストーリーが聞こえる

これをナラティブフロー (物語の流れ) という (多くの人とシステムを横断)

成果に焦点を当てろ

システム内部の機能を決めるときには、まずシステムの外側で起きてほしいことを考える

そのような成果を生み出すリリースを切り出す

リリースロードマップの作成

マップをスライスに分ける (上下方向に切る)

左側にスライスごとに期待する成果を記述

カードを適切なスライスに入れていく

これは機能のリストではなく、現実世界でのメリットの羅列

特定の成果に的を絞ることが開発における優先順位付けの秘訣

Minimum Viable Product (MVP) について

大きなアイデアを前進させるために、まずは会社のオポチュニティ (好機) として扱う

会社の幹部と議論 (大きなアイデアとは何？ 顧客・ユーザーは誰？ なぜ彼らはそれを使いたがる？ なぜ我々が作る？)

社内でこの好機のオーナーになるために、社内の人と共通理解を築く必要

次に、解決しようとしている問題が本当にあるのか確かめる

顧客・ユーザーと話しながら、新しいソフトウェアを試したらいいと思われる人々 (顧客開発パートナーと言ったりもする) をリスト化していく

学べば学ぶほど最初のオポチュニティは変わっていく

自分のソリューションが有用で価値あるものかどうか知るために、プロトタイプを作ってユーザーに見てもらう

そのあとは、minimum 未満で viable ではないが、対象の顧客やユーザーの問題を解決できるかもしれない製品を作り、開発パートナーになってもらった顧客やユーザーに送り届ける

実際に使ってもらえるか？

Minimum で Viable になるまでリリースを繰り返す

開発パートナーの人たちが、自発的に他の人に薦めるようになったら MVP であると言える

検証された学習戦略というリーンスタートアップ的思考の重要概念のひとつ

エリック・リースの MVP を、MVPe (Minimum Viable Product experiment) と呼ぶことにする

我々の目標は、何かを作ることではなく、正しいものを作っているかどうかを学ぶこと

学ぶことが目標であれば、構築を最小限にして学ぶ必要があるものに注力できる

マップは、会話の助けに必要な分だけ作ればよい (製品全体のマップを作る必要はない)

最良の見積りは、自分が何を見積もっているのかを本当に理解している開発者から出てくる

共通理解の構築が見積りのカギ！

少しずつ構築するための計画

リリースできる最小限の構成でもそれなりの大きさがあれば、例えば 3 つのスライスに分ける

1. 歩くスケルトン (スチールスレッドや曳光弾とも) : 機能の最初から最後まで道をつなげる

2. もっと良くする

ここで、プロトタイプではわからなかったことなどがわかったりする

3. リリースできるように磨けるだけ磨ける

上記の 3 つスライスはリリースのためのものではないので、スライスごとのリリースはしない

見積りはあくまで予測でしかないが、実績は測定できる

測定することで見積りを正確なものに近づけることができる

大きなものをスライスすることで測定する機会が増える

ストーリーマップにリスクストーリーを組み込んだ事例

リスクや不確実性のために必要な時間を計画に組み込むように

リスクを測定してまなびをステークホルダーに共有する方法としてリスクバーンダウンチャートも得られた

芸術家が作品を作成するようにソフトウェアを開発する

どんなに小さな製品や機能でも、リリースバックログを 3 つに分ける

序盤戦 : 製品が最初から最後まで動くことを確認

製品全般に関わる基本的機能や基本的なユーザー行動に注力

技術的に難しい部分やリスクの高い部分も

中盤戦 : 仕上げを埋めていく

序盤戦が適切に終わっていれば、パフォーマンス、スケーラビリティ、ユーザビリティなどの製品全体を対象とするテストも可能に

終盤戦 : リリースを磨く

全てはリスク対策 : 製品が間違っていると後から判明するリスクや、技術的リスク

ソフトウェアを使う人が目標達成のためにしているタスクをユーザータスクという

この概念が素敵なユーザーストーリーを書くために最も重要

例えば 「朝食を作る」 みたいな粒度で書くべきであり、「コップにジュースを注ぐ」 みたいな粒度では書かない

『ユースケース実践ガイド』 にてゴールレベルという概念が紹介されている

タスクを左から右に向かうフローに整理 : これがナラティブフロー

まず思いつくタスクでナラティブフローを作った後、さらに追加で例外時のタスクや理想の状態におけるタスクを追加していく

このとき、似たようなタスクは同じ列に入れていく

まとまって発生するように見えるストーリーをまとめる (アクティビティという)

アクティビティのポストイットの並びがバックボーンになる

スライスを使って、特定の目標を達成するためのタスクと細部を明らかにする

例 : 寝坊して急いで家を出なければならないときのように、急ぎの場合でもやる必要があるものとそうでないものを分ける

上に必須のものを残して、省略できるものを下に移動する

このとき、アクティビティ自体は (上のスライスからはタスクが消えたとしても) 残しておく

将来のことをマッピングした将来マップと現在のことをマッピングする現在マップがあるが、コンセプトは同じ

ユーザーエクスペリエンスコミュニティではユーザーを理解するために現在マップを作る (ジャーニーマップと呼ぶこともある)

ストーリーの考え方は、Kent Beck が考えたもの

要件記述に関する問題

同じドキュメントを見ても人々が異なる理解をする

間違ったことを正確に記述していることがある

何が必要かは書かれているが、なぜ必要かが書かれていない

単純に、完璧なドキュメントを必死に書くことをやめて、ストーリーを語るようにした

ストーリーの思想は語ること : 聞き手の心にエネルギーや興味、ビジョンを生み出す

ストーリーのプロセスはロン・ジェフリーズの 『XP エクストリーム・プログラミング 導入編』 で実践しているものが適切

Kent Beck がストーリーのアイデアをはじめて文章にしたとき、ユーザーストーリーとは言わずにストーリーと呼んだ

Connextra で生まれたテンプレート : <ユーザータイプ> として、私は <これこれの結果を得る> ために、<これこれ> をしたい

誰が、何を、なぜ、を考えられるように

誰と会話すればいいかがわかるようにする

テンプレートゾンビにはならないように (テンプレートに従っていなくても、ストーリーはストーリー)

テンプレートはあくまで練習用であって、難しい領域では最良の選択ではない

リアルに迫るために

「誰が」 の解像度を上げる (「ユーザー」 では広すぎる)

ユーザーのタスクから考えられないもの (権限チェックなど、ユーザーが意図的に選択しないもの) については、ユーザーではなくサービスやシステム目線で考える

「なぜ」 は階層構造になっていることが多いので、深く掘り下げること

ソフトウェアの外部について話す (どこで、いつ、使われるのか？ どれぐらいの頻度で？ 利用時の状況は？)

うまくいかない可能性について話す

疑問や暗黙の仮定について話す

より良い解決法について話す

How について語る : why、what、how のいずれもバランスがとられて話されるべき

how が要件になってしまうと良くないが、そうでなければ how を話さないと解決策のコストを考えられない

期間について語る

ストーリーカードは図書館の目録カードのようなもの : 全ての情報がそこにあるわけではない

壁に情報があるとコラボレーションが生まれる

ロン・ジェフリーズの 3 つの C のサイクルを完成させると 5 つの C になる

ストーリーの詳細を他の誰かに渡して作ってもらおうとしても決してうまくいかない

チームに属する誰もがどのストーリーをも拾えるように、全員がどのストーリーについての会話にも参加する、というのはバッドプラクティス

効果的な議論や意思決定は 2 人から 5 人が適している

完成したものの品質について話すときの 3 つの観点

ユーザーエクスペリエンスの質

機能の品質

コードの品質

変更が必要な場合は、以下の 2 つを切り離して考えること

合意したとおりのものを作ったか？

合意したものを作ったうえで、その完成品を見た結果、変更を加えるべきか？

作ったうえで学習することを織り込んでおく

ストーリーをバックログに入れるときには、最初からそれを変更することと、その変更をさらに変更することを織り込む

2011 年に Kent Beck はアジャイル宣言の修正版を公開

『動くソフトウェア (または包括的なドキュメント) よりも、「検証された学習」 を』

学ぶために計画し、計画するために学ぶ

ストーリーが表すソリューションがコストがかかりすぎるなら、目標達成に近づく別のものを検討

コストに問題がなくても大規模であれば、早い段階で進行状況を評価したり確認できる小さなものに分解

ストーリーの適正なサイズ

ビジネス視点 : 会社が業績を上げる役に立つ粒度

ユーザー視点 : ニーズを満たす

開発チーム視点 : ビルドやテストに数日しかかからない粒度

ストーリーを砕くには会話がいちばん

エピックは大きすぎるが、それはあくまで開発チーム視点であり、ビジネスや顧客、ユーザー視点だと適正なサイズ

グループにまとめると便利な一連のストーリーをテーマという用語を使おう

ストーリーの岩を砕くサイクル → ストーリーのライフサイクル

プロダクトオーナーが率いる小規模な組織横断チームがプロダクトディスカバリーの仕事を取り仕切る (プロダクトディスカバリーチーム)

ストーリーを書き、ストーリーについての会話を主催する責任者がひとりだけ、というのは破綻する

スクラムでいうところのプロダクトオーナー

一人では足りない

プロダクトオーナーは製品とチーム全体が同じ方向に向かって動くようにする重要なリーダー

逆に、委員会による設計もよくない (変な妥協をしたり、あるいはあらゆることをやったりする)

『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』 によるプロダクトマネジャーの仕事 : 価値があり、使いやすくて実現可能な製品を見極めること

ストーリーワークショップにおいては次の 3 人組が必要

プロダクトディスカバリーチームのメンバー

ユーザーエクスペリエンスデザイナーやビジネスアナリスト

ウェイターと客の関係ではなく、医者と患者の関係に近づける

IT システム以外をプロダクトとして扱う事業 (銀行など) の場合、プロダクトマネジャーは銀行口座や信用商品などを対象とする

こういう組織では、ビジネスアナリストが要件収集の役割を与えられることが多い

クライアント ‐ ベンダーアンチパターンに陥りがち

プロデューサーと音楽バンドのような関係 (音楽バンドの成功のためにプロデューサーは尽力する) を目指すべし

ストーリーのライフサイクルを参照

ストーリーのライフサイクルやディスカバリーの進め方を参照

最初に開発する必要があるのは、製品ではなく顧客 (『アントレプレナーの教科書』)

ソリューションに興味を持つ顧客が見つかったかどうか継続的にチェック

頭のなかにあるソリューションが、彼らが購入し、使用し、他の人に薦めるようなものになっているかどうかチェックする

『リーン・スタートアップ』 のエリック・リースのプロダクト開発に対する最大の貢献 : 「構築 - 測定 - 学習」 という短いスローガンに単純化したこと

この学習サイクルを短縮する

従来のデザインプロセスは、学習と設計に時間をかけすぎる

デザイン思考にリーンスタートアップを (サイクルを短縮する)

目標は、できる限り早いうちに何かを学ぶこと

ストーリーワークショップの話

『アステロイド』 というゲーム

ストーリーの分解を全部どんどん小さくすると不必要な複雑さに埋もれてしまう

段階に応じた目的を意識

1. オポチュニティ : ストーリーは誰のため？ 彼らが解決したい問題は何？ 会社の事業戦略に沿っている？

2. ディスカバリー : 誰がなぜどのようにプロダクトを使う？

3. 開発戦略のプランニング : リスクはどこにある？ 最も多くのことを学ぶにはどうすればいい？

4. 次の開発サイクルのプランニング : 何を構築するか決めて、完成したことを確認する方法について意見を一致

ステークホルダーが参加しないチームプロダクトレビューおよびリフレクション

『偉大な芸術に完成はない。 あるものは途中で投げ出されたものだけだ。』