技術的負債とは｜リファクタリング案件の合意形成と単価への影響

技術的負債とは｜「悪いコード」ではなく変更コストの前借り

結論として、技術的負債は将来の変更コストを前借りしている状態です。借りること自体は悪ではありません。返済計画がないまま利息だけが膨らむ状況が問題になります。

この比喩を最初に使ったのはWard Cunninghamで、整理し直したのがMartin Fowlerです。Fowlerは「Is High Quality Software Worth the Cost?」で、内部品質への投資は数週間単位で回収が始まりうると論じています。ただしこれは特定の論考であり、回収時期は対象範囲や変更頻度に左右されます。それでも、ここが発注側との対話で効きます。品質を「長期的にはいつか効く話」ではなく、数週間から数か月のスパンで見積もりに跳ね返る話として扱えるからです。

四象限で分けると会話が噛み合う

Fowlerの「技術的負債の四象限」は、負債を「無謀か慎重か」×「意図的か無自覚か」で分けます。

外部人材にとって重要なのは、どの象限かを口に出さないことです。「無謀な負債ですね」は既存メンバーへの人格評価に聞こえます。分類は自分の頭の整理に使い、会話では現在の変更コストだけを扱います。

リファクタリングとリライトは別物として扱う

リファクタリングは外部から見た振る舞いを変えずに内部構造を改善する作業です。作り直し（リライト）や基盤移行とは、リスクもコストも合意の取り方も違います。ここを混ぜて提案すると、発注側は「大掛かりな話」と受け取り、判断が止まります。

提案時は「今回は振る舞いを変えません。テストが通ることで担保します」と明示するだけで、通過率が変わります。基盤そのものを載せ替える話に発展しそうなら、それは別案件として切り出し、モダナイゼーションの文脈で議論します。

ミニFAQ：Q. 負債という言葉を発注側に使ってよい？

A. 相手がエンジニア出身なら問題ありません。非エンジニアのPMや事業責任者には「改修時間が延びている箇所」と言い換えたほうが伝わります。負債という語は責任追及の文脈に読まれることがあります。

フリーランスが技術的負債に着手しづらい3つの構造

結論として、外部人材が改善に踏み出せない理由は技術力ではなく契約・期間・可視性の3つに集約されます。それぞれ打ち手が違うため、自分がどれで詰まっているかを先に見極めます。

準委任の指示範囲から外れる

準委任契約は、善管注意義務をもって役務を提供する形の契約です。何をどこまで行うかは、契約上の業務範囲と現場での指示・合意に基づくのが一般的で、裁量の広さは案件ごとに差があります。頼まれていないリファクタリングを独断で進めると、成果物の期待値がずれ、稼働時間の説明もつきにくくなります。実際にどこまで裁量が認められるかは個別契約の記載によるため、業務内容欄の確認が出発点になります。契約形態ごとの責任範囲は「準委任契約と請負契約の違い｜フリーランスエンジニアが知るべきリスクと注意点」で整理しています。

打ち手はシンプルで、改善をタスクとして起票し、承認を得てから着手することです。黙ってやると評価されないどころか、レビュー時に「余計な差分」として扱われます。

参画期間が短く、回収前に契約が終わる

3か月更新の案件では、改善の効果が出る前に契約期間が切れることがあります。自分が去った後にメリットが残る施策は、提案しても優先度が上がりにくいのが実情です。

短期参画なら、対象を自分が今まさに触っている範囲に絞ります。「このチケットの実装にあたり、対象クラスの分割を含めたい。追加は2人日です」という形なら、期間の長さは論点になりません。

発注側に劣化が見えていない

コードの複雑度は発注側の画面には映りません。見えているのは「最近リリースが遅い」「同じ機能の改修に前回の倍かかった」という結果だけです。原因が負債にあると結びついていないケースは珍しくありません。

つまり提案の前段として、劣化を相手の観測範囲の言葉に翻訳する作業が必要になります。ここが次の章です。

負債を可視化する｜合意形成に使える指標の作り方

結論から言うと、可視化の目的は正確な計測ではなく優先順位に納得してもらうことです。精緻な指標より、判断に使える粗い指標のほうが機能します。

静的解析で測れるもの・測れないもの

SonarQubeなどの静的解析ツールは、循環的複雑度、重複行、カバレッジ、保守性の推定工数といった値を出します。指標の定義はSonarQube公式ドキュメントのメトリクス定義で確認できます。ツールが出す「修正に必要な推定時間」は、そのまま見積もりには使えません。あくまで箇所同士を比較するための相対値として扱うのが実務的な距離感です。

