新しいソフトウエア開発手法


新しいソフトウエア開発手法


(original: The New Methodology)

マーチン・フォウラー
チーフサイエンティスト , ThoughtWorks

過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。

(訳注:翻訳にあたり、著者より提供された参考文献(WEBサイト)リストを元に参考文献一覧を追加し、本文中にその一覧との相互リンクを埋めこんでいます。キーワード自体のリンクは原文と同じ英語サイトへのリンク、その前の*は参考文献一覧の該当項目へのリンクになっています。一部の項目では、そこから訳書や日本語に翻訳されたサイトを参照できます。)

開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ

ソフトウエアの開発は「書いては直し」という言葉がピッタリなドロドロの仕事になりがちだ。ソフトウエアは無計画に書かれ、そのデザインは近視眼的な決定をつぎはぎしたようなものが多い。小さなシステムならば、そういうやり方でもなんとかなるがシステムが大規模になればなるほど、新しい機能を追加することがどんどん難しくなる。そういうシステムで見られる典型的な徴候は、「完成」したはずのシステムを異様に長時間テストしている、という状況だ。そのような長時間のテストによりスケジュールは大混乱となってしまう。なぜならば、テストやデバッグがスケジュールできないからだ。

我々はこういうやり方で長い間なんとかやってきたが、一方で別のやり方も昔から知っている。「開発手法」というやつだ。開発手法は、ソフトウエア開発のプロセスに規律を押しつけることで、開発がもうちょっと予測可能で効率的に進むことを目標としている。そして、他の分野におけるエンジニアリングの開発手法から発想されたもので、事前にプロセスを計画することに異常にこだわる。

こういう開発手法というやつが出現して随分になるが、これですごくうまく行ったという話はあまり聞かない。これが人気を博したという話は、さらに聞いたことがない。開発手法にはいろいろ文句がつくが「それは官僚的だ」というのが代表的だ。開発手法のとおりにやろうとすると、手間が多くなりかえって開発が進まないものだ。こういう開発手法は重量級と呼ばれたりする。* Jim Highsmith'sあたりはmonumental methodologies(たいした開発手法だね)とまで言ってる。

それで、これはちょっとやりすぎだろうということで、ここ数年、一群の新しい開発手法が生まれてきた。まだ名前がついてないが、昔の「重量級」のものと区別して「ライトな」開発手法と呼ばれている。昔の「重量級」開発手法が官僚的だとボロクソに言ってた人は、みんなこの流れが結構気にいってるみたいだ。「ライトな」開発手法は、「手続きゼロ」と「手続きだらけ」のちょうどいい妥協点を探る試みで、最も効果を生むちょうどいいくらいの手続きを提供しようとしている。

その努力の結果、「ライトな」開発手法では重量級のものと全然違う所にポイントを置くこととなった。一番ビックリすることは、ドキュメントにこだわらないことだ。というか、各フェーズのドキュメントの量は少い方がエラいんだ、みたいなことを強調する。じゃ、何が大事かって言ったら、コードだ。ソースコードこそが最も重要なドキュメントの構成要素だ、と言うのだ。

でも「ライトな」開発手法ってのはこれだけだと言われると、私はちょっと違うと思う。ドキュメントを書かないっていうのは単なる徴候であって、もっと根本の違いに目を向けるべきだと言いたい。

これから、その違いを詳しく見て行こう。適応的かつ人間中心の開発プロセスとはどんなものか、その長所と短所、そして、開発者としてであれ顧客(エンドユーザ)としてであれ、採用すべき価値のあるものかどうか、そういうことがわかるように説明していくつもりだ。

予見的手法 対 適応的手法

デザインとモノ作りを分割する

これまでの開発手法は、建築関係や機械工学から知恵を借りてきている。そっち方面では、モノを作る前に計画をたてることが絶対条件だ。そして設計者は、作るためには何が必要で、どう組み合わせるかを細かく指定した設計図を何枚も書く。橋にかかる負荷をどう処理するかというような、設計上の選択肢は設計図を書く時点で決定できる。そして、設計図は全く別のグループ、別の会社に手渡され、彼らが実際にモノを作ることになる。モノ作りは、ちゃんと設計図にのっとってやることになっている。実際には、モノ作りをする人たちも問題に直面するだろうが、たいていほんのちょっとしたことだ。

設計図を見ればどういう部品を使って、どういうふうに組み合わすのかすぐわかるので、設計図をもとにして、モノ作りのプランを細い所までたてることができる。そのプランを見れば、なすべき作業や作業同士の前後関係もちゃんとわかる。だから、スケジュールも予算も事前に確定しやすい。また、作業をする人がどう動けばいいのかもプランにきちんと書いてある。そういうわけで、モノ作りには熟練の技は必要であっても頭を使う必要はない。

だから、次の2つは根本的に違う作業工程なのだ。予見することが難しく創造的な人がやんなきゃだめなデザインと、予見することがずっと簡単なモノ作りだ。そしてデザインが終わればモノ作りの計画をたてることができる。計画があれば、実際のモノ作りを終りまで見とおすことも簡単だ。また、建築ではモノ作りデザインよりずっとたくさんの費用と時間を必要とする。

それで、多くの開発手法は(建築をみならって)こういう方向に持っていこうとする:「あまりスキルのない人でもちゃんと動けるような、仕様書があればいいのだ」そのためには「デザイン」と「モノ作り」を分割する必要がある。目標は、「モノ作り」が単純作業になるような「デザイン」であり、そういう「デザイン」のための開発手法が必要とされている、ということだ。

で、こういう発想から何が産まれただろうか?「それがUMLのような設計書の役割だろう」って言う人もたくさんいるだろう。確かに、難しい所・・・設計上の決定がUMLの上で全部できちゃうとしたら、建築屋さんみたいに「モノ作り」のプランをたてて設計書をコーダーに渡して、後は知らん顔したってかまわない。

だけどここでちょっと考えてほしい。あなたは、本当に何も考えないですぐにコードが書けるような設計書ってものを見たことがあるかな?ある?それじゃ、その設計書を書くのとコードを書くのとで、どっちが時間がかかった?同じくらいの時間がかかったんじゃ、こういうアプローチをとる意味がないような気がするんだけど、どうかな?

