第 1 章　インセプションデッキとは？

プロジェクトを始めたとき、こんな経験はありませんか？

• 「このプロジェクト、結局何を作るんだっけ？」
• 「誰のためにやるんだろう？」
• 「なぜ今やる必要があるの？」

プロジェクトの立ち上げ時には、こうした“モヤモヤ”がつきものです。 メンバー全員が同じ理解を持っているように見えても、実際にはそれぞれの頭の中に違うイメージが広がっていることが少なくありません。

そんなときに役立つのが、**インセプションデッキ（Inception Deck）**です。

プロジェクトの“航海図”

インセプションデッキを一言で表すなら、「プロジェクトの航海図」です。

「なぜやるのか」「何をやるのか」「どう進めるのか」という 3 つの問いに答え、チーム全員で共有するためのフレームワーク。 出発前に目的地やルートを確認するように、プロジェクトでも最初に共通認識を作ることが大切です。

インセプションデッキは、アジャイル開発を推進してきた Atlassian や ThoughtWorks などで広まり、多くの現場で使われてきました。 今では「プロジェクトを立ち上げるときに、まずやるべきワーク」として、さまざまな組織に取り入れられています。

役割は「認識合わせ」と「目的共有」

インセプションデッキの役割は大きく分けて 2 つあります。

1. 認識合わせ
   • ゴールや進め方の認識がズレると、あとで大きな修正や手戻りが発生します。
   • 最初に認識を揃えることで、余計な摩擦を防ぐことができます。
2. 目的共有
   • プロジェクトの“存在意義”を理解しているかどうかで、メンバーのモチベーションは大きく変わります。
   • 「自分たちは何のためにこの仕事をしているのか」を全員が理解することが、強いチームを作る第一歩です。

10 個の質問

インセプションデッキは、10 個の質問で構成されています。 これに答えていくことで、自然とプロジェクトの全体像が浮かび上がってきます。

1. 我々はなぜここにいるのか？
2. エレベーターピッチ
3. プロジェクトのボックスの外と中
4. やらないことリスト
5. ご近所さんを探せ
6. 解決案を描く
7. 夜も眠れない問題
8. 期間を見積もる
9. トレードオフスライダー
10. 何がどれだけ必要か？

これらの問いは「正解を出すこと」が目的ではありません。 大切なのは、チームで会話をしながら共通認識を作っていくことです。

第 2 章　なぜインセプションデッキが必要なのか？

プロジェクトがうまく進まない原因の多くは、実は「技術的な難しさ」ではなく、認識のズレにあります。

プロジェクトでよくある“すれ違い”

こんな経験はないでしょうか？

• 「この機能ってやるんだっけ？」
• 「私は必要ないと思ってたけど…？」
• 「いや、最初に言ってなかった？」

こうしたやりとりは、誰もが悪気なく起こしてしまうものです。 けれど、こうした小さなズレが積み重なると、後戻りや無駄な作業が増え、チームの信頼関係まで揺らいでしまうことがあります。

特に、チームの中だけでなく、顧客やステークホルダーとの間でもズレがあると、プロジェクト全体に大きな影響を与えかねません。

インセプションデッキが解決すること

インセプションデッキは、こうしたズレを防ぐための仕組みです。

• 目的を共有する：「なぜこのプロジェクトをやるのか？」を明確にする
• ゴールをそろえる：「何を目指すのか？」をチーム全員で描く
• 言葉をそろえる：顧客・開発者の間で共通言語を持つ

この 3 つを整えるだけで、プロジェクトは格段に進めやすくなります。

モチベーションを高める

さらに、インセプションデッキはチームのモチベーションを上げる効果もあります。

人は、「自分の仕事が誰の役に立っているのか」「どんな意味があるのか」を理解したときにこそ、本気で取り組めるものです。

逆に「ただ言われたからやっている」という状態では、どうしても受け身になりがちです。

インセプションデッキを通して、メンバー一人ひとりが「自分たちのプロジェクトだ」と思えるようになることが大きな価値なのです。

よくある問題を解決する

インセプションデッキを使うことで、次のような課題を事前に防ぐことができます。

• 「そもそも何を作るんだっけ？」という迷子状態
• 「誰のためにやってるの？」という目的喪失感
• 「ここはやる？やらない？」という範囲の曖昧さ
• 「なんでこのスケジュール？」という見通し不足

