インセプションデッキの効能

エス・エム・エスキャリアの各サービスは日々変化する環境の中で素早いPDCAを回し続けているため、システム側も早いサイクルで開発やリリースを継続することが求められています。
そんな中で開発チームもごく自然にアジャイルの状態を目指してきました。
サービスごとに開発の進め方は様々なのですが、私のチームでの取り組みを少しずつご紹介していきます。

今回はアジャイルプロジェクトで採用されるインセプションデッキについてです。
私のチームでは看護師さんに日常的に使っていただけるようなプロダクトを複数制作しているのですが、それぞれにインセプションデッキを用意しています。

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

インセプションデッキに関する説明は様々なサイトにありますのでここでは割愛させていただきますが、簡潔なプロジェクト憲章のようなものです。
一番詳しくは書籍「アジャイルサムライ」で紹介されています。
そのプロジェクトの目的、背景、優先度、リスクなどに関する10個の質問とその回答から成り、みんなで作り、共有されていることもポイントです。
インセプションデッキはこんな症状を予防してくれます。

  • チームのメンバーは何だかよく分かっていないけどプロジェクトが始まってしまった。
  • 始まったは良いけれど何を何のために作っているのか分からなくなってしまう。
  • やらないと言っていた(気がする)ことがプロジェクトに追加されている。
  • 品質にこだわって作っていたら「リリース期限に間に合わないよ!」と言われてしまう。

などなど・・・
どれも発症するとプロジェクトの成否に関わる重大なリスクですね。

実際には

  1. 我われはなぜここにいるのか
  2. エレベーターピッチを作る
  3. パッケージデザインを作る
  4. やらないことリストを作る
  5. 「ご近所さん」を探せ
  6. 解決案を描く
  7. 夜も眠れなくなるような問題は何だろう
  8. 期間を見極める
  9. 何を諦めるのかをはっきりさせる
  10. 何がどれだけ必要なのか

といった10の質問へみんなで回答して作り上げていくのですが、ここではそのうちの幾つかを私達が実践した時の経験を交えてピックアップしてみます。

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

これはプロジェクトの目的や背景を認識するためのもので、非常に重要なことです。
私たちは何のためにここに集まっているのか?なんのためにプロジェクトをやるのか?
ここが曖昧だとこの先のことが決まらなかったり、迷走していきます。

私達の場合、プロジェクトは事業の戦略に紐づくことがほとんどです。
事業戦略の中におけるプロダクトの位置付けを知り、今回は何を達成することを目的としているのかを皆で共有します。
ここで議論になることは多いのですが、それはとても良いことだと思います。
「誰かがやりたいからやる!」で推し進めるのではなく、メンバー間で議論が行われている方が健全ですし、出来上がった目的に納得感も生まれます。
オーナーはメンバーからの事業に関する疑問に答え、みんなでプロジェクトの向かうところを再確認します。
この議論の中でスコープや優先順位の話になることもしばしばあります。

やらないことリストを作る

ここでは「やること」と「やらないこと」を決めます。
「やりたいこと」はたくさんあると思いますが、限られた時間とお金の中で「やれること」は限られています。
また、プロジェクトの目的に合わないものも混ざっているかもしれません。
みんなで話し合いながら、「やりたいこと」から「やらないこと」を選別します。

やらないことに移すのは少し勇気が必要なこともありますが、迷う時は出来るだけ戦略やデータを元にした決断をするようにしています。
例えばサイトをリニューアルするプロジェクトではこれまでのコンテンツの利用状況を詳しく調べて、利用度の低いものは「やらないこと」に移すようにしています。ユーザーの意見を聞いたり、競合サービスの状況と照らし合わせて判断することもあります。
オーナーだけが「やらないこと」を出し切ったと思っても、開発チームから見ればまだ足りていないことも多いです。あとで「これが含まれていないのはおかしい!」「そんなの作る話だったっけ?」とならないように、オーナーも開発チームも合意の上で実施したいところです。

「ご近所さん」を探せ

