インセプションデッキとは？新規事業の合意形成に効く10項目

新規事業やプロジェクトを立ち上げる際、関係者全員の認識を1枚絵で揃えるためのアジャイル発祥のツールがインセプションデッキです。「インセプトデッキ」と呼ばれることもありますが、正式名称は「Inception Deck（インセプションデッキ）」で、Jonathan Rasmusson著『アジャイルサムライ』（2010年原著、邦訳オーム社）で世界に広まりました。

本記事では、インセプションデッキを構成する10の質問を新規事業の文脈で再解釈し、具体的な書き方・テンプレート・活用ポイントを実務目線で解説します。

インセプションデッキとは何か？

インセプションデッキとは、プロジェクトのWhy（目的）／What（成果物）／How（進め方）を10の質問でA4スライド10〜15枚程度にまとめ、ステークホルダー全員で期待値合わせ（Alignment & Expectation Setting）を行うための軽量チャーター（憲章）です。

アジャイルサムライ日本語版コミュニティ（agile-samurai-ja）では、Keynote／PowerPoint版の空白テンプレートが公開されており、誰でも自由に利用できます。

インセプションデッキの3つの定義特徴

特徴	内容
軽量性	重厚なPMBOK型プロジェクト計画書ではなく、10枚前後で完結する
対話前提	完成物よりも「議論プロセスの中で合意が形成されること」自体が成果物
期間目安	作成に数日〜2週間。3〜6ヶ月のプロジェクトに有効（Agile Warrior, 2010）

なぜ今、新規事業に必要なのか

新規事業は「正解がない・ステークホルダーが多い・撤退判断が遅れがち」という3重苦を抱えます。インセプションデッキは、走り出す前に「やらないこと」「諦めるもの」「眠れない問題」を文字にして配ることで、後工程の手戻り・社内政治・スコープクリープを大幅に減らせます。

インセプションデッキ 10項目の全体像

10項目は前半5つ（Why＝なぜ作るか）と後半5つ（How＝どう作るか）に大別されます。

#	項目（日本語）	原題	区分	一言で言うと
1	われわれはなぜここにいるのか	Ask why we are here	Why	事業の存在意義
2	エレベーターピッチ	Create an elevator pitch	Why	30秒で語れる本質
3	パッケージデザイン	Design a product box	Why	顧客への訴求軸
4	やらないことリスト	Create a NOT list	Why	スコープの境界線
5	「ご近所さん」を探せ	Meet your neighbours	Why	ステークホルダー地図
6	解決案を描く	Show the solution	How	技術アーキテクチャの粗描き
7	夜も眠れない問題	What keeps us up at night	How	主要リスクの可視化
8	期間を見極める	Size it up	How	スケジュールの当たり
9	何を諦めるのか（トレードオフスライダー）	What's going to give	How	QCDS優先順位
10	何がどれだけ必要か	What's it going to take	How	体制とコスト

【Why編】1〜5項目：なぜ作るのかを言語化する5つの問い

1. われわれはなぜここにいるのか

プロジェクトの根本動機を、スポンサーの言葉ではなく自分たちの言葉に翻訳する項目です。問いはシンプルで「なぜこの事業をやるのか？」「やめたら何が困るのか？」の2つ。

新規事業の場合、顧客の現場に最低3回は足を運び、ペルソナの一次情報を持ち帰ったうえで、チーム全員で「なぜ自社がやるべきか」を1ページに落とします。社内の根回し用パワポではなく、現場で得た生の課題引用を1つは入れたい。「上から言われたから」を理由にすると、まずチームが動きません。

2. エレベーターピッチ

30秒で事業を説明できるレベルまで磨く項目です。後でピボット判断するときの「何を残すか」の判断基準にもなります。

書き方は、Geoffrey Mooreのポジショニング論で広く知られる型を流用するのが定番です。

