ウォーターフォール開発とは

何を開発するかが着手前に確定する案件なら、そのまま採用してかまいません。確定していない部分がある案件では、その部分だけ試作を確認しながら決定する進め方を組み合わせます。

ウォーターフォールのままでよいのは次のような案件です。

• 既存システムの刷新で、今の機能をそのまま仕様の出発点にできる
• 法改正や制度変更への対応で、要件が外部の条件で確定する
• 他社や他システムとの接続仕様を事前に確定させる必要がある
• リリース日を変更できない
• 監査や規制のために設計書と試験記録を保管する必要がある

判断の目安は着手前に主要な画面、帳票、連携先の一覧を列挙し、業務部門がそれを承認できるかどうかです。列挙できない部分が全体の2〜3割を超える案件は、全体をウォーターフォールで確定させると、完成時に要件が業務の実態と一致しなくなっているリスクが高まります。期間が1年を超えて途中で事業の状況が変化しそうな案件も同じです。

組み合わせる場合は接続仕様や基幹の処理をウォーターフォールで確定させ、画面や操作性は試作を確認しながら反復して開発する形が珍しくありません。反復する部分では社内標準の工程ごとの承認を、区切りごとに試作を確認する場で代替します。

要件定義が完了する前の金額は、確定額でなく幅のある概算とみなします。要件定義と開発は契約を分離し、開発の総額は要件定義の後に確定させます。IPAの情報システム・モデル取引・契約書も、工程ごとに個別の契約を結ぶ多段階契約を基本にしています。

見積もりとあわせて、次の点を確認します。

• 見積もりの前提にした機能の一覧と、範囲外にしたもの
• 仕様変更を誰が申し入れ、追加の費用と納期への影響を誰がいつ示し、誰が承認するかという変更の手続き
• 各工程の完了時に発注側の誰が成果物を承認するか
• 受入れテストに業務部門から何人を何週間投入する前提になっているか
• 納品後に発見された不具合を無償で修正してもらえる期間と、その期間がいつ起算されるか

承認済みの工程のやり直しを伴う変更には、原則として追加の費用と期間がかかります。最初に確定した金額と納期が守られるのは、要件が着手前に確定し、途中で変更されない場合に限られます。

書類の完成度ではなく、動作するものと試験の結果で進捗を確認します。ウォーターフォールではシステム全体をつないだ試験を後半に実施するので、設計の誤りや性能の問題を終盤まで把握しにくいです。

• 工程の完了は自己申告の進捗率でなく、承認済みの成果物で確認する。進捗率が9割前後のまま何週間も変化しなければ、遅れの兆候とみなす
• 主要な機能を一通りつないで動作させる試作や、データ移行のリハーサルを、早期の計画に組み込んでもらう
• 他システムとの接続試験を最後の工程に集中させず、相手側の試験環境を利用できる時期を発注側で早めに確保する

開発会社の報告会では未解決の課題の件数と、その増減を毎回確認します。課題の件数が減少しないまま工程だけが進行しているなら、問題は後半に一斉に発覚します。