こうした不安や疑問を“最初にテーブルに乗せる”ことが、プロジェクトをスムーズに進める第一歩になります。

このように、インセプションデッキは単なる「準備作業」ではなく、プロジェクトの成功率を高めるための土台づくりです。

第 3 章　インセプションデッキの 10 個の質問

インセプションデッキの中心となるのが、10 個の質問です。

これらの質問に答えていくことで、自然とプロジェクトの目的・範囲・リスク・リソースといった全体像が浮かび上がります。 一つひとつの質問はシンプルですが、チームで会話を通じて考えることに意味があります。

10 個の質問一覧

1. 我々はなぜここにいるのか？
2. エレベーターピッチ
3. プロジェクトのボックスの外と中
4. やらないことリスト
5. ご近所さんを探せ
6. 解決案を描く
7. 夜も眠れない問題
8. 期間を見積もる
9. トレードオフスライダー
10. 何がどれだけ必要か？

正解を出すことが目的ではない

大切なのは、全てに完璧な答えを出すことではありません。 むしろ、質問をきっかけに会話を広げることが最大の目的です。

• 「ここはまだ不確かだね」
• 「それは別の案もあるかもしれない」
• 「この部分は後で調査が必要だね」

こうした気づきを持ち寄ることで、チーム全体の理解が深まります。

使い方は柔軟に

10 個すべてを一度にやるのは大変かもしれません。 その場合は、プロジェクトの状況に応じて必要な質問だけを選んで使うのも有効です。

たとえば：

• 新規立ち上げなら「① なぜここにいるのか」「② エレベーターピッチ」から始める
• 不安が多いプロジェクトなら「⑦ 夜も眠れない問題」に時間をかける
• リリース前の調整なら「⑨ トレードオフスライダー」で合意形成を図る

会話こそが価値

インセプションデッキを進めるときに大事なのは、一人が説明して終わりにしないことです。 チーム全員が参加し、それぞれの考えを出し合ってこそ価値が生まれます。

「このプロジェクトは自分ごとだ」と思えるかどうか。 その実感を持って進められるかどうかが、成功のカギになります。

第 4 章　質問 ①「我々はなぜここにいるのか？」

インセプションデッキの最初の問いは、とてもシンプルでありながら核心を突いています。 「我々はなぜここにいるのか？」 つまり、このプロジェクトをなぜやるのか、その背景と目的を明らかにする問いです。

背景と目的を整理する

プロジェクトは、何かしらの課題や期待から生まれます。 しかし、その「なぜ？」を明確に言葉にできることは意外と少ないのです。

ここでは次の 2 つの視点を切り分けて考えるのがポイントです。

• 背景：どんな課題や事情があって、このプロジェクトが必要になったのか
• 目的：このプロジェクトが成功したとき、どんな価値を生み出すのか

例：背景と目的の整理

• 背景：営業現場で紙の申込書を使っており、手間とミスが多い
• 目的：営業担当がスムーズに契約を進められるよう、ペーパーレス化を実現する

背景だけだと「愚痴」で終わってしまい、目的だけだと「理想論」で終わってしまいます。 両方をセットで言葉にすることで、チーム全体にとっての納得感が生まれるのです。

形式よりも納得感

ここで大切なのは、「カッコいい説明」を作ることではありません。 チーム全員が腹落ちできる言葉になっているかどうかです。

• ❌「上から言われたからやる」
• ⭕「営業現場の負担を減らし、契約スピードを上げるためにやる」

この違いは、プロジェクトの進めやすさに大きく影響します。

チーム全員で語れる状態を目指す

また、この問いに答えるのは誰か一人ではなく、チーム全員で考えることが大切です。 一人ひとりが「なぜこのプロジェクトをやっているのか」を自分の言葉で語れるようになれば、 プロジェクトはぐっと強いものになります。

この問いを通して作るのは、単なる“目的の表明”ではありません。 「このプロジェクトには存在意義がある」という共通の土台なのです。

第 5 章　質問 ②「エレベーターピッチ」

プロジェクトの目的が整理できたら、次はそれを短く、わかりやすく説明できるかを確認します。 このときに役立つのが「エレベーターピッチ」です。

エレベーターピッチとは？