「関係者を洗い出しましょう」という意味で、これも非常に重要です。
特に部署が複数存在して長年に渡る複雑な関係が存在していたり、外部に業務を委託していたりすると尚更です。社外の関係者には特に気を使わなければなりません。

例えば私達がサイトをリニューアルする際にはこんなご近所さんがいました。

  • 社内の別サイトがAPIで情報を取得していた。
  • サイトが別のスマホアプリと情報を共有していた。
  • 社外の業者に投稿の監視を依頼していた。
  • 別のサイトと会員情報を共有していた。
  • 他の部署に各サイトのデータの集計やパフォーマンスをウォッチしているチームがあるため、DBの構造を変えるなら共有が必要。
  • インフラ担当者から協力を得る必要がある。

関係者の存在をプロジェクトの早い段階でしっかりと洗い出しておくことは大切です。
単純に自分たちの開発スコープに影響する場合もありますし、相手に対応してもらわなくてはならないこともあります。
オーナーは関係者にプロジェクトの内容を説明しながら、必要なリソースを確保してもらうお願いに回ることもあります。関係者とは有効な関係を築いておきたいところです。
プロジェクトの終盤になって「こんなところにも関係者が!」となると大変なのは想像に難くないですよね。周りをよく見渡して抜け漏れがないか確認しましょう。

何を諦めるのかをはっきりさせる

プロジェクトにおける以下の4つの主要な要素のうち、何を重視して何を諦めるのかを決めます。

もちろん「全て優先!」は出来ません。

  • 予算(予算内に収まる事)
  • 時間(期限通りにリリース出来る事)
  • 品質(高い品質、少ないバグ)
  • スコープ(機能を満たす事)

上記4つはコントロール可能ですが、事業の戦略に紐付いていると予算や時間は決まっている事が多いです。
予算や時間とトレード・オフの関係になるのが品質とスコープです。

品質はどこまでこだわるか?が大切になります。
優先度を下げなければならない場合、私たちは最低限守るべき品質のラインを開発チームで定め、まずはそこを外さないようにしています。
それには該当しないが例えばもっと美しく、もっと堅牢に、みたいなことはリリース後に時間を確保してリファクタリングしていきましょう、といったルールで進めています。

次はスコープです。オーナーは「プロダクトは育てるもの」という意識を持つようにして初期リリース時のスコープ縮小に努めています。スコープの縮小を事業の責任者に納得してもらうことは非常に難しいですが、「やりません」ではなく、「こういったプランでリリース後にプロダクトが成長していきます。」という話であれば聞いてもらえることが多いです。
また、プロジェクトの進行中に発生する様々な課題もスコープには加味しておく必要があります。

インセプションデッキの効能

10の質問のうち、4つほどの例を書いてみました。

インセプションデッキを用意すると、

  • 目的がわからない
  • そんなこと言ってたっけ?

が減ります。つまり認識のズレがなくなるわけです。
これだけでもメンバーのストレスが減り、出口の見えないプロジェクトで苦しむことが少なくなりますね。

実感したのはインセプションデッキは作る過程と、定期的な振り返りや手直しが大切だということ。
作成や編集時にはチームであれこれ議論しながら修正を加えることで、全体の共通認識が出来上がっていきます。
疑問点なども早い段階で洗い出せるので、後から出てきたかもしれないリスクを解消できます。

また、インセプションデッキに立ち戻る時間を意識して作る必要性も感じました。
今自分たちのやっていること、やろうとしていることがインセプションデッキの内容からずれていないか、定期的に問うことが重要なようです。協議の上でインセプションデッキそのものを見直して修正することもあります。
特に「何を諦めるのかをはっきりさせる」の内容は振り返りが大切です。
例えばリリースの期限を遵守するべきプロジェクトだが、気がついたら品質に拘り過ぎてしまっていた、といった事態に気づくこともあります。

そして立ち戻る場所であるインセプションデッキはメンバー間で共有されていることが重要です。
誰かが一方的に作り上げ、どこか目につかないところに存在していてはいけません。

これからプロジェクトが立ち上がる、今のプロジェクトがどうも迷走している。
そんな時はチームのメンバーでインセプションデッキを作ってみるのはいかがでしょうか。