ユーザー ストーリー マッピングで顧客を第一に考える

ユーザー ストーリー マッピングの形式は、各ビジネスとチームの構造によって異なりますが、多くの場合、各分野の専門家のチーム (中小企業) を会議室に集め、紙、マーカー、ホワイトボード、ポストイット、その他カメラなどの基本的なツールを提供することから始まります。チームは、これらのツールを使用して、ユーザー、機能、プロセス ステップに関する情報を記録することができます。

最初のステップでは、全員を参加させ、ロール プレイを行います。ユーザー、ユーザーの問題、製品の使い方などを特定することが不可欠です。顧客とやり取りする参加者は、このプロセスに大きな意義をもたらせます。

シンプルなスクリプトを使用して、ユーザー ストーリーを明確にすることができます。「(この製品のユーザー) として、私は (アクションをすること) ができ、(メリットを得る) ことができるのか？」

このスクリプトは、次のようにすることもできます。「クレジット カードの利用者として、オンラインで支払いをスケジュール化して、遅延しないようにできますか？」

異なる色のポストイットを使うことによって、サポートする活動を含むステップバイステップのプロセスを示すのに役立ちます。チームがユーザー ストーリーを作成したら、ポストイットはタイムラインとリリース予定の論理的なスプリントにグループ化できます。

このエクササイズは非常に視覚的であるため、バックログが完全に表示され、問題、計画の不一致、障害、ギャップ、範囲外の機能、代替ソリューション、リスクを明らかにすることができます。これにより、チームはその後の実行計画を立てることができます。

ユーザー ストーリー マッピングのベスト プラクティスには、次のようなものがあります。

• マーカー、ホワイトボード、ポストイット ノート、ステッカー (重要な部分を強調表示する点や星) など、視覚化プロセスを支援するツールを提供します。
• 顧客の視点からストーリーを伝えることができる顧客の代表者に参加してもらいます。
• ワイヤフレームを使用してストーリーをサポートします。
• 各ユーザー ストーリーには、誰が、何を、いつしたかを記述してください。
• 各ユーザー ストーリーを 1 回のイテレーションでコード化できる程度に具体的にします。

Shai Shandil, Agile Coach with Softsolutions, is a Certified Scrum Professional trained by Jeff Patton. He advises, “Teams should be co-located (at least temporarily). The presence of clients or their representatives adds value to the process, and tactile tools (a big wall, painter’s tape, sticky notes, markers) are very useful.”

シャンディル (Shandil) 氏と彼の率いるチームが使用したユーザー ストーリー マップのサンプルは、こちらをクリックしてください。

X/Y 軸: 設計者と開発者が共同作業する場所

ユーザー ストーリー マップはさまざまな形式で表示できますが、ほとんどの場合、X 軸と Y 軸を含むダイナミックなビジュアルで表示されます。横軸 (x) には、ユーザーがシステムを使用する際に体験する活動の順序を表示しています。縦軸 (y) は、機能の高度化を表示しています。最初の行には最も基本的な機能が含まれており、後続の行はより複雑になっています。

以下のテンプレートを使用して、ユーザー ストーリーをマッピングすることができます。これは、Microsoft Word で入力したり、壁にポストイットを付けて再作成したりできるサンプル テンプレートです。ボックスの数は、特定のシステムを使用している間に行われる活動によって異なる場合があります。

‌  Word テンプレートをダウンロード

Jonathan Roger, Operations Director with AndPlus and Certified ScrumMaster, applies user story mapping when working with clients. “First, we write epics (very large user stories). Once we have the high-level user flow for an application, we order the epics along the top of a board. Under each epic, we place smaller, individual user stories. Each of these represents one way to use the system. The final step is to prioritize in order to define the minimum viable product for our client’s end-users.”

以下に、MVP を金色で強調表示した X/Y のサンプル図です。

実際のアジャイル作業とリーン作業は、マップの完了時に開始できます。

全体像が決まったら、デザイナー、開発者、関係者と一緒に「マップを順を追って見る」ことが大切です。ユーザーがこの作業に参加できれば、結果は実体験に沿ったものとなります。このプロセスでは、チームはユーザー ストーリー マップを見直して、不足部分を埋めたり、忘れられた要素を特定することで、より強力な製品作りを目指します。

マップが完成したら、スプリントとイテレーションの計画を立てます。そこでチームはアジャイル、リーン、スクラムの言語と実践を用いてタイムラインを定義し、エピック、バックログ、タスクを開発して割り当てることでプロジェクトを始動させます。

ユーザー ストーリー マッピングによりアジャイル方法論とリーン方法論を簡素化

ユーザー ストーリー マッピングは、アジャイル開発方法論およびリーン開発方法論をサポートします。アジャイルは、細かい作業と迅速な納品に重点を置いています。ユーザー ストーリー マッピングは、グループ化して優先順位を付けることができる機能のバックログを作成することで、この反復的なアプローチを可能にします。

ユーザー ストーリー マッピングの課題: 集中力の維持

顧客のニーズを理解するには、調査を行い、感情移入をすることが必要です。これにより、課題が生じ、チームの初期計画や期待事項に支障が生じたり、変更されたりする可能性があります。カスタマー エクスペリエンスにできるだけ近い調査を行う必要があります。アンケートやインタビューは常に役立ちます。カスタマー サービスの技術者、営業担当者、UX デザイナーは、顧客の視点から物を見る経験が豊富であるため、何かを見つける手助けとなる場合があります。

ユーザー ストーリー マッピングの一般的な課題を以下に示します。

• 明確性の欠如: ユーザー ストーリー マッピング プロセスを開始する前に、ターゲット顧客とソリューションが解決する (または解決する予定の) 問題を把握することは不可欠です。
• チームの拠点: チームが異なる場所にいて対面で作業できない場合、計画、会議、コミュニケーション面での課題が発生する可能性があります。
• 文書化: 場合によっては、最初に行われるチームの話し合いで何を含めるかといった内容が、適切に文書化されなかったり、重要度がランク付けされていない場合があります。また、ホワイトボードや付箋に書かれている内容が文書化されていないと、紛失してしまう可能性があります。バックログを作成すると、冗長な作業のように感じ、異なるストーリーの積み重なりとなり、プロジェクトを理解するのが難しくなります。
• 焦点: ストーリーは、ユーザーの受容性や必要性以外の理由で機能に焦点を当てる場合があります。エンド ユーザーが不可欠と判断したものが、このバックログの中に埋もれてしまい、製品に取り入れられたり、新しいバージョン用のバックログとして割り当てられたりすることができません。