XP変奏曲

原題: Variations on a Theme of XP

Martin Fowler
Chief Scientist, ThoughtWorks

XPの魅力のひとつは、XP を実践するためにやるべきことが、明確に定められているというところにある。さらに、XPのプラクティスはうまく連携するように作られているので、どれか一つでも欠けるとひどい結果になる。しかし、XPや他のライトな方法論を支える原則には「自己適応性」があったはずだ。つまり、プロジェクトの進展に従ってプロセス自体を変えて行くべきだ、ということだ。この考えと、XPの厳格なプラクティス集とは、果たしてどう整合するのだろうか。

• なんで方法論など採用しようと思うのだろうか
• 方法論の改変可能性
• 改変可能性と方法論
• XPとは何か
• XPと自己適応性
• 具体化された XP のバリエーションを作る
• XP とその適用範囲

仮に私が、あるソフトウェア方法論（methodology）を作り出したとしよう（実際にはそんなことをやるつもりはないのだが）。これを Martin's Methodology、略して MM と呼ぶことにする。そこに「俺達は MM を実践しているぜ」と主張するやからが現れたとしよう。でも、本当に MM を実践しているかなんて、どうやったらわかるのだろうか（彼らが成功しているんだったら MM を実践していると認めてやって、失敗しているんだったらそれは MM と認めない、という手もあるのだけどね）。というか、私が判定することに意味があるのだろうか。

これは、ソフトウェアプロセスにつきものの問題である。そして今、この質問がXPや他のライトな方法論に対して問いかけられている。特にXPの場合、厳格に守るべき一群のプラクティスと、明確に区切られた境界条件とを持っているので、これは重要な質問となる。しかし、ThoughtWorks社の私たちを含めて多くの人が、この境界の外側でXPを試そうとしている。いったいどこまで行ったら、もうそれはXPとは呼べない、ということになるのだろうか。

さらに言えば、ライトな方法論の核となる部分は「自己適応性」ではなかったか、という話もある。つまり、プロセスの適用に合わせて、方法そのものを変更することが期待されているのだ。しかしこの考えは、XPの厳格さと相容れるものなのだろうか。

なんで方法論など採用しようと思うのだろうか

この疑問に答えるために、ちょっと後退してこう問いかけたほうがよいだろう：方法論とは、いったい何のためにあるのだろうか。なぜ人は、方法論など使おうと思いたがるのだろうか。私の答えはこうである。方法論を使う人たちは、正しいソフトウェアの開発のやり方に関心を持っている人たちであり、彼らは、ある方法論をなぞっていれば、成功に向かう正しい道にきっとつれていってもらえるはず、と期待しているのだ。

さらにこうも言えるだろう。方法論に従うことで、何か失敗が起きた場合に、「いや、やれることはやったんだよ -- ちゃんと有名な方法論に従っていたんだし」といって自分を弁護しようとしているのだ、と。後者の理由で方法論に従うことはよくやり玉にあげられる。しかし、ある仕事を行うのに所定のプロセスを踏むことが期待されており、もしそうしなかったら、将来、問題に対して責任を問われる可能性が高まる、という規則や規律が多く見られるということも事実である。

どちらの場合にせよ、人々はあるステップを踏襲することで成功のチャンスを増やしたいと考えていることには変わりない。そしてこれは当然である。だって、ソフトウェアの開発の歴史はもう何十年にもなろうというのだ。他人の経験からいろいろと学べていいはずではないか。

方法論の改変可能性

乱暴に言えば、多くの方法論は、その作者が、自分が一回だけやってみたことを参考に述べてみたものでしかない。いや、これはその作者がラッキーだった場合のことだ -- 私はほとんどの方法論は、こうできたら良かったのに、という作者の希望に基づいたものではないかと疑っている。アイデアを思いついた人は何人かいるかもしれない、しかし、誰でもいいからその結果を実際に試したことがあるのか、ということはまた別の問題なのだ。

ソフトウェアはまた、極端に変わりやすいものだ、という特徴がある。まず、ソフトウェアの重要な変数の一つは「人間」である。異なる方法は、人間が違えば働き方も違ってくる。その企業のカルチャーもまたソフトウェアに大きな影響を持つ。さらに、ソフトウェアのスタイルという問題もある。電話機関連の開発のために作られたプロセスが、情報システムやゲームにも適するとはとても思えない。

方法論者の名誉のために言っておけば、彼らの多くがこのことを認識している。人々を単純なステップに従わせるだけで完璧な結果が得られるなんてことはない、ということは方法論者もわきまえている。どうしたって方法論の「適応」やら「調整」やらをしなくてはならないのだ。でも、どう調整しろと指示するのだろうか。方法論を採用した側は、何が「調整の範囲内」で、何が「方法論の否定」につながるのか、一体どうやったら判断できるというのだろうか。

