インセプションデッキとは？ アジャイルを成功させる「10の質問」

はじめに

アジャイルとウォーターフォールでは開発手法が異なりますが、いずれも「何を作るのか」の方針は必要です。
ウォーターフォールでは「プロジェクト憲章」が該当しますが、アジャイルでは「インセプションデッキ」で方針を明確にすることが多いです。

インセプションデッキとは、アジャイルの教科書とも言われる「アジャイルサムライ」が提示する、プロジェクトを明確にするための10個の質問と課題です。
これはプロジェクト開始時に作成しますが、開発中も更新したり都度参照することでプロジェクトの判断基準にします。

ここではインセプションデッキを作成するときのポイントについて解説します。

インセプションデッキ作成の注意点

ステークホルダーを巻き込むこと

インセプションデッキの作成で最も重要なのは、顧客などステークホルダーを巻き込むことです。
ここでいうステークホルダーとは、例えば開発チーム、顧客、プロジェクトに関わる部署など多岐にわたります。

特にアジャイルでは顧客と協同作業で進めることが重要になってくるので、顧客側もプロジェクトへ主体的に参画してもらうため、その動機付けとしてインセプションデッキの作成から参画してもらうことは有効です。
顧客によってはアジャイルの経験不足により、主体的に参画することに難色を示す場合もあるかもしれませんが、それでも理由を説明して理解してもらいます。
ここで納得してもらえないようでは、そもそもプロジェクト開始後も主体的に参画してもらうことは難しいでしょう。

インセプションデッキを作成したら、上層部やオーナー、スポンサーなどプロジェクトに意見できるステークホルダーに説明します。
インセプションデッキはステークホルダーに説明しやすい構成となっているので、積極的に活用するとよいでしょう。

見やすい場所に置く

アジャイルプロジェクトを推進していると、次の進め方に悩んだり立ち止まることがあります。
進め方の判断に迷ったらインセプションデッキを振り返ることで当初の目的を再確認することができます。

しかし、インセプションデッキが作成時から見られず埃をかぶっている状態では、困っているときに振り返ろうという話にはなりません。
そのためにも印刷して壁に貼るなど、日頃からインセプションデッキが目に入る環境にすると効果的です。
もしリモート作業が中心の場合は、打ち合わせで困ったらインセプションデッキを開くというルールを作ることも有効です。

インセプションデッキの作成

それではインセプションデッキの作成ポイントについて解説します。
アジャイルサムライの「インセプションデッキ　テンプレート」からテンプレートを入手できるので、そちらも参考にしてください。

インセプションデッキには10種類ありますが全てを作成する必要はありません。
プロジェクト特性を考慮したうえで使いたいものを選択すると良いでしょう。

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

プロジェクトは、ある目的を実現するための活動です。
その目的を明確にすることは重要であり、ここが間違えると期待する成果につながらないでしょう。
重要なポイントなので、それっぽい理由を並べるだけでなく背景を調査したり、様々な人の意見を聴くことでイメージを鮮明にします。
ユーザの現場を見学したり、ステークホルダーへのヒアリングやインタビューを行うなど、目的の裏に真の意図が隠れていないか、についても調べます。

人によっては様々な意見や考え方があるでしょうが、ステークホルダー間で合意を取っていきます。
この合意の中で意見を取捨選択していくことになるかもしれませんが、それを最初に行うことが重要です。
プロジェクト遂行中に様々な意見が出てきても対処できない事態になるかもしれません。
そうなると現場から不満の声があがることにもつながります。

エレベータピッチ

エレベータピッチとは、エレベータに乗っている30秒程度の時間でプロジェクトが説明できるくらい、プロジェクトのポイントを整理するために作成します。
ここで必要なのは説明を短くすることではなく、様々な情報をそぎ落としてコアの部分だけを残すことで目的を明確にすることができます。
またコアの部分を検討するのは容易でなく、ステークホルダー間で様々な議論をすることになります。
その議論により、プロジェクトへの深い理解につながるでしょう。

パッケージデザイン

プロジェクトの成果をアピールするためのパンフレットのようなパッケージデザインを作成します。
そこで成果物のキャッチコピーを考えるわけですが、商品をアピールするためには「誰に」「どのような効果があるのか」を伝える必要があります。
どのような訴求をすれば相手に魅力的に感じてもらえるか考えることは、どのような機能が求められているのかを考えることです。
実際に作成したパッケージデザインを使用して営業するわけではないのですが、ステークホルダーとワイガヤして考えると楽しいですし、新しい気づきを得ることもあります。

やらないことリスト

やらないことリストは、ウォーターフォール開発でいうスコープマネジメントに近いです。
アジャイルでは「あれも、これも」と作業範囲が広がりやすいのですが、プロジェクト特性で範囲外にすべきことを明確にすることで制御します。
スコープが明確になっていることで必要のない検討や調査を回避することもできます。

