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


The New Methodology


Martin Fowler
Chief Scientist , ThoughtWorks

In the past few years there's been a rapidly growing interest in "lightweight" methodologies. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for lightweight methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation. I also give a summary and references to the processes in this school and consider the factors that should influence your choice of whether to go down this newly trodden path.

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

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


1From Nothing, to Heavy, to Light

Most software development is a chaotic activity, often characterized by the phrase "code and fix". The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new features to the system. Furthermore bugs become increasingly prevalent and increasingly difficult to fix. A typical sign of such a system is a long test phase after the system is "feature complete". Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.

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


We've lived with this style of development for a long time, but we've also had an alternative for a long time: methodology. Methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient. They do this by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines.

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


These methodologies have been around for a long time. They've not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There's so much stuff to do to follow the methodology that the whole pace of development slows down. Hence they are often referred to as heavy methodologies, or to use * Jim Highsmith's term: monumental methodologies.

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


As a reaction to these methodologies, a new group of methodologies have appeared in the last few years. Although there's no official name for them, they are often referred to as light methodologies - signaling a clear reaction to the heavyweight methodologies. For many people the appeal of these lightweight methodologies is their reaction to the bureaucracy of the heavy weight methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff.

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


The result of all of this is that lightweight methods have some significant changes in emphasis from heavyweight methods. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code.

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


However I don't think this is the key point about lightweight methods. Lack of documentation is a symptom of two much deeper differences:

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


In the following sections I'll explore these differences in more detail, so that you can understand what an adaptive and people-centered process is like, it's benefits and drawbacks, and whether it's something you should use: either as a developer or customer of software.

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


2Predictive versus Adaptive

2.1Separation of Design and Construction

The usual inspiration for methodologies is engineering disciplines such as civil or mechanical engineering. Such disciplines put a lot of emphasis on planning before you build. Such engineers will work on a series of drawings that precisely indicate what needs to be built and how these things need to be put together. Many design decisions, such as how to deal with the load on a bridge, are made as the drawings are produced. The drawings are then handed over to a different group, often a different company, to be built. It's assumed that the construction process will follow the drawings. In practice the constructors will run into some problems, but these are usually small.

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


Since the drawings specify the pieces and how they need to be put together, they act as the foundation for a detailed construction plan. Such a plan can figure out the tasks that need to be done and what dependencies exist between these tasks. This allows for a reasonably predictable schedule and budget for construction. It also says in detail how the people doing the construction work should do their work. This allows the construction to be less skilled intellectually, although they are often very skilled manually.

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


So what we see here are two fundamentally different activities. Design which is difficult to predict and requires expensive and creative people, and construction which is easier to predict. Once we have the design, we can plan the construction. Once we have the plan for the construction, we can then deal with construction in a much more predictable way. In civil engineering construction is much bigger in both cost and time than design and planning.

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


So the approach for many methodologies looks like this: we want a predictable schedule that can use people with lower skills. To do this we must separate design from construction. Therefore we need to figure out how to do the design for software so that the construction can be straightforward once the planning is done.

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


So what form does this plan take? For many, this is the role of design notations such as the *UML. If we can make all the significant decisions using the UML, we can build a construction plan and then hand these designs off to coders as a construction activity.

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


But here lies crucial questions. Can you get a design that is capable of turning the coding into a construction activity? And if so, is construction sufficiently larger in cost and time to make this approach worthwhile?

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


All of this brings a few questions to mind. The first is the matter of how difficult it is to get a UML-like design into a state that it can be handed over to programmers. The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing. The models that civil engineers use are based on many years of practice that are enshrined in engineering codes. Furthermore the key issues, such as the way forces play in the design, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams is peer review. While this is helpful it leads to errors in the design that are often only uncovered during coding and testing. Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software.

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


Another issue is that of comparative cost. When you build a bridge, the cost of the design effort is about 10% of the job, with the rest being construction. In software the amount of time spent in coding is much, much less (*McConnell suggests that for a large project, only 15% of the project is code and unit test, an almost perfect reversal of the bridge building ratios. Even if you lump in all testing as part of construction, then design is still 50% of the work.) This raises an important question about the nature of design in software compared to its role in other branches of engineering.

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


