はじめに：「DRY原則」は絶対正義か？
エンジニアとしてキャリアを積むと、「DRY（Don't Repeat Yourself）」や「Clean Architecture」 こそが絶対的な正義であると信じ込んでしまう時期があります。
- コピペコードは悪だ。
- ハードコーディングは罪だ。
- 共通化されていない処理は、即刻リファクタリングすべきだ。
かつての私もそうでした。
しかし、私は現在、「エンジニア」としてコードを書きながら、「経営者」として会社のPL（損益計算書）を見ています。
その二つの視点を持った今、私は断言できます。
「ビジネスを成功させるために、あえて『汚いコード（技術的負債）』を選ぶべき瞬間がある」
今回は、技術的な正しさよりも「利益と納期」を優先する際の、私の 「戦略的判断基準」 を共有します。これは、エンジニアとしての魂を売る話ではありません。ビジネスという戦場で生き残るための、武器の話です。
1. 技術的負債＝「借金（レバレッジ）」である
経営において「借金（Debt）」は必ずしも悪ではありません。
事業を拡大するための「融資」は、成長を加速させるためのレバレッジ（てこ） です。
エンジニアリングにおける「技術的負債」も全く同じです。
戦略的負債の定義
「今、リファクタリングに使うはずだった3日間を借り入れて、リリースを早め、市場の反応を見る」こと。
これは、スタートアップや新規事業においては極めて合理的な投資行動です。
悪いのは「借金すること」そのものではなく、「返済計画のない借金（闇雲なスパゲッティコード）」 を作ることです。
2. 私が「あえてコピペ」を指示する3つのケース
私は自社の開発や、クライアントワーク（PM業務）において、メンバーに 「ここは共通化しないで。コピペでいいよ」 と指示することがあります。
その判断基準は以下の3点です。
Case A: 「生存期間（TTL）」が短い機能
- 状況: 来週の展示会のためだけのデモ機能、あるいは1ヶ月限定のLP（ランディングページ）。
- 判断: 共通化禁止。フルハードコーディング推奨。
- 理由: この機能は、数週間後にはゴミ箱行きです。捨てることが確定しているコードを綺麗に設計するのは、経営視点で見れば**「コストの無駄遣い」**でしかありません。
Case B: 「仕様変更」の方向性が定まっていないPoC
- 状況: 新規事業のMVP（Minimum Viable Product）。仕様がまだ固まっておらず、ユーザーの反応次第で大きく変わる可能性がある。
- 判断: 拙速な抽象化（共通化）を避ける。
- 理由: 「将来使うかも」と思って作った共通クラスは、大抵使いません（YAGNI原則）。むしろ、仕様変更が入った時に、共通化されているせいで 「あっちを直すとこっちが壊れる」 という結合度の高さが足かせになります。このフェーズでは、コピペで独立させておいた方が、破壊的な変更に強いのです。
Case C: 「納期」が「品質」より優先される契約
- 状況: 「今月中にリリースできれば大型契約が決まる。できなければ契約破棄」という瀬戸際。
- 判断: テストコードは書かなくていい。動くものを出せ。
-
理由: ここでエンジニアが「テストカバレッジが...」とこだわり、納期を逃せば、会社の売上が消えます。売上が消えれば、エンジニアの給料も払えません。
「まずは稼ぐ。稼いだ金で、来月リファクタリングする」 という順序が、ビジネスでは正義です。
3. 「良い負債」にするためのたった一つのルール
ただし、汚いコードを放置すれば、それは「不良債権」になり、いつか開発チームを破綻させます。
私が「コピペ」や「ハードコーディング」を許容する時、必ずセットで守らせるルールがあります。
「『なぜ汚く書いたか』と『いつ直すか』をコメントに残すこと」
// TODO: 展示会デモ用（2026-02-28）
// 展示会終了後にこのファイルごと削除する。
// そのため、あえてUserComponentとは共通化せずに実装している。
//
// 返済計画: 2026-03-05 までに本番実装へリプレース
const demoUserData = {
id: 'demo-001',
name: 'テスト ユーザー',
role: 'admin' // 本来はRBACで管理
};
このように 「意図的な負債である」と宣言されていれば 、後から見たエンジニア（あるいは未来の自分）は迷わず削除やリファクタリングができます。
一番怖いのは、「何も考えずに書かれた汚いコード」なのか「意図を持って書かれた戦略的な汚いコード」なのか区別がつかないことです。
4. エンジニアのコスト意識（PL脳）
エンジニアの単価を時給8,000円と仮定します（外注単価の目安）。
「綺麗な設計」にこだわってリリースが1週間（40時間）遅れた場合、直接的な人件費だけで32万円のコスト増です。
さらに、その1週間の遅れで競合他社に顧客を奪われた場合の 機会損失（Opportunity Cost） は、数百万円、数千万円になるかもしれません。
「このリファクタリングは、数百万の機会損失に見合う価値があるか？」
経営者兼エンジニアは、常にこの問いを自分に投げかけています。
具体例：SUSの現場でよくある「技術的負債」のROI計算
| 項目 | 内容 |
|---|---|
| 案件 | 顧客管理システムの追加機能開発 |
| 要件 | 1週間後のデモで「AI分析機能」を見せる必要がある |
| 選択肢A | 綺麗な設計で実装（設計2日＋実装3日＋テスト2日）＝ 納期不可 |
| 選択肢B | コピペで動作するデモを作り、本番は後で作り直す（実装1.5日） |
| 判断 | 選択肢Bを選び、コメントに「本番リリース前にリファクタリング必須（2026-03-10）」と記載 |
結果：
デモで契約獲得（年間1,200万円）。その後、獲得した予算でリファクタリングを実施。
まとめ：真の「シニアエンジニア」とは
技術的な理想を追求できるエンジニアは優秀です。
しかし、「ビジネスの状況に応じて、あえて理想を捨て、泥臭い現実解を選べるエンジニア」 こそが、本当の意味でのシニアエンジニアであり、経営者がパートナーとして呼びたい人材です。
- 技術的視点: Clean Architecture, DRY原則, カバレッジ100%
- 経営的視点: Time to Market, ROI, Cash Flow
この両方の変数を扱えるようになると、エンジニアリングはもっと面白くなります。
私はこれからも、「利益を生むためのコピペ」 を恐れずに使い分けていきます。
この記事を書いた人✏️@YushiYamamoto
株式会社プロドウガ CEO / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。