投稿日：2026.09.02 最終更新日：2026.09.20
バリュープロポジションキャンバスの書き方｜6要素・記入例・検証方法
キャンバスは埋まったのに、顧客が選ぶ理由を説明できない。
どの欄を、どう書き直せばよいのでしょうか。
バリュープロポジションキャンバスは、顧客が求めることと、自社が提供する価値を6要素で整理するフレームワークです。大切なのは、空欄を埋めることではなく、顧客に確かめるべき仮説を見つけることです。本記事では、6要素の意味、顧客側から書く手順、BtoBの記入例、作成後の検証方法を解説します。888名の自社調査も踏まえ、「便利」「効率化」で止まった記述を、具体的な顧客の行動と次の判断へ変える方法を整理します。
この記事のポイント
- 6要素は「顧客が求めること」と「自社が提供すること」に分けて考える
- 対象の顧客を一つに絞り、右側の顧客プロフィールから書き始める
- 「便利」「効率化」を、具体的な仕事・困る場面・望む結果へ書き直す
- 記入後は、困りごとの存在・解決の効果・導入の条件を順に確かめる
目次
バリュープロポジションキャンバスとは？顧客と提供価値を6要素で整理する
バリュープロポジションキャンバスは、「誰の、どの困りごとを、どう解決するか」を整理する道具です。英語名の頭文字からVPCとも呼ばれます。顧客側の3要素と、自社の提供価値側の3要素を並べ、両者が対応しているかを確かめます。
開発元のStrategyzerが公開するキャンバスでは、右側が顧客プロフィール、左側がバリューマップです。公式の用紙を使う場合は、同ページのテンプレート案内を参照してください。
最初は用語を覚えるより、顧客について書く欄と、自社の提案を書く欄を分けることが大切です。次の表では、それぞれに書く内容を整理しました。
| 記入する側 | 要素 | 書く内容 |
|---|---|---|
| 顧客側（右） | 顧客のジョブ | 顧客が行いたい仕事、達成したいこと |
| 顧客側（右） | ペイン | その仕事で起きる困りごと、障害、避けたいリスク |
| 顧客側（右） | ゲイン | 顧客が望む結果や、得られるとうれしいこと |
| 提供価値側（左） | 製品・サービス | 顧客へ提供するもの |
| 提供価値側（左） | ペインリリーバー | 困りごとを減らす仕組み |
| 提供価値側（左） | ゲインクリエイター | 望む結果を生み出す仕組み |
例えば「取引先へ月次報告を提出する」がジョブ、「数字の確認に追われ、締め切りに間に合わない」がペインです。それに対して「未入力の部署を一覧表示し、確認漏れを減らす」はペインリリーバーに当たります。困りごとと、それを減らす方法は別の欄に書きます。
顧客の欄に「当社のシステムを使いたい」と書かず、その手前にある仕事と目的を書いてください。顧客はシステムを使うためではなく、仕事を終えたり、望む結果を得たりするためにサービスを選ぶからです。
BMCは事業全体、VPCは顧客と価値の関係を見る
ビジネスモデルキャンバス（BMC）は、顧客、収益、提供方法、必要な資源など、事業全体の仕組みを整理します。VPCは、その中の「顧客セグメント」と「価値提案」を詳しく考えるための道具です。
顧客がなぜ選ぶのかを説明できないならVPC、価値は伝わるがどう届けて利益を残すかが曖昧ならBMCが向いています。両方を同時に埋める必要はありません。顧客と価値の仮説が具体化した段階で、新規事業のビジネスモデル設計へ広げると、次に考える範囲が明確になります。
リーンキャンバスも事業の仮説を一枚で整理しますが、課題、解決策、主要な指標などを含みます。VPCだけでは、採算、販売経路、実行体制まで確かめたことにはなりません。用途を分け、同じ説明を複数の資料へ転記する作業を増やさないようにします。
顧客の欄を埋める前に、直接聞いた事実があるかを確認する
社内で顧客像を詳しく描けても、それが実際の顧客と一致するとは限りません。まず、自分たちが知っていることは、直接聞いた話や観察した行動なのか、社内で考えた仮説なのかを分けます。
イノベーション総研の888名調査では、直近で関わった新規事業について、チームがターゲット顧客と直接対話した回数を尋ねました。顧客候補との対話も含めた回答を、回数帯でまとめると次のようになります。
チームがターゲット顧客と直接対話した回数
出典：イノベーション総合研究所「新規事業の実態と意思決定に関する調査」（2026年4月、n=888、調査実施：株式会社マクロミル）
対話が3回以下という回答は、全体の半数近くを占めています。この調査はVPCの利用効果を測ったものではありませんが、社内の議論だけで顧客理解が十分だと判断していないか、確認するきっかけになります。
イノベーション総研では、VPCを「顧客理解の完成図」ではなく、次に何を顧客へ確かめるかを決めるための資料として使うことを勧めます。対話の回数を増やすことよりも、重要な仮説について、誰のどの行動を確かめたかが判断材料になります。
「確認した事実」と「そこから考えた仮説」を分ける
例えば、顧客が「月次報告は大変だ」と話したなら、まず確認できたのは、その発言があったことです。「報告を自動化すれば有料でも使う」という結論までは確認できていません。発言の記録と、チームの解釈を分けて書きます。
VPCの横に根拠メモを置くと、欄の中を長文で埋めずに済みます。イノベーション総研では、項目ごとに次の状態を付ける方法を提案します。
- 事実：誰がいつ話したか、何を観察したかを確認できる内容
- 仮説：事実を踏まえて、チームが考えた理由や解決方法
- 未確認：必要な情報がまだなく、判断できない内容
「事実」とした項目も、確認した相手や場面を越えて一般化しないことが大切です。1社の月末業務で起きた問題が、すべての企業に当てはまるとは限りません。反対の例が出たら、都合の悪い回答として除外せず、対象顧客の分け方から見直します。
顧客に否定された項目こそ、書き直す価値がある
Strategyzerが2026年1月に紹介したカナダの消費財チームの例では、顧客プロフィールを使った20件のインタビューによって、社内で想定したジョブやペイン、ゲインが修正されました。重要なのは、キャンバスを説得材料として見せるのではなく、顧客に否定・修正してもらう材料にしたことです。詳しくはStrategyzerの顧客インタビュー事例に掲載されています。
この使い方を自社へ取り入れるなら、「この説明で合っていますか」だけで終えないでください。「違うと感じた箇所はどこですか」「直近では何が起きましたか」と聞き、想定していなかった仕事や負担も追加します。なお、この事例はイノベーション総研の支援実績ではありません。
バリュープロポジションキャンバスの書き方｜顧客側から進める6ステップ
書き始める前に、対象顧客、利用場面、記入日を決めます。以下はイノベーション総研が実務向けに整理した6ステップです。空欄をなくすのではなく、次の検証で確かめたいことが分かる状態を目指します。
1. 対象の顧客と、困りごとが起きる場面を一つに絞る
「製造業の企業」のような広い対象では、何を書けばよいかが定まりません。「複数部署から数字を集め、月次報告を取引先へ提出する担当者」のように、役割と場面まで絞ります。
BtoBでは、同じ会社でも利用者と決裁者が求めることは異なります。最初から全員を一枚に入れず、まず一つの役割について書いてください。役割を分けるとは、同じ人でも「使う立場」と「予算を決める立場」の話を区別することです。
ここで決めるのは最終的な市場の大きさではなく、最初に理解する相手です。別の役割にも価値がありそうなら、二枚目の候補として残します。
2. ジョブは「何を、どこまで終えたいか」で書く
ジョブには、顧客が達成したいことを書きます。「資料作成」だけでなく、「月末までに取引先へ提出し、差し戻しなく受理される」のように、完了したと判断する条件を入れます。
ジョブは作業だけとは限りません。「取引先に信頼される担当者でいたい」「提出後にミスを指摘される不安を減らしたい」といった、周囲からの評価や気持ちも関係します。ただし、内心を想像して事実のように書かず、本人の発言や行動を確かめるための仮説として残してください。
自社の機能名を使わずにジョブを説明できれば、システム、外注、人手の工夫など、顧客が選び得る別の方法とも比べられます。
3. ペインは「何が起きて、何に困るか」まで具体化する
ペインには、ジョブを進めるうえでの負担や障害を書きます。「面倒」だけでは、転記、確認、承認待ちのどこを改善すべきか分かりません。「部署ごとの数字がそろわず、提出直前に確認が集中する」まで書きます。
その困りごとが最後に起きたとき、顧客がどう対処したかも確かめてください。自分で残業したのか、別の担当者に頼んだのか、費用を払って外注したのかで、解決に使える手段や負担の大きさが変わります。
今は問題が起きていなくても、避けたい事故や信用の低下が重要なペインになることもあります。その場合は、過去の出来事、現在の予防策、問題が起きた場合の影響を聞き、単なる漠然とした不安と分けます。
4. ゲインは「どんな状態になればうれしいか」で書く
ゲインには、顧客が望む結果を書きます。「使いやすい」ではなく、「月末を待たずに数字の不足を把握でき、余裕を持って提出できる」のように、仕事の変化として表します。
ペインを反転させるだけでは見えないゲインもあります。例えば、提出の遅れをなくすことに加え、「報告内容を使って取引先へ改善提案ができる」ことに価値を感じる顧客もいるでしょう。これは記事の説明用の仮説であり、実際に望まれているかは別途確認します。
望む結果が複数ある場合は、必須条件なのか、あればうれしいのかも分けます。必須の締め切りを守れないまま、見栄えのよいグラフを増やしても選ばれるとは限りません。
5. 頻度・影響・現在の対処から、優先する課題を選ぶ
書き出した項目をすべて解決しようとすると、提案も検証も広がります。まず顧客にとって重要な項目を選び、その根拠を確認します。
- 頻度：どの場面で、どのくらい繰り返し起きるか
- 影響：時間、費用、品質、信用などに何が起きるか
- 現在の対処：解決や予防のために、どんな手間や費用を使っているか
毎日起きる小さな手間と、年に一度でも事業を止めるリスクでは、優先度の考え方が違います。頻度だけで順位を決めず、顧客が今何を優先しているかを聞きます。判断できない項目は仮順位にとどめ、次の面談で比べてもらってください。
6. 提供するものと、その働きを顧客側の重要項目へ対応させる
ここで初めて左側を具体化します。「製品・サービス」に提供物を書き、「ペインリリーバー」に負担を減らす仕組み、「ゲインクリエイター」に望む結果を生む仕組みを書きます。
例えば「部署共通の入力フォーム」が提供物です。「入力の不足を検出して差し戻しを減らす」が負担を減らす働き、「提出前から数字を確認し、改善の相談を始められる」が望む結果を生む働きになります。同じ機能でも、顧客の何を変えるかを説明し分けます。
顧客側のどの項目にもつながらない機能は、最初の提案から外す候補です。自社の得意分野だからという理由だけで残さず、優先した課題との関係を確かめてください。
VPCを次の行動につなげるには、何が足りませんか？
近い状況を開くと、先に確認する内容が分かります。
NEXT STEP
次のステップ
VPCの仮説を、実際に試せる検証計画へ
何を、誰に、どこまで試せばよいかが決まらない方へ。イノベーション総研の新規事業立ち上げ支援では、事業仮説の整理から、検証の設計、試作品の開発、初期顧客の獲得まで、段階に応じて支援します。
BtoBの記入例｜月次報告の負担を減らすサービスを考える
ここからは、複数部署の数字を集める月次報告サービスを例に、書き方と判断の仕方を確認します。以下は説明用の架空例です。実在の顧客や、検証済みの成果を示すものではありません。
想定する相手は「取引先向けの月次報告を取りまとめる担当者」です。抽象的な記入を、行動と結果が分かる仮説へ書き直してみます。
| 記入欄 | 曖昧な書き方 | 具体化した仮説 |
|---|---|---|
| ジョブ | 報告業務を効率化したい | 各部署の数字をそろえ、月末の締め切りまでに取引先へ報告する |
| ペイン | 集計が面倒 | 部署ごとの様式が違い、転記ミスの確認で提出が遅れる |
| ゲイン | 楽に仕事をしたい | 提出前に不足を見つけ、余裕を持って内容を確認できる |
| 製品・サービス | 便利な管理ツール | 各部署の入力をまとめ、報告書へ出力するサービス |
| ペインリリーバー | 手間を減らす | 入力様式をそろえ、数字の転記と照合を減らす |
| ゲインクリエイター | 生産性を高める | 入力状況を随時表示し、未提出の部署への確認を前倒しする |
この例では、提供するものと、その働きが区別できています。ただし「様式の違いが遅れの主因か」「入力状況を早く知れば提出が早まるか」は未確認です。説明が筋道立っていることと、顧客の現実に合っていることを混同しないでください。
今のやり方と比べ、乗り換える理由まで考える
競合は同種のサービスだけではありません。今使っている表計算ファイル、担当者への電話、作業の外注、何も変えずに残業で対応することも比較対象です。
この例で、共有の表計算ファイルを一つ作れば十分なら、新しいサービスへ移行する理由は弱くなります。一方、取引先ごとに様式が違い、版の管理や提出権限の確認まで必要なら、単なる集計以上の課題があるかもしれません。
最初の面談では、現在の資料や手順を差し支えのない範囲で見せてもらい、「現状の方法では何が残るか」を確かめます。顧客が困っていると話しても、移行の手間のほうが大きければ選ばれません。
利用者が喜んでも、予算を持つ人の判断は別に確かめる
BtoBでは、作業をする本人に価値があっても、費用負担者や運用者が別の条件を持っています。この例なら、利用者の「作業を減らしたい」に対し、管理者は「追加費用に見合うか」、情報システム部門は「外部へ出せないデータがないか」を確認する可能性があります。
そこで利用者向けのVPCを作った後、導入を左右する役割について別に整理します。利用者の満足度を、そのまま社内の導入承認の根拠へ置き換えないためです。
イノベーション総研の顧客対話資料でも、利用者・運用者・費用負担者・決裁者を分けて記録します。役割が一人に重なる場合でも、どの立場で答えたのかを残すと、未確認の導入条件を見つけやすくなります。
仮説と違う話が出たら、機能を足す前に右側を書き直す
仮に面談で「様式は統一済みで、遅れるのは上司の承認待ち」と分かったら、転記を減らす提案を押し通してはいけません。この時点では、最重要のペインを「承認の待ち時間」へ書き直す必要があります。
次に確かめるのは、上司が何を確認しているのか、どの資料が不足しているのか、どこまで担当者へ権限を渡せるのかです。単に催促の通知機能を足しても、判断材料の不足が原因なら解決しません。
反対の情報が出たときに、提案ではなく顧客理解から直せることが、VPCを使う利点です。変更前の仮説も消さず、どの事実を受けて変えたかを残します。
VPCを書いた後は、課題・効果・導入条件の3段階で確かめる
左右の欄を線で結べても、顧客が選ぶとはまだ言えません。イノベーション総研では、記入後の検証を「困りごとがあるか」「提案で改善するか」「導入できるか」の3段階に分けることを提案します。ここでは、各段階で何を確かめ、次へ進むかを決める方法を説明します。
1. 課題の存在を、最近の出来事と現在の対処で確かめる
まず、想定した困りごとが本当に起きているかを聞きます。「月次報告は大変ですか」ではなく、「直近の提出では、どこで作業が止まりましたか」「そのとき誰がどう対応しましたか」と、具体的な出来事をたどります。
発生頻度、関わる人、使った時間や費用、現状の回避策まで分かると、優先して解決する理由が見えてきます。資料の確認や画面の観察が必要なら、守秘や個人情報の扱いに配慮し、共有可能な範囲で進めてください。
想定した問題が起きていなければ、解決策の説明へ急がず、対象顧客か課題の仮説を修正します。詳しい質問の組み立ては、BtoB顧客インタビューのやり方で確認できます。
2. 解決の効果を、試作品を使った行動で確かめる
課題が確認できたら、提案で状況が改善するかを試します。すべての機能を開発する必要はありません。画面の試作品、手作業を含む簡易サービス、実際の業務を再現したテストなど、確かめたいことに合う方法を選びます。
月次報告の例なら、同じ作業を現在の方法と試作品で行い、入力の不足を見つけられるか、確認の往復が減るかを見ます。「見やすい」という感想だけで効果を確定せず、どの作業が変わったのかを記録してください。
確認したい指標と、次へ進む条件は試す前に決めます。業務の種類やリスクが違うため、一律の削減率を正解にはしません。効果が出なければ、機能の不足だけでなく、最優先の課題を取り違えていないかも見直します。
3. 導入の条件を、費用負担者と承認する人に確かめる
試作品で効果が見えても、利用者だけでは購入を決められないことがあります。誰の予算から払うか、既存の契約や業務を変えられるか、導入時にどの確認が必要かを、該当する相手へ聞きます。
価格の確認も「いくらなら買いますか」だけでは不十分です。提案する範囲、導入費用、運用に必要な作業をそろえたうえで、予算化や試行の相談へ進めるかを確認します。有料の試行へ進む場合は、料金と条件を事前に合意してください。
イノベーション総研は、この段階を含めて初めて、次の開発や投資の判断材料がそろうと考えます。ただし、少数の試行で確認できたことを、市場全体での継続利用の証明へ広げないことが重要です。継続して選ばれるかの判断は、PMFの考え方へつなげます。
対話やテストの後は、何が確認でき、何が否定され、何が残ったかを整理します。次の行動は「継続して試す」「対象や提案を変える」「いったん止める」のどれかです。「もう少し調べる」とする場合も、次の相手、確かめること、担当、期限まで決めてください。
VPCが形だけになる5つの失敗と、修正する場所
VPCを使っても提案が具体化しないときは、記入量より、どこで顧客の事実と離れたかを見ます。ここでは、現行の書き方で起きやすい5つの問題を、それぞれの修正方法と組にして整理します。
1. 自社の製品に合う困りごとだけを集める
既存の機能を説明できる話ばかり集めると、顧客が実際に優先する問題を見落とします。例えば、帳票の自動出力を売りたいからといって、報告業務の問題がすべて転記にあるとは限りません。
修正する場所は右側の顧客プロフィールです。提案を見せる前に、仕事の流れと止まる場面を聞きます。技術や製品の強みは捨てず、顧客側の重要な項目へどう役立つかを後から考えてください。
2. 利用者と決裁者を一枚に混ぜる
利用者は操作の手間を減らしたい一方、決裁者は費用や導入のリスクを抑えたいかもしれません。一枚に混ぜると、誰に何を確かめたのかが分からなくなります。
役割ごとに右側を分けたうえで、両立しない条件を確認します。例えば利用者の自由な入力が、運用者には確認工数の増加になるなら、入力の自由度と管理方法を一緒に検討します。開発元も、複数の顧客層を混在させることへの注意を示しています。
3. 「便利」「安心」「効率化」だけで説明する
抽象語だけでは、顧客が同じ意味で受け取っているか分かりません。「安心」なら、入力を間違えない安心なのか、承認後に責任を問われない安心なのかで、必要な仕組みが変わります。
「誰が、どの場面で、何をできるようになるか」へ書き直します。説明を読んだ別の担当者が、確かめる質問やテストを思い浮かべられるかが目安です。
4. すべての課題に応えて、機能を増やす
要望を漏れなく入れるほど、提案が強くなるとは限りません。入力、集計、承認、分析、チャットを同時に作ると、何の効果を確認したい試作品なのかも曖昧になります。
優先したジョブ・ペイン・ゲインへ戻り、最初に確かめる価値を絞ります。対応しない要望には理由を残し、後回しにする条件を決めてください。顧客の重要度が変わったら、その時点で取り上げ直せます。
5. 社内で承認された後、書き直さない
会議で合意したことは、顧客の事実で確かめたこととは違います。承認後に異なる情報が出てもキャンバスを固定すると、検証は最初の案を説明するための作業になってしまいます。
顧客接点のある担当者、技術・開発担当者、事業責任者が、同じ根拠を見て変更点を確認する時間を設けます。意見が割れたら多数決で顧客像を決めず、どの事実があれば判断できるかを整理してください。
キャンバスの完成度より、次の判断が具体化したかを確認しましょう。VPCでは解けない収益や体制の問題が見えてきたら、新規事業フレームワークの使い分けを参考に、必要な検討へ進めます。
バリュープロポジションキャンバスでよくある質問
初めて使うときや、作成後に判断が止まったときの疑問をまとめました。
まとめ｜次に確かめる相手と問いを、一つ決める
バリュープロポジションキャンバスは、顧客のジョブ・ペイン・ゲインと、自社が提供するもの・その働きを整理する道具です。対象顧客を一つに絞り、顧客側から書くと、製品ありきの説明から離れやすくなります。
記入後は、課題の存在、提案の効果、導入条件を分けて確かめます。好意的な発言だけで判断せず、最近の行動、現在の対処、試作品の利用結果、予算や承認の条件を集めてください。
まずは、いまのVPCで根拠が弱く、外れたら提案が変わる項目を一つ選びましょう。「誰へ、何を、いつ確かめるか」を決めれば、キャンバスは完成した資料ではなく、次の検証を進める道具になります。
CONTACT
お問い合わせ
顧客に選ばれる理由と、次の検証を整理したい方へ
顧客の課題、提供価値、価格や導入条件。いまの仮説と集まっている情報を伺い、次に確かめることや実行の進め方をご相談いただけます。
