su-kun1899/ユーザーストーリーマッピング読書メモ.md

## ユーザーストーリーマッピング読書メモ.md

      
    Raw
  

              ユーザーストーリーマッピング読書メモ.md
            
          
    第0章


共通理解を作ることが大事

そのためのストーリー
要件や共有ドキュメントでは作れない
記憶を思い起こさせるようなドキュメントが大事


成果とインパクトが本当の目的であることを忘れてはいけない

「早く」、「多く」、「作る」ことは本質ではない


第1章


ストーリーは書くものではなく語るもの
全体像をまず明らかにする

顧客とユーザー
誰が何をする？


ストーリーの粒度のイメージ

全体像のストーリーカードは「それから」で繋がる
詳細は「かもしれない」で表現できる


思考をアウトプットすることの大切さ

カードやポストイットにすぐ残しておけばアイデアが蒸発しない
esa.ioなんかもそうだと思うが、アウトプットする手段と場所が常にあることの重要さ


第2章


MVPリリースを見つける

仮定を証明または反証できる最小単位


優先順位は成果で判断する
ストーリーにラベルをつけるといいかもしれない

差別化
競合追従
コスト削減
etc


第3章


アイデアをチャンスとして捉える
問題が、本当に問題なのか存在するのか
学習、検証のために作る
MVPを見つける戦略

第4章


スライスはリリースではない。マイルストーン
完成は存在しない
イテレーティブでインクリメンタル

序盤、中盤、終盤で戦略は変わる（スライスが戦略になる）
序盤は基礎的な機能や高リスクなもの
中盤で仕上げにかかる。パフォーマンスやスケーラビリティも
終盤で磨き上げる。フィードバックを取り込む


完璧な見積もりは矛盾。予算を管理する
リスクが高いところを先に手がければリスク対策になる

第5章


やってみる

目覚めてから仕事に行くまでのストーリーを書き出す
ゴールレベルで書く

他のことをやるために意図的に中断することができないもの

シャワーは中断できない


細かいものはサブタスク

お湯の調節、髪を洗う、など


「それから」でつながる一連の流れをナラティブフローと呼ぶ

左から右へ、同時に行われるものは縦に並べる


見落としがないか、代替案はないか語って整理する
まとまり毎にバックボーンのラベルをつける

最上段に。「それから」でつながるストーリー


特定の目的に合わせてスライスする

もっとも贅沢な朝は？寝坊した朝は？


追加オプション

苦痛：うまくいっていないところ
疑問：なぜそれをするのか？
アイデア


おすすめのステップ

誰のためか、なぜマップを作るのか明らかにする
全体像をマッピングする（深さにはこだわらない）
掘り下げる
リリース戦略を切り出す（最小限を探す）
学習戦略を切り出す（検証できる最小限）
開発戦略を切り出す


第6章


人は同じドキュメントを読んで違う理解をする
完璧なドキュメントを作ることをやめ、語ることにしたのがストーリー
３つのC

カード
会話
確認（受け入れ基準）


言葉と写真
☆記憶を呼び起こすものをちゃんと残しておくのが大切そう。蒸発させない

第7章


テンプレート

[ユーザータイプ]として、私は[これこれの結果を得る]ために、[これこれを]したい


テンプレートにしばられない

who/what/why を明らかにすればストーリーは語れる


コメントを書く手段を残しておく
チェックリスト

whoをリアルに

ユーザーという言い方はやめる
ユーザーが1人だけであることはまずない


what

ユーザーのタスクを考える
ログインはユーザーが意図的にやりたいことではない

誰がなぜそれを重要視するのか


why

突き詰める

他のユーザー、ユーザーの会社、ビジネスステークホルダーが重視する理由


ソフトウェアの外の世界

いつ、頻度、状況、そばにいるのは誰？


うまくいかない可能性

代替案は？
システムがダウンしたら？
今はどうしてる？


疑問と暗黙の仮定

本当にこれを使う？暗黙の仮定を置いていないか
依存しているシステムや技術を仮定に置いていないか


もっと良い方法について語る

会話の仮定で、最初の頃よりいろんな要素が明らかになるはず
時々立ち返ることで、よりよいソリューションにたどり着くこともある


How

ソリューションについてもきちんと語る
例えばソフトウェア開発で、技術者であれば考えているはずだが、ちゃんと議論する
専門分野に経緯をはらいお互いから学ぶ
☆結局のところ、リスペクトを前提におかないと


期間

推定でいいので、語っておく
「非常に長い時間」「数日」など


バケーションの写真

記憶を思い起こさせるものをちゃんと残しておく
参加者の名前を書き起こしておく
写真を撮って、Wikiなどでシェア


第8章


着目点はそれぞれ異なる

プロダクトオーナー、アナリスト、テスター、デザイナー。。


カードは図書館の目録カード

追跡できるようにする


カードに書いてあるモノ

タイトル
説明
規模
価値（重要度）
メトリクス（効果測定の指標？）
依存関係（前提となるストーリー）
状況
日付（追加した日、議論開始日、終了日）


ツールに踊らされない、共通理解を築くことが大事

リモートのメンバーの場合工夫が必要
全員が同時に参加できること


