プロジェクト成功のカギ！インセプションデッキのススメ

プロジェクトに関わる時、「これって何でやるんだっけ…？」と疑問に感じるシーンありませんか？目的を聞いても、人によって言うことが違ったり。

そんな時ぜひ活用して欲しいのが、「インセプションデッキ」。これを使うことで、

プロジェクトの目的を明文化し、本質を見失わない
プロジェクト関係者全員で認識を揃える

この2点を叶えることが出来ます。私自身もプロジェクトマネージャとして案件に携わる中、インセプションデッキを活用してからのほうが圧倒的に効率よく進められています。

今回はインセプションデッキの概要と、導入しなかったケース、したケースでのエピソードについてまとめます。

インセプションデッキとは

我々は何故ここにいるのか
エレベーターピッチ
パッケージデザイン
やらないこと
ご近所さん
解決策
夜も眠れない問題
期間を見極める
何を諦めるのか
何がどれだけ必要なのか

という10項目を書き出して明文化するものです。

プロジェクトとは、本来何かの目的を達成するために立ち上げられたもの。まずは関係者間で、認識を揃えることが成功を左右するカギと言っても過言ではありません。

立ち上げ初期は、初期メンバーの中に共通認識が生まれていることが多いので、さほど問題になりません。しかしプロジェクトが本格的に走り始めると、関係者が増えていったり、初期メンバーの離脱、あるいは記憶の忘却（よくある）など、プロジェクトの本質を知る人がどんどん減っていきます。目の前の業務引き継ぎはされても、プロジェクトの本質が引き継がれないことは往々にしてあります。

これの何がまずいか。プロジェクトを進める中で、当初想定していなかったことや考慮漏れに出くわし、何かを決断しなければいけないシーンです。プロジェクトは限られた予算、人員、時間で進めており、機能を切り捨てたり、選択をしなければいけないシーンに出くわします。その時に、このプロジェクトの本質を見失うと、重要度や優先度を見誤った判断になってしまうのです。

それを防ぐ時に役立つのが「インセプションデッキ」。判断基準が明確になりますし、明文化されていますので、関係者全員の合意も得やすいという効果があります。

インセプションデッキを導入する前のエピソード

総予算1.5億程度のサービス立ち上げプロジェクトに、途中からプロマネとして参画しました。「スケジュールがやばいから何とかして！」というオーダー。立ち上げの目的は人によって認知式が違っており、目の前の「スケジュール」を最優先に物事を判断してきました。

結果的にスケジュール通りにリリースは出来ましたが、後日初期メンバーから話をきくと、「既存サービスのユーザビリティが悪かったので、新サービスではユーザの使い勝手を最優先にコンセプトづくりをしてきた」というのです。約2年かかったプロジェクトでしたが、立ち上げメンバーは全員離脱しており、このコンセプトは誰にも継承されておらず、「サービスのリリース」自体が目的になっているケースでした。反省エピソードです。

インセプションデッキ導入後のエピソード

前章で立ち上げたサービスに、新規機能を追加するプロジェクトが発足。前回の反省を活かし、プロジェクト立ち上げ時に「インセプションデッキ」を作成しました。この資料は誰からも見れる状態で配置し、さらにプロジェクトのキックオフ時に関係者に説明。また関係者が増えたときにもこの「インセプションデッキ」の資料をもとに背景を理解してもらい、関係者間で溝が生まれることはありませんでした。スケジュール通りリリースは完了、現在も本来の目的達成に向けたPDCAサイクルも機能しています。