まずなぜインセプションデッキが存在するのかについてなのですが、一言で言うと「プロジェクトの全体像を明確にするため」です。

インセプションとは、プロジェクトの目的、方向性、背景、優先順位、方向性等を整理できるフレームワークです。10個のアクティビティが用意されていて、クライエント、またチーム全員で話し合いながらそれに答えていく形式で埋めていきます。最終的にチーム全員で合意したものがインセプションデッキとしてアウトプットされます。

インセプションとは？

インセプション・ワークショップではプロジェクトの向かう先を決定し、ワークショップ後に制作されるドキュメントはインセプション・デッキと呼ばれています。

インセプション・デッキはチーム・メンバーみんなで共通認識を合わせるのに役立ちます。これはアジャイル・プロジェクトにおける「プロジェクト憲章」に近い意味合いを持ちます。

💡プロジェクト憲章とは、企業や組織内でプロジェクトを公式・正式に承認すること、プロジェクト・マネージャを特定しその権限や責任を明確にすること、ビジネス・ニーズ、目標、プロジェクトによる期待される結果、プロジェクトの経済面を明確にすることを目的とした重要な文書です。

ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになりました。

動くソフトウェアを素早く開発するための「アジャイルソフトウェア開発手法」を、実際に導入するにはどうすればよいかを、豊富な図を使い親しみやすい言葉で解説しています。経験豊かな著者が具体的なノウハウをまとめた本書は、アジャイル開発を導入したいと考えている組織や人のための「現場のマニュアル」として役立ってくれることでしょう。

インセプションデッキについては、Jonathan氏のブログ「The Agile Warrior」にて説明を読むことができます。

インセプションの3つの重要な要素

プロダクト開発エンゲージメントの開始フェーズは、短い期間で3つの重要な結果を達成するようにデザインされています。

1.プロダクト開発の主要な仮定、仮説、および成功指標を明らかにします。
ソリューションの構築中に利害関係者が意思決定を行うためのフレームワークを提供するのに役立ちます。

2.プロダクトの初期設計式を作成します。
利害関係者とのコミュニケーションや継続的な投資の追求に役立ちますが、プロダクトと市場の適合性のテストやユーザー調査の実施にも同様に重要です。

3.最初のプロダクトバックログ、ロードマップ、およびリリース予測を作成します。
最初のリリース以降に到達するために必要な投資の感覚が得られます。
できるだけ早くアジャイル開発フェーズに移行します。これにより、ライブ・マーケットやユーザーテスト、仮定の検証、主要な成功指標に対する測定、無駄の最小化が可能になります。

インセプションのステップ

問題のグラフ化
キック・オフ・ワークショップには、さまざまなステップにわたって、目標に応じて次のアクティビティをいくつか含めることができます。

Step1：マーケット
→ プロダクト開発の調査
→ プロダクト・ビジョン・ステートメント
→ 成功指標の特定
→ ビジネス・モデル・キャンバス

Step2：ユーザー
→ バリュー・プロポジションの調査
→ ユーザー・ジャーニー・マッピング
→ ジョブ・マッピング
→ バリュー・プロポジション・キャンバス
→ 見積もり

Step3：
→ プロダクト・バックログの生成およびファースト・パス・サイジング
→ インパクト・マッピング
→ ストーリー・マッピング
→ ストーリーの見積もり

Step4：ラピッド・デザイン・プロトタイピング
このデザイン主導の集中は、プロダクト開発の演習にユーザー中心の感性をもたらします。 通常、結果には次のものが含まれます。
→ ユーザーフロー図
→ タスク・フロー・ワイヤーフレーム
→ インタラクティブ・プロトタイプ
→ コンセプト検証テスト（クライアントの関与が必要な場合があります）
また、これらの設計表現に照らしてプロダクト・バックログを確認することもよくあります。これにより、ロードマップ・リリース予測も改善される可能性があります。

Step5：スプリントのテクニカル的準備
アジャイル開発サイクルに入ると、デリバリーチームの目標は、機能的で展開可能なソフトウェアを段階的に提供することです。 プロトタイプと並行して、技術的な発見と準備が行われる可能性があります。 これには次のものが含まれます。

