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

ユーザーストーリーマッピングを読みました。

ユーザーストーリーマッピングの方法論よりも、とにかく会話する、作るものを減らすことを論じています。 ドキュメントが正義じゃない、バックログを上から消化するのが正義じゃない、というのは私もぼんやりと感じていたことではありましたが、よりはっきりとその感覚が着きました。 ストーリーマッピングを実際に運用するには、本文にもありましたが、外部コーチに依頼するのがよいでしょうね。

以下まとめ。基本的に丁寧語は私の意見とか解釈です。

0章 まず最初に呼んでください

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

  • 本書の中で何度も登場する概念ですが、目的だったり手段だったり、どんな対象であっても、共通理解を得るためには会話が必須である、ということです。「顧客が本当に必要だったもの」の風刺絵は有名ですが、「共通理解を得られていない」状態は本当に容易に発生してしまいます。これを防ぐためにはドキュメントでは足りません。多くのエンジニアは体験していることでしょう。
  • ドキュメントは共通理解を思い出すためのツールである。同時に、共通理解を思い出すためのツールとして、会話の際の写真だったりビデオにまとめたりすることも有用である。

大切なのはソフトウェアではない

  • ソフトウェア（アウトプット）を作ることは目的ではない。本当に必要なものは、アウトプットの後に結果として現れるもの（成果）だ。
  • いつも私たちが持っている時間とリソース以上に、作るべきものが存在する
    • 「作るべき」という表現が曖昧です。私は「作ることになっている」といったほうがしっくりきます。
    • やるべきことは、「作ることになっている」を減らすことだ。アウトプットを最小化し、成果を最大化することだ。

「要件」

  • 要件という言葉は危険だ。「これは要件である」と言った瞬間、思考は停止する。

1章 全体像

筆者の不満からストーリーマッピングへ

ストーリーマッピングの流れ

  • 前提: 顧客とエンジニアが会話しながら進める。会話の内容はカードやポストイットに記入する。
  • 始めは要件リストを作ることを目的としない。ビジネス目標を明らかにすることだ。そのビジネスによってどんな利益がもたらされるか、どんな課題が解決されるか、カードに記入して優先順位をつけて並べる。
  • 次にユーザーのイメージを描く。どんなユーザーがいて、それぞれの現在と理想の状態をカードに記入する。これも優先順位で並べる。
    • アウトプットを減らすことを忘れてはならない。すべてのユーザーを対象にできないことに気をつける。
  • ユーザーのストーリーを描く。横軸を時間軸として、そのユーザーがどんな体験すをするのかを記入していく。
    • カードを並べることでコミュニケーションができる、ということが面白さだ。
    • 時系列に並べることで、思考の漏れに気づくことができる。そのためにもこの時点では深さよりも幅を重視する。
  • 各ストーリーの各ステップを詳細化し、下にカードを並べていく。

2章 作るものを減らすためのプラン

  • 1章で全体像を作ったが、すべてを作ることを目的にしてはならない。

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

  • 私にとって、シンプルでありながら良く響く、いい言葉です。

ストーリーマップのスライス

  • ストーリーのカードが横方向で時系列順に、縦方向に優先度順で並んでいる。ここで、リリースの単位を区切るため横にテープを貼る。最も上のテープが MVP を示す。
  • 優先度は機能ではなく成果で決める。

MVP

  • Minimum Viable Product。いまや一般的に用いられる言葉ですが、筆者は viable という言葉について、我々の向き合い方が足りないことを懸念しています。 viable とは「自力で生き残れる」という意味。作るものを減らすため、我々には問いが必要ですが、その問いとは、どうであればユーザーにとって minimum で viable であるか、ということです。
    • MVP とは、望まれる成果を実現できる最小の製品のリリースである。
  • 筆者は MVS (Minimum Viable Solution) という言葉を好んでいます。我々が作るものは全く新しい製品であることよりも、既にあるものに機能や能力を追加することが多いためです。
    • MVS とは、望まれる成果を実現できる最小のソリューションリリースである。
  • minimum で viable かどうかはリリース前は推測にすぎない。仮定を証明または反証される必要がある。

