インセプションデッキの作り方
インセプションデッキは、軽量なプロジェクト憲章ツール、あるいはプロジェクト初期の「最初の山札」とも称され、特にアジャイルソフトウェア開発において、プロジェクトに関与する全てのステークホルダー間で共通理解を確立するために不可欠なものとされていますす。その主な目的は、本格的な開発に着手する前に、ビジョン、スコープ、目標、そして主要なパラメータについて認識を合わせることにあります。
インセプションデッキが解決しようとする核心的な問題は、プロジェクトの目標、目的、背景に対する認識の齟齬に起因するプロジェクトの失敗を防ぐことです。これらはしばしば、プロジェクトが開始される前にその運命を決定づけてしまいます。インセプションデッキは、「合意が存在しないにもかかわらず、合意があると思い込む」というよくある問題を解決します。
その利点としては、プロジェクトスコープの明確化、チーム内での統一された認識の醸成、優先順位の可視化、課題の事前予測、そしてユーザー価値の明確化などが挙げられます。
インセプションデッキとは
インセプションデッキとは、プロジェクト開始時に利害関係者間で認識を揃え、プロジェクトの目的やスコープ、成功条件を言語化するための資料です。形式としては、数枚から十数枚のスライドで構成され、ビジョンやペルソナ、機能一覧、リスク、スケジュールなどを可視化します。
これは単なる「企画書」ではなく、プロジェクトの“起動（inception）”を円滑に進めるための共通理解ツールであり、アジャイルコーチやスクラムマスターの間で広く用いられています。
インセプションデッキを用いると、意思決定の判断軸が明確化され、要件変更や範囲拡大の際も根拠に立ち返りやすくなるため、プロジェクト全体のブレを抑制できます。特に多様なバックグラウンドを持つメンバーが集まる場合、その効果は一層大きくなります。
インセプションデッキを作成する目的
インセプションデッキを作成する主な目的は三つあります。
第一に、ステークホルダー全員のゴールを一致させること。ビジョンやKPI、スコープを明文化することで、プロジェクトの方向性に迷いがなくなります。第二に、リスクや前提条件を洗い出し、認識のズレを事前に無くすこと。これにより、開発初期の大きな手戻りを防ぎ、スムーズなスタートアップを実現します。第三に、チームのコミットメントを高めること。各自が「なぜこの仕事をするのか」を理解し、能動的に動けるようになるため、生産性およびモチベーションが向上します。
これら三つの目的を同時に達成するには、ただスライドを作るだけでなく、ワークショップ形式でチーム全員の意見を引き出しながら進めることが重要です。ワークショップのファシリテーションを意識した構成にすることで、議論の質が上がり、完成度の高いデッキができあがります。
インセプションデッキ 10の質問
インセプションデッキを構成する際、以下の10の質問を順に検討すると効果的です。これらは、Google Venturesのデザインスプリントやアジャイル開発のベストプラクティスから抽出したもので、プロジェクトの骨子を体系的に整理できます。
1. 我々は何故ここにいるのか？
プロジェクトの根本的な理由と目標を定義する。企業MVV/OKRとの深い整合性、「なぜ今か」の明確化。
プロジェクトの存在意義は、企業のミッション・ビジョン・バリューやOKRと結び付けて初めて説得力を持つ。まずは組織が掲げる長期的な社会的インパクトを再確認し、その達成に向けて当該プロジェクトがどのギャップを埋めるのかを定義することが出発点となる。
さらに「なぜ今なのか」を示すために、市場環境や顧客ニーズの変化、規制・テクノロジー動向など外部要因を根拠立て、タイムクリティカルな背景を示すとチームの緊張感と意思決定の速度が高まる。
こうして根本的な目的を言語化することで、以降の議論で迷ったときに立ち返る北極星が共有される。
2. エレベーターピッチを作る
プロジェクトの簡潔で説得力のある要約を作成する。ストーリーテリング、明確な価値提案。
プロジェクトの核心を30秒で語れるようにすることは、社内外での支持獲得に直結する。顧客像と課題をワンフレーズで提示し、その課題をどう解決してどんな価値を生むのかをストーリーとして結ぶ。
ここでは「ヒーローズジャーニー」の構造を意識すると、聞き手が主人公に感情移入しやすくなる。企業MVVに合致した社会的意義を最後に添えると、単なる機能説明ではなく、共感を呼ぶ語り口になる。
3. パッケージデザインを作る
製品の視覚的表現を通じて共通認識を醸成する。サービスや無形製品への応用、視覚的コラボレーションツールの活用。
製品やサービスの完成形を視覚的に表現することで、メンバー間の解像度を一気にそろえられる。物理的パッケージが存在しないSaaSやコンサルティングのような無形商材でも、LPのファーストビューやアプリのホーム画面、サービスロゴなどを擬似的な“箱”としてデザインすることで同じ効果が得られる。
Figma や Miro など共有型のボードを使い、リアルタイムでアイデアを付箋や図形に落とし込むと、視覚的コラボレーションが促進され、完成イメージが短時間で固まる。
4. やらないことリストを作る
スコープ外を明確にし、期待値を管理する。厳密な定義、MVPとの連携、動的な環境での焦点維持。
プロジェクトの成功確率を上げるには、何をやらないかを明示し、チームの集中力と期待値を守ることが欠かせない。ビジョンと直接関係しない機能や将来の拡張要件を切り離し、「今回は手を付けない」と宣言することで、MVPを最短距離でリリースできる。
環境変化が激しい領域では、定期的にリストを見直してもよいが、更新する際には必ず「なぜ追加・削除するのか」の根拠を添えて焦点をぶらさないようにする。
5. ご近所さんを探せ
関係者を特定し、関係性を理解する。詳細なステークホルダーマッピング、コミュニケーション計画の策定。
ステークホルダーを網羅的に洗い出し、その利害・影響度・関与度をマッピングすることで、後の合意形成が容易になる。社内部門や経営層はもちろん、外部パートナー、規制当局、場合によってはコミュニティまで含め、双方向の期待と要望を整理する。
関係者の優先順位に応じてコミュニケーションチャネルと頻度を設計し、適切な情報粒度でレポーティングする計画を立てておくと、プロジェクト後半に発生しがちな“棚卸しミーティング地獄”を避けられる。
6. 解決策を描く
技術的アプローチや開発手法の概要を示す。複雑なシステムのための視覚化、Low-code/No-codeプラットフォームの活用検討。
ここでは技術スタックやアーキテクチャ、業務プロセスの大枠を示し、ソリューションの実現性を定性的に確認する。マイクロサービスやイベント駆動、Low-code/No-code といった選択肢を比較し、なぜその構成が戦略的にフィットするのかを説明する。
複雑な依存関係やデータフローはC4モデルやシーケンス図に落とし込み、視覚的に共有することで、技術・業務双方のメンバーが同じ絵を見ながら議論できる状態をつくる。
7. 夜も眠れない問題は何か？
プロジェクトのリスクや懸念事項を洗い出す。構造化されたリスク議論、Pre-mortemの導入。
プロジェクトを頓挫させかねないリスクや不確実性を、感情論ではなく構造化された形で洗い出す。まずは Pre-mortem 手法を取り入れ、「もしこのプロジェクトが失敗したと仮定したら、理由は何だろう」と逆算思考で議論すると、潜在的な脅威が顕在化しやすい。リスクは発生確率と影響度で評価し、対策オーナーと監視方法をスライドに明文化しておくと、後工程のリスクリストにシームレスに接続できる。
8. 全体像を把握する（期間を見極める）
プロジェクトの規模や期間を大まかに見積もる。不確実性の高いプロジェクトのための柔軟な予測、価値ベースの見積もり。
機能点数や開発工数を粗く見積もり、フェーズ分割のロードマップを描いて全体の大きさを把握する。仮説駆動で開発を進める場合は価値ベース見積もりを併用し、「顧客価値が高い順に実装していく」方針を前面に打ち出すと、仕様変更が生じても優先順位の議論に戻りやすい。
不確実性の高い領域ではバッファを厚めに取り、タイムボックスを設けたスパイク作業で未知を削減する戦略が有効である。
9. 何を諦めるか？
プロジェクトの制約における優先順位を決定する。多様なステークホルダー間での真の合意形成を促すファシリテーション。
リソースや期限が有限である以上、最終的に削るべき要素を合意形成するフェーズが必要になる。品質、範囲、コスト、スケジュールのどこを柔軟にするかをチーム全員で可視化し、トレードオフを受け入れる覚悟を共有する。
ファシリテーターは、立場や権限が異なるステークホルダー間で利害を調整し、合意文書として残すまでを責任範囲とする。こうして決定した「諦め」のラインは、後日に議論が蒸し返された際の防波堤として機能する。
10. 何がどれだけ必要なのか？
必要なリソース（チーム、予算、スキル）を明確にする。チームのワーキングアグリーメントの初期設定となる。
この10の質問を一つずつ具体的に議論し、回答をスライドにまとめることで、デッキ全体がブレのない一貫性を持ちます。各質問は論理的に前後関係があり、回答を洗い出す順序も大切です。最初に「なぜ」を議論し、次に「誰」を明確にし、最後に「どう測るか」を固めることで、ストーリー性のあるデッキになります。
トレンドは、これらの問いを、プロジェクト開始時の全ての重要な側面が議論されることを保証するための包括的なガイドとして使用し、独断的なチェックリストとしてではなく、これらの問いが引き起こす対話に焦点を当てることです。
したがって、10の問いは優れた出発点を提供しますが、チームは特定のプロジェクトの文脈とインセプションデッキの望ましい成果に合わせて、これらを調整する権限を持つべきです。
インセプションデッキ「やらないことリスト」
プロジェクトを効率的に進めるためには、「やらないこと」を明確にすることが重要です。やらないことリストを作ることで、スコープクリープ（範囲拡大）を抑え、リソース配分の無駄を防ぎます。以下の観点で検討しましょう。
まず、要望のうち「ビジョンに直結しない機能」は明確に除外します。例えば、将来的に必要となるかもしれないが今回のMVPには不要な機能はすべてやらないこととしてリスト化します。次に、技術的制約や法規制によって実現が難しい機能や期間内に実装困難な要素もリストに含めます。さらに、マーケットやオーディエンス調査から外れた顧客セグメント向けの要件も「やらないこと」として切り捨てます。
このリストは単なる否定ではなく、優先度を担保するための意思決定ツールです。デッキのスライドに「インセプションデッキ やらないことリスト」というタイトルで設け、チーム全員で合意を取りましょう。
インセプションデッキのトレードオフスライダー
トレードオフスライダーは、プロジェクトの品質・コスト・スコープを可視化するフレームワークです。
各要素をスライダーで表現し、どこに重きを置くかをチームで合意します。例えば品質を高く設定すればコストとスケジュールに厳しさが増すなど、各要素の相関関係を理解できるようにします。
品質
成果物がどれだけ安定的で高い価値を提供できるかを示します。トレードオフスライダー上で品質を上げるほど、テスト工程や細部の仕上げに時間とリソースを割く必要があるため、自然とコストとスケジュールには厳しさが増します。
高品質を最優先する場合には、機能の数を絞り込むか、追加予算を確保するか、あるいはリリース時期を後ろ倒しにする決断が必要になります。
このように品質を軸に置くことで、チーム内で「どこまで妥協せずに製品を仕上げるか」という共通理解を持ちやすくなります。
範囲
プロジェクトで実現すべき機能や要求事項の総体的なボリュームを指します。スライダーで範囲を広げることは、実装すべき機能の増加を意味し、結果としてコストとスケジュールを圧迫します。
逆に範囲を絞り込むことで、限られた時間内に品質を担保しつつリリースできる可能性が高まり、コストの最適化にもつながります。
ここで重要なのは、あらかじめ「今回やらないことリスト」を定義し、不要な機能を意図的に排除する意思決定をドキュメント化しておくことです。そうすることで、後続の仕様変更要求に対しても、範囲をコントロールしやすくなります。
コスト
プロジェクトに投入できる予算や人的リソースの上限を示す要素です。スライダーでコストを抑えたい場合には、範囲と品質のいずれか、もしくは両方を調整する必要が生じます。
たとえば、予算を厳格に管理するプロジェクトでは、品質基準をある程度許容するか、機能を最小限に絞ったMVP形式でリリースするかを検討しなければなりません。
予算超過のリスクを回避しながらチームが最大の価値を発揮できるよう、コスト軸の設定はステークホルダー全員で合意することが不可欠です。
スケジュール
ロジェクトを完了させるまでの期間的制約を表します。リリース期限が厳しい場合には、品質や範囲、コストのいずれか、あるいは複数をトレードオフとして受け入れる必要があります。
たとえば、固定された納期に合わせるために範囲を削減し、本質的な機能だけを優先的に開発するといった判断が求められます。また、スケジュールを延長できる余地がある場合には、品質向上や追加機能の実装を検討できるため、全体のバランスを再設定しながら最適解を探っていくプロセスが重要です。
トレードオフスライダーの使い方
具体的には、スライダーを３軸（品質、コスト、スケジュール）または４軸（品質、範囲、コスト、スケジュール）で描き、各軸の目盛りを初期値として示します。ワークショップ時は、ステークホルダーと議論しながらスライダーをスライドさせ、最終的なバランスポイントを決定します。これにより、要件変更や追加リクエストの際に、「なぜ優先度を落とすのか」「どこを犠牲にするのか」を具体的に説明でき、合意形成が容易になります。
インセプションデッキ テンプレート(GitHub)
以下は、典型的なインセプションデッキのテンプレート構成例です。プロジェクト規模やフェーズに応じて必要なスライドを追加・削除してください。
- タイトル（プロジェクト名／日付／作成者）
- ビジョンステートメント（なぜこのプロジェクトか）
- ペルソナ／ユーザーセグメント
- 課題とニーズ
- テクノロジースタック／プラットフォーム
- スコープ（機能一覧）
- やらないことリスト
- トレードオフスライダー
- リスクと前提条件
- タイムライン（ロードマップ）
- 役割とチーム編成
- 成功指標（KPI）
- 次のアクション／意思決定ポイント
このテンプレートは社内ドキュメントとして共有し、必要に応じてプロジェクトごとにカスタマイズすると良いでしょう。テンプレート自体を Google スライドや PowerPointで用意し、常に最新バージョンを参照できるよう運用すると、毎回の作成効率が向上します。
参考: Notionでインセプションデッキテンプレートを作ったので公開します
インセプションデッキの具体例
最後に、実際のプロジェクトで使われたインセプションデッキの例を紹介します。あるECサイトリニューアルプロジェクトでは、以下のように構成されました。
- ビジョンステートメント：「ユーザーがストレスなく購入を完了できる直感的なUIを提供し、コンバージョン率を20％向上させる」
- ペルソナ：「30代子育てママ」「初めてECを使う高齢者」
- 機能一覧：「ワンクリック購入」「ゲスト購入」「おすすめレコメンド」
- やらないこと：「ソーシャルログイン」「AR試着機能」
- トレードオフスライダー：品質80、コスト60、スケジュール70
- リスク：「決済システムのAPI変更」「物流システム連携の遅延」
- タイムライン：プロトタイプ2週間、ユーザーテスト1週間、本番リリース1ヶ月後
- KPI：「購入完了率」「カゴ落ち率」「平均購入単価」
このように、各要素を具体的な数値やユーザー像で示すことで、チーム全員が認識を揃えた状態でプロジェクトを開始できました。特に「やらないこと」と「トレードオフスライダー」は、後半の要件変更時に迅速な意思決定を支えるキーとなりました。
インセプションデッキの作り方まとめ
インセプションデッキは、プロジェクトを成功に導くための強力なコミュニケーションツールです。インセプションデッキは、プロジェクトの主要な側面が変更されたときに更新され、再検討されるべき「生きた、呼吸するプロジェクト成果物」であるべきです。作成されてから破棄されるものではありません。これは、「最終版」がその時点でのみ最終であり、容易に更新可能であるべきことを意味します。
インセプションデッキを再検討し更新するための4つの主要なタイミングは、❶メンバー／ステークホルダーの変更時、❷プロジェクトの方向性の変更時、❸定期的（例：四半期ごと）、❹進捗不良／リスク顕在化時とされます。Notion、Confluence、Google Docsのようなツールは、生きた文書の作成を容易にします。
アジャイルプロジェクトは変化によって特徴付けられます。静的なインセプションデッキはすぐに時代遅れになり、無関係になります。「生きた文書」という概念は、持続的な価値にとって不可欠です。
したがって、ドキュメンテーションのトレンドは、単に洗練された「最終」デッキを作成するだけでなく、容易な更新とバージョン管理を可能にするフォーマットとプラットフォーム（例：共同作業ウィキ、共有ドキュメント）を選択し、プロジェクトライフサイクル全体を通じて関連性のあるガイドであり続けることを保証することです。「最終報告書」は、むしろ「現在の作業バージョン」に近いものです。
これらを踏まえて、自社のプロジェクトに最適なインセプションデッキを設計し、チームの共通理解を深め、意思決定をスピーディかつ確実にする一助としてください。記事が皆さまのプロジェクト立ち上げにお役立てば幸いです。