この問いかけはライトな方法論の主導者たちにとって重要な問題である。こういった方法論の主要な特徴に、私の言葉でいえば「自己適応的（self-adaptive）であること」があげられるからである。自己適応的とは、方法論を使うにつれて、その方法論自体を変更していくべきだ、ということを意味している。こうなると、どこまでを方法論のバリエーションと認めるかという境界は、さらに曖昧なものとなるだろう。方法論を使うプロジェクトごとのバリエーションだけではなく、同じプロジェクトの中でも、時間によってある方法論の別個のバリエーションが立ち現れてくるからである。

これが「方法論者の二律背反」だ。ある方法論のバリエーションの範囲を説明しようという時には、方法論で想定していた御利益が利用者の手にキチンともたらされるよう、その範囲を狭めなくてはならない一方で、利用者が自分の状況に合わせて方法論を改変できるよう、どこかに余地も残さなくてはならないのだ。

改変可能性と方法論

方法論の「バリエーションの作り易さ」を考える際に、方法論にも様々なタイプがあることは気に留めておくべきだろう。バリエーション作成の際に課題となることは、方法論のタイプごとに違うからだ。というわけで、以下に方法論の分類をまとめてみる。ここで用いる用語は、この論文のために作り出したものであって、分類が必ずしも厳密ではないことに注意されたい。

まず初めに取り上げるのは、具体化されたプロセスだ。具体化されたプロセス（concrete process）では、実践すべきプラクティスはこれとこれだ、と定められている。具体化されたプロセスのバリエーションは存在しないか、あってもほんの少しだけである。具体化されたプロセスの長所は、プロセスに従うためにやるべきことをかなり明確にしていることだ。しかし明らかに、改変ができないという制約もある。いや、実際には不可能ではないのだが。いつだって利用者のほうは、具体化されたプロセスを採用して、さらにローカルな改変を加えているものだ。問題は「どう改変すべきか」という点を具体化されたプロセスは何一つ示していないという点にある。さらに、もちろん改変を小さいものに留めておけば、プロセスの支持者から認めてもらうことは可能（特に自分のプロジェクトが成功しているならね）だろうが、うるさくいえば改変をした時点でもう、プロセスをはみ出したことになるのである。

具体化されたプロセスだと固定的すぎるので、多くのプロセスは、どう改変すべきかという点も明確に定めるようにしている。こういったプロセスを　調整可能なプロセス（tailorable process）と呼ぶことにしよう。調整可能なプロセスは、正当なバリエーションにはどんなものがあるか、またそれらのバリエーションはいつ使うべきなのか、ということにプロセスの説明の小さくない部分を費やすのが普通である。バリエーションに関するアドバイスを示しているという点では、具体化されたプロセスに対して差を付けていると言えよう。しかし、これでも完全とはいえない。その改変を正しく行うにはどうすべきなのか理解するのは、簡単にはいかないことが多いからだ。何かやろうと思ったら、基本形のプロセスと全てのバリエーションとの両方を理解しなくてはならない。

ここで、プロセスの「サイズ」に着目してみよう。プロセスのサイズとは何を意味するのかというのも難しい問題だが、一つの方法として、プロセスをマスターするまでにどれだけの量を読まなくてはならないか、という基準を用いてみる。すると、調整可能なプロセスのサイズは大きくなるはずである。何をしなくてはいけなくて、何を省略しても構わないのか、全てを述べ尽くすのが調整可能なプロセスだからだ。しかしこれだと、Ｓサイズのプロセスを見いだすためにＬサイズのプロセスを理解する必要が出てくる。小さいサイズのプロセスしか必要としないなら、こんなことはしたくないだろう。

上記のような意味で「調整可能」なプロセスは数多くある。現在もっとも有名なものはラショナル統一プロセス（RUP）である。調整の範囲がこれより広いものはまず見あたらない。あまりにも広いので、 プロセス・フレームワークという名前が付けられている。説明としては、RUP を使う人は実際にはRUPの特定の一インスタンスを使うのであって、自由度の高いRUPの全体までを理解したり使ったりする必要はない、ということになっている。だから、具体化されたプロセスとRUP（調整可能なプロセス）とを同時に使う、ということは十分ありえるのである。私の意見では、このミックスを実践して、でもあまりRUPのほうを気にしていないのであれば、それって具体化されたプロセスを使っているのと変わらないだろう。しかしRUPは、「バリエーションに関する指針」という具体化されたプロセスが持っていないものを示してくれたり、またRUPの他の具体化されたインスタンスを実践しているグループとの! コ! ! ! ミュニケーションを円滑にしたりする上では、助けとなるだろう。