These kinds of questions led Jack Reeves to *suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.

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


This thinking leads to some important conclusions:

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


2.2The Unpredictability of Requirements

There's a refrain I've heard on every problem project I've run into. The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it.

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


One route is to treat changing requirements as the result of poor requirements engineering. The idea behind requirements engineering is to get a fully understood picture of the requirements before you begin building the software, get a customer sign-off to these requirements, and then set up procedures that limit requirements changes after the sign-off.

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


One problem with this is that just trying to understand the options for requirements is tough. It's even tougher because the development organization usually doesn't provide cost information on the requirements. You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can't tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof?

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


Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify.

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


Software's intangible nature also cuts in. It's very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not.

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


This leads to the ironic point that people expect that requirements should be changeable. After all software is supposed to be soft. So not just are requirements changeable, they ought to be changeable. It takes a lot of energy to get customers of software to fix requirements. It's even worse if they've ever dabbled in software development themselves, because then they "know" that software is easy to change.

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


But even if you could settle all that and really could get an accurate and stable set of requirements you're probably still doomed. In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has made a billion on stock market trading.

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


Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.

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


2.3Is Predictability Impossible?

In general, no. There are some software developments where predictability is possible. Organizations such as NASA's space shuttle software group are a prime example of where software development can be predictable. It requires a lot of ceremony, plenty of time, a large team, and stable requirements. There are projects out there that are space shuttles. However I don't think much business software fits into that category. For this you need a different kind of process.

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


One of the big dangers is to pretend that you can follow a predictable process when you can't. People who work on methodology are not very good at identifying boundary conditions: the places where the methodology passes from appropriate in inappropriate. Most methodologists want their methodologies to be usable by everyone, so they don't understand nor publicize their boundary conditions. This leads to people using a methodology in the wrong circumstances, such as using a predictable methodology in a unpredictable situation.

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


There's a strong temptation to do that. Predictability is a very desirable property. However if you believe you can be predictable when you can't, it leads to situations where people build a plan early on, then don't properly handle the situation where the plan falls apart. You see the plan and reality slowly drifting apart. For a long time you can pretend that the plan is still valid. But at some point the drift becomes too much and the plan falls apart. Usually the fall is painful.

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


So if you are in a situation that isn't predictable you can't use a predictive methodology. That's a hard blow. It means that many of the models for controlling projects, many of the models for the whole customer relationship, just aren't true any more. The benefits of predictability are so great, it's difficult to let them go. Like so many problems the hardest part is simply realizing that the problem exists.

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


However letting go of predictability doesn't mean you have to revert to uncontrollable chaos. Instead you need a process that can give you control over an unpredictability. That's what adaptivity is all about.

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


2.4Controlling an Unpredictable Process

So how do we control ourselves in an unpredictable world? The most important, and still difficult part is to know accurately where we are. We need an honest feedback mechanism which can accurately tell us what the situation is at frequent intervals.

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


The key to this feedback is iterative development. This is not a new idea. Iterative development has been around for a while under many names: incremental, evolutionary, staged, spiral... lots of names. The key to iterative development is to frequently produce working versions of the final system that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.

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


The point of this is that there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements.

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


Iterative development makes sense in predictable processes as well. But it is essential in adaptive processes because an adaptive process needs to be able to deal with changes in required features. This leads to a style of planning where long term plans are very fluid, and the only stable plans are short term plans that are made for a single iteration. Iterative development gives you a firm foundation in each iteration that you can base your later plans around.

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


A key question for this is how long an iteration should be. Different people give different answers. XP suggests iterations of between one and three weeks. SCRUM suggests a length of a month. Crystal will stretch further. The tendency, however, is to make each iteration as short as you can get away with. This provides more frequent feedback, so you know where you are more often.

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


2.5The Adaptive Customer

This kind of adaptive process requires a different kind of relationship with a customer than the ones that are often considered, particularly when development is done by a separate firm. When you hire a separate firm to do software development, most customers would prefer a fixed-price contract. Tell the developers what they want, ask for bids, accept a bid, and then the onus is on the development organization to build the software.

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