ということを考えていると問題は次のようになる。まず、黙ってプログラマーに渡してハイ終わり、と言えるようなUMLなどの設計書を書くことがどれだけ難しいかということ。そういう設計書はみためかっこいいんだけど、いざプログラムに落とそうとするとボロボロで使えない、ということが問題なのだ。建築屋さんは、現場で何年も揉まれたちゃんとしたモデルを持っていて、それで仕事をする。しかも、連中のする「デザイン」のキーポイント、例えば力学的な検討とかは数学的な解析になじみやすい。それに引きかえ、我々がUMLのような図に対してできるチェックと言えば、せいぜいピアレビューくらいのものだ。ピアレビューだって役にたつことは役にたつが、エラーを見落してしまって、コーディングやテストになってから問題が露見するということもよくある。ちゃんとした設計者でも(一応、自分もそのつもりなんだけど)、設計書を実際のソフトウエアに落としてみて驚くこともよくある。

もうひとつのポイントは費用の割合だ。橋をかけるような仕事では、「デザイン」のコストはせいぜい全体の1割だ。一方、ソフトウエア開発では、コーディングの占める時間はずっとずっと少ない。*McConnellによると、大規模プロジェクトでは、コーディングと単体テストにかかるのは15%だけだそうだ。つまり、橋の場合とほとんど逆の結果となる。全てのテスト工程を「モノ作り」の方に入れても、「デザイン」は依然として半分を占めている。だから、他の分野のエンジニアリングにおける「デザイン」の役割と、ソフトウエアのそれを比較するのはどこかおかしいのではないか?という疑問がわいてくる。

Jack Reevesは、これと同じようなことを考えているうちに「実はソースコードが設計書で、(建築でいう)モノ作りに相当するのは、コンパイラーとリンカーを動かしてる時間だけじゃないだろうか」とか*言いはじめた。確かにそうだ。「モノ作り」というからには、完全に自動化できる作業じゃないとおかしい。

以上のことから、私の結論としては以下のとおり。

だいたい仕様を予見できたことがない

私は問題のあるプロジェクトに突っこまれたことがたくさんあるが、どこでも必ず耳にする言葉がある。開発者たちは私の所に来て「このプロジェクトの問題点は要求仕様がコロコロ変わることなんだ」と言う。それはあたりまえのことであって、みんなが揃ってそのことを何かとんでもないことのように言うのが、私には一番不思議だ。ビジネスに関わるソフトウエアを開発するなら、要求仕様が変わるってことは、ノルマくらいに考えるべきだ。問題は、それにどう対応するかだろう。

ひとつの考え方は、要求仕様が変わることを要求分析がヘボだからだとみなすことだ。要求分析の背後には、こんな考え方がある。開発に入る前に、要求の全体像を文書化して顧客のハンコをもらって、ハンコをもらった限りはちょっとやそっとで変更を許さないように、その手続きを決める。

このやり方の問題点は、要求の中にある選択肢を理解するのが難しいということだ。開発する側の組織が要求分析の時にコストに関する情報を提供しないと、これはより難しくなる。例えば、車にサンルーフをつけようとして、それが1000円なのか100万円なのかセールスマン自身がわかってなかったら、決断しようたって無理だ。あなたは、これと同じような状況で立往生することになるだろう。

見積もりが難しい理由はいろいろある。ひとつには、ソフトウエアの開発が「デザイン」であるからだ。「デザイン」だから、プランをたて費用を見積もるのは難しい。また、基本的な素材がすぐに変化していくこともある。さらに、個人に依存していることも理由のひとつだ。個人を予見したり数量化することが難しい。

ソフトウエアが目に見えないものであることも考慮する必要がある。ソフトウエアの機能がどのような価値を持っているかは、実際に触ってみるまでわからない。本当に価値ある機能を見ぬくためには、早期の開発バージョンを使用してみるしかない。

こういうわけで、人々が要求仕様を決定できないという皮肉が生まれる。結局、みんなソフトウエアがソフトであってほしいのだ。要求仕様は変化するものだ?・・・甘い、甘い。要求仕様は変化するべきなのだ。顧客に要求仕様を決定させるにはエネルギーがいる。特に、顧客がソフトウエア開発をかじっているとたちが悪い。だって、ソフトウエアをいじるのは簡単だってことがバレバレだから。

それにね。もし、そういうゴタゴタをなんとかやりくりして、正確で固定した要求仕様書を手に入れられたとしても、あなたには悲惨な運命が待っている。現在では、経済やビジネス自体が流動的で、そのためにソフトウエアの価値も凄い勢いで変化してしまう。完璧な要求仕様書があったとしても、それは半年とはもたない。顧客が仕様を固定させたとしても、顧客をとりまくビジネスの世界がそんな悠長なことを許してくれない。さらにビジネスの世界に起こる変化は、誰にも予知できない。「予測した」と言いはる奴もいるが、そういう連中が株で大儲けしたって話は聞かないなあ。

そして、ソフトウエアの開発は全て要求仕様に依存している。きちっと固定した要求仕様が書けないとしたら、事前に計画をたてるっていうのは、不可能だと思う。

予測は絶対に不可能なんだろうか?

私は予測がどういう状況でも絶対に不可能だとは言ってないよ。実際、そういう環境でソフトウエアが開発されたケースもある。NASAのスペースシャトルのソフトを作ったチームなんかは典型的な例だ。ただ、そういうのはおおげさな儀式と途方もない時間とたくさんの人間を必要とする。もちろん「凍結した要求仕様書」もね。だけど、普通ビジネスで使うソフトウエアはこういうふうにはいかない。全く違うプロセスを必要とする。

一番危いのは、できるはずがないのに予見可能なプロセスに従おうとすることだ。だいたい、何かの開発手法にハマちゃってる奴はその開発手法がピッタリ来るケースと、そうでないケースを見わけることができないんだよね。ってゆうか、その開発手法が誰にでも通じるものだと思いたがってて、それが適用可能な領域とそうでない領域を区別する必要も感じてない。そういう連中が、開発手法を間違った環境で使おうとしてハマっちゃうのさ。典型的な間違いが「予測(計画)を前提とした開発手法を予測不可能な状況で使ってしまう」こと。

