リーンキャンバスの書き方｜9項目と検証の進め方

この記事の結論

リーンキャンバスは課題から書き始める9項目のフレームで、埋めた後に最も危うい仮説から検証する使い方が前提です。

新規事業のアイデアはあるものの、何から手をつけて検証すればいいか分からない。そんな起業家や新規事業担当者に向けて、まず頭の中を整理する道具がリーンキャンバスです。1枚のシートに事業の要素を書き出すだけで、どこが仮説でどこが未検証かが一目で分かるようになります。

ノートに思いつくまま書き出すよりも、決まった9つのマスに沿って書く方が、抜け漏れなく・短時間で整理できます。事業計画書のように何十ページも書く必要はなく、A4用紙1枚に収まる分量で十分です。

本記事ではリーンキャンバスの9項目とその書き方の手順、よくあるつまずきポイント、そして「書いた後」に何をすべきかまで解説します。書き方の型を知るだけでなく、書いたキャンバスをどう検証に活かすかまで押さえておくと、机上のアイデアを実際の事業に近づけるスピードが変わってきます。関連するBtoBマーケティング用語はBtoBマーケティング用語集でまとめて確認できます。

リーンキャンバスとは何か

リーンキャンバスは、事業アイデアを9つの要素に分けて1枚のシートに書き出すフレームワークです。アッシュ・マウリャが著書『Running Lean（実践リーンスタートアップ）』の中で提唱し、リーンスタートアップの実践ツールとして広く使われています。

事業計画書のように文章で綴るのではなく、要素ごとにマス目へ短く書き込む形式のため、慣れれば20〜30分程度で最初の1枚を作れます。目的は完成度の高い計画書を作ることではなく、「どこが仮説で、どこから検証すべきか」を可視化することにあります。埋めた内容の多くは検証前の仮説にすぎないため、正確さよりもまず全体像を書き出すことを優先します。

リーンキャンバスが好まれる理由の1つは、事業アイデアの全体像を「1枚で・短時間で・チームで共有できる」点にあります。数十ページの事業計画書は作成にも読み込みにも時間がかかり、レビューのたびに全体を読み直す負担が生じます。1枚のシートであれば、関係者全員が同じ資料を見ながら「どこが弱いか」「どこから検証するか」を短時間で議論できます。

似たツールに「ビジネスモデルキャンバス（BMC）」があります。両者はマス目の形式が似ていますが、ねらいが異なります。

新規事業や新サービスの立ち上げで「まず何を検証すべきか」を洗い出したい場合はリーンキャンバス、既存事業を含めて事業構造を俯瞰したい場合はBMCが向いています。BMCの書き方はビジネスモデルキャンバスの書き方と検証活用で詳しく解説しています。

リーンキャンバスの9項目

リーンキャンバスは9つのマスで構成されます。まずは全体像を表で確認しましょう。

9項目すべてを最初から精緻に埋める必要はありません。空欄があってもよく、埋まっていない箇所こそが次に検証すべきポイントだと捉えます。特に「圧倒的な優位性」は立ち上げ初期には埋まらないことが多く、無理に絞り出す必要はありません。

記入例：架空のBtoB資料共有サービス

イメージをつかむために、架空のBtoB向けサービス（営業資料をオンラインで共有するサービス）を例に、9項目の記入例を見てみましょう。

この例のように、9項目は互いに関連し合っています。課題（②誰が資料を見たか分からない）に対して解決策（②フォーム入力後にダウンロード可能にする）が対応し、主要指標（フォーム経由のダウンロード数）でその効果を計測する、という一貫した流れになっているかを確認しながら書くと、キャンバス全体の整合性が取りやすくなります。

リーンキャンバスの書き方【4ステップ】

書く順番を誤ると、実現性の薄い解決策から書き始めて手戻りが増えます。以下の順番で進めると、仮説の整合性を保ちやすくなります。

1. 顧客セグメントと課題を書く
2. 独自の価値提案と解決策を仮決めする
3. チャネル・収益の流れ・コスト構造を埋める
4. 主要指標と圧倒的な優位性で仕上げる

ステップ1: 顧客セグメントと課題から書く

最初に埋めるのは顧客セグメントと課題です。事業アイデアが「誰の・どんな課題を解決するか」から出発している以上、ここが曖昧なまま先に進むと、独自の価値提案や解決策が的外れになります。

顧客セグメントは「30代の会社員」のような属性だけでなく、可能であれば「最初に使ってくれそうな層（アーリーアダプター）」まで具体化します。例えば新規事業として社内資料共有ツールを企画する場合、顧客セグメントは「中小企業の営業部門」、アーリーアダプターは「営業資料を PDF で作っているが配布方法に困っている企業の営業担当者」のように、行動が想像できる粒度まで絞り込みます。顧客セグメントごとの行動や検討フェーズを具体化する際は、カスタマージャーニーマップの作り方も参考になります。

