READYFORのプロダクトマネージャー、kecy (@kecbigmt)です。初投稿！
さてさて先日、Jeff Patton著「ユーザーストーリーマッピング」という本を読みました。
元々は「プロダクト開発の文脈で『ユーザーストーリーマップ』ってあるけど、実際どう使えるんだろう？」「鳥かわいい」という程度の動機で読み始めた本でした。
ですが、読み進めるうちに、単なるひとつの手法には留まらない、プロダクト開発の進め方についての体系的な知識を得られたような気がしたので、忘れないように／理解を深めるために文章にしておきます。
ここでは、主に本書の
- 第12章「岩を砕く人」
- 第13章「オポチュニティから始める」
- 第14章「ディスカバリーを介して共通理解を築く」
から得られたものを中心に整理します。アウトラインはこちら！
また、「ユーザーストーリーマップとは何か」については詳しく触れません。初見の方にとっては以下が参考になると思います。
簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story Mapping)
こんな文章を残したくなるくらい、得られるものの多い本なので未読の方はぜひ読んでください！
前置き：すごいぞストーリー
前述の通り、本書は「ユーザーストーリーマップ（以下、ストーリーマップ）」を紹介するだけの本ではありません。
もちろん前半ではストーリーマップについてしっかり説明してくれます。しかし、途中からは「プロダクト開発がどこから始まり、どのように課題を捉え、ソリューションを見つけ、それを分解して、実際に世に出せるようにするか」を説く内容になっていきます。
ここでは前置きとして、ストーリーやストーリーマップが、そこからプロダクト開発論にまで広げられるくらい強力な実用性・汎用性を持った考え方であることを力説させてください。
ストーリーマップのコンセプト
私見ながら、ストーリーマップの中心的な考え方は、
- 「ユーザーがプロダクトを使って目的を達成する流れ」 を「ストーリー」として捉えること
- それによって開発に関わる人たちの間で共感や共通理解を作りやすくすること
- さらにストーリーを分解可能なものとして捉え、分解・マッピング・グループ化することで、タスクの細分化や優先順位付け、リリース戦略について議論しやすくすること
にあると考えています。
全部大事なのですが、「分解可能であること」 は意外と重要です。どう重要なのか、もう少し掘り下げていきましょう。
"分解可能"であることの強力さ
本書ではストーリーを「岩」に例えています。
大きなストーリーは小さなストーリーに分解でき、それら小さなストーリーはさらに小さなストーリーに分解できる。ちょうど岩のように。そして、どのサイズでも（どれだけ小さくても）、ストーリーはストーリーだ。
Jeff Patton『ユーザーストーリーマッピング』（オライリージャパン、2015）p.172
ここでいう「ストーリー」は「ポストイット1枚分に収まるような短いセンテンス」のことだと理解してもらっていいでしょう。
例えば、
「ミュージシャンが自分のバンドを効率的にプロモーションできる」
のような大きなストーリーから始まり、それを分解していけば、
- 「ライブを告知できる」
- 「バンドのメーリングリストを運用できる」
などになり、さらに細かく分解していけば
- 「チラシを作ることができる」
- 「チラシのレイアウトを変えることができる」
- 「作成中のチラシをプレビューできる」
などになっていきます。
これを一般化すれば、以下のようなパターンが考えられるでしょう：
- ビジネスにとって意味があると理解するのにちょうど良いサイズの大ストーリー （会社が業績を上げられるようなストーリー）
- ユーザーの個別のニーズを満たすのにちょうど良いサイズの中ストーリー
- 開発するのにあたってちょうど良いサイズの小ストーリー
これは、コミュニケーションにとって非常に都合がいいことです。
なぜなら、「これから何を作るか」「いま何を作っているか」「何をリリースしたか」といった議論を、すべてストーリーをベースに語ることができるようになるからです。
つまり、プロダクト開発のどの段階でも、開発メンバーはストーリーマップを囲んでコミュニケーションを取ることができます。
もっと言うなら、やろうと思えば役員会議から開発チームの朝会まで、どのレイヤーにおけるコミュニケーションでも、「ストーリー」をベースにプロダクトについて議論することさえできるでしょう。
ここが、ストーリーという考え方のもっとも強力なところだと考えています。
その強みがあるからこそ、本書は「ストーリー」を中心にしてプロダクト開発のプロセス全体を論じることができました。
この記事で整理したかったのがそこです。前置きはこれくらいにして、開発プロセスについて本書で論じられていることをより使いやすいように体系立ててまとめていきます。
本論：ストーリー・ライフサイクル
本書で論じられているプロダクト開発のプロセス全体を3行にまとめるなら、
- ユーザーとビジネスの要求に応えるようなプロダクト開発の「機会」を選び取る
- その機会に相応しい、実用最小限のソリューション（MVS）を見つけ出す
- そのソリューションを開発してユーザーに届ける
となります。これをこのまま、開発プロセスを3つのフェーズとして捉えると考えやすいでしょう。
本書で登場する言葉を用いて名付けるなら、
- オポチュニティ・フェーズ
- ディスカバリー・フェーズ
- デリバリー・フェーズ
です。
また、ディスカバリーとデリバリーの間では、本書で「最後で最良の会話」として強調されている「ストーリーワークショップ」を行います。
ストーリーワークショップでは、ディスカバリーで見つけ出したソリューションについて細部にわたって議論し、「具体的に何を開発するのか」や受入基準について意見を一致させます。
開発者・テスター・その他開発に関わるあらゆる人たちで議論し、ストーリーを適正サイズに分割し、開発のイテレーションに投入することで、デリバリー・フェーズへと移行する最終準備をします。
また、デリバリー・フェーズを経てユーザーにソリューションを届けることができたら、「レビュー」を行います。
成果物の品質・プラン・プロセスについて振り返り、やり残しやリリースして得られた知見を元にして新しい「機会」を得て、次の開発サイクルの出発点へと移ります。
この循環を「ストーリー・ライフサイクル」と呼ぶことにします。
……以上は、本書で使われている言葉を援用しているものの、あくまで独自の解釈にもとづく整理です。本書を読んでもこのようには書かれていないので注意してください。
ここから3つのフェーズとストーリーワークショップについて詳しく説明して、この記事は終了となります。
目次は以下の通り。
- Ⅰ. オポチュニティ・フェーズ
- Ⅱ. ディスカバリー・フェーズ
レビューについては詳しく触れません。気になる方は、ぜひ本書の第18章「構築するすべてのものから学ぶ」を読んでください。
Ⅰ. オポチュニティ・フェーズ
まずは最初のオポチュニティ・フェーズ。
本書では、分解する前の最初のストーリーを「機会 (opportunity)」と呼んでいます。これは、新しいプロダクトや機能のアイディアだったり、ユーザーやプロダクトが抱える問題だったりさまざまです。
サイズとしては、「ビジネスにとって適切なサイズの大ストーリー」や「ユーザーにとって適切なサイズの中ストーリー」くらいでしょう。
きっとチームにはこうした粒度の「やりたいこと」がたくさんあるはず。そんなストーリーの山のことを本書では「オポチュニティバックログ」と呼んでいます。
その山に積まれている個々のオポチュニティについて議論し、そのアイディアでさらに先に進むか、それともボツにするかを決めるための会話が、ストーリー・ライフサイクルの出発点となります。
この会話では以下のような問いについて議論します：
- それは誰のためのものか？
- どんな問題を解決しようとしているのか？
- 私たちはどのようなものをイメージしているか？
- なぜ必要か？
- サイズ、おおよその開発期間はどのくらいか？
重要な点は、たとえ「先に進む」という結論になっても、そのストーリーはこの時点では文字通り「機会」であるということです。「要求」でも「要件」でもありません。
次のディスカバリー・フェーズでは、そのストーリーを深くまでじっくり検討することになります。ユーザーの中に入り込んで現在のジャーニーとペインやゲインを理解し、複数のソリューションの可能性を探り、プロトタイプを作って、具体的に何が必要なのかを議論することになります。
その結果、アイディアを捨てるという判断になることもあり得ます。そうしたことも考慮に入れた上で、「ディスカバリーに進もう」という判断を下す必要があります。
オポチュニティ・フェーズにおける手法として、本書では以下の具体例が紹介されています：
- オポチュニティキャンバス（リーンキャンバスとよく似たもの）
- ジャーニーマッピング（カスタマージャーニーマッピングのこと）
- リハーサル・リ・マッピング（ジャーニーマップを作った上で、そこで想定しているペルソナを実際に演じて精度を上げる）
詳しくは本書の第13章「オポチュニティから始める」をご覧ください。
Ⅱ. ディスカバリー・フェーズ
先に進めると決めたオポチュニティを深く掘り下げて検討するのが、2番目の「ディスカバリー・フェーズ」です。
ここは、ストーリーにとっては一番の山場なので、説明する内容も長くなります。
ディスカバリーの目標
ディスカバリー・フェーズの目標は、目の前のオポチュニティに相応しいMVS（Minimum Viable Solution、実用最小限のソリューション） を探し出すこと。
「なぜ実用最小限でなければならないのか」は後々触れます。
このフェーズでは、誰が(who)、何を(what)、なぜ(why)について、前のフェーズよりもずっと多くのことを深く掘り下げて探究することが求められます。
具体的には、次のような問いです：
- 私たちが本当に解決するのはどのような問題か？
- 私たちのサービス、プロダクトを購入/採用するユーザーにとって価値のあるソリューションとはどのようなものか？
- 使えるソリューションはどのようなものか？
- 使える時間とツールから考えて実現可能なものは何か？
自分で選び取ったオポチュニティについて、こうした問いを投げかけ、それに答えるプロセスを進めていきます。
その過程で生まれるソリューション（サービス、プロダクト、機能）の案は、すべて小さなストーリーのタイトルになります。そして、そのストーリーをさらに深く掘り下げていき、さらに小さいストーリーに分割されることもあるでしょう。
ディスカバリーの4つのステップ
そして、実現する価値のありそうな、見込みのあるソリューションが得られたら、より具体化して理解を深めながら議論を進めます。
具体的には、以下の4つのステップで進めていきます：
- ビジネスの立場からアイディアの枠組みを作る
- ユーザーを理解し、どのように彼らを助けるかを明らかにする
- ソリューションのイメージを描く
- MVSは何か、それをどう作ればいいかを明らかにするために、最小化とプランニングを行う
ひとつひとつ見ていきましょう。
Step 1：アイディアの枠組みを作る
まず最初に、なぜそれが必要なのか・誰のために作るのか・成功をどのようにして測定するのかを明確にしていきます。
- どんな事業課題に対処しようとしているのか？
- 影響を受ける具体的な事業指標
- 具体的なユーザーは誰か？
- ユーザーがそのソリューションを利用しているどうか、気に入っているかどうかを測定できる指標は何か？
- 大きなリスクや、暗黙の前提はあるか？
- ステークホルダーやその手の専門家との、参考になりそうな議論は過去にあるか？
オポチュニティ・フェーズで検討していたこととも重複しますが、それをより広く深く掘り下げていきます。
Step 2：ユーザーを理解する
次に、対象となるユーザーのペルソナやカスタマージョブを明らかにし、彼らの現在のジャーニーを理解し、そこで生じるゲインやペインについて考察します。
「バリュープロポジションキャンバス」の右半分（赤枠の部分）を具体化するステップとも言い換えられるでしょう。
このためには、ユーザーを深く理解している人やユーザーについての情報を得るために必要な人に参加してもらうことが必要となります。
（ここは本書の内容だけだとしっくり来なかったので、自分なりの解釈です）
Step.3：ソリューションのイメージを描く
WhyとWhoが明らかになったら、次はWhatです。
特定のユーザーに焦点を絞り、彼らのためのソリューションのイメージを描きます。言葉と絵を使ってソリューションを視覚化し、ユーザーとともにその正しさをチェックしていくプロセスです。
規模や状況に応じて方法はいろいろあり、本書では例として以下が挙げられています：
- ストーリーマップ
- ユースケースとユーザーシナリオ
- UIスケッチとストーリーボード
- UIプロトタイプ
- アーキテクチャ・技術面での設計スケッチ
- アーキテクチャ・技術面でのプロトタイプ
- チームメンバー、ユーザー、顧客、ステークホルダー、問題領域のエキスパートを集めた多数の共同作業
例えば、以下のような活用が考えられます：
- まずはストーリーマップと簡単なスケッチで、ソリューションがカバーする一連の流れを可視化する
- これによって、チームメンバーでの共通理解を築きつつ、議論によってその精度を上げていく
- UIスケッチやストーリーボード、UIプロトタイプを作成することで、UI/UXの精度を上げる
- 設計スケッチで技術的な検討の精度を上げたり、プロトタイプ版を開発して技術検証を行う
Step.4：最小化とプランニング
ついに最後のステップ、本書の筆者がもっとも重要だと強調するステップです。
ここまで来るころにはさまざまなユーザーの期待に応える立派なソリューションの絵図が描けているはず。
ですが、それを一度に実現するのは困難だし、成果のためには実は不要なものだって含まれていることが多いでしょう。
このあたりについては金言が多いので、いくつか引用しておきます。
私たちの目標は、構築する量（アウトプット）を最小限に抑え、仕事から得られる利益（成果とインパクト）を最大限に引き上げることだと忘れてはならない。
同書 p.232
とか、
作るべきものはいつも多すぎる。 申し訳ないがこれは事実だ。少しでもソフトウェア開発に従事したことがあれば、すでにこのことはご存知だろう。私は10年以上の長い間、そうではないフリをしようと努力してきたが、諦めた。
同書 p.232
とか 、
最初のリリースが世に出ると、世界は変わる。それは良いことだ。このことは一方で、将来のリリースは、私たちが作った新しい世界を前提として、新たに考え直さなければならないことも意味している。
同書 p.233
とか…なぜだろう、心にグサグサ刺さってきます。
編み出したソリューションを「絵に描いた餅」で終わらせないためには、ストーリーマップをMVSごとに切り分け、段階的なリリースバックログと開発プランを組み立てる必要があります。
そして、リリースするごとにその時点の世界を前提として、次に開発すべき内容を考え直します。
ここでの「MVS」とは、特定のターゲットユーザー・用途にとって価値があり、使えて、実現可能性がある最小限のソリューションのこと。
つまり優先度の高いソリューションから段階的に開発・リリースしていこうという話ですが、ここには大きな落とし穴があると筆者は強調しています。
ほとんどの人々が犯す優先順位づけの誤りは、まず機能の優先順位を決めようとすることだ。 機能の優先順位を考える前に、具体的なビジネスゴール、顧客、ユーザー、次いで彼らの目標の優先順位付けをしよう。
同書 p.234
つまり、機能に優先順位をつけるのは最後です。その前に
- 事業におけるゴール
- ユーザーや顧客
- 彼らが持つ目標
に優先順位をつけましょう。そうすれば自ずと機能の優先順位も決まってくるでしょう。
最小化（ストーリーマップのスライス）のわかりやすい事例として、本書の第3章「より早く学ぶためのプラン」で紹介されているエリックの例が参考になります。
こうして4つのステップを経て生まれる、「価値のあるプロダクトのリリースにつながるストーリーの集まり」を、本書の筆者はリリースバックログと呼んでいます。
Ⅱ → Ⅲ. ストーリーワークショップ
ディスカバリー・フェーズで得られたリリースバックログをもとに、デリバリー・フェーズでの開発に移ります。
しかし、その前に「最後で最良の会話」が必要だと本書では強調されています。
それが、ストーリーワークショップ。開発者、テスター、ユーザー、UI/UXの専門家、開発チームのあらゆる人たちに参加してもらい、ストーリーマップを囲んで詳しく精査します。
これに続くデリバリー・フェーズで具体的に何を開発するかについての意見、細かい部品のテスト方法や受入基準についての意見を一致させます。
ワークショップは1回あたり3〜5人程度の小規模に保たれ、必要に応じてほぼ毎日行われます。
その着地点について、本書では以下のように説明されています：
ストーリーについて良い議論ができれば、ストーリーワークショップが終わったときには、適切なサイズのストーリーが揃い、さらに多くの補助的なドキュメントやモデルができているだろう。ストーリーが完成した際のチェック方法を表す受入基準ができれば、完成である。
同書 p.276
これ以上の内容はここでは触れません。具体的な進め方や例については、本書の第16章「リファイン、定義、構築」を参照してください。
Ⅲ. デリバリー・フェーズ
ついにプロダクトを実際に開発するフェーズとなりました。
3番目のデリバリー・フェーズは、十分なプロダクトを開発してユーザーに届けるための段階。
ユーザーが追求する成果を生み出せる状態になっているかどうかが、「十分」の目安となります。
このフェーズではストーリーは主役ではありません。開発されるプロダクトが主役です。
ですが、ストーリーワークショップを乗り越えて洗練されたストーリーマップは、全体像についての共通理解を維持しながら開発を進めるための強力なコミュニケーションツールになるでしょう。
すでに作ったところとそうでないところを示すダッシュボードとしても使えるし、プロダクトオーナーやプロダクトマネージャーは現在の進捗状況を見ながら次に重点をおくべきストーリーを考えることができます。
そして、このフェーズで重要なこととして筆者が強調するのは「作る間も会話を続ける」ことです。
どれだけ必死に頑張ってストーリーについての最後で最良の会話を行えたとしても、構築を始めた後で学ぶすべてのことを予測することはできない。毎日、ストーリーについての会話を頻繁かつ何度も行うことを予め見込んでおく。そうした会話セッションの必要があれば、デイリースタンドアップミーティングで提案する。
同書 p.180
ストーリーからは少し脱線しますが、さらにデリバリーは以下のようなプロセスを歩みます。
- 開発中もストーリーの細部を埋め、動く部品を観察してフィードバックを提供する
- プロダクトの品質、現在のプランやプロセスを頻繁に振り返る
- 開発が進んで「意味のある量の動くプロダクト」ができたら、ユーザーとともにテストして学びを得る・ステークホルダーに見せて進行状況や品質を可視化する
- 現在のプロダクトと「十分」という重りを天秤にかけ、釣り合うならユーザーに向けてリリースする
……こうしたプロセスを経てようやくリリースされたとき、そのプロダクトは本当の意味で始まります。
できあがったプロダクトをもとにレビューを行い、社内やユーザーからのフィードバックを受け取ります。そして次のオポチュニティを掴み、次のディスカバリーへ。
こうして回っていくのが、ストーリー・ライフサイクルです（再掲）：
おわりに
このようなサイクルをまだ実践できているわけではありませんが、この考え方に基づくプロダクト作りに日々取り組んでいます。
現状維持に安住せず、今よりも良いものを目指してトライ&エラーを続けていけるのは、メンバーの自律性を重視するREADYFORのカルチャーと組織作りがあるからです。
これはお世辞でもポジショントークでもなく、約4ヶ月前に入社してすぐに実感しました。
READYFORでは、エンジニアの採用活動を積極的に行なっています。より良いプロダクトづくりのために私たちと一緒に取り組んでいただける方、エントリーをお待ちしています！
募集要項
