早すぎる共通化 vs 重複コード、現場での判断基準は？

🖊️テーマ

「同じような処理は共通化して1つにまとめる」のは開発の基本ですが、共通化しすぎたせいで、後から「一部の画面だけ仕様を変えたい」となったときに共通処理が足かせになり、修正が大惨事になった経験はありませんか？

逆に、共通化を恐れて重複コードだらけにすると、仕様変更の際に全箇所を直して回る不毛な作業が発生します。

まだ経験の浅い若手エンジニアから「似たような処理なので共通化しちゃっていいですか？」と聞かれたとき、皆さんは将来の手戻りを防ぐために、どのタイミングまで「あえて共通化せずに残せ」とアドバイスしていますか？現場独自の「折り合いの付け方」をぜひ教えてください！

👤運営メンバーの回答

運営メンバーのFさんは、「まったく同じロジックだとしても、3箇所以上で使われるまでは絶対に共通化させない（2箇所まではコピペを許容する）」というルールを徹底しているとのこと！

2回目の段階では、それが本当に同じ目的の処理なのか、たまたま今同じなだけなのかが見極められないため、早すぎる共通化で身動きが取れなくなるリスクを避けるためにそうしているそうです。

〜teratailトーク!とは？〜

詳細を公式ブログで公開しています。ぜひお読みください。
「teratailトーク!」スタート🎉　気軽に意見交換しよう！

回答8件

fana

総合スコア12437

投稿2026/06/29 01:25

編集2026/06/29 01:33

たまたま今同じなだけなのかが見極められない

ここの意味が分からないです．
本当に「今同じ」なのであればそれはその時点では「同じ」として扱えば良いのでは…？
そこを

AとBの処理は本当に同じ（コードの見た目とかの話じゃなくて，意味/処理内容/etc が全く同じ） →　だけども，将来のことがわからないので共通化せずに個別にしておく

…なんてことをしてしまうと，近い将来に「は？　なにこのコピペプログラムは？　ふざけてるの？」ってなるだけだと思うのですが……

将来に備えるなら，

ものっすごい強大な塊のようなコードがぐちゃぐちゃに絡み合っててもう後から個別化しようとか無理すぎる！　みたいな状態を作らないこと

を徹底し，将来本当にAとBが別の話になってきた際には

個別化すべき時が来たのに，無理に「共通コード」状態を引きずらないこと．

みたいなのが必要なことなんじゃないかなぁ．
（この時点でコピペで２つに増やしたって良いよね？　っていう）

まぁ，「言うは易し」という感じではあるのだけど……

とにかく各時点において同じものは同じにしておかないと

全箇所を直して回る不毛な作業

で地獄を見る率が 150% ．
そもそも「全箇所……とは？」っていうことになりますし．

tamoto

総合スコア4446

投稿2026/06/29 09:33

共通化に「早すぎる」という概念はないと思います。早すぎる最適化の話と混同していそうに思います。
概念が同じであるものには常に同じものを使い、むしろ共通化されていない状態を許容しないようにするべきです。
もしも、未来にその共通処理から一部の利用者に対して異なる処理を行いたい要件が発生したなら、そのタイミングで処理を複製し、分離するのです。
よくある誤った共通化に、「概念が異なる処理なのに、コード記述が同じだからと流用する共通化 (変更の単位が異なるものを流用している)」「共通化された処理にフラグを追加して中で処理を分けている (そもそも共通処理じゃない/共通化の分割単位が正しくない)」というものがあるので、これらを間違って共通化しなければ、共通化は積極的に行う方が良いです。

「似たような処理なら共通化してよいか」-> よくないです。処理が似ているかどうかと、同じ目的を達成したいものかどうかは直交する概念です。後者はなるべく共通化すべきで、前者だけであれば絶対に共通化してはいけません。
「3箇所以上で使われるまでは絶対に共通化させない」-> 3箇所以上で使われることと、その処理が同じ概念であるかどうかは別です。同じ概念なら、2箇所で使われる処理でも共通化していくべきです。

ただし、同一の概念で同一の処理であるにも関わらず、共通化せずに各ロジックの内部に複製コードを書いた方がむしろ良い例外ケースがあります。それは、「ビジネス要件に一切依存せず、誰がいつ書いても常に同じ処理になるようなユーティリティ処理」です。
これらには共通化の際に処理を置くべき「適切なドメイン」というものが存在しないため、共通化したところで共通処理として統一的に使わせることが難しく、また他人が同一処理を無から再発明するシナリオが残り続け、未来の重複を防ぐことが本質的に困難なものです。
これらに関しては、共通化せずに各サービスレイヤーコードが private に持つことは問題ないと考えています。ただし、public にしないことが必須条件となります。

例外と言ったものの、実は「共通化可能に見える同一処理」がこれに該当するケースはかなり多く、これらを共通化すべきかで悩んでいるのかもしれません。
しかしこれらは「未来に機能が変更される可能性が限りなく低い」ため、共通化することによって無用な依存関係という負債を導入することになり、共通化しない方が総合的に利益が大きくなる可能性が高いと考えており、自分はこれらを一切共通化しないようにしています。

結論、ビジネスロジック上の同一概念は全て共通化し、ドメイン依存を持たないユーティリティ処理は同一でも共通化しないのが正解です。

jimbe

総合スコア13492

投稿2026/06/30 05:31

2回目の段階では、それが本当に同じ目的の処理なのか、たまたま今同じなだけなのかが見極められない

というのは、その処理が何なのか分かってないということではないでしょうか。その点だけでも、判断する材料が揃ってないのでは。

また段取りとして、共通化したものを分けることは『修正のタイミング』で行うだけですが、後々重複を共通化するというのははっきりした『タイミング』がありません。聞き手に「半年後(とか1年後とかプロジェクト終了時とか)に同じままだったら共通化だね」と言うのでしょうか。

fana

総合スコア12437

投稿2026/06/30 06:38

個別化すべき時が来たのに，無理に「共通コード」状態を引きずらないこと

これ，（自分で書いてる話だけども）
「個別化すべき時が来た」……のか？　という判断が結構難しいというか，なかなか踏ん切りがつかないというか．

C++
1//なんか共通処理があったのを……
2void CommonFunc(){ /*共通処理*/ }
3
4//↓
5
6//「XXXのときだけ，ちょっと微妙な差が～」みたいな話になった際，
7//こんな感じに済ませちゃうときも正直わりとある感．
8void CommonFunc( bool ForXXX=false )
9{
10  /*...*/
11
12  if( ForXXX ){ ... }  //←地獄の扉が開きつつある気がするんだけども…
13
14  /*...*/
15}