User story mapping

© 2019 Core Concept Technologies Inc.
ユーザーストーリーマッピング
株式会社コアコンセプト・テクノロジー
DXD 安宅彰一朗
2021年6月14日

ユーザーストーリーマッピング CONFIDENTIAL
ユーザーストーリーマッピングとは
ざっくり言うと要件定義です。
このソフトウェアで何をしたいかを決めるってことですね。
これだけ聞くと、それいつもやってますやん？
むしろやらないと何も始まらないですしって思うじゃないですか
ということで今回はアジャイル開発におけるストーリーマッピングとは
何なのか、どんなもので、何のためにあるのかというお話です。
ちなみにソフトウェア開発失敗の
半分以上の理由は
要件定義ミスったからです。

アジャイルの思考
理由を理解せず手法だけ知っても意味がありません。
そもそもアジャイルの基本的な考え方に以下があります。
・正解を知っている人などいない（ユーザ自身ですら知らない）
・はじめから正解にはたどり着けない（失敗するしそこから学ぶ）
・情報は他人にうまく伝わらない（伝言ゲーム面白いですよね）
・完璧にソフトウェアの挙動を定義するドキュメントなど存在しない
・常に「実現したいこと」＞「実現できること」である
有名な例のあれ
顧客が説明した要件プログラマのコード

アジャイル的な思考では以下を分けて考えます。
・アウトプット：結果（機能とか処理とかをどれだけ作ったか）
・アウトカム：成果（ユーザーが↑を使って得られた効果）
アジャイル開発の目的は「アウトカムを最大化すること」です。
これを実現する方法は「アウトプットを最小化する」です。
一瞬直感に反しますが理由は以下です。
・成果は使ってみないとわからない
・やりたいこと、は、できることを常に上回る
ソフトウェア開発で最悪なのは「機能を大量に作ったけど何もビジネス的
な成果を産まなかった」です。
（統計的にソフトウェアの機能の60%以上はたいして使われてません）

以下はアジャイルのインクリメンタル開発を端的な絵で表したものです。
部分的な部品を段階的に提供するのではなく、
ユーザーの価値になるものを提供するという思想ですね。
上の絵だと4までユーザに価値が生まれません。
この絵を見て下の1～4無駄やんけと思うかもしれません。
それは結果論です、たまたま正解を知っているからそう思うだけです。
実際には車が正解かどうかはまだ仮説です。
開発チームが得るものは完成したコードではなく
正解に近づいているという学びです。
（実際ここまで劇的な学びがあるのはBtoCみたいな
実際のユーザーがはっきりしていない場合です）
コードはリファクタリングしましょう。
こちらじゃなくて
こちらです！

WFとアジャイルの違い
要件定義の目指す所についてはWFもアジャイルもたいして変わりません。
違いはその進め方と方法です。
・進め方
機能
開発
機能
開発
要件定義
外部設計
内部設計
実装/テスト
WF アジャイル
何やるか決める
正しかったかどう
かわかる

共通理解
学び
WFとアジャイルの違い
・方法
WF
アジャイル
・最初の人が正解を知っている前提
・ドキュメントによる伝言ゲーム
・途中でやることを変えられない
・失敗に気づくのは最後
・正解を見つけることが目的
・対話による共通理解
・優先順位の見直し
・小さく実施、学びを得る

WFの課題おさらい
別にWFでも上手く行くなら良いのですよ。
上手く行かないからみんな日々苦労してるんですよってことです。
おさらいになりますがWFの戦略上の課題は以下です。
• 最初に全部決めるという原則が超絶難度
• 情報共有（ドキュメンテーション）コストが膨大
・WF開発とは「工程をドキュメントというインターフェイスを使って分離する」開発手法です
・前工程との依存関係をドキュメントのみにすることで疎結合にしているということですね
・そのため前工程の経緯など知らなくても次工程の開発ができる（※という建前）
・この手法は「前工程が変わらないこととして膨大なコストを掛けてもペイ出来る」戦略です
・これ前提が間違っていて、変わらないことなんてないですよね？
・現代のソフトウェアは複雑化していて、「◯◯したい」に無限の実現方法があります。
・それを全部ドキュメンテーションするコストが膨大で、しかも頻繁に変わります。
そのメンテナンスコストを払えなくなっているのが現状です。
・現代のソフトウェア開発の戦略として
・全てを予見することは不可能に近く、ドキュメンテーションはオーバーコストになりがち
・そもそも正解を知ってる人がいない（実験するしかない）

