Mirai Translate TECH BLOG

株式会社みらい翻訳のテックブログ

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

こんにちは。みらい翻訳でバックエンドエンジニアをしている原と申します。社内ニックネームは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に置いて、スコープ(やること)を納期より優先すべきかどうかで判断しました
項目 1 2 3 4 5 6 7 8 9 10
品質
コスト
納期
...
...

10.必要リソースはどの程度か? - What's it going to take

『どのようなチームで、どういう期間で、どれだけの費用かを端的に表現』

  • ここはそもそも決まっていることも多いかもしれないです

やってみてどうだったか

案の定、話してみるとチーム内でも認識の相違があり、特に「目的は何なのか」「やることの優先度」などは議論が盛り上がりました。

チームとして活動するには、全員が同じ方向を向いて同じゴールを目指すべきです。誰かが一方的に目的とゴールを決めてしまうのではなく、メンバーそれぞれの価値観から「どうあるべきか」「なぜそう判断するのか」を議論することができたので、インセプションデッキをやってみてよかったと思います。

現在プロジェクト進行中ですが、判断に迷った時にはインセプションデッキを見返すようにしています。

今回の反省点として、本来は最初から全員で話しながら作ることが重要だと理解した上で、時間の都合で最初に一人である程度作ってから議論するスタイルを取りました。ある程度はスムーズに会話が進む反面、どうしても先入観が働いてしまったりすると思うので、機会があればみんなで話しながらも作ってみたいです。

まとめ

今回は私たちのチームの工夫を取り入れたインセプションデッキを紹介しました。

プロジェクトを効果的に進める上で、目的やゴールを明確にすることが重要なのは言うまでもありません。

冒頭の繰り返しになりますが、インセプションデッキの目的はきれいな資料を作ることではなく、チームのメンバーがお互いの意見を交わして会話をすることです。

10個の質問すべてができなくても、まずは1つ2つからでも取り組んでみるのもよいかと思います。一部だけ実施するとしたら、個人的なおすすめはこちらです。

  • 1.プロジェクトの目的は何か? - Why are we here ?
  • 3.どんな価値が得られるか? - Product Box
  • 4.どこをスコープとするか? - NOT list
  • 9.優先すべき指標は何か? - What's going to give

この記事から何か少しでも、みなさまの参考になれば幸いです。長くなってしまいましたが、最後までお読み頂きありがとうございました。

みらい翻訳ではエンジニアを募集しています

みらい翻訳ではバックエンドシステムのアーキテクチャ刷新をいっしょに推進してくださるメンバーを募集しています。ご興味のある方は下記リンクからお問い合わせください。

miraitranslate.com