【やり方】インセプションデッキとは

みなさん、数々のプロジェクトが生まれては継続されたり、失敗したり、多くの方がプロジェクトに関わっていると思います。

ところで、

全員が同じ方向を継続的に向けているでしょうか？

特に、

• 大事なことが抜けてませんか？
• 一方的にPMが話しているだけではないですか？
• 偉い人だけで決めてませんか？
• 都合がいいことしか伝えてないのでは？
• メンバーが不安に思ったことは共有されていますか？
• テンションがずれてませんか？
• 全員で合意ができていますか？
• 全員が後から確認できるアウトプットがありますか？
• 方向性が変わった時にアウトプットを再確認、定義できていますか？

自信を持って「YES！！」と言える方はこの記事を読まなくても大丈夫です。 それ以外の方はこれから読み進めることをお勧めします。

では、なぜ全員が同じ方向を向き続けるのは難しいのでしょうか？

それは、

• 役割が違う
• レポートラインが違う
• 価値観が違う

ということが原因だと思います。 その解決手法が

インセプションデッキを作ることです。

では、インセプションデッキがなぜ適しているかを紐解いていきます。

Why?

有名な画像でこんなものがあります。

これは顧客が本当に必要だったものを表しており、簡単にいうと

• 本当に欲しいものは誰もわかっていない
• 「言った」「言わない」でずれてしまう
• イメージだけだとみんな異なる。

例えば、「かっこいいもの」という言葉で全員が同じものをイメージできるのか？ という問題と同じです。

ではこれをどう解決していくかです。

When？

• プロジェクトの始まった時
• メンバーが増えた時

Who?

• チームメンバー全員

Where?

• みんな一緒にできるならどこでもどうぞ。

How

• チーム全員で話し合って合意したものをアウトプットする

ところで

「もうキックオフミーティングや説明会でやってるよ」という方、 本当に今のやり方で十分ですか？

• 大事なことが抜けてませんか？
• 一方的にPMが話しているだけではないですか？
• 偉い人だけで決めてませんか？
• 都合がいいことしか伝えてないのでは？
• メンバーが不安に思ったことは共有されていますか？
• テンションがずれてませんか？
• 全員で合意ができていますか？
• 全員が後から確認できるアウトプットがありますか？
• 方向性が変わった時にアウトプットを再確認、定義できていますか？

ということで、インセプションデッキはプロセスが大事です。

具体的には？

実際はこんなことを決めていきます。

プロジェクトの名前

[プロジェクトの名前]

名前をつけた理由

• [名前をつけた理由その1]
• [名前をつけた理由その2]
• [名前をつけた理由その3]

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

1. [大事な理由その1]
2. [大事な理由その2]
3. [大事な理由その3]

プロジェクトの根幹に関わる理由

[このプロジェクトの根幹に関わる理由を1つ、ここに書く]

2. エレベーターピッチ

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

3. パッケージデザイン

[プロダクトの名前]

最高のキャッチコピー

[最高のキャッチコピー]

ユーザーへのアピール

1. [ユーザーへのアピールその1]
2. [ユーザーへのアピールその2]
3. [ユーザーへのアピールその3]

4. やらないことリスト

カテゴリ	項目	やる / やらない / あとで決める	理由
[カテゴリ]	[やること]	やる	[やると決めた理由]
[カテゴリ]	[やらないこと]	やらない	[やらないと決めた理由]
[カテゴリ]	[あとで決める]	あとで決める	[あとで決めると決めた理由]

5. プロジェクトコミュニティは...

関係者全員を！

...思っているよりもずっと大きい！

6. 技術的な解決策の概要

採用する技術

• [プログラミング言語]
• [ライブラリ]
• [ツール]
• [その他の要素技術]

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

• [もし起きたらこわーいこと、その1]
• [もし起きたらこわーいこと、その2]
• [もし起きたらこわーいこと、その3]

8. 期間を見極める

あくまで推測であって、確約するものではありません。

9. トレードオフ・スライダー

典型的なフォース

max	>>>	>>>	>>>	min	項目
o					機能をぜんぶ揃える（スコープ）
	o				予算内に収める（予算）
		o			期日を死守する（時間）
			o		高い品質、少ない欠陥（品質）

上記以外で重要なこと

max	>>>	>>>	>>>	min	項目
o					使い勝手
	o				とにかくシンプルに！
		o			詳細な監査ログ
			o		[などなど]

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

要素	値
人数	3名
期間	3.5ヶ月
予算	$250K

俺たちの"Aチーム"

人数	役割	強みや期待すること
1	アナリスト	必要な分だけ必要なときに分析するスタイルで働ける。テストも喜んで手伝える。素早い繰り返し型の開発スタイルで働ける。
2	開発者	C#、MVC.NET、jQuery、SQL、ユニットテスト、リファクタリング、TDD、継続的インテグレーション
0.5	マネージャ	顧客と直接顔を合わせてのコミュニケーションを担当する。状況報告、スコープ調整、予算管理、レポートラインへの報告

---

最後に

このインセプションデッキは「アジャイルサムライ」など数多くのアジャイル指南書に記載があります。 ぜひ、こちらについてもご覧ください。

passionate-po.hatenablog.com