具体的なステップに関することは何ひとつ示さず、むしろプロセスを下支えしている、ソフトウェア開発に関する一つの思想を示すことに特化したプロセスというものも存在する。こういった思想的なプロセス（philosophical process）が柔軟であるのは当たり前で、なぜなら、同じ思想に対して、それに則ってプロジェクトを進めるための方法はたくさんあるからだ。細かいステップやバリエーションの話に踏み込まない分、調整可能なプロセスやプロセス・フレームワークのようなサイズの大きさに陥らずにすむだろう。しかし、思想的なプロセスに具体的なステップが欠けているということは、実践もまた難しくなるということで、じゃあ月曜日に何をすればいいのか、はっきりと教えてくれたりはしないのだ。Jim Highsmith の ASDはこの思想的なプロセスの好例だろう。

プロセスと呼ばれていないかもしれないが、関係の深いものとしてベストプラクティス集という考え方がある。ベストプラクティス集（best practice collection）の例として相応しいのは、McConnel がそのすばらしい著作 Rapid Developmentに収めたコレクションだろう。こういうプラクティス集というものは、それぞれがある程度独立した、開発中に行うと良いことを一グループにまとめたものある。プラクティスの実践は、どんな順番で行っても構わない。思想的なプロセスとは逆に、ベストプラクティス集は部品に着目する。しかし、どのプラクティスを自分のプロジェクトで試すかを決めるのは、最終的にあなた次第、ということになる。

ベストプラクティスの長所は、こんがらがったステップの網の目をたぐるようなことをしなくても、すぐ利用できるという点にある。これは使える、と思ったものだけピックアップすればよいのだ。私自身、いわゆる「方法論」を信用してこなかった人間なので、このベストプラクティス・アプローチを気にいっていた。しかし、XPが私の蒙を啓いてくれたのは、プラクティスは「相互に独立した部品」などではない、ということだ。XPの威力は、個別のプラクティスからもたらされるというよりは、Kentが選び抜いたプラクティス集の、相互作用から湧き出てくるものなのだ。XPのプラクティスを個別に見ているだけだと、その肝心なところを取り逃すことになるだろう。私はこのことから、プラクティスも重要だが、そのプラクティス同士の相互作用も負けず劣らず重要であること、そしてこの相互作用こそが、具体化されたプロセスや調整可能なプロセスがきちんと見据えていたものだったということを、理解したのだった。

つまるところ、どのアプローチにもある意味で不完全である。具体化されたプロセスは、理論上は改変不可能だし、実践の場面でも「改変の手だて」を示してくれない。調整可能なプロセスは、理屈としてはうまくいくが、「調整」を行うためにとんでもない量のマテリアルを理解する必要がある。思想的なプロセスから揺るぎない土台を得られたとしても、具体的にやるべきことは教えてもらえない。そして、ベストプラクティス集はやるべきことを個別に示してくれるが、そのプラクティスの相互作用については、口を閉ざしたままなのだ。

XPとは何か

XPと改変可能性を考えるにあたって、まずXPが、上記の方法論分類でどこに入るかを見る必要がある。「具体化されたプロセス」に分類されることに異論はないだろう。XPには従うべきプラクティスが12個あるし、また、みんなが12個のプラクティスの全てを行うようにとXPの主導者が腐心していることは、関連するディスカッショングループをずっと追いかけていればすぐに明らかになるからだ。あまりに熱心なので、あいつらは自分の意見をしつこく押しつける人々だ、という評判が立ってしまったくらいだ。

しかしXPの魅力は、XPの具体的なプラクティスに惹かれたのではなく、XPの底部を流れる「哲学」に共鳴した人々から産み出されているのだ。XPが関心を示しているのは、適応可能性、人間指向、軽量プロセス、そして創発的なふるまいなどだが、これは抗いがたい組み合わせだ。たくさんの人がXPを、具体化されたプロセスという枠から外れた場所で使ってみようと考えている。

XPの風変わりな特徴で、私がことのほか気に入っていることがある。それは、自分の適用範囲の境界を、きっちりと定めていることだ。多くても十数人くらいの、同じ場所にいる開発者からなるチームで行われることを想定している。この境界はとても明解だ。しかし、境界の外にくるようなプロジェクトであっても、XP には試してみたいと思わせるところがたくさんある。プロジェクトの人数が30人だったらどうなるのだろうか。物理的に隔てられた開発者が多数いる場合には、どうだろうか。「適応可能性」や「人間指向」といった原則は、ここでも必要とされるだろう。であれば、XP になるたけ近づける努力をしても、よいのではないか。

