記事に「#ネタバレ」タグがついています
記事の中で映画、ゲーム、漫画などのネタバレが含まれているかもしれません。気になるかたは注意してお読みください。
見出し画像

BOOK#25「ユーザーストーリーマッピング」

●今回読んだ本

「ユーザーストーリーマッピング」―ジェフ・パットン著(出版社: オライリー・ジャパン・ジャパン|2015年7月25日発行)

●内容メモ #ネタバレ

▽概要
ケント・ベック提唱。ストーリーの山を作った時、とかく見失われがちな全体像を提供するためのテクニック。ストーリーを作る本当の目的は共通理解をつかむことである。
※注意…共有ドキュメントは共通理解ではない。ドキュメントは記憶を助けるために存在する。私たちは同じドキュメントを読むことができるが、違う理解をする。完璧なドキュメントを書こうとするのを阻止しなくてはならない。なんでもいいので何かを書こう。それから、言葉と絵で生産的な会話をして、共通理解に気づくのである。
※共通理解…互いに相手がイメージしていることとその理由を理解していること。

▽要件定義
あなたのアイディアについて細かく会話をし、設計、仕様策定に入る。これらの作業を誰か他人に委ねる場合にはこの詳細全体のことを要件と呼ぶ。しかし要件とは、私たちが持っている「人々を手助けできそうなアイディア」の別名であることを忘れないのが大切だ。

▽ベロシティ(速度)
アウトプットは必要なものだが、アウトプットは私たちが本当に欲しいものではない。本当に欲しいものとはアウトプットの後に結果として現れるものだ。それを成果(アウトカム)と呼ぶ。成果とは、物が世に出た(Come-out)ときに何が起こるから。アウトプットを最小限に抑え最大限の成果とインパクトを獲得しよう。いつも私たちが持っている時間とリソース以上に、作るべきものが存在する。


▽ユーザーストーリーマッピングとは
(1)ストーリーは、要件を形式に落とし込むためのものではない。言葉と絵を使いながらストーリーを話すのは、共通理解を築くためのメカニズム
・ストーリーがストーリーと呼ばれているのは、何を書くべきかではなく、それをどのように使うべきかだからだ。
・ストーリーマッピングとは、大きなストーリーを話しながら小さく分割していくことだ。
・アイデアを書き留めていなかったり、参照されることがなかったりするのは非常にまずいことである。
・1つのストーリーを掘り下げる前に、全体としてどのようなストーリーがあるのかを明らかにしよう。そうすることでストーリーマップの幅がハッキリする。

(2)ストーリーは要件ではない。会社、顧客、ユーザが抱える問題の解決についての議論であり、何を作るかについての意見を一致に導くものだ
・やりたいことを全てリストアップし、その中で優先順位をつける。最も高い評価をつけたものについて話をし、1度に1つずつそれを作っていく。この機能リストはアジャイルの世界でバックログと呼ばれている。
・次にアクティビティーを細部に分解していく。ユーザストーリーの個々のステップで立ち止まり、具体的、代替案、不具合時の対処、装飾などの細部を決定していく。

(3)あなたがしなければならない事は、より早くより多くのソフトウェアを作ることではない。作ると決めたものから最大限の成果とインパクトを生み出すことだ
・作る物を減らす(条件、MVP、リリースロードマップ)
・より早く学ぶ
・時間通りに終わらせる(リスク、必要最低限、見積)


▽方法
●ストーリーを書き出す

ソフトウェアを使う人々がそれぞれの目標を達成するためにしているタスク(短い動詞)はユーザタスクと呼ぶ。ユーザタスクは、ストーリーマップの基本的な構成要素であり、ユーザーによって違う。タスクは岩のようなものである。大きな岩にハンマーを打ち込むと、それは小さな塊に分割される。小さな岩も相変わらず岩だ。タスクでも同じである。小さなタスクから大きなタスクを見分けるためには「ゴールレベルの概念」を用いる。
※ゴールレベルの概念…以下の3つの軸により、小さなタスクを1つに纏めたり、大きなタスクを分割したりする。
(1)機能レベルのタスク(シャワーを浴びる)
(2)サブタスク(お湯の温度を調整する、髪を洗う、…/海面レベル)
(3)サマリーレベルのタスク(身支度を整える ※1連のタスクをまとめる|“身支度をする”を構成する他の“海面レベル”のタスクとセットにする|歯を磨く、デオドラント、ヘアセット)

●ストーリーを整理する

(1)タスクを書き出す
タスクとタスクを結ぶ接続詞句は「それから私は」である。左から右の時系列で語るストーリーの順序をナラティブフローと呼ぶ(物語の順序)。そしてその全体をマップと呼ぶ。

(2)見落としがないか確認する
いちどマップを作り上げたら、次に、細部、代わりのタスク、変種、例外等はマップの本体に入れる。そうすることで見落としを防ぐ。ほぼ同時に行われる事は縦に並べる。マップの縦方向にはバリエーションや代わりのタスクが含まれる状態になる。

(3)フローを整理し直す
タスクをつなぐために別の接続詞も使ってみよう。例えば「いつもはこれをするが、時々これをする」とか「これかこれをしてから、これをする」など。