まあ、そういう連中の気持ちもわからないでもない。私だって、いろんなことが予測可能だったらすごく気持ちいいと思う。しかし、できない予言をできると思いこんじゃうと、プランを必要以上に早いタイミングで作っちゃうことになる。しかも、そのプランがダメになった時に、お手あげになっちゃってドツボに陥る。プランは現実とだんだんと遊離していく。最初のうちは大丈夫大丈夫と言ってられるだろうが、いずれ、そうは言えなってプランを捨てることになる。たいていそれには痛みが伴う。

だから、もし予測が不可能な状況にいたら、予測を前提とした開発手法は絶対に使ってはいけない。使ったらひどい目にあうだろう。無理して使っても、プロジェクトをコントロールしたり顧客とやりとりするモデルはほとんど使えないと言うことだ。ものごとが予測可能だったら何もかもうまくいく。それだけに、そうでないという現実を受けいれるのは難しい。「問題」というものはえてしてそうだけど、「問題」の一番問題なことは「問題」が存在していることを認識することだ。

予測可能性を手離したらと言って、必ず制御不能の混沌が待ってるということじゃない。ただ、予測不可能性とうまくやってけそうなプロセスを必要とするということだ。「適用的」っていうのは、実はそういうことなんだ。

予見不可能なプロセスをコントロールする

では、この予測不可能な世界に住む我々自身をどうやってコントロールしたらいいだろうか?最も重要だが困難なことは、正確に自分たちの住む世界のことを知ることだ。我々には、現在の状況がどうなのかを、そのつど繰り返し正確に報告してくれる正直なフィードバックメカニズムが必要なのだ。

このフィードバックのための鍵は繰り返し型開発手法だ。これは別に目新しい考えではない。繰り返し型開発手法はいろいろな名前をつけられているが、前からある・・・インクリメンタル、進化的、ステージ型、スパイラルなどなど。繰り返し型開発手法の鍵は、最終的なシステムの別バージョン(機能は限られるが実際に動くもの)を何度も作り出すことだ。別バージョンは、機能的には不足があってもいいが最終成果物に対する要求には忠実にできてないといけない。そして、完全に統合化されていて本番システムと同じように注意深くテストされているべきだ。

ポイントは、テストされ統合されたシステムによって、プロジェクトに「現実」の重みをそそぎこみ、現実から遊離しないようにすることは不可能だ、ということである。ドキュメントには全ての種類の欠陥を隠すことができる。テストされていないコードにはたくさんの欠陥が残ってしまう。 しかし一旦、人々が実際にシステムの前にすわって、それに触れてみれば欠陥は一目瞭然、現実のものとなる。バグであれ、間違った要求であれ。

繰り返し型開発手法は、予見可能なプロセスに適用しても意味がある。しかし、変化する仕様を扱う適応的なプロセスにおいてこそ欠くことのできないものである。そして、長期計画は流動的で、はっきりした工程があるのは繰り返し一回分の短期計画だけ、というスタイルのプランニングを導く。さらに、繰り返しのたびにしっかりとした基礎を築き、それが次回のための基盤となるのだ。

繰り返しの長さはどれくらいがいいのか、ということは重要な検討項目である。人によって答は違う。XPは1週間から3週間、SCRUMは1ヶ月、クリスタルはもっと長い。ただ、全体的にはなるべく短くした方がいいと言う者が多いようだ。短くするほど、フィードバックの間隔も短くなり自分の位置を確認できる機会も多くなる。

適応的な顧客

この類の適応的プロセスは顧客との関係も、普通考えるのと違うやり方を要求する(顧客と開発者が違う会社の場合は特に)。普通、ソフトウエア開発のために外注を頼むとしたら、料金を固定して契約することを望むだろう。開発者に必要なことを伝え、入札させて選択する。そしたら、ソフトウエアを開発する責任はその会社のものになる。

固定料金で契約しようとしたら、確定した仕様が必要となり予見できるプロセスも必要となる。適応的プロセスや未確定の仕様があるならば、固定料金といういつもの概念では仕事にならない。固定料金モデルを適応的プロセスにあてはめようとすると、苦痛に満ちた爆発が待っている。やっかいなことは、開発者の会社と全く同じく顧客側の会社もダメージを受けることだ。なんだかんだ言って、ビジネス上の必要がなければソフトを発注することもない。そのソフトができなければ、顧客のビジネスも苦しむ。支払いのあるなしにかかわらず、それは損失なのだ。実際は、払うはずだった金額よりその損失額の方が大きい。だって、ソフトに開発費用がそれが産みだすビジネス上の価値より大きいわけはないからね。

だから、予測可能を前提としたプロセスが使えっこないとわかってるのに、固定料金の契約にサインすると言うことは、お互いに危い橋を渡ることになる。つまり、顧客の側もやり方を変えなくちゃいけないと言うことだ。

適応的プロセスでは、顧客はソフトウエア開発をもうちょっときめ細かくコントロールする必要がある。繰り返しのたびに、毎回、顧客は進捗をチェックしてソフトウエア開発を方向づけなくてはいけない。必然的に、顧客と開発者の関係は密になる。本当のビジネス上の提携関係になる。そういう深い関係を必要としない顧客もいるし、必要としない開発者もいる。しかし、適応的プロセスをうまく機能させようとしたら、これは絶対に必要なことだ。

顧客にとってそれで何が嬉しいかと言うと、打てば響くようなソフトウエア開発ができることだ。余分なものは何もないが本当に使えるシステムがすぐに手に入る。とりあえず使ってみれば文句も出てくるしビジネスも変化していくだろう。その流れにそって、システムを修正していけばいいのだ。

人を一番前に置くこと

適応的プロセスを実施することは簡単なことではない。特に、開発者のチームがとても効率的に動かないとまず駄目だろう。個人個人も質が高くなくては駄目だし、みんなが力を合わせる方法も効率的でないとうまくいかない。適応的プロセスはデキる奴が必要だが、どういうわけかデキる連中はそういうスタイルが好きなんだ。

交換可能な部品

