インセプションデッキの作り方｜10の質問とシステム開発の記入例

インセプションデッキは、プロジェクトを始める前に「10の質問」にチームと関係者で答え、スライド10枚ほどにまとめたものです。 目的は、原典の言葉で「alignment and expectation setting」、つまり全員の向きをそろえ、期待をすり合わせることです。

確認環境：10の質問の名前は、オーム社の書籍ページの目次（第4章・第5章の節名）と、Jonathan Rasmusson のブログ記事「The Agile Inception Deck」の原文で確かめました。スライドの文言は、日本語版の公式サポートリポジトリ（GitHub の agile-samurai-ja/support）にあるテンプレート（日本語版 0.4、2012-04-02）から文字を取り出して確かめています。Markdown のテンプレートを調べるスクリプトは Python 3.11.15（Linux）で動かし、Mermaid の図は Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0）で描画できることを確かめました（確認日 2026年10月13日）。

インセプションデッキとは

インセプションデッキは、Jonathan Rasmusson が書籍『The Agile Samurai』（日本語版『アジャイルサムライ――達人開発者への道』、オーム社、2011年）で紹介した、プロジェクトの方向づけの道具です。 著者のブログでは、アジャイルの手法の多くが「プロジェクトの憲章づくり（project chartering）」について触れていない、という問題意識から書かれています。

• 何をするか：10の質問に、チームと関係者が一緒に答えます。答えをスライド1枚ずつにまとめます。
• 何が得られるか：「なぜやるのか」「何をやらないのか」「何を譲るのか」が、コードを書く前に合意されます。
• どのくらい使えるか：ブログでは、作るのに「数日から1〜2週間」かかり、「3〜6か月分の計画」に使えるとしています。
• 作ったあと：テンプレートの最後のスライドには、見えるところに貼り、状況が変わったら更新する（"Put it somewhere visible for all too see. And update it when things change."）と書かれています。

flowchart LR
  subgraph W["前半：なぜ・なに（第4章 全体像を捉える）"]
    q1["1 我われはなぜここにいるのか"] --> q2["2 エレベーターピッチ"] --> q3["3 パッケージデザイン"] --> q4["4 やらないことリスト"] --> q5["5 ご近所さんを探せ"]
  end
  subgraph H["後半：どうやって（第5章 具現化させる）"]
    q6["6 解決案を描く"] --> q7["7 夜も眠れなくなる問題"] --> q8["8 期間を見極める"] --> q9["9 何を諦めるのか"] --> q10["10 何がどれだけ必要か"]
  end
  q5 --> q6

書籍では、前半の5つが第4章「全体像を捉える」、後半の5つが第5章「具現化させる」にまとめられています。 前半で「なぜ・なに」をそろえ、後半で「どうやって・いくらで」を見積もる流れです。

プロジェクト憲章・キックオフとの違い

インセプションデッキの答えは、憲章やキックオフの資料の材料になります。プロジェクト憲章は関連記事「プロジェクト憲章の書き方｜テンプレート全文とシステム開発の記入例」で、キックオフの資料は「キックオフミーティングのアジェンダテンプレートと資料の目次例・進め方」で扱っています。

記入例の前提：社内の勤怠管理システムの刷新

この記事では、次のプロジェクトを例に10枚を書きます。人数や期間は説明のための仮の値です。

• 社員 約300名の会社。今は勤怠のパッケージ製品と Excel を組み合わせて使っている
• パッケージの保守が切れるため、社内向けの Web アプリに作り替える
• 打刻（ICカード・Web）、休暇・残業の申請と承認、給与計算システムへの連携を対象にする
• スポンサーは人事部長。開発はチーム5名

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

目的：プロジェクトをやる理由を書き出し、いちばん大事な1つを選びます。 ブログでは「なぜ作るのかを知らなければ、よいプロダクトは作れない」と説明しています。開発の途中で判断に迷ったとき、この1つに立ち返ります。

書き方：テンプレートの説明は「会社がこのプロジェクトにお金を使いたい理由を全部書き出し、いちばん大事なものを1つ選んで目立たせる」です。日本語版のスライドには「大事な理由その1〜3」と「このプロジェクトの根幹に関わる理由を1つ、ここに書く」の欄があります。