これ無駄じゃない？
これ無駄じゃね？やめようぜ、と言ったのがケント・ベックです。
※アジャイルソフトウェア開発宣言の人
「ドキュメントは間違ったものを正確に記述していることが多い」
→思い当たり過ぎて心が痛いですね。
しかも同じドキュメントを読んでも思い描くイメージはみんな違います。
さらに正確に記述することにより量が膨大で開発者はそれを読むのに必死。
そして結局ドキュメントは間違っている。
「ソフトウェアを使う人と作る人が直接会話できれば、
コストをかけずにユーザーを喜ばせる方法が見つかる」
→伝言ゲームは情報が変質します。また一方通行です。
「この要件意味が分からないけど言われたからやる」みたいなこと多いですよね。
解決方法はシンプルです。ドキュメントを必死に書くことをやめ、
ユーザーと直接対話する、それだけです。
効果のない方法をやめて、もっと本質的なことに時間を使いませんか
ということですね。
もちろんこれだって仮説です。ただ2001年のアジャイルソフトウェア開発宣言以降で
どちらの開発手法がより有効だったのかを見れば少なくともこちらの方が筋が良い気がします。

ユーザーストーリーとは
ところでユーザーストーリーとはなんでしょう？
「ソフトウェアの機能をユーザーの観点から、
堅苦しくない一般的な言葉で説明するもの」
良いストーリーの書き方は諸説あります。
• INVEST
（独立、交渉可能、価値がある、見積もり可能、小さい、テスタブル）
大切なことは
• 誰が痛みを感じていて（who）
• 何をしてほしいのかを聞き（what）
• それはなぜなのかを理解する（why）
• そして深堀りする（why, why, why…） ←ここが重要
「客⇔ウェイター」ではなく「患者⇔医者」の関係性です。

要件定義と言ったけどあれは嘘です
厳密に言うとユーザーストーリーと要件は違います。
要件というのは「何を(what)」が書かれているものです。
ユーザーストーリーは文字通り物語です。
誰が(who)、何を(what)、なぜ(why)を語ります。
従来の要件定義の最大の勘違いは
「誰かが正解を知っていて、開発者をそれを理解するだけ」
と思っていることです。（クライアントベンダーアンチパターン）
まあこれは自分たちの身を守るためという部分もあります。
ただし要件通り作ったにも関わらず訴えられて、
しかも負けたりしているので完璧ではないです。

要件定義と言ったけどあれは嘘です
WF畑の人が「従来どおりのドキュメントを作らねばならない」
というストーリーを書いたとしましょう。
意見を出すことは良いことです。
ではそれがユーザーにどんな価値をもたらすのか語ってもらいましょう。
そうして皆の納得が得られれば優先度が上がるでしょう。
判断の場には色々な立場の人がいて、それぞれ関心が違います。
違う立場の人が議論する軸が何かというと
それはユーザーの価値（アウトカム）を高めるかという点です。
※別にドキュメントが要らないというわけではないです。
プロダクト特性、規模、フェーズによって、ドキュメントがないことの弊害が
顕著になってきた場合、作成することがユーザー価値を高める可能性はあります。
結論「プロダクトによる」ってことです。
というよりアジャイル自体「プロダクトごとに最適は自分で考えてね」という考え方です

ユーザーストーリーマッピングの位置づけ
アジャイル開発は「必要なときに必要なことだけ考える」という戦略です。
（1イテレーションに実施することにチームが集中して生産性を上げる）
見通しの良い、近い所から一歩一歩進んでいく
そうすると今居る場所が分からなくなるときがあります。
2週間後のことは分かる、半年後のことは知らん、みたいな。
（俗に漂流アジャイルとか言います）
なんかノリで海に出たけど、今どの辺なんでしたっけ？
みたいなことを避けるための海図、それがストーリーマッピングです。

期待してたらすみません
ユーザーストーリーマッピングは
要件定義をミスらないようにはどうするか、というものではありません。
そんなものはありません。
ないものを追い求めても無駄です、やめましょう。
（というよりはそこを追い求めることが逆にリスクになりがちです
コストが掛かる割に効果が低かったり、時間がかかって機会喪失したり）
• 全体のことをそのタイミングに合った解像度で考え
• 間違っていたら適宜修正する
という方法です。