A fixed price contract requires stable requirements and hence a predictive process. Adaptive processes and unstable requirements imply you cannot work with the usual notion of fixed-price. Trying to fit a fixed price model to an adaptive process ends up in a very painful explosion. The nasty part of this explosion is that the customer gets hurt every bit as much as the software development company. After all the customer wouldn't be wanting some software unless their business needed it. If they don't get it their business suffers. So even if they pay the development company nothing, they still lose. Indeed they lose more than they would pay for the software (why would they pay for the software if the business value of that software were less?)

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


So there's dangers for both sides in signing a fixed price contract in conditions where a predictive process cannot be used. This means that the customer has to work differently.

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


In an adaptive process the customer has much finer-grained control over the software development process. At every iteration they get both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership. This level of engagement is not for every customer organization, nor for every software developer; but it's essential to make an adaptive process work properly.

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


The key benefit for the customer is a much more responsive software development. A usable, although minimal, system can go into production early on. The customer can then change its capabilities according to changes in the business, and also from learning from how the system is used in reality.

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


3Putting People First

Executing an adaptive process is not easy. In particular it requires a very effective team of developers. The team needs to be effective both in the quality of the individuals, and in the way the team blends together. There's also an interesting synergy: not just does adaptivity require a strong team, most good developers prefer an adaptive process.

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


3.1Plug Compatible Programming Units

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manger. The individuals aren't so important, only the roles are important. That way if you plan a project it doesn't matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

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


But this raises a key question: are the people involved in software development replaceable parts? One of the key features of lightweight methods is that they reject this assumption.

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


Perhaps the most explicit rejection of people as resources is Alistair Cockburn. In his paper *Characterizing People as Non-Linear, First-Order Components in Software Development, he makes the point that predictable processes require components that behave in a predictable way. However people are not predictable components. Furthermore his studies of software projectshave led him to conclude the people are the most important factor in software development. In the title, [of his article] I refer to people as "components". That is how people are treated in the process / methodology design literature. The mistake in this approach is that "people" are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts ofunplanned project trajectories we so often see.

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


Although Cockburn is the most explicit in his people-centric view of software development, the notion of people first is a common theme with many thinkers in software. The problem, too often, is that methodology has been opposed to the notion of people as the first-order factor in project success.

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


This creates a strong positive feedback effect. If you expect all your developers to be plug compatible programming units, you don't try to treat them as individuals. This lowers morale (and productivity). The good people look for a better place to be, and you end up with what you desire: plug compatible programming units.

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


Deciding that people come first is a big decision, one that requires a lot determination to push through. The notion of people as resources is deeply ingrained in business thinking, it's roots going back to the impact of * Frederick Taylor's Scientific Management approach. In running a factory, this Taylorist approach makes sense. But for the highly creative and professional work, which I believe software development to be, this does not hold. (And in fact modern manufacturing is also moving away from the Taylorist model.)

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


3.2Programmers are Responsible Professionals

A key part of the Taylorist notion is that the people doing the work are not the people who can best figure out how best to do that work. In a factory this may be true for several reasons. Part of this is that many factory workers are not the most intelligent or creative people, in part this is because there is a tension between management and workers in that management makes more money when the workers make less.

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


Recent history increasingly shows us how untrue this is for software development. Increasingly bright and capable people are attracted to software development, attracted by both its glitz and by potentially large rewards. (Both of which tempted me away from electronic engineering.) Such schemes as stock options increasingly align the programmers interests with the company's.

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


(There may well be a generational effect here. Some anecdotal evidence makes me wonder if more brighter people have ventured into software engineering in the last ten years or so. If so this would be a reason for why there is such a cult of youth in the computer business, like most cults there needs to be a grain of truth in it.)

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


When you want to hire and retain good people, you have to recognize that they are competent professionals. As such they are the best people to decide how to conduct their technical work. The Taylorist notion of a separate planning department that decides how to do things only works if the planners understand how to do the job better than those doing it. If you have bright, motivated people doing the job then this does not hold.

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


3.3Managing a People Oriented Process

People orientation manifests itself in a number of different ways in lightweight processes. It leads to different effects, not all of them are consistent.

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