3章 より早く学ぶためのプラン

  • 何を学ぶか？それはどうだったら minimum かつ viable か、です。
  • 取り組もうとしている問題が本当に存在するか。私たちは時が経つと問題の実在性が頭から抜けていきますが、定期的に向き合うべきものでありましょう。
  • 紹介されている例では、 viable ですらない製品を開発し、そこから機能を追加していく、という方法を採っていました。まさに、いかに作るものを減らすか、ということにフォーカスした方法です。

4章 時間どおりに終わらせるためのプラン

  • マップは製品全体のものを作る必要はない。既にある製品に機能を追加する際は、その機能のマップを作成しても十分だ。
  • よい見積もりには共通理解が不可欠だ。

マップのスライス

  • マップは3つにスライスする。1つ目は特定のストーリーを最初から最後までつなげるもの。2つ目は他のストーリーをカバーする(1つ目のスライスの不確実性を補う)もの。3つ目は機能を磨けるだけ磨くもの。
  • 各スライスはリリースの単位ではない。イテレーションを回し、どのスライスまでをリリースするかを判断する。

ダヴィンチに学ぶ

  • 「偉大な芸術に完成はない。あるのは途中で投げ出されたものだけだ。」 – レオナルド・ダ・ヴィンチ
  • ダヴィンチがモナリザを5日間で描くとして、キャンバスを5等分し、それを1日に1区分ずつ完成させていく、なんてことはしなかっただろう。描く前のイメージが完璧ではなく、描きながら学習する必要があることを彼は知っていたはずだ。
  • 我々の開発も同じく、スケッチのような基本機能のシンプル版を作り、イテレーティブに学習しながら追加していく。

5章 あなたはもうやり方を知っている

  • マップを作る練習として、朝起きてから家を出るまでの自分のストーリーマップを作る、というものです。

起床時のストーリーマップ

  • まず今朝起きてから行ったことをすべてカードに書く。
    • この時点で粒度は気にしない。だいたい15-25になる人が多い。
  • カードをサマリーレベルにまとめる。
    • 例えば髪を洗う、お湯の温度を調整する、などはシャワー浴びる、というタスクに。
  • カードを横軸方向に、時系列順に並べる。
    • ナラティブフローと呼ぶ。
  • カードを眺めて、見落とした部分があったら埋める。
  • 別のストーリーを探る。
    • 今朝はいま描き出したストーリーだったかもしれないが、たとえば昨日の朝はどうだっただろう。いつもより遅く起きて慌てて準備したりしなかっただろうか。
  • フローを整理する
    • 緊急時の朝、通常時の朝、素晴らしい朝などで分ける
  • アクティビティを整理する
    • 共通の目標があるタスクを集約したものをアクティビティと呼ぶ。かばんを持ち、天気をチェックし、必要なら傘を持つといった行為。名前がついていない事が多いが、何かしら呼び名をつける。
  • タスクをスライスする
    • 寝坊した場合、すべてのタスクをこなすことはできない。その場合の最小のタスクをスライスする。

実際のストーリーマップ

  • 前述のストーリーマップは「現在の」マップだ。製品開発の際は「将来の」マップを作る必要がある。しかし本質は変わらない。

6章 ストーリーについての本当のストーリー

  • ストーリーは作ることが目的になってはいけない。語られなければならない。ケント・ベックも言っている。

7章 より良いストーリーテリングのために

  • ストーリーを語るためのコツ。

ストーリーのテンプレート

  • テンプレートを使用すると取り組みやすい。
    • [ユーザータイプ]として、[これこれの結果を得る]ために、[これこれを]したい。
  • ただし、テンプレートが目的になってはいけない。これはストーリーを語るための道具にすぎない。
  • 誰が、何を、なぜ、をリアルに語ろう。

8章 カードに書かれていることがすべてではない

  • プロダクトには多くのステークホルダーが存在する。交わされた会話はカードに書き出し、写真で保存しよう。
  • ツールを導入したがるケースが多いが、たいていホワイトボードとカードで行ったほうがうまくいく。

9章 カードは始まりにすぎない

  • ケント・ベックは、2011年にアジャイル宣言の修正版を発表した
    • 動くソフトウェア（または包括的なドキュメント）よりも、「検証された学習」を。
  • これは知りませんでした。「検証された」というのは、作った結果について考えるという意味が込められているそうです。イテレーティブということがここでも効いてきます。

