過去私が残した宿題＝XP

最近、XP(eXtreamProgramming)に関して、調べています。
すっかり市民権を得て、今更？と思われる方もしれませんが、
私にとっては、ちょっとした宿題なわけで…。

XPが日本に登場した際は、相当のインパクトがあったことを
覚えています。
2001年当時、私は新米プログラマーで、この業界の現実に呆然と
しながらも、地上の星を探す毎日を送っていました。

その意味でも、XPはある意味、希望をもたらす思想であったはず
なのですが、その時の私は、こう思って、信じていました。
「絶対、ものにならない。」

絶対、早晩に廃れると思っていました。

内容は、ワクワクするようなモノで、とても関心がありました。
しかし、日本では、このXPのやり方は絶対にできないと、
目の前の仕事を眺めながら、思っていました。

XPのやり方は、現状の日本の開発現場、つまり請負契約を前提とした
開発には適用できないと。
とても若い私「だって、この期間でこの工数でこの機能を実装するって、もう最初からきまっているんだもの」

しかも、当時、XPが上げているプラクティスは全てやらないと、
意味がないっというようなお触れがあったような。
（私の勘違いかもしれません）
そこには、オンサイト顧客や週４０時間労働も含まれるわけで…。

ペアプログラミング！
二人で一台の端末で、プログラミングをする。
このやり方だと、きっと成果は出るはずだ。品質の向上に繋がる。

しかし…、
二人日で、これまでの二人日分の進捗がこなせるのだろうか？
という思いがよぎる。

二人で組んで、二人分以上のパワーを発揮できるのだろうかと？
パートナー次第では、二人がかりで、一人分を少し超えるくらいに
なりかねない。

私は、むしろ、統一プロセスの方の道を信仰していました。

それから、丸5年。

XPは息絶えることなく、アジャイル開発という大きな枠組みの中で、
存在し続けています。
この背景には、重厚なドキュメントベースの重い開発ではなく、軽量プロセスの開発を
求める局面が増えてきたということは、周知の事実。
(今現在、XPが実際の案件でどれだけ適用されているかは、わかりませんが)

私は、過去の自分が残したこの宿題を、真剣に調べてみようと思った。
XPの全てを適用できるケースは少ないかもしれない。
しかし、いくつかのプラクティスは、効果がありそうだ。
あるいは、自分なりに応用してみるのを考えるのも楽しそうだ。
XPのプラクティスには、GTDの雰囲気がある。

というわけで、本当に今更ですが、XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)、
読んでいて、ワクワク感がありました。
このワクワク感こそ、エンジニアが、大切にしたい思いかなと。

もう少し踏み込んだ話は、また別の機会にします。