課題は3つ程度に絞り、それぞれについて「今、顧客はどう対処しているか（既存の代替手段）」も書きます。既存の代替手段が見えると、自分たちの解決策がどこで優位に立てるかが明確になります。代替手段が「特に何もしていない」場合は、そもそも顧客がその課題を強く感じていない可能性があるため、課題設定自体を見直すサインになります。

ステップ2: 独自の価値提案と解決策を仮決めする

課題が整理できたら、独自の価値提案を1文で書きます。「誰の・どんな課題を・どう解決するか」が伝わる文章にすることがコツです。長い説明が必要な場合は、価値提案が絞り切れていない可能性があります。例えば「PDF資料をアップロードするだけで、リード獲得フォーム付きの共有ページをすぐに作れる」のように、行動と結果がセットで分かる文章を目指します。

解決策は課題1つにつき1〜2行で、機能名ではなく「何が実現できるか」のレベルで書きます。この段階で機能仕様まで作り込むと、後の検証結果を踏まえた修正がしづらくなります。あくまで「この課題に対してどんな方向性で解決するか」の当たりをつける段階だと割り切りましょう。

ステップ3: チャネル・収益・コスト構造を埋める

事業を回すための実務項目を埋めます。BtoB向け SaaS を例に考えると、次のように書けます。

• チャネル: 直接営業、パートナー経由の紹介、展示会、オウンドメディア経由の資料ダウンロード
• 収益の流れ: 月額課金＋初期導入費。無料プランからの有償転換も想定
• コスト構造: 開発人件費、営業担当の人件費、広告費、サーバー・インフラ費用

この段階では正確な金額よりも、「どの項目にコストとリソースがかかるか」の当たりをつけることを優先します。数字の精緻さは、後続の検証や資金計画のフェーズで詰めていけば十分です。

チャネルは特に、後の検証フェーズと直結する項目です。どの経路で顧客に到達するかによって、検証の進め方も変わります。直接営業がメインなら商談での反応を見ることになりますし、オウンドメディアやSNS経由の流入が中心なら、資料の公開ページへのアクセス数や反応率が重要な手がかりになります。

ステップ4: 主要指標と圧倒的な優位性で仕上げる

主要指標と圧倒的な優位性は、9項目の中でも最後まで埋まりにくいマスです。主要指標は「何を計測すれば事業の進捗が分かるか」を1〜3個に絞って書きます。例えば「資料の公開ページ数」「フォーム経由のダウンロード数」「ダウンロードから商談化した件数」のように、行動の連鎖として追える指標を選ぶと、後の検証と接続しやすくなります。

圧倒的な優位性は、立ち上げ初期には持っていないことも多いため、無理に埋めず「現時点では無し」と正直に書いて構いません。事業が進み、顧客基盤や独自データ、ネットワーク効果などが蓄積されてから後づけで埋めていく項目だと考えましょう。

つまずきポイント

リーンキャンバスの作成でよくあるつまずきは、次の3つです。

• 項目を埋めること自体が目的化する: 9マスを全部埋めた時点で満足してしまい、内容の検証に進まないケースです。リーンキャンバスはゴールではなく、検証すべき仮説の一覧表だと捉え直しましょう。
• 課題の解像度が粗いまま進める: 「業務が非効率」のような抽象的な課題では、解決策も曖昧になります。「誰が」「どの作業で」「どれくらいの頻度で」困っているかまで具体化します。解像度が粗いままだと、後で検証しようにも「何を確かめればよいか」が定まりません。
• 1回書いて満足し、検証しない: リーンキャンバスは一度作って終わりのドキュメントではありません。書いた時点の内容はあくまで仮説であり、実際に顧客に確かめるまでは正しいかどうか分かりません。特に課題と解決策の2項目は、机上の議論だけでは検証が完結しない点に注意が必要です。

これら3つのつまずきに共通するのは、「書くこと」と「検証すること」を分けて考えられていない点です。リーンキャンバスを書く工程はあくまで準備であり、本番はその後の検証にあります。書き終えた時点で一区切りとせず、次にどう検証するかまでセットで考える習慣をつけましょう。

書いた後の検証を仕組み化する

リーンキャンバスの価値は「書くこと」よりも「書いた仮説を検証すること」にあります。特に課題と解決策の2項目は、実際の見込み顧客の反応を見なければ正しいかどうか判断できません。ここを検証しないまま先に進めると、プロダクトを作り込んだ後に「そもそも課題設定が外れていた」と気づく、という手戻りの大きい失敗につながります。

