コードクローンの意義について

東証VSみずほ証券、この世界でシステム開発している人にとっては「不毛な争いだなあ（自分ちだって似たようなもんだろ？）」と思っている人が多いんじゃないかと思います。みずほ証券のシステムは見たことないけど、ヒューマンエラーを防止するための仕組みがお粗末だったから誤発注された部分も否定出来ないんじゃないかな。
それはさておき、この記事。

ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされており、品質が極めて低い」と主張。これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。

［論点3］どんな開発手法を適用すべきか | 日経 xTECH（クロステック）

これも正直どうかなと思います。記述の重複には理由がある場合とない場合があります。適切な理由であれば、記述が重複していたとしても問題ないこともあります。ではどういう時に適切か。

一つは、処理が「たまたま」同じな場合。これはあえてたまたまと言っていますが、その時点においては必然的に同じである、しかし、業務要件は必ずしも未来に渡って同じであることを保証しない、という場合がほとんどです。共通処理ってのはそれが共通である必然性がなければならず、こっちでもあっちでも同じ事やっているから一緒にしちゃおうぜ、というのは設計がきちんとできていないということとほぼ同義です。こういった状況的な共通化は余計なリスクを抱え込むことになります。

もう一つのポイントは、変更が容易なシステムかどうか。例えば銀行の勘定系システムにおいて、共通化した部分に仕様変更が入るとどうなるか。当然ですが、それを使っているプログラムについて（論理的には影響が０と判断できても）全量再テストをする、というケースがありえます。これが単に関数レベルの問題だったとしても、ロードモジュールに変更が入る場合、使ってなくてもテスト、というのが（最近は少し改善方向に向いているとはいえ）社会インフラ系システムでは日常茶飯事です。DLLだったらどうなのよ、ということもありますが、例えばOSとかパッケージのライブラリ修正についても影響がないことをベンダーに一筆入れさせたりきちんとテストしたりするので…

これらの話はコピペを是としない人から見ると大変馬鹿馬鹿しい問題かもしれませんが、こと運用が始まっていて止めることが許されないシステムにおいては、変更を局所化する対応というのは重要な話です。

え？コピペで作ったところに全部対応が入ったら大変じゃないかって？
そうなんですが、保守以降のシステムにおいて大変なのはテスト工数なんでコピペ工数なんて相対的に見たら大したことないんですよね…

うん、ちょっと言っていることがおかしいような気もします。少なくとも、これって品質がよくなるとかそういう問題ではないのではないかと。費用対効果は低い施策であることも確かです。でも、こういう世界もあるわけなので、この手の言い争いはあんまり意味が無いですね。