記入例

書くときのコツ：理由は「〜を作る」ではなく「〜できるようにする」と、結果で書きます。手段（Web アプリにする）が理由に入ると、別の手段を比べられなくなります。

2. エレベーターピッチ

目的：プロダクトを「誰の・何のための・ほかと何が違うか」で、30秒ほどで言える形にします。 ブログでは「何のプロダクトか、誰のためか、なぜ特別か」を伝えるものとしています。著者はコメント欄で、この型は Geoffrey Moore の『Crossing the Chasm（キャズム）』から来たと書いています。

日本語版テンプレートの型（原文のまま）

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

記入例

月末の締めと残業時間の確認に手間をかけたくない
人事部と管理職 向けの、
「勤怠ナビ」というプロダクトは、
社内向けの勤怠管理Webアプリ です。
これは 打刻から承認、給与計算への連携までを1か所で終えること ができ、
現行のパッケージとExcelの組み合わせ とは違って、
残業の上限に近づいた社員を月の途中で知らせる機能 が備わっている。

書くときのコツ：「代替手段の最右翼」には、利用者が今使っているもの（今のやり方）を書きます。社内システムでは、競合の製品より「今の手作業」が最大の代わりになることが多いです。

3. パッケージデザイン

目的：プロダクトが店の棚に並んでいたら、箱に何が書かれているかを考えます。 テンプレートの説明は「チームに、利用者の目でプロジェクトを見てもらうこと」です。ブログでは「人がこれを買う理由のトップ3は何か」「精神を表すスローガンを1つ挙げるなら何か」と問いかけています。

書き方：日本語版のスライドの欄は「（プロダクトの名前）」「（素敵な写真）」「（最高のキャッチコピー）」「（ユーザーへのアピールその1〜3）」です。

記入例

書くときのコツ：アピールは機能名ではなく、利用者の得になることで書きます。「CSV出力機能」より「給与計算にそのまま渡せる」のほうが、利用者の目線になります。

4. やらないことリスト

目的：やること・やらないことを先に決めて、範囲をはっきりさせます。 ブログでは「イエスと言うのは簡単だ。難しいのはノーと言うことだ」と書き、「やる」の列から、大まかなユーザーストーリーが出てくるとしています。

書き方：日本語版のスライドは「やる」「やらない」「あとで決める」の3つの欄です。テンプレートの説明には、プロジェクトを始める前に「あとで決める」をすべて「やる」か「やらない」に移す（"move all the UNRESOLVED ones to either IN or OUT"）と書かれています。

記入例

書くときのコツ：「やらない」には、誰かが「やるだろう」と思っていそうなものを書きます。勤怠の例では「給与計算そのもの」がそれにあたります。勤怠のデータを持つと、給与計算もできそうに見えるからです。範囲の決め方は、関連記事「スコープ定義の書き方 スコープ記述書テンプレートと対象外の例」で扱っています。

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

目的：チームの外で、プロジェクトに関わる人を前もって洗い出します。 ブログでは「たいていのプロジェクトは、日々の担当者以外の人がいて初めて成功する」と説明しています。テンプレートの説明は「関わることになる人を全員挙げ、関係を作り始める」です。

書き方：日本語版のスライドは、中央に「コアチーム」を置き、周りに「（○○グループ）」「（他のチーム）」「（ほげほげ部門）」を並べる形です。スライドには「関係者全員を！」「…思っているよりもずっと大きい！」と書かれています。

記入例

関わる人の関心と影響の大きさを表で整理する方法は、関連記事「ステークホルダー管理表の書き方とテンプレート｜関心度×影響度マトリクスの例」で扱っています。

6. 解決案を描く

目的：どう作るつもりかを図で示し、リスクがある箇所を見せます。 ブログでは「チームを選ぶときに、アーキテクチャも選んでいる」と書き、全員が納得していることを確かめる場としています。あわせて「答えを全部持っていないなら、ここで正直に言う機会でもある」としています。

書き方：テンプレートの説明は「使うつもりのツールやライブラリの前提を書く。アーキテクチャの中でリスクがある部分も目立たせる」です。日本語版のスライドには「採用する技術」の欄と、「←リスクがある箇所」「←今回は対象外」の印があります。