→ ドメインと脅威のモデリング
→ データフロー図
→ 現状のコンポーネント図
→ 外部統合ポイント
→ 既存のIPの監査/評価
→ API定義
→ サポートされているメッセージ形式とプロトコル
→ サービスレベルアグリーメントのレビュー
→ 非機能要件の発見
→ ソリューションに適したエンジニアリングプラクティスのレビュー

Step6：スプリントの技術的準備
場合によっては、クライアントは、他のインセプションアクティビティの結果がより明確な絵を描くまで、スプリント技術準備の要素を延期することを好むかもしれません。これらの要素は次々に発生するように編成できますが、これらの要素がすでに十分に理解されていない限り、準備が完了する前に実際のスプリントベースの開発を行うべきではありません。

Step7：結果の要約
開始フェーズの目標は、成功する作業リズムと、成功のためのスプリントベースの開発プロセスを設定するために必要な入力を確立することです。 通常、インセプションは次の結果をもたらします。

Step8：製品のバックログとリリース計画、および付随する投資予測。
利害関係者および/またはユーザーの検証に適した設計式またはプロトタイプ。発生するソフトウェアの機能的でテスト可能なスライス（「増分」）の開発をサポートするための技術環境と十分な技術的理解。

これらの結果は、利害関係者にレビューの定期的なスケジュールを提供し、必要に応じて市場またはユーザーテストに展開する機会を与えるローリング開発リズムに到達するために必要なすべてです。

また、製品所有者が開発プロセス全体を通じて開発チームを導くために使用できる、主要な製品開発/市場仮説および主要な成功指標の記録がある場合もあります。

具体的な項目

具体的には以下のような項目を考えます。これらの質問は、ステークホルダーと開発チーム間で認識を合わせるべき重要な項目といえます。

→ プロジェクトを実施する理由・背景
我われはなぜここにいるのか？プロジェクトの背景とゴールを書き出しましょう。
→ エレベーターピッチを作る
プロダクトの概要・短い時間でプロジェクトについてプレゼンしてみよう！
→ パッケージデザインを作る
特長を表すキャッチフレーズ。プロジェクトの特長を書き出そう！
→ やらないことリスト
やらないことリストを作る。時間に余裕を作り、本当に重点を置くべき部分を探そう！
→ 「ご近所さん」を探そう
このプロジェクトに関わっているメンバーを書き出そう！
→ テクニカルソリューション
解決案を描く。技術的な解決策を探そう！
→ プロジェクト・リスク
夜も眠れなくなるような問題は何だろう？プロジェクトのリスクを洗い出そう！
→ スケジュール
期間を見極める。暫定マイルストーン、完了期限
→ トレードオフスライダー
何を諦めるのかをはっきりさせる。開発時に優先する要素、トレードオフの確認
→ 初回のリリースに必要なもの
→ プロジェクトの体制
チーム・メンバーの役割と期待値を明文化します。

これに取り組むことによって得られる効果は様々が、プロジェクトを進めていく上での指針になったり、迷った時に重視すべきことは何かを見定める判断基準を得ることができます。

プロジェクトを実施する理由・背景

我われはなぜここにいるのか？プロジェクトの背景とゴールを書き出しましょう。このプロジェクトの目的がなんなのか？また顧客はどんな課題を解決したいと思っているのかを書き出しましょう。

エレベーター・ピッチ

エレベーター・ピッチとは、エレベーターに乗っているくらいの短い時間で自分自身や自社のビジネスなどについてプレゼンする手法のことです。15～30秒という短時間で行うプレゼンは、営業活動だけでなく、自己アピールなどにも活用できるスキルです。

このフレームワークを使用し、シンプルな言葉でプロダクトを表現する方法を見つけ出しましょう。

これはプロダクトの価値にフォーカスしたアクティビティで
→ このプロダクトは誰向けなのか？
→ コアとなる価値は何か？
→ 競合との差別化はできているのか？
などといった、プロダクトに対する認識を明らかにできます。またチームメンバーと合意して一つにまとめたい時にこのアクティビティをしてみてもいいかもしれません。

