XP(1) : 新しい開発手法
最近「XP」という開発手法が非常に注目されている。かつて開発手法にここまで関心が集まることがあっただろうか。私自身はまだ導入しかかっている途中、という状況なのだが、この「思想」を知れば知るほど惹きこまれる魅力を感じる。この新しい開発手法について考えてみたい。
ウォーターフォールの何が悪い
現在、最も一般的な開発手法はウォーターフォールモデルだろう。最近はプロトタイプモデルやスパイラルモデルなどの、反復型の開発手法も一般的になってきてはいるが、それでも基本はウォーターフォールを原型としたものといえる。ご存知のようにウォーターフォールモデルは、「要求定義」「外部設計」「内部設計」「コーディング」「テスト」と、順にフェーズをこなして行く開発手法である。この手法では、工程が進んでしまうと、仕様漏れなど手戻りが必要になった時に大変なコストがかかる、という問題がよく指摘されるのはご存知だろう。そもそも、手戻りするようなことになってはいけない。という手法なのである。もしそういう場面になったら開発者は「コストをかけて手戻りするか」それとも「仕様は変えずにその場しのぎでコーディングするか」という選択を迫られることになってしまうのだ。
そもそもこのような開発手法は、建築の世界から習ったものであると言われている。建築の世界では最初の厳密な設計が不可欠である。当然ながら、作っては壊し、作りながら設計する。というわけにはいかないのだ。なぜなら、「設計」の工程に比べて「作る」工程のほうが圧倒的にコストのかかる大きな作業だからである。
ソフトウェアの場合、「設計」と「作る（ここではコーディングのこと）」工程にかかる工数の比率を考えてみれば、建築の手法をそのままソフトウェアに当てはめることが、必ずしも自然ではないことに気が付く。もともとこのような手法は、「設計」の工程に比べて「作る」工程のほうが圧倒的に大きくなければ、成り立たない考え方なのだ。
建築の世界では、「設計者」と「施工者」それぞれに必要なスキルの違いははっきりしている。しかしソフトウェアの世界では、「設計者」と「プログラマ」、必要なスキルの違いは曖昧だ。建築の世界での「設計書」は、その通りに作れば誰が作っても、基本的には同じものができる厳密なものである。本来設計書とは、それさえあれば後は機械的な作業で自動化できるくらいの厳密なものでなくてはならない。ソフトウェアの設計書はそこまで厳密だろうか。そうではないはずだ。そこまで行ってしまったら、それは「コード」になってしまう。それなら最初からコードを書いたほうがいい。
そこでJack Reevesという人は、この当てはめ方が間違っていると考えたらしい。建築で言う「設計書」とは、ソフトウェアでは「コード」のこと。「作る」工程は、実は「コンパイル・ビルド」のことなのではないか。と。
これがXPを始めとする新しい軽量級の開発手法の基盤的な考え方なのである。つまりソフトウェア開発では、コーディングまでが設計なのだ。
この話はMartin FowlerのThe New Methodlogy（邦訳）という論文に大変分かりやすく書いてあるので是非参照されたい。
そこでXP
最近登場してきた軽量級の開発手法のうち、最も有名なものが「XP (eXtreme Programming)」である。従来の開発手法では、最初の設計は、それですべてが決まるほど大事だとされてきた。しかしXPでは初期の設計よりも、「リファクタリング」という方法で、再設計の繰り返しにより洗練させていくことを良しとする。また、従来は絶対に必須だったドキュメント。XPではドキュメントを重視しない。
初期設計を重視せずにドキュメントも書かない？仕様変更に柔軟に対応できる？XPをさわりだけ聞くと、まるで行き当たりばったりのプログラミングのように感じられる。今までとは、あまりにも逆の考え方なので、これまで何年もウォーターフォールでやってきた人にとってはうさんくさく感じるかもしれない。しかし「これがもし本当なら・・」という理想像にワクワクしてくる。
XPについては、優れた解説がWebで読めるので、是非、オブジェクト倶楽部のeXtreme programming FAQあたりを参照してもらいたい。