メインコンテンツまでスキップ

第81章：技術的負債を「意図的に」作る 〜リリース優先の判断基準〜 🚀💸

「設計がキレイじゃないと出せない…」って悩むと、いつまでもリリースできなくなるよね🥲 でも逆に「雑に出したら地獄」もある…😇 この章は、その中間の “コントロールされた雑さ” を作る話だよ✨

今日のゴール 🎯✨​

  • 技術的負債を「事故」じゃなく「戦略」にする考え方を身につける🧠
  • “借金していい場所 / ダメな場所” を判断できるようになる✅
  • 後で返せるように、返済計画つきの負債 を作れるようになる📒💪

Technical Debt Concept

技術的負債ってなに？💡​

ざっくり言うと、

  • 今すぐ早く進むために、未来の自分にツケを回すこと 😅
  • ただし、ツケには 利息（直すのがどんどん大変になる） がつく💦

技術的負債そのものは悪じゃないよ🙅‍♀️ 問題なのは…

  • 「気づかないうちに増える」
  • 「返す気がない」
  • 「返せない場所に作る」

この3つが合体したとき！☠️

「意図的な負債」 vs 「事故の負債」🚑🧯​

✅ 意図的な負債（OK）​

  • どこにあるか分かる👀
  • 期限か条件が決まってる📅
  • 返し方が決まってる🧾
  • 影響範囲が小さく、封じ込めている🧱

❌ 事故の負債（ヤバい）​

  • どこにあるか分からない🙈
  • 期限も返済計画もない😇
  • コア部分に混ざって広がる🦠
  • AIに増築させてカオス化🤖🔥

1人開発で「意図的な負債」が超大事な理由 🧑‍💻✨​

1人だと最初に必要なのはだいたいこれ👇

  • 仕様が本当に合ってるか、早く確かめたい👂
  • ユーザーの反応を見て方向転換したい🧭
  • “完璧な設計” より “生きたフィードバック” が欲しい📣

つまり… 最初から全部きれいに作るのは、むしろリスク なことが多いんだよね😌

借金していいか？判断チェックリスト ✅🧠​

迷ったら、この順で考えるのがおすすめだよ✨

① そこは「コア」？それとも「周辺」？🎯​

  • コア（勝負所）：借金しにくい（利息が爆増しやすい）💥
  • 周辺（ログ・通知・管理画面・一時的な画面）：借金しやすい🙂

② 仕様が固まってる？まだ揺れてる？🌊​

  • 揺れてるなら、きれいに作るほど「作り直し」確率が上がる😵 → とりあえず出す価値 が上がる📈

③ 影響範囲は小さい？広い？🧨​

  • 1画面だけ、1機能だけ → 借金OK寄り👌
  • 共有ライブラリやドメイン根幹 → 借金NG寄り🙅‍♀️

④ 後で “差し替え可能” にしてる？🔌​

  • インターフェースで隠す
  • メソッド1個に押し込める
  • フォルダを分ける

この「逃げ道」があるほど安全🛟✨

⑤ テストで守れる？🧪​

借金しても、振る舞いがテストで守られてると返済がラク！💪 （テストは“保険”だよ〜🏥）

⑥ 返済のタイミングが決められる？⏳​

  • 「βを出したら返す」
  • 「ユーザーが10人超えたら返す」
  • 「次のスプリントで返す」

みたいに 条件つきでもOK 🙆‍♀️

⑦ “記録” する？しない？📒​

記録しない借金は、だいたい踏み倒す😇 なので「借金台帳」作ろ！

借金台帳（Debt Ledger）テンプレ 📒✨​

そのままメモ帳やIssueに貼ってOKだよ🫶

  • ID：DEBT-001
  • 場所：Application/Order/ の CreateOrderHandler
  • 内容：割引計算を if 文直書き（本当はポリシーに分離したい）
  • 理由：仕様がまだ揺れてる／今週リリース優先
  • リスク：中（仕様確定後に書き換え必須）
  • 封じ込め策：IDiscountPolicy に差し替え予定、呼び出し箇所は1つ
  • 返済条件：割引ルールが確定したタイミング
  • 返済作業：Policy化 + テスト追加
  • 期限：2026-02-XX（目安でOK）

これがあるだけで、未来の自分が泣かない😭✨

“借金していい実装” の作り方（C#例）🧱✨​

例：割引ルールがまだ曖昧。でも注文は先に出したい！🛒💨 👉 割引だけ「差し替え前提」にして雑実装 する作戦💡

public interface IDiscountPolicy
{
    decimal CalculateDiscount(decimal subtotal, string? couponCode);
}

// とりあえず版（借金！でも差し替えやすい場所に隔離してる）
public sealed class TemporaryDiscountPolicy : IDiscountPolicy
{
    public decimal CalculateDiscount(decimal subtotal, string? couponCode)
    {
        if (string.IsNullOrWhiteSpace(couponCode)) return 0m;

        // DEBT-001: 仕様が固まったらルールをドメイン側へ移動＆テスト強化
        return couponCode switch
        {
            "WELCOME10" => Math.Min(1000m, subtotal * 0.10m),
            "VIP"       => Math.Min(3000m, subtotal * 0.15m),
            _           => 0m
        };
    }
}

ポイントはここだよ👇🥰

  • 雑でもOK。でも 雑さを1クラスに閉じ込めてる 🧱
  • 後で本物（ちゃんとしたドメインルール）に 差し替えやすい 🔁
  • 借金ID（DEBT-001）を入れて追跡できる👀

絶対に“借金しちゃダメ”ゾーン 🚫🔥​

ここで借金すると、だいたい取り返しつかなくなるよ🥶

  • 認証・認可（ログイン、権限）🔐
  • お金・課金・ポイント計算💴（間違えると信用が死ぬ）
  • 個人情報の扱い（保存・ログ出力）🧑‍⚖️
  • データの整合性（重複登録、二重決済など）💥
  • 監査・ログ（後で追えないと詰む）📝

ここは最初から堅めが正解🙆‍♀️✨

AI（Copilot等）に“借金前提で作らせる”プロンプト例 🤖💬​

そのまま貼って使えるやつ置いとくね🫶✨

プロンプト（例）

  • 「2日でβリリースしたい。割引仕様は未確定。将来差し替えやすい形で“暫定実装”を作って」
  • 「暫定部分は1箇所に隔離して、インターフェース越しに呼ぶ構造にして」
  • 「借金台帳（Debt Ledger）も一緒に箇条書きで出して」
  • 「“絶対に借金しない場所” を指摘して、危険なら止めて」

AIに「雑に作っていいよ」じゃなくて、 “雑さを閉じ込めてね” って言うのがコツだよ🧠✨

ミニ演習（15〜30分）🧪✨​

あなたのアプリで、今悩んでる機能を1つ選んでね😊

  1. 「今すぐ出すなら雑にしたい部分」を3つ書く📝

  2. それぞれに 封じ込め策（差し替え口） を考える🔌

  3. 借金台帳を3件ぶん作る📒

  4. AIにこう聞く👇

    • 「この借金は危険？利息は高い？より安全な封じ込め案ある？」

できたら、未来の自分が拍手するやつ👏🥳

まとめ 🎉​

  • 技術的負債は「悪」じゃない🙅‍♀️
  • でも “意図的” にしないと事故る 🚑
  • 借金していい条件は 封じ込め・可視化・返済計画 の3点セット🧱📒⏳
  • AI時代は特に、境界線（差し替え口）を人間が作る のが最強✨🤖