- Amazon.co.jp ・本 (368ページ)
- / ISBN・EAN: 9784873117324
作品紹介・あらすじ
「ユーザストーリマッピング」提唱者による書き下ろし!
「ユーザストーリマッピング」は、Jeff Patton氏が提案する計画手法で、顧客の視点からサービスや商品の要件を記述することを特徴とします。XPを実践するためのプラクティスの一つで「ユーザストーリー」があり、これはワークショップ形式で機能を洗い出しながら、インデックスカードに記録して並べ替えていく手法です。
感想・レビュー・書評
-
プロダクト開発に関わるあらゆる人にとって福音書となり得る。
アジャイル開発について、これまで色々なものを読んできたが、この本で自分のなかでは一通りの道具が揃ったように思える。これからアジャイル開発を勉強する人には、以下の書籍と併せて本書をオススメしたい。
・アジャイルサムライ−達人開発者への道−(http://booklog.jp/item/1/4274068560)
・アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~(http://booklog.jp/item/1/4839924023)
アジャイルサムライで、その意義とチームとしてどうあるべきか、全体像を学ぶことができた。次に、アジャイルな見積もりと計画づくりで、計画そのものではなく”計画づくり”が重要であることとその技法を学んだ。この時点でも、アジャイル開発について、ある程度は腑に落ちていたのだが、出発地点であるストーリーの作り方については、ずっと模索している状態だった。これを解決したのが本書で、ストーリーの出し方、整理の仕方、ステークホルダーとチームへの活用など、あらゆることが惜しみもなく書かれている。
システム開発ではなく、プロダクト開発としてみると、例えば営業のプラン作りにも活用できるのではないかと思える。プロダクトはシステムだけで成り立つわけではなく、そこには沢山の役割の人が関わる。ストーリーマップの主戦場はシステム開発なのかもしれないが、これを介してプロダクトをプロダクトに関わる人すべてが考えることができる優れたものであることが分かった。
著者も言うように、端々のトピックは誰かが既に述べていたものであるかもしれないが、それらをストーリーマップという言葉と形でまとめあげ、通貫したものとしたことは賞賛に値する。オライリーから出ているから技術書だろう、などと思っては非常に損。詳細をみるコメント0件をすべて表示 -
多くのユーザーのなかから一人に絞ってその人を満足させるとしたら、誰にする?
海外の人はこの手の質問が非常に上手い。問いが自由で本質的。
ー基本的な質問ー
大きなアイデアとはなにか?
顧客は誰か?ユーザーは誰か?
彼らはなぜ製品を使いたいと思うか?なぜ私たちがそれをつくるのか?我が社にとってどんな意味を持つのか?
すべてのリリースを実験として扱い、何を学びたいのかを忘れないようにする。リリースすると区切りのごとく打ち上げしてしまうが、本来ならKPI達成時点で打ち上げするべきだ。開発をしているうちにビジネスの目的が見えなくなっていく。
■ストーリーマッピングの6つのステップ
1.問題の枠組みを明らかにする
2.全体像をマッピングする
3.掘り下げる
4.リリース戦略を切り出す
5.学習戦略を切り出す
6.開発戦略を切り出す
学習戦略という考え方が斬新。
■ユーザーストーリーを確定するための3層構造
1.最初は粗いステップを明らかにする
2.ユーザーロールごとに細かいアクティビティに分割する
3.「〈ロール〉という立場から、私は〈価値〉を得るために〈機能〉が欲しい」という形式で具体化する。
例)
〈ユーザータイプ〉として、私は〈これこれの結果を得る〉ために、〈これこれ〉をしたい。
バンドマネージャーとして、私はチラシをカスタマイズするためにイメージをアップロードしたい。→ここから議論がはじまる
ーロンジェフリーズの3Cー
カード・・・ソフトウェアに望むことをカードに書いていく
会話・・・集まってどのようなソフトウェアをつくるかについて会話する
確認・・・ソフトウェアが完成したことをどのように確認するか意見を統一する(受入基準、デモ)
全体を可視化して議論する。見えているカードに対して意見を積み上げていくのだ。
ーぼやきー
価値とは何だろうか?どうパターン化されるか。
パターン化できるならばフレームに則って価値検討、実現手段に落とせる。価値とはなにか -
目的:ユーザーストーリーについて理解する
感想:とても勉強になりました。ユーザーストーリーという言葉の意味、実際の使い方がよく理解できました。
その他プロダクト開発の進め方について勉強になる点が複数あり、とても参考になりました。
今後も教科書的に読んでいきたいと思います。
要点:
・ユーザーストーリーはユーザーの行動ストーリーである。誰に、何を、なぜで考える
・ユーザーストーリーはプロダクト開発に関わる人たちとの共通理解のためにある
・ユーザーストーリーには大きさがある。時にはエピックと呼ばれたりする。開発用のストーリーは1日2日程度でテストまでできるもの(ここが1番知りたかった)
・ユーザーストーリーを考えて最小のアウトプットで最大のアウトカムを出す、結果インパクト(事業成長)を狙う
・オポチュニティ(アイデア)発生→オポチュニティ評価で進行判断→ディスカバリーでMVP(MVS)を決める→ストーリーワークショップでストーリーの分割調整→制作、の流れ
-
BDD系の本
ソフトウェア開発をするのであれば、確実に読んでおきたい一冊 -
本書の一番最初でも注意しているが、これはユーザーストーリーの書き方の本ではない。ストーリーはあくまで共通理解を得るためのものであり、大事なのは会話。という内容。
-
もう一週間早く読めば良かった…
プロダクトディスカバリーについてこれでもかとポイントをおさえている良書。早速実践します。 -
気づきが多い本だった。ただ、今の自分には使いどころが難しい感じなのが残念。
-
プロダクト開発を始める前に一度読んでおくと良い
自分達が作りたいプロダクトが誰にどんな価値を提供するのかを整理できる
※根本的に業務のやり方を変える場合はストーリーマッピングではなくクリティカルシンキングがベター -
ソフトウェア開発の話が中心のため、思っていたよりもエンジニア向きな内容で、そうでないものにとっては少しイメージのしにくさを感じた。
ストーリーマッピングの意義(必要性)は本書を通じてよく理解できた。
ページ数は多いものの、同じことが繰り返し書かれている印象。
印象に残ったのは以下の内容。
・「要件」という便利な言葉を使うことのリスク
(ウェイターではなく医者であれ)
・あれもこれもとやろうとせず優先度の高いことの実現に集中すべき
・機能よりもユーザーの価値を優先すべき
-
開発においてどうストーリーを位置づければよいのかについて知りたくて手にとった。ところが、この本はどうやってストーリーを作るのかについての本ではない。どうやって必要なものをリリースできるのかについての本だったのだ。完全なものを求めてもリリースできなければ仕方がないのだ。そこをどう折り合いをつけるというよりは決めるのかについての本なのだ。そのためにストーリーをマッピングするというのがこの本の提案。日本に馴染みのない例の部分はわかりにくい部分は多少あるけれど,それを補う面白さがある。次に作るものではこの方法を取り入れて考えてみたい。
-
システム構築において非常によい組み立て方を教えてくれるいい本だったと思う。
-
よんだ
-
新しいソフトウェアを開発する上でのユーザーストーリーの重要性が理解はできた。実践の中で読み返しながら、つまづいたポイントについては再学習が必要なほど、内容は充実していた。
-
2.00
-
良かった。
エンジニアも読むべし。
アジャイル実践しているが、ユーザーストーリをうまく使いこなせていない。諦めてしまったのなら、これ読んでリトライしよう -
大事だなと思ったところ。
・ストーリーを使う目的は共通理解を作ること。
・ストーリーは要件ではない。
・ドキュメントで共通理解を作るのは難しいので、記憶を助けるドキュメントを。
・作れるものは限りある中で最大限の成果とインパクトを狙う。
中盤から文章が頭に入ってこなかったり、実装にどう繋げるか理解出来なかったので読み直したい。
-
ざっと目を通した。
繰り返し何度も読む本 -
ストーリーの位置付け、活用方法について理解が深まった。前半は実例を交えた説明があり大変わかりやすい。後半はアジャイル開発やスクラムの説明焼き直しの感があり冗長にも感じた。
-
プロダクト開発におけるユーザーストーリーマッピングの解説書
具体的な方法論とベースとすべきマインドの解説がわかりやすい
「ストーリーを話すのは共通理解のため」
最も印象に残ったのはこの部分
作成者、承認者、指示者、被支持者..
内部統制対応以後、役割、責任分解を守るためにアウトプットばかり多くなる古い仕組みでのシステム開発に携わっていた自分のは興味深い内容だった -
(図書館員のつぶやき)
ソフトウェア開発にとってはぴったり!の本。目次に目を通しただけでも開きたくなるかも知れませんよ!使えると思います、借りてみらんね。 -
ソフトウェア開発だけでなく、様々な企画や作業内容の確認などにも使える手法だと感じた。もちろんソフトウェア開発の場合には超有用なので必読といっても良いかも。
-
読み終わった
-
4章のモナリザが一番しっくりきた。
ある程度経験のあるエンジニアが陥りやすいパターンだと思う。
最初から最後まで要件が変わらないのであればパズルみたいにパーツを組み合わせて作った方がうまくいくんじゃないかと思う。
しかし実際のソフトウェアの開発では要件が途中で変わらないことの方がまれだ。 -
ユーザーストーリーマッピングの手法を分かりやすく解説しているのももちろんそうなのだけれど、それ以上に「いいプロダクト」を作るためのヒントがたくさん書いてあるいい本。