これまでの開発手法が結局何をしたいのかと言うと、人間を交換可能な歯車にすることだ。そういうプロセスでは、人間は種類ごとに分類された資源として扱われる。「アナリスト1丁、コーダー4丁、テスター3丁、マネージャー1丁」みたいな感じで。連中が欲しいのはひとりの人間でなく、単なる役割なんだ。誰が来るかはどうでもいい、人数を揃えればいい。プランに関係するのは人数だけだから、それがわかればいいんだ。

こういうやり方をしてたら「本当にソフト開発に関わる人間は交換可能なパーツなんだろうか?」という疑問が浮かんでくる。「ライト」な開発手法で最も大事なことは、そういう考え方を断固として拒否することなんだ。

たぶん、「人を資源のように見るのはイヤだよ」って一番ハッキリ口にしてるのは Alistair Cockburn だろう。*Characterizing People as Non-Linear, First-Order Components in Software Developmentという論文の中で予測可能なプロセスは予測可能な部品を要求する(プロセスを予測可能にしたがる人は、部品が自分勝手に動き回っちゃ困ると考える)ということを強調している。だけど、人間は予測可能な部品じゃない。彼は、さらにソフトウエアプロジェクトについて研究を進め、人間こそがソフトウエア開発で一番大事な要因だ、という結論に至った。「この論文のタイトルで私は人間のことをあえてcmponents(部品)と呼んでいる。開発手法の中で人々はそういうふうに扱われている。このアプローチで間違っていることは、人間がとても可変的で非線形的であり、ユニークな成功モードと失敗モードを持っていることだ。この要因こそが、第一に考えるべきことでこれを無視するなんてとんでもない。プロセスの失敗と、それを引き起こす方法論の設計者たちが、プロジェクトを明後日の方向へ追いやってしまうんだ。よくあることなんだけど。」

「人間中心のソフトウエア開発」のことを、Cockburn みたいにズバズバ言う奴は他にいないが、ソフトウエアについてモノを考える人で、人間優先ということをテーマにしている人はけっこういる。だが、人間という概念をプロジェクト成功のための一次的要因とするなんてことには、これまでの開発手法は大反対してきた。それが問題なんだ。

このことが、強力なフィードバック効果を産んでしまう。もし、あなたが開発者が交換可能な部品であることを期待したとする。そしたら、チームは個々の人間で構成されていることを忘れてしまう。みんなやる気をなくし、生産性も落ちる。そして、デキる奴はみんな逃げ出してしまい、最後にあなたは期待どおりのもの・・・交換可能な部品を発見することになる。

人間が最初だと決めることはちょっとした決断であり、決断力がなかったらそれを通すことはできない。開発者とは人月だという概念は、ビジネスの中に深くしみこんでいる。なんたって、*フレデリック・テイラーの科学的管理アプローチ以来のことだからね。工場を経営するなら、テイラー信者のやりかたも意味がある。しかし、とても創造的でプロフェッショナルな仕事、ソフトウエア開発は当然そうだと思うが、についてはそうは言えない。(実際には、あっちの方でも今はあまり流行らないみたいだけど)

プログラマーは責任あるプロフェッショナルだ

テイラー信者の中心的な概念とは、現場で仕事をしてる連中にはどうやったら仕事がうまく運ぶかわからない、という考え方だ。工場では、これが成り立つ理由がいくつかあるだろう。ひとつには工場労働者の中には知的で創造的な人があまりいないからだ。また、管理者だけいい給料をもらって労働者の取り分が少いことから、両者の間に緊張があることも理由のひとつだろう。

ソフトウエア開発では事情が違うってことが、だんだんと見えてきた。だんだんと、明晰で能力のある人たちがソフトウエア開発に、その輝きと大きな報酬に魅力を感じて飛び込んできている。(かくゆう私もその2つに魅せられて電子回路のエンジニアリングから転向したクチだ)ストックオプションみたいなシステムでさらに多くのプログラマが呼び寄せられている

(このことには世代的な影響があるかもしれない。より多くの頭のいい人がソフトウエア業界に来るようになったというのは、ここ10年くらいのことだよね。私にはそんな気がするけど。もしそうなら、コンピュータビジネスに「若さに対するカルト的崇拝」があるのもうなずける話だ。ほかのカルト的崇拝と同様に、ひとつぶくらいの真実が、そこに無くてはならないからだ。)

もしできる人を雇って逃がさないようにしたいなら、連中は目端がきくプロフェッショナルだということを肝に命じておくべきだ。技術的な仕事をどうやって運営するかの決断は、彼ら自身にさせるのが一番いい。管理部みたいな部署でやり方を決めるテイラー流の概念は、その管理部の人間が現場よりどうすれば仕事がはかどるかわかってる場合にしか使えない。ヤル気マンマンで切れる人間が仕事をする時は、話が違うんだ。

人間中心のプロセスを管理する

人間指向と言っても流儀はいろいろある。流儀によって効果が違うし、なかには全く逆のことを言っている場合もある。

重要な鍵となる要素としては、プロセスを自分から取り入れていくのはOKだけど、押し付けられるのはゴメンだよ、ってことだ。まあ、そういうことが好きなおエライさんもよくいるけどね。上が押し付けるから、下の者はムキになって逆らうんだ。ましてや、おエライさんのために実際に開発する時間がなくなったりすれば、なおさらだ。プロセスを受けいれるということは、ある意味自由を失うことだ。それだからこそ、チーム全員が納得してそれに全面的にのっかってくれないとマズいんだよ。

だから、適応的なプロセスに従うという選択ができるのは開発者自身だけだ、という興味深い結論が得られる。これは、守るべき規則がたくさんあるXPで顕著である。クリスタルは、規則は少い方がいいという大目標のために、この点については効果的な補足項目を用意している。

もうひとつのポイントは、開発者が全ての技術的決定を行うかどうかだ。XPはこの点では徹底していて、プランニングプロセスでは、仕事にどのくらいの時間がかかるかの見積もりをするのは、絶対に開発者だと言いきっている。

管理職の立場にいる人にとっては、そういうふうに技術者にまかせるのは、かなり大きな変革だ。そういうやり方は、プロジェクトのリーダーシップにおいて開発者と管理者が同等の地位を占め、責任を分かちあうことを必要とする。同等と言ってることに注意してほしい。それでも管理者には役割があるが、開発者の方に専門知識があることを認識しなくてはダメだ。