[潜在ニーズ]を解決したい[ターゲット顧客]向けの、
[プロダクトカテゴリ]である[プロダクト名]は、
[重要な利点と対価に見合う説得力のある理由]ができ、
[代替手段の最右翼]とは違って、
[差別化の決定的な特徴]が備わっている。

ピッチを書けないということは、事業の輪郭がまだ定まっていないという診断結果でもあります。月1回更新し、変化の履歴をそのままピボット記録として残すと、後で振り返るときに役立ちます。

3. パッケージデザイン

「もし店頭に並ぶならどんな箱か」を絵にして、顧客視点の便益（Benefit）と機能（Feature）を切り分ける項目です。

作り方は3ステップ。

1. 商品名・キャッチコピー・3つのベネフィットを書く
2. ベネフィットの裏に「どんな機能がそれを実現するか」を紐付ける
3. チームメンバー数人で別々に書き、ズレを議論する

B2B SaaSのような無形サービスでも、「もし箱に入っていたら」という思考実験は機能優先順位付けに直結します。

4. やらないことリスト

スコープクリープ（範囲の肥大化）を防ぐ項目です。「何をしないか」を意思決定として明文化します。

書き方は3分類。

分類	例
やる	法人ユーザーの一括登録機能
やらない（明示的に切る）	多言語対応、SSO連携
後で決める	個人ユーザー向けプラン、API公開

本丸は「やらない」をスポンサーに承認してもらうこと。口頭ではなくデッキに書き、押印レベルで合意しておきます。

5. 「ご近所さん」を探せ

プロジェクトに影響を与える／受ける関係者を網羅的に洗い出し、巻き込み戦略を立てる項目です。

ステークホルダーマップの構成例。

カテゴリ	例
中核チーム	PM、開発、デザイナー
直接の関係者	営業、カスタマーサクセス、法務
間接の関係者	経理、人事、情報システム
外部	顧客、パートナー、規制当局、株主

「事前に顔を売っておくべき人」「敵に回すと致命的な人」をマーキングし、キックオフ前に1on1を入れておくと、後々の合意形成が一気に楽になります。

【How編】6〜10項目：どう作るのかを設計する5つの問い

6. 解決案を描く

アーキテクチャをざっくり描いて「技術的に成立する」ことをチームで合意する項目です。

書き方の原則は3つ。詳細設計ではなくホワイトボード1枚レベルで止める。不明点・前提・既知のリスクは図内に明記する。技術選定の代替案も併記する（PostgreSQL vs DynamoDBなど）。

ありがちな落とし穴が、いきなりマイクロサービスやMLモデルを盛り込んでしまうこと。MVPフェーズなら、モノリス＋外部APIで十分なケースが大半です。

7. 夜も眠れない問題

黙っていれば消えるリスクを、あえて口に出して台帳化する項目です。

典型的な「眠れない問題」5パターン。

カテゴリ	例
市場リスク	競合（既存プレイヤー）が同じ機能を半年以内に出す
技術リスク	想定APIのレート制限が事業計画に合わない
法務リスク	個人情報保護法・電子帳簿保存法の改正影響
組織リスク	キーマンの離脱、開発リソースの兼務問題
資金リスク	想定売上が立たない場合の追加調達余力

月次で「眠れる／眠れない」のステータス更新を行い、解消したものはチームでちゃんと祝うこと。リスク管理は「祝う場」とセットで運用すると続きます。

8. 期間を見極める

不確実性が高くても、終わりを区切ることでマネジメントを成立させる項目です。

アジャイルサムライでは3〜6ヶ月を1つの区切りとして推奨しています。新規事業なら、3ヶ月の実証実験フェーズ＋3ヶ月の本格開発フェーズに分けるのが現実的。線表ではなくマイルストーンで管理します（例: M1 プロトタイプ完成、M2 クローズドβ、M3 一般公開）。

9. 何を諦めるのか（トレードオフスライダー）