「エレベーターピッチ」とは、エレベーターに乗っている短い時間で、自分のアイデアを相手に伝えることをイメージした表現です。

つまり、「このプロジェクトってどんなもの？」と聞かれたときに、30 秒以内で本質を伝えられる説明を用意しておく、ということです。

テンプレートを使う

エレベーターピッチにはよく使われるテンプレートがあります。

[対象ユーザー] 向けの

[ニーズや課題] を解決する

[プロダクト名] は、

[主要な機能] を提供する

[カテゴリ名] です。

これは、[競合や代替手段] と違って、

[差別化ポイント] を提供します。

一見長く見えますが、実際に当てはめるとシンプルに整理できます。

例：営業支援アプリの場合

• 対象ユーザー：営業担当者
• ニーズや課題：訪問前の準備や記録に時間がかかる
• プロダクト名：「SalesTab」
• 主要な機能：顧客情報の閲覧・記録を一元化
• カテゴリ名：営業支援アプリ
• 競合や代替手段：紙の台帳やバラバラのデータ管理
• 差別化ポイント：外出先でもスマホでサッと利用可能

完成形はこうなります 👇

営業担当者向けの 訪問前の準備の手間を減らす 「SalesTab」は、 顧客情報の閲覧や記録を一元化できる 営業支援アプリです。 これは、紙の台帳や分散されたデータと違って、 外出先でもスマホで手軽に使えるのが強みです。

一言で伝えられる強さ

このように、エレベーターピッチを作っておくと、

• 顧客や上司への説明
• 新メンバーへの紹介
• チーム内での確認

あらゆる場面で役立ちます。

また、一言で説明できるかどうかは、チーム自身が本質を理解できているかの試金石でもあります。

第 6 章　質問 ③「プロジェクトのボックスの外と中」

プロジェクトを進めていくうちに、いつの間にか「やること」がどんどん増えていく…。 そんな経験はありませんか？

最初はシンプルだった計画も、関係者の要望や新しいアイデアが加わって、気づけば収拾がつかなくなってしまう。 これをスコープクリープ-scope creepと呼びます。

「ボックスの内」と「ボックスの外」

インセプションデッキの 3 つ目の質問は、この問題を防ぐためのものです。 それが 「プロジェクトのボックスの外と中」。

イメージはシンプルです。

• ボックスの中：このプロジェクトでやること
• ボックスの外：このプロジェクトではやらないこと

つまり、「守備範囲」を最初に決めておく、ということです。

「やること」と「やらないこと」の線引き

多くの現場では、「やること」は明確に書かれますが、「やらないこと」はあまり言葉にされません。 その結果、後から「これも入ってるよね？」と解釈が広がり、チームが混乱してしまいます。

だからこそ、「やらないこと」を明示することが大事なのです。

例：営業支援アプリの場合

• ボックスの中
  • 既存の顧客管理アプリをスマホ対応にする
  • 営業日報をモバイルで入力できるようにする
• ボックスの外
  • UI デザインの全面刷新（今回は対象外）
  • 分析ダッシュボードの再設計（別プロジェクトで対応）

チームを守る「盾」になる

この線引きをやっておくと、チームにとって大きな武器になります。

• 関係者からの追加要望に対して →「今回はボックスの外です」と説明できる
• メンバーの不安に対して →「これはやらなくていいと最初に決めてある」と安心できる

こうした“盾”があるだけで、プロジェクトはずっと健全に進められるのです。

次につながる「やらないことリスト」

この「ボックスの外と中」でざっくり線引きをした上で、 さらに詳しく「やらないこと」を整理するのが次の質問 ④ です。

「やらない」と宣言する勇気を持つことで、チームは本当に大切なことに集中できるようになります。

第 7 章　質問 ④「やらないことリスト」

プロジェクトで失敗しがちな原因のひとつが、「やることが際限なく増えていく」ことです。 要望やアイデアが次々に出てくると、最初に決めたゴールがどんどんぼやけてしまいます。

そこで役立つのが、インセプションデッキの 4 つ目の質問。 「やらないことリスト」です。

あえて「やらない」と決める

「やること」をリストアップするのは誰でもやります。 でも、「やらないこと」を最初から明示しているプロジェクトは意外と少ないのです。

