アジャイル開発でプロジェクトマネジメントの屋台骨となる厳選4項目 インセプションデッキを書いてみよう

こんにちは! mofmofで受託開発や新規事業の立ち上げをしている岩井です。現場のエンジニアが書くシリーズ(第何弾なのかわかりませんが)、今回はアジャイルプロジェクトを進める上で非常に重要なインセプションデッキというものを紹介してみようかなと思います。

目次

  1. インセプションデッキとは
  2. インセプションデッキの紹介
  3. 厳選4項目
    1. 我々はなぜここにいるのか
    2. エレベーターピッチ
    3. やらないことリスト
    4. トレードオフスライダー
  4. 実際のプロジェクトで活かすために

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

アジャイルの教科書と言っても過言ではない「アジャイルサムライ」という書籍で紹介されているスライド集です。以上。

というのはあまりにもざっくりしすぎているので、もう少し詳しく概要を紹介しようかなと思います。

まず、なぜインセプションデッキが存在するのかという話なのですが、一言で言うと「プロジェクトのWhyとHowを明確にするため」です。自分たちはどうしてこのプロジェクトに取り組むのかという事であったり、開発しようとしているプロダクトのコアとなる価値はなんなのか、顧客に届けたい価値は何かといったことを明確にします。

これに取り組むことによって、例えばプロジェクトを進めていく中で迷走し始めた時の指針とすることができたり、トレードオフの関係にある事柄の判断について「自分たちが重視すべきことは何か」という原点が生まれます。実際走ってみないとわからないことだらけのプロジェクトにおいて、あらかじめ「こういう時はこんな軸に準じて判断しよう」といういわば屋台骨を準備することができるわけですね。

なので、具体的に「こんな事態になった時にこんな対処をしよう」を決めるのではなく、「なぜ、どのように取り組んでいくのか」というやや抽象的なレベルの内容を議論することとなります。

また、のちのち発覚すると手戻りに繋がったり、いざそういう事態に陥った時には話しづらいような事柄もあらかじめ認識合わせをしておく・話しておく機会にもなります。「自分はこうしたくて開発を依頼したんだけど」「いや、こう言っていたから自分たちはこう捉えて開発をしていた」…のような事態を避けるため、プロジェクトの向かう先の認識合わせをする場となります。

さあ、そんなこと一体どうやって話すんだい?という気持ちになってきましたね。ご紹介いたします。

インセプションデッキの紹介

インセプションデッキは10枚のスライドで構成されています。雛形は書籍「アジャイルサムライ」のサポートページで配布されていますので参考にしてください。こちら

スライドの趣旨を列挙すると下記のような形になります。

whyを明らかにする

  1. 我々はなぜここにいるのか
  2. エレベーターピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. 「ご近所さん」を探せ

howを明らかにする

  1. 技術的な解決策
  2. 夜も眠れない問題
  3. 期間を明確にする
  4. トレードオフスライダー
  5. 何がどれだけ必要か

理想で言えば、プロジェクトの参加者全員が個々人で全てを埋め、実際持ち寄り比較しつつ議論しつつ、合意を得た一つを作り上げるというものが望ましいです。このフローであれば、全員がプロジェクトの価値や向かうべき先を腹落ちさせた状態でプロジェクトを進めることができます。

この取り組みによって得られるのは自律的なチームです。プロダクト責任者が下した判断を鵜呑みにするのではなく、チームの一人一人がプロジェクトで実現したいことに対して適切と考えたことを発信できます。結果、プロジェクトで目指していたことを、より高精度で・より高品質で実現することが可能となります。

しかし、現実問題として全てを議論し合意するというのは時間的に厳しいプロジェクトが多いと思います。mofmofでは10スライドのうち、特に時間対効果の高い4スライドをピックアップして合意することを目指しています。その4スライドについて、詳細に紹介しようと思います。

厳選4項目

ズバリ、こちらです。

whyを明らかにする

  1. 我々はなぜここにいるのか
  2. エレベーターピッチ
  3. やらないことリスト

howを明らかにする

  1. トレードオフスライダー

それぞれ解説・ポイント紹介をしていきます。

我々はなぜここにいるのか

一つ目は通称「なぜここ」です。このプロジェクトでたどり着きたいゴールを明確にするものですね。

例えば地球上のあらゆる場所から、地球上でもっとも多い選択肢の中から欲しいものを買えるようにするためとかですかね。ものすごい品揃えのECサイトを作るため、ではなく。

ホームセンターにドリルを買いに来る人は、ドリルが欲しいのではなく、穴が欲しいからドリルを買いに来ているんだーみたいな話ありますよね。アプリケーションを開発しようとしているのは、その成果物によって実現したい何かがあるはずなので、そういったプロジェクトの根幹部分を書いてみましょう。