One of the key elements is that of accepting the process rather the imposition of a process. Often software processes are imposed by management figures. As such they are often resisted, particularly when the management figures have had a significant amount of time away from active development. Accepting a process requires commitment, and as such needs the active involvement of all the team.

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


This ends up with the interesting result that only the developers themselves can choose to follow an adaptive process. This is particularly true for XP, which requires a lot of discipline to execute. This is where Crystal is such an effective complement as it aims at being minimally disciplined.

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


Another point is that the developers must be able to make all technical decisions. XP gets to the heart of this where in its planning process it states that only developers may make estimates on how much time it will take to do some work.

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


Such technical leadership is a big shift for many people in management positions. Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.

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


An important reason for this is the rate of change of technology in our industry. After a few years technical knowledge becomes obsolete. This half life of technical skills is without parallel in any other industry. Even technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.

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


3.4The Role of Business Leadership

But the technical people cannot do the whole process themselves. They need guidance on the business needs. This leads to another important aspect of adaptive processes: they need very close contact with business expertise.

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


This goes beyond most projects involvement of the business role. Lightweight teams cannot exist with occasional communication . They need continuous access to business expertise. Furthermore this access is not something that is handled at a management level, it is something that is present for every developer. Since developers are capable professionals in their own discipline, they need to be able to work as equals with other professionals in other disciplines.

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


A large part of this, of course, is due to the nature of adaptive development. Since the whole premise of adaptive development is that things change quickly, you need constant contact to advise everybody of the changes.

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


There is nothing more frustrating to a developer than seeing their hard work go to waste. So it's important to ensure that there is good quality business expertise that is both available to the developer and is of sufficient quality that the developer can trust them.

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


4The Self-Adaptive Process

So far I've talked about adaptivity in the context of a project adapting its software frequently to meet the changing requirements of its customers. However there's another angle to adaptivity: that of the process changing over time. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.

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


The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. At the end of each iteration, have a short meeting and ask yourself the following questions (culled from *Norm Kerth)

These questions will lead you to ideas to change the process for the next iteration. In this way a process that starts off with problems can improve as the project goes on, adapting better to the team that uses it.

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

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


If self-adaptivity occurs within a project, it's even more marked across an organization. To deepen the process of self-adaptivity I suggest teams do a more formal review and major project milestones following the project retrospective sessions outlined by Norm Kerth. These retrospectives involve a 2-3 day offsite meeting and a trained facilitator. Not only do they provide learning for the team, they also provide learning for the whole organization.

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


A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project. While both published processes and the experience of other projects can act as an inspiration and a baseline, the developers professional responsibility is to adapt the process to the task at hand.

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


This self-adaptivity is most marked in ASD and Crystal. XP's rigid rules seem to disallow it, but that is only a surface impression since XP does encourage people to tune the process. The main difference with XP is that its advocates suggest doing XP by the book for several iterations before adapting it. In addition reviews are neither emphasized, nor part of the process, although there are suggestions that reviews should be made one of the XP practices.

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


5The Methodologies

Several methodologies fit under this lightweight banner. While all of them share many characteristics, there are also some significant differences. I can't highlight all the points in this brief survey, but at least I can point you to some places to look.

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


5.1XP (Extreme Programming)

Of all the lightweight methodologies, this is the one that has got the most attention. Partly this is because of the remarkable ability of the leaders of XP, in particular Kent Beck, to get attention. It's also because of the ability of Kent Beck to attract people to the approach, and to take a leading role in it. In some ways, however, the popularity of XP has become a problem, as it has rather crowded out the other methodologies and their valuable ideas.

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


The roots of XP lie in the Smalltalk community, and in particular the close collaboration of Kent Beck and Ward Cunningham in the late 1980's. Both of them refined their practices on numerous projects during the early 90's, extending their ideas of a software development approach that was both adaptive and people-oriented.

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


The crucial step from informal practice to a methodology occurred in the spring of 1996. Kent was asked to review the progress of a payroll project for Chrysler. The project was being carried out in Smalltalk by a contracting company, and was in trouble. Due to the low quality of the code base, Kent recommended throwing out the entire code base and starting from scratch his leadership. The result was the Chrysler C3 project (Chrysler Comprehensive Compensation) which since became the early flagship and training ground for XP.

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


