はじめに
- 「ユーザーストーリーマッピング」のまとめと感想。
- "ユーザーストーリーマッピング" とは、なんのために製品を作るのかを明確にすることで、なにを作るのかを決めるためのテクニックだ。
- 本書は書名の通りユーザーストーリーマッピングについての解説と、ユーザーストーリーマッピングを用いてなにを作るかを明確にすることでより少ないアウトプットでより大きな成果を得ることができるアジャイルな開発プロセスについての紹介が記載されている。
- 「なんのために作るのか」を主軸にすることでソフトウェアの方向性が定まり「なんのために作るのか」が共有されることでソフトウェア開発の精度が上がっていく。アイディアとしてはシンプルでありながらとても強力なプロセスに魅力を感じたので復習のために内容をまとめてみる。
ストーリーとは
- ストーリーとは特定の形式のドキュメントではなく、問題解決のための議論であり、何を作るかについての意見を一致させるためのプロセスだ。
要件だけでは誤解する
- 要件として書かれたドキュメントを読んだだけでは書いた人の思惑のとおりに理解される保証はどこにもない。大体の場合は誤解される。
- 「カレーの材料を買ってくる」という要件があるとする。具体的な食材が記載されていないので豚肉がほしいのに鶏肉を買ってきてしまうかもしれない。
- それでは食材を具体的に記載すればいいか？食材を買い間違えたあとならそう言えるだろう。それでは買ってくる店や望ましい値段、食材の選定基準などどこまで記載すれば間違いのないドキュメントになるだろうか？
- 誤解されない完璧なドキュメントは存在しない。あるいは仮に記述可能だとしても全てのドキュメントを完璧にしようとすることはコストがかかりすぎて現実的ではない。
- どうすれば誤解されることなく要件を伝えられるのか？要件について話し合うのだ。
- 要件が誰のためのものでありなんのためのものであるのかについて話をし、必要であれば簡単な図や絵を使ってお互いの理解を共有し合うことで意見を一致させることができる。
- 本書ではこのプロセスのことをストーリーと呼んでいる。
ストーリーと要件の違いは
- 要件が「なにをする」というただのタスクだとして、ストーリーは「だれが」「なんのために」「なにをする」ということについての議論であり、タスクの背景を説明しタスクについてのチームの意見を一致させる役割を持つ。
- たとえば「カレーの材料を買ってくる」という要件に対してストーリーは以下のような感じだ。
顧客 「カレーの材料を買ってきてください」
製作者「誰が食べるためのカレーですか？」
顧客 「うちのこどもに食べさせるためのカレーです。うちのこはカレーが大好きなのです。」
製作者「こどもということはルーは甘口がよろしいですね？買ってくる材料は具体的には、じゃがいも、たまねぎ、にんじん、豚肉、カレールー、でよろしいですか？」
顧客 「いいえ、子供は成人していて辛いものが好きなので辛口でお願いします。じゃがいもは家にあったのでいらないです。それ以外のものはおっしゃっていただいたもので問題ありません。」
製作者「わかりました。それでは、たまねぎ、にんじん、豚肉、カレールー（辛口）を買ってきます。」
- 上記の例ではストーリーを使うことで要件の時点では不確定だったルーの辛さについての意見が一致した。
- また、ストーリーとして具体的に物語ることでじゃがいもは不要であるという重大な項目を発見することができた。
- さらに、製作者がよりよいカレーのレシピを知っていたら提案することもできるし、おすすめのカレー屋さんを教えることで外食に変更ということになりカレーの材料を買ってくるという要件がなくなるかもしれない。
ユーザーストーリーマッピングとは
- ユーザーストーリーマッピングとは、ソフトウェアの製作目的を整理し、ストーリーを作り分割しまとめるという操作である。
- この操作を通じて、ソフトウェア全体の製作目的や個々のストーリーがソフトウェアの中でどのような役割を果たすのかが明確になり、次になにを作るのかという判断の助けを得ることができる。
- それでは実際にユーザーストーリーマッピングを試してみる。
なんのために作るのか
- まずはソフトウェアが実現することによってなにがしたいのか、なんのために製作するのかを書き出していく。
- この「ソフトウェアによってやりたいこと」をオポチュニティ（機会）と呼ぶ。
- オポチュニティには対象ユーザーがいるはずなのでペルソナも書き出してオポチュニティに関連づけていく。
- オポチュニティが出揃ったら優先順位をつけていく。
なにをするのか
- 次に各オポチュニティを具体的なストーリーに落とし込んでいく。
- オポチュニティの数が多かったら優先度が高いものだけでいい。
- まずは大きい粒度でストーリーにしていき、ソフトウェアの利用フローの順に左から右に並べていく。
- まずは利用フローの最初から最後まで一通り把握するために、あえて詳細には踏み込まない。
さらになにをするのか
- 大きいストーリーを分割して小さくする。小さいストーリーは大きいストーリーの下に優先度順に並べる。
なにから作っていくか
- ストーリーが出揃ったら実際に作っていくが、全部作るのは難しい場合は、どのストーリーから作っていくかを決める。
- 最初に作り出すストーリーの選び方としては、例えば特定のペルソナや特定のオポチュニティに関連づくストーリーだけを選んだり、すでに絞り込み済みであれば小さいストーリーの優先度順に選んでいく。
ユーザーストーリーマッピングを使った開発プロセス
- ユーザーストーリーマッピングを使うことでなんのために作るのかが明確になり、より少ないアウトプットでより大きな成果を得ることができるアジャイルな開発プロセスを利用することができる。
作るものを減らす
- いつも私たちが持っている時間やリソース以上に、作るべきものが存在する
- ユーザーストーリーマッピングを使ってなんのために作るのかを明確にし、やるべきことを絞り込んで作るものを減らす。
- ストーリーによりなんのために作るのかという意識をチーム内で統一することで、目標から外れた無駄なものを製作することがなくなり、各人の裁量内で目標を叶えるより最適な製作方法が選択できるようになるので、作るものを減らすことができる。
より早く学ぶ
- ユーザーストーリーマッピングによって作るべきものが決まったらいきなり作り出すのではなく、プロトタイプを作ってユーザーに試してもらうことで、オポチュニティがただしいのかどうか学習することができる。
- プロトタイプで十分な成果が得られたら、引き続き学習のために必要最小限の機能だけを実装した製品を作り、ユーザーに試してもらい成果を計測する。
- こうして実験、計測、学習を繰り返すことで、アイディアを検証しながら省コストで製作を行うことができる。
時間通りに終わらせる
- ユーザーストーリーマップは会話の助けに必要な分だけ作ればいい。
- 既存の製品に追加しようとしている機能についての会話をしたいならば、製品全体のマップを作る必要はなくその機能についてのマップだけを作る。
- ユーザーストーリーマップを横に3つにスライスして順次製作していく。
- 一つ目のスライスでは機能を一通りとりあえず動くようになるところまでを目標に製作する。
- 機能間のフローの調整や結合は作り込んでから調整するほどリスクが高くなるので先に調整してしまいリスクを回避する。
- 製作できるかどうか不明確でリスクが高いストーリーなどもここに入れる。
- 二つ目のスライスでは機能を作り込んでいく。
- 三つ目のスライスではリリースできるように製品に磨きをかける。
- このようにインクリメンタルに実装し続けながらイテレーティブに改善し続ける。リスクを早期に解消して納期を守る確率を上げつつ出来る限りクオリティを上げていく。
おわりに
- 開発プロセスというと大きすぎて手に負えないイメージがあったが、「なんのために作るのか」ということを軸にして考えることで、カードを並べたり、成果を測定したり、レビューしたりという退屈に感じていたことの意義がわかるようになってきたので、良い勉強になった。
- 「本当は、あなたの仕事は世界を変えることだ」という言葉は最初イタいなと思ってしまったが内容を理解できてきたらいい言葉に思えてくる。
自分はいま世界を変えられているだろうか？自覚的でなければきっと世界は変えられない。ソフトウェアはコードだけじゃなく世界を変えようという意思でできている。