広がるインクリメンタリズム

ときどき、特定の専門分野をインクリメンタルな方法で使用できるかどうか疑問に思われることがあります。「アジャイルプロジェクトでは（セキュリティ、ユーザーインターフェイスデザイン、データベース、国際化）を行うことはできません。なぜならこれらの側面は事前に完了する必要があるからです」

このような質問を受けた場合、すぐに難しい状況に陥ります。なぜなら、私はその専門分野にそれほど詳しくないからです。アプリケーション設計については語れると思いますが、セキュリティ（たとえば）については語れません。そして、質問者はその分野で高い評価を得ているリーダーである可能性があります。

その分野における既知の限界にもかかわらず、その分野での計画的な設計しか使用できないと言うつもりはありません。言えることは、その領域でインクリメンタル設計を行うことができるかどうかは実際には不明だということです。私は、「xに対してインクリメンタル設計は使用できません」と言った人が、実際には使用可能であることに気付くケースを数多く見てきました。アプリケーション設計はその一例であり、データベース設計は別の例です。したがって、人々が本格的にインクリメンタル設計を試すまでは、それを排除するのは非常に気が進まないのです。

この質問を評価する際の難しさの一部は、インクリメンタル設計を不適切に行うことがあまりに簡単であることです。管理されていない方法でインクリメンタル設計を行った場合、混乱した設計になる可能性が最も高くなります。インクリメンタル設計を機能させるためには、設計を整理する必要があります。私は「デザインは死んだのか」の中で、これらを支援する手法と呼んでいます。ソフトウェア設計の場合、ソフトウェア設計を収束させ、ソフトウェアエントロピーを回避するための重要な支援手法として、テスト、継続的インテグレーション、およびリファクタリングを挙げました。UI設計など、別のことを議論する場合、問題はそれらの支援手法を見つけることです。ソフトウェア設計のものと似ているか、あるいはインスパイアされている可能性がありますが、何か別のものかもしれません。たとえば、データベース設計では、インクリメンタルデータ移行が重要な支援手法です。適切な支援手法のセットを見つけるまで、インクリメンタル設計は不安定です。

その不安定さにもかかわらず、インクリメンタルアプローチは非常に価値のあるものだと考えています。正しい方法を見つけるために実験する価値があります。段階的な事前設計アプローチは頻繁に失敗します。さらに、要件が変化する可能性が高く、これは少なくともエンタープライズソフトウェア開発では避けられない要素であると考えられます。

しかしながら、私がインクリメンタリズムを支持する最大の理由は、最も古い理由です。それはリスク管理です。設計を試さずに設計を使用すると、思い通りに機能しない、開発の後半でスケジュールが遅れるなどの事態に陥りやすくなります。これらのリスクは、ソフトウェア開発のより多くの側面にインクリメンタリズムを導入する方法を探る十分な理由になります。