今風でモダンでイケてる令和版インセプションデッキテンプレートを作ってみた

昨日、インセプションデッキの解説を翻訳したのですが、令和にもなったので今風なインセプションデッキのテンプレートを作ってみました。

きっかけ

登場してから10年以上経ち、市民権を得たインセプションデッキですが、「書き方がよくわからない」という相談が結構多く、一緒に作成していると「ちょっとこれはわかりにくいかもなぁ」とか「ちょっとこれは今の現場に合わないなぁ」とか「スライドの順番がいまいちなのかなぁ」と感じることもしばしば。

そこで、内容を整理して、今風にしてみたのが今回紹介する令和版インセプションデッキです。デッキはGoogleスライドで公開しています。

『アジャイルサムライ』だと、「第4章全体像を捉える」、『第5章具現化させる』にわけて分類されてるので、ここでも、

前半：全体像を捉える（スライド7枚）
後半：具現化させる（スライド7枚）

に分類しました。

はじめのスライドから順番に決めていきやすい並びにもしているつもりです。が実際に使ったり、使ってくれた人のフィードバックを得ながら改善していこうと思っています。

以下、スライドになります。この記事を見ながら作れるように解説していきます。

前半：全体像を捉える

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

プロダクトやチームに会社が投資する理由をすべて書き出します。すべて書き出した後に、もっとも重要なものをひとつ選びましょう。

「なぜ（Why）」は動機です。動機は原動力と言えます。動機が明確になると、的確な意思決定ができます。また、「なぜ」はチームやプロダクトの存在理由です。存在理由はプロジェクトのコアとなる情報です。もっともコアな情報を判断材料に加えられます。

「われわれはなぜここにいるのか？」では、まず我々に対する期待値を統一します。

エレベーターピッチ

緑の文字部分を書き換えます。それ以外の文も自然な言葉になるように修正します。

サンプルも以下に書いておきます。

[建設現場のトラック専用道路にアクセスが必要な個々の建設チーム] 向けの、
[ロードクロージャーシステム（通称RCS）] は、
[道路が閉鎖されたときに作業員に通知] できる
[安全なコミュニケーションツール] です。
[現在の紙ベースのシステム] とは異なり、
われわれのプロダクトは [Webベースなので、すべての契約者はいつでもどこでもアクセス] が可能になります。

「われわれはなぜここにいるのか？」は「なぜ、Why」のためのスライドでした。エレベーターピッチは「プロダクトそのもの、何を、What」を明確にするものです。自分たちのやっている「こと」や自分たちの顧客、プロダクトの特性が明らかになります。

ここにまとめられたものは、すべて「とても」重要な情報です。しかし、重要なあまり、書きすぎるとわかりにくくなります。あくまでシンプルに。

エレベーターピッチでは「何を」作るのかを統一します。

チーム名は何か？

インセプションデッキの表紙として追加したスライドです。自分たちに名前をつけましょう。表紙には大きく、クールな響きを持つチーム名を記載します。自分の子供に名前をつけるのと同じ気持ちでやれば、チームに親近感がわくはずです。

バージョンや更新情報を簡単に書いておくと、過去の経緯を理解できるようになります。インセプションデッキは開発の大きな区切り、メンバーの増減、四半期や半期といったタイミングで見直しましょう。

チームのあるべき姿

追加したスライドです。チームとしての方向性を考えるため、チームのテーマをここに書きます。チームの方向性が決まらずまとまらない現場が多いようなので追加しました。

どういったチームになりたいか？どういったチームで働きたいか？メンバーはどうふるまるべきか？多種多様な時代であれど、チームで働くためには規律が必要です。アジャイル開発で実現したい自分たちの姿を書いてみるといいと思います。

まよったときは「自律したチーム」としてみてください。このテーマは奥が深いので、自律（自立じゃないよ）するためのいろいろアイデアが浮かぶはずです。

チームメンバーへの期待

もともとのインセプションデッキだと「俺たちのAチーム」に当たるスライドです。

このプロジェクトを成功させるために、誰が必要で、どのようなスキルが必要なのかをまとめます。特定の人物が重要な場合は、バイネームで書き込みます。

また、それぞれのメンバーに対する期待を出し合えば、相互理解につながります。特に「そんな期待していたの？考えてもいなかった」といった期待値のズレを早期になくせます。

チームイベントを決める

追加したスライドです。このあたりはより具体的な仕事の進め方やコミュニケーションパスの設計になります。スクラムイベントや会社で必要な定例などをここにまとめておきます。

イベントと同時に、そのイベントの意図も明示しましょう。アジャイルチーム以外の人にとっては、「スプリントレビュー？なにそれ？」です。どういった意味を持たせ運用したのかを説明するチャンスです。

タスク管理方法やドキュメント置き場などのルールもここに書いておいてもいいかもです。

とりまくプロジェクトコミュニティ

プロジェクト期間中、何らかの形で関わりを持つ人たちをリストアップします。

どのコミュニティとどういう関係性があり、どういうやりとりが発生するかをまとめます。

まとめるだけでは何も起きません。このスライドの目的は、これらの人たちと関係を早期に築きはじめ、彼らがこちらに気がつく前に、こちらから先に歩み寄ることです。

これによって、彼らはわれわれのために備えられ、必要なときにサポートできるようになります。そのために、誰が、いつまでに、何をやるかも整理しましょう。

後半：具現化させる

ざっくりリリース計画

追加したスライドです。インセプションデッキは、スプリント開始前に作られるケースが多いので、ここではリリースレベルの計画（ロードマップとよばれる場合もあるかもしれません）を「ざっくり」用意しておきます。細かい計画づくりはスプリント計画のタイミングを使います。

このスライドは細かい道のりを表してくれませんが、だいたいの方向を指し示す地図になります。

トレードオフランキング

このスライドによって、ピンチのときに何が重要なのかがわかります。優先度の低いものほど、柔軟に調整できるということもわかります。

スライダーはわかりにくいのでランキング形式にしました。また、品質は最近トレードオフ対象じゃなくなってきたようなので削除しました。アジャイルチームは人件費と追加型で予算を考えるケースが多いので、予算もなくてもいいかもしれません。予算というより売上とかのほうがいいのかも？

やらないことリスト

やること、やらないことをリストアップします。保留中のものはプロジェクト前にかならず「やる」、「やらない」を決めましょう（『アジャイルサムライ』だと「いつか決める」になってますが、「いつまでも決まらない」になりがちなのですぐ決めちゃいましょう）。

やらないことを選ぶことで、本質的にやるべきことが明確になるはずです。あれもこれもやることリストにあるなら、「半分をやらないにできないか？」を考えてみてください。

技術的な解決策

このスライドは、チームがどのように構築するかを知らせるものです。想定しているツールやライブラリなどをここにリストアップします。アプリケーション・アーキテクチャの中で、リスクの高い部分があればそれも強調しましょう。それ以外のリスクは次の「夜も眠れなくなる問題」で話し合うのでここでは「技術的」な話をします。

この方法によって、解決策から技術的な課題を洗い出せます。解決策としたライブラリや言語、アーキテクチャが適切かどうか？チーム内で合意が取れているか？リスクがどれぐらいあるか？を話し合えます。もし、アイデアがない場合は、正直に白状しましょう。あとで話すよりも、今話しておいたほうがいい方向に進みます。

初期プロジェクトではない場合は、このスライドをスキップしてもよいです。