ユーザーストーリーマッピングのポイント
重要なポイントは3つです。
・関係者の共通理解を得る
マップを作り上げることが目的ではありません。
それはただの結果でありその過程で行われる議論が本質です。
なのでマップだけ見ても意味はありません
（記憶を呼び起こすただの目次です）
・やらないことを決める
アウトカムを最大化する → アウトプットを最小化する、とは
やらないことを決めるということです。
「岩からダイヤモンドを見つけ出す作業」とも表現されます。
・繰り返す
マップは一度決定したら終わりではありません。常に見直しましょう。
学習し改善するというプロセスがアジャイル開発です。
一度決めたら変えられないのは日本人の悪い癖です。

とりあえずやってみよう！
やってみないとイメージ湧きませんよね？
ということでやってみましょう。テーマは「朝やること」です。
まず今日の朝を思い出してください。
やったことを付箋にでも書き出してみましょう。
これが「ストーリー」です。
目覚まし止
める
シャワーを
浴びる
パジャマを
脱ぐ
歯を磨く
顔を洗う
服を着替え
る
ニュースを
聞く

私とあなたは違います
目覚まし止
める
シャワーを
浴びる
パジャマを
脱ぐ
歯を磨く
顔を洗う
服を着替え
る
ニュースを
聞く
大切なことは
• 共通理解を作り上げる
• 意識の穴に気づく
湯船にお湯
をためる
TVをつける
朝ご飯を食
べる
頭を洗う
体を洗う
湯船につか
る
ジョギング
する
同じことだが粒度が違う
→大きさについて議論しましょう
今のフェーズで検討すべき解像度を合わせましょう
コーヒーを
飲む
このストーリーの大きさにも正解なんてないです。
テーマが「お風呂時間」だったらこのレベルでも良いかもしれません。
関係者の意識が揃っていることが大切です。
ジョギング
する
コーヒーを
飲む
かばんに道
具を詰める

時系列に並べよう
目覚まし止
める
シャワーを
浴びる
パジャマを
脱ぐ
歯を磨く
顔を洗う
服を着替え
る
ニュースを
聞く
ナラティブフロー
TVをつける
朝ご飯を食
べる
うまくストーリーが流れるように左から右に並べます。
大体同時に行われることは縦に並べます。
この作業をやっていくと議論が生まれます。
・ストーリーAとストーリーBの前後関係について
・上手くストーリーが流れない。必要なストーリーが足りない（意識の盲点への気付き）
大切なことは「関係者の共通理解を得ること」「意識の盲点に気づくこと」です。
ジョギング
する
コーヒーを
飲む
かばんに道
具を詰める
物事には前後関係があります。時系列で並べましょう
ストーリーを時系列に並べたものを「ナラティブフロー」といいます。

どうなるどうなる
「意識の盲点」をさらに減らして行きましょう。
テーマを「休日の朝やること」や「旅行に行く日の朝」、
「なんかいい感じの朝」とかバリエーションを増やして書き出してみましょう。
1人で思いつく以上のストーリーが生まれるはずです。
ペルソナを設定してみましょう。ユーザーとなる人物を具体的に想定するってこと
です。
そしてそろそろ「アウトプットを最小化する」を意識しましょう。
万人のニーズを完璧にサポートすることなど不可能です。
いずれターゲットとするとしても、1stターゲットの議論はしておきましょう。
田中くん（仮）
・22歳男性
・社会人１年目
・趣味はサッカー観戦
・わりとインドア
ペルソナをどこまで具体化するかもプロダクト次第です。
大事なことは
「このユーザーなら普通こうするだろう」
と想像し議論できることです。

フローを整理する
目覚まし止
める
シャワーを
浴びる
パジャマを
脱ぐ
歯を磨く
顔を洗う
服を着替え
る
ニュースを
聞く
TVをつける
朝ご飯を食
べる
ジョギング
する
コーヒーを
飲む
かばんに道
具を詰める
思いつく限りストーリーを書き出し、時系列に並べ、議論を重ねて行くと
関連性のあるストーリーから大きな流れが見えて来ます。
それを「バックボーン」と呼びます。
xxx xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
身支度栄養補給外出準備
起きる運動
バックボーンは全体の見通しを良くします。
また個々のストーリーが変わってもバックボーンは変化
しないことが多いです。
それだけシステムの根本に存在する概念ということです。