〇〇を作るため(what)でも良いと言えば良いのですが、それを作らなくてもプロジェクトの目的が達成できるだとか、目的をより忠実に達成するためには実は〇〇を作るより××の方が効果的だったみたいな事態も起こり得ますからね。なので「なぜそのプロダクトを作りたいのか」というwhyにフォーカスした方が良いのではないかと思います。

余談ですが、趣味で個人開発するときなんかは「触ってみたい技術で遊ぶため」みたいな浅いものを掲げてしまうこともあります。

エレベーターピッチ

次はエレベーターピッチです。これはプロダクトの価値にフォーカスしたスライドですね。

といったクリティカルな部分を明確にしなければなりません。

どの空欄を埋めるにしてもプロダクトの価値をしっかり理解していないといけません。プロダクトの発案者であれば的確に埋めることができるかもしれませんが、開発チームメンバーはなかなか悩むのではないでしょうか。

しかし、これによってプロダクトに対する認識の齟齬が明らかになるかもしれませんし、気づいていなかったプロダクトの価値に気づくことができるかもしれません。また、自分で考える・メンバーと合意して一つにまとめるという過程で、参加者一人一人がプロダクト像を腹落ちさせることができます。やはり自律的なチーム作りに一役買うわけですね。

やらないことリスト

やることリストではなく、やらないことリストです。やることを列挙したら無限ですからね。

このプロダクトに何が必須で何は不要で、何はプロジェクト中に判断したいかということを明確にしましょう。「初回リリース時点では」という前提を置いても良いかもしれません。議論・合意できるのであればプロジェクト中に変更するのも全然OKです。

「いつオンライン決済機能が搭載されるんでしょうか?」「え、工数かかるので他の機能を優先するって言ってませんでしたっけ?」「いや、でもこれがないとユーザーに使ってもらえないし…」なんて認識の齟齬がプロジェクト終盤に判明したりすると困っちゃうので、これを避けるためのものです。

やるべきことに集中するためにも、当面は考えなくて良いことをここで明確にし、合意しておきましょう。

トレードオフスライダー

プロジェクト開始前から不測の事態を想像するのは難しい(予測できないから不測なわけですが)ので、もし何かが起こった場合、チームとしてはどんな方針で対応するのか、といったことをあらかじめ話しておくためのスライドです。

雛形には多くの要素が記載されていますが、mofmofでは3項目だけピックアップして考えることもよしとしています。

これだけ話しておけばとりあえず不足はありません。品質については、「品質」というワードの定義をチームで合意しないと認識の齟齬につながるのでmofmofでは削除するようにしています。

これらはトレードオフ、すなわちどれかを選ぶなら他のどれかを手放さざるを得ないという関係にあります。期間を縮めるのであれば予算を増やして開発人数を増やしたり、予算が出せないのであれば短期間かつ機能を削らないといけなかったと、全てを取ることは不可能です。

プロジェクト開始時には妥当な計画を立てるものですが、プロジェクト進行中に何が起きるかはわかりません。どうしても何かしらの判断を下し、進行方法を考えなおさないといけない場面は出てきます。例えば考慮していなかったユースケースに対応しないといけなくなったり、当初は軽く考えていた機能の開発が思いの外大変で進捗が芳しくなかったり。そういった場面でチームは何を優先的に選択し、何に妥協することが可能なのか。そういった判断の指針をここで合意しておくためのものになります。

実際のプロジェクトで活かすために

以上にしっかりと取り組めば、やらなかった場合と比較してかなり良いスタートダッシュが切れるのではないでしょうか。ただし、もちろん最初に作ってそれっきりでは効果を最大限に発揮できません。また、インセプションデッキは最初に決めたものが絶対!というものでもありません。

プロジェクトの要所要所で確認し、現状と相違があれば都度アップデートし、判断に困ることがあれば即座に見返すことができるようにしておくことが重要です。

エンジニアとしてはやや専門外な領域となるため大変な部分もあるかと思いますが、言われたものを作るだけになるよりは、これから作るものがどんな価値を提供するのかを理解しておくことはモチベーションに大きくつながると思います。そうでなくても手戻りや認識の相違が減らせる、プロダクトの根本的な価値にエンジニアがコミットできるという点はプロジェクト進行上とても心強いものです。

そのため、mofmofでは(あくまでもオプションプランではありますが、)開発着手前に設計プランとしてこのインセプションデッキに取り組む時間を設けているほどです。

等々実務的な益を語ってきましたが、そういったものを抜きにしてもインセプションデッキを考えること自体が楽しいので、是非是非やってみてください。

以上、インセプションデッキのあれこれでした。