The first phase of C3 went live in early 1997. The project continued since and ran into difficulties later, which resulted in the canceling of further development in 1999. As I write this, it still pays the original 10,000 salaried employees.

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


XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.

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


One of the most striking, as well as initially appealing to me, is its strong emphasis on testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.

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


On this platform XP builds an evolutionary design process that relies on refactoring a simple base system with every iteration. All design is centered around the current iteration with no design done for anticipated future needs. The result is a design process that is disciplined, yet startling, combining discipline with adaptivity in a way that arguably makes it the most well developed of all the adaptive methodologies.

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


XP has developed a wide leadership, many of them springing from the seminal C3 project. As a result there's a lot of sources for more information. The best *summary at the moment is written by an outsider, Jim Highsmith, whose own methodology I'll cover later. Kent Beck wrote *Extreme Programming Explained the key manifesto of XP, which explains the rationale behind the methodology and enough of an explanation of it to tell folks if they are interested in pursuing it further.

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


Two further books are in the works. Three members of the C3 project: Ron Jeffries, Ann Anderson, and Chet Hendrickson are writing *Extreme Programming Installed, an explanation of XP based on the C3 experience. Kent Beck and I are writing *Planning Extreme Programming, which discusses how you do planning in this adaptive manner.

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


As well as books, there are a fair number of web resources. Much of the early advocacy and development of the XP ideas occurred on Ward Cunningham's *wiki web collaborative writing environment. The wiki remains a fascinating place to discover, although its rambling nature does lead you into being sucked in. To find a more structured approach to XP, it's best to start with two sites from C3 alumni: Ron Jeffries's *xProgramming.com and Don Wells's *extremeProgramming.org. Bill Wake's *xPlorations contains a slew of useful papers. Robert Martin, the well known author on C++ and OO design has also joined the list of XP promoters. His company, *ObjectMentor, has a number of papers on its web site. They also sponsor the *xp discussion egroup.

本と同様、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のスポンサーでもある。


5.2Cockburn's Crystal Family

*Alistair Cockburn has been working on methodology ever since he was tasked by IBM to write about methodology in the early 90's. His approach is unlike most methodologists, however. Instead of building on solely personal experience to build a theory of how things should be done, he supplements his direct experience with actively seeking to interview projects to see how they work. Furthermore he isn't afraid to alter his views based on his discoveries: all of which make him my favorite methodologist.

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


His book, *Surviving Object-Oriented Projects, was his first piece of advice on running projects, and remains my number one book recommendation for running iterative projects.

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


Since that book he's explored light methods further, coming up with the *Crystal family of methodologies. It's a family because he believes that different kinds of projects require different kinds of methodologies. He looks into this variation along two axes: the number of people in the project, and the consequences of errors. Each methodology fits into a different part of the grid, so a 40 person project that can lose discretionary money has a different methodology than a six person life-critical project.

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


The Crystals share a human orientation with XP, but this people-centeredness is done in a different way. Alistair considers that people find it hard to follow a disciplined process, thus rather than follow XP's high discipline, Alistair explores the least disciplined methodology that could still succeed, consciously trading off productivity for ease of execution. He thus considers that although Crystal is less productive than XP, more people will be able to follow it.

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


Alistair also puts a lot of weight in end of iteration reviews, thus encouraging the process to be self-improving. His assertion is that iterative development is there to find problems early, and then to enable people to correct them. This places more emphasis on people monitoring their process and tuning it as they develop.

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


5.3Open Source

You may be surprised by this heading. After all open source is a style of software, not so much a process. However there is a definite way of doing things in the open source community, and much of their approach is as applicable to closed source projects as it is to open source. In particular their process is geared to physically distributed teams, which is important because most adaptive processes stress co-located teams.

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


Most open source projects have one or more maintainers. A maintainer is the only person who is allowed to commit a change into the source code repository. However people other than the maintainer may make changes to the code base. The key difference is that other folks need to send their change to the maintainer, who then reviews it and applies it to the code base. Usually these changes are made in the form of patch files which make this process easier. The maintainer thus is responsible for coordinating the patches and maintaining the design cohesion of the software.

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


