溜池随想録 #12 「XP（エクストリーム・プログラミング）」　（2010年5月）

XPとは何か

　XP（エクストリーム・プログラミング）は、アジャイルソフトウェア開発手法の中で最も有名なものの一つである。

　歴史を辿ると1996年にスタートしたクライスラー社（自動車産業のビッグ３の一つ）の給与システム開発プロジェクトにその源流がある。このプロジェクトのリーダーであったケント・ベック（Kent Beck）は、その経験をまとめた書籍”Extreme Programming Explained”を1999年に出版している（邦題は『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』、ピアソンエデュケーションから2000年12月に出版されている）。

　XPには、その効果が実証されているいくつかの実践項目（プラクティス）がある。ケント・ベックが”Extreme Programming Explained”で示したプラクティスは12であったが、その後、いくつかのプラクティスが追加、再編され、いくつかのバリエーションが生まれている。ただ、その本質は変化していない。次に簡単にXPのプラクティスを解説しよう。
 

XPのプラクティス

(1) プランニング・ゲーム（Planning Game）
　プランニング・ゲームは、リリース（顧客への公開）の計画とイテレーション（反復）の計画を策定することである。まず、顧客が必要な機能を書き出し、それに基づいてリリース計画を策定する。このリリース計画に基づいてイテレーション計画を策定する。イテレーションの期間は1～3週間で、その間に実行可能なソフトウェアを開発する。リリースはできるだけ頻繁であることが望ましいが、各イテレーションの終了時にリリースする必要はない。
　また、最初から完璧な計画を策定することは不可能なので、基本的に毎週、計画の見直しを行う。
　重要なことは、1～3週間毎に進捗を100%見えるようにすることである。これによって、プロジェクトがどこまで進んだか、次に何をすべきなのかが明確になる。 

(2) テスト駆動型開発（Test Driven Development）
　XPでは、コード（プログラム）を書く前にユニットテストを作成する。このユニットテストは自動化されていることが望ましい。先にテストを書くことによって、開発すべき機能を明確にすることができ、またテストを自動化しておけば、万が一、時間が切迫した場合でもテストを省略しようという誘惑に負ける危険性をなくせる。 

(3) ペア・プログラミング（Pair Programming）
　ペア・プログラミングは、コーディングを常にペアで行うことを意味する。つまり2人のプログラマが1つのディスプレイ、1つのキーボードを使ってコードを作成する。したがって、一人がコードを書いている間、もう一人はそのコードをレビューすることになる。ペア・プログラミングの効率を研究したある論文によれば、表面的にコストは15％程度増加するが、欠陥率が15%改善し、プログラムはより洗練されたものになる。また、ペアを固定せずにローテーションすることによって、プログラミング・スキルの向上、人材育成という効果が得られる。こうした効果を考えると、ペア・プログラミングは有益なプラクティスである。 

(4) チーム全体（Whole Team）
　このプラクティスは、”On-site Customer”と呼ばれていたものである。XPでは、顧客も開発に積極的に参加することが求められる。顧客は契約交渉の相手ではなく、一緒に情報システムを開発するチームの構成員である。開発すべき機能のリストアップやそのプライオリティの決定は顧客の作業であるし、受入テストも発注者側が作成する（少なくともテスト内容の確認を行う）。さらに、開発中の疑問点をすぐに解消するために、開発対象となっている業務について精通している顧客が現場にいることが望ましい。これが難しい場合であっても、開発者の質問にすぐに答えられる体制をとることが必要である。

(5) 継続的な統合（Continuous Integration）
　XPでは1日に何度もプログラムの統合テストを行う。個々のプログラムが修正される度に統合し、テストを行うことによって、システムの不具合を早期に発見できる。これによって、終盤になってからプロジェクトが火を噴く事態を避けることができる。 

(6)　設計改善（Design Improvement）
　設計改善は当初「リファクタリング（Refactoring）」と呼ばれていたプラクティスで、機能を変更することなくコードを書き換えることである。つまり、システムの動作を変えることなく、コードをよりシンプルでわかりやすいものにする。XPでは、プログラム中の複雑な部分をよりシンプルにできるのであれば、誰でも自由にコードを書き直すことができる。リファクタリングを行うことによって、開発メンバーはより簡素でわかりやすいコードを書く能力を磨くことができる。もちろん、書き直したコードはすべてのテストをパスしなければならない。 

　残るプラクティスは次回に紹介しよう。