検証の進め方としてよく紹介されるのが、顧客インタビューや MVP（実用最小限の製品）を作って反応を見る方法です。どちらも有効な手段ですが、インタビューは対象者の確保や日程調整に時間がかかり、MVP は最小限とはいえ一定の開発コストがかかります。新規事業の立ち上げ期には、プロダクトを作り込む前段階で、もっと軽く検証したい場面も多くあります。

その場合に有効なのが、リーンキャンバスの課題・解決策の仮説を簡単な資料に落とし込み、その資料への反応を計測する方法です。具体的には、次のような流れになります。

1. 課題と解決策の仮説を、1〜2枚のスライドや簡易な提案資料としてまとめる
2. その資料を PDF として DocLead にアップロードし、リード獲得フォーム付きの共有ページを発行する
3. 見込み顧客や関係者に共有ページの URL を送り、資料をダウンロードしてもらう
4. フォーム経由でダウンロードした人（誰が反応したか）とページの PV（閲覧数）を確認し、課題設定への関心度合いを見る

この方法なら、プロダクトを作り込む前の段階でも「どのくらいの人が、どの課題設定に反応したか」を数値として残せます。関心が高ければ課題設定が的を射ている可能性が高く、次のステップ（MVP開発やより深いインタビュー）に進む根拠になります。逆に反応が薄ければ、プロダクトを作り込む前に課題設定を練り直せます。

DocLead は PDF をアップロードするだけでリード獲得フォーム付きの共有ページを発行でき、ページの公開・非公開はワンクリックで切り替えられます。仮説ごとに資料を作り分けて公開し、反応を見てから次の仮説に差し替える、という軽い運用サイクルを回せるのが特徴です。反応が薄い資料は非公開に戻し、フォームから得られた反応（誰がダウンロードしたか）とPVの推移を見ながら、課題設定や解決策の仮説をキャンバスに書き戻していきます。

この検証サイクルのポイントは、プロダクトを1行もコードを書かずに始められることです。リーンキャンバスの4項目目までを書き終えた時点、つまり解決策がまだ「アイデアレベル」の段階でも、それを説明する資料さえあれば検証に着手できます。開発に着手する前に課題設定の確からしさを確認できれば、開発リソースを投じた後に「そもそも需要がなかった」と気づくリスクを減らせます。

効率化のヒント

リーンキャンバスは一度で完成させるものではありません。検証を重ねるたびに書き直す前提で運用すると、形骸化を防げます。

• 週次や隔週などの短いサイクルで見直し、変更点を記録する
• チームで共有する際は、変更前後を比較できるようにしておく（前回からどこを変えたかが分かるようにする）
• 検証結果（誰が資料に反応したか、どの課題設定への関心が高かったか）をキャンバスの余白にメモとして残す
• 埋まらないマス（主に主要指標・圧倒的な優位性）は無理に埋めず、次の検証で情報が増えたタイミングで更新する
• 資料やスライドなど検証に使った成果物は、後から見返せるようにファイル名や保存場所を統一しておく

小さく作って、実際の反応で検証し、また書き直す。この繰り返しが、リーンキャンバスを机上の空論で終わらせないための最も確実な方法です。

よくある質問

リーンキャンバスは1人で書いても良いですか？

1人で書き始めても構いません。ただし、事業に関わる他のメンバーがいる場合は、書いた後にレビューしてもらうことをおすすめします。特に課題セグメントや課題の解像度は、複数人の視点で確認すると粗さに気づきやすくなります。

9項目のうち、どこから埋めても良いですか？

順不同でも書けますが、本記事で紹介した「顧客セグメント→課題→価値提案→解決策→チャネル・収益・コスト→主要指標・優位性」の順で埋めると、前の項目が後の項目の土台になるため整合性を保ちやすくなります。迷ったらこの順番に沿って進めてください。

リーンキャンバスとビジネスモデルキャンバスはどちらを使うべきですか？

新規事業や新サービスの立ち上げで、何を検証すべきか優先順位をつけたい場合はリーンキャンバスが向いています。既存事業も含めて事業構造全体を関係者に説明したい場合はビジネスモデルキャンバスが向いています。両方を使い分けている企業もあります。

書いたリーンキャンバスはどのくらいの頻度で見直すべきですか？

決まった正解はありませんが、週次や隔週など短いサイクルで見直すと、検証結果を反映しやすくなります。特に立ち上げ初期は状況の変化が大きいため、月1回程度では変化を追いきれないことがあります。

課題を検証する前に、解決策（プロダクト）を作り始めても良いですか？

急ぎたい気持ちは理解できますが、おすすめしません。課題設定が外れていた場合、作り込んだ解決策ごと作り直すことになり、時間もコストも余計にかかります。まずは資料やインタビューなど、開発コストをかけない方法で課題への反応を確かめてから、解決策の作り込みに進むほうが、結果的に早く正しい方向へ辿り着けます。