Different projects handle the maintainer role in different ways. Some have one maintainer for the whole project, some divide into modules and have a maintainer per module, some rotate the maintainer, some have multiple maintainers on the same code, others have a combination of these ideas. Most open source folks are part time, so there is an issue on how well such a team coordinates for a full time project.

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


A particular feature of open source development is that debugging is highly parallelizable. So many people can be involved in debugging. When they find a bug they can send the patch to the maintainer. This is a good role for non-maintainers since most of the time is spent finding the bug. It's also good for folks without strong design skills.

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


The process for open-source isn't well written up as yet. The most famous paper is Eric Raymond's *The Cathedral and the Bazar, which while an excellent description is also rather brief. Klaus Fogel's *book on the CVS code repository also contains several good chapters on open-source process that would be interesting even to those who never want to do cvs update.

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


5.4Highsmith's Adaptive Software Development

Jim Highsmith has spent many years working with predictive methodologies. He developed them, installed them, taught them, and has concluded that they are profoundly flawed: particularly for modern businesses.

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


His recent book focuses on the adaptive nature of new methodologies, with a particular emphasis on applying ideas that originate in the world of complex adaptive systems (commonly referred to as chaos theory.) It doesn't provide the kind of detailed practices like the XP work does, but it does provide the fundamental groundwork for why adaptive development is important and the consequences at the deeper organizational and management levels.

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


5.5SCRUM

SCRUM has been around for a while in object-oriented circles, although I'll confess I'm not too au fait with its history or development. Again it focuses on the fact that defined and repeatable processes only work for tackling defined and repeatable problems with defined and repeatable people in defined and repeatable environments.

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


SCRUM divides a project into iterations (which they call sprints) of 30 days. Before you begin a sprint you define the functionality required for that sprint and then leave the team to deliver it. The point is to stabilize the requirements during the sprint.

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


However management does not disengage during the sprint. Every day the team holds a short (fifteen minute) meeting, called a scrum, where the team runs through what it will do in the next day. In particular they surface to the management blocks: impediments to progress that are getting in the way that management needs to resolve. They also report on what's been done so management gets a daily update of where the project is.

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


SCRUM literature focuses mainly on the iterative planning and tracking process. It's very close to the other lightweights in many respects and should work well with the coding practices from XP.

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


There isn't any book on SCRUM at the moment, but there are a number of web resources. Ken Schwaber hosts *controlChaos.com which is probably the best overview of SCRUM. Jeff Sutherland has always has an active web site on object technology issues and includes a *section on SCRUM. There's also a good overview of SCRUM practices in the *PLoPD 4 book.

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


5.6Coad's Feature Driven Development

Feature Driven Development (FDD) was developed by the long time OO guru Peter Coad. Like the other adaptive methodologies, it focuses on short iterations that deliver tangible functionality. In FDD's case the iterations are two weeks long.

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


FDD has five processes. The first three are done at the beginning of the project.

Each process is broken down into tasks and is given verification criteria

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

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


The developers come in two kinds: class owners and chief programmers. The chief programmer are the most experienced developers. They are assigned features to build. However they don't build them alone. Instead the chief programmer identifies which classes are involved in implementing the feature and gathers their class owners together to form a feature team for developing that feature. The chief programmer acts as the coordinator, lead designer, and mentor while the class owners do much of the coding of the feature.

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


The main description of FDD is in Peter Coad et al's *UML in Color book. His company, *TogetherSoft, also does consulting and training on FDD.

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


5.7Other Sources

There are a number of other papers and discussions about this theme of light methods. While these may not be full methodologies, they do offer insights into this growing field.

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


The Patterns Language of Programming conferences has often contained material that touches on this subject, if only because many of the folks interested in patterns are also interested in more adaptive and humane methods. A leading early paper was Jim Coplein's paper at *PLoP1. Ward Cunningham's Episodes pattern language appeared in *PLoP2. Jim Coplein now hosts the *OrgPatterns site, a wiki which collects together patterns for organizational patterns.

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


Dirk Riehle sent a paper to XP2000 that *compares the value systems of XP and Adaptive Software Development. The *July edition of the Coad letter compares XP to FDD. The July edition of IEEE Software includes several articles on "*process diversity" which touch on these methodologies.

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