パッケージ・デザイン

プロジェクトの特長を書き出して、ユーザーの視点からプロダクトについてしっかりに考えることはとても大切です。プロダクト・ボックスを作成するとでプロジェクトないしサービスの特徴を捉えることができます。またプロダクトの強みやアピールポイントも再認識できます。

→ ユーザーがこのプロダクトを購入しようとしている3つの理由は何ですか？
→ このプロダクトのスローガンが1つあったとしたら、それは何でしょうか。

やらないことリスト

時間に余裕を作り、本当に重点を置くべき部分を探そう！

はやることリストではなく、やらないことリストを作りのがポイントになります。MVPリリース時点では、プロダクトの必須で、また不要なアイテムは何かを明確にすることが大切になります。やらなければいけないことに集中するためにも、無駄を省き、時間を節約しましょう。

「ご近所さん」を探そう

ご近所さんとはここでは「プロジェクトに関わる人物」をピックアップしておくことを指しています。ここではプロジェクトの相関関係を図示などを作ります。

プロジェクトに関わるコミュニティは、たいてい思っているよりも大きいことを理解していないことが多いために、失敗に終わるケースがあります。実際のチームメンバーはもちろん、何かあった時に頼れるステークホルダー、外部の人材や、顧客側の担当者などこのプロジェクトに関わる全ての人を明記しておくことで今後の作業もスムーズになります。

テクニカル・ソリューション

技術的な解決策を探そう！

ここでは具体的な技術アプローチを書き出します。これを洗い出しておくことでエンジニア以外でも「どんな技術なのか」「どこが単一障害点」になりうるのかなどをあらかじめ洗い出しておきます。

ここでは技術アーキテクチャの高レベルのブループリントを作成しましょう。そしてチームの同意を確認してください。

プロジェクト・リスク

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

これはプロジェクトのリスクを管理しておくために、プロジェクトのリスクを洗い出します。何が起きたらリスクをプロジェクト立ち上げから管理しておくことで、早めの対策を打つことを目的とします。特にクリティカルな問題をあらかじめ洗い出しておきます。

スケジュール

期間を見極める。暫定マイルストーン、完了期限

前もってプロジェクトを完了するのにかかる日数を正確に決めることは難しいので、ここでは利害関係者のために高レベルのストーリーの計画と見積もりを決めます。やらないことリストはここで役に立ちます。 

トレードオフスライダー

優先事項の確認しよう。
何を諦めるのかをはっきりさせる。開発時に優先する要素、トレードオフの確認

すべてのプロジェクトには、時間、お金、範囲、品質などの手段があります。 これらのどれが最も重要で、どれが柔軟にできるかをよく理解することが大切です。このトレードオフスライダーは、プロジェクトの中で必要な機能の取捨選択をする際に立ち返る指標です。
品質、予算、納期、スコープの優先順位を決め、プロジェクトが判断を迫られた際の材料とします。例えば、予算はどうしても固定である場合は、予算が優先順位１位となり、予算に合うようにスコープや品質、納期を調整することとなります。

初回のリリースに必要なもの

ここではMVPを見極めるために初回のスコープを定義します。

すべての利害関係者の頭に浮かぶ2つの質問について説明します。これにはどのくらいの時間がかかり、どのくらいの費用がかかりますか？

プロジェクトの体制

チーム・メンバーの役割と期待値を明文化します。

インセプションデッキの良いところは、チームメンバーで共通の認識をもつ、また共通体験を通して真の合意にたどりつくプロセスです。アウトプット自体はそんなに重要ではなく、ワークショップこそが重要だと思います。

よろしければこちらのインセプション・デッキ の テンプレート (日本語版)をお使いください。Googleスライド版は、コピーをしてお使いください。

私も、色々勉強中なので、皆さまの、ご意見・ご感想をお聞かせください。お読み頂きまして、ありがとうございました。

メルボルンを拠点にプロダクトデザイナーとして働いています。 主にデジタル・プロダクトの制作に携わっています。