仕様変更の多いプロジェクトで実践した設計手法とその効果

はじめに

この記事では、「不確実性の高いプロジェクトにおいて、設計段階でどのように柔軟性を持たせ、変更に強い構成を実現したか」の事例をご紹介します。
仕様変更が多発する前提の中で、以下の設計思想に基づき、設計を行いました。

結論として、プロジェクト内でいくつか工夫や試行錯誤は必要でしたが、当該設計思想は不確実性の高いプロジェクトでも非常に有効であると感じました。

注意事項

本記事は他の言語やフレームワークにも応用できる内容ですが、本記事で想定しているのは中規模開発です。

※ ここでは、中規模開発を実行ファイル 1つにつき 2,500〜5,000行程度のプログラムと定義しています。

設計思想の適用と工夫

DFD（データフロー図）の活用

まずDFDでデータの流れを整理し、矛盾や途切れを特定。
既存テーブルの調査、要件のヒアリング、新規テーブル検討を経て、実装前にデータフローの整合性を確認しました。

「共通化しない」方針

仕様変更が頻繁に発生している段階で安易に共通化すると、修正時の影響範囲が広がると判断しました。
例えば、SQLの場合、SQLを細かく分解して使いまわすこと¹はせず、あえて処理ごとに固有SQLを用いて設計しました。
共通化は、仕様変更のリスクが減少した段階で着手し、保守性とのバランスを取る方針を採用しました。

工夫の結果

メリット

要件変更対応の容易化

仕様変更時も修正範囲を限定しやすく、どこを直せばよいか明確でした。

デメリット

類似処理の分散

同様の処理が複数箇所に点在し、仕様変更時の修正漏れリスクがやや高くなりました。
そこで同じロジックは統一した記述でgrep検索しやすくするとともに、変更頻度が低い部分だけ段階的に共通化する工夫を加えました。

さいごに

DFDを活用してデータの流れと整合性を可視化し、柔軟な設計アプローチ（たとえば初期段階では共通処理をあえて避ける）を採用することで、安定した開発を実現しました。

プロジェクトの進行に伴って、要件が明確化・安定化する過程では、段階的に共通化やリファクタリングにも着手し、保守性と拡張性の向上にも寄与しました。

1. SQLを再利用しやすくする方法として、SQLを細かく分解し、それぞれの結果をLINQで結合するアプローチもあります。この方法はSQLの再利用には向きますが、本プロジェクトでは変更時の影響を見極めやすくするため、あえて処理単位で固有SQLを記述する方針を採用しました。 ↩