誰も書いていない操作をストーリーマップで掘り出す
「機能一覧はすべて実装した。テストも全部通った。なのにリリース後、バグ報告が止まらない」。こうした報告をよく見ると、原因は実装ミスよりも誰も要件に書いていなかった操作であることが少なくありません。入力の途中でブラウザを閉じた、戻るボタンで前の画面に戻った、スマホで始めた手続きをPCで続けた。どれも利用者にとってはごく自然な行動ですが、機能一覧には現れません。
この記事では、要件定義の段階でこうした「抜けている操作」を見つける方法として、ユーザーストーリーマッピングの作り方と点検リストを紹介します。
なぜ機能一覧では抜けが見えないのか
機能一覧は「システムが何をできるか」を並べたものです。「会員登録」「商品検索」「カートに追加」「決済」と項目は揃っていても、それぞれの間で利用者が何をするかは書かれません。
たとえば「決済」の項目があっても、次のような問いには答えていないことがほとんどです。
- 決済画面で戻るボタンを押したら、カートの中身はどうなるか
- カード情報の入力中にセッションが切れたら、どこから再開するか
- 注文確定の直後に取り消したくなったら、どの画面から操作するか
こうした問いの答えは、実装者がその場で決めることになります。決めた内容が人によってばらばらになり、それが後から「仕様通りに動かない」というバグ報告として返ってきます。
ストーリーマップの作り方
ストーリーマップは、利用者の操作を時系列で横に並べ、詳細を縦に積み上げた地図です。付箋とホワイトボード、またはオンラインのボードツールで作れます。
1. 主要アクティビティを横一列に並べる
利用者が目的を達成するまでの大きな流れを、左から右へ5〜8個程度で並べます。ECサイトなら「探す」「比べる」「カートに入れる」「購入する」「受け取る」のような粒度です。
2. 各アクティビティをステップに分ける
アクティビティの下に、利用者が実際に行う操作を並べます。「購入する」なら「配送先を入力する」「支払い方法を選ぶ」「確認画面を見る」「確定する」です。ここで大事なのは、システムの機能名ではなく利用者の動詞で書くことです。
3. ステップの下に詳細とバリエーションを積む
各ステップの下に、具体的な操作や分岐を縦に積みます。「配送先を入力する」の下には「登録済みの住所を選ぶ」「新しい住所を入力する」「郵便番号から自動補完する」などが並びます。
4. 時間軸を逆走させて読む
完成したマップを左から右へ読むだけでは、正常な流れしか見えません。右から左へ、つまり戻る方向に読むと、「確認画面から配送先入力に戻ったら入力内容は残るか」といった問いが自然に出てきます。
抜けやすい操作の点検リスト
ステップごとに、次の4つの観点を当てはめてみてください。付箋が1枚も貼れない観点があれば、そこが要件の抜けです。
- 中断: このステップの途中で画面を閉じる、通信が切れる、スリープする。入力内容はどうなるか
- 再開: 中断した後に戻ってきたとき、どこから始まるか。時間が経って情報が古くなっていたらどうするか
- 取り消し: 直前の操作をなかったことにできるか。できないなら、確定前にそれが伝わるか
- 別端末での続き: スマホで始めてPCで続けたとき、状態は引き継がれるか。2つのタブで同時に開いていたらどうなるか
加えて、ブラウザの戻るボタン、ページの再読み込み、ボタンの2回押しも各ステップで一度は確認しておくと安心です。
記入例: 「支払い方法を選ぶ」ステップ
- 中断: カード番号入力中にタブを閉じた → 再訪時は空欄に戻す（カード情報は保持しない）
- 再開: 15分以上経ってから戻った → 在庫と価格を再確認し、変更があれば明示する
- 取り消し: 支払い方法を選び直したい → 確認画面から変更リンクで戻れる
- 別端末: スマホで選んだ支払い方法をPCで見る → カート内容のみ引き継ぎ、支払い方法は再選択
この4行が要件として書かれているだけで、実装者が迷う場面と、テスト観点の抜けが同時に減ります。
よくある失敗
- 開発者だけで作る: 実装の都合で操作を並べてしまい、利用者の実際の動きとずれます。PM・デザイナー・CSなど、利用者の行動を知っている人を必ず入れます
- 正常系の地図で満足する: きれいな一本道ができた時点で終えてしまうのが最も多い失敗です。点検リストを当てるまでが作業だと決めておきます
- 作って終わりにする: マップは仕様変更のたびに更新します。新しいステップを足したら、その場で4観点を当て直します
Bugoon での実践
ストーリーマップで洗い出した操作は、リリース後に実際に踏まれたかどうかで答え合わせができます。Bugoon のウィジェットはサイトにタグを埋め込むだけで動き、報告時に報告前の操作ステップを自動で記録します。「戻るボタンを押したら入力が消えた」という報告が届いたとき、どの順番で操作したかがレポートに残っているので、マップのどのステップの、どの観点が抜けていたのかをすぐに特定できます。
スクリーンショットとアノテーションで画面の状態を示し、GitHub Issue 連携で開発チームに渡し、カンバンボードで対応状況を追う。届いた報告をストーリーマップに付箋として書き戻していけば、次の要件定義で同じ抜けを作らずに済みます。