かくして論争の火蓋が切られる。XP を狭くとらえるべきだいう人達と、広く捉えるべきだいう人達との間に起きる論争だ。XP は「ブランド」になってしまったおかげで、論争はさらにヒートアップする。みんな、自分たちが XP を実践していると言いたくてしかたがない。だってそう言うことによって、自分らがどんな価値観と原則に基づいて仕事をしているか、アピール出来るのだから。その価値観は、大規模チームや遠隔地分散チームで仕事をしているときでも、大事なものなのだ。

どこまでを XP と認めるかと、いう公式声明を発する運営委員会など XP にはない。XP にあるのは、非公式な集会を持つという程度のコミュニティであって、そのコミュニティは本件への態度をまだ保留している。XP が、具体化されたプロセス -- 大地に刺さった「くい」-- であって欲しい、とKent は述べている。彼こそはXPコミュニティでのスーパーマンであれば、その見解も影響力が大きい。だから、支配的な見方は「XPは具体化されたプロセスである」となるわけだ。

XPと自己適応性

XPを、かっちりと決められたプロセス、大地に刺さった「くい」と捉えるならば、じゃあこれとXPが自己適応的でなくてはならないという考えと、どうつじつまをあわせるのだろうか。

答えのカギは、XPのために習熟度レベルを定義したらどうか、という質問に対する Kent Beck の言葉にある。こんな質問を聞いたら普通、CMM を連想させる「習熟度レベル」をXPに入れるなんて、と身震いするだろう。しかし Kent は、彼がよくやるように、思慮深い重々しさでもって応じて、みんなを驚かせた。XPには「三段階の習熟度レベル」があると答えたのだ：

• レベル 1 では、本に書かれたとおりに全てのプラクティスを実践する。
• レベル 2 では、XPをローカルな条件に適応させる。
• レベル 3 ではもう、XPを実践しているかどうかなんて、気に止めたりしない。

ここに、自己適応性の萌芽が見える -- XPをやり続けるために、XPを適応させる必要がある。私の言葉で言い替えてみよう：もしイテレーションの六回目になっても、一回目と同じやりかたでXPをやっているんだったら、それはXPを実践していることになっていないのだ。

しかしここで、習熟に至る段階のことを忘れてはいけない。上記の「レベル分け」だと、適応を始める前には、人々が規則通りにXPを実践することを想定している。重要なのは、XPがどう機能するのか、やりもしないで見通すことなど難しいということだ。XPを形づくるプラクティス群は、あなたが全部を試してみてその関連と協調のさまを見ない限り、とてもとらえがたいやり方の連携を行う。効果のほどについて本を読んだり推測したりしても、その場で体験することの足下にも及ばない。信じて欲しい。XPはこうなるだろうという私の予想と、実際に私がC3プロジェクトで見聞きしたこととの間には、大きな開きがあったのだ。

これが、XPを改善するにはどうしたらいいかなどという思索にふける前に、まずは規則通りにやってみろよ、とXP主唱者が強調することが多い理由である。どうしたわけか、この強調は了見の狭い狂信性を呈してしまう。でもそれには理由があって、XP主導者は自分自身が懐疑的であったこと、そして前のやり方に対する固執があったことを思い出すからなのだ。彼らだって、実際に試してみて初めて、XP が、予想しなかったやりかたで動くものだということを認識したのだ。自分が予想できなかったんだから、他人だって予想できないはずだ、と考えるのは当然であり、であれば、その「経験」を経ていない他人の言葉など聞きたくなくなろうというものだ。

具体化された XP のバリエーションを作る

このことは、プロセスを改変可能なものにする方策について別な視点を与えてくれる。この方策は、ある具体化されたプロセスを基礎に置く。こんがらがっているが調整可能なプロセスの使い方にとりくむ代わりに、まずは、明らかに自分の要求に最も合致するものではないとしても、ある具体化されたプロセスを選ぶところから始めよう。この非最適解だが具体的なプロセスとつきあってみる。そうすると、プロセスに関して普通なら見過ごしてしまうような重要なことを学べるだろう。そうなったら、改変を開始する。他のプロセスから知見を借りるのもよいだろう。