QCDS（品質・コスト・納期・スコープ）の優先順位を事前に合意する項目です。

スライダー記入例。

軸	高 ←──────→ 低	補足
スコープ	●──────	機能を削る前提
期間	──────●	半期内のリリース必達
予算	───●───	初期予算の20%まで超過可
品質	●──────	決済まわりの品質は譲れない

新規事業の鉄則として、「全部Max」は無理。実質的にスコープが調整弁になることを最初に宣言しておくと、後の修羅場で揉めません。

10. 何がどれだけ必要か

体制・期間・コストを概算し、スポンサーから「Go」の判断をもらう項目です。

算出項目の例（期間6ヶ月・チーム5.5名想定の人件費内訳）。

区分	役職・項目	単価・内訳	期間	金額
人件費	プロダクトオーナー（PO） 0.5名	月120万円 × 0.5	6ヶ月	360万円
人件費	プロジェクトマネージャー（PM） 1名	月120万円	6ヶ月	720万円
人件費	エンジニア 3名	月100万円 × 3	6ヶ月	1,800万円
人件費	デザイナー 1名	月120万円	6ヶ月	720万円
人件費 小計	—	—	—	3,600万円
直接費	外部ツール（SaaS・クラウド・有償ライブラリ等）	月20万円	6ヶ月	120万円
間接費・予備費	直接費合計の15%（仕様変更・追加調査等のバッファ）	—	—	558万円
合計	—	—	6ヶ月	約4,278万円

※ 単価は新規事業立ち上げ向けの一般的な業務委託相場（東京・2026年時点の参考値）。社員のみで構成する場合は社会保険料・福利厚生分を含めて再計算が必要です。

コツは、「人月」だけで見積もらないこと。プロダクトオーナー（PO）の稼働率まで含めて算出するのが、新規事業特有のポイントです。POの片手間運用は、新規事業の失敗要因として個人的にもよく見ます。

インセプションデッキの作り方：5ステップ実践手順

Step 1: 開催準備（所要1〜3日）

• 参加者: PM、PO、エンジニア、デザイナー、主要ステークホルダー（5〜10名）
• 場所: オフライン推奨（リモートの場合はMiro、Cacoo、Mural等のホワイトボードツール）
• 事前資料: 顧客インタビューのサマリー、競合調査、技術調査メモ

Step 2: ワークショップ実施（所要1〜2日）

• 1日目: Why編（項目1〜5）を午前午後で集中議論
• 2日目: How編（項目6〜10）を実施。10は最後に必ず行う

Step 3: ドラフト作成（所要2〜3日）

• 議論メモをスライド10〜15枚に整理
• 写真や付箋の画像も貼り、議論の熱量を残す

Step 4: ステークホルダーレビュー（所要1週間）

• スポンサーに正式レビューを依頼
• 特に「やらないことリスト」「トレードオフスライダー」を口頭で読み合わせる

Step 5: 運用と更新

• キックオフで全員に配布
• 月1回（最低でも四半期1回）レビューし、変更履歴を残す
• 大幅変更時はピボット会議を開く

インセプションデッキと他フレームワークの違い

新規事業の現場では複数のフレームワークが併用されます。役割の違いを整理しておきましょう。

フレームワーク	主目的	主な利用フェーズ	強み	限界
インセプションデッキ	プロジェクト合意形成	立ち上げ	軽量・対話的	仮説検証は別途必要
リーンキャンバス	ビジネスモデル仮説	アイデア検証	1枚で全体俯瞰	体制・スケジュール不在
ビジネスモデルキャンバス	既存事業の分析	戦略策定	9ブロック構造	顧客課題の深掘り弱い
PRD（Product Requirements Document）	プロダクト要求仕様	開発前	機能粒度の明確化	Why/Whoが薄い
PMI/PMBOK プロジェクト憲章	大規模PJの公式承認	計画	網羅性	重厚で動きが遅い