このことの重要な理由は、この産業の技術革新のスピードだ。数年かそこらで技術的な知識は時代遅れになる。他のどの産業より、技術的なスキルの半減期が短い。現役の技術者も、もし管理職になったらすぐに自分のスキルがひからびてしまうことを認識しなくてはならない。元技術者なら、自分のスキルはもはや存在しないも同然で、現役の開発者を信頼して彼らに頼るしか道はないのだ。

ビジネス的リーダーシップの役割

しかし、技術者が全てのプロセスを実施することはできない。業務上の必要に対するガイダンスが必要だ。このことから、適応的プロセスの重要な側面が導かれる・・・開発者は業務の専門家と密に接触を保つこと。

だから、ビジネスの役割は普通のプロジェクトより大きくなる。「ライトな」開発手法で運営するチームは、コミュニケーションが粗では存在できない。継続的に業務の専門家にアクセスする必要がある。それは、管理者のレベルで扱えばいいというレベルではない。全ての開発者の目の前に存在してないとダメだ。開発者は、彼ら自身の仕事については有能だしプロフェッショナルだが、別の仕事のプロフェッショナルと一緒に仕事をする必要がある。

もちろん、こうなる理由は適応的開発の性質のためだ。適応的開発では、物事が素早く変化するというのが根本的な前提なので、その変化を知らせるべき人と常に一緒にいる必要がある。

一生懸命やった仕事が無駄になってしまうことを、開発者は何より不満に感じる。だから、業務の専門家が必要だ。そして、その人は常に開発者の側にいなくてはいけないし、開発者が信じるに足るだけのそれなりの人でなくてはいけない。

自己適応的プロセス

ここまで私は、顧客の要求がたびたび変化するという観点から適応性について説明してきた。しかし、もうひとつの観点がある・・・プロセス自身の適応性だ。適応的プロセスを使って開始したプロジェクトは、1年後に全く同じプロセスを使用しているとは限らない。チームが彼ら自身のためにもっとうまいやり方を発見し、プロセスを合わせていくということがたびたびあるだろう。

自己適応性の最初のパートは、定期的にプロセス自身をレビューすることだ。普通は、これは繰り返しのたびに行う。繰り返しが一回終わったら、次の質問を自分自身にしてみるといいだろう。

この質問が、次回の繰り返しのプロセスをどう変えるかのアイディアをもたらすだろう。このようにして、最初は問題だらけのプロセスがだんだんと改良されていく。そして、それを使うチームにピッタリのものになっていく。

もし、自己適応性がプロジェクトの内部で起こるとしたら、組織をまたいで注目されてもいい。自己適応性を深めるために、プロジェクトの大きなマイルストーンでは、もう少し本格的なレビューをすることをお勧めする。Norm Kerthが、そういうプロジェクトをふりかえるためのセッションのやり方の概説しているので、それに従えばいいだろう。そういう回顧は、ちょっと場所を変えて訓練されたファシリテーターを呼んで2〜3日かけて行なった方がいい。それは、プロジェクトのメンバーだけでなく、組織全体に参考になるものを提供するだろう。

自己適応性の究極の形では、もはや会社共通の開発手法は必要としなくなる。そのかわりに、それぞれのチームが自分のやり方を選ぶ。それどころか、積極的にそのやり方をプロジェクトに合わせて調整していくのだ。本に書いてあることや他のプロジェクトの経験は、基本とヒントを提供するが、開発者たちは、自分の責任でそういうものをどんどん改変していってもかまわない。

こういう自己適応性という概念は、ASDとクリスタルによく出てくる。XPはルールがキチキチなので、そういうことが許されてないように見える。

方法論カタログ

「ライトな」という名前に値する開発手法はいくつかある。どれにも共通の特徴がたくさんあるが、はっきりとした違いもある。この短いサーベイでは、全ての特徴をあげることはできないが、少くともあなたが探す場所を見つける助けにはなるだろう。

XP (エクストリーム・プログラミング)

「ライトな」開発手法の中でも、これが一番注目を集めている。ひとつにはXPのリーダたち、特に Kent Beck が注目を集めることに能力があるからだろう。また、彼は人々を集め引っぱっていくことにも秀でている。しかしながら、XPが有名になりすぎたことで困ったこともある。XPによって、他の開発手法、その価値あるアイディアが押し出されてしまっている。

XPのルーツは、Smalltalkコミュニティだ。Kent Beck と Ward Cunningham の緊密な協力関係の中から、1980年代後半に産まれた。90年代前半に、ふたりともその時の経験を非常に多くのプロジェクトの中で洗練させていった。そして、適応的で人間指向のソフトウエア開発へのアプローチを発展させていった。

ウチワだけの実験から、ちゃんとした開発手法への決定的な一歩は、1996年の春に踏み出された。この時 Kent は、Chryslerの人事システムの進捗をレビューするように要請された。このプロジェクトは、ある会社によってSmalltalkで開発されていたが、トラブっていた。コードの出来はひどいものだったので、Kentは、全てのコードを捨ててゼロからやりなおそうと言って、リーダーシップを取った。その結果、初期におけるXPの旗艦であり訓練所となったChrysler C3 project (Chrysler Comprehensive Compensation)が産まれた。

C3の最初のフェーズは、1997年初頭に稼働した。このプロジェクトはその後も継続し、後に困難に直面した。そして、1999年に新規の開発は中止された。これを書いている時点で、そのシステムが10000人の従業員の給与を支払っている。

XPは4つの価値から始まる・・・コミュニケーション、フィードバック、単純さ、そして勇気だ。次にXPプロジェクトが従うべき、12のプラクティスが続く。多くのプラクティスは、歳月を経て試練に耐えてきたテクニックだが、ほとんどの計画的プロセスを含め、多くの人からは忘れ去れてしまっていた。XPは単にそれを復活させただけではない。XPはひとつの全体性へとそれをつむぎあわせ、強化した。

XPはテストを非常に重視する。私はまずそこに注目したのだが、この点でXPは急所をとらえてると思う。テストに言及しない開発手法はないけど、テストはどうでもいいような扱いになっていることが多い。ところが、XPではテストこそが開発の基礎である。全てのプログラマーは、実際に稼働するコードを書くのと同時にテストのコードも書く。そのテストコードは、継続的なビルドのプロセスに統合化されて、さらなる開発のための確かな基盤となる。