やらないことリストでは「やる」「やらない」「後で決める」を設定します。
そこでは開発チームだけでなく顧客にも参加してもらうことが大切です。
ちなみに全て「やる」「やらない」で分類できるとよいですが、プロジェクトを進めてみないとわからないケースもあります。
そういったものは無理に「やる」「やらない」でわけるのでなく「後で決める」に分類すると良いでしょう。
ある程度進んで判断できるようになったら、その時に検討すればよいです。
検討結果は、やらないことリストに反映していきます。

「ご近所さん」を探せ

これはウォーターフォール開発におけるステークホルダーマネジメントに該当します。
プロジェクトに関係するステークホルダーを洗い出し、コミュニケーションをとるべき相手が誰なのか確認します。
この洗い出しには組織の体制や仕組みに詳しい人にヒアリングすると良いでしょう。

ステークホルダーが整理されたら、対象の相手に声をかけて関係構築します。
必要になったタイミングで、いきなり相談しても相手は困ることもあるので、プロジェクト開始くらいであらかじめ声をかけておくと良いでしょう。
調整や相談が必要になる時期を伝えておくことで相手側も準備することができます。
良好な関係を築くことができれば尚良いです。

解決案を描く

システム開発のプロジェクトではアーキテクチャ概要がわかる資料を作成します。
ウォーターフォール開発のプロジェクト計画書であればシステム構成図に該当するドキュメントです。

そこでの注意点は次の2つです。

概要レベルで作成する
資料は詳細まで作成せず、概要がわかる程度に留めます。
この手の資料は作り始めると深堀してしまうことが少なくありませんが、そこで作業工数を使ってはアジャイル特有のスピードが出せません。
ステークホルダーとイメージを共有できる概要レベルでよいです。

気になる点・リスクを記載する
不明点や懸念点、リスクと思われる情報を図に書き込みます。
きれいな資料を作成することが目的でなく、ステークホルダーと共有することが大切です。

夜も眠れない問題

リスク管理のことであり、プロジェクトで想定されるリスクをステークホルダーと協議して洗い出します。
ウォーターフォール開発と同様に、アジャイルでもリスクを想定して対策を練ることは重要です。
ただしウォーターフォール開発のように細かく分析したり、リスク対策の予算とった費用計算までは行いません。
リスクの顕在化、または予兆が出た場合、その対策を検討して作業タスクに組み込まれます。
リスク対策の計画に時間を使うのではなく、常にリスクを意識しながら作業に注力します。

期間を見極める

ウォーターフォール開発におけるマスタスケジュールに該当しますが、アジャイルでは工程という概念がないので、リリースまでのざっくりとしたスケジュール計画を設定します。
さらに、要求される機能を全て完了することを確約するスケジュールではなく、目安です。

もしスケジュールが厳しくなった場合、このスケジュールに間に合うよう機能を調整するか、または機能を充足するために期間を調整するのか検討します。
そこでは、次に説明する「何を諦めるか」で用意するトレードオフ・スライダーを使います。

補足ですが、アジャイルプロジェクトの作業期間が長いのはリスクが高いです。
ただでさえアジャイルは先行きが不透明な状態で進めるので、１年などの長期プロジェクトでは気づいたらコストがオーバーしていた、ということになりかねません。
やらないことリストを活用しながら、６か月程度でプロジェクトを区切って進めるとよいです。

何を諦めるのか

プロジェクトを進めていくとスコープ範囲の増加、当初予定より時間やコストが不足することがあります。
全ての目標を達成するための努力や工夫は必要ですが、それが現実的でない場合の調整で使用するのがトレードオフ・スライダーです。
プロジェクトにおいて「時間」「コスト」「品質」「スコープ」などの要素に優先度をつけて、調整が必要な場合に何を諦めるのか設定します。
とはいえ「時間」「コスト」「品質」の優先度を下げるのは現実的でない場合が多いです。
実質的には何かあれば「スコープ」を調整対象とするための布石として使用することになると思います。
実際に困ったときにトレードオフ・スライダーを検討するのではなく、プロジェクト開始前にステークホルダーと合意を取ることが大切です。

何がどれだけ必要か

ウォーターフォール開発における要員計画とコストマネジメントに該当します。
ウォーターフォールでは各工程の成果物作成に必要な工数をベースにコストを算出しますが、アジャイルでは確保する要員と期間でコストを算出します。

まずアジャイルプロジェクトを遂行するためのチームの役割を設定します。
開発者やテスターなどの役割はわかりやすいのですが、顧客などの役割もここで定義します。
この顧客とはスクラムでいうプロダクトオーナーに該当し、作成するプロダクトに対する責任を持ちます。
顧客によってはアジャイルについて理解不足の場合もあるので、役割を十分に理解してもらいプロジェクトに積極参加してもらうよう調整します。

ここで役割を設定したら、「期間を見極める」で定義したスケジュールの期間を使ってコストを算出します。