移行プロジェクトにおけるウォーターフォールモデルの再認識

この記事はウィルゲート Advent Calendar 2025 10日目の記事です。

adventar.org

こんにちは。ウィルゲート開発室PMO（プロジェクトマネジメントオフィス）を担当している大嶋です。

今回は、基幹システムの移行プロジェクトを進める中で感じた課題や学びについて振り返ります。今回のシステム移行は、技術負債の解消とライセンスコスト削減を目的としたもので、新旧プロダクトの置き換えという大きなテーマでした。プロジェクトでは自社と協業先との役割分担の難しさを強く実感するとともに、ウォーターフォールモデルの工程ごとの意味を改めて再認識する機会にもなりました。

---

移行プロジェクトの背景

今回の移行は、長年使用してきた基幹システムの技術的負債を解消し、ライセンス費用も削減する目的で進めているプロジェクトです。既存システムの陳腐化や保守性の課題が積み重なり、将来的な改善スピードにも影響が出ていたため、刷新は避けられない判断でした。

移行プロジェクトがウォーターフォールモデルになった理由

今回のプロジェクトでは、開発手法としてウォーターフォールモデルを採用しました。主な理由は次の通りです。

• 移行の完了期日が明確に存在していたこと
  契約や運用上のスケジュールから、移行の完了期限が初期段階で決まっていました。固定されたリリース時期に向けて工程を順序立てて管理できる点は、ウォーターフォールの利点でした。

• 現行システムがあり、機能・品質基準が明確だったこと
  移行対象の機能や業務フローが既に確立されており、再現すべき仕様もはっきりしていました。そのため、要件を固めてから実装に進むウォーターフォールの進め方がフィットしました。

自社と協業先との役割分担の難しさ

プロジェクトで最も苦労したのが「役割分担の線引き」でした。

業務要件やシステム要件は自社が責任を持って定義すべき領域ですが、製造やテストについてはどこまでを協業先に委ね、どこからを共に進めるかの判断が難しい場面が多々ありました。

また、機能仕様や画面のレイアウトを自社で細かく決めすぎると、移行先プロダクトが標準として持っている良さを活かしにくくなるため、協業先の持つ移行先プロダクトにおける専門性を踏まえた適切な提案を引き出すための「任せ方」も課題でした。

自社と協業先の役割イメージ図

工程をまとめたことで気づいたウォーターフォールの本質

今回の進め方では、要件定義の後に基本設計フェーズを設けず、設計と製造を一つの流れで進めました。しかしその結果、要件書に記載されていない仕様が曖昧なまま実装に入り、後工程でギャップが発生しやすくなりました。

ウォーターフォールでは、

要件定義：何を実現するか

基本設計：どのように実現するか

という橋渡しの役割が重要で、この工程を省略すると不確実性が一気に増すことを痛感しました。

テスト工程のスコープが曖昧になった問題

テスト工程でも、単体・結合・システムの境界が曖昧になり、特に単体で結合レベルの動作確認までしようとする場面がありました。

V字モデルに基づくと、

単体 → 詳細設計の検証

結合 → 基本設計・機能仕様の検証

システム → 要件定義の検証

という対応関係があります。この整理が曖昧だと、テスト工程がかえって混乱し、品質保証の観点も揺らぎます。

一般的なV字モデル

システムテスト本来の役割の再確認

システムテストは「実際に業務が回るか」を確認することが本来の目的です。今回の振り返りでは、仕様レベルの確認に意識が偏ってしまう場面もあり、業務フローに沿ったテストケースへ見直すことで工程の目的が再度明確になりました。

まとめと今後の展望

今回の振り返りを通して、役割分担の難しさ、工程の意義、品質保証の考え方など、多くの学びがありました。特にウォーターフォールモデルの「各工程の目的」が曖昧になると、その歪みが後工程に確実に現れることを再認識しました。

プロジェクト自体はまだ完了しておらず、ローンチは 2026年1月 を予定しています。現在は、移行後の業務切替やデータ移行の計画・準備といった最終フェーズに向けた大詰めの段階にあります。ここまで得た学びを活かし、残りの期間は業務フローと移行リスクの精査に重点を置きながら、安定した移行に向けて仕上げていく予定です。

「ウィルゲート Advent Calendar 2025」、翌日は佐々木さんの「GDG DevFest Tokyo 2025 へ参加してきました！」です！