http://martinfowler.com/bliki/SpreadingIncrementalism.html

漸進手法が他の分野でも使えることに疑問を抱いている人がいる。 「 アジャイルプロジェクトでは (セキュリティ|ユーザーインターフェース設計|データベース|国際化|*) を行うことは出来ない。 これは前払いで行われるべきものだからだ。 」 といった具合。

私に対してそういった疑問が投げかけられたら……どうしよう。 その分野には精通してないから、すぐにしどろもどろになってしまうと思う。 アプリケーション設計についてだったら話すことはできるけれど、 （例えば）セキュリティについて話すことはできないからね。 それに、疑問を投げかけてくる人はその分野の識者かもしれないし。

ただ、その分野に精通してはいないけれど、 「その分野では計画設計しか使えませんね」と言うつもりはない。 漸進的設計が使えるかどうかは誰にも分からない。 私は「漸進的設計なんて X には使えないよ」 と言ったそばから使えることに気付いた、 なんていう事例をいくつも見てきている。 アプリケーション設計もそうだし、データベース設計もそうだ。 だから、実際に漸進的設計をやってみるまで 「その分野では漸進的設計は使えない」と言うつもりはサラサラない。

ただ、この疑問が正しいかどうか判断することは難しい。 漸進的設計はテキトーにやることだってできてしまうからだ。 コントロールされていない漸進的設計をヤってしまうと、 でたらめな設計になってしまう可能性が高い。 漸進的設計を機能させるには、設計を律する何かが必要となる。 Is Design Dead（設計の終焉?）で私は、これを「enabling practice(翻訳では”「できることを増やす」プラクティス”となっているが、これはおかしいので原文ママにした。)」と名付けた。 ソフトウェア設計だと、 テスト、継続的インテグレーション、リファクタリング がキーとなる enabling practice であり、 これらがソフトウェア設計を収束させ、 ソフトウェアエントロピーの増大を回避してくれる。 となると、その他の分野（例えば、ユーザーインターフェース設計）の enabling practice は何だろうかという話になるわけだが、 それはソフトウェア設計のそれに似たものや連想したものになるかもしれないし、 反対に、まったく違ったものになるかもしれない。 例えばデータベース設計では、「漸進的データ移行」がキーとなる enabling practice となっている。 いずれにせよ、それにふさわしい enabling practice を見つけるまで、 漸進的設計は薄氷（危ない橋）ってことだね。

危ないとは言ったものの、漸進的手法は非常に価値がある。 最も効果的な方法を見つけるために、やってみるのもいいんじゃないだろうか。 フェーズのある前払い設計手法は頻繁に失敗している。 その上、変わりやすい要求にうまく対応できていない。 エンタープライズソフトウェア開発において、 要求変更は避けられないものだというのに。

要求変更に対応できるというのも理由のひとつだが、 私が漸進主義を好む最大の理由は、（よく言われることだけど）リスクマネジメントにある。 設計をしっかり試していないと、 思ったように動かないものや開発スケジュールの遅れに対応できない。 これらのリスクは、 漸進主義をソフトウェア開発の様々な局面に導入する方法を探すという十分な理由になる。