使い分けの推奨: アイデア段階＝リーンキャンバス → 立ち上げ＝インセプションデッキ → 開発フェーズ＝PRD、というリレー方式が現実的です。

インセプションデッキ作成時の落とし穴とコツ

よくある失敗パターン5選

1. 「完成」を目的化する: 議論プロセスが本体。スライドは副産物
2. PMだけで作ってしまう: 関係者が議論に参加しないと合意は形成されない
3. やらないことリストが空白: 「全部やる」は何も決めていないのと同じ
4. トレードオフスライダーを全部Max: スポンサーの「全部欲しい」を翻訳するのがPMの仕事
5. 作って終わり: 月次レビューしないと壁の絵になる

成功させる3つのコツ

• オフライン2日合宿: リモートよりも合意形成の質が圧倒的に高い
• POを巻き込む: 0.5人月以上の稼働を最初に確保する
• 「眠れない問題」を経営に共有: リスクを上層に開示することで、後の意思決定が速くなる

まとめ：インセプションデッキは「議論の足場」である

インセプションデッキは、書き上げることが目的ではありません。10の問いを通じてチームに共通言語を作ること、そのプロセスこそが本体です。新規事業のような不確実性の高い領域では、走り出す前の2週間の投資が、後の半年〜1年のスピードを大きく変えると感じています。

まずはアジャイルサムライ日本語コミュニティの空白テンプレートをダウンロードして、「われわれはなぜここにいるのか」から書き始めてみてください。最初の1問だけでも、チーム内の温度差がはっきり見えてくるはずです。

FAQ

Q1. インセプションデッキとインセプトデッキは違うものですか？

同じものを指します。正式名称は「Inception Deck」で、日本語ではインセプションデッキ／インセプトデッキの2表記が混在しています。アジャイルサムライ（オーム社）では「インセプションデッキ」表記が用いられています。

Q2. インセプションデッキの作成にはどれくらい時間がかかりますか？

ワークショップ実施が1〜2日、ドラフト作成・レビューを含めて合計2週間が目安です。Agile Warrior（2010）では「3〜6ヶ月のプロジェクトに有効」とされており、長期プロジェクトの場合は四半期ごとの更新を推奨します。

Q3. 10項目すべてを必ず作る必要がありますか？

必須ではありません。プロジェクトの規模・性質に応じて省略可能ですが、新規事業では「1. なぜここにいるのか」「4. やらないことリスト」「7. 夜も眠れない問題」「9. トレードオフスライダー」の4項目は最低限必須と考えてください。

Q4. リーンキャンバスやビジネスモデルキャンバスとの違いは？

リーンキャンバス／BMCはビジネスモデル仮説を整理するツール、インセプションデッキはプロジェクト遂行の合意形成ツールです。アイデア段階ではキャンバス、立ち上げ段階ではデッキ、というリレー運用が現実的です。

Q5. リモートでも作成できますか？

可能です。Miro、Cacoo、Muralなどのオンラインホワイトボードツールが利用できます。ただし合意形成の質はオフラインに劣るため、初回は1日でもオフライン合宿を推奨します。

Q6. 中小企業や1人スタートアップでも使えますか？

使えます。1人でも10の問いに自答することで、思考の漏れを発見できます。ただし「ご近所さん」「夜も眠れない問題」は外部メンター・投資家との壁打ちで補完すると質が上がります。

Q7. インセプションデッキはいつ更新すべきですか？

月1回の定例レビュー、四半期での全体見直し、ピボット時の臨時更新が推奨です。「やらないことリスト」と「トレードオフスライダー」は特に変動しやすいので、毎月チェックしてください。

Q8. インセプションデッキのテンプレートはどこで入手できますか？

アジャイルサムライ日本語版コミュニティ（GitHub: agile-samurai-ja/support）でKeynote／PowerPoint版が無料公開されています。MiroやCacooにも公式テンプレートが用意されています。