「ユーザーストーリーマッピング」を読んだ

ちょっと前に読んだINSPIRED 熱狂させる製品を生み出すプロダクトマネジメントにこれを読むべし！と書かれていたのでユーザーストーリーマッピングを買って読みました。（なお、書籍代は会社の福利厚生で補助が出ます。本当にありがたい）

内容に関する感想

雑に残します。

• ストーリーを使う目的は、良いストーリーを書くことではない
• 製品開発の目標は、製品をつくることではない
• ストーリーとは、どのように書くべきかではなく、どのように使われるかについてつけられた名前
• ストーリーをもとにチーム内で会話することが大切
• ストーリーにおける会話とは、お互いが理解している問題を最もよく解決できる方法に到達するために共同作業すること
• ストーリーマッピングは製品のビジョンをバックログに変換し、自分たちが何を（What）開発するつもりなのか、誰のために（Who）なぜ（Why）開発するのかを理解するための方法
  • ストーリーにはWhat、Who、Whyが必要
• Whoには「ユーザー」という言葉をなるべく使わない。ユーザーにも色々な種類があるので、具体的にできれば良い
• MVP（Minimum Viable Product）は過程を証明または反証するために作れる、あるいは実行できる最小のもの
• MVPではなくMVS（Minimum Viable Solution）
• 開発するもののほとんどが新しいプロダクトではなく既存のプロダクトへの機能追加や機能の改善であるため、製品というよりソリューションであるという考え（個人的にはめちゃくちゃ賛成）
• 共有ドキュメントは共通理解ではない。ドキュメントを共有することで自分以外の全員が同じ理解をできる可能性は低い
• 色々なタイプのユーザーから同じように気に入られることは難しいので、ターゲットを絞ろう
• プロダクト開発では何かを作ることではなく、正しいものを作っているかどうかを学ぶことが大切
• 自分だちが正しいものを作っているかどうかは顧客に提供してみないとわからない。それが唯一の方法である。
• ストーリーのおすすめのテンプレ
  • [ユーザータイプ] として、私は [これこれの結果を得る] ために、[これこれを] したい。
• ストーリーのテンプレはあるが、無理してこれに当てはめる必要もない
• ストーリーの真価は、カードに何が書かれているかではない。ストーリーを語ったときの学びが大切。
• リリースした成果物の品質の評価の観点は3つ
  • UX（ユーザーエクスペリエンス）
    • わかりやすいか？使っていて面白いか？見栄えは良いか？
  • 機能の品質
    • バグやエラーなしに最初に意見が一致したとおりの処理が実行できているか？
  • コードの品質
    • コードの品質は高いか？拡張子しやすいか？メンテしやすいか？技術的負債があるかどうかも確認すべし
• 本物のユーザーがソフトウェアを操作しているところを見ずに、何週間も開発を進めるのは避けるべき

書籍全体の感想

まず、ストーリーやユーザーストーリーマッピングに関する知識を得られたのはよかったです。

ただ以下の点はちょっと微妙だなと思いました。（あくまで個人の感想です）

後半は疲れたというか「これ以上読んでも似た内容の繰り返しでは？」と思い、ほとんど読んでいません。（興味があるところをかいつまんでさらっと読んで終わりました）

スクラムとかリーンスタートアップに関する本をあまり読んでいない人にはかなり良さそうと思いました。

気になった方はぜひ読んでみてください。