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

  • オライリージャパン
4.16
  • (30)
  • (43)
  • (14)
  • (1)
  • (0)
本棚登録 : 561
感想 : 28
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (368ページ)
  • / ISBN・EAN: 9784873117324

作品紹介・あらすじ

「ユーザストーリマッピング」提唱者による書き下ろし!
「ユーザストーリマッピング」は、Jeff Patton氏が提案する計画手法で、顧客の視点からサービスや商品の要件を記述することを特徴とします。XPを実践するためのプラクティスの一つで「ユーザストーリー」があり、これはワークショップ形式で機能を洗い出しながら、インデックスカードに記録して並べ替えていく手法です。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • プロダクト開発に関わるあらゆる人にとって福音書となり得る。
    アジャイル開発について、これまで色々なものを読んできたが、この本で自分のなかでは一通りの道具が揃ったように思える。これからアジャイル開発を勉強する人には、以下の書籍と併せて本書をオススメしたい。

    ・アジャイルサムライ−達人開発者への道−(http://booklog.jp/item/1/4274068560
    ・アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~(http://booklog.jp/item/1/4839924023

    アジャイルサムライで、その意義とチームとしてどうあるべきか、全体像を学ぶことができた。次に、アジャイルな見積もりと計画づくりで、計画そのものではなく”計画づくり”が重要であることとその技法を学んだ。この時点でも、アジャイル開発について、ある程度は腑に落ちていたのだが、出発地点であるストーリーの作り方については、ずっと模索している状態だった。これを解決したのが本書で、ストーリーの出し方、整理の仕方、ステークホルダーとチームへの活用など、あらゆることが惜しみもなく書かれている。

    システム開発ではなく、プロダクト開発としてみると、例えば営業のプラン作りにも活用できるのではないかと思える。プロダクトはシステムだけで成り立つわけではなく、そこには沢山の役割の人が関わる。ストーリーマップの主戦場はシステム開発なのかもしれないが、これを介してプロダクトをプロダクトに関わる人すべてが考えることができる優れたものであることが分かった。
    著者も言うように、端々のトピックは誰かが既に述べていたものであるかもしれないが、それらをストーリーマップという言葉と形でまとめあげ、通貫したものとしたことは賞賛に値する。オライリーから出ているから技術書だろう、などと思っては非常に損。

  •  アジャイル開発のお勉強。

    ■シンプルな優先順位付けモデル
    ・差別化機能:ライバルとの差を生む機能
    ・相殺化機能:ライバルの差別化機能に近づく機能
    ・コスト削減機能:組織のコストを下げる機能
    ・テーブルステークス機能:市場での競争のための必要な機能

    ■ストーリーマッピングの6つのシンプルなステップ
    1.問題の枠組みを明らかにする
    2.全体像をマッピングする
    3.掘り下げる
    4.リリース戦略を切り出す
    5.学習戦略を切り出す
    6.開発戦略を切り出す

    ■私たちは同じドキュメントを読むことができるが、違う理解をする
     ドキュメントにはたいてい何が必要かが書かれていて、なぜ必要なのかは書かれていない。ソフトウェアを作る人が、将来ソフトウェアを使うユーザーと彼らがそれを使う理由を理解している人と話すことができれば、コストをかけずにそれらのユーザーを喜ばせる方法が見つかる。話をしなければ、大切なことは決してわからない。

    ■最良のソリューションは、解決すべき問題を抱えている人々と、その問題を解決できる人々の間のコラボレーションから生まれる
     …完璧なドキュメントを必死に書くのをやめ、ともにストーリーを語ることにしたのである。

    ■ストーリー駆動とドキュメント駆動
    ・ストーリー駆動:
     共通理解を築くところから始める
     →議論を通じて共通理解を広げる
     →共通理解を形にしたソフトウェアを作る
    ・ドキュメント駆動
     共通理解を築くところから始める
     →ドキュメントだけを読んだのでは理解にずれが生じる
     →作られたソフトウェアが期待はずれのものになっても不思議ではない

     効率的な議論や意思決定は、2人から5人の少人数のグループがもっとも適している。…しかし、人数が5人よりも多くなると、1つの話題で話をするためには努力が必要になってくる。

    ■仕事の結果を点検する
    ・ユーザーエクスペリエンスの質
    ・機能の品質
    ・コードの品質
     書いたコードの品質は高いか?標準に合致しているか?しばらくこのコードを手元に置いておく場合もあるので、拡張、メンテナンスしやすい感じがするか、後で対応しなければならない「技術的負債」があるかどうかを把握しておくといい。

    ■これはあなたのためのものではない
     チームの全員がユーザーの横にいる必要はない。実際、全員が雁首を揃えて待ち構えていたら、ユーザーは逃げ出すだろう。しかし、そこにいると、他の方法では得られていない共感が生まれる。ユーザーが自分の製品を使って苦闘しているところを見ると、俄然やる気が出てくるものだ。

    ■ストーリーが表しているソリューションがコストのかかりすぎるものなら、目標達成に近づく別のソリューションを検討しよう。

    ■ストーリーがコスト的に問題はなくても、大規模なソリューションを表している場合、早い段階で進行状況を評価、確認できる小さな部品に分割しよう。

    ■大きなものを大きなプランに分割してはならない。大きなものは、小さなプランの小さなものに分割するのだ。

     ところで、そもそもカップケーキはウェディングケーキにはならないのではないだろうか?いや、そういうものもあり得る。

  • 多くのユーザーのなかから一人に絞ってその人を満足させるとしたら、誰にする?

    海外の人はこの手の質問が非常に上手い。問いが自由で本質的。

    ー基本的な質問ー
    大きなアイデアとはなにか?
    顧客は誰か?ユーザーは誰か?
    彼らはなぜ製品を使いたいと思うか?なぜ私たちがそれをつくるのか?我が社にとってどんな意味を持つのか?

    すべてのリリースを実験として扱い、何を学びたいのかを忘れないようにする。リリースすると区切りのごとく打ち上げしてしまうが、本来ならKPI達成時点で打ち上げするべきだ。開発をしているうちにビジネスの目的が見えなくなっていく。

    ■ストーリーマッピングの6つのステップ
    1.問題の枠組みを明らかにする
    2.全体像をマッピングする
    3.掘り下げる
    4.リリース戦略を切り出す
    5.学習戦略を切り出す
    6.開発戦略を切り出す

    学習戦略という考え方が斬新。

    ■ユーザーストーリーを確定するための3層構造
    1.最初は粗いステップを明らかにする
    2.ユーザーロールごとに細かいアクティビティに分割する
    3.「〈ロール〉という立場から、私は〈価値〉を得るために〈機能〉が欲しい」という形式で具体化する。

    例)
    〈ユーザータイプ〉として、私は〈これこれの結果を得る〉ために、〈これこれ〉をしたい。
    バンドマネージャーとして、私はチラシをカスタマイズするためにイメージをアップロードしたい。→ここから議論がはじまる

    ーロンジェフリーズの3Cー
    カード・・・ソフトウェアに望むことをカードに書いていく
    会話・・・集まってどのようなソフトウェアをつくるかについて会話する
    確認・・・ソフトウェアが完成したことをどのように確認するか意見を統一する(受入基準、デモ)

    全体を可視化して議論する。見えているカードに対して意見を積み上げていくのだ。

    ーぼやきー
    価値とは何だろうか?どうパターン化されるか。
    パターン化できるならばフレームに則って価値検討、実現手段に落とせる。価値とはなにか

  • アジャイル開発、特にスクラム開発では、ストーリーを優先度をもとに一次元のバックログに並べますが、ユーザーストーリーマッピングはストーリーの元となるユーザーペルソナなどと合わせ、ストーリーを二次元的に並べて整理するもの、でしょうか。

    挙げられたストーリーがなぜこのプロダクトに必要なのかや、ナラティブフロー(ユーザーがプロダクトを使うときに体験する内容を時系列で並べたもの)の実現のために不足しているストーリーの可視化、不要ストーリーのあぶり出しなどにとても効果的だと感じました。

    特にゲーム開発の場合、ユーザーの志向を無視した適当な機能実装を要求されることが多いので(ほとんどの場合、売れてる他ゲームの機能を何も考えずに入れ込もうとするケース)それを却下したいときに役立ちそうな気がします。

    とても勉強になった本書ですが、難点があるとすれば、洋書特有のまわりくどい表現と冗長な文章でしょうか。変な比喩表現をなくしたり、要点を箇条書きにするなどすれば、すっきりした内容になって重要なポイントをつかみやすくなりそう(多分…)。

  • 目的:ユーザーストーリーについて理解する

    感想:とても勉強になりました。ユーザーストーリーという言葉の意味、実際の使い方がよく理解できました。

    その他プロダクト開発の進め方について勉強になる点が複数あり、とても参考になりました。

    今後も教科書的に読んでいきたいと思います。

    要点:
    ・ユーザーストーリーはユーザーの行動ストーリーである。誰に、何を、なぜで考える

    ・ユーザーストーリーはプロダクト開発に関わる人たちとの共通理解のためにある

    ・ユーザーストーリーには大きさがある。時にはエピックと呼ばれたりする。開発用のストーリーは1日2日程度でテストまでできるもの(ここが1番知りたかった)

    ・ユーザーストーリーを考えて最小のアウトプットで最大のアウトカムを出す、結果インパクト(事業成長)を狙う

    ・オポチュニティ(アイデア)発生→オポチュニティ評価で進行判断→ディスカバリーでMVP(MVS)を決める→ストーリーワークショップでストーリーの分割調整→制作、の流れ

  • BDD系の本
    ソフトウェア開発をするのであれば、確実に読んでおきたい一冊

  • 本書の一番最初でも注意しているが、これはユーザーストーリーの書き方の本ではない。ストーリーはあくまで共通理解を得るためのものであり、大事なのは会話。という内容。

  • もう一週間早く読めば良かった…
    プロダクトディスカバリーについてこれでもかとポイントをおさえている良書。早速実践します。

  • 気づきが多い本だった。ただ、今の自分には使いどころが難しい感じなのが残念。

  • プロダクト開発を始める前に一度読んでおくと良い
    自分達が作りたいプロダクトが誰にどんな価値を提供するのかを整理できる
    ※根本的に業務のやり方を変える場合はストーリーマッピングではなくクリティカルシンキングがベター

全28件中 1 - 10件を表示

Jeff Pattonの作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×