この基盤の上にXPは漸進的な設計プロセスを構築する。そのプロセスは、素朴な原型システムを繰り返しのたびに「リファクタリング」していくことに依存している。設計は今回のするべきことだけに集中し、先々必要となる要望などは一切考慮しない。

XPは幅広いリーダーシップを開発してきた。多くはC3プロジェクトから湧きおこったものだ。その結果として、たくさんの情報ソースがある。現時点で一番いい*サマリーは、外部の人間である Jim Highsmith のものだ。彼自身は別の開発手法を提唱しているのだが、それについては後程触れることにする。Kent Beck は *Extreme Programming Explainedという本を書いている。これは、XPのバイブルであり、この開発手法の背後にある理論的根拠を説明している。XPを徹底的に追求したい人にも充分な情報を提供している。

さらに2冊の本が、現在執筆中である。C3プロジェクトのメンバー3人、Ron Jeffries Ann Anderson Chet Hendrickson が*Extreme Programming Installedという本を書いている。これはC3プロジェクトの経験をもとにXPを説明した本だ。Kent Beckと私は、*Planning Extreme Programmingを書いている。こちらは、適応的なやり方でどうやって計画するかを議論したものだ。

本と同様、WEBにもたくさんの情報源がある。初期にXPの支持者を集め、XPのアイディアがまとめられたのは、Ward Cunninghamの*wiki web という共同執筆環境の上だ。wikiは今でも探検するだけの魅力をそなえている場所が、散慢になりがちなのでとことん勉強するのはむかない。順序だててじっくりXPに取り組みたいのなら、C3のOBが作った2つのサイトから始めるのがいいだろう。Ron Jeffries の *xProgramming.com と Don Wells's *extremeProgramming.orgだ。Bill Wakeの *xPlorations にも、有用な論文がたくさんある。C++とオブジェクト指向デザインに関する著書で知られた Robert Martin もXP推進者の仲間入りをした。彼の会社である *ObjectMentor は、自社のサイトにたくさんの論文を置いているし、 *xp discussion egroupのスポンサーでもある。

Cockburn's Crystal Family

*Alistair Cockburn は、90年代初頭にIBMから開発手法について書くように命じられてから、開発手法にかかわっている。だが、彼のアプローチはちょっとかわっている。普通だったら、自分の経験から物事をどうやるべきかを理論化するのだが、彼は、インタビューに応じてくれるプロジェクトを探しまわって彼らのやり方を聞き、彼自身の経験を補完しているのだ。そして、その結果得たものがあれば、自分の見解を変えることも恐れない。そういう所が、私は気にいっている。

*Surviving Object-Oriented Projects は、プロジェクト運営に関する最初のアドバイス集だ。繰り返し型プロジェクトを行なう人には、私はこの本をいの一番に勧めている。

その本の後も、彼は「ライトな」開発手法についてさらに調べ、*Crystal family of methodologiesを書いた。それが「family」なのは、彼はプロジェクトの種類によって違う開発手法が必要になると信じているからだ。彼は、これを「プロジェクトの人数」と「エラーが引き起こす結果」という2つの座標軸で整理する。この座標に4つの開発手法が対応する。だから、金銭的損害の少ない40人のプロジェクトと命にかかわる6人のプロジェクトは、違う開発手法が必要になる。

CrystalsもXPと同様に、人間を中心に考えるが、その「人間指向」のやり方がちょっと違う。Alistair は人々が規律に従うことが大変なことだと見ていることを考慮し、XPの厳い規律に従うかわりに、意識的に生産性と実行可能性のトレードオフを取り、「これより規律をルーズにしたら、さすがにダメだろう」という限界の開発手法を探究した。「確かにCrystalはXPより生産性が低い、だけど、XPよりたくさんの人に受けいれられるだろう」と彼は考えている。

Alistair はまた、繰り返しの最後のレビューに重点を置いており、プロセスが自分自身を改良していくよう勇気づけている。繰り返し型開発は、問題を見つけやすくして修正を可能にするためにこそ存在理由がある、と彼は主張している。だから、人々が自分のやってることを把握して、開発を続けながらそのやり方を調整することに重点を置くわけだ。

オープンソース

この見出しには驚いただろう。どう言おうが、オープンソースはソフトウエア自身の特性であって、開発プロセスの特性ではない。しかしながら、オープンソースコミュニティの連中は、確かにひとつの流儀を持っている。そして、その流儀の大部分は、ソースがオープンだろうとクローズだろうと適用できるものだ。特に、彼らの開発方法はチームのメンバーが地理的に離れていることを考えにいれている。ほとんどの適応的開発手法は、チームのメンバーが同じ場所で仕事をすることを強調しているので、これは重要なことだ。

ほとんどのオープンソースプロジェクトには1人以上のメンテナンス担当者がいる。メンテナンス担当者だけが、ソースコードの変更をリポジトリにコミットすることを許されている。しかし、それ以外の人もコードに変更を加えることがある。重要な違いは、他の連中はメンテナンス担当者に変更を送り、メンテナンス担当者はレビューしてから変更を適用することだ。通常、この変更は作業が簡単になるようにパッチファイルを利用して行なう。メンテナンス担当者は、このように多くのパッチを調整して、そのソフトウエアの設計上の均質性を保つことに責任を負っている。

プロジェクトごとにメンテナンス担当者の役割は違っている。プロジェクト全体をひとりで担当する者もいるし、モジュールに分割してモジュールごとに担当者を置く場合もある。当番制の場合もあるし、同じコードに複数の担当者を置く場合もある。なかには、以上のどれかを組合せているケースもある。ほとんどのオープンソースの人はパートタイムだ。だから、そういうチームがフルタイムのプロジェクトをうまくこなすことにも注目すべきだろう。

オープンソースの開発の特質として、デバッグをとても多くの人が同時並行的に行なうことがあげられる。デバッグにはたくさんの人が参加する。彼らはバグを見つけるとメンテナンス担当者にパッチを送る。これは、バグはたいてい発見するまでに時間を要するものだから、メンテナンス担当者以外の人にはよい役割だろう。また、高度な設計能力がない人もデバッグには容易に参加できる。