(4)マップからバックボーンを抽出する
一歩下がって左から右にマップ全体を見てみると、まとまって発生するように見えるストーリーの塊があることに気づく。いくつかのタスクが塊として、より大きい目標に到達するためにまとまって発生する様子が見えてくる。類似するポストイットのグループの上に色の違うポストイット(もしくは形の違うポストイット)を置く。これをアクティビティと呼ぶ。アクティビティとして、同じような人々が同じようなタイミングで特定の目標を達成するために行う1連のタスクを1つにまとめる。アクティビティは、共通の目標に向かうタスクを集約し、これとおおまかなタスクがストーリーマップのバックボーンを形成する。
※マップを作るときのポイント…製品、顧客のためにマップを作るときには、彼らが呼んでいる言葉や呼び方を使うようにする(ユーザーに適した言語レベルに合わせる。

(5)ある成果を得るための最小限のタスクをまとめスライスを切る
MVPの見極め。必要なタスクが見極められ、詳細が理解できるようになる。

●ストーリーマッピングの6つのシンプルなステップ
1.問題の枠組みを明らかにする
2.全体像をマッピングする
3.掘り下げる深いほうに向かって進み、他のタイプのユーザについて他のやり方について、どのようなタイプの誤りが起こり得るかを想定する
4.リリース戦略を切り出す
5.学習戦略を切り出す
6.開発戦略を切り出す

●ロン・ジェフリーズの3つのC

・カード(Card)
・会話(Conversation)
・確認(confirmation)

●5つのC
カード→会話→確認→構築→結果→カード…
・構築…議論の場で記録したメモや写真を見て西部思い出しながら地位もソフトウェアを作る
・結果…作ったものを最初はチームとして次にビジネスステークホルダーとともに評価し最後に顧客、ユーザとのテストで評価する

▽オポチュニティ
ストーリーの旅はアイデアから始まる。それは新規のアイディアかもしれないし、新製品のアイディアかもしれない。すでにある機能を改良するはずの変更かもしれないし、解決しなければならない問題かもしれない。それら全部をオポチュニティ(機会)と呼ぶことにする。それは利益が得られる何かを作るチャンスだからだ。
ストーリーについての最初の議論は、オポチュニティ(好機)の枠組みをつかむためのものだ。そして、オポチュニティを仮説として扱い、解決しようとしている問題が本当に存在するかを確かめよう。オポチュニティの議論では、その問題を解決する価値があるかどうかを判断する。それが前進かボツかの判断となる。判断できるだけの情報を持っていない場合には、学ばなければならないことのリストを作り、必要な情報の収集に努めよう。情報集めても前進かボツかを判断できない場合には、オポチュニティバックログに戻して後で議論することもできる。これを延期と称する。
課題解決をイメージするために、スケッチを描きプロトタイプをつくろう。自分のソリューションが価値のある使えるものかどうかを知るために、プロトタイプを作ってユーザに見てもらう。

▽オポチュニティーキャンパス(キャンバス駆動アプローチ)
1.問題またはソリューション
2.ユーザと顧客
3.現在のソリューション
4.ユーザが得る価値
5.ユーザへの効果の測定方法
6.採用されるための戦略
7.ビジネス問題
8.ビジネスへの効果の測定方法
9.予算

〔説明〕
キャンパス内のボックスには、オポチュニティについての議論で使える論理的な順序に従って番号がつけられている。他の人とキャンバスを共有している場合には、左から右、上から下に言うようにする。左から右のフローは、アウトプットと成果のモデルの「現在」から「将来」に向かっている。上から下は、ユーザのニーズからビジネスのニーズに移っていく。これは、書き込みをしていくフォームではなく、議論し、反復的に理解を深めていくべきテーマの集合である。
※このキャンバスは情報を空間的に組織する。キャンバスは大きく、重要な懸案をすべてを1カ所にまとめるので、グループで見ながら作業できる。
※キャンパス内の構成によって、依存関係がわかる。情報は、依存する他の情報の隣に配置される。
※共同作業を通じて皆でキャンバスを作り上げていくことにより共通理解が得られ自分の仕事と言う意識が高まり、全員の足並みが揃うため、全員の力が結集される。


●その他

▽なぜ読みたいと思ったのか
デザインスクールでユーザーストーリーマッピングについて学んだものの、もう少し深く知識を得たいと思ったから

▽興味を持ったきっかけ
デザインスクールでユーザーストーリーマッピングについて軽く学んだこと

▽この本を読むことの意義
ユーザーストーリーマッピングをより正しく認識し、より有意義に活用したい

▽どんな本の内容だと思って手に取ったのか
ユーザーストーリーマッピングの概念や手順についてより深く学べると思って

▽実際読んでみてどんな本だったのか
思っていた以上に読みやすい。カラーだし、かしこまりすぎていない文章と構成で。とはいえ、内容を完璧に読み砕けているかという自信はないけれど…読むのに抵抗なく読めると思う。途中に出てきた『私はよく「ダヴィンチならどうするだろう?」と自問する。というのは嘘で、本当はそんなことはしていないのだけれど、するほうがいいんじゃないかとは思っている。』の表現は嘘なんかい!と心の中で突っ込んでしまったので、面白い表現だなーと思った。笑

▽タイトルをつけ直す(要約)とすると?
ユーザーストーリーマッピング指南書

▽知らなかった単語(用語)について
・ロン・ジェフリーズの3つのC、その発展の5C


●Amazon



この記事が参加している募集

最近の学び

この記事が気に入ったらサポートをしてみませんか?