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

目的

顧客の要望を聞き取り、一覧にした。30件並んだ。それを見て、何から作るかの議論が始まらない。

要望が多いのではなく、並べ方が優先順位を考えられない形になっている。本書を読む目的は、一覧を地図に変えることにある。

論点1 縦に並べず、使う流れに沿って置く

本書の中心は並べ方だ。機能を縦に積むのをやめ、利用者が探す・比べる・申し込む・使うという流れで横に置く。

• 縦の一覧 … どれも必要に見えて、削れない
• 横の地図 … 横に薄く切ると、使える最小の一式が取れる

並べ方を変えるだけで、「全部必要です」から「まずこの列」へ議論が動く。顧客との優先順位の会話に使える形になる。

いちこ

一覧にすると、全部必要だと言われてしまいます。

シュン

一覧だとそうなるんだ。流れに置くと、どこが先かは顧客自身が言い出すよ。

論点2 作った数ではなく、起きた変化を見る

本書が区別するのが、作ったものと起きた変化だ。機能12件を予定通り作ったは、何も起きていないことと両立する。

• 作ったもの … 機能12件、予定通り
• 起きた変化 … 入力の手間が半分になった

予定通り作ったのに使われないという状態は、左端だけを見ている。営業が顧客と確かめるべきは真ん中の列になる。

論点3 言葉が一致しても、認識は一致していない

「ダッシュボードが欲しい」で合意した気になる。だが営業は案件一覧を、顧客は経営報告を、開発はグラフを思い描いている。

• 言葉で揃える … 一致した気になるだけ
• 具体で揃える … 誰が、いつ、何を見て、何を決めるのか

商談で聞いた本当の目的を開発に渡す役は営業に回る。渡し方の勘所は アジャイルサムライ のインセプションデッキに。

いちこ

同じ言葉を使っていたので、合意できていると思っていました。

シュン

そこが一番こわいところだね。一致して見えるから、確かめなくなるんだ。

この本の限界と、次に読む本

開発チーム向けに書かれており、分量もある。営業として使うなら、並べ方と優先順位の章だけで足りる。期日と範囲の交渉なら アジャイルサムライ、発注側の責任範囲なら システムを「外注」するときに読む本 が隣に並ぶ。