Original English language title: Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt
Copyright ©2006 Venkat Subramaniam and Andy Hunt Translation Copyright ©2007 Ohmsha, Ltd.
All rights reserved.
No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. 本書を発行するにあたって、内容に誤りのないようできる限りの注意を払いましたが、本書の内容を適用した結果生 じたこと、また、適用できなかった結果について、著者、出版社とも一切の責任を負いませんのでご了承ください。 本書に掲載されている会社名・製品名は一般に各社の登録商標または商標です。 本書は、「著作権法」によって、著作権等の権利が保護されている著作物です。本書の複製権・翻訳権・上映権・譲渡 権・公衆送信権（送信可能化権を含む）は著作権者が保有しています。本書の全部または一部につき、無断で転載、複 写複製、電子的装置への入力等をされると、著作権等の侵害となる場合がありますので、ご注意ください。 本書の無断複写は、著作権法上の制限事項を除き、禁じられています。本書の複写複製を希望される場合は、そのつ ど事前に下記へ連絡して許諾を得てください。 • オーム社開発部「アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣」係宛、E-mail（ [email protected]）または書状、FAX（03-3293-2825）にて
“Practices of an Agile Developer”
読者の声
「こんな気分」というセクションはまさに金言だ。こうしなさい、と誰かに諭される のとは全然違って、自分でそのプラクティスを正しく実践できていることがわかる んだから。
I
Nathaniel T. Schutta
, “Foundations of Ajax”
共著者こういう本が
Pragmatic Bookshelf
から出るのを待っていた。短く、読みやすく、 当を得た、深く、鋭く、役に立つ本だ。「アジャイル」でありたい人にとって貴重な リソースになるに違いない。I
Forrest Chang
,
ソフトウェア開発主任 読み始めてから幾度となく「みんなもっとこの本を読むべき」と思った。でもすぐ に、この本が必要なのは自分だと気づいたんだ。あらゆるレベルの開発者に強くお すすめしたい。I
Guerry A. Semones
,
上級ソフトウェアエンジニア, Appistry
社この本は、あなたが自分のプロジェクトにアジャイルなプラクティスの導入を検討 すべき理由を、経験に基づいたわかりやすい言葉で示してくれる。たいていの書籍 から読み取るのが最も難しいのは、この手の現場で培われた知見だ。
I
Matthew Johnson
,
主席ソフトウェアエンジニア 自分はPragmatic Bookshelf
のほかの本を持っていて、この本に出てくるいくつ かのプラクティスにも馴染みがあった。この本ではそんなアイデアを簡潔にわかり やすく、まとまった形で知ることができる。「アジャイル」になりたい新人やチーム には特におすすめだ。I
Scott Splavec
,
上級ソフトウェアエンジニア アジャイルなプラクティスが業界に波及するにつれ、「アジャイル」が本当に意味す ることを理解したいという要望も増えてきた。この本は、まさにその要望に簡潔か つ実践的に応えるものだ。iv “Practices of an Agile Developer”読者の声
きっとあなたはアジャイルな方法論のことを耳にしたことがあり、自分の毎日の仕 事を改善するのに何ができるのか自問したことがあるだろう。私に言わせれば、そ の答えがこの本だ。これを読めば、あなたに実践できるプラクティスを内なる天使 がそっと教えてくれるだろう。
I
David Lázaro Saz
,
ソフトウェア開発者アジャイルの核心となるプラクティスについて、とても包括的なのに焦点の定まっ た簡潔な要約だ。特定のアジャイルな方法論を押し付けるのでなく、いろいろな方 法論に共通するプラクティスを結びつけ、首尾一貫した全体像を描き出しているの がいいと思う。より迅速により信頼性のある方法で、ものすごく優れたソフトウェ アを開発したくてうずうずしている人は、読んだほうがいい。
I
Matthew Bass
,
ソフトウェアコンサルタント 文句なく“
達人プログラマー”
の続編！ほとんどの格言には 逆の格言がある
どちらかが劣っているということではない 両者の間でバランスをとることが重要なのだ
目次
“Practices of an Agile Developer”読者の声 iii
目次 xi 第1章 アジャイルソフトウェア開発 1 第2章 アジャイルの初心 11
I
1
成果をあげるのが仕事. . . 13
I
2
応急処置は泥沼を招く. . . 16
I
3
人ではなくアイデアを批判する. . . 19
I
4
機雷がなんだ！ 全速前進！. . . 24
第3章 アジャイルさを育む 27I
5
変化に付いていく. . . 29
I
6
チームに投資する. . . 32
I
7
時が来たら習慣を捨てる. . . 35
I
8
わかるまで質問する. . . 38
I
9
リズムに乗る. . . 41
第4章 ユーザが求めるものを提供する 45I
10
顧客に決断してもらう. . . 47
I
11
設計は指針であって、指図ではない. . . 50
I
12
技術の採用根拠を明確にする. . . 54
I
13
いつでもリリースできるようにしておく. . . 57
I
14
はやめに統合、こまめに統合. . . 61
I
15
早いうちにデプロイを自動化する. . . 64
I
16
頻繁なデモでフィードバックを得る. . . 67
I
17
短いイテレーションでインクリメンタルにリリースする. . . 72
I
18
定額契約は守れない約束. . . 76
第5章 アジャイルなフィードバック 79I
19
天使を味方につける. . . 81
I
20
作る前から使う. . . 86
I
21
違いがあれば結果も変わる. . . 91
I
22
受け入れテストを自動化する. . . 94
xii 目次
I
23
ありのままの進捗を計測する. . . 97
I
24
ユーザの声に耳を傾ける. . . 100
第6章 アジャイルなコーディング 103I
25
意図を明確に表現するコードを書く. . . 105
I
26
コードで伝える. . . 110
I
27
トレードオフを積極的に考慮する. . . 115
I
28
インクリメンタルにコードを書く. . . 118
I
29
シンプルにすること. . . 120
I
30
凝集度の高いコードを書く. . . 122
I
31
“Tell, Don’t Ask”
――― 求めるな、命じよ. . . 126
I
32
取り決めを守ってコードを置き換える. . . 129
第7章 アジャイルなデバッグ 133I
33
ソリューションログをつける. . . 134
I
34
警告をエラーとみなす. . . 136
I
35
問題を切り分けて攻める. . . 140
I
36
あらゆる例外を報告する. . . 143
I
37
役に立つエラーメッセージを提供する. . . 145
第8章 アジャイルなコラボレーション 151I
38
定常的に顔を合わせる. . . 153
I
39
アーキテクトもコードを書くべき. . . 157
I
40
共同所有を実践する. . . 160
I
41
メンターになる. . . 162
I
42
答えを見つけられるように力を貸す. . . 164
I
43
コードの共有には段取りがある. . . 166
I
44
コードをレビューする. . . 169
I
45
みんなに知らせる. . . 172
第9章 終章：アジャイルへ踏み出す 1759.1
たったひとつの新しいプラクティス. . . 175
9.2
窮地のプロジェクトを救う. . . 176
9.3
アジャイルな開発のはじめ方：マネージャ向けガイド. . . 177
9.4
アジャイルな開発のはじめ方：プログラマ向けガイド. . . 179
9.5
これで終わり？. . . 180
xiii 付録A 参考資料 181
A.1 Web
上の資料. . . 181
A.2
参考文献. . . 185
天使の助言 191 監訳者あとがき 195 索引 199第
1
章アジャイルソフトウェア開発
Agile Software Development
道を間違えたなら どれだけ進んでいたとしても 引き返せ ――― トルコの諺 冒頭に引用したトルコの諺は実に単純でわかりやすい。ソフトウェア開発の指針 にも使えそうだと思ったかもしれない。ところが、往々にして開発者というものは 何とかなるだろうという誤った希望的観測を抱いたまま、間違った道を進んでしま うものだ（僕らだって例外じゃない）。「きっといい線いってるはずだ」「それほど道 から外れてないだろう」。ソフトウェア開発が、諺に出てくる道のようにまっすぐで 行き先の決まったものなら、それでうまく切り抜けられることもあるだろう。でも 違うんだ。ソフトウェア開発はまっすぐな道じゃない。 むしろ、ソフトウェア開発はサーフィンに似ている。波はダイナミックに変化し 続ける。海そのものが予測不可能でリスクが高い。海中にはサメが潜んでいるかも しれない。 それでもサーフィンに挑戦するのは、ひとつとして同じ波がないからだ。波はそ れぞれ形が異なるし、場所に応じて動きも変わる。砂浜に打ち寄せる波と岩礁の上 で砕ける波は、まったく別物だ。 ソフトウェア開発における波は、プロジェクトで発生する要件や課題だ。波は決 して途絶えることなく、絶えず変化し続ける。波と同じように、ソフトウェアプロ ジェクトの形もさまざまだ。対象とする領域やアプリケーションが異なれば、取り 組むべき課題も異なる。もちろんサメもいる。いろんな姿をしたサメが。 ソフトウェアプロジェクトの成功は、チームの開発者全員のスキル、鍛錬、能力 に左右される。優れた開発者は、優れたサーファーと同じく、（技術的な）適性、バ ランス感覚、そしてアジャイルさを備えている。アジャイルであることとは、状況 の変化にすばやく適応できる能力のことだ。サーファーは、予想よりも早く波が砕 けても適応できなければならない。開発者なら、想定外の早さで設計が破綻しても 適応できなければならない。
2 第1章 アジャイルソフトウェア開発
アジャイルの本質
では、アジャイルであることとは具体的には何なのか。その実践であるアジャイ ルソフトウェア開発というムーブメントは一体どこで生まれたのだろうか。2001
年2
月、17
人の同志がユタ州のスノーバードに集まった。本書の著者である アンディも出席した。会合の目的は、当時軽量プロセス（Lightweight Processes
） と総称されていた新たなソフトウェア開発の動向について話し合うことだった。 そのころアンディたちは、中間成果物の多さの割には最終成果物が少ない重厚長 大な開発方法論のせいで、数々のプロジェクトが失敗するのを目の当たりにしてい た。もっと優れた開発方法論があるはずだ。重要度の高い事柄に注力し、重要度の 低い事柄（貴重な時間を浪費するばかりで、大して成果の出ない事柄）には労力を 割かないようにする方法論が。17
人はそれにアジャイルという名前を与え、アジャイルマニフェストを発表し た。アジャイルマニフェストでは、ソフトウェア開発で重視するものを改めて考え 直した。重視するのは、人、人と人との交流と協調、適応力、動作するソフトウェ アだ（以下のコラムでアジャイルマニフェストの冒頭部分を紹介する）。}
}
アジャイルマニフェスト
*1 我々は、自らソフトウェアを開発し、かつ他者のソフトウェア開発を援助することを 通じて、よりよいソフトウェア開発方法を解明しようとしている。この過程において、 我々は、s
プロセスやツールよりも、人と人との交流をs
包括的なドキュメントよりも、動作するソフトウェアをs
契約上の交渉よりも、顧客との協調をs
計画に従うことよりも、変化に適応することを 重視するに至った。これは、上記各行の左側にある項目の価値を認めながらも、右側に ある項目の価値をより重視するということである。Copyright 2001, the Agile Manifesto authors 詳細はagilemanifesto.orgを参照。
}
}
3 ソフトウェア開発に対するアジャイルなアプローチとは、適応力と協調を重んじ る人々が、一丸となって目に見える具体的な目標（きちんと動作するソフトウェア） に向かっていくことである。これがアジャイルの本質だ。開発がアジャイルになる と、開発現場で重点を置くものが、計画を絶対視する（
plan-based
）方式から、よ り自然で継続的なスタイルへと変化していく。 アジャイル開発では、チームのメンバー（およびチームと共に作業するメンバー） 全員が、プロジェクトで明確な結果を出すことを目指すプロフェッショナルである ことを前提としている。必ずしも全員が経験豊富なプロフェッショナルではないか もしれない。しかし、プロフェッショナルとしての意識を持ち、自らの持てる力を 最大限に発揮したいという意欲に満ちている。 だから、ずる休み、手抜き、あからさまなサボりに悩まされているチームには、 アジャイル開発は合わないと思う。そんなチームに必要なのは、もっと鈍重で時間 のかかる、生産性の低い開発プロセスだ。あなたが胸を張って「うちのチームはそ んなんじゃない」と言えるなら、アジャイルなスタイルで開発を始められる。 アジャイルな開発スタイルとは、つまりこういうことだ。プロジェクトの最後に まとめてテストしない。統合を月末まで延期しない。コードを書き始めたからと いって要求やフィードバックの反映を止めない。 これまでとは違って、プロジェクトの継続的な開発。
散発的ではない
ライフサイクル全体を通じて、あらゆる 作業を継続的に実行するんだ。そもそも ソフトウェアというものは、ユーザが使 い続ける限り、本当の意味で「完成」する ことはない。だから、ソフトウェアの開発はもはやプロジェクトですらないといっ てもいい。ソフトウェア開発は継続的なものなんだ。フィードバックも継続的だ。 問題を発見するまでに何カ月も待つ必要はない。まだ傷が浅いうちに見つけ出し、 すばやく修正する。見つけたその時、見つけたその場で、だ。 これがアジャイルな開発スタイルだ。 アジャイル開発の手法はいくつかあるが、継続的な開発という考え方はいずれに も当てはまる。継続的なのは開発のライフサイクルに限らない。技術スキルの習 得、要求の取り入れ、製品のデプロイ、ユーザへのトレーニングなど、すべてのレ ベルのあらゆる活動が継続的だ。 なぜか？ それは、ソフトウェア開発がエネルギーを注ぐ
とても複雑な営みだからだ。まだ問題に なっていないとか、そう大きな問題では ないからといって物事を放置していると、 きっと状況は悪化して手に負えなくなる。ある種の軋轢が増すと、修正や変更は難4 第1章 アジャイルソフトウェア開発 しくなっていく。どのような軋轢であれ、うまく対処する方法はただひとつだ。シ ステムに対してエネルギーを少しずつ、継続的に注入し続けるしかない（『達人プロ グラマー』の第
1
章「2.
ソフトウェアのエントロピー」を参照）。 アジャイル開発は単に危機管理に別の名前をつけて誤魔化しただけではないの か、との疑いを抱く人もいる。そうじゃない。危機管理が必要になるのは、問題が 手に負えなくなったときだ。今やっていることを放り出してでも、すぐさま危機に 対処しなければならない。そして、その対処が原因となって次なる危機を引き起こ す。どこまでも続く危機と混乱の悪循環。これは僕らが陥りたくない状況そのも のだ。 そうなってはいけない。小さな問題には小さなうちに対処しよう。未知の課題は 深入りする前によく調べよう。過ちに気づいたらすぐに、素直にそれを認めよう。 そのためには、自分の考え方、コーディングのプラクティス、チームワークを見直 す必要がある。難しいことじゃない。とはいうものの、最初は違和感をおぼえるか もしれない。アジャイルの実践
ソフトウェア開発がアジャイルであることをわかりやすく定義すると、次のよう になる。 開発がアジャイルであるということは、協調性を重んじる環境で、 フィードバックに基づいた調整を行い続けることである これが現実に意味するところと、アジャイルチームでの活動とを、ざっとまとめ よう。 アジャイル開発はチーム作業だ。アジャイルチームは小規模か、10
人前後の小さ なチームに分割されている。たいていは互いが密に連携できる環境、できれば「ブ ルペン（つまり仕切りのない空間）」で作業し、コードや開発に必要なタスクを共有 する。システムを実際に使うユーザやソフトウェアの開発費用を支払ってくれる顧 客の近くで作業を進める。そしてできるだけ「はやめに、こまめに」最新バージョ ンのシステムを見てもらう。 書いたコードからのフィードバックを取り入れ続ける。継続的にプロジェクトの ビルドとテストを行うために自動化する。作業を進めていくにつれて、コードに変 更が必要だと気づくこともあるだろう。コードを変更するのは、機能的な振る舞い が変わったときだけではない。コードの命脈を保つために、どの部分のコードで あっても必要に応じて再設計する。これはリファクタリングと呼ばれている。リ ファクタリングは継続的な開発の構成要素だ。コードが本当の意味で「完成」する ことはない。5
}
}
アジャイルツールキット
本書ではアジャイルプロジェクトで普通に使われる基本的なツールに言及することが ある。あなたに馴染みのないツールがあるかもしれないので、ここで簡単に紹介してお こう。各ツールの詳細は、参考文献に挙げる書籍を参照してほしい。t
WikiWikiとはWikiWikiWebの略で、ユーザがWebブラウザだけでコンテンツの編集 や新しいコンテンツへのリンクを作成できるWebサイトのことだ。Wikiはコラボ レーションを促進する優れたツールだ。チームメンバー全員が必要に応じてコンテ ンツを動的に追加したり、既存のコンテンツを整理したりできる。Wikiの詳細は
“The Wiki Way”[LC01]を参照してほしい。
t
バージョン管理プロジェクトのビルドに必要な一切合切（ソースコード、ドキュメント、アイコン、 ビルドスクリプトなどすべて）は、バージョン管理システムの制御下に置く必要があ る。いまだに共有ネットワークドライブにファイルを置いているチームが多いこと には驚かされるが、なんともアマチュア的なアプローチだ。バージョン管理のセッ トアップと使用方法の詳細は、“Pragmatic Version Control Using CVS”[TH03]ま たは“Pragmatic Version Control Using Subversion”[Mas05]を参照してほしい*2。
t
ユニットテストコードを使ってコードを動かすことで、開発者は大きなフィードバックを得られる。 ユニットテストについては本書のなかでも詳しく説明するが、テスティングフレー ムワークを活用すれば、こまごました作業の大部分を気にしなくて済ませられる。 ユニットテストの基礎は、“Pragmatic Unit Testing in Java”[HT03]や“Pragmatic Unit Testing in C#”[HT04]を参照してほしい。また、実践的な例については、“JUnit Recipes”[Rai04]が参考になる。
t
ビルドの自動化 各自のマシンでのローカルビルドも、チーム全体の成果として実行するビルドも、完 全に自動化して、再現可能なビルドにできる。こうしたビルドは常時実行されるこ とから、継続的インテグレーションとも呼ばれている。ユニットテストと同様に、継 続的インテグレーションを行うフリーソフトウェア、オープンソースソフトウェア、 あるいは商用製品も多数開発されている。ビルドの自動化（とラバランプ*3の使い 方）に関するさまざまなヒントは、“Pragmatic Project Automation”[Cla04]を参照 してほしい。 さらに、これらの基本的なツールを実践で組み合わせるうえでのヒントは、“Ship It!”[RG05]が参考になる。}
}
*2［訳注］これからバージョン管理を始めるなら、CVSよりもSubversionを選ぼう:-) *3［訳注］日本のアジャイル開発コミュニティでは「ソフトウェアあんどん」や「XFD」（eXtreme Feedback Device）といったキーワードで認知されている照明器具。
6 第1章 アジャイルソフトウェア開発 作業はイテレーション単位で進めていく。イテレーション（反復）とは、
1
週間 程度の短い時間のまとまりのことで、この単位で機能を実装していく。イテレー ションの成果を顧客にデモして、フィードバックを得る（進んでいる方向が正しい ことも確認する）。そして現実的な範囲内で可能な限り頻繁に、完全なバージョン を実際のユーザに向けてリリースする。 以上をふまえて、本書では以下の各分野におけるアジャイル開発者のプラクティ スを詳しく紹介していく。t
第2章：アジャイルの初心 ソフトウェア開発は、なにもかも頭の中で行われる。本章では、アジャイルと いう言葉の意味と、本書の残りの部分の基礎となるアジャイルなものの考え方 や、アジャイルになるための優れた個人的プラクティスを紹介する。t
第3章：アジャイルさを育む アジャイルプロジェクトでは、立ち止まっているわけにはいかない。開発対象 の機能そのものではないものの、健全なチームを維持していくうえで欠かせない プラクティスがある。そうしたチームの後ろ盾となるプラクティスを継続しなけ ればならない。本章では、チームとチームメンバーが成長と前進を続けるために 実行すべきプラクティスを紹介する。t
第4章：ユーザが求めるものを提供する どんなによくできたソフトウェアでも、ユーザのニーズを満たしていなけれ ば、無用の長物だ。本章では、ユーザの巻き込み方、ユーザのシステムを利用し た経験に学ぶ方法、ユーザの真のニーズに沿った形でのプロジェクトの進め方と いったプラクティスや手法を紹介する。t
第5章：アジャイルなフィードバック フィードバックに基づいてソフトウェアや開発プロセスを修正するのは、ア ジャイルチームの軌道を正しく保ち、陥りがちな泥沼や事故を防ぐために必要な プラクティスだ。最良のフィードバックは、コードそのものから得られるフィー ドバックだ。本章では、チームの進捗や作業効率をうまく管理する方法だけでな く、そうしたフィードバックを得る方法も紹介する。t
第6章：アジャイルなコーディング コードの柔軟性と適応性を維持して、将来の不確定要素に対応できるようにし ておくことは、アジャイル開発を成功に導くうえできわめて重要だ。本章では、7 見通しのよい柔軟なコードを維持するための実践的で実績のある手法を紹介す る。これにより、コードが化け物に変身することを避けられる。
t
第7章：アジャイルなデバッグ エラーのデバッグは、プロジェクトにとってかなりの時間的負担となることが ある。プロジェクトの時間は決して無駄にはできない。本章では、もっと効率よ くデバッグする方法や、プロジェクトの時間を節約する方法を紹介する。t
第8章：アジャイルなコラボレーション 結局のところ、1
人のアジャイル開発者にあげられる成果には限りがある。そ れ以上を目指すには、アジャイルチームが必要だ。本章では、チームをまとめ上 げるうえで特に有効なプラクティスや、チームを日々うまく機能させ、将来に向 けて成長させていくために役立つプラクティスを紹介する。悪魔の囁き
本書をぱらぱらとめくると、各ヒントの冒頭部分に、小さな悪魔のイラストが登 場し、悪癖へと誘惑する言葉を投げかけてくる。例えば、こんな感じだ。 「さあ、手っ取り早くやっちまおうぜ。時間を節約できること間違いなし。 大丈夫、誰も気づきやしないって。今の仕事はさっさと片付けて、次のこと をやる。それが一番肝心なことじゃないか」 悪魔が放つ挑発の言葉には、スコット・アダムスの漫画ディルバート*4に出てく る「髪のとんがった上司」が言いそうな、取るに足りないセリフもある。しかし、 アダムスが愛読者たちから多くの着想を得ていることをお忘れなく。 なかには、かなり突飛に感じられる言葉もあるだろう。だが、すべて現実にあり えるものだ。僕らが噂に聞いたものもあれば、実際に目にしたものもある。実は僕 らがひそかに思ったりしたことも含まれている。こうした言葉の数々は、僕らを惑 わす甘い誘いであり、「プロジェクトの時間を節約できたら」という儚い望みを抱い ているとついつい向かってしまう、犠牲の大きな「近道」なのだ。 こうした誘惑に打ち勝つべく、各プラクティスの後半では、我らが内なる天使に ご登場願い、助言を授かっている。内なる天使からの助言は、僕らの進むべき道だ。 例えば次のようなものだ。 *4［訳注］Dilbert：スコット・アダムス作の新聞漫画。主人公ディルバートはエンジニアで、職場の官僚主義と 適当に付き合いながら仕事をしている。8 第1章 アジャイルソフトウェア開発 難題から始めなさい どんなときも、最初に最大の難問へ取り組みなさい。簡単なものは後回しで よいのです。 そうはいっても現場では、はっきりと白黒を付けられないことも多い。そこで、 紹介するプラクティスを実践したときの気持ちを説明したセクションと、プラク ティスを効果的に実践しつつバランスを保つためのヒントを記したセクションも用 意してある。次の
2
つがそうだ。こんな気分
「こんな気分」のセクションでは、紹介したプラクティスが引き起こすはずの感情 を説明する。ここで説明したような気持ちにならない場合は、プラクティスの実践 方法を見直すべきかもしれない。バランスが肝心
s
プラクティスの実践が過剰だったり不足したりすることもありえる。そこでこ の「バランスが肝心」のセクションでは、プラクティスのバランスをとるため のヒントや、プラクティスを有効活用するための全般的なヒントを紹介する。 結局のところ、どんなに良いプラクティスであっても、やりすぎたり、使い方を 誤ったりすれば、大きな危険を招くことになる。僕らは、チームがプラクティスの バランスを保てなかったがために失敗してしまったアジャイルプロジェクト（と呼 ばれていた何か）の事例を幾度となく目にしてきた。僕らの願いは、本書で紹介す るプラクティスが、あなたの現場の成果へとつながることだ。 本書で紹介するプラクティスの教えを、バランスを考えて効果的に現場へ適用す れば、プロジェクトにもチームにも見通しの明るい変化の兆しをもたらすことがで きるだろう。 そしてあなたは、アジャイル開発者としてのプラクティスに従うだけにとどまら ず、プラクティスの背後にある原理原則をも理解できるようになるはずだ。謝辞
どんな書籍も、大きな苦労の末に生み出されている。出版の舞台裏には、不肖筆 者たちだけでなく、とてもたくさんの人がかかわっている。 本書の刊行に際しては、次に示す方々にご尽力いただいた。ここに感謝の意を表 したい。9
表紙のイラスト*5を作成していただいた
Jim Moore
氏と、見事な編集の腕前を発揮していただいた
Kim Wimpsett
氏に感謝する（本書に誤りが残っているとしたら、僕らが最終段階で加えた編集のせいだ）。
Johannes Brodwall
、Chad Fowler
、Stephen Jenkins
、Bil Kleb
、Wes Reisz
の各氏にも、大いなる感謝の意を表したい。彼らからはさまざまなヒントや貢献を いただいた。そして、レビューを担当していただいた皆さんにも感謝する。以下に名前を記す 優秀な方々が、貴重な時間を割いて快く協力してくれた。本書の内容をさらに向上 させることができたのも彼らのおかげである。
Marcus Ahnve
、Eldon Alameda
、Sergei Anikin
、Matthew Bass
、David Bock
、A. Lester Buck III
、Brandon
Campbell
、Forrest Chang
、Mike Clark
、John Cook
、Ed Gibbs
、Dave
Good-lad
、Ramamurthy Gopalakrishnan
、Marty Haught
、Jack Herrington
、Ron
Jeffries
、Matthew Johnson
、Jason Hiltz Laforge
、Todd Little
、Ted Neward
、James Newkirk
、Jared Richardson
、Frédérick Ros
、Bill Rushmore
、David
Lázaro Saz
、Nate Schutta
、Matt Secoske
、Guerry Semones
、Brian Sletten
、Mike Stok
、Stephen Viles
、Leif Wickland
、Joe Winter
。ヴェンカットからの謝辞
優れたご指導をいただいたDave Thomas
氏に感謝する。氏の指導や励まし、建 設的な批評がなかったら、本書が形になることはなく、単に「すごく良い考えだ」 のレベルで終わっていたことだろう。 共著者がAndy Hunt
であったことをうれしく思っている。彼からは非常に多く を学んだ。彼は、技術的な知識や技能が優れている（そんなことみんな知ってるよ ね）のはもちろんだが、表現力に溢れ、人柄も抜群だ。また、本書の製作に関するす べての段階で、Pragmatic Programmers
社の進め方は称賛に値するものだった。 書籍の出版に必要な正しい道具と手法、そして何より出版に取り組むうえでの姿勢 を完全に理解し、体現していた。 私を励ましてくれたMarc Garbey
氏に感謝する。彼のようなユーモアとアジャ イル開発の感覚に溢れた人は、この世には貴重だ。彼は素晴らしい友人だ。ま た、日頃から仲良くしてもらっているギーク（じゃなくて、友人）諸君にも感謝す る。Ben Galbraith
、Brian Sletten
、Bruce Tate
、Dave Thomas
、David Geary
、Dion Almaer
、Eitan Suez
、Erik Hatcher
、Glenn Vanderburg
、Howard Lewis
Ship
、Jason Hunter
、Justin Gehtland
、Mark Richards
、Neal Ford
、Ramnivas
Laddad
、Scott Davis
、Stu Halloway
、Ted Neward
。本当にありがとう。また、NFJS
のディレクタであるJay Zimmerman
氏（通称アジャイルドライバー）にも10 第1章 アジャイルソフトウェア開発
感謝する。励ましてもらったり、アジャイルであることについての私の考えを彼の 顧客に披露する機会を与えてもらった。
正しい価値観について教えてくれた父と、深い啓示を与えてくれた母に感謝する。 また、妻
Kavitha
と、2
人の息子Karthik
とKrupakar
の頑張りと励ましがなけ れば、この仕事は不可能だった。愛を込めて、感謝の言葉を贈る。ありがとう。アンディからの謝辞
ここまでで、ほぼ全員への感謝が済んでいるように思うので、Venkat
に謝意を 伝えたい。特に、本書の執筆に誘ってくれたことに感謝を。そのへんの誰かの誘い なら受けなかったが、Venkat
からの誘いである。彼ほどプラクティスを熟知して いる人はいない。 スノーバードで集まったアジャイル仲間のみんなにも感謝したいと思う。あのと き一緒にいた誰かがアジャイルなるものを発明したというわけではなく、皆の努力 を結集したおかげで、現代のソフトウェア開発業界に隆盛著しい一大勢力を生み出 すことができた。 そしてもちろん、私を支え、理解してくれた家族にも感謝する。『達人プログラ マー』の出版に始まった長い道のりだけれど、おかげで楽しい旅路になっている。 さあ、お待ちかね。本編の始まりだ。第
2
章アジャイルの初心
Beginning Agility
道の起点を決める者が、その行先を決める。 ――― ハリー・エマソン・フォスディック ソフトウェア開発の方法論をテーマとした従来の書籍でよくある説明の流れはこ うだ。まず最初に、プロジェクトで必要となる役割を説明する。それに続いて、作 る必要のあるたくさんの成果物（ドキュメント、チェックリスト、ガントチャート など）が説明される。たいていの規則は「汝……すべし」的な戒律調の堅い文体に なっている*1。本書はこうした流れに従わない。ようこそ、アジャイルな開発の世 界へ。僕らのやり方はちょっと違う。 例えば、とある有名なソフトウェア開発方法論は、ひとつのプロジェクトに約35
種類の役割を担当者それぞれに割り当てることを推奨している。アーキテクト、デ ザイナ、コーダー、ライブラリアンなどだ。アジャイルな方法論はこれとはまった く異なる方針をとっている。用意している役割はただひとつ、ソフトウェア開発 者だけだ。そして、それを担うのはあなただ。チームで行動し、顧客とも緊密に連 携してソフトウェアを開発する。アジャイル開発で信頼をおくのは人だ。ガント チャートや戒律が綴じられた二穴リングファイルじゃない。 ソフトウェア開発が本当に行われる場所は、チャートやIDE
や設計ツールの中で はない。人の頭の中だ。しかし、頭の中にあるのはソフトウェア開発のことだけで はない。そこは個人的な感情、職場での駆け引き、自分勝手な思い込み、記憶、そ の他もろもろの雑念に満ちており、しかもこれらがすべてごちゃまぜになっている。 ちょっとした態度や気分の変化が大きな違いにつながるのはこのためだ。 だからこそ、態度には十分に気を配ろう。自分自身の態度はもちろん、チームの 態度にも。プロジェクトとチームが評価できる成果をあげること、個人とチームが 成長すること、そして成功を収めることに全力を傾けること。これがプロフェッ ショナルの態度だ。誰しもつい志の低い目標でお茶を濁してしまいがちだが、本章 では本当の目標に向かって全力を傾け続けるための方法を見ていく。さまざまな障 壁を乗り越えて、「成果をあげるのが仕事」だと考える必要があるのだ（その方法に ついては13
ページを参照）。 *1「システムは……するものとする」といった言い回しもよく見かける。12 第2章 アジャイルの初心 ソフトウェアプロジェクトでは、納期に追われて焦るあまり、発生した問題に対 して後先考えず、場当たり的に対処してしまいがちだ。しかし、経験豊富な開発者 なら誰もが知っているように、「応急処置は泥沼を招く」ものだ（この問題を回避す る方法は
16
ページで説明する）。 誰にでも自尊心はある。具体的な名前は出さないけど、なんていうか、自尊心に 「満ち溢れた」人もいる。問題を解決してほしいと頼まれて、その解決策を見出せ ば、誰だって誇らしく思うものだ。しかし時には、その誇りのせいで客観的にもの ごとを考えられなくなることがある。設計について話し合っていたはずが、いつの まにか脱線して、個人や人格を攻撃しあう口論になり、もともとの論点や今扱って いる問題について考えることから離れてしまった経験はないだろうか。「人ではな くアイデアを批判する」ほうがずっと有益だ（19
ページ）。 フィードバックはアジャイル開発に欠かせない要素だ。進んでいる方向が間違っ ていることに気づいたら、すぐに向きを変えなければならない。とはいえ、問題を 指摘するのは必ずしも簡単なことではない。政治的なしがらみがある場合には特に 難しい。けれども時には勇気を出して、「機雷がなんだ！ 全速前進！」という気概 で臨むことも必要だ（24
ページ）。 アジャイル開発がうまくいくのは、あなたが自分のプロジェクト、仕事、それか らキャリアに対してプロフェッショナルとしての態度で取り組んでいるときだけ だ。その態度が歪んでいるようだと、ここで紹介するプラクティスもあまり役に立 たない。正しい態度で取り組めば、プラクティスを最大限に活用し、成果をあげら れるだろう。その時には、ここで紹介するプラクティスやヒントがきっと役に立つ はずだ。I1成果をあげるのが仕事 13
I
1成果をあげるのが仕事
「問題に対処するうえで最も重要な第一歩は、犯人を突き止めることだ。大 馬鹿野郎を探し出せ！ 過失を明確にすれば、問題の再発を確実に阻止でき るってもんだ」 この悪魔の囁きがもっともらしく聞こえることもある。何をおいてもまず犯人探 しをしたくなることはないだろうか？ その答えは、断じてノーだ。問題の修正が最 優先だ。 信じられないことかもしれないが、誰もがプロジェクトの成果を常に最優先で考 えているとは限らない。あなた自身だって例外じゃない。問題が起こったとき、あ なたはとっさにどう反応するだろうか。「デフォルト」の反応を考えてみよう。 事態をややこしくする言葉を口走ったり、誰かに責任転嫁をしたり、相手の態度 を頑なにさせたりして、うっかり火に油を注いでしまうことがあるかもしれない。 そんなことをしてはいけない。正しい道を歩むんだ。「事態の解決や状況を打開す るために、今の自分に何ができるだろうか？」と自問するんだ。アジャイルチーム は、成果を重視する。本当にやりたいことは、責任転嫁の先を探すことではなく、 問題の修正に専念することだろう。 サーカスで象の糞を始末する仕事のほ非難してもバグは直らない
うがまだましだと思えるほど最悪な仕事 は、極端に後ろ向きな集団で働かねばな らないことだ。彼らは問題の解決には興 味がない。互いに後ろ指をさしあうのに夢中だ。陰口を叩いたり、非難する相手を 探すのに必死になっている。チームがそんな状態では、生産性はどんどん低下して いく。自分のいるチームがそんなところだとわかったら、徐々に抜けようなんて 思ってはいけない。即刻、おさらばするんだ。それができないのなら、せめて話題 を陰湿な責任のなすりつけ合いから、もっと当たり障りのないスポーツや天気の話 題に向けるようにしよう（「ところで最近のヤンキースはどうだい？」）。 アジャイルチームではこんなことは起きない。アジャイルチームでメンバーに不 平をこぼしたら、こんな返事が返ってくるはずだ。「オーケー。で、私が力になれ ることはある？」 そう、彼らはくよくよ考える代わりに、努力をその問題の解決 に向ける。なぜそうするのかは明らかだ。成果をあげることこそが重要だからだ。 誰の手柄だとか、誰の責任だとか、誰が一番頭がいいとか、そんなことはどうでも いい。 まずは自分自身からこうした受け答えを心がけよう。誰かから不満や問題を持ち かけられたら詳しい事情を聞いて、自分が力になれることはないかと尋ねてみるん だ。これはほんのちょっとしたことかもしれない。だがこうすることで、あなたの14 第2章 アジャイルの初心 態度を相手にはっきりと示せる。あなたが問題を解決したいと思っていること。問 題を蒸し返したいのではないのだということ。これが悲観的な考えから抜け出す きっかけになるんだ。誰かの力にならないで、何をしようというんだ？ やがてみん なに「この人に話を持ちかければ、問題の解決に向けて真剣に力を貸してくれる」 とわかってもらえるようになる。問題を解決したければあなたのところへ相談に やって来ればよいのだし、愚痴を言いたいだけならよそへ行けばいいのだ。 一方、自分が誰かに助力を求めたのに適当にあしらわれた場合はどうすべきだろ うか――― あきらめずに食い下がればいい。自分が何を求めているかを具体的に説明 しよう。目的はあくまでも問題の解決であって、非難合戦でもなければ手柄合戦で もないことをはっきりさせるんだ。 非難してもバグは直りません 誰かの後ろ指をさすのではなく、自分のできる解決策に注力しなさい。大事 なことは、意味のある成果をあげることです。
こんな気分
自分が答えを知らないということを安心して認められる。大きな失敗は学習の機 会だ。魔女狩りの機会じゃない。チームは一致団結する場だ。互いを非難しあう場 じゃない。}
}
遵守は成果ではない
標準化やプロセスに関する取り組みのなかには、プロセスへの遵守の度合いを評価の 重点に置いているものが少なくない。プロセスがうまくいっていることは即ち、定めら れたプロセスにきちんと従っていることであり、それさえ満たせば世はすべて事もな し、という理屈だ。 ところが現実とはそれでうまくいくものではない。ISO-9001の認証を取得したうえ で、しっかりと鉛を裏打ちした救命胴衣を製造することもできる。製造プロセスは所定 の文書にきちんと従っている。だが、その胴衣を着用した人はみんな溺れてしまう。 いくらプロセスへの遵守の度合いを測定しても、成果は測定できない。アジャイル チームはプロセスよりも成果に価値を置く。}
}
I1成果をあげるのが仕事 15
バランスが肝心
s
「自分のせいじゃない」というのが正しいことはまずない。また、「全部お前の せいだ」というのも同じくらい間違っている。s
まったくミスをしていないのであれば、それはおそらく一生懸命やっていない 証拠だ。s
起こった問題が不具合なのか仕様追加なのかを、品質保証担当（QA
：Quality
Assurance
）と開発者との間で言い争っても無意味だ。口論している時間で修 正できてしまうことのほうが多い。s
チームメンバーの誰かが、仕様やAPI
呼び出し、前回の会議での決定事項など を誤解していたとしたら、同じように誤解しているメンバーがほかにもいると 思っていい。誤解を招きやすい点をチーム全体がきちんと把握できているか確 認しておくこと。s
チームの足を引っ張る言動を繰り返すメンバーには、プロとしての自覚が足 りない。問題の解決に向けてチームでやっていこうという気がないのだ。足を 引っ張るメンバーは、チームから外さなければならない*2。s
チームの多数派（特に影響力の強い開発者）の振る舞いがプロ意識に欠けてい て、チームの運営に無関心な場合は、自分自身がチームを離れてよそで成功を 目指すべきだ（「デスマーチ」プロジェクト[You99]
に引きずり込まれるのに 比べたら、はるかにましだ）。 *2クビにする必要はないが、そのチームには必要ないということだ。ただし、人を入れ替えたり外したりすると、 チーム全体のバランスを崩すおそれがある。そのことは頭に入れておいてほしい。16 第2章 アジャイルの初心
