前提条件マッピング：先に検証すべき仮説を選ぶ方法

チーム全員が同じ製品アイデアに賛成していても、うまくいくと考える理由は違うことがあります。ある人は顧客がすでに課題を感じていると考え、別の人は解決にお金を払うと考え、さらに別の人は必要なデータを簡単に入手できると考えています。前提を明らかにしなければ、整ったロードマップの裏に、三つの異なる見込みが隠れたままになります。

前提条件マッピングのワークショップは、どの不確実性から調べるかを決めるためのものです。投資判断を変えうる前提を見つけ、そのまま進めるべきかを判断できる検証を設計します。

重要度と裏付けを分ける

前提条件マップにおける重要度とは、その前提が正しいことにアイデアの成立がどれだけ依存しているかを指します。裏付けとは、その前提について実際に何が分かっているかです。この二つは別の判断です。強い確信があるからといって証拠が強いとは限らず、簡単に確かめられる事柄が重要とも限りません。

Strategyzerの前提条件マッピングでは、重要度と裏付けを軸にして、重要なのに十分な根拠がない仮説を見つけます。この区別は議論を整理するために使うもので、付箋の位置に科学的な精密さがあるとみなすものではありません。

縦軸は下から上へ重要度が低いものから高いもの、横軸は左から右へ裏付けが弱いものから強いものとして、両端にラベルを付けます。最初の検証候補は、通常、重要度が高く裏付けが弱い領域にあります。全員が同じ意味で読めるなら、軸の向きは変えても構いません。

自由な発想より先に、判断したいことを決める

ボードの上部に「今四半期に顧客向けレポートポータルを作るべきか」のような判断事項を書きます。何がかかっているのか、いつまでに決める必要があるのかも添えます。そうしないと、興味深くても目の前の判断に関係しない不確実性が並んでしまいます。

顧客のニーズを明確にする前に機能を決めてしまった場合は、オポチュニティソリューションツリーの具体例で、目指す成果、満たされていないニーズ、解決策、検証を分けて整理する方法を確認できます。

顧客の行動、実現上の制約、事業上の影響を理解している人を集めます。アイデアの概要と、すでに得られている情報を共有してください。ビジネスモデルキャンバスがあるなら、各ブロックを手がかりに、顧客、チャネル、コスト、パートナーについて問いを立てます。キャンバスは検討材料であり、事業モデルが成立する証拠ではありません。

議論の前に、各自で書き出してもらいます。一枚の付箋には一つの主張と、それを現時点で正しいと思う理由を書きます。そうすれば、サポートへの問い合わせ、インタビューの発言、経営者の直感を、異なる種類の材料として見分けられます。

曖昧な前提を検証可能な主張に直す

「顧客はもっと良いレポートを求めている」では、検証するには広すぎます。読み込みの速さ、グラフの分かりやすさ、メールの削減、データの書き出しなど、さまざまな意味がありえます。「小規模な制作会社の顧客担当者は、毎週プロジェクトの進捗を顧客に報告する必要があり、その作成に繰り返し手作業が発生している」とすれば、調べる対象が明確になります。

Strategyzerは、有用な仮説の条件として、検証可能であること、具体的であること、一つの事柄を扱うことを挙げています。実務では、誰の、どの状況で、どのような行動を想定するのかを書きます。需要、支払い意欲、実現可能性を一つにまとめた主張は分けましょう。一つを裏付ける情報が、残りも証明するわけではありません。

「何が分かれば、この主張は誤りだと言えるか」と逆からも考えます。同意以外の結果を認めないなら、それは仮説ではなく、売り込みのための説明になっています。

例：制作会社は顧客ポータルを作るべきか

小規模な制作会社が、顧客向けレポートポータルの導入を検討しているとします。この架空の例では、顧客との会話が数件あり、現在のレポートの見本もありますが、稼働中のポータルはありません。

ログインに関する前提は明らかな検証候補ですが、データの信頼性も重要です。顧客が積極的でも、不正確なレポートの問題は解決しません。そこで、実際の利用を観察しつつデータを手作業で確認できる、小規模な試行を選びます。テーマの議論は後回しにします。その判断を待っても、高額な投資への後戻りできない約束にはつながらないからです。

見せかけの精密さを避け、裏付けの質を検討する

各付箋について、情報の出所、どのユーザーを代表しているのか、別の説明が成り立たないかを確認します。「顧客がダッシュボードを求めた」のは、新しいログイン先が欲しいからではなく、進捗会議を減らしたいからかもしれません。一社からの五つのコメントは、独立した五社の意見ではありません。

根拠へのリンクや短い引用を、該当する主張のそばに置きます。顧客フィードバックの整理ガイドは、繰り返し出てくる観察結果をまとめる際に役立ちます。ただし、繰り返されたことだけを市場需要の証明にしないようにします。

意見の違いをすべて投票の平均で解決しようとしないでください。サポートではよく聞く課題を営業が知らないなら、接している顧客層が違うのかを調べます。別のセグメントについての主張であれば、付箋を分けます。その食い違いこそ、ワークショップで得られる最も有用な発見かもしれません。

判断を変えうる検証を選ぶ

選んだ前提を、主張、参加者またはデータ、実施内容、観察項目、判断基準、担当者を記載した短い検証カードにします。判断基準は結果を見る前に決めます。小規模な調査が決定的な証拠になるわけではありませんが、望む答えに合わせて成功の定義を変えることを防げます。

制作会社の試行では、普段の担当者から顧客を招待し、ログインが必要な小さなポータルに、内容を確認済みの週次進捗ページを用意します。繰り返し催促しなくても再訪するか、同じ情報をメールで求め続けるかを観察し、その後に理由を尋ねます。誰でも開けるページなら情報の有用性は調べられても、ログインする意思があるかは分かりません。一度リンクを開いただけで定着したと判断せず、反応がないことを満足の表れとも解釈しないでください。

データの完全性は、別途技術的に確認します。手作業で準備した試行版から有用性は学べても、自動レポートが安定して動き、低コストで提供できるとは分かりません。残る不確実性を明示し、良好な結果の中に紛れ込ませないことが大切です。

結果に応じて計画を変える

元の主張は残し、その下に観察結果を加えます。そのうえで、継続するか、アイデアを修正するか、別の情報を集めるか、中止するかを決めます。参加者が少なすぎたり、重要な状況を再現できなかったりした場合、「判断できない」も適切な結果です。

例えば、顧客が簡潔なメールを好み、ポータルにほとんど戻らないなら、機能を増やす代わりにメール要約の改善を試せます。ポータルは使われても、スタッフがデータ修正に時間をかけすぎるなら、次の投資先はデータ品質かもしれません。同じ製品アイデアから始まっても、導かれる判断は異なります。

Boardmixを開き、上に行くほど重要度が高く、右に行くほど裏付けが強いマトリクスを描きます。制作会社の例では「顧客は催促なしで再訪する」を、重要度が高く裏付けが弱い角に置きます。「既存データから正確な要約を作れる」は、近くに別の主張として置きます。マトリクスの横に、実施内容、観察項目、判断基準、担当者を記した試行カードを加え、結果はその下に記録します。一度好意的な発言があっただけで「裏付けが強い」領域へ移動しないでください。より広い検討には、プロダクトディスカバリーのワークショップガイドも活用できます。