記入例

flowchart LR
  subgraph S["技術的な解決策の概要"]
    U["社員（PC・スマホのブラウザ）"] --> W["勤怠Webアプリ<br>（Java / Spring Boot）"]
    C["ICカード打刻機"] -->|"打刻データ"| W
    W --> DB[("勤怠DB<br>PostgreSQL")]
    W -->|"月次CSV"| P["給与計算システム（既存）"]
    W -->|"ログイン"| ID["社内ID基盤（SSO）"]
  end
  R1["リスクがある箇所：<br>打刻機の連携仕様"] -.-> C
  O1["今回は対象外：<br>シフト作成"] -.-> W

• 採用する技術：Java 21、Spring Boot、PostgreSQL、社内ID基盤（SSO）
• リスクがある箇所：打刻機の連携仕様（まだ手元にない）

全体の構成図をもう一段詳しく描く方法は、関連記事「C4モデルの書き方｜コンテキスト図・コンテナ図のMermaid例」で扱っています。

7. 夜も眠れなくなるような問題は何だろう？

目的：心配するに値するリスクを、始める前に話しておきます。 ブログでは「心配する価値のあるリスクを見つける」演習とし、チームでどうにかできるものと、できないものを分けることを勧めています。例として、専任のメンバーを確保することは「どうにかできるもので、戦う価値がある」と書いています。

書き方：日本語版のスライドの欄は「もし起きたらこわーいこと、その1〜3」です。

記入例

書くときのコツ：ここで挙がったものは、リスクの一覧にそのまま移せます。関連記事「リスク管理表のテンプレートと書き方 リスク一覧60例と評価基準」で扱っています。

8. 期間を見極める

目的：プロジェクトの大きさを、ざっくり示します。 ブログでは「正確な日数は最初には言えない。でも、3か月か、6か月か、9か月かは言える」「大事なのは精度ではない」と書いています。テンプレートの説明は「（1、3、6か月の）どれかの大きさを伝える。このスライドを作る前に、大まかなストーリーの一覧を作って見積もる」「確約ではない」です。日本語版のスライドにも「あくまで推測であって、確約するものではありません。」と書かれています。

書き方：日本語版のスライドは、リリースまでの矢印の上に「構築」「受入テスト」「トレーニング」を並べ、「〜3ヶ月」「1週間」のように長さを書く形です。

記入例（Mermaid のガントチャートで描いたもの）

gantt
  title 勤怠管理システム刷新（推測であり確約ではない）
  dateFormat YYYY-MM-DD
  axisFormat %m/%d
  tickInterval 2week
  section 構築
  打刻・申請・承認（イテレーション1〜6） :a1, 2027-01-04, 12w
  給与計算連携・帳票（イテレーション7〜8） :a2, after a1, 4w
  section 受け入れ
  受入テスト（人事部・情報システム部） :a3, after a2, 2w
  section 展開
  説明会・トレーニング :a4, after a3, 1w
  リリース :milestone, after a4, 0d

合計は 12＋4＋2＋1＝19週、およそ4か月半です。 2週間のイテレーション（決まった長さの開発の区切り）を8回と置いています。ストーリーの大きさの見積もり方は、関連記事「ストーリーポイントの見積もり方｜基準表とプランニングポーカー手順」で扱っています。

9. 何を諦めるのかをはっきりさせる（トレードオフスライダー）

目的：うまくいかなくなったとき、何を譲るかを先に決めます。 ブログでは、時間・予算・スコープ・品質の4つを挙げ、「お金がすべてのプロジェクトもあれば、日付がすべてのプロジェクトもある」と書いています。アジャイルではふつうはスコープを調整するとしています。

トレードオフスライダーのルール（テンプレートの説明の原文から）

1. 2つのスライダーを同じ位置に置かない（"No two sliders can occupy the same level."）
2. ほかに大事な要素は、下に書き足す（"List other important project factors down below."）

日本語版のスライドの「典型的なフォース」は次の4つです。下の段には「上記以外で重要なこと」の例として「簡単に使える」「考えさせない！」「詳細な証跡（なんでもログを取る）」が並んでいます。