一方で、ドメイン知識が暗黙のまま埋まっている、命名が業務用語とずれている、といった負債は静的解析では検出されません。この領域は「ドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころ」の観点で、業務モデルとコードの距離として説明したほうが伝わります。

「変更頻度 × 複雑度」で対象を10%に絞る

実務でいちばん使えるのは、Gitの変更履歴と複雑度の掛け合わせです。手順は3つです。

1. 直近6〜12か月のコミット履歴から、ファイル別の変更回数を集計する

2. 静的解析で複雑度・行数の大きいファイルを抽出する

3. 両方の上位に入るファイルを、対象候補としてまずは上位10%前後を目安に絞る（適切な幅はコードベースの規模で変わります）

複雑だが誰も触らないコードは、放置しても損害が出ません。逆に毎週触るのに複雑なファイルは、変更のたびに時間と障害リスクを生みます。ここだけを対象にすると、提案の説得力が一気に上がります。

業務側の言葉に翻訳する

提案書に書くのは複雑度の数値ではありません。次の3つに変換します。

• 工数：「この画面の改修は直近3件の平均で5.2人日。同規模の他画面は2.1人日です」

• 障害：「直近半年の本番障害8件のうち5件が同じモジュール起点です」

• リードタイム：「該当領域のPRは平均レビュー3往復。他領域は1.2往復です」

数字の出どころは自分の手元にあります。チケット管理ツールの実績工数、障害チケットの起票履歴、PRのレビューコメント数。どれも既存データの集計で足ります。工数の根拠づくり全般は「工数見積もりのやり方｜手法4種・根拠の作り方とバッファ設計・失敗パターン」が参考になります。

ミニFAQ：Q. 静的解析ツールが導入されていない現場ではどうする？

A. 導入提案から入ると話が長くなります。ローカルで解析を一度だけ回し、結果を手元資料として使うほうが早いです。ツール導入自体を目的化すると、本題の改善が後回しになります。

合意形成の進め方｜誰に・いつ・どの言葉で通すか

結論として、合意形成は相手の評価指標に接続できたときだけ通ります。技術的な正しさは前提であって、通過理由にはなりません。

相手別に論点を変える

同じ改善でも、相手によって刺さる面が違います。一つの資料を全員に配るのではなく、話す相手の1行だけ差し替える運用が現実的です。

提案は「現状・影響・選択肢・費用・判断依頼」の5点で出す

A4一枚、説明15分に収めます。構成は固定でかまいません。

1. 現状：対象範囲と観測値（変更回数・工数・障害件数）

2. 影響：このまま進んだ場合に何がどれだけ遅くなるか

3. 選択肢：やらない／部分的にやる／まとめてやる、の3案を並べる

4. 費用：それぞれの追加工数と、実施しない場合の想定超過

5. 判断依頼：決めてほしいことを1つだけ書く

「やらない」を選択肢に含めるのが要点です。選択肢を3つ出すと、相手の仕事は判断になります。1案だけ持っていくと、相手の仕事は承認か拒否になり、拒否のほうが安全に見えます。

タイミングは障害直後と見積もり提示時

提案が通りやすいのは2つの瞬間です。ひとつは本番障害の振り返り直後。原因と負債が結びついている状態なら、対策として自然に議論に乗ります。もうひとつは見積もりを提示するときです。「この機能追加は8人日。既存構造のままだと13人日で、先に3人日の整理を入れると合計11人日です」という形なら、改善は独立した提案ではなく見積もりの一部になります。

避けたいのは、参画直後の提案です。参画後2〜4週間は観察に充て、提案は稼働1か月目以降に回したほうが通りやすくなります。コードの経緯を知らないまま出した指摘は、既存メンバーの反発を招きます。参画直後の振る舞いについては「コードレビューの作法｜指摘の書き方・受け方と信頼される進め方」が具体的です。

ミニFAQ：Q. 提案が却下されたら、そのまま引き下がるべき？

A. 却下の記録だけ残しておきます。「◯月に提案、コスト理由で見送り」と書いておくと、同じ領域で障害が起きたときに「予見されていた」ことが示せます。再提案のタイミングはそこです。

稼働の組み込み方｜日常業務に混ぜる4パターン

結論として、専用のリファクタリング期間を取りに行くより、通常の開発稼働に混ぜるほうが承認コストが低いケースが多くなります。4つの型を状況で使い分けます。

