システム開発におけるプロジェクトの進め方として、ウォーターフォールとアジャイルが知られています。ウォーターフォールが一般的ですが、評判はよくありません。いわく、
- 工程が進んだあとの手戻りが難しい。
- 各工程でドキュメントばかり書いている。
- 製造工程では品質のばらつきが大きい。大規模ほど管理が困難になる。
- 見積作成が難しい。そもそも入り口となる要求が、どんどん膨れ上がることは珍しくない。
- 時代が求めている短納期開発に適用できない。
といった問題が指摘されています。ではアジャイルだと解決するかといえば、そう単純でもありません。アジャイルの場合は、次の点を気をつけることになります。
- ドキュメントを残さず、すぐコードを修正する形のため、開発者の能力に依存する。
- 手戻り可能と、何でも修正できるを混同しがち。実際にはしっかりしたスケジュール管理を行っている。
- 見積作成が難しい。契約時点で「いくらで何ができる」ことを明示しにくい。
- 短期開発向けだが、大規模開発への適用は困難と考えられている。一番の問題は、アジャイルに精通した開発者（開発言語の習熟も含む）の要員確保。ウォーターフォールに馴れた開発者をアジャイルに適用できるかというと現実には厳しい。
私は「超高速ウォーターフォール」という第三の道を提唱しています。これは自動生成エンジンという技術の活用で、はじめて可能となるものです。次のような特徴があります。
- ドキュメントはしっかりつくるが、基本設計まで。それ以降は自動生成エンジンがコードを生成するため不要である。
- 単体テスト、結合テストは不要。基本設計どおりに動作するかという総合テストのみ行う。
- 自動生成エンジンが対応できないカスタマイズコードがあれば、その分は従来通りドキュメントやテストを行う。ただしその分量が少なければ少人数で対応および管理可能。
- 全体の工期を短くし、手戻りという概念を、次開発のテーマに回す。これはアジャイルの良いところを継承。
- 短い工期毎に必ず動作する成果物を出す。この単位で見積を行うことで見積精度も向上する。
- 時代が求めている短納期開発に対応できる。
ということで、ウォーターフォールに馴れた開発会社はアジャイルへ転身するのではなく、自らの強みを活かしつつ「超高速ウォーターフォール」にシフトしていくのが良いと思います。
こういう話をあちこちで行っていますが、おかげさまで好評です。Wagby の代理店も増加傾向で、超高速ウォーターフォールは現実的な解として受け入れられつつあることを実感しています。
