参考書籍:アジャイルサムライ
この記事は次の書籍を参考にしています。
インセプションデッキ概要
インセプションデッキの役割はプロジェクトの意思決定のためのツール
インセプションデッキはプロジェクトの意思決定のためのツールである。
10の手強い質問から構成されており、プロジェクトを開始する前に確定しておくことで、利害関係者からの質問に即座に回答できるようになる。
また、プロジェクトを革新まで煮詰めて抽出した共通理解を、開発チームに共有する効果を持つ。 さらにその共通認識をより広範囲なプロジェクト関係者全員（いわゆるプロジェクトコミュニティ）へ手軽に伝えるためのツールだ。
インセプションデッキを構築する質問には、プロジェクト開始前に全て回答できるようになってなければならない
参考：インセプションデッキを構成する10の質問：https://do-scrum.com/wp-content/uploads/2021/08/71eae26b604ea2fa14cd94aae57d54a8.png
インセプションデッキの仕組み
インセプションデッキの背景の考え方はこうである。
然るべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して認識を合わせられるはずだ
そしてその「然るべき人」に「ステークスホルダー」を加えるのが大切である。
なぜなら、プロジェクトが重要な判断を迫られるような状況に陥ったときに、何かを決定するのはプロジェクトマネージャーだけではなく、ステークスホルダーだからである。
そのステークスホルダーにプロジェクトを取り巻く環境を正しく理解してもらうからこそ、適切な判断が下せるのである。
インセプションデッキの設問と課題の一覧
- 我々はなぜここにいるのか？
なんのために自分たちはチームを組むのか？
自分たちの顧客は誰なのか？
そもそもこのプロジェクトが始まった理由はなんなのか？
これらを再確認する
- エレベーターピッチを作る
30秒いないに2センテンスでプロジェクトをアピールするもの。
- パッケージデザインを作る
雑誌のページに君のソフトウェアパッケージが販売されていたらどんな内容が良いだろうか？
- やらないことリストを作る プロジェクトで実現したいこととというのは明確になっている。
そこに加えてやらないこともはっきりさせて、一覧に表す。
- ご近所さんを探す
「プロジェクトの関係者」に含まれる範囲はかなり広い。
そういった関係者をコンタクトをとっておくことはあらゆるリスク回避に役立つ
- 解決案を描く
チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描いておこう。
- 夜も眠れなくなる問題はなんだろう？
プロジェクトで起きる問題について、考えるだけでも恐ろしいものものある。
そういった心配事こそ、話し合う必要がある。 どうすれば被害を最小限に食い止められるだろうか？最悪の事態を避けられないだろうか？
- 期間を見極める
どれくらいの期間が必要なプロジェクトだろうか？ 3ヶ月か半年か9ヶ月か？
- 何を諦めるかはっきりさせる
プロジェクトにはいくつか操作可能な要素がある。
期間にスコープに予算に品質。 現時点で譲れない要素はどれか？譲にやむをえないものは何だろうか？
- 何がどれだけ必要か？
期間はどれくらいかかりそうか？ コストは？ どんなチームならプロジェクトをやり遂げられるだろうか？
インセプションデッキ前半はプロジェクトの存在意義について
インセプションデッキ前半はプロジェクトの存在意義について語る
我々はなぜここにいるのか？
エレベーターピッチを作る
パッケージデザインを作る
やらないことリストを作る
ご近所さんを探す
インセプションデッキ1：我々はなぜここにいるのか？(チームのイメージ共有)
目的:いかなるプロジェクトでも、そのプロジェクトを成功させたいのであればその背景にある「なぜ？」を理解しなければならない。(チーム内部の共有)
これができなければ以下の内容ができなくなる。
詳しい情報を得た時に、目的を意識した的確な判断ができない
対立点やトレードオフのバラン素を考えられない
自分たちで考える権利を与えられる。
ここで大事なのは、自分自身が現場で確かめるということだ。
例えば、建設現場のシステムのプロジェクトに立ち会うとき
実際に建設現場に足を運ぶのが良い 現地の安全管理者とコンタクトを取る。 トレーラーをみる。 そして貧弱なインターネット回線をみる。
これらの行動を取ることをおすすめする。
とにかく、「これこそが「我々がなぜここにいるかの答えだ！」という質問の答えだ！」と言えるものと、それを考えた理由が何なのかを 話し合うことが大事である。
その際には、次のことも想定されるだろう。
あるプロジェクトでのこと。 この時の「我々はなぜここにいるのか？」の回答がチームメンバーで見事にバラバラであった。 請求書を簡略化することだとか、 高額なサービスを販売するマーケティングなのか 紙を減らすことなのか？ いずれも良い回答だと思うが、これは「顧客に問い合わせて確定させなければならない内容」である
インセプションデッキ2：エレベーターピッチ(外部へのキャッチコピー)
目的:私たちのプロジェクトやアイデアの本質を素早く伝えるため(外部向け)
例えばあなたのプロジェクトの関係者とエレベーターで隣あったとしよう。
この方にはあらかじめプロジェクトについて説明しておきたいことが山ほどあるが、30秒以内で新規事業を説明できるだろうか？
このような文章をエレベーターピッチと呼ぶ
うまく練られたエレベーターピッチには次の効果がある。
明確になる
チームの意識を顧客に向けさせる
確信を捉える
エレベーターピッチのテンプレートには次のようなものが良い
・[潜在的なニーズ]をみたいしたい ・[対象顧客]向けの、 ・[プロダクト名]というプロダクトは、 ・[プロダクトのカテゴリー]である。 ・これは[重要な要点、対価に見合う説得力のある理由]ができ、 ・[代替手段の最右翼]とは違って、 ・[差別化の決定的な特徴]が備わっている。
私たちのプロジェクトやアイデアの本質を素早く伝えるために必要なものの全てをエレベーターピッチは語れる。
デッキインセプション3:パッケージデザインを作る:第三者向け
目的:第三者向けの説明を用意すること
あなたのプロジェクトが作成したソフトウェアを買うとしたら、その理由は何なのかを話し合うことが大事です。
特に顧客に訴求する要件は何か。そのプロジェクトでの値打ちは何なのかを意識する。
ここではお客様に対してはフィーチャーを伝えてはいけない。
ここで訴えるべきは、効能である。
「245馬力のエンジン」ではなく、「高速道路で楽々追い越す」
「クルーズコントロール」ではなく、「ガソリン代の節約」
「アンチロックブレーキ」ではなく、「大切な人との安全なドライブ」
フィーチャーそのものではなく、フィーチャーの効能をアピールしよう
デッキインセプション4:やらないことリストを作る
プロジェクトのスコープへの期待をマネジメントするにあたっては、何をやるのかと同じぐらい、何をやらないかは大事だ。
この効果は
お客さんがプロジェクトに期待することをわかりやすくすること
開発チームが本当に重要なことだけに集中できる
意思決定のスピードを増加させる
という効果をもたらす。
「やる」の欄にはスコープに入れて取り組むものを並べる。
「やらない」の欄にはスコープから外すもの、もう気にしないものを並べる。
次回のリリース以降に延期予定のフィーチャや、単にプロジェクトの対象範囲を超えているようなものが「やらない」ことの候補である。
何にしてもここに入ったものについては当面は気に病むのをやめよう。
- 「後で決める」の欄には、今はどうするかまだ決めかねている項目を並べる。
人によって意見が異なるものについては、どちらに置かずに保留にするのだ。
デッキインセプション5:ご近所さんを探す
プロジェクトのご近所さんとあって、あらかじめ知り合いになっておく。 後になって「挨拶しておけばよかった」と感謝することになるからだ。
この場面では信頼関係を構築しておくことが大切。
プロジェクトコミュニティは考えているよりも常に広大
プロジェクトを立ち上げる前に、チーム全員でブレインストーミングするのが大切で、意識するのはやりとりしなければらない相手は誰かを探すこと。
例えば、以下の部門の人とはコンタクトを取っておく
ガバナンス部門 セキュリティかんさ リリース判定担当 業務改革担当 変更管理担当 データベース管理者 事業戦略部門 教育部門 テクニカルライター 法務 ヘルプデスク ネットワーク/インフラ プラクティスリーダーチーム コンプラ部門
おおよそ状況を把握できたら、洗い出した連絡先のグループについて話し合って、具体的な担当者がわかるかどうかを確認する。
他部署を巻き込めない時にどうするか？
顧客がプロジェクトに積極的に関わるということについてはアジャイル手法の開発の中で最も重要な点である
仮に顧客があまりにも多忙で、そもそもこのソフトウェアを「なぜ作らなければならないのか？」を説明できなければ、そもそもそんなソフトウェアは作られるべきではないとすら言える。
お客様に対しては、わかりやすく、しっかりと説明することが大事。 このプロジェクトに何が必要なのかを、「皆さんに積極的に関わっていただく必要があります。当事者意識を持っていただいた上でさまざまなお約束をしていただけねばなりません」」と説明するのが必要。
もし時間が取れなかったら、 準備が出来次第、再度お伺いします。 と伝えるのだ。
デッキインセプションの後半はプロジェクトの具体的な解決策
以前までの章で、「なぜこのプロジェクトを達成させなければならないのか？」については学んだと思う。
ここからは次の質問に答えることで、プロジェクトの具体的な解決策を提示する。
技術的な解決策を提示する
リスクを共有する
時間軸を図る
インセプションデッキ6：技術的なアーキテクチャを表示する
解決策を視覚化することとは、私たちが何をしようとしているのかを理解し、共通認識を生み出します。
また、アーキテクチャを書き出すことには次のようなメリットがあるのです。
プロジェクトの範囲を明確にする。
システムのリスクを伝達する。
どの部分に工数がかかりそうかが見える。
「全員の頭の中のアーキテクチャが一致していそう」と判断した場合でもアーキテクチャは書き出してください。
アーキテクチャを書き出しチーム全体に共有することは心理的安全を生み出します。
イベント駆動アーキテクチャのメリット：https://techblog.short-tips.info/inhouse_se/2005event_driven_arch.md
アーキテクチャを書き出してみるだけでそのシステムがどれだけ複雑なのか、どれだけ大きいのかが明確になります。
また、あなたがオープンソースソフトウェアを使いたい場合の承諾を得る際にも役に立つことでしょう。（複数の企業では、オープンソースソフトウェアの使用に許可が必要な場合があるからです。）
インセプションデッキ7：考えたくないリスクを考える
大抵のプロジェクトマネージャーは楽観的で、推測は的外れです。
やらなきゃならない仕事,タスクは常に使える時間と使える金額を上回ります。
そしてそのリスクを我々は心のどこかで認知しているのです。
リスクについて考えることはとても良いこと
プロジェクトの失敗する要因を確認することはプロジェクトのを成功に導くために必要な最低条件です。
上記のようなリスクについてプロジェクトが始まる前に事前に考えて置き、対応策や捨てても良いものを書き起こしておこう。
参考：夜も眠れなくなる問題:https://zenn.dev/ken1flan/articles/144208c4a75475
このようにプロジェクトにまつわるリスクを書き出すことは実は大きなメリットがある。
それは、ほとんどのプロジェクトマネージャーはこれらのリスクが怖い余りに存在をなかったものとして考えようともしないのだ
その中でもプロジェクトに関するリスクを事前に察知し、解決しようとするチームの姿勢は、上層部からのあなたの評価にも繋がることだろう
インセプションデッキ8：サイズを測る（時間軸）
ここまできたらそのプロジェクトがどれくらい時間がかかるのかをおおざっぱに測ってみましょう。
ですが、プロジェクトの利害関係者にはこのサイズをとてもとても大雑把なものであると説明する必要がります。
また、プロジェクトの期限がどれくらい伸び縮みしてもよいかをこの機会に利害関係者に確認してっ見ましょう。
そしてこの「サイズを図る」という段階では一つのコツがあります。
小さく図る
優秀なプロジェクトマネージャーのITプロジェクトは一つのフェーズは最長でも6か月以内です。
それ以上フェーズを伸ばすことは、彼はリスクが高すぎると感じています。
例えば仕様が大きく変わったり、競合が同様の製品を作成したり、OSSで大部分のシステムを書き換えれたり、そもそもプロジェクトが必要なくなったりなど...
また、優秀なプロジェクトマネージャーはほとんどのシステムの機能は6ヶ月以内で構築できると自負しています。
システムの機能をそぎ落とし、シンプルに保ちつつ納期を6ヶ月以内に保つことが、正確なサイズ測定に繋がるのです。
インセプションデッキ9：トレードオフスライダー
プロジェクトに対しては常に何らかの法則や力が働いている。
予算や日程は常に固定されてしまっている場合がほとんどだ。 しかしながら、「システムが実現可能な範囲」についてはコントロールすることができる。
これらのシステムにまつわる力はほとんど常に衝突する。 どちらかを優先しようと思ったらどちらかを捨てなければならない。
つまるところ、次の質問についてはプロジェクト開始前に答えられるようにしなくてはならない。
- これらの力のうち、ソフトウェア プロジェクトにとって最も貴重なものはどれですか?
• a) 品質。
• b) 時間。
• c) 範囲。
• d) 予算。
これをさらに分かりやすい言葉にすると
- やることが多すぎて時間が足りない場合、以下のどれかをしなければならない
• a) カットスコープ
• b) プロジェクトに人を追加する
• c) リリース日を延期する
• d) 品質を犠牲にする
どう答えたかはその人次第ではあるが、大抵の場合、時と場合によるが含まれるだろう。
ちなみにこれら四つのプロジェクトにまつわる要素を、「荒ぶる四天王」と呼ばれたりする。
https://www.publickey1.jp/blog/20/_2020.html
トレードオフスライダー
トレードオフスライダーはプロジェクトが困窮した時に、どの要素を削るかを決める為のツールだ。
例えば次のスライダーだと、
「予算をはみ出しても全然いいし、品質が多少荒くてバグがいくつか出てもイイから、期限と機能は必ず守ってほしい」
という要件が求められていることが分かる。
ちなみに、トレードオフスライダーで図るべき項目は一つだけではない。
「荒ぶる四天王」以外にも、顧客への説明で重要だと思われる点や優先したい機能、運用上の注意点などもトレードオフスライダーに組み込んでよい。
ちなみに、「全部優先しないとダメだ！」は無し。（いざというときの判断に遅れが出てしまう）
インセプションデッキ10：コストを算出する（大雑把に！）
デッキインセプションの最後の項目は「予算」である。
参考:https://ncdc.co.jp/columns/7297/
最後に決めるべきことは、「どれくらいの基幹で」「どれくらいの人数が必要で」「予算はいくらぐらいか」
まずはチームメンバーについて確定させる。
チームメンバーについて
あいまいで快適 コマンドアンドコントロールなしで機能できる
- UXデザイナー
- プロトタイプを素早く作れる人
- 開発者
- C#、ASP.NET、MVC の経験 - 単体テスト、TDD、リファクタリング、継続的インテグレーション
- アナリスト
- ジャストインタイム分析に慣れている - XP スタイルのストーリー カード開発 - テストを手伝ってくれる
- カスタマー
- 質問に 1 日 1 時間対応 - フィードバックのために週に 1 回会うことができる - プロジェクトに関する指示、操縦、および意思決定ができる
- テスター1名
- 自動テストの経験
- 開発者と顧客とうまく連携する
- 探索的テストが得意
この中で最も重要なのは カスタマー(顧客) である。
なぜならば、プロジェクトが何を達成するべきなのかを本当の意味で理解しているのはカスタマーのみだからである。
この人には通常よりも時間を割いて確認を取るべき事項がある。
本当に時間を使うことができるのか？
この人にはプロジェクトや環境を決定できる権限があるのか？
本当にプロジェクトを全うする意思があるのか？
彼らとは1on1のミーティングを設けて、これらの真相を確認しなくてはならない。
予算について
プロジェクトの予算については、ここはあえて大雑把にいこう。
一つのイテレーションにかかる時間とそれに費やされる人時を計測し、後は掛け算を行うだけだ。
インセプションデッキまとめ
インセプションデッキは10個の質問から構成され、それぞれが「なぜ」「どのように」の質問に答える事ができるツールであった。
