共通化する前に考えるべきなのは、コードではなく「変更理由」
「同じような処理があるから共通化しよう。」
システム開発では、ごく自然に行われる判断です。重複したコードを減らせば保守しやすくなり、修正箇所も少なくなる。一見すると合理的な設計に思えるでしょう。しかし、この考え方だけで共通化を進めると、変更のたびに条件分岐が増え、影響範囲が広がり、結果として設計を複雑にしてしまうことがあります。
では、何が問題なのでしょうか。
それは、コードの形だけを見て共通化を判断してしまうことです。設計で本当に見るべきなのは、コードが似ているかどうかではありません。将来も同じ理由で変更されるものかどうかです。
この記事では、「とりあえず共通化」が設計を壊してしまう理由と、本当に共通化すべき場面の考え方について解説します。
設計とは、変更を整理すること
設計というと、クラス構成やデザインパターンを思い浮かべる人も少なくありません。しかし、それらはあくまで手段です。設計の目的は、将来の変更をできるだけ小さな影響で実現できる構造を作ることにあります。そのためには、同じ理由で変わるものをまとめ、異なる理由で変わるものは分ける必要があります。この視点を持たずに共通化を進めると、本来は独立して変更できたものまで結び付けてしまいます。つまり、設計を良くするための共通化が、設計を壊す原因になってしまうのです。
共通化は目的ではなく手段
「共通化」という言葉には、良い設計という印象があります。確かに、同じ処理を何度も書かなくて済む状態は理想的です。しかし、それは適切に共通化できた場合の話です。
目的が曖昧なまま、「似ているから」「同じ処理だから」「重複は悪だから」という理由だけでまとめてしまうと、異なる責務まで一つの処理に集約されてしまいます。
その結果、一つの機能を修正しただけなのに別の機能まで影響を受けるようになり、修正のたびに影響範囲を調査する必要が生まれます。共通化そのものが悪いのではありません。判断基準のない共通化が問題なのです。
「今は同じ」と「これからも同じ」は違う
例えば、会員登録と管理者登録があるとします。現在は入力チェックの内容がほとんど同じだったため、一つの共通メソッドにまとめました。この時点では良い判断に見えます。ところが数か月後、会員登録ではメール認証が追加され、管理者登録では承認フローが追加されたとします。
すると共通メソッドには、「管理者ならこの処理」「一般会員ならこちら」「管理画面経由なら別処理」といった条件分岐が増えていきます。
最初はシンプルだった共通処理が、いつの間にか多くの仕様を抱え込んだ巨大なメソッドへ変わってしまいます。これは、現在の共通点だけを見て判断した結果です。設計では、「今同じか」ではなく、「将来も同じ理由で変わるか」を考える必要があります。
DRYは「コードの重複」をなくす原則ではない
「Don’t Repeat Yourself（DRY）」という設計原則を、「重複コードをなくすこと」と理解しているケースがあります。しかし、本来DRYが避けたいのは、知識の重複です。つまり、同じ事実を複数箇所で管理しないことを目的としています。
例えば、税率を複数のプログラムへ直接書いていた場合、税率が変更されるたびにすべて修正しなければなりません。これは同じ知識を複数管理している状態です。
一方で、偶然似たようなコードは必ずしも同じ知識とは限りません。見た目は同じでも、業務上の意味や変更理由が異なるなら、それらは別々に管理した方が保守しやすい場合もあります。コードが重複しているという理由だけで共通化すると、本来独立すべき知識まで結び付けてしまうことになります。
抽象化とは、共通点を探すことではない
共通化と混同されやすいものに、抽象化があります。抽象化とは、似ているものをまとめることではありません。本質的に同じ役割や責務を表現することです。
例えば、CSV出力、PDF出力、Excel出力は形式は異なりますが、いずれも「ファイルへ出力する」という共通した責務を持っています。一方で、会員登録と管理者登録は、「登録」という言葉は共通していますが、将来の仕様変更まで同じとは限りません。変更理由が異なるのであれば、一つにまとめることで柔軟性を失う可能性があります。
抽象化で見るべきなのは、名前や処理の似ている部分ではなく、何のために存在し、どのような理由で変更されるのかです。
共通化を判断するときの基準は一つだけ
共通化すべきか迷ったときは、次の問いを考えてみてください。「これらは将来も同じ理由で変更されるだろうか。」この問いに自信を持って「はい」と答えられるなら、共通化する価値があります。
一方で、変更理由が異なる可能性があるなら、多少コードが重複していても分けておいた方が、結果として保守しやすい設計になることが少なくありません。設計では、コード量を減らすことよりも、変更の影響範囲を小さく保つことの方が重要だからです。
まとめ
「重複しているから共通化する。」
この判断自体は間違いではありません。問題なのは、それがコードの見た目だけを基準にした判断になっていることです。設計で本当に整理すべきなのは、コードではなく変更です。
変更理由が同じものはまとめる。
変更理由が異なるものは分ける。
この基準を持つだけで、安易な共通化による条件分岐や密結合を避けやすくなります。共通化は、設計そのものではありません。設計とは、変更を整理することです。そして、共通化はそのための一つの手段にすぎません。
手段が目的になった瞬間、設計は少しずつ複雑になっていきます。共通化を考える前に、「コードが似ているか」ではなく、「将来も同じ理由で変わるか」を考えてみてください。その視点が、長く保守できる設計につながります。
コメント