XPは哲学か
この連載をはじめた時に、「技術論的なことがなく、哲学みたいですね。」と言われた。
ソフトウェアプロセスとの関係
この連載を終えるにあたり、ひとつ述べておきたいことがある。それは、ソフトウェアプロセスとの関係である。
明日を担うもの
今、欧米において、ソフトウェア開発手法は新しいステージに移ったのではないかと感じる。なぜなら、XPを含めたAgile開発手法について、一過性のブームではなく、多くのオブジェクト指向技術の著名な人々が語り始めているからだ。
そのとき、「哲学でしょうね。」と答えた。
これは、新しい開発手法が進めるには、まず、ビジョンやポリシーが必要となるからだ。ビジョンやポリシーを述べるときには、どうしても哲学になってしまうのではないだろうか。何か新しいものを提唱するには、技術論だけではなく、哲学の世界も必要なのだ。
これは、再帰しているのではなく、次の段階を語るには哲学的なものからスタートする必要性があるということだろう。
私の今までの戯言も哲学的なことしかないかもしれない。技術論はゼロと言った方が良い。
ソフトウェアプロセス改善でSPAやCMMがブーム気味に騒がれている。XPは目の敵にされたり、マッピングされたりしている。
XPは開発手法である。ソフトウェアプロセス手法ではない。このことを理解している人が意外と少ない。理解していれば、批判したり、マッピングしたりはしない。要するにそれを唱えている人の成熟度は、本当は低いのかもしれない。
情報システムを開発するには、ソフトウェアプロセスと開発手法がバランスのとれた両輪の輪でなければならないと言うことだ。ウォーター･フォール型テンプレートのソフトウェアプロセスでXPを見てはいけない。XPにあったテンプレートでソフトウェアプロセスを行わなければならない。
私の個人的な考えであるが、XPをうまく行えるプロジェクトは、ソフトウェア成熟度が高いことを前提としている。XPでは、モニタリングや最適化を常に継続的にできることが求められる。短期リリースをすることから、そのサイクルは非常に短期間で継続的に速いスピードで回って行く。しっかりした成熟度を持ったプロジェクトでないとその流れに呑まれてしまい、うまく開発を進めることは出来ない。
しかし、XPを数千人月のシステム開発プロジェクトに適用することは避けるべきである。そのようなシステムは重厚長大なシステム開発手法がマッチする。これは、組織の中の組織を管理していかなければならないからだ。組織の中の人を管理できる範囲なら、XPは可能であろう。（例えば、学校を考えると、クラス程度なら人として管理、学年となると組織として管理となるであろう。）
いずれにしても、ソフトウェアプロセスと開発手法は、ともに助け合うもので相反するものではあってはならない。うまくバランスを取り、両輪の輪として適用して欲しい。
これは、XPを含めたAgile開発手法が、明日を担うソフトウェア開発手法なのかもしれないからだ。
だが、日本においては、「ソフトウェアの失われた10年」により、オブジェクト指向技術が一つの開発手法として確立されたとは言い難い。ましてや、この新しい開発手法のステージについてとなると哲学的なこととなり、ますます理解されにくくなっている。
そのような状況では、XPがただのブームとして、Agileが風疹のように騒がれるだけに終わることは十分危惧される。
Kent Beckの愛読書は、宮本武蔵の五輪書のようである。ひょっとしたら、XPの極意は五輪書かもしれない。そうだとしたら悲しいことである。日本の心が日本で受け入れられないことになるからである。
XPが明日を担うもの、もしくはそれを導くものならば、この戯言も何かの一石を投じたのではと考える。非常に、小さな石ではあるが。
しかし、明日を担うものを望まない人達には、戯言もただの塵と化すであろう。
今日、そして明日においてもソフトウェア開発者を名のり続けたい人には、明日を担う開発手法を求めて行って欲しい。望まない人には、必要ないであろう。彼らには明日がいらないのだから。
【参考文献】