🖊️テーマ
「同じような処理は共通化して1つにまとめる」のは開発の基本ですが、共通化しすぎたせいで、後から「一部の画面だけ仕様を変えたい」となったときに共通処理が足かせになり、修正が大惨事になった経験はありませんか？
逆に、共通化を恐れて重複コードだらけにすると、仕様変更の際に全箇所を直して回る不毛な作業が発生します。
まだ経験の浅い若手エンジニアから「似たような処理なので共通化しちゃっていいですか？」と聞かれたとき、皆さんは将来の手戻りを防ぐために、どのタイミングまで「あえて共通化せずに残せ」とアドバイスしていますか？現場独自の「折り合いの付け方」をぜひ教えてください！
👤運営メンバーの回答
運営メンバーのFさんは、「まったく同じロジックだとしても、3箇所以上で使われるまでは絶対に共通化させない（2箇所まではコピペを許容する）」というルールを徹底しているとのこと！
2回目の段階では、それが本当に同じ目的の処理なのか、たまたま今同じなだけなのかが見極められないため、早すぎる共通化で身動きが取れなくなるリスクを避けるためにそうしているそうです。
〜teratailトーク!とは？〜
詳細を公式ブログで公開しています。ぜひお読みください。
「teratailトーク!」スタート🎉 気軽に意見交換しよう！
回答9件
#1
総合スコア12463
投稿2026/06/29 01:25
編集2026/06/29 01:33たまたま今同じなだけなのかが見極められない
ここの意味が分からないです．
本当に「今同じ」なのであればそれはその時点では「同じ」として扱えば良いのでは…？
そこを
- AとBの処理は本当に同じ（コードの見た目とかの話じゃなくて，意味/処理内容/etc が全く同じ） → だけども，将来のことがわからないので共通化せずに個別にしておく
…なんてことをしてしまうと，近い将来に「は？ なにこのコピペプログラムは？ ふざけてるの？」ってなるだけだと思うのですが……
将来に備えるなら，
- ものっすごい強大な塊のようなコードがぐちゃぐちゃに絡み合っててもう後から個別化しようとか無理すぎる！ みたいな状態を作らないこと
を徹底し，将来本当にAとBが別の話になってきた際には
- 個別化すべき時が来たのに，無理に「共通コード」状態を引きずらないこと．
みたいなのが必要なことなんじゃないかなぁ．
（この時点でコピペで２つに増やしたって良いよね？ っていう）
まぁ，「言うは易し」という感じではあるのだけど……
とにかく各時点において同じものは同じにしておかないと
全箇所を直して回る不毛な作業
で地獄を見る率が 150% ．
そもそも「全箇所……とは？」っていうことになりますし．
#2
総合スコア4446
投稿2026/06/29 09:33
共通化に「早すぎる」という概念はないと思います。早すぎる最適化の話と混同していそうに思います。
概念が同じであるものには常に同じものを使い、むしろ共通化されていない状態を許容しないようにするべきです。
もしも、未来にその共通処理から一部の利用者に対して異なる処理を行いたい要件が発生したなら、そのタイミングで処理を複製し、分離するのです。
よくある誤った共通化に、「概念が異なる処理なのに、コード記述が同じだからと流用する共通化 (変更の単位が異なるものを流用している)」「共通化された処理にフラグを追加して中で処理を分けている (そもそも共通処理じゃない/共通化の分割単位が正しくない)」というものがあるので、これらを間違って共通化しなければ、共通化は積極的に行う方が良いです。
- 「似たような処理なら共通化してよいか」-> よくないです。処理が似ているかどうかと、同じ目的を達成したいものかどうかは直交する概念です。後者はなるべく共通化すべきで、前者だけであれば絶対に共通化してはいけません。
- 「3箇所以上で使われるまでは絶対に共通化させない」-> 3箇所以上で使われることと、その処理が同じ概念であるかどうかは別です。同じ概念なら、2箇所で使われる処理でも共通化していくべきです。
ただし、同一の概念で同一の処理であるにも関わらず、共通化せずに各ロジックの内部に複製コードを書いた方がむしろ良い例外ケースがあります。それは、「ビジネス要件に一切依存せず、誰がいつ書いても常に同じ処理になるようなユーティリティ処理」です。
これらには共通化の際に処理を置くべき「適切なドメイン」というものが存在しないため、共通化したところで共通処理として統一的に使わせることが難しく、また他人が同一処理を無から再発明するシナリオが残り続け、未来の重複を防ぐことが本質的に困難なものです。
これらに関しては、共通化せずに各サービスレイヤーコードが private に持つことは問題ないと考えています。ただし、public にしないことが必須条件となります。
例外と言ったものの、実は「共通化可能に見える同一処理」がこれに該当するケースはかなり多く、これらを共通化すべきかで悩んでいるのかもしれません。
しかしこれらは「未来に機能が変更される可能性が限りなく低い」ため、共通化することによって無用な依存関係という負債を導入することになり、共通化しない方が総合的に利益が大きくなる可能性が高いと考えており、自分はこれらを一切共通化しないようにしています。
結論、ビジネスロジック上の同一概念は全て共通化し、ドメイン依存を持たないユーティリティ処理は同一でも共通化しないのが正解です。
#3
総合スコア13504
投稿2026/06/30 05:31
2回目の段階では、それが本当に同じ目的の処理なのか、たまたま今同じなだけなのかが見極められない
というのは、その処理が何なのか分かってないということではないでしょうか。その点だけでも、判断する材料が揃ってないのでは。
また段取りとして、共通化したものを分けることは『修正のタイミング』で行うだけですが、後々重複を共通化するというのははっきりした『タイミング』がありません。聞き手に「半年後(とか1年後とかプロジェクト終了時とか)に同じままだったら共通化だね」と言うのでしょうか。
#4
総合スコア12463
投稿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}
#5
総合スコア140
投稿2026/06/30 11:56
- 概念として同じことをやろうとしているのか、たまたまコードが似ているだけなのか
- 不変な要素と流動的な要素の切り分け
- ただ作るだけじゃなく、この処理はどういう時に使う（逆にいえば、それをやりたいときはこれを使う）というルールの徹底
また、ここで言われている共通化が「抽象化」も含むのならば、特に上二つはより慎重に検討すべきでしょう。
これらを、責任をもってやれるならば積極的に共通化すべきですが、それが出来ない無責任な共通化はすべきではないと思います。
共通部品は一度作ったらなかなか変更できませんので、慎重に検討する必要があります。
一方、本格的なライブラリ開発ではなく、極めてスコープの狭い範囲だけ（例えば自分の受け持つ範囲だけで有効とか）で使うような共通化処理を書く余地があるのならば、ある程度自由にやってもいいと思います。共通部品の「重さ」は影響スコープの広さに比例するからです。
#6
総合スコア370
投稿2026/06/30 23:23
編集2026/06/30 23:28元の質問は、具体的にかいてないので、書いてない部分は、かってに仮定して回答になってしまう。難しい
雑談提供だからそうなのかな
fanaさんの一例だとシンプルでわかりやすいです
時間がない時に応急処置で、やってしまいますね、テストも短くて済みますしｗ
でも、あとで地獄をみるんですよね。
だから、残り寿命で、決めちゃうことも多いですね
残り寿命が短いと地獄を見る前に製品自体が消滅してしまうのでｗ
#7
総合スコア12463
投稿2026/07/01 01:18
残り寿命
（これがまた，想定の 250% くらいになったりして…）
#8
総合スコア302
投稿2026/07/01 09:27
編集2026/07/01 09:31回答を見るまで別の意見だったけど、回答を見る限り
コードが似てるから共通化しようという判断を持ち込むのがまず間違っていて、仕様的に同じなら同じにする、仕様的に別なら別にする、これ以外ないと思う。
似てるコードは共通化（汎用関数にする）みたいなのが仕様ならその仕様に乗っ取った関数を作る、やり方にする、だけの話
つまり判断するのは同じコードにしていいか、ではなく同じ仕様にしていいかって話だな
#9
総合スコア333
投稿2026/07/08 07:09
仕様に近いですが、ビジネスロジックが共通しているかどうかも結構大事な気がします。
なので、そういう観点アドバイスするかなと思います。
振る舞いが現状似ていても、プロダクトやサービスが大きくなるにつれ、担っているビジネスロジックが異なっている場合、共通項がどんどん少なくなり、if文やpropsが大量にある共通コード（キメラ）になるので...
ただ、そのあたり考えて実装するの難しいな（経験やセンス、ビジネスに対する関心次第）ってきがするので、全員に求めるには意外とハードル高かったりって感じてます。
自分が実装者のときはそこを意識しますし、レビューするときはそこの観点でレビューします。
それ以外は気付けないので放置して、気づいたときに考える...って感じです
あなたの回答
tips
プレビュー