いつの間にか、社内ですっかりインセプションデッキおじさんと化している中村です、こんにちは。
今日は、ヌーラボでのインセプションデッキの使われ方と、インセプションデッキを作る際に私が気をつけていることを紹介します。
インセプションデッキとは
インセプションデッキとは、プロジェクトの目的や背景といった全体像を捉え、プロジェクトの向かう先を表すためのドキュメントです。お偉いさんから一方的に降ってくるものではなく、メンバーみんなで考えて共通認識を合わせるのが特徴です。詳しくは、書籍「アジャイルサムライ」などを参照ください。
私とインセプションデッキの馴れ初めは、およそ1年前の2016年末のことです。外部アジャイルコーチとして入ってもらっているギルドワークス様からこういうものがあるよと教えてもらい、その当時走ろうとしていたプロジェクトに適用してみました。
それ以来、事あるごとに社内で展開していき、1年間で大小合わせて10以上のプロジェクトに導入してきました。1ヶ月に1回はデッキを作成している計算ですね😄 数だけでなく、インセプションデッキを有効に使ってプロジェクトのリリース計画を戦略的に考えることができた例もこちらで紹介してあるので、ぜひ読んでみてください。
ヌーラボにとってのインセプションデッキ
インセプションデッキの有用性は各所で言われていますが、ヌーラボにとってのインセプションデッキはどういうものだったのでしょう?2点ほど取り上げてみます。
プロジェクトの目的を考える機会に最適
ヌーラボではエンジニア率が非常に高く、全体的な技術力には強みがあります。その強みを最大限に活かしつつ、プロジェクトの目的や方向性を捉えるためのものとして、インセプションデッキは効果的でした。
エンジニア同士の会話だと、どうしても「What : 何を作るか」「How : どう作るか」に話が偏りがちになります。「Why : なぜ作るか」「for Whom : 誰のために作るか」をじっくり考えるために、インセプションデッキの中でも「我われはなぜここにいるのか」「エレベーターピッチ」を特に重視しています。
導入時のハードルが低い(低かった)
何か新しいアイデアを導入するときは、多かれ少なかれハードルが存在します。ただ、インセプションデッキについては、下記の理由から導入のハードルが低かったと感じています。
- 定められているテンプレートに従って、話したい内容に注力できる
- 時間の余裕があるプロジェクト初期に導入できる
1. は、プロジェクトについて何を話すべきかを一から自分たちで考えるのではなく、テンプレートに従って話していくことによって、導入時のコストがだいぶ低かったと感じています。もちろん、徐々に自分たちの状況に応じて調整・改善していく事が望ましいですが、まずは始めやすいというのも一つのメリットでしょう。
2. について、うまくいくか分からない新しい取り組みを、プロジェクト終了間際・リリース間際に試すのはなかなか難しいことです。ですが、まだ時間の調整をつけやすいプロジェクト初期での導入が適しているインセプションデッキは、その意味でも導入が容易でした。
インセプションデッキ作成時に気をつけていること
最後に、インセプションデッキを作るときに私が気をつけていることを紹介します。上で特に重視しているとお話した、「我われはなぜここにいるのか」「エレベーターピッチ」の2つを取り上げます。
我われはなぜここにいるのか
ここでは、少し粗があっても仮置きして次に進めることを意識しています。一番最初にやるであろうこの質問の段階では、メンバーがまだ探り探りなことが多く、活発な議論になりにくいことが多いです。そのため、議論が深まっていないために多少曖昧な言葉が残っていても、そのまま受け入れた上で次に進めています。
その代わり、次のエレベーターピッチ後にまた戻ってくることを前提としています。エレベーターピッチを話している中でかなり場があたたまって建設的な議論ができるようになってくるので、その雰囲気を持って「我われはなぜここにいるのか」⇔「エレベーターピッチ」間の整合性を取ります。
エレベーターピッチ
私がファシリテーターとして入る場合、特に大事な以下の3つの質問に絞って話し合います。
上記3つの質問に対して、以下の点を特に気をつけて進めます。
- ゆるふわな言葉をそのままにしない
- 質問間で整合性を取る
- トートロジーにならないようにする
1. について、ちょっと極端な例ですが「全てのユーザにとって、より便利な操作ができるようになります」という文を考えてみましょう。これはどのようなものにでもあてはまる、何の情報にもなってない説明です。こういう意見が上がってきた場合、丁寧に問いかけて言語化してもらうようにしています。
ある程度各質問に対する回答ができあがってきた後に、2. の整合性を確認します。1つ1つの回答は問題なくとも、整合性が取れていないこともよくあります。「このユーザは、この課題にほんとに困ってるのかなあ?」「このソリューションでほんとに課題を解決できるんだっけ?」などを言葉に出しながら、確かめていきます。
また、2 の派生ですがトートロジー、すなわち同じことを言ってないかも合わせて確認します。トートロジーになった場合、「課題ができないことによって、結果何が引き起こされているんだろう」という風に、課題の方を一段抽象度をあげて考えてみることが多いです。
最初はえいやでやってみたところもありましたが、やってみてこれはいい!というのを強く実感しました。あまりの感動に、他のプロジェクトで流用できるようにCacoo上でテンプレートを作って公開したぐらいです。
これからも、よりよいプロダクト・サービスを提供し続けていくために、いいものはどんどん取り入れていきたいと思っています。みなさんがやっているやり方で、これはいいというものは、ぜひぜひお聞かせください。