思い出せるようにする

写真、ビデオ、テキスト


可能な限りカードとホワイトボードで仕事をする
分析や追跡はツールの方が向いている

進行状況の順位づけ、追跡、分析


第9章


共通理解は人に渡せない

見取り図、全体像はあなたの頭のなかにあるから


ストーリーを語り継げるようにする

ドキュメントでは誤解が生まれる
シンプルなアウトプット（バケーションの写真）


意思決定は少人数で行う

語り継げるようにしておけば、最小限の人数で済む


☆バケーションの写真、っていうのが新しいドキュメントの形なのかも
仕事の結果を点検する

UX

つかいやすい？面白い？統一性は？


機能品質

バグやテストのフィードバック


コードの品質

技術的負債


共通理解した通りのものができたか？

できたけっかそれは期待どおりの結果をえられたか？


ユーザーが実際に使うところを見てみたほうがいい

☆これは本当にそうかも


学習を前提にする

何かをつくり、修正し、また修正する
検証可能な学習を


第10章


ケーキを作る

誰のためのものか、何のためのものか、好きなものは
小麦粉が何カップか、焼き方は、といった話はしない


大きなものは分解する

ケーキとは違う、大きなプランに分解するのはよくない

材料をはかる、混ぜる、焼く、など


カップケーキをたくさん作る

できるだけ早く味見できるように


半分しか焼けてないケーキではなく、半分のしっかり焼けたケーキを

全員がおいしく食べることはできる


#第11章

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

ユーザならニーズ
開発チームなら構築とテストに2日位
ビジネスなら業績に役に立つ


ストーリーを小さくするのは岩を砕くようなもの

どこまでが岩でどこからが小石か。表現にこだわらない
分解する必要があるものをエピックと呼んでもいいかも
用語にはこだわらない


アイデアはオポチュニティバックログ

新機能、改良、問題点
作るかどうかは分からない


MVSの発見

顧客とユーザーは誰か
今はどうやってニーズを満たしているのか
どう変わるのか
どのような形でどう振る舞うのか
構築にどれくらい時間がかかるのか


ストーリーの細部を語る

スクラムではバックログリファインメント
共通理解を持てるまで必ず行う


作っている間も語る

見落としがあるのが人間だもの


振り返る

製品の品質、プラン、作業内容
スクラムでのスプリントレビューやレトロスペクテ

ィブ


ユーザーとともに評価する

学習のためのフィードバックを期待する


ビジネスステークホルダーと評価する

MVSについて語る


リリースしてからも評価を続ける

新しいオポチュニティを掴む


第12章


プロダクトオーナー一人にすべてのストーリーを押し付けるのは間違っている

コラボレーションを生むことが必要
判断は必要。設計は民主的なものではない


価値があって、使いやすく、実現可能なスイートスポットを見つける

専門知識がカバーできる少人数のディスカバリーチーム
プロダクトオーナー
UXデザイナー
シニアエンジニア
コラボレーションのハブになる


スリーアミーゴス

詳細を語る最後のタイミング
開発者、テスター、ディスカバリチームのメンバー
掘り下げ、受け入れ基準を一致させる
ストーリーの分解

１〜３日でテストまで可能なサイズが理想


クライアント・ベンダーアンチパターンに嵌らないようにする

要件の合意（見積もり、約束）ではない
ウェイターと客ではなく、医者と患者の関係になる

患者自身が処方箋をもってくるわけではない
医者は診断する


プロダクトオーナーはプロデューサーになる

御用聞きにならない
ステークホルダーにとっての医者になる


第13章


オポチュニティの議論

誰のためのものか
どんな問題を解決しようとしているのか

代替案、競合


イメージの共有
なぜ必要か？

ビジネス戦略との合致性


サイズ

どれくらい実現にかかるかザックリ


深く掘り下げるか、ボツにするか、再考するか決める

ボツは素晴らしい結果


☆読み取れるメッセージ

作らないことが重要

やりたいことの方がいつだって多い
やらないということを選択したのは素晴らしい成果だ


共通理解が何よりも大切
ストーリーを語るんだよ、ストーリーを！


現在のストーリーマッピングを行う

ジャーニーマップになる

違う色で議論すると、ホットスポットが見つかるかも
オポチュニティになる


第14章


ディスカバリーはソフトウェア構築のためにやるのではない
ビジネスの立場からのアイデアの枠組みを作る
顧客とユーザーを理解する

軽めのペルソナをスケッチする
誰も見ないのでは意味が無い、共同作業で作る
組織のペルソナ、オーグソナを作る
現在のストーリーマップ、ジャーニーマップを作る


ソリューションのイメージを描く

言葉では足りない、絵を描く

ユーザインタフェースの共通理解を得る


技術的な課題をチェックする
抜け漏れがないかチェックする

カーチェイスや銃撃戦だけを語っていないか？
そこに至るまでの経緯やその後を考える


最小化する

学習のための最小限にする
捨てるものの方が多いくらいでなければうまくいっているとはいえない


優先順位はビジネスゴールで考える、つまり全体像が見えてから決める必要がある

☆全体像を見えるようにするのがストーリーマップだね！