この「やらないことリスト」は、スコープを守り、優先順位を明確にするための仕組みです。

例：営業支援アプリの場合

• ✅ やること
  • 営業日報のスマホ対応
  • 顧客情報の閲覧・登録機能
• ❌ やらないこと
  • デザインの全面刷新（今回は対象外）
  • 多言語対応（次フェーズで検討）
  • 高度な分析ダッシュボード（別プロジェクトで対応）

「やらない」と言える勇気

プロジェクトが炎上する原因のひとつは、断りきれずに何でも取り込んでしまうことです。

「ついでにこれもやってよ」 「あとこれも入れておいて」

こうした要望をそのまま受け入れてしまうと、最初に決めたゴールからどんどん遠ざかっていきます。

「やらない」と明確に言えるだけで、プロジェクトは健全性を保てるのです。

関係者との信頼関係にも効く

「やらないこと」を合意しておくと、後から「なぜこれは入っていないの？」と聞かれたときに説明がしやすくなります。 あらかじめ線引きを共有していることで、関係者とのコミュニケーションもスムーズになります。

削ぎ落とすことで見えるもの

プロジェクトには「やりたいこと」が山のようにあります。 でも、時間も人も予算も有限です。

だからこそ、「今回はここまで」と潔く決めることで、本当にやるべきことが浮かび上がるのです。

第 8 章　質問 ⑤「ご近所さんを探せ」

プロジェクトは、チームの中だけで完結するものではありません。 実際には、周囲のさまざまな人や部門と関わりながら進んでいきます。

インセプションデッキの 5 つ目の質問は、「ご近所さんを探せ」です。 つまり、「このプロジェクトに関わってくる人は誰か？」を洗い出しておく作業です。

ご近所さん＝ステークホルダー

ここでいう「ご近所さん」とは、プロジェクトに影響を与える、あるいは影響を受ける人たちのことです。

• システム連携が必要な別チーム
• 営業やサポート部門
• セキュリティやインフラ担当
• もちろん顧客やユーザー自身

こうした人たちを最初から把握しておかないと、思わぬところでトラブルが起こります。

「知らなかった」は一番のリスク

プロジェクトを進めていてよくあるのが、後からこう言われるケースです。

• 「この機能、ウチの業務に影響あるんだけど聞いてないよ？」
• 「このシステムとつながるなら、最初に相談してくれないと困る」

こうした「後出しのご近所問題」は、時間もコストも余計にかかる大きなリスクになります。

例：営業支援アプリの場合

営業支援アプリを導入する場合、関わりそうなご近所さんはこんな人たちです。

• 営業部門：実際に使う当事者。業務フローに大きな影響
• サポートセンター：リリース後に問い合わせ対応を担う
• 情報システム部門：システム連携やアカウント管理を調整
• セキュリティチーム：顧客データ取り扱いのレビューが必要

早めに声をかけることが大事

ご近所さんを洗い出したら、できるだけ早い段階で声をかけることが大切です。

「まだ何も決まっていないけど、関わりそうだから一度話を聞いてもらえますか？」 これくらいの軽い相談で十分です。

大事なのは、「ちゃんとあなたのことを考えてますよ」と伝えること。 その一言で、後々の協力が得やすくなります。

周囲を巻き込む力が、プロジェクトを強くする

ご近所さんを探すことは、単なるリストアップ作業ではありません。 チームの外に味方を増やす活動でもあります。

プロジェクトは孤立すると弱いですが、周囲とつながることで柔軟に動けるようになります。

第 9 章　質問 ⑥「解決案を描く」

ここまでで「なぜやるのか」「誰と関わるのか」など、プロジェクトの土台を整理してきました。 次はいよいよ、「ではどうやって解決するのか？」という問いに向き合います。

インセプションデッキの 6 つ目の質問は、「解決案を描く」です。

解決案を“見える形”にする

ここで大事なのは、完璧な設計図をつくることではありません。 目的は、頭の中にあるイメージを「見える形」にして、チーム全員で共有することです。

• ユーザーがどう動くかを示す ユーザーフロー
• 画面イメージを簡単に表す ワイヤーフレーム
• システムの仕組みをざっくり示す 構成図

こうしたラフなスケッチや図を用意するだけで、言葉だけでは伝わりにくい部分が一気に共有しやすくなります。

