Part3からは，代表的なアジャイル型プロセスを取り上げ，それぞれ基礎と実践に分けて解説していく。まず取り上げるのは「XP（エクストリーム・プログラミング）」だ。その本質は，開発者の創意工夫を引き出すことで，結果として開発生産性と品質を高めることにある。

　1999年秋に発表されたケント・ベック著の「eXtreme Programming eXplained：Embrace Change」は，世界中のソフトウエア開発者に大きな衝撃を与えた。XPの登場によって，今日のアジャイル型プロセスのムーブメントが始まったと言っていいだろう。

　発表当時，XPは熱烈な賛辞や共感と，痛烈な批判の両方で迎えられた。賛辞は伝統的な開発プロセスに限界を感じていた現場の開発者から，批判は伝統的な開発プロセスを利用してきたマネジャーからが多かった。

　批判の内容は，主に次のようなものだった。

　「XPは要件定義や基本設計を無視している。また，文書による形式知を軽視するなど，ソフトウエア開発でやってはいけないことを推奨している」。

　「XPは手抜きを正当化している。XPによって秩序が破壊され，開発プロセスがないころの混沌に戻ってしまうのではないか？」。

　これらの“誤解”は，XPの実像が正しく伝わっていないことに起因している。XPにおいても，要件定義や設計を無視しているわけではなく，プラクティス（実践すべき作業内容）の中でこれらの要素が存在している。ただし，その内容は非常に軽量であり，RUP（Rational Unified Process）などで行うものとは，内容が異なる。

　一方でPart2でも紹介した通り，XPとは開発者がソフトウエアを効率よく作成するためのプロセスであり，プロジェクトマネジメントについて弱い部分があることも事実である。そのような場合にはRUPや，あるいはScrumなどのマネジメント主体のアジャイル型プロセスで補完することも考えられる。

　また，XPが秩序を破壊し混沌をもたらすわけではない。筆者自身，XPに初めて触れたときには，これまで実際に行っていたことや，理想と考えていた行為のいくつかが具体化されていると感じ，共感を覚えた。実際のシステム開発プロジェクトにXPを導入したところ，当初こそメンバーにとまどいが見られたものの，品質，チームのモチベーション，顧客満足度のすべてについて顕著な向上が見られた。

　一方で，XPに過大な期待を寄せるがゆえの誤解もあるようだ。

　「XPは実装こそすべて。実装の妨げになる分析も設計も，文書の類も全く必要ない」。

　「XPには，プラクティス（実践すべき作業内容）はあるが，開発者を縛るルールは存在しない」。

　実際にはXPにも当然，守るべきルールが存在するし，XPのプラクティスの基本は，実は伝統的プロセスと同じものだ。ただ，それを一度分解してから選び出し，効率よく組み直したものと解釈すべきである。

　Part3とPart4で，これらの誤解を解くとともに， XPがなぜ効果的なのか，という謎を解き明かしていきたい。まず今回は，背景にある思想やXPの特徴であるプラクティスの内容など，XPの基礎を解説する。

手軽に素早く，しかも“楽しく”

　そもそも，XPとは何だろうか。提唱者であるケント・ベックはXPのことを「XPはライト級で，優れていて，低リスクで，融通がきき，予測可能で，科学的で，楽しく行えるソフトウエア開発プロセス」と紹介している。

　ソフトウエア・エンジニアリングの話題で“楽しく”という単語が含まれているのは珍しい。そう，XPが多くのプログラマから支持されている最大の理由がここにある。

　“楽しさ”という言葉に，違和感を覚える読者がいるかもしれない。ここで言う楽しさとは，プログラマ自身の創意工夫による充実感，それによって優れたソフトをより効率的に開発することによる達成感のことだ。

　これまでのソフトウエア・エンジニアリングは，プログラマに苦痛を与える方向に成長してきたのではないだろうか？ 上流工程と下流工程を分けた分業化は，プログラミングから創意工夫の余地を奪い，単に決められた設計に従ってコードを記述する作業に変えてしまった。行き過ぎた知の形式化は，文書作成に手間をかけるあまり，肝心のプログラミングの時間を奪った。それでもプログラマがこれらの辛苦を受け入れてきたのは，これがソフトウエア開発プロジェクトを成功させる正しい道だと教えられていたためである。

　しかし，XPは別の道があることに気づかせてくれた。XPは本来プログラマが持つ本能のようなものを生かすこと，物事をシンプルに考えてプログラミングに集中できるようにすることこそが，結果としてソフトウエアを効率良く正確に開発する近道であると示しているのだ。

　詳しくは後述するが，XPではユーザーの要求をいかに実装するかを，メンバーみんなで意見を出し合って考える。この過程が，何より“楽しい”のである。ユーザーが要求を提示した段階では，その実現手段は決まっていない。それを，メンバーがわいわい議論しながら，アイデアのある人はそれを具現化できる。「アーキテクト」や「モデラー」，「上流の設計者（デザイナー）」が考えた通りにコードに落としていくだけの作業と比べたら，プログラマにとっては比較にならないほど“楽しい”行為である。