10章 ケーキのようにストーリーを焼く

  • 大きいストーリーは分割しよう、という話。

11章 岩を砕いていく

  • ストーリーは、扱う人によって適正サイズが異なる。
    • ビジネス -> ユーザー -> 開発
    • それでも、岩をどれだけ砕いても岩であるのと同じように、ストーリーはどれだけ分割してもストーリーだ。
    • この語彙を分けたくなるのはソフトウェア業界の人間の性だが、あまりこだわらない方が良い。それよりも語ることを考えよう。

12章 岩を砕く人

  • ストーリーの責任者はプロダクトオーナーだけである、というのは誤解だ。
  • 我々が求めるソリューションは、価値がある、使いやすい、実現可能である、の3つの円が重なりあう部分にある。それぞれを見極めるために様々なスキルをもった人々が協力しなければならない。

13章 オポチュニティから始める

  • 分割する元のストーリーを、本書ではオポチュニティと呼ぶ。エピックと呼ぶ人もいる。
  • オポチュニティが生まれたら、それを掘り下げるべきか、ボツにするべきか、先送りにするかを検討する。
    • ボツになるのは素晴らしいことだ。作るものを減らすことを忘れてはならない。

14章 ディスカバリーを介して共通理解を築く

  • オポチュニティからプロダクトバックログを取り出す工程をディスカバリーと呼ぶ。
    • たぶん。文中で明確に定義されていないので……
  • ディスカバリーは4つのステップから成る。
    • ビジネスの立場からアイデアの枠組みを作る
    • 顧客とユーザーを理解し、どのように彼らを助けるかを明らかにする
    • ソリューションのイメージを描く
    • MVS は何か、その MVS をどう作ればいいかを明らかにするために、最小化とプランニングを行う
  • デザインスタジオ（ワールドカフェに似ている気がします）などの手法を用いて会話、アイデア創出する。
  • 優先順位付けは、ビジネス目標を考えてから。

15章 ディスカバリーによる検証された学習

私たちはほとんどの場合間違っている

  • Chaos レポートなどで報告されているとおり、作ったものが大きなインパクトを与えたというプロジェクトは全体の20%に過ぎない。64-75%は使用されてすらいない。
  • CEO が考えだした素晴らしいアイデアを実現してリリースする、なんてのは古き悪しき時代のやり方だ。

デザイン思考

  • 共感
    • 顧客として一緒に仕事してみる
  • 定義
    • 取り組む問題を定義する
  • アイデア創出
    • ソリューションを複数考える
  • プロトタイプ
    • 動くものを作る
  • テスト
    • バグを見つけるテストではなく、作ったものが顧客の問題を解決するかのテスト

推測の扱い

  • 取り組もうとしていることのなかにどんな推測があって、そのリスクがどの程度かを分析する。また名前をつける。
  • 推測をストーリー形式で表現する。
    • どんなユーザーがどんな行動をとるか
  • ユーザーテストし、考え直す

16章 リファイン、定義、構築

  • ストーリーマップができたが、細かいところが大雑把に見えることがある。そんなときはワークショップでストーリーに磨きをかける。
  • 私たちは具体的に何を作るのか、にフォーカスする。
    • スクラムでいうスプリントプランニングにあたる。
  • ストーリーの分割もここで行われることがある。常にではない。
  • メンバーはオプトイン。全員が参加する必要はない。
  • フィッシュボウル・コラボレーションの形式もよい。

17章 ストーリーは実際にはアステロイドに似ている

  • ストーリーを細かくしすぎるのも良くない。
    • 優先順位づけが大変だったり管理しづらかったりするためのようです。
  • 細かくしすぎたストーリーを戻すことはできる。

18章 構築するすべてのものから学ぶ

  • レビュー、振り返りの話
  • 製品、当初建てた計画、実行したプロセスをチームでレビューする
  • チーム外のステークホルダーに製品をレビューしてもらう
  • ユーザーテストをする
  • リリース後に加えた改良はもっとも価値がある

19章 終わり？それとも–

  • 良いソフトウェア製品と同様に、この本に終わりはない。