なぜ「描く」のか？

口頭だけの説明は、聞く人によってイメージが変わってしまいます。 たとえば「シンプルな画面にする」と言っても、人によって想像するデザインは違いますよね。

図や絵にしてみることで、共通のイメージを持てるようになる。 これが「描く」ことの最大の効果です。

例：営業支援アプリの場合

• ユーザーはアプリで顧客を検索し、訪問メモを確認する
• 訪問後に日報を入力し、上司がすぐに確認できる
• データは既存システムの DB に保存され、他部門とも共有可能

この流れを、ホワイトボードや付箋、Miro ボードなどで絵にしてみると、 「そうそう、こういう動きだよね」とチーム全員が同じ絵を見て話せるようになります。

正解を出す必要はない

この段階では、アイデアは荒削りで構いません。 むしろ「これって実現できるかな？」「このやり方はちょっと難しいかも」と議論が広がること自体が大事です。

アイデアを形にする → みんなで検討する → 修正する この繰り返しが、プロジェクトの現実味を高めていきます。

次へのつながり

「解決案を描く」ことで、次の質問につながります。 不安な点が見えてきたら、それは「夜も眠れない問題」へ。 実現にかかる時間が気になったら、「期間を見積もる」へ。

つまり、この解決案はプロジェクトを具体化する“ハブ”のような役割を持っているのです。

第 10 章　質問 ⑦「夜も眠れない問題」

プロジェクトを始める前や進めている最中に、 「ここがちょっと不安なんだよな…」と感じることはありませんか？

それをあえて言葉にして、チーム全体で共有するのが、インセプションデッキの 7 つ目の質問。 「夜も眠れない問題」です。

不安を見える化する

リスクや懸念は、放っておくと大きな問題になります。 けれど、多くの現場では「今は言わないでおこう」と我慢されがちです。

• スケジュール、本当に間に合うかな？
• 外部システムとの連携、想定以上に大変じゃない？
• メンバーの人数、足りるのかな？

こうした声を飲み込んでしまうと、後から大きなトラブルとして噴き出します。

出すこと自体に価値がある

「夜も眠れない問題」の目的は、解決策をすぐに出すことではありません。 大切なのは、“不安が存在する”という事実を可視化することです。

• 「その懸念はチーム全員が認識できている」
• 「一人で抱え込まなくてもいい」

この状態にするだけでも、チームに安心感が生まれます。

実際の進め方

方法はシンプルです。 チームメンバー全員が、不安やリスクを思いつくままに付箋やツールに書き出します。

• 小さなことでも構わない
• 「心配しすぎでは？」と否定しない
• 出してくれたことに「ありがとう」と返す

このルールを守るだけで、意外なほど多くのリスクが見えてきます。

例：営業支援アプリの場合

• 顧客データの移行に失敗すると大問題になる
• API 連携先の担当が頻繁に変わるので調整が難しい
• 外出先での利用時、通信環境が不安定だと使いにくいかもしれない

リスクを「注意ポイント」に変える

リスクはゼロにはできません。 ですが、事前に知っているかどうかで、対応の仕方は大きく変わります。

「爆弾」になる前に見つけておけば、 ただの「注意ポイント」として扱えるようになるのです。

チームに安心感をもたらす問い

夜も眠れない問題を扱うことで、 「自分の不安を言っていいんだ」と思える雰囲気が生まれます。 これは、チームの健全性を保つうえでとても大切な文化です。

第 11 章　質問 ⑧「期間を見積もる」

ここまでで、プロジェクトの目的・範囲・リスクを整理してきました。 次に大切なのは、「どれくらいの時間がかかりそうか」をチームで見積もることです。

インセプションデッキの 8 つ目の質問は、「期間を見積もる」。 プロジェクトの大まかなスケジュール感を共有するステップです。

ざっくりでいい

「見積もり」と聞くと、正確な数字を出さないといけない気がして、構えてしまう人も多いかもしれません。 でも、ここで必要なのはざっくりとした感覚の共有です。

• 「最初のプロトタイプは 2 ヶ月くらいで出せそう」
• 「ユーザーテストは夏前にできるといいね」
• 「リリースは年末を目指そう」

このくらいの粒度で十分です。

認識のズレを防ぐ

