| 観点 | インセプションデッキ | 説明 |
| プロダクトの観点 | エレベータピッチ | プロジェクトの内容を簡潔に説明。何(what)をの部分を明確化。 解決したい課題、ターゲットユーザー、他のサービスと比べた差別化要素等を整理する。 |
| われわれは何故ここにいるのか | プロジェクトの目的(why)をはっきりさせる | |
| パッケージデザイン | ||
| やらないことリスト | やらないことを一覧化する。スコープ範囲外を決めておくことにより、より必要なことに集中できるようになる。 | |
| 人の観点 | われわれのAチーム | どんなチームかを定義。役割や強み、期待することの意識を合わせる |
| ご近所さんを探せ | プロダクトコミュニティとして、ステークホルダーを明確化。 役割分担とかを整理しておかないと、想定外の所で横槍が入る場合がある。 | |
| 技術や品質の観点 | トレードオフスライダー | QCD+スコープどれを重視するかの優先順位を定義する。 少なくとも1つは妥協できるものを選ぶ必要がある。 通常の場合は一番優先度下げて調整べきなのがスコープになる。鉄のトライアングルと呼ばれる考え方があるので押さえておきたい。 ただし、外的要因などで往々にして一番最初に犠牲になるのは品質になってしまうことも多いのも実情。リリース後に別の問題を発生させる危険性があるので、そうならないようにうまく調整したいところ。 |
| 計画やマネジメントの観点 | 夜も眠れない問題 | やばい事態って何？を定義する。リスクの明確化が必要。 |
| 期間を見極める | 初期のスケジュールを立てる。 ただし、ここでのスケジュールはコミットではないことは関係者に理解してもらう必要がある。 |
