私自身は幸運なことに、要件が「現行機能の踏襲」であるプロジェクトに携わったことはないのですが、要件がこれに近いプログラムをプライベートで作成しているので、参考までにその経験を記事として残します。
私が作成しているプログラムはとあるゲーム（RPG）の戦闘部分の計算を行うシミュレータであり、ゲーム攻略のために作成しています。
要件としては下記であり、同じ計算が行われるということ自体に価値があるプログラムです。
・ゲームで行われる計算と同じ計算を実装する
・諸事情によりゲームを解析することはできない
・ゲームには場当たり的な対応やバグが多数含まれており、それも仕様として実装する
これを実務に置き換えると以下のような要件であり、限りなく「現行機能の踏襲」に近い状況です。
・現行システムと同じ機能を実装する
・諸事情により現行のソースコードを入手できない
（他ベンダーが開発、ソースコード紛失、等の理由で）
・場当たり的な保守・運用が多数行われており、それも仕様として実装する
私が作成しているプログラムで最も複雑な部分は、攻撃手段毎のダメージ計算式です。
攻撃手段は数百種類存在し、それぞれ異なった計算を行う必要があります。
本来であれば、各々の攻撃手段毎で共通するルールが存在するため、そのルールを抽象化して実装することで保守性を確保することができます（図「本来あるべき姿」）。
（「本来」というのは、「シリーズ初期は」や「運用当初は」といった言葉で置き換えてください）
しかし、実態としては、場当たり的な対応が行われる過程でそのルールを逸脱する計算が行われる攻撃手段が存在します（図「実態１」）。
また、実装の誤りにより、攻撃手段によっては一部計算式が異なる物もあります（図「実態２」）。
ゲームを解析することができれば、既存のソースコードをそのままコンバートしたり、ロジックを真似ることで現行のソースコードと同程度のレベルで抽象化したりすることができるのですが、今回はその手は使えません。
更に、実装を始めた段階では現行のゲームの全ての挙動が判明しているわけではなく、プログラムを作ってみて初めて判明する挙動というのも存在するため、このことも開発の難易度を高める要因となっています。
つまり、十分な抽象化が行えない状況で、将来の変更（新たに見つかった挙動への対応）を見据えたプログラミングを行う必要があります。
私が作成しているプログラムでは、下記のような対応をとっています（図「対応策」）。
１．攻撃手段毎にクラス分けする
一番避けなければならないのが、攻撃手段の分岐を計算式中で多様することでソースコードが複雑化し、保守困難になることである。
そこで、ルールに従った抽象化を行わず、攻撃手段毎にクラス分けした。
重複した記述は多くなるが、ある攻撃手段に対する変更が他の攻撃手段に影響を及ぼすのを避けることはでき、攻撃手段毎の処理内容を追うことも容易になる。
（なお、小規模な開発である場合、「クラス」は「関数」に置き換えても良い）
２．各々のクラスで使用する計算式は部品化する
ダメージ計算式は分解可能であるため、分解した計算式を部品（共通関数）として用意し、その部品を組み合わせることで各々のクラスの実装を可能とした。
攻撃手段毎の微妙な計算式の違いを、部品の組み換えや追加で吸収することが可能になり、保守性が向上する。
このプログラムは公開してから（使い物になる状態になってから）数年経っていますが、今の所は保守困難な状態にはなっていません。
しかし、十分に抽象化を行えなかった影響で、保守性は正直良くありません。
攻撃手段の数だけコピペが必要になるような対応も何回か発生しています。
「現行機能の踏襲」という要件はビジネス上の観点から見ても問題がある（業務改善ができない）と思いますが、実装上も
・共通ルールを見つけるのが困難で、十分な抽象化を行えない
・作ってから初めて明らかになる仕様があり、変更を見こさなければならない
という困難さがあり、実装を工夫したとしても十分な保守性を確保するのは難しいです。
保守性が悪いということは、将来の開発でQCDを確保することも困難になります。
「現行機能の踏襲」という要件は、開発コストの低減やリスクの低減に繋がらないと考えた方が無難だと思います。
今回の例のように、現行機能通りにすること自体に価値があるのであれば別ですが、そうでなければ、要件を「現行機能の踏襲」とすることには慎重になる必要があります。
プライベートでもプログラムを作っているので、その中で仕事に活かせそうなスキルや経験が得られることがあります。
また何かあれば、記事にしていきたいと思います。
コメント