見積もりを共有する一番の目的は、認識のズレを防ぐことです。

• 開発者は「3 週間でできる」と思っている
• ビジネス側は「来週にはできるはず」と思っている

こうしたすれ違いは、プロジェクトの摩擦を生む典型的な原因です。 だからこそ、最初に時間の感覚を合わせることが大切なのです。

例：営業支援アプリの場合（ざっくり計画）

• 4〜5 月：要件整理と設計
• 6 月：開発開始、最初のプロトタイプ
• 7 月中旬：ユーザーテスト
• 8 月：最終調整
• 9 月：リリース

不確実性もセットで伝える

もちろん、この段階で出した見積もりはあくまで仮です。 外部要因やメンバーの稼働状況によって変わることもあります。

だからこそ、「この部分はまだ不確か」と一緒に伝えておくことが重要です。

• 「この連携部分は調査次第で後ろ倒しになる可能性がある」
• 「人のアサイン次第でスケジュールが変わる」

こうした補足があるだけで、後からの調整がぐっとやりやすくなります。

ゴールに向けた道しるべ

見積もりは「当てるため」ではなく、「準備するため」にあります。 見通しがあるだけで、チームは安心して進められるのです。

第 12 章　質問 ⑨「トレードオフスライダー」

プロジェクトにはいつも「全部は無理」という現実があります。 スピード、品質、コスト、機能の多さ…。 どれも大事ですが、すべてを最高にすることはできません。

インセプションデッキの 9 つ目の質問は、「トレードオフスライダー」。 これは、プロジェクトの優先順位をチーム全体で整理するための問いです。

トレードオフとは？

「トレードオフ」とは、何かを優先すれば、他の何かが犠牲になるという関係性のことです。

• 「早くリリースする」→ 品質はある程度妥協する必要がある
• 「品質を最優先にする」→ 時間やコストが増える可能性がある
• 「コストを抑える」→ 機能やスピードを諦めなければならない

プロジェクトでは、このバランスを常に意識する必要があります。

スライダーで可視化する

このときに役立つのが「スライダー」の考え方です。 いくつかの要素を並べ、それぞれをどれくらい重視するのかをスライダーで調整してみます。

たとえば 👇

• スピード（速さ）
• 品質（安定性・バグの少なさ）
• コスト（予算内に収めること）
• 機能の豊富さ
• デザイン性
• 柔軟性（将来の拡張性）
• 顧客満足度
• 技術チャレンジ

これをチーム全員で話し合いながら「ここは優先度高め」「ここは今回は控えめ」と決めていきます。

価値観のズレを見える化する

この作業をやると、チーム内での価値観のズレが可視化されることがあります。

• PM は「スピード最優先」と考えている
• エンジニアは「品質を犠牲にすると後で痛い目に合う」と思っている
• デザイナーは「見た目を軽視するとユーザーが離れる」と危惧している

こうした異なる視点を、最初からテーブルに出しておくことが大事です。

判断基準として活きる

優先順位を整理しておくと、後から意思決定をするときに迷いにくくなります。

「機能追加と品質のどちらを優先する？」と悩んだときも、 「今回は品質優先と決めていたよね」と立ち返れる指針になります。

チームの合意をつくるプロセス

トレードオフスライダーは、単なるチェックリストではありません。 チーム全員で優先順位を合意するプロセスそのものに価値があります。

「何を大切にするのか」を一度しっかり話し合っておく。 これが、プロジェクトを安定して進める大きな力になるのです。

第 13 章　質問 ⑩「何がどれだけ必要か？」

最後の問いは、プロジェクトを実現するために具体的に何が必要なのかを整理することです。 これがインセプションデッキの 10 個目の質問、「何がどれだけ必要か？」です。

リソースを見える化する

プロジェクトを進めるには、人・時間・お金・ツール・環境など、さまざまなリソースが必要です。 けれど、これらを明確にしないまま走り出すと、途中で「全然足りない！」という事態になりがちです。

だからこそ、最初に必要なものをざっくり洗い出すことが大切です。

観点ごとの整理例

👥 人（役割・スキル）

• フロントエンドエンジニアが 1 名必要
• インフラ担当は週 1 で関与
• UI/UX デザイナーは途中レビューのみ依頼

⏰ 時間（稼働量）

