米国ではアジャイルプロセスの採用が活発だ。日本でも、契約トラブルを防ぐにはアジャイルプロセスの導入を検討すべきである。以下で、今後の契約形態を考える上でカギとなるアジャイルプロセスについて説明する。
アジャイルプロセスとは、迅速かつ適応的にソフトウエアを開発するための軽量な開発方法論である。アジャイルプロセスにはさまざまな種類があるが、その代表といえるのが「スクラム」である（図6）。
スクラムは、ラグビーのスクラムにちなんだ名前だ。7人前後のメンバーが1チームとなり、チームとしてメンバーが協力し、2週間から1カ月の周期で繰り返し開発する。スクラムではこの繰り返し（イテレーション）期間をスプリントと呼び、数回のスプリントを繰り返して開発を進める。
アジャイルプロセスといっても闇雲に開発するわけではない。最初にリリース計画を立て、次に製品基準の調整・レビュー・配布を行う。開発準備が整ったら、スプリントを数回実施。すべてのスプリントが終了すると、本番環境への最終的な移行作業（クロージャー）を行う。スプリントごとに本番リリースする場合もある。
各スプリントの対象となるシステム要件がプロダクトバックログだ。このうち当該スプリントで扱うものを作業レベルに詳細化したのがスプリントバックログである。
アジャイルプロセスが最も効果的なのは、ユーザーのニーズがはっきりしない新サービスや新分野の開発だ。優先度の高い機能から早くリリースし、ニーズを確認しながらシステムを成長させてリリースを繰り返すため、ユーザーに求められるものを無駄なく早く提供することが期待できる。
では、大規模なエンタープライズシステムの開発ではアジャイルプロセスを適用できるのか。新規のエンタープライズシステムの開発なら、上記と同様に早期リリースやニーズ確認による作り直し防止の効果を期待できる。しかし要件を確認しながら開発を進めるケースではリスクが大きく、ある程度要件を詰めた基本設計まではウォーターフォールモデルで実施する必要がある。
もっとも、エンタープライズシステムの開発では、新規よりも稼働中の既存システムを対象にするケースが多い。サポート切れを機に再構築するものだ。既存システムでは改善要望の積み残しが多いかもしれないが、再構築を機に操作性や性能を向上させたいと思うもの。このときアジャイルプロセスに期待するのは、早期リリースではなく、ニーズ確認による作り直しの防止やユーザービリティーの向上だ。