「ユーザーストーリーマップ」を使用して要件を分割し、製品のMVPを正確に定義します

スタートアップ企業で、まだユーザーストーリーマップを使用したことがない方は、ぜひお試しください。本日ご紹介するのは、Jeff Patton 氏の「ユーザーストーリーマップ」における要件分割手法です。製品の成功は、競合他社よりもユーザーのニーズを満たすことにかかっていますが、これは簡単なことではありません。なぜなら、多かれ少なかれ、次の 3 つの罠に陥ってしまうからです。>>1. 需要自体を理解し、中核となる問題点を把握できるようにする。>>2. 独自の方法でそれに対応することを選択する。>>3. 需要の実現をさまざまな規模のストーリーに分割し、競合他社よりも迅速かつ適切に実行する。この記事では、3 番目の落とし穴に焦点を当てます。これは、多様な需要がある複雑な製品に特に当てはまります。ストーリーマップメソッドを習得すると、ユーザーの行動を観察してユーザーの行動パターンを抽出するインタラクティブプロダクトマネージャー、ユーザーエクスペリエンスに焦点を当ててユーザーのハイポイントを見つけるユーザーオペレーション、またはビジネスプロセスに参加して他の部門と連携するその他の役割のいずれであっても、これは需要分割中に全体像を把握するための手法であり、部門間の連携中にコミュニケーションをとるためのより効果的な方法であることがわかります。

MVPとは何ですか?

最小限の実行可能な製品 (MVP) は、望ましい結果を生み出すことができる最小の製品リリースです。ここで明確にする必要があるのは、「最小限」とはどのユーザーに対するものなのかということです。これらのユーザーはソフトウェアを通じてどのような目標を達成する必要がありますか? また、完全に新しい製品はほとんどなく、既存の製品に新しい機能を追加したり、既存の機能を改善したりすることが多いです。したがって、最小限の実行可能なソリューションについても話すことができます。最小限の実行可能なソリューションとは、期待される結果を生み出すことができる最小のリリースプランを指します。

最初の MVP リリースの仮定を学習して検証することに重点を置くのではなく、小規模な実験やプロトタイプを設定して、最小限かつ実行可能な製品についての推測を検証する必要もあります。したがって、MVP はまったく製品ではありません。最小限の実行可能な製品は、仮説を検証するために行われる最小の実験です。

MVPを見つけるにはどうすればいいですか?

多くの場合、完璧な製品を作るにはやるべきことが多すぎて、すぐに圧倒されてしまいます。すべての機能が揃っていることはとても重要なように思えますが、特定のユーザーとユーザーが目的を達成するための基本的な機能について考えてみると、これらのユーザーと要求は 1 つまたは 2 つの簡潔な文章で要約できることがわかります。まず、ユーザーストーリーマップを作成します。全員が異なるチームから来ており、各チームが異なる領域に重点を置いていますが、目標は製品を提供することです。この製品を提供するには、全員が協力する必要があります。リリース計画は各チームの視点に基づいて作成することはできず、すべての依存関係を視覚的に表示する必要があります。ストーリーマップは、合意を形成し、チームが依存関係を視覚化するために使用されます。ストーリーマップを作成するプロセスは、デザインの落とし穴を発見するのに役立ちます。私たちは、他のチームが本当に必要なことを知らないのに、他のチームが対応してくれるだろうと思い込んでしまうことがよくあります。場合によっては、一部のデザインで主要な機能間の重要なつながりが失われていることに気付くことがあります。チームがユーザーストーリーマップを作成するときに、不足している部分を事前に発見できます。ユーザーストーリーマップディスカッションミーティングを開催しましょう！準備する必要があるものは次のとおりです。>>1. 比較的邪魔されないスペース。>>2. ホワイトボード（製品が複雑で、多くのユーザー行動を伴う場合は、床、ガラスの壁などを使用できます）。>>3. 約 5 人のディスカッショングループ（製品、ビジネス、インタラクティブデザイン、操作など。人数が多すぎると情報が制御不能になりやすいため、注意してください）。>>4. 付箋紙数枚（できれば異なる色）。

