プロジェクト・企画のドキュメントはキチンと作ろうの話(インセプションデッキ)
【当該記事について】
この記事は、僕自身がインセプションデッキを久々に作ることになったので、その意義と内容をおさらいする意味で記述しています。
そもそものインセプションデッキの成り立ちや概念の説明などは省き、質問項目10個の内容と意義に言及しています。
詳しくは参考記事を末尾に掲載いたしますので、そちらをご参照ください。
――――――――――――――――――
【プロジェクトのドキュメントを作る意義】
結論としては「プロジェクトに対する共通認識を持つため」です。
個人的に経験したことなのですが、プロジェクトや企画に関して「コンセプトやターゲットが把握できない」だとか「スケジュール感や優先順位が推し量れない」ということが多々有りました。
もちろん参加しているメンバーに確認や質問することは出来るのですが、プロジェクトや企画の責任者・担当者自身もキチンとしたイメージを持っていなかったり、場当たりの対応や判断の放棄ということもしばしば発生していました。
例えば「お客さんのことを考えてやってくれればいいよ」とか、回答になってないですよね。
さらに言えば、誰かに聞けるのであれば良い方で、中には発足時のメンバーが全員退社しておりプロジェクト自体のコンセプト・方向性がわからないケースもありました。
これでは一貫した対応や舵取りが行えないので、品質の低下は免れません。
プロジェクトや企画は発足時のメンバー以外の人が関わることもありえますし、担当者・責任者が交代することもあります。
その際に「お客さんのことを考えてくれればいいから」や「勉強して、あとはわかるでしょ」ではなく、そもそものコンセプト・全体像・方向性が共有できるドキュメントがあると、その後の成果も変わってくるものになると思います。
プロジェクトや企画を1人でやる場合以外は、他メンバーもプロジェクトの意義や全体像を共有できるようドキュメントを作成するべきでしょう。
(ドキュメントを作ったからといって必ずしも成功するわけではないですが)
こういった「プロジェクトの憲章」として”インセプションデッキ”を活用しよう、という話になります。
似たようなドキュメントとして”ビジネスマップキャンバス”や”リーンキャンバス”などもありますが、これはどちらかというと「ビジネス面でのプロジェクトの意義の明示」となります。
プロジェクトの制作・運用・運営という視点では、インセプションデッキの方がより有用なドキュメントになりうる、と思われます。
――――――――――――――――――
【インセプションデッキで問われる10の質問】
インセプションデッキは、10個の質問を通じてプロジェクトのコンセプトや全体像を表していくものです。
(なんですが、いろいろ調べて下記では11個となっています)
本来であればメンバー全員との話し合いを通じて形成していくものですが、まずは個人で考えてみて、そこを起点に意見をもらってブラッシュアップするというのも良いと思います。
(ゼロベースでスタートすると話が止まってしまう可能性もありますしね)
また、1回のミーティングで決められないことは保留にするというのも良いと思います。
次のTODOはその点を決めるためにするべき行動、ということになり、プロジェクト自体は確実に前に進みます。
むしろ空白となった点を埋めないままにスタートすれば、前述の「場当たり的な対応」を余儀なくされ、プロジェクトの品質低下を引き起こしかねません。
そういう場合は、空白となってしまう箇所を予め予測し、プロジェクトに何が足りていないかを確認することも大事です。
■ 1.我々はなぜここにいるのか？(ミッション)
プロジェクトのゴールや、参加メンバーが関わる意義を示すものとなります。
3つの理由を明示し、1つの大きな根幹(に関わる理由)を明示します。
プロジェクト・企画のコンセプトを明確にし、存在意義を示します。
また、関わっている人間の「なぜ自分がやるの？」という問いに答えることもできます。
「なぜ？」という問いに答える(why)ことに気をつけないと、ブレが生じます。
2のエレベーターピッチとの整合性を図るため、場合によっては書き直すことも重要です。
■ 2.エレベーターピッチ(ニーズ)
プロジェクトの価値に対してフォーカスしています。
下記の問いを埋めていく形で形成します。
・[潜在的なニーズを満たす・潜在的な課題の解決]をしたい
・[対象顧客]向けの、
・[プロダクト・プロジェクト名]というプロダクトは、
・[プロジェクト・プロダクトのカテゴリー]です。
・これは、[利点・対価に見合う説得力のある理由]ができ、
・[代替手段の最右翼]とは違って、
・[差別化の決定的な特徴]が備わっている。
こちらも1と同様に、プロジェクトの存在意義を示すのに重要なものとなります。
競合する他のプロジェクトやプロダクトとの差別的優位点も示すことになるので「これってすでに有る○○でよくない？」という不毛な結論から脱することができます。
また、文章内で同じ内容を繰り返さないように気をつけることで、課題をより深く捉えることができたり、現状での認識で足りているのかを確認することもできます。
■ 3.パッケージデザイン(ビジョン)
これはプロダクトの名前・写真・キャッチコピー・アピールを3点、といった形で、紹介文を書くようなものとなります。
ユーザーやお客様に対して、プロダクトのベネフィットや価値を示すものです。
イメージボードとして最適なものかと思いますが、ケースによっては明確に示すことができない場合もあります。
(例えば、社内向けで研究目的のプロジェクトだったりする場合)
ただ、そういった場合でもイメージボードを作ること自体は有用かと思われますので、ある程度のビジョンが見えるようにしておく、というのは重要かと思います。
■ 4.やらないことリスト(スコープ)
これは「やること」「やらないこと」「あとで決めること」を明確にしていくリストです。
プロジェクトに対して必須の事項と不要な事項、進捗に合わせて判断していくべき事項を明確化します。
このリストはどちらかというと「やらないこと」を明確化するのが重要です。
あれもこれもと「やること」を全部乗せしていくとキリがありません、人気があるからと海鮮とトンカツとうなぎを乗せたらカオス丼が出来上がります。
この「やらないこと」を明確にする際には、1と2の部分は重要になってきます。
■ 5.プロジェクトコミュニティ(ステークホルダー)
このプロジェクトがどの程度の影響力があるのか、を示しています。
コアとなるメンバーやチーム以外に、実現することで影響を及ぼす関係者全てを列挙します。
これらを明確化することで、新たに協力を得たい場合や専門的な問題が発生した場合の相談先、プロジェクトを拡張したい場合の第一候補となる協力者を把握することもできます。
また、影響を知ることでメリットや意義をより具体化することができるとも言えます。
■ 6.技術的な解決策の概要(アーキテクチャ)
プロジェクトを実現していくにあたり、採用する技術や対応方法(技術的にどう実現するのか)を記述します。
リスクがある箇所を割り出したり、採用を見送る点などを把握するために用います。
必要となるツールや採用技術だけでなく、問題発生時の解決策となる技術を把握できればより良いかもしれません。
■ 7.夜も眠れなくなるような問題は？(リスク)
もし起こった場合に問題となるポイントを挙げ、その対策を考えます。
おそらく考えだすとキリがない部分でもあるので、「目標の達成を妨げる要因」など、コアんポイントに絞って考えると良いでしょう。
また、数に関しても3〜5項目程度に抑えておくと良いかもしれません。
(もちろん、後々リスト化して各個対応策を提示していくことも大事かと思います)
■ 8.期間を見極める(スケジュール)
初回リリースまでと定めた場合に、どれくらいの作業と期間が必要なのかを明確化します。
まずは一番最後のゴールに関して設定しておくと良いでしょう。
そこにむけてどのような作業が必要なのか、各作業はどの程度の期間が必要なのか(どの程度の期間が取れるのか)を割り出し、落とし込んでいきます。
スケジュールをハッキリすることで、いつまで経ってもプロジェクトが進まないだとか、スケジュール感が場当たり的になって優先順位が付けられないなどを解決することができます。
また、このスケジュールはあくまで推測を元にした形とします。
場合に応じて柔軟に対応できるよう心がけましょう。
■ 9.トレードオフ・スライダー(プライオリティ)
項目を設けて、1〜5の重要度を設けることで何を優先すべきかをハッキリさせます。
逆に言えば「何を諦めるのか」を明確にすることが重要です。
プロジェクトに応じて項目は様々となりますが、比較的下記の項目は汎用性の高いものとなります。
(なお、※は必須項目とされています)
・機能を全て揃える(スコープ)※
・予算内に収める(予算)※
・期日を死守する(時間)※
・高い品質、数くない欠陥(品質)※
・簡単に使える、考えさせない(使い勝手)
・高い効果、有用性(効用)
「全部5(最重要)だろ！」となるのは単なる思考停止です。
最重要になるのはせいぜい1〜2でしょう、例えば期日に関して融通が効くのであれば5ではなくなるはずです。
必要に応じ項目を増やすことで対応しますが、全体で8項目程度になるようにします。
■ 10.初回のリリースに必要なもの(コスト)
こちらはリリース前に必要な人員の計算なども行います。
必要経費と人件費を割り出すことで、プロジェクトにかかってくるコストを算出することが目的です。
また、8と似ていますが、もしそれ以外にも作業が発生し人的コストが必要となるのであれば、この項目で明確化しておくと良いと思います。
突然の人材不足にそなえることができます。
■ おまけの11：役割と人数(メンバー)
チーム内の役割と人数、それらに期待することや強みを明示します。
これは役割に対して人数や仕事量を設定してもいいですし、参加メンバー個人に対しての役割と期待することや強みを設定しても良いかもしれません。
傍観者効果に言われるように、行動を起こさないメンバーが多い場合には、自主性を持ったメンバーも行動をしにくい、という状況になりかねません。
漠然と「よろしくお願いしま〜す」ではなく明確に役割を設定することで、自信をもって行動に移したり、他のメンバーと協力しやすい環境を作る一助になると思われます。
――――――――――――――――――
【参考資料】
この記事ではインセプションデッキの各項目の質問内容と役割に関して記述していました。
きちんとインセプションデッキを知りたい方やテンプレートを参考にしたい方は、下記の各記事を参考にしていただくと役立つと思います。
(それぞれ短く、わかりやすくまとめられております)
また、今回の記事を書くに当たって、上記記事を参考にさせていただいております。
もし、当該記事に問題がある場合は、お手数をおかけいたしますがコメントなどでご連絡いただけますと幸いです。
誠意対応させていただきます。
(内容の誤りのご指摘などもいただけますと幸いです)
この記事が気に入ったらサポートをしてみませんか？