• チーム全体で月間 ◯◯ 時間程度を想定
• 特定の月は他案件の兼務で半分以下になる

💰 お金（予算）

• 外部ベンダーに依頼する部分の費用
• 開発環境やクラウド利用料

🧰 ツール・環境

• Git、CI/CD 環境、ドキュメント共有ツール
• テスト用のデータや環境

ギャップに気づく

この問いで重要なのは、不足しているものに気づくことです。

• 人が足りないなら、追加のアサインを検討する
• 予算が不足するなら、スコープや優先順位を見直す
• ツールがないなら、調達の手続きを早めに始める

必要なものが揃っているかどうかを確認するだけでなく、足りないものをどう補うかを考えることが大事です。

計画の「現実味」を高める

「何がどれだけ必要か？」を考えることで、プロジェクト計画がぐっと現実的になります。 理想論で終わらず、実際に動ける計画へと近づけるためのステップなのです。

10 個の質問のゴール

これで、インセプションデッキの 10 個の質問をすべて確認しました。

• 目的を定め
• 範囲を決め
• 関係者を洗い出し
• 解決策を描き
• 不安を表に出し
• 時間や優先度を調整し
• リソースを明らかにする

この一連の流れを通じて、プロジェクトの全体像をチーム全員で描くことができるのです。

第 14 章　インセプションデッキの活かし方

ここまで、インセプションデッキの 10 個の質問をひとつずつ見てきました。 では、実際に現場でどう活かしていけばよいのでしょうか？

この章では、インセプションデッキを現場で使うときの工夫やコツを紹介します。

アジャイル開発での活用

インセプションデッキは、アジャイル開発との相性が抜群です。 なぜなら、チーム全員で共通認識を持つことがアジャイルにおいて何よりも大事だからです。

• スプリントを始める前に「ゴールや優先度」を再確認する
• プロダクトバックログを作るときの土台として使う
• レトロスペクティブ（ふりかえり）で見直し、更新する

こうした使い方をすれば、インセプションデッキは単なる“準備資料”にとどまらず、チームを支えるガイドになります。

ウォーターフォールやハイブリッドでも使える

「インセプションデッキはアジャイル専用では？」と思われるかもしれません。 実は、ウォーターフォールやハイブリッド型のプロジェクトでも十分に活用できます。

特に有効なのは次のような場面です 👇

• 上流工程での要件定義の前に「方向性を確認」する
• 部署横断のプロジェクトで「関係者を洗い出す」
• 長期プロジェクトの途中で「ゴールを再確認する」

開発手法に関係なく、チーム全体で“共通の地図”を持つことが価値なのです。

部分的に取り入れる

「10 個全部やるのは大変そう」と思うかもしれません。 そんなときは、必要な部分だけを取り入れるのがおすすめです。

• プロジェクト開始時なら「① なぜここにいるのか？」と「② エレベーターピッチ」
• リスクが気になるときは「⑦ 夜も眠れない問題」
• 優先順位で揉めそうなら「⑨ トレードオフスライダー」

状況に合わせて“ミニ・インセプションデッキ”として使うのも有効です。

継続的にアップデートする

インセプションデッキは、一度作って終わりではありません。 プロジェクトが進むにつれて状況は変化します。

• 新しいメンバーが加わったとき
• ゴールが見直されたとき
• スケジュールや優先度が変わったとき

こうしたタイミングで、インセプションデッキを再確認・更新することで、常に“今の共通認識”を保てます。

「会話のきっかけ」として使う

最後に大切なのは、インセプションデッキを「会話を引き出すためのツール」として捉えることです。 きれいなドキュメントを作ること自体が目的ではありません。

大事なのは、メンバー同士が話し合い、互いの考えを理解する時間です。 その結果として信頼関係が強まり、チームが同じ方向を向いて進めるようになります。

第 15 章　 Q&A よくある質問集

インセプションデッキについて勉強会をすると、毎回さまざまな質問が出てきます。 この章では、よくある質問とその答えをまとめました。

Q1. インセプションデッキは必ず全部やらないといけませんか？

A: 必要ありません。 10 個すべてやれたら理想ですが、時間や状況に応じて必要な部分だけ取り入れるのでも十分効果があります。 たとえば「今回はリスク洗い出しだけ」でも立派な活用です。