この会議の目的は、参加者全員が各アクションごとに付箋を使用して、製品の使用シナリオで発生するすべてのユーザー行動をタイムラインに沿って左から右に記述することです。同時に起こる出来事は同じ位置の下に書きます。同じシーンに異なるアクションの可能性が現れた場合、異なる分岐アクションが形成されることがあります。メインラインに戻るか、分岐ラインが終了するまで続きます。この記述プロセスでは、ユーザーアクションが発生する順序について全員が議論するため、非常に騒がしくなる可能性があります。その途中で、これまで考えもしなかった詳細も発見されるでしょう。

これらの詳細こそが、関係者全員に利益をもたらす可能性があります。これは、自分自身に対して何らかの前提を確立しないボトムアップのアプローチであることを覚えておくことが重要です。これにより、ある行動を「必要」か「不要」かを判断したかどうかを忘れることができます。パノラマ画像が表示されたら、同時発生している無関係な画像を結合して、ルートの主要ノードでどのユーザーエクスペリエンスが非常に重要であるかを確認できます。ユーザーストーリーの観点から自社製品を見ると、全体的な状況をすぐに明確に把握できるようになります。ストーリーマップが完成すると、やるべきことが多すぎて、すべてを完了するにはプロジェクトの期限がほぼ無限であることがわかります。このとき、「xxx 効果を達成するには、すべての機能コードを使用する必要がありますか?」と自問する必要があります。システム外部の予想される結果に焦点を当てて、システム内で必要な機能を特定します。次に、MVP リリース計画を分割します。最初のリリースで実行する必要があるコンテンツをユーザーストーリーマップに分割し、残りを後続のリリースで完了します。思考プロセスは、次のようになります。「xx の期待値内で xx の結果を達成できれば、製品は発売時に見栄えが良くなります。リリース計画のすべての機能は、ユーザーの基本的なニーズであり、驚くべきものであり、目を引くものです。」結果、つまりリリース後にユーザーが使用して認識できるものに焦点を当て、リリース計画は結果指向である必要があります。次に、リリースロードマップを分割します。ストーリーマップ全体には多くの内容が含まれていますが、すべての機能を完了するために必要な時間は許容範囲を超えています。最も重要な目標に焦点を当て、最初のリリースに何を含めるべきかを特定します。ユーザーストーリーマップ上のメモを水平に分割し、各リリースの左側に、期待される結果を説明する短いテキストを記載したメモを貼り付けます。次に、各リリースの予想される結果にできるだけ一致するように、リリース間でカードを移動します。したがって、マップ全体の左側には、目標成果を識別する公開された名前のリストが表示されます。これはリリースロードマップです。開発作業の優先順位を決める秘訣は、特定の目標成果に焦点を当てることです。最後に、機能ではなく結果を優先します。

大きな成果を細分化する秘訣は、小さく具体的な成果に焦点を当てることです。結果の背後には、特定のアクティビティに参加している特定のユーザーの特定の行動の変化があります。今後のイベントに注目して、イベントに参加するユーザーを選択します。しかし、アクティブユーザーに焦点を当てるだけでは、比較的長期間にわたって既存のシステムを通じてニーズが満たされ続ける他のユーザーのニーズを同時に満たすことはできません。一度にすべての人を満足させることはできません。

まとめ

あなたの仕事はソフトウェアを開発することではなく、競合他社よりもユーザーのニーズを満たすことです。ストーリーマップを使用して MVP のリリースプランを出力し、開発の削減、学習の高速化、および予定通りのリリースを実現します。ユーザーストーリーマップを作成するときは、次の 3 つの点に留意してください。ユーザーストーリーをできるだけ包括的に記述する。ユーザーの行動を視覚化する。マップの前に立って、次の開発段階で何を達成したいかを再検討する。

この記事は@京贝贝（Qinggua Media）によって編集され、公開されました。転載の際は著者情報と出典を明記してください。

製品プロモーションサービス： APPプロモーションサービス広告

<<: 【乾物】低コストで最初の 1,000 人の有効ユーザーを獲得する方法 (完全版)

>>: WeChat Pay マーチャントプラットフォームのログインアカウントとパスワードは何ですか?