記入例

左（MAX）にあるほど譲れないもの、右（MIN）にあるほど譲れるものです。 4つすべてを左に寄せると、譲るものが決まっていないのと同じです。スポンサーに「期日と品質のどちらかを選ぶとしたら」と聞くと、位置が決まりやすくなります。優先順位の考え方は、関連記事「QCDとは？優先順位の決め方とトレードオフの例・管理指標一覧」で扱っています。

10. 何がどれだけ必要なのか

目的：必要な人数・役割・期間・費用を示し、スポンサーがやる価値を判断できるようにします。 テンプレートの説明は、関係者がふつう知りたいのは「いくらかかるか」「いつ終わるか」の2つで、それに答えるスライドだとしています。あわせて「どんな人が、どんなスキルを持って必要か」を示し、特定の人が欠かせないなら名前を書くよう勧めています。

書き方：日本語版のスライドは「俺たちの“Aチーム”」（人数・役割・強みや期待すること）と、「初回のリリースに必要なもの」（例：「3名、3.5ヶ月、$250K」）の2枚です。

記入例

初回のリリースに必要なもの：5.5名、4.5か月、費用は社内の単価で計算した金額

テンプレートの最後のスライドの説明には、デッキを作る中で聞いた「無茶な話」を持ち出し、スポンサーと率直に話す機会だと書かれています。「この人がいないと進まない」「この条件がそろわないと期日は守れない」は、ここで言います。工数の出し方は、関連記事「工数見積もりの方法｜積み上げ・三点見積もりの計算例と精度を上げるコツ」で扱っています。

進め方：時間・参加者・順番

原典は「正しい人を部屋に集める」ことを求めていますが、時間割は決めていません。 以下は、ブログの「数日から1〜2週間」の範囲で組んだ例です。

• スポンサーは、1・9・10 には必ずいてもらうほうが進めやすくなります。「なぜやるのか」と「何を譲るのか」は、お金を出す人が決めることだからです。テンプレートの1枚目にも、スポンサーの名前を大きく書く欄があります。
• 8（期間）の前に、大まかなストーリーの一覧を作ります。 テンプレートの説明がそう求めています。書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」で扱っています。
• 司会は、プロジェクトを動かす人が務めます。 著者はブログのコメント欄で「プロジェクトを動かしている人なら誰でも」と答えています。進行のしかたは、関連記事「会議ファシリテーションの進め方 アジェンダ設計とフレーズ集」で扱っています。

Markdown のテンプレート（コピーして使える形）

スライドの代わりに Markdown で書くと、リポジトリやWikiで差分を残せます。見出しは日本語版の節名に合わせています。

# インセプションデッキ：<プロジェクトの名前>

- スポンサー：<スポンサーの名前>
- 版：0.1（YYYY-MM-DD）

## 1. 我われはなぜここにいるのか
- **<このプロジェクトの根幹に関わる理由を1つ>**
- 大事な理由その1
- 大事な理由その2

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

## 3. パッケージデザイン
- 名前：
- キャッチコピー：
- アピールその1：
- アピールその2：
- アピールその3：

## 4. やらないことリスト
| 区分 | 項目 |
|---|---|
| やる |  |
| やらない |  |
| あとで決める |  |

## 5. ご近所さんを探せ
| 関わる人・部署 | 関わる場面 | 早めに話すこと |
|---|---|---|
| コアチーム |  |  |

## 6. 解決案を描く
- 採用する技術：<言語> / <ライブラリ> / <ツール>
- リスクがある箇所：
- 今回は対象外：

## 7. 夜も眠れなくなる問題
| こわいこと | チームで手を打てるか | 打つ手 |
|---|---|---|
|  |  |  |

## 8. 期間を見極める
- およそ <N> か月（推測であり確約ではない）

## 9. 何を諦めるのか（トレードオフスライダー）
| フォース | 位置（1=最優先、4=いちばん譲れる） |
|---|---|
| 期日を死守する（時間） | 1 |
| 高い品質、少ない欠陥（品質） | 2 |
| 予算内に収める（予算） | 3 |
| 機能をぜんぶ揃える（スコープ） | 4 |