オープンソースの開発プロセスを書いた本はまだ少ない。一番有名な論文は Eric Raymond の*伽藍とバザールだろう。これは短くてうまく書かれている。Klaus Fogelの *CVSはCVSというバージョン管理システムについて書かれたものだが、何章かを割いて、オープンソースの開発プロセスについて書いてある。この部分は、"cvs update"というコマンドに縁のない人が読んでも面白いと思う。

Highsmithの適応的ソフトウエア開発

Jim Highsmith は、何年もの間、予見的な開発手法の仕事をしてきた。彼は、予見的開発手法を開発し実践し教えてきた人だが、最終的に、これは全然ダメだと結論に至った。特に、現代のビジネスには合わないと。

彼は最近の本では、新しい開発手法の適応的な特質に注目している。そして、複雑な適応的システムから産みだされたアイディアを適用することを強調している。(これは、カオス理論として知られている)それは、XPのように詳細なプラクティスは提供しないが、なぜ適応的な開発が必要かに関する基本的な土台とマネージメントの深い階層がもたらすものを提供する。

SCRUM

SCRUMはオブジェクト指向のサークルの中ではそれなりに知られていた。とは言え、正直に言うと私はその歴史や由来についてはそれほど詳しく知らない。これもまた、同じ問題に注目している。すなわち、決まりきった繰りかえしのプロセスは、決まりきった繰りかえしの問題に決まりきった繰りかえしの連中が決まりきった繰りかえしの環境で使う場合しか、使えないということ。

SCRUMは(スプリント:短距離走と呼ぶ)30日間の繰りかえしにプロジェクトを分割する。スプリントを始める前に、そのスプリントで必要とされる機能を定義して、それを開発チームに手渡す。ポイントは、スプリントの間は要求をいじらないことだ。

しかし、これはスプリントの間、管理が不要になるということじゃない。毎日、チームは(15分間の)短いミーティングを行なう。ここでチームは次の日に何をするかをおさらいする。また、その日に何が完了したかをリポートするので、管理者はプロジェクトの現在位置について毎日知ることができる。

SCRUMの文献は、主にプランニングとトラッキングのプロセスを繰り返すことに集中している。多くの点で、「ライトな」開発手法に通じるものがあるし、XPのコーディングのプラクティクストと両立するだろう。

SCRUMについての書籍は存在しないが、WEB上のリソースならたくさんある。Ken Schwaber は、おそらくSCRUMの一番いい概説である*controlChaos.comを運営している。Jeff Sutherlandはオブジェクト指向に関するアクティブなサイトを運営しているが、その中に*SCRUMについてのセクションがある。*PLoPD 4 にもSCRUMのプラクティスに関する概説がある。

Coadのフィーチャー指向開発

フィーチャー指向開発(FDD)はオブジェクト指向の神様的存在のPeter Coadによって長年開発されてきた。それは、他の適応的手法と同じように、短い繰り返しで確実な機能を提供することに集中する。FDDは繰り返しは2週間とされている。

FDDには5つのプロセスがある。最初の3つはプロジェクトの開始時に行われる

次の2つの繰り返しのたびに行われる それぞれのプロセスはタスクに分割されていて、確認方法が提供されている。

開発者はクラス所有者とチーフプログラマの二種類に分けられる。チーフプログラマは最も経験の深い開発者がなる。彼らには構築すべき機能が割当てられる。しかし、彼らは一人でそれを構築するわけではない。チーフプログラマーは、その機能を実現することに関わるクラスを特定し、そのクラスの所有者を集めてチームを作る。チーフプログラマーは、調停者として設計者として家庭教師としてふるまい、クラス所有者がほとんどのコーディングを行なう。

FDDは主に*UML in Color に記述されている。また、彼の会社、*TogetherSoftはFDDに関するトレーニングとコンサルティングを行っている。

その他の情報源

「ライトな」手法についての論文や討論は他にもたくさんある。それらは完全な手法にはなっていないが、この成長する分野についての洞察をもたらしてくれる。

パターンに興味を持つ人は、適応的手法や人間中心主義にも同じく興味を持つようだが、Patterns Language of Programmingカンファレンスには、このテーマについての素材がたくさん含まれている。Jim Copleinの論文*PLoP1が初期の有名なものだ。Ward CunninghamのEpisodes pattern languageが*PLoP2に現われている。Jim Copleinは*OrgPatternsというサイトもやっているが、ここは組織的パターンも集めているwikiサイトである。

Dirk Riehleは XP2000 に*compares the value systemsというXPと適応的開発についての論文を送った。Coad Letterの*7月号ではXPとFDDを比較している。IEEE Softwareの7月号には、これらの手法について論じた"*process diversity"という記事がある。

Should you go light?

誰もが「ライトな」手法でハッピーになるわけじゃない。この道を行くつもりなら、心にとめておいた方がいいことがいくつかある。私自身は、これらの新しい手法は広く適応可能だし、もっともっとたくさんの人が使うべきだと思っているけどね。

現代の環境では、もっと使われている手法と言えば「コードを書いてそれから直す」だろう。そういう混沌と比較すれば、規律を導入することは何にせよ役に立つだろう。だが、いきなり「重量級」で行くより「ライトな」アプローチにした方がギャップは小さい。ライトな手法のよさは「軽さ」なんだ。プロセスが全くない所へプロセスを持ち込むとしたら、単純なプロセスの方が従いやすい。

新しい手法の最も重大な限界は、どれだけ多人数のチームが扱えるかと言うことだ。クリスタルは50人くらいのチームで使用されている。それ以上の規模になると、どうやったら適応的なアプローチが使えるか、そもそもそういう方法がなりたつのか、ということに関するデータはほとんど存在しない。

この記事で言っておきたいことがひとつある。要求仕様が確実でなく流動的な時は適応的手法がいいよ、と言うことだ。確実な仕様を手にできないなら、設計を確実にして計画どおりに進めることは期待できない。そういう場合なら、適応的プロセスは、居心地は悪いにしても効率的であるとは言えるだろう。一番の障害になるのは顧客だろう。私の見方では、仕様が変化していくのに予見的なプロセスに従うことは、開発者も往生するが顧客の方も同じなんだけどね。

