既存のシステムの機能拡張の見積もりを行う際、その機能強化による影響の大きさを正しく把握する必要が肝要です。
影響の大きさを把握する上で、もし新たなデータの状態が発生するような修正をするのであれば、その修正の影響が思いの他大きくなることを警戒する必要があります。
例えば、セミナー予約用のWebシステムを考えてみます。
既存のフローは以下の通りであるとします。
①見込客がシステムのアカウントを取得する
②主催企業が見込客にDMを送信する
③見込客がDMに書かれた候補日時の中から一つを選び予約完了
それぞれの時点での見込客のデータの状態は以下の通りであるとします。
①DM送信済みフラグ＝偽、日時選択済みフラグ＝偽
②DM送信済みフラグ＝真、日時選択済みフラグ＝偽
③DM送信済みフラグ＝真、日時選択済みフラグ＝真
ここで、DMの内容を取り消しし①のフローに戻せるようにする、という機能拡張を行うとします。
この際、「DMの内容の取り消し」を「DM送信済みフラグを偽にする」と実装してしまうと
・DM送信済みフラグ＝偽、日時選択済みフラグ＝真
というこれまでになかった状態が発生する可能性が出てしまいます。
（③の状態でDMの内容を取り消しすると上記のような状態になる）
そして、既存のプログラムで、「日時選択済みフラグが真の場合に③のフロー上にいると判断する」というロジックが存在する場合、それらのロジックは全て修正対象になってしまいますし、新たに発生したデータの状態を各プログラムでどう扱うか、ということも考慮する必要が出てきてしまいます。
このように、新たなデータの状態が発生するような修正は、見た目の修正規模と比べて影響が大きくなる恐れがあります。
影響を小さくしたいのであれば、これまでに存在していたデータの状態のみを使って機能拡張を実現できないか、を考えることが重要です。
（今回の例では、対象のデータに対して「日時選択済みフラグを偽にする」という操作も行うか、対象のデータをコピーして新たなデータを作成した上で新たなデータを「DM送信済みフラグ＝偽、日時選択済みフラグ＝偽」にするか、のどちらかの対応を考えた方が良いです）