ディスカバリーを部屋に閉じこもってやるようなことではいいものは作れない

第15章


見つけたMVSは殆どの場合間違っている

純粋な失敗でないが、成功ともいえない
うまくいくのが2割、失敗も2割、どちらでもないのが6割


誰も文句を言わないのは、誰もまともに使っていない時だ
仕事は出荷してから始まるのに、出荷したら祝杯をあげる
デザイン思考を使う

まず共感する

ユーザ、顧客と直接話す
データでは共感を得られない


定義する

「特定の人々」と「特定の問題」を選ぶ


アイデア創出

ストーリーマップを使うのがいいかも


プロトタイプ

紙のようなシンプルなものでよい
ユーザーと顧客自身が評価できるようなものまで改良する


テスト

バグを見つけるテストではない
本当に問題を解決できるか？をユーザーと顧客自身に評価してもらう
Fakeを使い、実際の動作が想像できるようにする


デザイン思考も失敗する

ニーズとターゲットを絞らない
調査に長い時間を使う
データだけを見て、人と話し学ぶ時間を取らない
多くの人のために多くの問題を解決しようとする
アイデアを一部の人だけが出す
複数のソリューションを検討しない
見た目だけのプロトタイプ
ソリューションに盲目的になる（素晴らしいはずだ！）
コストを度外視している（許容されるとしても）
期待しない成果から学習しない


デザイン思考にリーンスタートアップを

構築-測定-学習

スタートアップに限ったものではない


推測から始まる
リスクの高い仮定に名前をつける

仮説が間違っていた場合のリスク


小さいプロトタイプを設計-構築し、テストする
MVPは完全な製品でなく、学習のために構築できる最小限の製品
顧客やユーザーとともにテストを実行する
ソリューションと仮設を考えなおす
学習できないことが失敗である


第16章


ストーリーワークショップを行い、構築に向けて細部を掘り下げる
生産的な規模で行う（3〜5人）

UIについての有識者（UXデザイナー、プロダクトオーナー、アナリストなど）
実現可能性を理解している人（開発者）
どうなる？を真剣に考えられるよう手助けできる人(テスター)


オプションを検討する

ターゲットユーザ
ユーザは本当にそれを使うか？
UIはどうなるか
どう作るか（期間の予測）


意見統一を図る

完成確認時に何をチェックするか
レビューの際のデモの内容


記録を残す
実例を使って話す
必要に応じてストーリーを分割する
ワークショップが機能しないケース

1人が説明し、全員がそれを聞く
受け入れ基準ばかり気にして、誰が何をなぜについて語る人がいない
機能と技術両方の観点からオプションを検討できていないとき


アジャイルのプランニングミーティングが長引いてしまう

拷問から開放されるために合意する
別の日に動かしても同じこと
オプトインを認める
フィッシュボウルコラボレーションを使う

会話できる人は円の中にいる人だけ（5人までなら入っていい）


プランニングのレシピ

準備

１〜２週間前からストーリーを選択しておく
事前にワークショップを行う
チーム外の人々も招集する


プランニング

大きな目標から議論する
ストーリーの全体像を理解する
デリバリチームのためのタイムボックスを設定する

プロダクトオーナーは質問に答えられるようすぐ近くにいる


個別のプランを作る
全員一致でプランを決定する


お祝いをする

プランができあがったらそこでその日の仕事を終わり、次の日からリフレッシュして始める


デリバリーでストーリーマップを活用する

ストーリーマップをバックログにする
可視化されている状態


ストーリーワークショップではシンプルなミニマップを作る

第17章


すべての大きなストーリーを全部最初に細かくする必要はない
段階によって少しずつ小さくしていく

オポチュニティ

事業戦略に沿っているか


ディスカバリー

価値があり、使いやすく、実現可能な製品のイメージ


開発戦略

リスクを考慮し、学習する


次の開発プラン

構築するものと、完成を確認する方法


細かくなりすぎたストーリーは組み立て直す

小さなストーリーはまとめる
巨大なバックログは官僚的


マッピングをやりすぎない

会話をサポートするためのもの
ある機能開発のためにシステム全体をやるのはtoo much


小さなやり残し無駄な労力は使わない

第18章


チームプロダクトレビュー

スプリントレビューでは全員が集まる

ステークホルダーには共通理解を持っていない人もいる
☆スクラムは理想形。ステークホルダーみんなが共通理解を持っていたほうがいいに決まっている


チームプロダクトレビュー

共同作業を行ってきた人たちだけで行う

プロダクト
プラン
プロセス


ステークホルダープロダクトレビュー

ディスカバリーの成果
デリバリーの成果


十分なもの

意識しないが、それぞれにないと困るものが揃っている

ステークホルダー
顧客
ユーザー


ユーザーテスト

ショーアンドテルでなく、テストしてもらう


リリースから学ぶ

観察期間の設置
メトリクスを組み込む


期限が来た時

ソフトウェアに本当の完成はない
成果が保証されることは決してない
リリース後に加えた改良はもっとも価値がある


マップでリリース準備

各アクティビティに通信簿のように評価を与える
評価の高いものだけリリースできるように


第19章


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