みんな気がついてると思うが、50人以上だったら伝統的に予見的プロセスがいいし、仕様が変化しそうなら適応的プロセスがいいと私は言った。じゃ、50人以上で仕様も変化するならどっちにしたらいいだろうか?さすがの私もこれには答えられないので、誰か他の人に聞いてみてくれ。ただ私に言えることは(もうわかってるだろうが)「それはとてつもなく困難だ」と言うことだけだ。

そして、もし適応的手法をとるなら、開発者を信頼してものごとを決める場に呼んでやんないとダメだよ。その信頼が無いと適応的手法は成り立たない。だから、開発者の質が低くやる気がないとお嘆きのあなたは、予見的アプローチを使った方がいいだろう。

まとめると、以下の要因がある時は適応的手法がお勧め。

逆に、こういう要因があったら予見的手法がいい。

で、結局どれ?

どれも新しい手法であり、私はちょっとしたガイドしか提供できないが、私が選ぶとしたら、ポイントはふたつ。その1・・・チームの人数、その2・・・どれだけ厳しい規律に従う用意があるかどうか。

12人以下でみんな乗り気になってるなら、間違いなくXPがいい。とことんやらなきゃだめということではない。XPのアプローチを部分的に適応してもいいことがたくさんあるだろう。キーとなるのは完全自動化単体テストだ。それさえちゃんとやるつもりならば、技術的な基盤がしっかりしている。もし、それ(単体テストの自動化)を手ぬきするつもりだったら、XPの他のことはとてもできないと私は予想する。

もし規律というものがこれまでなくて、しかも人数が多いなら、クリスタルのアドバイスに従うのがいいだろう。それは「ライト」中の「ライト」だし、Cockburnはとりわけ適応的だ。それでもXPのプランニングプロセスは使うだろう。

そうは言ったけど、実は今私は40人のチームと仕事をしてるんだけど、このチームは多くのXPプラクティスを実施していて、ほとんどのフルセットのXPと言ってもいいくらいだ。だから、チーム全体でしっかりとした決断ができるならば、この限界点にこだわる必要はないかもしれない。

最後に最も大事なことを言っておこう。始める時に「なんとか」というプロセスを開始したとしよう。その「なんとか」はほんとうの意味ではあなたの仕事のプロセスではないんだ。プロセスをチェックして自分の環境に合わせていじることが一番重要なことだ。プロジェクトが完了する時点では、そのプロセスは「あなたの」プロセスになってるはずだ。その時には「なんとか」っていう名前はおまけみたいなものさ。

参考文献

書籍

titleauthorisbnurlreference
Adaptive Software DevelopmentHighsmith0932633404http://www.amazon.com/exec/obidos/ASIN/0932633404[1]
UML DistilledFowler020165783Xhttp://www.amazon.com/exec/obidos/ASIN/020165783X
(Japanese)http://www.shoeisha.com/book/Detail.asp?PI=1&CTID=10&BID=1031&tK=UML
Extreme Programming Explained: Embrace ChangeBeck201616416http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=201616416[1]
Design PatternsGamma, Helm, Johnson, and Vlissidies0201633612http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201633612
Surviving Object-Oriented ProjectsCockburn0201498340http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201498340[1]
Bio of Taylorwho0140260803http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0140260803[1]
plopd1 0201607344http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201607344[1]
jeffries-xpi 0201708426http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201708426[1]
fogel-cvs 1576104907http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1576104907
(Japanese)http://www.linux.or.jp/bookreview/BR35.html
[1]
beckFowlerPEP 0201710919http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201710919[1]
plopd2 0201895277http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201895277[1]
pragmatic 020161622Xhttp://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=020161622X
huntThomas 020161622Xhttp://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=020161622X
plopd4 0201433044http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201433044[1]
Java Modeling in Color with UML 013011510Xhttp://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=013011510X
(Japanese)http://www.mmjp.or.jp/pearsoned/nbi.html
[1]
McConnell-rapid 1556159005http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1556159005[1]

WEBサイト

nameurlreference
xp-egrouphttp://www.egroups.com/group/extremeprogramming/[1]
xpCutterhttp://www.cutter.com/ead/ead0002.html[1]
rielhe-xp2000http://www.riehle.org/papers/2000/xp-2000.html[1]
reeves-designhttp://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm[1]
orgPatternshttp://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns[1]
extremeProgramming.orghttp://www.extremeprogramming.org
(Japanese)http://product.uis-inf.co.jp/playground/
[1]
cockburn-non-linearhttp://members.aol.com/humansandt/papers/nonlinear/nonlinear.htm[1]
sutherland-scrumhttp://jeffsutherland.com/scrum/index.html[1]
coad-letter-7-2000http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html[1]
togetherSofthttp://www.togethersoft.com[1]
xpWikihttp://c2.com/cgi/wiki?ExtremeProgrammingRoadmap[1]
normKerthhttp://c2.com/ppr/about/author/norm.html
controlChaos.com http://www.controlchaos.com[1]
objectMentorhttp://www.objectmentor.com[1]
ieeeSoftware-jul-2000http://www.computer.org/software/so2000/s4toc.htm[1]
cockburn-homehttp://members.aol.com/acockburn/[1] [2]
xPlorations http://users.vnet.net/wwake/xp/[1]
xProgramminghttp://www.xprogramming.com[1]
xunithttp://www.xProgramming.com/software.htm
cathedralBazarhttp://www.tuxedo.org/~esr/writings/cathedral-bazaar
(Japanese)http://cruel.org/freeware/cathedral.html
[1]

謝辞

この記事のためには書ききれないほどたくさんの人からアイディアをもらった。なかでも、はっきりとした提案をしてくれた、Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham, Bill Kimmel, そして Frank Westphalに感謝する。

これは、成長するWEB論文であり、私はいじりたくなったらすぐいじるつもりであることを覚えておいてほしい。大きく変更した時はそれを記録するけど、小さな修正はコメントなしでやってしまうつもり。


Copyright マーチン・フォウラー, all rights reserved
Japanese translation by 中島 拓 ,(株)ブレーン(2000/9/27version:V1.0)
翻訳にあたっては、高林哲氏、及びXP-jpメーリングリストのメンバー諸氏からたくさんの助言を頂きました。ありがとうございました。