プラクティス名
インセプションデッキ
プラクティスの目的・狙い
- プロジェクト目的とチーム方針の明確化
- 共同作業を通じたチームビルディング
どんな時に使うか
- チームメンバーは集められたばかりで、ベースとなる共通認識がまだ無い
- ステークホルダーが別々の方向を向いており、プロジェクト目的やスコープなどの前提が定まっていない
実施手順
チーム全員参加で以下の10の質問と課題に対する回答を作成する。
1～5でプロジェクトの背後にある「Why」を突き詰め、6～10で「How」を考える。
| No | ワーク名 | ワークで明確化されること |
|---|---|---|
| 1 | 我々はなぜここにいるのか？ | チームのミッション |
| 2 | エレベーターピッチ | プロダクトのコンセプト |
| 3 | パッケージデザイン | プロダクトのイメージ |
| 4 | やらないことリスト | プロジェクトのスコープ |
| 5 | ご近所さんを探せ | ステークホルダー,関係者 |
| 6 | 技術的な解決策の概要 | システムアーキテクチャー |
| 7 | 夜も眠れなくなるような問題は何？ | リスク |
| 8 | 期間を見極める | スケジュール |
| 9 | トレードオフ・スライダー | 優先順位・判断基準 |
| 10 | 何がどれだけ必要なのか？ | リソース・コスト |
ワークを行うことでメンバーの認識が揃い、チームが機能するための下地が整う。文章は短くシンプルにまとめた方がよい。作成したインセプションデッキはいつでも参照できる場所に置き、新規メンバー加入時には必ず説明する。
アレンジ例
- 上記に加え「俺たちのＡチーム」というチームに必要なスキル・役割を明確化するワークを行う
- プロジェクトの期中や別のシーンでもここで使えそう、というところで単品で使用する
- 「3.パッケージデザイン」に「利用者の声（架空のレビュー評価）」を付け足してみる
アンチパターン
- 誰かが1人で書き上げてメンバーに説明する（＝ワークを通じた共通認識が生まれない）
- プロジェクトの冒頭で作成し、以降まったく更新しない（＝古新聞と化していく）
参考情報
インセプションデッキはRobin Gibson氏によって考案され、Jonathan Rasmusson氏の著書『アジャイルサムライ』で紹介され広まりました
書式のテンプレはオリジナル版がGithubに挙がっていたり、その他の形式でも色々な方が公開してくれていますが、質問数や文言などバリエーションかあるのでお好みのものを。フォーマット自体はシンプルなので自作も可能です。
インセプションデッキのより詳細な説明としては定番のAgileStudioさんのサイトをオススメします。
こぼれ話（私的コメント）
アジャイル開発は自由度が高い分、最初にきちんと背骨を通しておかないとプロジェクトが迷走しがちです。なので10枚きっちり書き上げて踏み固めておきたい！・・・ところですが、実は僕自身は今まで10枚書かせてもらったことが一度もありません。時間がないから全部はムリだねって話になって、1,2,4,5,9だけやろっか、みたいな感じで絞られてしまうのです。いつか10枚ちゃんと書ける日が来るといいなぁ、と常々思っています。新規プロダクトであればまだ推しやすいのですが、既存プロダクトだとスキップされがちなプラクティスです。
余談ですがアレンジ例にある「俺たちのＡチーム」は1980年代の米テレビドラマ「特攻野郎Aチーム」（正義の4人組がそれぞれの専門スキルを活かして悪の組織と戦う）から来ているようなのですが、この元ネタが分かるかどうかでチーム内の世代格差が明らかになってしまいそうです。ちなみ僕は知ってる派です。