フクロウの図表ラボ

対象のサービス

「家電製品の出張修理サービス」

• ユーザーは家電製品の修理をオンラインで申請
• 写真等からオンライン上で見積もり提示
• 金額を承認し、日程予約
• 修理業者が訪問、修理 ・修理完了時に確認と支払い　など

といった概要のサービスです。詳細は以下に続きます。

1. 要件のざっくりすりあわせ

ペルソナ

70代の一人暮らしの高齢者で、動かなくなった家電製品（例えばテレビ）を、自宅からオンラインで修理依頼でき、快適な生活を維持したい。

ユースケース

アクター：顧客、修理会社

目標　　：顧客は家電製品の修理をオンラインで申請し、修理が完了した製品を利用したい

主なフロー（メインフロー）：

1. 顧客は、修理会社のウェブサイトにアクセスする
2. 顧客は、修理申請フォームに必要事項（製品情報、故障状況等）を入力する
3. 修理会社は、必要事項から修理費用の見積を提示する
4. 顧客は、修理費用の見積を承認し、日程を選択して確定する
5. 修理会社は、確定内容の確認メールを顧客に送信する
6. 修理会社は、顧客の自宅へ訪問する
7. 修理会社は、修理を実施する
8. 顧客は修理完了を確認し、支払いを行う

代替フロー：
2‐a. 製品の型番がわからない場合は、写真をアップロードして製品を特定する
3‐a. 修理会社が修理不可と判断した場合は、見積を提示しない（断る）
4‐a. 顧客が見積もりを承認しない場合、修理はキャンセルとなる

例外フロー：
5-i. メールサーバーがダウンした場合、メールの代わりに電話で顧客に確認連絡する
6-i. 天災や事故で訪問が不可の場合、改めて日程調整を依頼する
8-i. 修理完了時に決済システムが機能しなかった場合、後日請求を行う

事後条件：
・顧客の家電製品が修理され、正常に動作する状態となる
・修理履歴が修理会社のシステムに記録される

2. 要件の具体化

ユーザーストーリー

<補足> ユースケースの網羅性を確認するため、UC = ユースケース、として上記ユースケースのフロー番号を追加しました。（本来無くてもいいと思います。）

US = ユーザーストーリー、の略です。

UC	US#	ユーザーストーリー
1	US#1	顧客として、家電製品の修理が申し込めるウェブサイトにアクセスしたい。なぜなら、オンライン申込を行いたいからだ。
2	US#2	修理会社として、顧客にアカウント登録をしてもらいたい。なぜなら修理記録を顧客単位で管理したいからだ。
2	US#3	顧客として、修理申請フォームを入力・送信したい。なぜなら、必要事項を送りたいからだ。
2	US#4	顧客として、修理申請フォームの入力を中断した場合、同じ場所から再開したい。なぜなら入力の手間を最小限にしたいからだ。
2-a	US#5	顧客として、修理申請時に型番の代わりに製品の写真をアップロードしたい。なぜなら、型番がわからなくても申込を完了したいからだ。
2-a	US#6	修理会社として、修理申請時に型番の代わりの写真で製品を特定したい。なぜなら、型番無しでも見積もりを可能としたいからだ。
3	US#7	修理会社として、オンラインで受け取った修理申請情報を基に見積もりを作成したい。なぜなら、効率的に顧客に見積もりを提示できるからだ。
3-a	US#8	修理会社として、修理が不可能な場合は速やかに顧客に通知したい。なぜなら、顧客のお金や時間を無駄にしたくないからだ。
4	US#9	顧客として、修理の見積もりを修理日程確定前に確認したい。なぜなら、費用を把握し、修理を進めるかどうか判断できるからだ。
4	US#10	顧客として、修理の日程を選択して確定したい。なぜなら、自分の予定に合わせて都合の良い日時を指定できるからだ。
4-a	US#11	顧客として、修理の見積もり金額に納得できなければ、申込みをキャンセルしたい。なぜなら予算内で修理を行いたいからだ。
5	US#12	顧客として、修理の確定内容をメールで受け取りたい。なぜなら、申込内容を確認し、記録として残せるからだ。
5-i	US#13	修理会社として、修理確定メールが送付完了しなかった場合に通知を受け取りたい。なぜなら、電話で顧客に確認連絡をしたいからだ。
6	US#14	顧客として、自宅で修理を受けたい。なぜなら、重い家電を持ち運ぶ手間が省けるからだ。
6-i	US#15	修理会社として、担当者の訪問が不可になった場合に顧客に日程再調整を依頼したい。なぜなら、顧客に再申込みの手間をかけずにサービスを提供したいからだ。
7	US#16	顧客として、修理完了後に動作確認をしたい。なぜなら、問題が解決されたことを確認できるからだ。
7	US#17	修理会社として、修理完了を顧客が確認したことを記録したい。なぜなら、確認済みの証跡を残したいからだ。
7	US#18	修理会社として、修理内容をシステムに記録したい。なぜなら、将来の修理や顧客サービスに活用できるからだ。
8	US#19	顧客として、修理完了後にその場で支払いを行いたい。なぜなら、後日の支払い手続きの手間が省けるからだ。
8	US#20	修理会社として、支払い完了後に領収書をメールで送付したい。なぜなら、訪問先での領収書発行の手間が省けるからだ。
8-i	US#21	修理会社として、訪問先で決済システムに問題が生じた場合に、支払い案内をメールで送付したい。なぜなら、支払い漏れを防ぎたいためだ。

ストーリーマップ

上記のユーザーストーリーを元に、ストーリーマッピングを行います。

まずは、ストーリー全体を俯瞰して、どんな風に見出しをつければ（区切れば）実装の相談がしやすいか、を考えます。

※ #14、#16のユーザーストーリーはシステムではなくオペレーションで実現するストーリーであることを区別するため、カードを白色にしています。

次に、各カテゴリーごと＝縦列の中で、優先度を考え並べ替えます。

右上にオレンジ矢印のついているカードが優先度を見直した対象です。

最後に、MVPや追加リリース（アップデート）単位で区切ります。

正確である必要はなく、この時点で想定されるイメージを関係者に共有する目的です。

上記画像（3つ）は、以下からPDFでも参照可能です。

3. 要件の実装

プロダクトバックログ

ストーリーマッピングで優先度が高いと判断したユーザーストーリーを「プロダクトバックログアイテム（PBI）」として並べます。

このとき、すべてのユーザーストーリーを一列に並べ直す必要があるので、ストーリーマッピング上では優先度は”並列”だったものも、改めて優先度を検討することが必ず必要です。

また、おすすめなのは、優先度が高くすぐに着手するものは、PBIとして並べるタイミングで、（必要に応じて）詳細度を上げておく、細分化しておくことです。

というのも、次のフェーズでスプリントバックログとして見積もりをするとき、スプリントゴールの対象を定めるときにも、適切な粒度であることは非常に重要だからです。

スプリントバックログ

最後に、”次の”スプリントの準備として、スプリントバックログを作成します。

個々のプロダクトバックログアイテムの「ストーリーポイント」が明確になっていること、また、進める上で必要な「バックログへの補足事項」はここで改めて確認・整理します。