XP(2) : とりあえず部分導入
それでもウォーターフォールになってしまう
ウォーターフォールモデルにもメリットがある。その1つはプロジェクトの初期の段階で、システムの規模が見積もれることである。もちろん前回書いたようにソフトウェアの設計書は建築のそれほど厳密ではないため、見積もりも正確なものとは言えない。それでも、現在のビジネスの形態では全体の見積もりを出すことは重要だ。
XPでは、最初に全体のスコープを決定するわけではないので、最終的な完成品の規模が見えにくい。現在のソフトウェア開発はおそらく一括の受託契約というのが主流であることを考えると、このようなビジネスではあまりマッチしないように思われる。
新しい開発手法の導入には、このような契約上の問題や、顧客や上司の説得など、現実的には越えなくてはならないハードルが少なくない。そもそも、私のように1人で活動している開発者は、ペアプログラミングをする相手がいない。ペアプログラミングはXPの中ではかなり重要な要素である。これができないと、XPのいくつかのプロクティスは成り立たない。
このように、誰もがすぐにフルセットでXPを導入できるわけではないだろう。しかし、XPの優れたプラクティスのいくつかは、従来の開発手法の上に、単体で導入しても大きな効果があると思われる。
XPのテスト手法は非常に良い
XPの導入が難しい場合でもとりあえず実践したい事項として、テストがある。これは、本流がXP以外の開発手法を使っている場合でも、とりあえずプログラマ個人レベルで実践が可能で、十分効果があるものだ。
XPではテストを非常に重要視する。その基本になっているのが「テストファースト」と呼ばれる開発スタイルである。簡単に言えば「コーディングと同時（あるいは先）に、常に自動テストコードを書く」という方法である。ウォーターフォールモデルでは、コーディング完了後の手作業の結合テストを重視するが、XPではユニットテストを重視する。しかもテストとコーディングを同時にやるのである。
この結果、すべてのコードに自動テストコードが付属することになるので、将来にわたって品質が維持できる。これにより、将来コードを修正する時に、何かを壊してしまうのではないか。という心配がなくなるのだ。最初は面倒に思うかもしれないが、心配は無用。すぐに効果を実感できるはずだ。
「納期まぎわに機能変更を要求されたが、品質が不安なので断った」「他人のプログラムに手を加えるのが怖い」「何年にも渡って手を加え続けているシステムで、だんだん不具合が増えてきた」こういう経験がある人には是非お勧めしたい。テストコードがあるというだけで、プログラマとして大きな自信が得られるようになるはずだ。
可能ならリファクタリングも
テストが実践できたら、次に導入したいのが「リファクタリング」だ。コーディングしていく過程で、「一応動くが、美しくない」コードを、美しく書きなおす作業がリファクタリングである。従来の方法では、動いているコードに手を入れることは、危険なことと思われていた。しかし、テストコードがあれば自信をもってコードを修正することができるのだ。なぜリファクタリングが必要なのかは、それなりの規模のシステムを書いた経験のある人ならわかるはずだ。
しかし、従来の開発手法の元では、大きなリファクタリングは難しいかもしれない。機能が増えないのに工数を割くことを上司や顧客は認めようとしないかもしれない。工数が表面化しないように小刻みにリファクタリングを繰り返すしかないだろう。
良いコードとは、どういうコードなのか分からない人は、Martin Fowlerの「Refactoring」（邦訳）という本を読んでみると良いだろう。