ここに、XPにおける「改変」のカギがある。方法論がどう機能するか本当に理解して初めて、その方法論をどう調整すればよいのかも本当に理解できるのだ。複雑で重量級の方法論なら、これだけで労力を費やしてしまうだろう。ライトな方法論は、わずかなプラクティスと、インクリメンタルな開発や学習をサイクルとして行うことへの強い志向とがあるおかげで、ぜんぜん手間にはならない。小さなものに細かい追加を行って改変するほうが、大きなものを細かい削除によって改変するよりも基本的にずっと楽なのだから。

しかし XP 固有の事情として、XPの仕組みの理解で大変なことがある。それは、やってみないかぎり本当に理解するのは困難だということだ。であれば、その「感じ」が充分につかめるまでは、XPを調整しようとするのは非常に注意しなくてはいけない、

一番よいのは、規則通りにXPを行うことでプロジェクトをスタートさせることだ。そして、落ちつくまで二、三のイテレーションを行い、その上で調整を行う。でもほとんどの場合、それをみんなできてないようだ。代わりにみんなは、各種の問題を解決するために、プラクティスを「単品」で適用するはめになっている。後者の方法は実行しやすいが、しかし各プラクティス間にどういう相互作用があるか見落としかねない、と言う大きなリスクがある。であれば、XP プラクティスを「単品」ごとに実践する場合は、XP 全体が機能するところを目撃した人についてもらって、その知識によりガイドして貰うことがより重要になってくると思う。

かくしてXPにおいても、初めに行うべきプラクティスと積むべき経験がある、ということになる。しかしこれははじまりに過ぎない。XP を自分の状況に適応させなくてはならないのだが、それを、XP がうまく機能するとはどういうことか理解した上で行うことが重要だ。しばらくの間は、ここを変えたほうがうまく行くのにと思ったとしても我慢して、XP をなるたけ本に書かれた形式に忠実に行うべきだ。この段階は「学習フェーズ」としてカウントしよう。イテレーションを何回かこなした後になって、適応を始める。その段階での「適応」案は、ここを変えたほうがいいと最初に思った時の「適応」案とは全然違ったものになっているだろう。

XP とその適用範囲

将来、XP とその適用範囲はどうなるのだろうか。ここ ThoughtWorks 社で私達は、XP を、60人程度(その半数が開発者)からなるプロジェクトの基盤として使っている。明らかに XP と呼ぶには大きすぎる数字だ。にも関わらず、これを XP と呼んでいるのは、XP が私達の仕事を導いている哲学となっているからだ。もちろん、これが矛盾だということは否定しようがない。XP と呼ばないほうがよいかもしれない。プロセスを軌道に乗せるため、プラクティスに手を加えたし、またサイズの問題があるので、チーム全体が「規則通りの」XPプロセスを経験したとはとても言えないからだ。

にも関わらず私は、XP がその大地に刺さった「くい」を、きちんと定められた範囲の枠内に収めてくれたほうがよいと思う。私達がここで行っていることは、XP の影響を受けてはいるが、別のプロセスなのだ。このプロセスに名前は付けないだろう。というのも、もう特定のプロジェクトに対してかなり適応してしまっており、これからも適応を繰り返していくのだから、これが XP かどうかなどということは私達は気に止めていないのだ。他のプロセスも似たような立ち現われ方をするだろうし、そうなるべきなのだ。XP に影響を受けたプロセス群が、次々に花開く最盛期を迎える。おそらく、XP を「樹」ではなく「タネ」だととらえるのが一番よいのだろう。

XP を「買う」(といっても購入費はかからないのだが)ことにしたときに、私達が手にするものは「タネ」だ。まずスタートすれば、小さくて、具体的で、それゆえに調整が必要な箇所がどこか把握しやすい、そんなプロセスとつき合ってきたXP コミュニティからの経験をいただくことが出来る。イテレーションを何回かこなすまでは、コミュニティからのアドバイスに従う。しかし次には、アドバイスを元にして、自分の状況への適応を行う必要がでてくる。ここでも経験を便りにするしか無いが、だからといって、XP を使っていたことを「失敗の時のいいわけ(cover your ass)」に用いることはできない。XP に限らず他のライトな方法論であっても、この種のいいわけには使えないだろう。そしてそれは方法論の欠点ではない。ライトな方法論は、最終的にはプロセスそのものをコントロールするくらいの権限を持ったチームで実践しなければ、どのみちうまく立ちゆかないのだ。タネが無ければ幹葉もあり得ないが、どんな庭師にも聞いてみるがいい、タネを撒いただけでは....

© Copyright Martin Fowler, all rights reserved

翻訳: 小野 剛 $Id: xpVariation-j.html,v 1.10 2001/01/19 06:16:16 ono Exp $