第3章 みんなをバスに乗せる
スタートを切る前からだめになってしまうプロジェクトは実に多い。主な理由は次の2つだ。
.答えるべき問いに答えられない。
.手ごわい質問をする勇気を持てない。
本章では、プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキを紹介する。インセプションデッキは10の課題で構成されている。いずれの課題も、プロジェクトを開始する前に聞いておかないとまずい質問ばかりだ。インセプションデッキを活用すれば、プロジェクトというバスに然るべき人が乗っているか、バスが然るべき方向を向いているかを、プログラマが最初の1行目のコードを書き始めるよりもずっと前にしっかりと確認できるようになる。
3.1プロジェクトがだめになるのはなぜか
プロジェクトが新しく始まった時点では、その成功について思い描く姿は人によってそれぞれ大きく異なるものだ。
これはプロジェクトにとって実にまずい状況だ。なぜなら、同じ言葉や言い回しを使って欲しいものを説明しているつもりなのに、いざソフトウェアができあがってみると、自分たちが実はお互いにまったく違うことを考えていたことに気づく羽目に陥るからだ。
ここでの問題は、プロジェクトの開始時点で関係者の認識が揃っていないことじゃない（それはむしろ自然なことだ）。問題は、関係者全員でプロジェクトについて話し合うよりも前にプロジェクトを始めてしまうことにある。
チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがだめになるんだ。
そうならないためには次の2つを満たすための工夫が必要だ。
.ゴールやビジョン、プロジェクトの状況や背景についてチームでよく話し合っておくこと。そうすれば、チームは状況に応じて適切な判断を下せる。
.ステークホルダーに情報を提供すること。彼らにはプロジェクトを続けるかどうかを決断するための材料が必要だ。
これを実現するには、尋ねたり答えたりするのがためらわれるような、手ごわい質問をするしかない。
3.2手ごわい質問をする
オーストラリアで仕事をしていたときに、たまたまThoughtWorks社*1のトップセールスの助手席に座る機会があった。その紳士の名前はキース・ドッズ。キースは私にいろんなことを教えてくれた。そのうちのひとつが、新しく契約を交わしたり何かを販売し始めたりするときに、手ごわい質問（Tough Question）をすることの重要性だ。
契約もプロジェクトも、まだこれから始める段階であれば、終盤とは違っていろんなことを質問をする余地があって、しかも質問するのに大した手間もかからないことはわかってもらえると思う。たとえば、次のようなあけすけな質問だって許されるだろう。
.どれぐらい経験を積んでいるチームですか？
.では、あなた自身はこの手の仕事の経験はありますか？
.ご予算はどれぐらいですか？
.このプロジェクトを統括するのはどなたですか？
. 2人のアナリストに30人のプログラマという体制で何も問題ない、と仰るのでしょうか？
.お尋ねしたいのですが、過去のプロジェクトで、オブジェクト指向の経験がほとんどない新人開発者ばかりのチームを率いて、レガシーなメインフレームのシステムをアジャイル手法を使ってRuby on Railsでリプレイスするのを成功させた事例はございますか？
アジャイルプロジェクトを始めるときも、これと同じだ。手ごわい質問は先に済ませておこう。それを手助けするツールがインセプションデッキだ。
3.3インセプションデッキのご紹介
インセプションデッキは、君のプロジェクトの視界をさえぎる濃い霧の向こうを照らすフラッシュライトだ。インセプションデッキは10の手ごわい質問と課題から構成されており、いずれの課題もプロジェクトを開始する前に聞いておかないとまずい質問ばかりだ。
ThoughtWorks社では、プロジェクトのスムーズな開始をサポートするのにインセプションデッキをよく使っていた。エクストリーム・プログラミングやスクラムのようなアジャイル手法は、プロジェクト憲章*2の作り方は教えてくれないのだ。現状分析と要件収集に6ヶ月も費やすことを正しいとはとても思えなかったが、さりとてその手軽な代替案もなかった。こうした状況を受けて、ロビン・ギボンズがインセプションデッキの原型を考え出した。インセプションデッキは、プロジェクトを核心まで煮詰めて抽出した共通理解を、開発チームだけじゃなく、より広範囲なプロジェクト関係者全員（いわゆるプロジェクトコミュニティ）へ手軽に伝えるためのツールだ。
3.4インセプションデッキの仕組み
インセプションデッキの背後にある考えはこうだ。「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ」と。
チームでこなしたインセプションデッキの課題の成果をそれぞれスライドとして並べていくと、どんなプロジェクトなのかということがだいたいわかる（普段私はこれをPowerPointを使ってやっている）。このプロジェクトは何であって、何でないのか。価値を届けるためにどこに力を注ぐべきか。などなど。このスライドの組（デッキ）がインセプションデッキだ。
インセプションデッキの作成に参加するのにふさわしい人物は誰か？プロジェクトに直接関係する人物なら誰にでもその資格がある。顧客、何かしらかかわりのあるステークホルダー、チームメンバー、開発者、テスター、アナリストなど、プロジェクトを円滑に進めていくことへ具体的に貢献できる全員が該当者だ。インセプションデッキの作成にあたっては、ステークホルダーを巻き込むことがとても重要だ。というのも、インセプションデッキは我われ開発チームだけのものではないからだ。インセプションデッキはステークホルダーにとっても役に立つ。「それでもなお、プロジェクトをやるのか？」というきわめて重要な決断を下すうえで有用な情報を提供してくれるからだ。
インセプションデッキの作成に要する期間は、数日から2週間程度を見込んでおけばよいだろう。インセプションデッキは、プロジェクトの今後半年間の見通しを立てるのにも向いているが、プロジェクトの状況や方針に大幅な変更があれば、そのタイミングで改訂しなければならない。
インセプションデッキは実際に使われる、生きた成果物だ。だから、作りっぱなしで棚にしまっておくようなものじゃない。仕事場の壁に貼り出すのがいいだろう。ときどきそれを眺めて思い出そう。何を作ろうとしているのか。そしてそれはなぜなのか。
改めて言うまでもないかもしれないが、本書で紹介しているインセプションデッキも単なるとっかかりにすぎない。他にも適切な質問や課題はないか、自分でも考えてみよう。君がプロジェクトを始める前にはっきりさせておきたいと思っていることは何だろう？
私がこれから紹介するインセプションデッキは出発点だと考えよう。盲信しちゃだめだ。ためらうことなく自分たちに合わせて改変してほしい。
インセプションデッキの10の設問と課題のそれぞれを詳しく見ていく前に、まずは一覧にして紹介しておこう。課題のそれぞれに簡単な説明もつけておいた。
1.我われはなぜここにいるのか？
何のために自分たちはチームを組むのか。自分たちの顧客は誰なのか。そもそもこのプロジェクトが始まった理由は何なのか。こうしたことを再確認する。
2.エレベーターピッチを作る
30秒以内に2センテンスでプロジェクトをアピールするとしたら、何を伝えるべきだろうか？
3.パッケージデザインを作る
何気なくめくった雑誌のページに、自分たちのプロダクトやサービスの広告が載っているとしたら、それはどんな内容がいいだろうか？それからもっと大事なのは、その広告を見た人は君のプロダクトを買いたくなるだろうか？
4.やらないことリストを作る
プロジェクトで実現したいことというのはかなり明確になっているものだ。それと同じかそれ以上に、やらないこともはっきりさせよう。そしてそれをわかりやすく一覧にするんだ。
5.「ご近所さん」を探せ
「プロジェクトの関係者」に含まれる範囲というものは、自分たちが思っているよりもずっと広いものだ。そうした「ご近所さん」を招いて、コーヒーでもごちそうしながら自己紹介ぐらいしてもいいんじゃないだろうか。
6.解決案を描く
チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描こう。
7.夜も眠れなくなるような問題は何だろう？
プロジェクトで起きる問題のなかには、考えることすら恐ろしいものだってある。だが、あえてそうした心配事について話し合おう。どうすれば最悪の事態を避けられるだろうか？被害を最小限に食い止める方法はあるだろうか？
8.期間を見極める
どれぐらいの期間が必要なプロジェクトだろうか？ 3ヶ月？半年？それとも9ヶ月？
9.何を諦めるのかをはっきりさせる
プロジェクトにはいくつか操作可能な要素がある。期間、スコープ、予算、それから品質。現時点で譲れない要素はどれだろう？譲ることになるのもやむを得ない要素はどれだろう？
10.何がどれだけ必要なのか
期間はどれぐらいかかりそうか？コストは？どんなチームならプロジェクトをやり遂げられるだろうか？
インセプションデッキはこの後に続く2章を割いて説明する。まずは第4章「全体像を捉える」（p. 51）でプロジェクトの背後にある「なぜ」をじっくり考える。それから第5章「具現化させる」（p. 73）で「どうやって」を詳しく検討していく。
じゃあまず、プロジェクトの「なぜ」から考えていこう。
