- なぜ僕たちは“全部作り直したい病”にかかるのか
- ■「全部作り直した方が早い」—— そう思い込む理由
- ■Big Bang Rewrite の現実は、意外なほどシビア
- ■“コードをキレイにすること”と“ビジネスの成功”はイコールではない
- ■“全部作り直す”より、もっと強い戦い方がある
- ■なぜPurposeful Debtという考え方が海外で強いのか？
- ■この記事の目的
- Purposeful Debtという考え方が、現場を救う
- ■Purposeful Debtとは何か？一言で言うと「選択」である
- ■海外の現場では、負債は「悪」ではなく「管理対象」になる
- ■Purposeful Debt がもたらす 3つのメリット
- ■Purposeful Debt をどうやって現場に導入するのか？
- ■“Purposeful Debt” は海外で強いエンジニアの共通スキル
- ■まとめ：Purposeful Debt は「海外で生き抜くための現実的戦略」
- 小さく勝つための「今すぐ処理できる技術的負債」の見つけ方
- ■負債を「全部眺める」から「粒度で分ける」に頭を切り替える
- ■低コスト × 高リターンを狙う：「負債の4象限」での選別
- ■負債の優先度を正しく判断するための「3つの質問」
- ■「これだけやれば一気に変わる」負債の典型例（WPF 版）
- ■海外で使われる「すぐできる負債改善」のルール
- ■なぜ「今すぐ拾える負債」を見つけるスキルが重要なのか？
- ■まとめ：負債の山から“1つの果実”だけを取っていく
- 未来を選び取る技術――「戦略的に借りて、戦略的に返す」エンジニアの生き方
- ●日本では「負債＝悪」だが、海外では「負債は戦略」
- ●未来をよくするために、あえて「返さない」という選択肢もある
- ●Purposeful Debt は「2つの未来」を作る技術
- ●Rewrite か Purposeful Debt か――正解はその人の“哲学”にある
- ●最後に：Purposeful Debt は “技術” ではなく “生き方” だ
なぜ僕たちは“全部作り直したい病”にかかるのか
〜Big Bang Rewrite の誘惑と、その裏に潜む落とし穴〜
（約3000文字）
正直に言います。僕も昔は「こんな古いコード、もう全部作り直したい！」と思っていました。
あなたも同じ気持ちになったこと、絶対ありますよね？
- 10年以上前の WPF アプリ
- MVVM が中途半端に入っている
- どこに何が書いてあるかわからない ViewModel
- コメントは化石のように古い
- 依存関係は複雑すぎて誰も触れない
海外で働き始めて最初のプロジェクトも、まさにそんな“レガシーコードのデパート”でした。
レビューを受けるとき、先輩エンジニアに “It works… somehow.” と肩をすくめて言われたのを今でも覚えています。
■「全部作り直した方が早い」—— そう思い込む理由
レガシーに直面したエンジニアの脳はこう動きます。
- 「このコード、いじるのムリじゃね？」
- 「直すより作り直したほうが綺麗じゃない？」
- 「というか気持ちよく書きたい！」
特に日本から海外に出ると、自由度の高い開発文化に触れて「どうせなら全部リファクタしてしまえ！」という気分になるんですよね。
でも、これが 危険な「全部作り直せば幸せになれる」神話 の始まりです。
■Big Bang Rewrite の現実は、意外なほどシビア
海外の現場でよく聞いたフレーズがあります。
“A total rewrite is a controlled detonation.”（全面書き換えは、制御された爆破だ）
かっこいい言い方ですが、要するに
「爆発するかどうかは運次第」
という意味です。
なぜか？
- 全機能を把握している人が誰もいない
- 影響範囲がブラックボックス
- 運用中の顧客が多すぎて止められない
- テストコードも古くて信用できない
- 作り直しているうちに仕様が変わる
- 途中で経営判断が変わる
実際、僕がいた海外企業でも、1年以上かけて作り直した新バージョンが結局リリースされず、プロジェクト終了という悲劇がありました。
現場の誰も腐ったコードを愛していたわけではありません。
でも、市場や顧客は「完璧なコード」を待ってはくれません。
■“コードをキレイにすること”と“ビジネスの成功”はイコールではない
技術者にとって「綺麗なコードを書く」ことは誇りです。
でも海外の現場ほど、こう言われることがあります。
“The business doesn’t care about your clean code.”
（ビジネスはあなたの綺麗なコードなんて気にしない）
最初はショックでした。
でも、半年、1年と海外で働いて気づきました。
これは技術を軽視しているわけじゃなくて、
「価値を届け続けることの方が重要だ」
という意味なんです。
コードが綺麗かどうかはユーザーには見えません。
でも、バグが減ること、機能が早く出ること、安定することは体感できます。
その結果、僕自身の意識も変わっていきました。
「作り直す」ではなく「動くものをより良くする」
この方針の方が、圧倒的に成果が出る。
■“全部作り直す”より、もっと強い戦い方がある
Big Bang Rewrite の誘惑に負けそうになっていた僕に、
あるアメリカ人シニアエンジニアが言いました。
“Don’t fight the debt. Control it.”
（負債と戦うんじゃない。負債をコントロールするんだ）
そのとき初めて聞いたのが
Purposeful Debt（目的を持った負債）
という概念でした。
これは、技術的負債をゼロにするのではなく、
「どの負債を抱え、どの負債を返すかを意図的に選ぶ」
という戦略です。
これを知った瞬間、僕は
「技術的負債 = 悪」
という固定観念から一気に解放されました。
■なぜPurposeful Debtという考え方が海外で強いのか？
海外のチームは、
- スピード
- 競争
- ユーザー価値
- 小さく早くリリースする文化
これがとても強い。
だから「全部書き直そう！」というアイデアはほぼ支持されません。
代わりに言われるのは、
- 今変えるべき部分はどこ？
- 本当に困っている人は誰？
- リターンが大きいのはどこ？
- 来月のリリースに間に合う？
- 逆に、今いじると危険な場所はどこ？
つまり、
“負債と仲良く付き合う”文化
なんです。
日本にいた頃は「負債はゼロにするもの」と思っていましたが、
海外で働くようになってからは
「目的のある負債なら、それは戦略になる」
という考えに変わりました。
■この記事の目的
この記事は、ただ「技術的負債は悪くない」という話ではありません。
あなたが海外で “生き残る力” を持つための思考法を共有すること
これが目的です。
次の「承」では、その鍵になる
Purposeful Debt の具体的な考え方
について深掘りしていきます。
Purposeful Debtという考え方が、現場を救う
〜「負債はゼロにできない。でも、武器にすることはできる」〜
（約3000文字）
前回の「起」で、僕たちが陥りがちな「全部作り直したい病」について話しました。
そして、海外の現場が重視しているのは
“コードを綺麗にすること”ではなく“価値を届け続けること”
だという文化の違いにも触れました。
今回はその続きとして、
**Purposeful Debt（目的ある負債）**という考え方が、なぜ現場を救うのか。
そして、それがどんな“武器”になるのかを掘り下げていきます。
■Purposeful Debtとは何か？一言で言うと「選択」である
技術的負債という言葉は、ネガティブな響きを持っています。
「負債」という言葉がそもそも悪い印象を与えますよね。
でも、Purposeful Debt の考え方は全く逆です。
Purposeful Debt = “選んで抱える負債” のこと。
つまり、
- どの負債を今返すべきか
- どの負債を後回しにするべきか
- どの負債はあえて残したほうが良いか
これを “意図的に” 決めるということなんです。
これを知ったとき、僕は「技術的負債はゼロにするもの」という常識が崩れました。
負債は、悪でも敵でもなく、
“プロジェクトを前に進めるための資源でもある”
という視点に変わりました。
■海外の現場では、負債は「悪」ではなく「管理対象」になる
海外の大規模チームで働くようになると、負債の扱いが日本とは全く違うことに驚きます。
日本：
- 負債は「トラブルの元」
- できれば全部解消したいもの
- 担当者が責任を負うもの
- 一度たまると誰も触れなくなる
海外：
- 負債は「プロダクトの自然な状態」
- 計画的に管理するもの
- スプリントやロードマップに組み込むもの
- プロダクトの成長とともに変化するもの
要するに、海外では負債は健康診断のようなもので、
定期的に測り、コントロールするもの
として扱われています。
これがめちゃくちゃ合理的なんです。
■Purposeful Debt がもたらす 3つのメリット
1. チームが“本当に重要なこと”に集中できる
負債ゼロを目指していると、どうしても視野が狭くなります。
- 「ここも直したい」
- 「この設計は古いから変えたい」
- 「このクラスの責務デカすぎる」
全部大事ですが、すべて優先度が高いわけではありません。
Purposeful Debt を導入すると、
“直さないとヤバい負債” と “直さなくても影響が小さい負債”
が明確になります。
これにより、チームのエネルギーを
価値を生む仕事に集中
させることができます。
2. スピードと品質のバランスが取れる
海外ではよくこう言われます。
“Speed is a feature.”（スピードも機能の一つだ）
遅いチームは負けます。
でも、雑すぎる実装は後で必ずしわ寄せが来ます。
だからこそ Purposeful Debt が効いてきます。
負債を「戦略的に残す」という選択ができると、
短期的なスピードと長期的な安定性の両立
が可能になります。
3. チーム全体の精神的負荷が下がる
負債が溜まっていると、チームの空気は重くなります。
- 「あのコード誰も触りたくない…」
- 「またバグ出るぞ…」
- 「もう手遅れじゃない？」
海外で働いていても、こういう空気を何度も経験しました。
でも、Purposeful Debt のフレームがあると、
- その負債は「後で返す予定」なのか
- 「今は触らなくていい」負債なのか
- 「危険だから今すぐ手を入れるべき」なのか
チーム全体で認識が合います。
認識が合うだけで、心理的にかなり楽になります。
■Purposeful Debt をどうやって現場に導入するのか？
実際の現場では、次の 4 つのステップで導入することが多かったです。
STEP1：負債の“棚卸し”をする
まずは現状の負債を洗い出します。
- 依存関係が複雑
- テストがない
- UI ロジックが View にスタックしてる
- SOLID 原則が死んでる
- どこを触ると何が壊れるかわからない
僕の海外プロジェクトでは、これを “Debt Inventory（負債インベントリ）” と呼んでいました。
STEP2：負債を「3つの箱」に分類する
負債は次の 3 つに分類します。
- Safe to ignore（しばらく放置OK）
- Plan to fix（計画的に返す）
- Critical（即対応しないと危険）
これをやると、「全部やる必要はない」ことが明確になります。
STEP3：ロードマップに組み込む
海外では当たり前ですが、負債返済のタスクをプロダクトロードマップに直接組み込みます。
例えば、
- Q2 の末に View 層の再構成
- Q3 にユニットテスト 20% → 40% に引き上げ
- 新機能開発のついでに古い部分を段階的に解体
こういった “計画性” が Purposeful Debt の核です。
STEP4：新しい負債を増やさない仕組みを作る
海外の現場では「負債をゼロにする」より、
“負債を計画的に管理できる状態を保つ”
ことが重視されます。
そのために、
- PRレビューを強化
- テストを必須化
- 小さなリファクタを日常化
- CI/CD で品質チェック
- コードオーナー制度の導入
こういった取り組みが自然とセットになります。
■“Purposeful Debt” は海外で強いエンジニアの共通スキル
海外の優秀なエンジニアは、
負債と戦うのではなく、負債を利用する
という使い方をします。
彼らは言います。
“We are not writing code. We are building a system that evolves.”
（私たちはコードを書いているんじゃない。進化し続けるシステムを作っているんだ）
進化し続けるシステムに負債はつきもの。
だから、Purposeful Debt の考え方が強力に効いてきます。
■まとめ：Purposeful Debt は「海外で生き抜くための現実的戦略」
- 負債はゼロにできない
- 負債は悪ではない
- 負債は計画すれば武器になる
Purposeful Debtは、
「スピード」と「品質」のどちらも手放さない、
海外で生き抜くための現実的で強力な戦略です。
次の「転」では、この考え方を実際の開発現場でどう使うか、
“今すぐ効果が出る負債の見つけ方”
を具体的に掘り下げていきます。
小さく勝つための「今すぐ処理できる技術的負債」の見つけ方
〜負債は“山”ではなく“粒”にして戦う〜
（約3000文字）
Purposeful Debt の概念がわかってくると、多くのエンジニアが次にこう悩み始めます。
「…で、どこから手を付ければいいの？」
僕も海外での初期、まさにこれで悩みました。
負債のリストはあっても、どれが “今の自分たちにとって価値があるのか” が見えない。
そこで、海外の現場で教わって、今でも最も役に立っているのが、
“Low-hanging fruit（低い位置にある果実）” の見極め方 です。
つまり、
努力が小さいのに、効果が大きい負債
を迷いなくピックアップできるようになる。
これができるエンジニアは、どの国に行っても確実に重宝されます。
■負債を「全部眺める」から「粒度で分ける」に頭を切り替える
海外のシニアエンジニアに最初に言われたのが、こんな一言でした。
“Don’t fight a mountain. Fight the pebbles.”
（山と戦うな。石ころと戦え。）
負債を「巨大な山」として捉えると、
どこから手を付けても地獄に見えます。
でも、その山を “粒に分解” すると、
急に “すぐ取れるもの” が見えてきます。
たとえば WPF の現場だと、
レガシーコードの山を全部直そうとすると絶望しますが、
- コードビハインドの 10 行だけロジックを切り出す
- INPC 実装の重複を 1 クラスだけ改善する
- DI の設定を 1 サービスだけ整える
- 1 つの ViewModel だけ責務を分割する
- XAML の巨大なスタイルを 1 つだけ Resource に分離する
こういう「石ころレベル」に分けると、
一つ一つは 30 分でできたりします。
ここが “負債を倒すコツ” なんです。
■低コスト × 高リターンを狙う：「負債の4象限」での選別
海外の現場でよく使われていたのが、
負債を次の 4つの象限に分類する方法 です。
① コスト低 × リターン高 → 最優先（すぐやる）
これが “Low-hanging fruit” です。
例：
- nullチェックを1段階追加するだけでバグが激減
- データ変換ロジックを専用クラスに移すだけでテスト可能になる
- 不要な依存関係を1つ切るだけでビルド時間が改善
- 単一の巨大メソッドを3つに分割 → 読解速度が倍に
- EventHandlerの解除漏れを1箇所だけ直すことでメモリリーク解消
こういう改善は インパクトが大きく、作業も小さい。
海外のエンジニアは、まずこれを拾います。
② コスト低 × リターン低 → スプリントの“ついで枠”
例：
- ラムダ式の簡略化
- コメントの更新
- 変数名の調整
- 小さな XAML の命名整理
優先度は高くないけど、
スプリントで余力があれば片付ける“掃除枠”。
③ コスト高 × リターン高 → 計画してやる
例：
- ViewModel全体の再構成
- レイヤーアーキテクチャの抜本改修
- テストの全面導入
- WPFのNavigation再設計
- 非同期処理の構造を Task ベースに総入れ替え
これは “やる価値はあるけど今は重すぎる” という類。
大抵ロードマップに吸収されます。
④ コスト高 × リターン低 → 触らない（放置が正解）
例：
- 今ほとんど使われていない古い画面の設計改善
- 動いているが美しくないコード（動作に問題がない）
- ほぼメンテされない特殊機能の内部構造改善
これは 触るメリットがない負債 です。
海外では、
「これ直したほうがきれいだけど、ビジネス価値ゼロだよね？」
と言われて、普通に却下されるやつです。
■負債の優先度を正しく判断するための「3つの質問」
僕が海外で教えてもらい、
今でも常に頭の中で使っている“判断基準”があります。
Q1：この改善は、ユーザーの痛みを減らすか？
- バグが減る
- 使いやすくなる
- レスポンスが改善する
ユーザー体験が変わるなら、優先度は爆上がりします。
Q2：将来の開発速度は上がるか？
- 変更が楽になる
- テストしやすくなる
- 依存関係が減る
開発速度に影響する改善は、海外では非常に高く評価されます。
Q3：リスクは減るのか？
- 事故らない設計になる
- 変な副作用が消える
- メモリリーク、スレッド問題がなくなる
WPF では特に
メモリリーク改善 = リスク削減の王様
です。
この3つを満たすほど、
「すぐやるべき負債」になります。
■「これだけやれば一気に変わる」負債の典型例（WPF 版）
WPF + MVVM の世界で、“低コスト × 大効果” の代表例をいくつか紹介します。
① コードビハインドのロジックを1つだけ ViewModel へ移動
→ テスト可能になる
→ 可読性UP
→ Viewの責務が減る
効果が大きいのに、作業は数分〜30分。
② INPC（通知プロパティ）の共通化
→ めちゃくちゃ記述量が減る
→ 可読性アップ
→ バグ源が激減
1日でプロジェクト全体が軽くなる。
③ 重複ロジックの切り出し
特に
- 日付計算
- 文字列加工
- Validation
- APIレスポンスの変換
など。
“重複の合流” は改善の王道。
④ XAML のリソース整理
- スタイル
- テンプレート
- Brushes
- Converters
これが1箇所にまとまるだけで、
メンテナンス性が段違いになります。
⑤ 非同期処理のUIスレッド問題を1箇所だけGo直し
WPFでは死ぬほどありがち。
タスクの ConfigureAwait(false) の整理や、Dispatcher の正しい使用を1箇所直すだけでバグが消えることも多い。
■海外で使われる「すぐできる負債改善」のルール
海外の現場では、負債の扱いにいくつか“文化的ルール”があります。
① PR で見つけた負債は、その場で直す（直せる規模なら）
レビューコメントで
「これ負債だね」と言うだけの人は評価されません。
海外は、
“If you see something, fix something.”
（見つけたならついでに直せ）
という文化が強い。
② スプリントに 10〜20% は“改善タスク枠”を確保する
これは Agile の基本でもありますが、
海外チームはこれを実際に徹底しています。
日本は「改善枠」が自然消滅しがちですが、
海外は「改善枠を削る」方がタブーです。
③ “Big Refactor”は禁止、日常の“小リファクタ”を積み重ねる
これは何度も強調されます。
“Big refactors kill projects.”
（大規模リファクタはプロジェクトを殺す）
海外はこの教訓を何度も経験しています。
④ 新機能を作るときは、既存の負債を1つ潰してから進む
これが個人的に一番好きなルール。
- 新しいコードを追加する前に
- 古い負債を1つ返済する
これで負債が自然に減っていきます。
■なぜ「今すぐ拾える負債」を見つけるスキルが重要なのか？
理由はシンプルです。
“負債を早く返せる人 = チームの価値を底上げできる人”
だから。
たった 15 分の改善でも、
- バグが減る
- レビューが早く進む
- 新人が理解しやすくなる
- テストが書きやすくなる
- 保守が楽になる
つまり、
チーム全体の生産性と幸福度が上がる。
海外で高く評価されるエンジニアは、
実は「大きな成果」を出す人ではなく、
小さな改善を継続できるエンジニア
だったりします。
■まとめ：負債の山から“1つの果実”だけを取っていく
- 負債は山のように見える
- でも実際は“石ころ”の集合体
- その中から「低コスト × 高リターン」を拾う
- 30 分の改善が、チームを救うこともある
- 海外で評価されるのは、小さく価値を積むエンジニア
Purposeful Debt を実践するためのカギは、
「全部やる」ではなく「今やる価値がある1つを選ぶ」
ことなんです。
次の「結」では、
海外で生き残るエンジニアに共通する
“負債と付き合う思考法の最終形”
についてまとめます。
未来を選び取る技術――「戦略的に借りて、戦略的に返す」エンジニアの生き方
◆結：Purposeful Debt がくれた「選択する勇気」
海外で働いていると、ふとした瞬間に気づくことがあります。
「あ、この判断って、技術じゃなくて 生き方の話なんだな」って。
これまで、僕は “Rewrite神話” と “Purposeful Debt” の話をしてきました。
つまり、完璧なゼロリセットを狙うか、今ある現実を素材にしながら前に進むか、という話です。
でもね、結局この2つって、技術選択というより、
「どんな未来を選ぶか」っていう哲学の問題なんです。
たとえば海外の同僚を見ていると、みんな意外とドライで、完璧主義じゃない。
「今できるベストを選ぼう」「未来のために、あえて負債を残してもいい」
そういう考え方が当たり前のように受け入れられている。
“Purposeful Debt”（目的を持った技術的負債）って、ただのテクニックじゃなくて、
海外エンジニアたちが長いキャリアの中で身につけてきた
「柔らかい判断力」 の集大成なんですよ。
●日本では「負債＝悪」だが、海外では「負債は戦略」
日本の現場にいたころ、負債と聞けば「返済しないと怒られるもの」というイメージが強かった。
レビューのときに「このコード、将来負債になるな」と言われたら、
即リファクタリングしなければいけない空気もあった。
でも海外では全然違う。
- 「これは今は負債でいいよ」
- 「完璧よりデリバリーを優先しよう」
- 「返すべきタイミングになったら返せばいい」
こんな会話が普通なんです。
最初は「え、本当に大丈夫？」ってビビったけど（笑）
彼らは 雑 をやりたいんじゃない。
“Return on Investment（ROI）を最大化する判断” をしているだけなんですよね。
あるシニアエンジニアが教えてくれた言葉が忘れられない。
“Tech debt is not a bug.
It’s a loan you take for a reason.”
（技術負債はバグじゃない。理由があって借りるローンだ。）
「Purposeful Debt」って、その一言に全部が集約されている気がします。
●未来をよくするために、あえて「返さない」という選択肢もある
あるプロジェクトで、古い WPF コントロールを大量に抱えたアプリがありました。
日本なら「どう考えても全部作り直しだな」と判断されそうなもの。
でも海外のプロジェクトリーダーは、こう言った。
「返さなくていい負債は返さない方がいい。
ビジネスが求めてないものを綺麗にするのは、ただの趣味だよ。」
この言葉は結構衝撃でした。
でも確かにそのとおりで、負債を返すかどうかって
「技術的に正しいか」ではなく「投資として回収できるか」で判断すべきなんですよね。
- 未来に価値を生む負債
- 実害が出るまで放置してもいい負債
- 今すぐ返さないと事業が止まる負債
負債には階層がある。
全部を返す必要なんてない。
これはまさに “技術ではなく、ビジネスを見て判断する” という海外エンジニアの価値観そのもの。
●Purposeful Debt は「2つの未来」を作る技術
技術的負債って、実は未来を作るツールなんです。
これまでの経験から、負債を残すことには2つの効果があります。
①「未来のために選択肢を残す」
負債を残すことで、後で “より良い選択肢” を選べます。
たとえば WPF の古いコードを無理に今アーキテクチャ替えするより、
.NET 9 や MAUI、Blazor がもっと安定したタイミングで移行した方がトータルで得、
というケースはたくさんあります。
負債は「保留」することで価値を生む。
②「未来の自分に助け舟を出す」
負債を Purposefully（意図的に）残すと、
未来の自分がリファクタリングしやすいように伏線を張っておけます。
- 拡張ポイントを残す
- 依存関係を整理しておく
- テストを書いておく
- “あとで抜き替えられる構造” を作っておく
これ全部、未来の自分が「ありがとう……！」って言うやつです（笑）
●Rewrite か Purposeful Debt か――正解はその人の“哲学”にある
結局のところ、RewriteとDebt、どっちが正しいかなんて存在しません。
大事なのは、あなたのキャリアの方向性。
Rewrite を選ぶというのは、
・責任を持って巨大なものを抱えに行く覚悟が必要
・長期の孤独な戦いに耐える必要がある
Purposeful Debt を選ぶというのは、
・状況を俯瞰して最適解を選べる柔軟性
・短期の成果と長期の戦略を同時に扱う力
ここから先は技術の話じゃなくて
自分がどんなエンジニアになりたいか の話になります。
英語が苦手でも、WPF の古いコードに疲れていても、
海外で働くという環境にプレッシャーを感じていても、
選べるんです。
あなたには、人生のハンドルを握る力がある。
Rewrite の未来も良い。
Debt の未来も良い。
大事なのは、
「何を選んで、どう説明し、どう動くか」 それだけです。
●最後に：Purposeful Debt は “技術” ではなく “生き方” だ
海外で働くようになって気づいたのは、
目的を持って負債を残すという判断は、
人生そのものにも応用できる ということ。
- 完璧じゃなくても進む
- 今できる最善を選ぶ
- 後で直せるように逃げ道を作っておく
- 自分の未来を信じる
- 大きな決断は、小さな改善の先に訪れる
何かに通じませんか？
そう、言語学習やキャリア、人生の戦略選択とまったく同じなんです。
Rewrite を狙わなくていい。
人生も、キャリアも、コードベースも、
「Purposeful Debt」的に積み重ねる方がずっと強い。
あなたが今日選んだ小さな負債が、
半年後にはあなたのキャリアの “武器” になるかもしれません。
完璧じゃなくていい。
でも、目的は必要。
目的のある負債は、あなたを必ず強くする。
コメント