5〜8名程度のスクラムチームで機能開発と並行して改善を進める場合、現場運用上の目安として、スプリントの10〜20%程度を改善枠に充てると回しやすいケースがあります。これは調査データに基づく標準値ではなく、現場での運用感として語られることの多い水準です。組織の成熟度や障害の発生状況で適切な比率は変わるため、固定の正解として扱わず、3スプリント（およそ6週間）ごとに見直すのが現実的です。

ボーイスカウト型は手軽ですが、差分が大きくなるとレビュー負荷を上げます。機能変更とリファクタリングは別コミット・別PRに分けるのが原則です。混ざったPRはレビュアーが振る舞いの変化を追えなくなり、結果として改善そのものへの心証が悪くなります。

テストがない領域に手を入れるときは、先に特性テスト（現在の振る舞いをそのまま固定するテスト）を置きます。生成AIを使った足場づくりは「AIテスト自動化の実務｜生成AIで単体・E2Eテストを作る手順と限界」で扱っています。

リファクタリング案件の実情｜単価への影響と探し方

まず短答です。リファクタリングを主目的とした単独の募集は、公開案件では多くありません。大半は開発案件や保守開発案件の業務内容欄に改善が含まれる形で出ています。

以下の数字は、2026年9月時点で、首都圏中心の主要フリーランスエージェント数社の公開案件ページを「リファクタリング」「改善」「技術的負債」「リプレイス」などの語で検索し、該当した数十件規模の募集を確認した範囲での目安です。非公開案件や個別打診は含みません。実務経験3年以上・週4〜5日稼働の準委任案件を想定しています。該当件数が限られる領域のため、統計的な相場ではなく公開募集上の目安として読んでください。

上のレンジは公開案件ベースの目安です。非公開で打診される上位ロールは個別条件で上振れすることがありますが、そちらは案件ごとの事情が強く、相場として一般化はできません。

100万円以上のレンジで募集される案件は、コードを直せる人ではなく、改善方針を決めて他のメンバーに展開できる人を想定しています。技術選定の判断経験、既存メンバーとの調整実績、移行計画を文書化した経験が問われます。近い役割の整理は「フリーランスのテックリード案件｜単価・必要経験・獲得ルート」にまとめています。

単価に効くのは改善そのものより「説明できること」

実績として残しやすいのは、コードの美しさではなく変化量です。契約更新や新規商談で示す材料としては、次の形が具体的です。

• 「対象モジュールの平均改修工数を5.2人日から2.8人日に短縮（10件の実績平均）」

• 「該当領域起点の本番障害を半年で5件から1件に低減」

• 「改善方針をドキュメント化し、既存メンバー3名に引き継いだ」

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」で整理しています。交渉の切り出し方は「フリーランスエンジニアの単価交渉のコツ｜タイミング・伝え方・根拠の作り方」が参考になります。

案件の探し方

エージェントの案件検索では、「リファクタリング」単体で絞ると件数が少なくなります。職種・言語条件を先に指定したうえで、業務内容のキーワードとして「改善」「リプレイス」「保守開発」「品質向上」を併用すると拾いやすくなります。フリコンの案件一覧でも、言語・環境から絞り込んだうえで業務内容を確認する流れが実務的です。

既存システムの保守を主軸にした案件の実情は「運用保守・オンコール案件のフリーランス実情｜単価相場・手当・契約」で扱っています。

ミニFAQ：Q. 面談で「技術的負債を直したい」と言うのは印象が悪い？

A. 現場の課題認識として聞かれる場面では有効です。ただし「今のコードを直したい」だけで終えると、機能開発の戦力として見られにくくなります。「機能開発を進めながら、変更コストが高い箇所を並行して整理してきた」という順序で話すほうが評価されやすい傾向があります。

ケース別｜参画期間と体制による進め方の違い

3か月更新の短期参画

対象を自分の担当チケットの範囲に限定します。独立した改善提案は出さず、見積もり内包型に寄せます。効果測定も自分の担当範囲で完結する指標（該当機能の改修工数）を使います。期間内に完結しない施策は、着手せず引き継ぎ資料に候補として書き残すほうが親切です。

1年以上の長期・準委任

スプリント枠型が機能します。初回は3スプリント程度の試行として提案し、効果が出た時点で恒常化を打診する流れが通りやすくなります。契約更新の場で改善実績を材料にする方法は「フリーランス契約更新面談で話すこと｜継続を勝ち取る準備と実績の示し方」にまとめています。

