ソフトウェア開発の羅針盤、インセプションデッキをつくってみよう

こんにちは。みらい翻訳でバックエンドエンジニアをしている原と申します。社内ニックネームはchanceです。

「Mirai Translator®︎」のバックエンドのアーキテクチャ刷新チームでリードエンジニアをしています。

今回は私たちのチームで実践したインセプションデッキの取り組みをシェアします。

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

ご存知の方も多いかと思いますが、簡単におさらいです。

インセプションデッキとは、「10個の"手強い"質問に答えることで、プロジェクトの方向性の認識を合わせる」というプラクティスです。

日本語版もあります。 github.com

書籍『アジャイルサムライ』によって広く認知されたものですが、アジャイルに限らず、どのようなプロジェクトでもとても有用なものだと思います。

参考書籍『アジャイルサムライ――達人開発者への道』 www.ohmsha.co.jp

10個の質問は場合によっては意見の衝突を生んだり、誰かの期待に沿わない結果となったり、まさに"手強い"ものになっています。しかし、インセプションデッキの作成を通してチームで会話をすることで、メンバー間の認識のズレを理解し、共に取り決めた内容を言語化して残しておくことができます。ここで重要なのは「資料を作成すること」よりも「会話をして共通理解を得ること」です。

なぜやろうと思ったのか

プロジェクトの背景にある課題や目的、スコープや優先度などは、チーム内のメンバーでも意外と認識があっていないものです。プロジェクト開始時期であればなおさらです。前提となるこの辺りの認識にズレがあると、打合せなどでも会話が噛み合わず、生産的な議論が阻害されます。

"言わなくても伝わる"ような間柄は家族や友人としてはとても素敵ですが、仕事においては少し心許ないですね。

特に私たちの取り組んでいるアーキテクチャ刷新というテーマは、様々な背景から「やった方がいい」ことが無数に出てきます。そこで、期間やスコープを区切って「今やること」と「今ではないこと」をしっかり区別して、メンバー全員が理解することが必要不可欠だと思い、インセプションデッキを導入することにしました。

私たちのインセプションデッキ

インセプションデッキについての解説は、すでに多くの素晴らしい記事があります。そのため、今回は基本的な解説ではなく、私たちがどのように工夫したかをご紹介できればと思います。

まず始めに、10個の質問内容についてですが、テンプレートとして広く紹介されているものは、英語の和訳であることも含めて質問にユーモアが効いていて、直感的でない箇所があるかなと感じていました。（意味を理解すれば絶妙なワードチョイスで、例えば「ステークホルダー」のようなビジネス用語より「ご近所さん」の方が仲間意識が表現されていると思います。全くもって批判ではないので悪しからずです。）

ユーモアの苦手な典型的日本人である私は、各質問に明快な（その代わり無機質な）副題を付けました。

#	Agile Samurai表記	アジャイルサムライ和訳	副題
1	Why are we here ?	我われはなぜここにいるのか	プロジェクトの目的は何か？
2	Elevator pitch	エレベーターピッチ	簡潔に説明するとどのようなプロジェクトか？
3	Product Box	パッケージデザイン	どんな価値が得られるか？
4	NOT list	やらないことリスト	どこをスコープとするか？
5	Meet the neighbors	ご近所さんを探せ	関係者は誰か？
6	Show solution	解決案を描く	どんなアーキテクチャになるか？
7	Up at night	夜も眠れない問題	予想されるリスクと対策はあるか？
8	Size it up	期間を見極める	期間はどのくらいを見込むか？
9	What's going to give	何を諦めるのか	優先すべき指標は何か？
10	What's it going to take	何がどれだけ必要か	必要リソースはどの程度か？

また、スライドではなくMarkdownの箇条書きと表組みで表現しました。
スライドの場合は要点がまとまってはいるものの、後から見直した際に情報が少ない（結局のところ、別途説明が必要になる）と感じたためです。箇条書きにして話し合ったことも残しておくことで、後で見返した時にも当時の状況を思い出しやすくなります。

各章のポイント

各項目について私たちが何に重きを置いて考えたのかを簡単にご紹介します。

1.プロジェクトの目的は何か？ - Why are we here ?

『今回、我々は何を実現するために活動するのか』

目的は何であるか を具体的に宣言します
同時に、つまり何を目的としないと言いたいのか も言語化しました
- これはとても辛い決断ですが、後から揉めないためにもここでしっかりと認識をあわせたいです。

2.簡潔に説明するとどのようなプロジェクトか？ - Elevator pitch

『2センテンスでプロジェクトの概要を表現する』

エレベーターピッチとは、エレベーター同乗中にできる程度の端的なプレゼンのことです
テンプレートの穴埋めが和訳よりも英語の方がニュアンスがしっくりきたので、英語の方でご紹介します

検討項目	英語
誰のためか？	For (XXX)
↑の人はどういうニーズがあるか？	who (XXX),
今回取り組むプロダクト名	the (XXX)
どういったものか？（「1.」で決めた目的など）	is a (XXX),
どう嬉しいものか？（「3.」で決めた価値など）	that (XXX).
代替手段として何があるか？	Unlike (XXX)
代替手段とは何が違うか？	our product (XXX)

3.どんな価値が得られるか？ - Product Box

『何を作るかではなく、作ったものによってもたらされる価値はなにか』

「商品パッケージのデザイン」はあまり馴染みがない発想なので、お堅く書きました
まず「何を作るか」を出して、それが「どんな価値を生むのか」を話し合いました

#	機能 (Features)	価値 (Benefits)
1	どんな機能	どんな価値
2	...	...
...	...	...

4.どこをスコープとするか？ - NOT list

『（もちろん）どれもやるべきなのだが、今やるのか、次にやるのかを決める』

特に「やらないこと」の方に気を使って、「今はやらない理由」と「ではいつやるのか」も併せて書きました
それを期待していた人にとって、上記はとても気になる内容だからです

5.関係者は誰か？ - Meet the neighbors

『関係者全員が仲間になり、相談しやすい状態にする』

関係するチームと主な役割を書き出して、早々に相談します
プロジェクトの成功に必要な人たちとは、早くから仲間であるべきです

6.どんなアーキテクチャになるか？ - Show solution

『どのようにシステムを構築するつもりか、簡潔な図で表現する』

既に合意しているつもりでも、目で見て確かめるのが重要です
図にすると、実は認識が違っていたり、思わぬ懸念に気付いたりします

7.予想されるリスクと対策はあるか？ - Up at night

『チームにとって取り組む値打ちのあるリスクを見極める』

起こりうるリスクを書き出してみます
自分たちが取り組めそうなものがあれば、対策を検討します

8.期間はどのくらいを見込むか？ - Size it up

『計画は見込みであり、事実を計画にフィードバックすることが重要』

スケジュールを可視化することで、期間に対する意識を持てるようにします
現時点での最大限の根拠を用いて、「確からしいあてずっぽう」とします

9.優先すべき指標は何か？ - What's going to give

『どの要素も大切に考えているが、より高い優先事項は何かを見極める』

「トレードオフスライダー」で優先事項を可視化します
優先度が低いものが重要ではないという意味にはなりません
- 重要でないものは、ここの議題に上がってきません
QCDとスコープを検討対象とします
- 大抵は、QCDを固定し、スコープを調整します
- 今回はスコープの項目として「4.」で挙げた「やること」を使いました
少し細かいですが、10段階評価としました
- 品質は、最優先で10
- コストは、チームの人数は固定ということで9
- 納期を5に置いて、スコープ（やること）を納期より優先すべきかどうかで判断しました