スライスする
さてプロダクトの全体像は見えてきました。関係者の共通理解も上々です。
ここからが重要です。常に「やりたいこと＞できること」なのを思い出してください。
アジャイルには「MVP（Minimum Viable Product）」という概念があります。
「実用最小限の製品」という意味です。
（本書ではMVS（Solution）と表現していたりしますが同じです）
ユーザーストーリーマッピングの目的は「MVPを決めること」です。
開発者が参加しているならざっくりとした見積もりも出せるでしょう。
簡単、普通、大変、すごく大変、ぐらいの感覚で良いです。
意思決定に利用しましょう。
何度も言いますが正確性とか求めても無駄です。
（統計上この時点での見積もりには1/4～4倍の誤差があります。
「見積もりと心理的安全性 - 不確実性コーン」(CCT Blog)

スライスする
目覚まし
止める
シャワー
を浴びる
パジャマ
を脱ぐ
歯を磨く
顔を洗う
服を着替
える
ニュース
を聞く
TVをつけ
る
朝ご飯を
食べる
ジョギン
グする
コーヒー
を飲む
かばんに
道具を詰
める
整理するためにマップの上段に余白を作りましょう。
朝やることで言うと、遅刻しそうな朝はやることを厳選せねばいけません。
ユーザーにとって「実用最小限とはなにか」を議論しましょう。
xxx xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
xxx
起きる運動
MV
P
歯も磨いてないし、お腹も空いてるし、ニュースも見て
ないですが、少なくとも出社はできます。
「最小限の価値とは」を議論し共通理解を得ること
それがシステムを理解するための重要なポイントです。

はじまるアジャイル開発
目覚まし
止める
パジャマ
を脱ぐ
顔を洗う
服を着替
える
かばんに
道具を詰
める
MVPは定義しました。MVPを獲得するために開発を行っていきましょう。
アジャイル開発とは特定の期間(イテレーション)を繰り返すことにより開発する手法
です。
よくある誤解に「2週間ごとにリリースされるんでしょ」というのがあります。
そんなことありません。普通に考えて2週間とか一瞬です。
何度かイテレーションを繰り返しMVPを得る。これが一般的です。
例えば以下のような感じです。
xxx
起きる運動
MV
P
イテレーション1
イテレーション2
イテレーション1何もしてないやんけ、とか思われますが結構大切な期間です。
フレームワークを検討したり、開発基盤を整えたり、CI/CD整備したり、不明な箇所を調査したり…
ここで得られる知見はチームにとって有益なものです。（歩くスケルトン）

繰り返す
ストーリーマッピングで重要なことに「繰り返す」があります。
アジャイルのバックログリファインメントとかグルーミングですね。
1イテレーション経てばその分の知見が開発チームに溜まったはずです。
それをマップに反映しましょう。
• 新しいストーリーが追加されたり
• ストーリーの優先順位が変わったり
• 大きなストーリーを小さく分割したり
少なくとも開発チームは2週間前よりプロダクトについて理解したはずです。
大切なことは当初の計画通り進めることではなく、
その時点でベストな(と思われる)選択をすることです。
参考：エピックという概念について
大きなストーリーを「エピック」と呼ぶことがあります。これは流派によります。
ただ本来ストーリーには決まった大きさはないのでどこからエピックと呼ぶのか論争が勃発します。
もしエピックという単語が出てきたらそう呼んだ人はそのストーリーを
「小さなストーリーに分割したほうがよい」と思ってる、ぐらいに捉えておけばよいです。

まとめ
ストーリーマッピングの手法自体はそんなに難しいことは言っていません。
• 可能ならユーザーと直接対話し
• 誰が(who)、何を(what)、なぜ(why)を考えて
• 流れや優先度に応じてマッピングする
• それを関係者の共通理解とする
なんでこれが上手くいかないのかというと以下のような人が居るからです。
• 計画は不変だと捉えている
• 計画をコミットメント(約束)だと捉えている
• 失敗を許容できない
• 言われたことだけやれば良いと考えている
実はこれはかなり難しい問題です。
個人の意識や思想、企業組織的なインセンティブ設計に関わってくる問題だからです。
ここが徐々に変わってくると良いのですが、、、
経済産業省の「DXレポート2」にもあるように全然進んでませんという状況です。

User story mapping

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to User story mapping

Similar to User story mapping (20)

Recently uploaded

Recently uploaded (8)

User story mapping