6Should you go light?

Using a light method is not for everyone. There are a number of things to bear in mind if you decide to follow this path. However I certainly believe that the these new methodologies are widely applicable and should be used by more people than currently consider them.

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


In today's environment, the most common methodology is code and fix. Applying more discipline than chaos will almost certainly help, and the lightweight approach has the advantage that it is much less of a step than using a heavyweight method. Here much of the advantage of the lightweight methods is indeed their weight. Simpler processes are more likely to be followed when you are used to no process at all.

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


One of the biggest limitations to these new methodologies is how they handle larger teams. Crystal has been used up to about fifty people, but beyond that size there is little evidence as to how you can use an adaptive approach, or even if such approaches work at all.

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


Hopefully one message that's clear from this article is that adaptive approaches are good when your requirements are uncertain or volatile. If you don't have stable requirements, then you aren't in the position to have a stable design and follow a planned process. In these situations an adaptive process may be less comfortable, but it will be more effective. Often the biggest barrier here is the customer. In my view it's important for the customer to understand that following a predictive process when requirements change is risky to them just as much as it is to development.

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


So you'll notice I've said that if you have more than fifty people you should use a traditional predictive process and if you change changing requirements you should use an adaptive process. What if you have both a large project and changing requirements? I don't have a good answer to this, so I'd suggest you seek a second opinion. I can tell you that things will be very difficult, but I suspect you already know that.

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


If you are going to take the adaptive route, you need to trust your developers and involve them in the decision. Adaptive processes rely on you trusting your developers, so if you consider your developers to be of low quality and motivation then you should use a predictive approach.

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


So to summarize. The following factors suggest an adaptive process

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


These factors suggest a predictive process

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


6.1Which Adaptive Process?

All of these processes are new, and I can only give some first hand experience to guide you. In my choice the question lies in the team size and how much discipline they are prepared to go for.

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


With a dozen developers or less that are inclined to try it, I'd certainly push for XP. It may be that the team won't go all out in the XP process, at least initially, but you still get a lot of benefit by a partial XP approach. For me the key test of using this process well is automated unit testing. If the team are prepared to do that, then the technical foundations will be in place. If they can't do that, then I don't suspect they'll handle the rest.

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


If the discipline isn't there, or the team is too large, then I'd be inclined to follow Crystal's advice. It's certainly the lightest of the light, and Cockburn is particularly adaptive to the lessons of development. I'd still use the XP planning process in these cases.

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


Having said that, however, I'm working with a team of forty who are successfully trying many XP practices and are pretty close to full XP, so with determination and a committed team you can adapt your process outside at least some of these boundaries.

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


And that's really the key message. Whatever process you start with will not be the process that'll really work for you. You have to take charge of your process, monitor it and adapt it to your circumstances. In the end it must become your process, any other labels are secondary.

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


7Reference

7.1Books

titleauthorisbnurlreference
Adaptive Software DevelopmentHighsmith0932633404http://www.amazon.com/exec/obidos/ASIN/0932633404[1] [2]
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
[1]
Extreme Programming Explained: Embrace ChangeBeck201616416http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=201616416[1] [2]
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] [2]
Bio of Taylorwho0140260803http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0140260803[1] [2]
plopd1 0201607344http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201607344[1] [2]
jeffries-xpi 0201708426http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201708426[1] [2]
fogel-cvs 1576104907http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1576104907
(Japanese)http://www.linux.or.jp/bookreview/BR35.html
[1] [2]
beckFowlerPEP 0201710919http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201710919[1] [2]
plopd2 0201895277http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201895277[1] [2]
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] [2]
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] [2]
McConnell-rapid 1556159005http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1556159005[1] [2]

7.2WEB

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

8Acknowlegements

I've taken lots of ideas from people for this paper, more than I could possibly list. For concrete suggestions I'd like to thank Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham, Bill Kimmel, and Frank Westphal.

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


Do remember that this is an evolving web paper and likely to change whenever I have the inclination. I'll add a record of significant changes, however minor changes will occur without comment.

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



Copyright Martin Fowler, all rights reserved