著者

Jonathan Rasmusson（ジョナサン・ラスマセン）

ジョナサン・ラスマセンは実務経験豊かな起業家であり、前職ではThoughtWorks 社のアジャイルコーチを務めていた。ジョナサンは世界をまたにかけたコンサルディングを行っており、一丸となって楽しみながら働ける現場の実現に尽力している。仕事以外では、息子のホッケーチームのコーチや、カナダの厳しい寒さのなかでのサイクリングを楽しんでいる。そうした多忙な暮らしの合間をぬって、自身のブログを通じて、自分自身のアジャイル開発の経験を読者と分かちあう活動を続けている。

監訳者

西村直人（にしむらなおと）

株式会社永和システムマネジメントサービスプロバイディング事業部アジャイルコーチ。スクラム道プロダクトオーナー。もっと仕事をアジャイルにしたいという思いを抑え切れず、2005 年に現職へ転職。そこから自分のチームや現場を軸にアジャイルなソフトウェア開発を実践してきた。2009 年に認定スクラムマスターの取得を機に、アジャイルコーチという肩書でお客様の組織や現場をアジャイルにするお手伝いをする事に情熱を傾けている。日本でもアジャイルなソフトウェア開発がもっと自然な形で定着してほしいと考え、ほんの少しでも力になればという思いから講演やコミュニティ運営なども行っている。心のマスター・センセイは、僕がこれまで関わってきた人達。

角谷信太郎（かくたにしんたろう）

株式会社永和システムマネジメントサービスプロバイディング事業部コミュニティマネージャ。日本Ruby の会理事。Asakusa.rb メンバー。20 世紀最後の年に『XP エクストリーム・プログラミング入門』と『達人プログラマー』という白と黒の書籍を読んでしまったときの思いを3 年余かけてこじらせたあげく、現職に転職。2004 年7 月からアジャイルなソフトウェア開発を実践。以来、エクストリーム・プログラミングの理念である「新たな社会構造」のために自分がやれることをやっている。心のマスター・センセイはJim Coplien。翻訳・監訳書は『アジャイルな見積りと計画づくり』『インターフェイス指向設計』『アジャイルプラクティス』『Java からRuby へ』。他にも寄稿や翻訳記事、講演など多数。

訳者

近藤修平（こんどうしゅうへい）

株式会社永和システムマネジメントサービスプロバイディング事業部所属。認定スクラムマスター。オブジェクト指向プログラミングとアジャイル開発手法に出会い、より楽しくより価値のあるソフトウェア開発を求めて2005 年に現職に転職し、プログラマ・現場リーダーとしてアジャイルなソフトウェア開発の研鑽に明け暮れている。心のマスター・センセイはトム・デマルコ。ソフトウェアは人がつくり、人が使い、人が育てるという観点から、最近は人とソフトウェアとのインターフェイスに新しい挑戦の場を求めている。著書には『iOS プログラミング逆引きリファレンス108』『サンプルプログラムでマスターするiPhone SDK プログラミング実践ガイド』。

角掛拓未（つのかけたくみ）

株式会社永和システムマネジメントサービスプロバイディング事業部所属。つかう人が喜ぶのはもちろん、つくる人も楽しむプロジェクトの「あり方」と「やり方」を模索している。心のマスター・センセイはこれから探していく。自分だからこそ生み出せる価値は何かをとことん考え形にしていきたいと強く思っている。哲学に「学習は楽しくあるべきだ」を掲げ、手始めに英単語を語源で楽しく効率よく学習するサービスD.D.（ディーツー）, D.D. Bot（@ddbot）を公開している。これからの展開にも乞うご期待。

みんなをバスに乗せる

スタートを切る前からだめになってしまうプロジェクトは実に多い。主な理由は次の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）で「どうやって」を詳しく検討していく。

じゃあまず、プロジェクトの「なぜ」から考えていこう。