内容紹介

マスターセンセイと学ぶアジャイル開発の道

動くソフトウェアを素早く開発するための「アジャイルソフトウェア開発手法」を、実際に導入するにはどうすればよいかを、豊富な図を使い親しみやすい言葉で解説しています。経験豊かな著者が具体的なノウハウをまとめた本書は、アジャイル開発を導入したいと考えている組織や人のための「現場のマニュアル」として役立ってくれることでしょう。

著者からのコメント

日本の読者の皆さんへ

君がこの本を手に取ったことに祝福を。おめでとう。というのも、君にはすごく大事な2つのことが備わってるってことだからだ。

1. 君は学ぶことが心から好きだ。
2. 君はソフトウェアのことを大切に思っている。

このどちらもが大切なんだ。君が学びたいという気持ちを抱かなければ、私との旅がこうして幕を開けようとすることもなかった。君がソフトウェアのことなんて気にしない人物だったら、私たちの世界は今よりも暮らしづらいものになっていただろう。

なぜなら世界はソフトウェアを必要としてるわけだから。世界はソフトウェアを作ることを手助けする人を必要としてるんだ。そう、君みたいなね。私たちが、君みたいに才気煥発で、頭が良くて、思慮深い、情熱にあふれた人達をもっと惹きつけられるようになるには、もっと成果をあげるソフトウェアの作り方が必要なんだ。わくわくするような、毎朝目を覚ますたび、今日一日またソフトウェアを作ることが楽しみで仕方がないようなやつがね。

そのために私は本書を書いた。もっとうまくソフトウェアを届けるやり方を探し求め、分かちあい、見出していこう（でもあんまり深刻に受け止めすぎないで。楽しみながらやっていこう）。

君の探してることが、本書を読んで見つけられることを願っている。もし見つからなかったとしても、探し続けることを止めないでほしい。

2011年4月26日

ジョナサン・ラスマセン

（日本語版序文より）

----

本書の特長

タイトルに加えて、ジョナサン独特の筆致と妙な味わいの挿絵に幻惑された読者がいるかもしれませんが、本書は見た目によらず硬派な1冊です。監訳者たちが本書の価値と特長だと捉えている点を、簡単にまとめておきます。1）開発者------もっといえばプログラマ向けに焦点を合わせていること、2）アジャイルな開発の進め方をひと通りすべてカバーしていること、3）よく練られた5部15章の構成になっていること、4）特定の方法論を前提としていないこと、5）ユーモアと楽しむ気持ちを忘れていないこと。これだけの内容を300ページ以内に収めたジョナサンたち原著執筆チームの力量には「お見事！」と喝采を送りたいです。

...

よく誤解されることなのですが、アジャイル開発は腕自慢の「優秀な」プログラマでなければ実践できない、というものではありません。たとえば、監訳者2人はアジャイル開発を実践していますが、プログラマとしてはいたって普通です。ですから、顧客にちゃんと価値を届けるためには、エンジニアリングプラクティスという先人の知恵の集大成を「問答無用」で「規律正しく実践」しなければなりません。それに、普通のプログラマは独りで実現できることもたかが知れています。だからチームを組むのです。

本書の冒頭でジョナサンは宣言します。「コードを実行するのはコンピュータかもしれないが、そのコードを生み出し、保守するのは私たち人間なんだ」と。私たちプログラマの多くは、普通のプログラマです（たくさんいるから「普通」なのです）。そんな私たちがチームを組んで成果をあげるには、物事をうまく運ぶための仕組みやプラクティスが必要です。だからといって、既存のアジャイル開発手法の提示するやり方を形だけなぞってもなかなかうまくいきません。

スケジュールを2週間単位で分割したMicrosoft Execlのシートを作ればイテレーションなのか？毎朝集まればデイリースタンドアップなのか？テストを先に書けばテスト駆動開発なのか？------「そうじゃないんだ」とばかりに、ジョナサンは「12の原則」を、字面だけでなく真に理解して体現した「圧倒的なアジャイルプロジェクトの姿」を私たちに示してくれます。10.6「デイリースタンドアップ」（p. 213）などはその好例です（毎朝、天地神明に誓ってから仕事をしてますか？ただ突っ立ってボソボソしゃべってるような開発者はいねがー？）。

私たちのソフトウェア開発の現場をどうにかできるのは私たちだけです。しかも、一つとして同じ現場はありません。だから「どんな書籍も手法も、君が必要とするありとあらゆるものを用意することなんてできない」のです。私たちは「自分の頭で考えるのをやめちゃだめ」なのです。

（「監訳者あとがき」より）

内容（「BOOK」データベースより）

アジャイルサムライ―それはソフトウェアを顧客に届ける猛々しきプロフェッショナルだ。本書では、圧倒的なアジャイルプロジェクトの姿を見せる。

著者について

著者・監訳者・訳者について

著者

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）を公開している。これからの展開にも乞うご期待。

著者略歴 (「BOOK著者紹介情報」より)

ラスマセン,ジョナサン
実務経験豊かな起業家であり、前職ではThoughtWorks社のアジャイルコーチを務めていた。世界をまたにかけたコンサルティングを行っており、一丸となって楽しみながら働ける現場の実現に尽力している

西村/直人
株式会社永和システムマネジメントサービスプロバイディング事業部アジャイルコーチ。スクラム道プロダクトオーナー

角谷/信太郎
株式会社永和システムマネジメントサービスプロバイディング事業部コミュニティマネージャ。日本Rubyの会理事。Asakusa.rbメンバー

近藤/修平
株式会社永和システムマネジメントサービスプロバイディング事業部所属。認定スクラムマスター

角掛/拓未
株式会社永和システムマネジメントサービスプロバイディング事業部所属(本データはこの書籍が刊行された当時に掲載されていたものです)

About this Title

第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）で「どうやって」を詳しく検討していく。

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