KDOC 169: 『ユーザーストーリーマッピング』

この文書のステータス

  • 作成
    • 2024-05-19 貴島
  • レビュー
    • 2024-05-20 貴島

概要

ユーザーストーリーマッピングは、ストーリーマッピングの手法を解説する本である。アジャイルによって分割されたストーリーの全体像を把握するテクニックを解説している。

メモ

  • 火星探査機の話(p4)
  • 完璧なドキュメントを書こうとするのを阻止しなければならない、と主張する。何かを書いて、言葉と絵で会話をして、共通理解を築いていく(p6)
  • 「ストーリー」の由来は、何を書くべきかではなく、どのように使うか。開発でストーリーを使っても、言葉と絵を使って会話していなければ間違っている、という
  • 世界を観察すると、不満、怒り、当惑している人々がいることに気づく。彼らを手助けできそうなアイデアを「要件」とよぶ(p11)
    • タブレットで困り果てながらも練習する祖母を思い出した
  • 欲しいのはソフトウェアやアウトプットではない。それを使って得られる成果、だという(p11)
  • より多く、早く作ることではなく，より少なく作るのが重要だという(p14)
  • ストーリーマップを作るときのスローガンは、「話して記録」だという(p25)
  • 膨大な作業が必要なことが明確になる。そこから現実的な量に削り、優先順位をつけていく
  • MVPの定義(p57)
    • 望まれる成果を実現できる最小限のソリューション
  • 「気に入った」、「使いやすい」と言ってくれた人々も、そう推測しているにすぎない可能性がある、という(p65)。個人でも、買わなきゃよかったものなんてよくある
  • プロトタイプに測定手段を埋め込んでいたので、人々が本当にソフトウェアを使っているかどうか、ソフトウェアの中で具体的に何をしたかを調べることができた、という(p67)
  • フィードバックには会話から得られた主観的なものもあれば、データから得られた客観的なものもあった、という(p69)
  • 学ぶことが目的の、最小限の製品を作る。自転車からバイク、自動車というように進化させていく(p70)
  • 目標は、自分が正しいものを作っているかどうかを、できる限り早く学ぶこと(p73)
  • 期限内に仕事を追えるために、画家や作家のように、イテレーションで仕事する(p87)
  • 日常生活を題材に実践して学ぶ(p92)
  • ストーリーカードにおける3つのC(p119)
    • カード: たくさんのカードを書く、またはストーリーマップを書く
    • 会話: 言葉や絵を使って会話を促進する
    • 確認: 開発に入る際は、受け入れ基準を使って合意の記録を残す
  • テンプレートゾンビ。無理やりテンプレートに押し込もうとしている人だという(p128)
  • ユーザーという言い方はやめよう。具体的のどのユーザなのか言おう、という。音楽ファンとか、バンドマネージャーとか(p131)
  • ストーリーを語り、ソリューションについて決定を下そうとしているときの第一の目標は、共通理解を築くこと。そして共通理解を築くのに、ホワイトボードの前で顔を突き合わせて話をする以上の方法はない、という(p145)
  • ストーリーの詳細を誰かに渡してソフトウェアを作ってもらおうとしても、決してうまくいかない。ほかの人が見ると、よく伝わっていない(p153)
  • アジャイルプロセスでは、学びは目的だ。作るものからどれだけ学びを得られるかを考える。間違いのために時間を使うプランを立てる、という(p157)
  • 検証された学習にするためには、作る過程で何を学びたいかを議論し、作った後で結果について考える、という(p159)
  • ストーリーと、詳細な各自の仕事(デリバリータスク)は違う。ストーリーについて議論したい(p163)
  • ストーリーの適正な大きさは、ロールによって異なる。ビジネスにとっての適正サイズ、ユーザ・顧客にとっての適正サイズ、開発にとっての適正サイズ。適正サイズは ビジネス > ユーザ > 開発 の順になる
  • 開発で求めているのは学習すること。「これはどうもただしくなさそう」とか「本当に使うなら、こうだともっとよさそう」という形を取る。逆に「これは素晴らしい」を期待してもいない(p184)
  • ベンダー・クライアントの関係はアンチパターン。医者と患者の関係が望ましい、という。医者に、〜の薬を処方してくれとか、〜の手術をしてくれとは言わない。ただ症状を伝える(p196)
  • ペルソナの組織版、オーグソナ(p220)
  • デザインスタジオは、すばやく行えるアイデア出しの手法(p225)
  • 残したアイデアよりも、捨てたアイデアの方が多いくらいであれば、ディスカバリーの仕事をできてない可能性が高い(p232)
  • ほとんどの人が犯す優先順位付けの誤りは、まず機能の優先順位を決めようとすることだ、という。機能の優先順位を考える前に、具体的なビジネスゴール、顧客、ユーザ、それから彼らの目標を用いて機能を選ぶ。それから優先順位付けをする(p234)
  • デザイン思考アプローチの最初のステップは共感である。製品を開発した結果として大切なことが、「その製品のユーザになると、実際どう感じるものなのか」を理解することだから。ユーザに近い体験をして、できる限り理解しなければならない(p243)
  • デザインプロセスの表(p246)
  • 『アントレプレナーの教科書』でいっていること。最初に開発する必要のあるものは製品ではなく顧客である。ソリューションに興味を持つ顧客が見つかったかどうかを継続的にチェックする。頭の中にあるソリューションは彼らが買い、使い、他の人に勧めるようなソリューションになっているかをチェックする。構築、測定、学習(p248)
  • 従来のデザインプロセスの血管は、学習と設計に非常に時間をかける部分にある。時間をかけるあまり、ソリューションに愛着を持ってしまい、ソリューションが本当に有効化をチェックし損なってしまう(p248)
  • ストーリーワークショップのレシピ(p264)
  • ワークショップは自発的でやる気がないといけない。無理に参加させる意味はない。オプトインを認めるようにする。希望者が多すぎる場合は、フィッシュボウルコラボレーションの形を取る。関心のある人はいつでも途中参加でき、関心がなければ途中退出してもよい。円に入らなければ、少し遠くから見るだけでもよい(p271)
  • 途中で仕事を点検できるのは大切。点検できるから、途中の段階の仕事を評価し軌道修正できる(p274)
  • グッド・ベター・ベストゲーム(p274)
  • ストーリーは、アステロイドゲームに似ている、という。大きい岩を撃つと小さい岩に分解する。欠片が飛んできて危険だ。小さい岩を撃つとなくなる。アステロイドの戦い方でよくないのは、すべての大きな岩を撃ってそれを小さな岩に分解してしまうことだ。同様に、すべての大きいストーリーを分解してはならない。バックログはあちこちに飛んでいく無数の小さな欠片でいっぱいになる(p288)
  • ストーリーを分解する手順(p288)
    • オポチュニティ
    • ディスカバリー
    • 開発戦略のプランニング
    • 次の開発サイクルのプランニング
  • バックログに数百もの項目を抱えている製品チームを見かける、バックログの優先順位づけに苦労していると言う。バックログを覗くと、小さなストーリーが無数にあることが多い、という。カードに書き出し、並び替え、大きなストーリ、複数のストーリーにまとめる(p290)
  • ストーリーマップはユーザと製品のアイデアについての会話をサポートするもの。議論する必要がなければその部分のマップを作る必要もない(p292)
  • ユーザにデモを見せ、使ったところを想像してもらい、気に入ったところを判断してもらう方法ではユーザから多くを学ぶことはできない、という。ユーザに実際に使ってもらうと、ソフトウェアがユーザの抱えている問題を解決できるかどうか評価するのに役立つだろう。そして、ユーザが使っているところを観察すれば、チームとしてより多くのことを学べる。製品をユーザがそう評価するのはなぜか、どのように使っているか。時間を割いて、ユーザがソフトウェアを使って現実の作業をしているところを観察する(p304)

感想

関連

なし。

Backlinks