Q2. ウォーターフォール型のプロジェクトでも使えますか？

A: はい、使えます。 インセプションデッキは開発手法に依存しません。 「チームで共通認識を持つ」ことが目的なので、ウォーターフォールやハイブリッド型でも有効です。

Q3. どのタイミングでやるのがベストですか？

A: 立ち上げ時が理想ですが、途中からでも遅くはありません。 「最近チームの方向性がぶれてきたな」と感じたときに再度やってみるのも効果的です。

Q4. どれくらい時間がかかりますか？

A: すべてやると半日〜1 日かかることもあります。 ただし、絞れば 1 時間程度でも十分。 分割して何回かに分けて実施する方法もおすすめです。

Q5. ファシリテーターは必要ですか？

A: いるとスムーズです。 ただし、特別なスキルを持った進行役である必要はありません。 「話が一方的にならないように場を回す人」がいれば十分です。

Q6. 答えが出ない質問があったらどうすればいいですか？

A: それも OK です。 「まだ不確か」という認識を共有できただけでも価値があります。 後で確認するためのタスクとして残しておきましょう。

Q7. 誰のためのツールなんですか？PM 向けですか？

A: PM 専用ではありません。 インセプションデッキはチーム全員のためのツールです。 エンジニア、デザイナー、ビジネス担当、顧客を含めて、全員が「自分ごと」としてプロジェクトに関わるための仕組みです。

Q8. テンプレートはありますか？

A: はい、あります。 Miro や Notion、スライド形式など、さまざまなテンプレートが公開されています。 まずは既存のテンプレートをベースに、自分たちのチームに合う形にカスタマイズして使うのがおすすめです。

Q9. フォーマットに縛られて自由な発想が出なくなりませんか？

A: 形式にこだわりすぎないことが大切です。 インセプションデッキは「会話を引き出すきっかけ」であり、完璧に埋めることが目的ではありません。 むしろ脱線や補足があっても構いません。

Q10. 一度やったら終わりですか？

A: いいえ、定期的に見直すのがおすすめです。 新メンバーが入ったときや、ゴールが変わったときなどに再確認すれば、常に「今の共通認識」を維持できます。

第 16 章　まとめ

ここまで、インセプションデッキの基本と 10 個の質問、そして活用の仕方や Q&A を紹介してきました。 最後に、このツールが私たちのプロジェクトにもたらす価値を改めて振り返りましょう。

プロジェクトの“航海図”

インセプションデッキは、単なるチェックリストや会議資料ではありません。 それは、プロジェクトという航海に出るための地図のようなものです。

• 「なぜ出航するのか」＝目的
• 「どこへ向かうのか」＝ゴール
• 「どのルートを通るのか」＝スコープと計画
• 「航海に必要なもの」＝リソース
• 「嵐や暗礁はどこにあるか」＝リスク

これらを出発前にチーム全員で確認しておくことで、旅の安全性と成功の確率は格段に上がります。

会話こそが最大の価値

10 個の質問に「正しい答え」を書くことが目的ではありません。 大切なのは、その質問を通じてチームが会話をすることです。

• 互いの考えを知る
• 認識のズレを修正する
• 不安や期待を言葉にする

こうした対話の積み重ねが、プロジェクトを強くします。

チームを“自分ごと”にする

インセプションデッキを実践すると、メンバー一人ひとりが「このプロジェクトは自分たちのものだ」と思えるようになります。 その瞬間、プロジェクトは単なる“仕事”から“挑戦”へと変わります。

これは、成果物以上に価値のあることかもしれません。

小さな一歩から始めよう

最後に強調したいのは、全部を一度にやる必要はないということです。 気になる質問をひとつ取り上げて話し合うだけでも、チームは確実に前進します。

• 今日は「なぜやるのか？」だけ考えてみよう
• 今回はリスクの洗い出しをやってみよう

そうした小さな一歩が積み重なり、チームを大きく変えていきます。

終わりに

プロジェクトの成功を左右するのは、技術力やツールだけではありません。 共通の認識を持ち、同じ方向に進めるチーム力こそが最大の武器です。

インセプションデッキは、その力を育てるためのシンプルで強力な仕組みです。

ぜひ、あなたの現場でも一度試してみてください。 きっと新しい発見や気づきが生まれるはずです。