はじめに
前回（②大原則編）で、設計の7つの大原則と、その親玉「変更に強くする」を腹落ちさせた私。いい感じに賢くなった気がして、調子に乗ってました。
特にDRY。「同じ知識は一箇所に」。これはもう完全に理解した。似たコードを見つけたら、まとめればいいんでしょ？ 簡単じゃん。……と思っていたら、先輩に冷たい目で止められたのが前回のラスト。
：DRY守ってるだけなのに、なんでダメなんですか？
：その「似てたらまとめればいい」が、一番事故るやつやからや。
今回はこの 「線引き」 の話です。原則を知ってるのに、なぜか実務でうまく使えない——たぶんこのシリーズで一番、私が長いこと悩んできたところ。
原則を知ってても、使えない
正直に告白すると、私はエンジニア4年目で、ここに挙げた原則は全部「聞いたことある」レベルでは知ってました。SOLIDもDRYもYAGNIも。
でも、知ってるのに使えない。
- DRY：目の前の似たコード、これは共通化すべき？ それとも放っておくべき？
- YAGNI：この機能、今作るべき？ それとも「まだ要らない」？
- 抽象化：このクラス、インターフェース切るべき？ やりすぎ？
全部、「どこで線を引くか」 がわからない。原則は知ってるのに、いざ手を動かすと毎回迷う。
そして、さっき先輩が言った通り、線引きをミスると「やらなさすぎ」より 「やりすぎ」の方が地獄 だったりします。良かれと思って共通化したコードが、いつの間にか全機能から参照される密結合の塊になって、一箇所いじると全部が連鎖崩壊する……ってやつ。
ミノ駆動さんの有名なクソコード動画「共通化の罠」が、まさにこれを的確に描いてて、初見で笑ったあと真顔になります。
「共通化、よかれと思ってやったのに、なんで地獄になるの？」── この感覚、心当たりある人多いんじゃないでしょうか。私はめちゃくちゃあります。
え、私のせいじゃない…？
なぜ線引きは「本質的に」難しいのか
先輩いわく、線引きが難しいのは努力や才能の問題じゃなくて、そもそもの構造が難しいからだそうです。理由は4つ。
理由1：文脈で正解が変わる
同じコードでも、状況次第で正解が逆になります。
「絶対の正解」が存在しないから、原則を機械的に当てはめても外れる。
理由2：原則同士がケンカする
前回「7つは全部地続き」と言いましたが、実務では原則同士がぶつかることもあります。
- DRY（重複を消せ）と YAGNI（先回りするな）：「2回しか出てないけど、3回目が来そう。今まとめる？」
- 高凝集（きっちり分けろ）と シンプルさ：「完璧に分けるとファイルが爆発する」
前回「7つは全部同時には満たせない、どれをどこまで適用するかは毎回トレードオフ」と言いましたが、まさにこれです。
理由3：未来予測は、たいてい外れる
線引きの多くは「将来どうなるか」の予測に依存します。「この機能、将来拡張されるかな？」と。
理由4：答え合わせが、数ヶ月〜数年後に来る
これが一番きつい。設計判断が良かったか悪かったかは、変更が必要になった瞬間 に初めてわかります。
……というわけで、線引きが難しいのは私の能力のせいじゃなかった。構造的にムズいんです。ちょっと安心しました
じゃあ、どうすればいいのか
コツ① 3回ルール（Rule of Three）
DRYの線引きで一番実用的なやつ。「同じコードが何回出たら共通化するか」のヒューリスティックです。
- 1回目：とりあえず書く
- 2回目：コピペでOK（多少モヤッとしても我慢）
- 3回目：ここで初めて「共通化する？」を検討
前回（②）のDRYで、「住所みたいに同じ"知識"があちこちに散らばってるのは、消すべき重複」という話をしました。でも厄介なのはその逆で、たまたま見た目が似てるだけのコードは、共通化すると事故ることがある。3回ルールは、この「本物の重複」と「似てるだけ」を見極めるための「待ち時間」なんですね。
「早すぎる抽象化のコスト ＞ 重複のコスト」
コツ② 迷ったら、具象に倒す
これも実務で効く指針です。迷ったら、共通化せずにベタ書きしておけ。
理由は、抽象化には 非対称性 があるから。
具象 → 抽象（後でまとめる） ：軽い。3つ目が出たらやればいい
抽象 → 具象（まとめたのを剥がす）：重い。依存してる全部を直す羽目に
進む方向（具象→抽象）は軽くて、戻る方向（抽象→具象）は重い。だったら、軽い方に倒しておくのが安全。迷ったら具象、これだけで設計の事故がだいぶ減ります。
コツ③ 「戻すコスト」を毎回問う
3つ目は、前回の 可逆性 の実践版。判断する前に、毎回これを問います。
「この判断、もし間違ってたら、戻すのに何がかかる？」
「絶対正しい選択」は選べなくても、「間違えても傷が浅い選択」なら選べる。これが不確実な中での現実的な戦い方です。
共通化、ありがちな2つの失敗
コツがわかったところで、逆に「やりがちな失敗」も知っておくと事故が減ります。2方向あります。
失敗1：「似てる」を「同じ」と勘違いする
前回ちらっと出した、この例。
calculateUserScore(user) { return user.points * 1.5; }
calculateProductScore(product) { return product.rating * 1.5; }
calculateOrderScore(order) { return order.amount * 1.5; }
3つとも * 1.5 してて、見た目はそっくり。「DRYだ！まとめよう！」と、こうしたくなる。
calculateScore(value) { return value * 1.5; }
ここで効くのが、前回も出た判断基準です。
「この3つは、"同じ理由で"変更されるか？」
同じ仕様変更が来たら3つとも一緒に変わる、なら共通化してOK。でも「ユーザーのスコアだけ変えたい」が起こりうる＝変わる理由が別々なら、たまたま今は似てるだけ。消しちゃダメ。
失敗2：逆に、重複を放置しすぎる
「具象に倒せ」「3回ルール」を聞くと、今度は「じゃあ共通化しなきゃいいんだ」と振り切る人がいます。これも失敗。
3回ルールは「早すぎる共通化を防ぐ」ためのもので、「永遠に共通化するな」じゃない。
いい質問です。そして、それが今回の結論に繋がります。
結論：線引き力は「言語化」で育つ
ただ、「振り返りの質」を上げる具体的な方法はあります。それが 判断の言語化 です。
設計判断するとき、頭の中だけで決めて終わりにせず、こう書き残す。
【検討した選択肢】
A. 共通化する B. 重複のまま残す C. 一部だけ共通化
【選んだ理由】
今は2箇所だが、関連機能で3箇所目が確実に出るのでA。
ただし実装時に再評価する余地を残す。
【切ったトレードオフ】
抽象化レイヤーが1段増える。将来仕様が分岐したときのリスクは残る。
書き残すことで、遅れてくる答え合わせを「あのとき何を考えてたか」と突き合わせられる。これが振り返りの質を上げ、線引きの嗅覚を育てる。地道だけど、これが王道なんですね。
まとめ
今回のポイント。
- 原則を知ってても線引きできないのは、勉強不足じゃなく構造的に難しいから（文脈依存／原則のトレードオフ／予測はたいてい外れる／答え合わせが遅い）
- 完璧な正解は出せないが、判断の質を上げるコツはある
- 3回ルール：3回出るまで共通化を待つ
- 迷ったら具象：抽象化は軽い、解体は重い。軽い方に倒す
- 戻すコストを問う：「間違えたら戻すのに何がかかる？」で選ぶ
- 共通化の失敗は2方向：「似てる」を「同じ」と勘違い／逆に放置しすぎ。 「変わる理由が同じか」 で判断
- 線引き力は 経験量 × 振り返りの質 でしか伸びない。判断の言語化（PR・ADR）が振り返りの質を上げる
線引きに「これさえやればOK」の魔法はない。でも、向き合い方の型はある。これを知ってるだけで、毎回の迷いが「意味のある迷い」に変わると思います。
で、次回
線引きの基本戦略が見えてきました。「迷ったら具象から始めて、共通項が見えてから抽象化する」。これで万事解決……かと思いきや、先輩が一言。
次回は、「具象から始める」戦略が通用しない例外 ── 「契約」の設計 に踏み込みます。