## 10. 何がどれだけ必要か
| 人数 | 役割 | 強みや期待すること |
|---|---|---|
|  |  |  |

抜けを調べるスクリプト

テンプレートのルールのうち、機械で調べられる3つ（10の見出しがそろっているか、「あとで決める」が残っていないか、スライダーが同じ位置に重なっていないか）を調べる Python のスクリプトです。

import re, sys

text = open(sys.argv[1], encoding="utf-8").read()
errors = []

# 10の質問の見出しがそろっているか
heads = re.findall(r"^## (\d+)\. ", text, re.M)
if heads != [str(i) for i in range(1, 11)]:
    errors.append(f"見出しが10個そろっていない: {heads}")

# やらないことリストに「あとで決める」が残っていないか
notlist = text.split("## 4.")[1].split("## 5.")[0]
pending = re.findall(r"^| あとで決める | (.+?) |", notlist, re.M)
if pending:
    errors.append(f"「あとで決める」が残っている: {pending}")

# トレードオフスライダー：同じ位置に2つ置かない
slider = text.split("## 9.")[1].split("## 10.")[0]
levels = [int(n) for n in re.findall(r"| (\d) |$", slider, re.M)]
if len(levels) != len(set(levels)):
    errors.append(f"スライダーの位置が重なっている: {levels}")

print("\n".join(errors) if errors else "OK")

勤怠管理システムの記入例（「あとで決める」に「子会社への展開」が1件残った版）で動かした結果です。

$ python3 check_deck.py deck.md
「あとで決める」が残っている: ['子会社への展開']

予算のスライダーを、時間と同じ「1」にした版では、次のように2件とも出ました。

$ python3 check_deck.py deck_ng.md
「あとで決める」が残っている: ['子会社への展開']
スライダーの位置が重なっている: [1, 2, 1, 4]

「子会社への展開」を「やらない（次の年度に検討）」に移すと、OK になりました。

よくある誤り

よくある質問

Q. 10個すべてに答えないといけませんか。 A. 原典は10の質問をそろいで紹介しています。小さな改修では、1（なぜ）・4（やらないこと）・9（何を諦めるか）だけでも、範囲と優先順位の行き違いを減らせます。どれを省いたかは、デッキに書いておくと後で見返せます。

Q. ウォーターフォールの開発でも使えますか。 A. 使えます。10の質問の多くは開発手法に関係なく、要件定義の前に関係者の認識をそろえるのに役立ちます。開発手法の違いは、関連記事「ウォーターフォールとアジャイルの違い比較表｜開発手法の選び方診断」で扱っています。

Q. いつ作り直しますか。 A. テンプレートの最後のスライドには「状況が変わったら更新する」と書かれています。スポンサーが変わったとき、範囲が大きく変わったとき、リリースの区切りのときが見直しの目安になります。

Q. MVP の範囲とはどう関係しますか。 A. 4 の「やる」と 10 の「初回のリリースに必要なもの」が、最初に届ける範囲の候補になります。MVP の考え方は、関連記事「MVPとは｜PoC・プロトタイプとの違いと作り方」で扱っています。

まとめ

• インセプションデッキは 10の質問への答え。目的は「全員の向きをそろえ、期待をすり合わせること」
• 前半（なぜ・なに）は なぜ・エレベーターピッチ・パッケージ・やらないこと・ご近所さん、後半（どうやって）は 解決案・眠れない問題・期間・何を諦めるか・何が必要か
• やらないことリストは、始める前に「あとで決める」を残さない
• トレードオフスライダーは、2つを同じ位置に置かない
• 期間は 推測であって確約ではない。作ったら見えるところに貼り、変わったら更新する

参考・出典

確認日はいずれも 2026年10月13日です。

• Jonathan Rasmusson「The Agile Inception Deck」（The Agile Warrior）：https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
• オーム社『アジャイルサムライ――達人開発者への道』書籍ページ（目次）：https://www.ohmsha.co.jp/book/9784274068560/
• agile-samurai-ja/support（『アジャイルサムライ』日本語版サポート、インセプションデッキのテンプレート 日本語版 0.4）：https://github.com/agile-samurai-ja/support

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。