インパクトマッピングで機能の優先順位を決める方法

機能の一覧だけでは、なぜある案を別の案より先に検討すべきかは分かりません。ダッシュボード、メールのリマインダー、新しい初期設定画面は、どれも便利そうに見えても、目指すものが違うかもしれません。まとめて点数を付ければ整った順位表はできますが、その食い違いは残ります。

インパクトマッピングは、人の行動の変化を通じて、機能の選択と事業目標を結び付ける手法です。バックログの優先順位を確定する前に使います。特に、解決すべき問題について合意しないまま、関係者が解決策を追加し続けているときに役立ちます。

四つの階層を正しく使い分ける

Gojko Adzicのインパクトマッピング解説では、目標、アクター、インパクト、成果物の順で対話を構成します。アクターは結果に影響を与えられる人や集団、インパクトはその人たちに必要な行動の変化です。成果物は、その変化を支えるために組織が提供できるものを指します。

この区別は重要です。「初期設定のチェックリストを作る」は成果物です。「新規管理者が手助けなしで最初の設定を完了する」は行動の変化です。「アクティベーションの成功を増やす」は目標ですが、まだ測定可能な定義が必要です。階層を混ぜると、マップは埋まって見えても、判断の根拠が曖昧なままになります。

手法全体の紹介は、インパクトマッピングの概要を参照してください。ここでは範囲を絞り、競合する機能提案から何を選ぶかに焦点を当てます。

目標を一つに絞り、範囲を明確にする

プロダクトの意思決定者、ユーザーを理解している人、実現上の制約を理解している人を集めます。対象者、観察できる成果、期間を含めて、一つの目標を書きます。信頼できるデータがあれば現状値も加えます。なければ推測の数値を入れず、現状を把握する作業を明示します。

例えば、架空の予約サービスが、新しく利用を始めたチーム管理者のうち、最初の一週間に実際の予約を成立させる人を増やしたいとします。チームは「実際の予約」からテスト予約を除き、観察できる顧客セグメントを定めます。また、サポート負荷を急増させない、望まない通知をユーザーに押し付けない、といった守るべき条件も決めます。

中心に「ダッシュボードを公開する」と置いてはいけません。解決策を先に決めてしまうからです。スポンサーが特定の成果物を求めるなら、どのような結果が得られれば作る価値があるのかを尋ねます。その問いによって、契約上必須の要件だと分かる場合もあります。そうした作業は、成果を期待して選ぶ任意の施策と区別します。

解決策より先にアクターを整理する

目標達成を助けたり妨げたりできる人を挙げます。予約サービスなら、新規管理者が空き時間を設定し、招待された人が予約を完了し、サポート担当者が設定上の問題からの復帰を助けます。データの制約は実装に影響しますが、「データベース」は、この意味でのアクターではありません。

アクターごとに、目標に役立つ具体的な行動を書きます。「もっと積極的に使う」より「予約可能な時間枠を公開する」のほうが明確です。観察、会話、製品内のイベントから、その変化をどう見分けるかを考えます。

できるだけ、すでに分かっているユーザーの困りごとを出発点にします。顧客フィードバックの整理手順は、裏付けとなる観察結果をまとめるのに役立ちますが、未検証の前提には印を残します。筋が通って見える枝も、因果関係についての仮説であり、実証された結果ではありません。

例：四つの要望を、その理由から整理する

予約サービスのチームには、分析ダッシュボード、ガイド付き設定、招待のリマインダー、サポート返信用の定型文という要望が来ています。すぐに機能を採点するのではなく、それぞれがどの行動を変えるはずなのかをマップにします。

ダッシュボードには価値があるかもしれませんが、チームはまだ今回の目標への貢献を説明できません。そこで、別の機会を検討する一覧へ移します。分析が重要ではないと判断したのではなく、継続利用に関する作業と、使い始めの活性化の問題を混ぜないための判断です。

マップからは、ガイド付き設定と短い支援通話が、同じ行動を探る代替手段だとも分かります。両方が自動的に、実施を約束したバックログ項目になるわけではありません。

成果物より先に、取り組む枝を選ぶ

どの行動変化が目標に最も重要そうか、どれに強い裏付けがあるかを話し合います。その後で、対応策の不確実性、労力、やり直しやすさを検討します。ボード上で同じ広さを占めているというだけで、すべての枝に同じ注意を向けないようにします。

サポートとの会話で、管理者が空き時間の設定を理解できないという話が繰り返し出ているとします。チームは、まず数件の設定操作を観察し、分かりやすい例を試せます。招待された人が予約ページに到達していないなら、そのページの簡略化は別の問題を解いているかもしれません。順番は、工数を見積もりやすい機能ではなく、得られた情報で決めます。

粗い点数を、精密さの競争にしないでください。点数は議論の要約にはなっても、説明は数値がなくても通じる必要があります。選んだ枝と理由を横に書きます。例えば「空き時間の設定につまずき、予約リンクを共有できないため、設定方法を調べる」とします。

考え方を確かめる小さな施策を選ぶ

選んだ枝について、想定する行動変化が起こりそうかを学べる、最小限の施策を探します。プロトタイプ、手作業で提供するサービス、分かりやすい説明、限定的な製品変更などが考えられます。必ずしも新機能とは限りません。

予約サービスの例では、新規管理者に空き時間の設定パターンを試してもらいます。適切な時間枠を作り、招待された人に何が表示されるかを説明できるかを観察します。さらに、できたリンクが実際の予約につながるかも確認します。設定完了だけでは、最終目標を達成したとは言えません。

どの結果なら継続、修正、中止を判断するかを書きます。その施策が、単純な週間勤務予定のユーザーにしか役立たないなら、その限界を残します。部分的な裏付けを、誰にでも有効な成功へと言い換えないでください。

マップとバックログを区別する

マップには代替案と因果関係の考え方があり、バックログには実施を検討中、または準備中の仕事があります。末端の枝をすべてバックログにコピーすると、選択肢が暗黙の約束に変わります。選んだ仕事だけを移し、それが支える行動へのつながりを残します。

インパクトマッピングのテンプレートを使うか、Boardmixを開いて空白のキャンバスに四つの階層を描きます。予約サービスの例では、初週の予約という目標から新規管理者へ、さらに利用可能な予約リンクの公開へつなぎます。その先を、空き時間の設定例、ガイド付き設定、短い支援通話に分けます。設定例には「最初に検証」と記し、残りは実施未定にしておきます。今回の目標と直接関係しない分析の要望は、見える場所に残しつつ、別の領域に置きます。

結果が得られたら、機能を拡張する前に、成果物と行動のつながりを見直します。招待文を分かりやすくするだけで問題が解決するなら、リマインダーの仕組みを作らない理由が得られます。作るものを減らす判断が、優先順位を話し合う場の最も有用な成果になることもあります。