一人目の外部エンジニア（体制が未整備）

レビュー体制もCIもない状態では、リファクタリングより先に壊れたことに気づける仕組みを作ります。優先順位は、特性テストの追加、CIでのテスト実行、静的解析の導入、の順です。この順序を飛ばして構造改善に入ると、振る舞いが変わったことを誰も検知できません。

体制づくりを含む役割は工数の性質が変わるため、契約前に業務範囲として明示しておきます。不具合発覚時の責任の考え方は「契約不適合責任｜業務委託・請負で不具合発覚時の対応と防衛策」を確認してください。

よくある失敗と対策

大きすぎるPRを出す

1,000行を超える差分は、レビュアーが振る舞いの変化を追えません。結果として「読めないので保留」になり、コンフリクトを重ねて腐ります。対策は分割です。適正サイズは言語や差分の性質、チームのレビュー文化で変わりますが、レビューしやすさの目安として1PRあたり400行以内を意識し、機能変更とリファクタリングを混ぜないようにします。レビューの原則はGoogleのエンジニアリング実践ガイドが参考になります。

「正しさ」で押し切ろうとする

設計原則を根拠に押すと、議論が技術的な正誤の勝負になります。相手が非エンジニアなら判断材料になりませんし、エンジニアなら反論可能な論点です。観測値とコストで話すと、勝ち負けではなく判断の問題になります。

効果測定を用意しないまま着手する

改善前の数値を取っていないと、終わった後に何も言えません。着手前に改修工数・障害件数・レビュー往復数の3つだけでも記録しておきます。1件でも前後比較があれば、次の提案の通過率が変わります。

既存メンバーの設計判断を否定する形で語る

「この設計は間違っている」は、当時の制約を知らない外部人材の発言としては危うい表現です。当時の判断は当時の条件下で妥当だったと前置きし、変わったのは条件のほうという構図で話すと摩擦が減ります。信頼構築の設計は「フリーランスエンジニアの信頼の作り方｜継続指名を生む長期設計」で扱っています。

実践チェックリスト｜提案前に埋める10項目

• 対象ファイルを変更頻度×複雑度の上位10%に絞ったか

• 改修工数・障害件数・レビュー往復数のいずれかで現状値を取ったか

• 提案先の関心（納期／持続性／コスト／障害）を特定したか

• 「やらない」を含む3案を用意したか

• 振る舞いを変えないことを明示したか

• 既存のテストで担保できるか、特性テストの追加が必要かを確認したか

• 追加工数を人日で提示したか

• 機能変更とリファクタリングを別PRに分ける方針を伝えたか

• 効果測定の指標と測定タイミング（3スプリント後など）を決めたか

• 判断してほしいことを1つに絞ったか

このチェックリストは、A4一枚の提案資料を作る際の項目表としてそのまま使えます。

まとめ

技術的負債への対処でフリーランスの評価を分けるのは、コードを直す腕前ではなく、直す対象を絞り、コストの言葉で合意を取り、変化量で示すまでの一連の進め方です。

• 技術的負債は変更コストの前借り。善悪ではなくコストで語る

• 対象は「変更頻度 × 複雑度」の上位10%程度に絞る

• 提案は現状・影響・選択肢・費用・判断依頼の5点、A4一枚・15分

• タイミングは障害直後と見積もり提示時。参画直後は避け、2〜4週間は観察に充てる

• 稼働は見積もり内包型とスプリント枠型（10〜20%程度）で日常に混ぜる

• 公開案件ではリファクタリング専業の募集は少なく、開発・保守開発案件の業務内容から拾う

• 単価に効くのは改修工数・障害件数の変化量として説明できること

• 案件探しは「リファクタリング」単体ではなく、「保守開発」「改善」「リプレイス」を含む開発案件から当たるのが現実的

次のステップとしては、いま参画している案件で直近6か月のコミット履歴を集計し、変更頻度の高いファイルを10件だけ書き出してみてください。そこに複雑度の情報を重ねれば、提案資料の「現状」欄はその日のうちに埋まります。

参照した主な資料は次のとおりです。

• 技術的負債の四象限（Martin Fowler）

• Is High Quality Software Worth the Cost?（Martin Fowler）

• SonarQube メトリクス定義

• Google Engineering Practices: Code Review

• IPA DX関連調査・資料

• IPA ソフトウェア開発分析データ集