はじめに

このリーンキャンバスは「事業を速くするためのもの」ではない

このリーンキャンバス改訂版は、仮説検証を速く回すためのチェックリストでも、投資家向けに分かりやすく整理するための資料でもない。

本来の目的はただ一つ、

事業・プロダクト・組織が、同じ世界を見て設計されているかを確認するための装置

である。

なぜ既存のリーンキャンバスでは足りなかったのか

従来のリーンキャンバスやビジネスモデル系フレームワークは、

• 問題
• 顧客
• 解決策
• 収益
• チャネル

を同一平面上で並べる構造を持っている。

これは初期整理としては有効だが、実務が進むにつれて、次のような問題が必ず起きる。

• ビジョンと打ち手が混線する
• 経営判断とプロダクト判断が衝突する
• 「正しいが噛み合っていない」議論が増える
• 誰がどこまで設計責任を持つのか曖昧になる

つまり、

問いのレイヤーが違うものが、同じ土俵で議論されてしまう

という構造的欠陥がある。

このキャンバスが前提としている考え方

1. 事業は「レイヤーの異なる設計物」の集合である

事業は一枚岩ではない。

• 世界観を決める設計
• 事業として成立させる設計
• プロダクトとして実装する設計

これらは連続しているが、同一ではない。

だから本キャンバスでは、

• A. ビジョンを捉える
• B. 事業をデザインする
• C. プロダクトをデザインする

という 三層構造 を明確に分けている。

2.「ユーザー」ではなく「瞬間」を起点にする

従来の多くのフレームワークは、

• ペルソナ
• セグメント
• ターゲットユーザー

から出発する。

しかし実務上重要なのは、

人ではなく、その人が「決断する瞬間」

である。

そのため本キャンバスでは、

• Target-Moment
• Alternative

を早い段階で置き、

価値が立ち上がる瞬間を先に固定する構造を採用している。

3.ソリューションは「最後にしか決められない」

多くの失敗は、

• Solution
• プロダクト
• 機能

を早く決めすぎることから始まる。

このキャンバスでは、

• Concept
• Target-Moment
• Problem
• Business-Model

が揃わない限り、

Solutionを語ること自体が未定義になる設計になっている。

これは遠回りに見えて、

最も手戻りが少ない進め方である。

このキャンバスの使い方について

このリーンキャンバスは、一度で埋めるものではない。完成させるものでもない。

むしろ、どこがまだ言語化できていないかを露呈させるためのものとして使われるべきである。

空白があることは失敗ではない。むしろ、どのレイヤーが未成熟なのか。どの設計責任が宙に浮いているのか。が可視化されること自体が価値である。

キャンバスフォーマット

A.ビジョンを捉える

※起業家の設計スコープに入るオブジェクト

1.Concept

• 事業を通じて実現されるべき世界観。

× NG例：

「〇〇を効率化するサービス」

「〇〇をDXする事業」

○ OK例：

「本来人が悩まなくていい判断から解放されている状態」

「専門知識を持たない人でも、適切な選択ができている世界」

プロダクト名・機能・業界用語は、できるだけ書かない。

2.Target-Moment

• ターゲットユーザーをコンセプトへと導ける最高の瞬間。

考える観点：

• いつ起きているか
• 何をしようとしているか
• なぜ今、判断が必要なのか

○ 例：

「情報が多すぎて、どれを信じていいか分からず立ち止まっている瞬間」

「今までのやり方が限界だと自覚した直後」

ここが曖昧だと、後続すべてがズレる。

3.Alternative

• その瞬間において現行では取られている代替手段。

○ よくある代替例：

• 自分で調べる
• 詳しい人に聞く
• 我慢する
• 先延ばしにする
• エクセル・メモ・チャットでなんとかする

重要なのは「なぜそれが選ばれているか」。

便利だからではなく、安心・慣れ・リスク回避が理由であることが多い。

4.Problem

• コンセプトの世界観を実現するために解決すべき重要な問題。

チェックポイント：

• 本人の努力では解決しない
• 気合や工夫で乗り切られている
• 失敗しても原因が分からない

○ 例：

「正しさを判断するための材料が、本人には揃わない構造になっている」

Problemは多くても3つまで。

B.事業をデザインする

※PMMの設計スコープに入るオブジェクト

1.Business-Model

• ビジョンを実現するための枠組み

考えるべきは：

• 誰が最終的な受益者か
• お金を払う合理性はどこにあるか
• 継続する理由は何か

「なぜこのモデルでないとConceptが実現しないのか」が説明できると強い。

2.Solution

• ビジネスモデルを成立させるシステム
• ※システム=webアプリケーションではなくオペレーションなども含めた全体的な機構のこと。

例：

• 判断を肩代わりする仕組み
• 人と機械が役割分担する構造
• 情報が集まり、整理され、返ってくる流れ

「この仕組みがないとBusiness-Modelが回らない」という視点で整理する。

3.Alliance

• ビジネスモデルを成立させるための仲間や提携先

問い：

• 自社だけでは持てない資源は何か
• 信頼・スケール・専門性はどこから補うか

将来像でもよいが、「なぜ必要か」は必ず言語化する。

4.Marketing

• ビジネスモデルを成立させるための顧客を巻き込む仕組み

観点：

• その瞬間に、どこにいるか
• どんな情報を探しているか
• 誰の言葉を信じるか

広告・SEO・営業は手段であり、本質は「接点の設計」。

C.プロダクトをデザインする

※PdMの設計スコープに入るオブジェクト

1.Service-Blue-Print

• 事業運営のための全てのフローを書き起こし、現状と理想を書き表したモノ

重要なのは：

• どこで詰まっているか
• どこが人に依存しているか
• どこを変えたいか

ここが甘いと、後段の設計が全部幻想になる。

2.Stakeholder-Xperience

• 各関係者に対してどのような体験を提供するのか表したモノ

問い：

• その人は、どこで不安になるか
• 何が分かれば前に進めるか
• 何を任せ、何を任せないか

体験は感情と判断のセットで考える。

3.Operation-Architecture

• オペレーションをどの組織がどのように担い連携するのかの全体構造を表したモノ

見るべき点：

• 判断は誰が持つか
• 失敗時の責任はどこに返るか
• スケールしたとき壊れないか

ここが曖昧だと、成長と同時に破綻する。

4.System-Architecture

• テクノロジーをどのようにどの領域で用いるのかの全体構造を表したモノ

ポイント：

• 判断の自動化と責任の所在
• ログ・検証・巻き戻しが可能か
• 将来変更できる余地があるか

AIを使うかどうかより、「任せ方」が重要。

5.Production-Line

• プロダクト開発をどの部分をどんな組織が担い行っていくのかを表したモノ

観点：

• 何が内製で、何が外注か
• どこがボトルネックになりやすいか
• 速度と品質のトレードオフはどこか

ここは「今」より「半年後」を想定すると良い。