リファクタリングとは｜発注者が見積・保守契約で確認する範囲と費用

ベンダーから届いた改修見積に「リファクタリング」という見慣れない項目が入っている、あるいは「新機能を追加する前に、まずリファクタリングが必要です」と説明されて想定より大幅に高い見積を受け取った——こうした状況で上司から「それは何で、なぜ払う必要があるのか」と問われ、即答できずに言葉の意味から調べ始めた方に向けた記事です。

厄介なのは、リファクタリングが「画面も機能も変わらない作業」だという点です。新しいボタンが増えるわけでも、バグが直るわけでもありません。それなのに、決して小さくない金額が見積に計上されます。しかも毎月の保守費用は、それとは別に払い続けることになります。「これは保守の範囲に入らないのか」「二重払いになっていないか」という疑問が残ったまま、決裁を進めるわけにもいきません。

さらに困るのは、「リファクタリングとは」と検索して出てくる記事の多くが、エンジニア向けの手法解説だということです。コードの重複をどう集約するか、命名をどう整えるかといった実装の作法は丁寧に書かれていても、発注者が知りたい「契約上の位置づけ」「金額の妥当性」「完了の確認方法」にはほとんど触れられていません。

発注者が押さえるべきポイントは、実は 4 つに整理できます。保守契約の範囲か追加発注かの線引き、「一式」でまとめられた見積の内訳、費用の組み立て方、そして成果が目に見えない作業の検収基準です。この 4 つを順に確認していけば、金額の根拠を自分の言葉で社内に説明できる状態になります。

本記事では、リファクタリングとは何かという定義から出発し、発注者の立場で見積書・保守契約書のどこを見て、ベンダーに何を質問すればよいかを整理します。実装手法のカタログではなく、契約と費用の判断材料に絞って解説します。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

リファクタリングとは｜動作を変えずにコードの構造を整える作業

リファクタリングとは、ソフトウェアの外から見た動作（振る舞い）を変えないまま、内部のソースコードの構造を整理し、読みやすく変更しやすい状態に改善する作業です。英語の refactoring は「因数分解をやり直す」という意味合いの語で、同じ結果を出す式をより扱いやすい形に書き換えるイメージに近いものです。

非エンジニアの方に向けた比喩としては、書類棚の整理が分かりやすいでしょう。棚の中にどんな書類が入っているかという「中身」は変わりません。しかし、ファイルがラベルなしで積み上がっている状態と、年度別・案件別にインデックスが付いた状態では、必要な書類を取り出すまでの時間が大きく変わります。リファクタリングはこの「取り出しやすさ」をコードに対して行う作業です。

ここで押さえておきたいのは、リファクタリングの費用は「新しい機能」に対して払うものではなく、「これから発生する改修作業を速く安全にするため」に払うものだという点です。この前提を理解しておくと、以降の契約・金額の議論が整理しやすくなります。

リファクタリングの目的と、機能追加・バグ修正との違い

ベンダーが行う作業を発注者の視点で分類すると、おおむね次の 3 つに分かれます。

リファクタリングの目的は、可読性（コードの読みやすさ）と保守性（変更のしやすさ）の改善です。目に見える変化がないため社内で説明しにくいのですが、逆に言えば「変化がないこと」自体が品質の証明でもあります。動作が変わってしまった場合、それはリファクタリングではなく仕様変更か不具合です。

発注者が最初に確認すべきなのは、提示された作業がこの 3 分類のどこに属するのかという点です。見積の項目名が「〇〇機能改修」となっていても、中身の大半がリファクタリングであるケースは珍しくありません。逆に「リファクタリング」の名目で機能変更が混ざっていることもあります。分類が曖昧なまま進めると、後述する検収の段階で「何をもって完了とするか」が決まらなくなります。

作り直し（リライト）・リプレースとの違い

リファクタリングと混同されやすいのが、リライトとリプレースです。この 3 つは費用規模もリスクの性質も大きく異なるため、ベンダーの提案がどれに該当するかは必ず確認してください。

• リファクタリング: 既存のコードを残したまま、段階的に内部構造を整える。動作は変えない。既存の挙動を壊すリスクは相対的に低く、途中で止めても価値が残る
• リライト（書き直し）: 同じ機能を新しいコードで作り直す。言語やフレームワークは維持する場合もある。完成までは価値が出ず、途中で止めると中途半端な状態が残る
• リプレース（置き換え）: システム自体を別の製品・別の基盤に置き換える。パッケージ製品やクラウドサービスへの移行を含む。最も費用規模が大きく、業務フローの変更も伴う

判断の分かれ目は、「現在のコードに手を入れ続ける価値があるか」という点です。改修のたびに影響範囲が読めず、開発元のサポートが終了した技術基盤に依存している場合は、段階的な改善では追いつかずリライトやリプレースの検討対象になります。一方で、技術基盤自体は現行で、特定の機能だけが複雑化しているのであれば、リファクタリングで十分に効果が出る可能性が高いといえます。

ベンダーが「作り直したほうが早い」と言う場合は、なぜ段階的な改善では対応できないのかを具体的に説明してもらいましょう。この説明が「古いから」「きれいに作りたいから」といった抽象的な理由に留まる場合は、判断を保留して構いません。

技術的負債とリファクタリングの関係

リファクタリングの話をすると、ほぼ必ず「技術的負債」という言葉が出てきます。技術的負債とは、納期を優先して一時的な実装で済ませた箇所、設計の見直しを後回しにした箇所などが積み重なり、将来の改修コストを押し上げている状態を指す比喩です。

借金と同じように、放置すると「利息」が付きます。この場合の利息とは、同じ規模の改修でも以前より工数がかかるようになる、改修のたびに想定外の不具合が出るようになる、といった形で現れるコスト増です。リファクタリングはこの負債に対する返済にあたります。

経済産業省が 2018 年に公表した「DX レポート」では、既存システムの複雑化・ブラックボックス化が進んだ結果、IT 予算の多くが既存システムの維持管理に充てられ、新しい取り組みに回せなくなる構造が指摘されました（経済産業省「DX レポート」（2018 年））。個社レベルでも同じことが起きます。改修見積が年々上がっている、同じような依頼なのに前回より工数が多い——こうした兆候が出ている場合、負債の利息を払い続けている状態である可能性があります。

技術的負債そのものの考え方や、どこまで許容してどこから返済すべきかという判断軸については、技術的負債の解説記事で詳しく整理しています。本記事では、負債の返済作業である「リファクタリング」を発注側がどう契約・費用の面で扱うかに話を進めます。

発注者がリファクタリングを求められる3つの場面

リファクタリングが話題にのぼるタイミングは、実務上ほぼ 3 パターンに集約されます。どのパターンに該当するかによって、「保守契約の範囲内と考えるべきか、追加発注として扱うべきか」の一次判断が変わります。まずは自社の状況がどれに当てはまるかを確認してください。

改修見積が高騰し「先にリファクタリングが必要」と説明された

最も多いのがこのパターンです。新機能の追加や既存機能の変更を依頼したところ、「現状のコードのままでは影響範囲が読めないため、先に該当部分を整理させてほしい」と提案され、当初想定していた予算を超える見積が提示されるケースです。

この場合に確認すべきは、リファクタリングが「今回の改修を実施するために技術的に必要な前提工程」なのか、「今後の改修も楽になる将来への投資」なのかという点です。前者であれば今回の改修費用の一部として扱うのが自然ですが、後者であれば今回の改修とは別の投資判断として切り出すべきです。実際には両方の性質を併せ持つことが多いため、「今回の改修に必要な最小限の整理」と「将来のための追加整理」を分けて見積を出してもらうと判断しやすくなります。

保守報告書・月次報告に「リファクタリング」の作業項目が入っていた

毎月の保守報告に「〇〇機能のリファクタリング」という作業が記載されていた場合、それが月額保守費用の内側で実施されたのか、別途請求されているのかを確認します。月額内で実施されているなら、保守契約の工数枠をリファクタリングに使ったということになります。

ここで考えるべきは、その工数配分が妥当かという点です。保守契約の工数枠が障害対応や問い合わせ対応に使われるべき場面で足りなくなっていないか、逆に余剰工数の有効活用としてリファクタリングに充てられているのか。後者であれば歓迎すべき運用ですが、発注側が内容を把握していない状態が続くと、何が改善されたのか分からないまま費用を払い続けることになります。

新機能追加や外部連携の前提工程として提案された

外部サービスとの API 連携、認証方式の変更、決済手段の追加など、既存システムの中核部分に手を入れる案件では、前提工程としてリファクタリングが提案されることがあります。既存の処理が特定の前提に強く依存していて、そのままでは新しい要素を差し込めないという状況です。

このパターンでは、リファクタリングを省略した場合に何が起きるのかを具体的に聞いてください。「将来的に困る」ではなく、「この連携を入れると既存の〇〇処理が二重に走る可能性があり、それを防ぐには△△部分の分離が必要」というレベルの説明が得られれば、前提工程として納得できます。説明が抽象的な場合は、リファクタリングなしで実装した場合の見積も併せて出してもらい、差額と追加リスクを比較すると判断材料になります。

ベンダーの提案を鵜呑みにせず・頭から否定もしないための初動

リファクタリングの提案に対する発注側の反応は、「技術的なことだから任せる」と丸投げするか、「機能が増えないなら不要」と全否定するかの両極に振れがちです。どちらも望ましい結果になりません。前者は金額の妥当性が検証されないまま進み、後者は負債が蓄積して将来の改修費用がさらに上がります。

最初に聞くべきことは、次の 3 点に絞って構いません。

1. いつ必要なのか: 今回の改修に必須か、将来のための投資か。延期した場合に何が起きるか
2. どこが対象なのか: システム全体か、特定の機能・画面か。対象範囲を具体的に特定できるか
3. なぜ今なのか: なぜこれまでの保守の中で対応されなかったのか、なぜこのタイミングで必要になったのか

3 点目は相手を責める質問ではなく、負債が蓄積した経緯を共有するための質問です。「過去の改修で納期優先の判断を重ねた結果」という説明であれば、今後の改修でも同じ判断が必要になる場面が来ると予測できます。この認識を共有できれば、リファクタリングを単発の支出ではなく、継続的な運用設計の一部として位置づけられるようになります。

リファクタリングは保守契約の範囲に含まれるのか

ここが本記事の中核であり、多くの発注者が最も判断に迷う論点です。結論から言えば、一般的な保守契約では、リファクタリングは範囲外として扱われるケースが多いものの、契約の書き方次第で範囲内にもなり得ます。重要なのは「一般論としてどちらか」ではなく、「自社の契約書ではどう定義されているか」を確認することです。

保守契約の一般的な範囲

まず、システム保守契約が通常カバーする作業を整理します。契約書の表現は会社ごとに異なりますが、おおむね次の範囲です。

費用の目安としては、年間保守費用を初期開発費の 5〜15% 程度とする整理がよく使われます。ただしこれは統計データではなく、業界で経験的に語られてきた慣行的な目安とされている数値です（システム保守費用の相場と内訳）。利用者数、稼働時間や対応スピードの要件、保守の範囲によって実際の費用は大きく変わるため、あくまで検討の出発点として扱ってください。

もう一つ知っておきたいのが、初期構築と運用保守を別契約にするのが業界の商習慣だという点です。初期構築時点では保守対象の範囲が確定していないため、正確な保守費用を算出できないという事情があります（見積書に運用保守費が入っていない発注案件の落とし穴）。つまり保守契約は、開発契約の延長ではなく独立した契約として、範囲が個別に定義されているものです。

リファクタリングが保守の範囲外になりやすい理由

では、なぜリファクタリングが保守の範囲から外れやすいのでしょうか。ベンダー側の都合というより、作業の性質に由来する構造的な理由が 3 つあります。

1. 完了条件を定義しにくい

障害対応であれば「システムが復旧したら完了」という明確な終点があります。リファクタリングには、この終点がありません。「どこまで整理すれば完了か」は程度の問題であり、やり始めれば際限なく続けられます。完了条件を定義できない作業を定額の月額契約に含めると、ベンダー側は「どこまでやれば義務を果たしたことになるか」が分からず、発注側は「十分にやってもらえたのか」が分からない状態になります。

2. 工数が読みにくい

リファクタリングの工数は、着手して中を調べるまで正確に見積れないことが多い作業です。表面的には同じ規模の機能でも、内部の依存関係の複雑さによって必要な工数が何倍も変わります。コードの重複を整理する作業ひとつを取っても、どれだけの箇所が関連しているかは調査するまで確定しません。見積の不確実性が大きい作業を定額枠に入れると、月額の中で工数が逼迫したときに障害対応が後回しになるリスクが生じます。

3. 「軽微な修正」の定義に収まらない

保守契約の多くは「軽微な修正」という表現で対応範囲を限定しています。リファクタリングは 1 件あたりの作業量が大きく、複数の機能に影響が及ぶため、通常この定義には収まりません。ここを曖昧にしたまま依頼すると、「軽微か否か」の解釈でベンダーと衝突することになります。

契約書で確認すべき条項と、ベンダーへの質問の仕方

自社の状況を判断するには、保守契約書の次の 4 点を確認してください。契約書の見出しは会社ごとに異なるため、該当する内容が書かれている箇所を探す形で読み進めます。

1. 業務範囲・対象業務の条項: 保守として実施する作業が列挙されている箇所。「軽微な修正」「軽微な改修」といった表現がある場合、その定義（工数の上限、対象の限定）が併記されているか
2. 範囲外作業の取り扱い: 範囲外の作業が発生した場合に別途見積・個別契約とする旨の条項があるか。この条項があれば、リファクタリングは原則として追加発注になります
3. 工数枠の有無: 月間の対応工数に上限（例: 月 20 時間まで）が定められているか。上限がある場合、その枠内で何を優先するかの取り決めがあるか
4. 成果物・報告の取り決め: 月次報告として何を提出してもらうか。作業内容の記載レベルが定義されているか

確認後、ベンダーに質問する際は「保守に含まれるべきではないですか」という詰め方ではなく、分類を確認する聞き方が建設的です。たとえば次のような形です。

「今回ご提案いただいたリファクタリングは、保守契約の業務範囲のどの項目に該当する想定でしょうか。範囲外にあたる場合は、別途のお見積としていただく前提で認識を合わせたいと考えています」

この質問は、相手に分類の根拠を説明させると同時に、こちらが契約書を読んでいることを伝える効果があります。保守契約そのものの類型や、請負・準委任といった契約形態の違いについては、保守契約の種類の記事で整理しています。

保守の範囲内に入れるべきケースと、追加発注にすべきケース

実務的な切り分けの目安を整理します。これは絶対的な基準ではなく、交渉の出発点として使うものです。

保守の範囲内で扱うことが妥当なケース

• 障害対応の過程で、再発防止のために必要になった局所的な修正
• セキュリティ更新やライブラリのバージョン更新に伴って必然的に発生するコードの修正
• 月間の工数枠に余剰があり、その活用先として発注側が内容を了承した上で実施される小規模な整理

追加発注として切り出すことが妥当なケース

• 複数の機能・画面にまたがる構造的な改善
• 特定の改修案件を実施するための前提工程
• テストの整備（自動テストの新規作成など）を伴う作業
• 工数が月間の保守枠を超える規模の作業

重要なのは、どちらに分類するかを着手前に文書で合意しておくことです。作業後に「これは保守の範囲でしたよね」と交渉するのは、双方にとって不毛な時間になります。

リファクタリングの見積で確認すべき作業範囲

追加発注として進めることになった場合、次の論点は見積の妥当性です。ここでつまずく最大の原因は、見積書に「リファクタリング作業 一式」と書かれていて中身が見えないことです。総額の妥当性を判断するのは困難ですが、内訳の妥当性なら発注者でも検証できます。

「一式」見積を4工程に分解する

リファクタリングの作業は、おおむね次の 4 工程に分解できます。見積がこの粒度で提示されていない場合は、分解して出し直してもらうよう依頼してください。

ここで多くの発注者が意外に感じるのが、2 の「テストの整備」が全体工数の相当部分を占めるケースがあるという点です。リファクタリングは「動作を変えない」ことが前提の作業ですから、動作が変わっていないことを確認する仕組みがなければ、安全に実施できません。既存システムに自動テストが整備されていない場合、まず安全網としてテストを作る工程が必要になります。

この構造を理解していないと、「コードを整理するだけなのに、なぜこんなに工数がかかるのか」という疑問が残ります。逆に、テスト整備の工数がほとんど計上されていない見積は、「動作が変わっていないことをどう確認するのか」を確認すべき対象です。手動での確認に依存する前提であれば、検証工程の工数とリスクを確認してください。

対象範囲の指定方法

リファクタリングは「システム全体」を対象にすると、費用も期間も発注者の想定を大きく超えます。そして全体を均等に改善することは、投資効率の面でも合理的ではありません。

優先すべきは、今後も改修が発生する見込みが高い部分です。判断材料としては次のような観点が使えます。

• 直近 1〜2 年で改修依頼が集中している機能
• 事業計画上、今後の機能追加が予定されている領域
• 障害や問い合わせが繰り返し発生している箇所
• 改修見積が他の機能に比べて明らかに高く出る箇所

反対に、何年も変更されておらず今後も変更予定がない機能は、構造が複雑でも改善の優先度は低くなります。改修が発生しない箇所の負債には、利息が付かないためです。

対象範囲は「機能単位」または「画面単位」で合意するのが実務的です。発注者が理解できる単位で範囲を定義しておけば、後から「どこまでやったのか」を確認できます。ベンダーがファイル単位・モジュール単位で提示してきた場合は、それが業務上どの機能に対応するのかを併記してもらうとよいでしょう。

手法名が並ぶ見積の読み方

見積の内訳に、聞き慣れない作業名が並ぶことがあります。発注者が見積項目を読み解くために必要な範囲で、代表的なものを整理します。実装の詳細を理解する必要はありません。

これらはいずれも「変更しやすさ」を上げるための作業であり、個別の手法の優劣を発注者が判断する必要はありません。確認すべきは、それぞれの作業がどの機能・どの範囲に対して行われるのかという点です。手法名だけが並び、対象範囲が書かれていない見積は、範囲が膨らむリスクを抱えています。

範囲が膨らむのを防ぐ取り決め

リファクタリングで最も起こりやすいトラブルが、着手後の範囲拡大です。コードを開けてみたら想定以上に複雑だった、関連箇所にも手を入れないと整理できなかった——といった理由で、工数が見積を超えていくパターンです。これは必ずしもベンダーの見積が甘かったわけではなく、この作業に本質的に伴う不確実性です。

不確実性を前提に、次の 3 点を発注前に取り決めておくことで、追加請求を巡る紛争を避けられます。

1. 上限工数の設定: 見積工数を超える場合は作業を止めて相談する、という取り決め。超過分を自動的に請求できない形にしておく
2. 中間報告のタイミング: 全工程の 3 分の 1 程度を終えた時点で、進捗と残作業の見通しを報告してもらう。ここで範囲の見直しができる状態にしておく
3. 範囲変更時の合意手順: 範囲を広げる場合は、追加工数・追加費用・スケジュール影響を書面で提示し、発注側の承認を得てから着手する

特に有効なのが、調査工程を先に小さく切り出す方法です。現状調査と影響範囲の特定だけを数日分の工数で発注し、その結果を踏まえて本体の見積を作り直してもらう形にすれば、不確実性の高い段階で大きな金額をコミットする必要がなくなります。

見積書全般の読み方や、項目の粒度・前提条件の確認観点については、システム開発の見積の記事も参考にしてください。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

リファクタリングの費用の目安と考え方

「リファクタリングの相場はいくらか」という問いには、残念ながら一般的な金額を示せません。作業量が対象システムの状態に完全に依存するためです。同じ「1 機能のリファクタリング」でも、内部の複雑さやテストの整備状況によって工数は何倍も変わります。相場を提示している情報があっても、自社のケースに当てはまる保証はありません。

その代わりに、自社の案件で概算を立てる手順と、保守費用との切り分け方、社内説明に使える指標を整理します。

定価相場が示しにくい理由と、工数×単価で概算を立てる手順

リファクタリングの費用は、基本的に「工数（人日・人月）× 単価」で構成されます。発注者が概算を立てる手順は次のとおりです。

1. 自社案件の単価を把握する: 過去の改修見積から、ベンダーの人日単価または人月単価を確認します。見積書に単価が明記されていない場合は、提示を依頼してください
2. 対象範囲を機能単位で絞る: 前述の優先度基準で、今回対象とする機能を 1〜3 個程度に限定します
3. 4 工程それぞれの工数を出してもらう: 調査・テスト整備・構造改善・検証の工程別に工数を提示してもらいます
4. テスト整備の比率を確認する: テスト整備の工数が全体に対してどの程度かを確認します。既存テストがない場合、この工程が大きくなるのは自然です
5. 調査工程を先行発注して精度を上げる: 不確実性が大きい場合は、調査のみを先に発注し、結果を踏まえて残りの見積を取り直します

この手順で出てくる金額は「相場との比較」では検証できませんが、「工程ごとの工数が納得できるか」という形で検証できます。社内決裁においても、総額だけを提示するより工程別の内訳を示したほうが説明が通りやすくなります。

保守費用との関係と二重払いの回避

毎月の保守費用を払っている状況でリファクタリングの追加費用が発生すると、「二重払いではないか」という疑問が生じます。この疑問を解消するには、月額に何が含まれ、何が別枠かを明示的に整理するのが確実です。

前述のとおり、年間保守費用を初期開発費の 5〜15% 程度とする目安は統計ではなく経験的な慣行であり、対応時間帯や SLA の水準によって上下します。月額の水準については、開発費の規模別に整理した目安も公開されています。開発費 100〜300 万円規模のアプリケーションで月額 2〜4 万円程度、300〜800 万円規模で月額 5〜10 万円程度、1,000 万円以上の規模で月額 15 万円以上（場合により 50 万円を超えることもある）という区分です（アプリ保守の費用相場）。自社の月額保守費がこのレンジのどこに位置するかを確認すると、保守として何をどこまで依頼できる水準なのか、見当がつきやすくなります。

整理の進め方としては、次の表のような形で作業種別ごとの帰属先を書き出し、ベンダーと認識を合わせておくとよいでしょう。

この表を作る作業自体に価値があります。多くの場合、作業種別ごとの帰属先は契約書に書かれているものの、運用の中で曖昧になっていきます。改めて書き出すと、「これは今までどちらで処理していたのか」という確認事項が出てくるはずです。それが二重払いや、逆にベンダー側の持ち出しを発見する手がかりになります。

費用対効果を社内に説明する指標

リファクタリングのメリットを社内に説明する際、「コードがきれいになる」「保守性が上がる」という説明では決裁は通りません。発注者が使うべき言葉は、将来の支出の抑制です。

説明に使える指標としては、次のようなものが挙げられます。いずれも自社の過去データから算出できるものです。

このうち最も説得力を持ちやすいのが、改修見積の推移です。たとえば同規模の改修が 2 年前は 50 万円だったのに今回は 90 万円になっている——これは説明の形を示すための仮の例ですが、こうした差分を自社の実データとして示せれば、「このまま放置すると次回はさらに上がる」という予測が成立します。リファクタリングの費用は、この上昇分を抑えるための支出として位置づけられます。

なお、これらの指標は「リファクタリング後にこうなる」という予測値を約束させるものではありません。改善の方向性と測定方法をベンダーと合意し、実施後に推移を追う形にしてください。将来値を数字で確約させようとすると、達成可能な範囲の控えめな約束しか得られなくなります。

一度に大きく投じない段階発注という選択肢

リファクタリングの費用は、一度に大きな金額を投じる必要がありません。むしろ段階的に進めたほうが、投資判断としても品質管理の面でも合理的です。

実務的な進め方としては、次のような選択肢があります。

• 調査フェーズの先行発注: 数日から 1〜2 週間程度の調査だけを先に発注し、現状と改善余地を把握してから本体の規模を決める
• 機能単位の分割発注: 対象機能を 1 つずつ発注し、1 件目の結果（工数の実績、効果の実感）を踏まえて 2 件目以降を判断する
• 改修案件への相乗り: 新しい改修案件が発生したときに、その対象箇所のリファクタリングを併せて実施する。改修のために必要な調査・テストと重複するため、単独実施より効率がよい

段階発注には、社内の決裁ハードルを下げられるという実務的な利点もあります。数百万円の投資判断を一度に通すより、まず調査フェーズの数十万円を通し、結果を根拠に次の決裁を取るほうが現実的です。

成果をどう確認するか｜リファクタリングの検収基準のつくり方

リファクタリングで発注者が最も不安を感じるのが、この検収の段階です。画面も機能も変わらないため、「本当に実施されたのか」「払った金額に見合う作業だったのか」を確認する手がかりがありません。さらに「既存の機能が壊れていないか」という心配も残ります。

検収基準は、次の 3 階層で設計すると整理しやすくなります。

動作が変わらないことをどう確認するか

リファクタリングの第一の要件は「動作が変わっていないこと」です。したがって検収の中心は、既存機能が従来どおり動くことの確認になります。これを回帰テストと呼びます。

発注前に決めておくべきことは次の 2 点です。

1. 自動テストの実行結果を提出してもらう範囲: 整備した自動テストがすべて正常に通過したことを、実行結果として提出してもらいます。テスト件数と結果（成功・失敗）の一覧が基本形です
2. 発注側が手動で確認する範囲: 自動テストで網羅できない部分、特に業務上クリティカルな操作フローについて、発注側の担当者が実際に操作して確認する範囲を決めます

2 点目は、発注側の工数が発生する点に注意が必要です。「対象機能の主要な操作フロー 5 本を検証環境で確認する」といった形で、具体的な作業量が見える形に落としておくと、受入時に慌てずに済みます。確認作業を担当する人（業務を一番よく知っている担当者）のスケジュールも、発注時点で押さえておきたいところです。

改善したことを示す指標の合意

動作が変わっていないことの確認だけでは、「何も変わっていない」ことしか証明できません。改善されたことを示す材料も必要です。

ここで使える指標は、ベンダー側が計測ツールで出力できるものが中心になります。発注者が数値の絶対的な良し悪しを判断する必要はありません。着手前と着手後の変化で見ます。

これらの数値は、ベンダーが使用している静的解析ツールから出力できます。重要なのは、着手前の値を測ってから作業を始めてもらうことです。着手後にしか測定していなければ、変化を示せません。発注時に「着手前の測定値を提出してください」と依頼しておけば済む話ですが、言わなければ測られないことが多い項目です。

なお、数値の改善幅を契約上の達成義務とするのは慎重に扱ってください。数値を目標にすると、数値が上がりやすい箇所だけを選んで作業する動機が生まれます。「測定して報告する」ことを義務とし、数値は議論の材料として扱うのが現実的です。

受け取るべき報告成果物の一覧

リファクタリングは納品物が目に見えにくい作業だからこそ、報告書類の取り決めが重要になります。最低限、次の 4 点を受領する前提で発注してください。

1. 対象範囲の一覧: 実際に手を入れた機能・画面・ファイルの一覧。発注時に合意した範囲と一致しているかを照合します
2. 変更内容の概要: どのような考え方で構造を整えたか、主要な変更の説明。実装の詳細ではなく、発注側が読んで理解できるレベルの説明を依頼します
3. テスト結果: 自動テストの実行結果と、確認した操作フローの一覧
4. 残課題の一覧: 今回対応しなかった箇所と、その理由・優先度。次回の投資判断の材料になります

4 点目の残課題一覧は特に価値があります。リファクタリングは一度で完結しないため、「次に何をすべきか」が文書化されていれば、次年度の予算計画に組み込めます。この一覧がないと、毎回ゼロから調査することになります。

検収基準は発注前に決める

ここまで挙げた検収基準は、すべて発注前に合意しておく必要があります。着手後に決めようとすると、必ず揉めます。

理由は単純です。着手後に「改善の度合いを数値で示してほしい」と依頼しても、着手前の測定値がなければ比較ができません。「主要な操作フローを確認したい」と後から言っても、検証環境が用意されていなければ確認できません。「残課題を一覧化してほしい」と完了後に頼んでも、作業中に気づいた点が記録されていなければ、思い出しながら書くことになります。

逆に言えば、検収基準を発注前に決める作業そのものが、スコープと金額の妥当性を検証する手段になります。「何をもって完了とするか」を具体化しようとすると、対象範囲の曖昧さや、見積に含まれていない工程が浮かび上がってきます。検収基準の議論は、見積の精度を上げる作業でもあるのです。

リファクタリングを依頼するときの契約形態と進め方

範囲・費用・検収基準が整理できたら、最後に実行フェーズの進め方を決めます。ここでは契約形態の選択と、どのベンダーに依頼するかの判断軸を整理します。

請負と準委任の使い分け

システム開発の委託契約は、大きく請負契約と準委任契約に分かれます。リファクタリングの場合、どちらが適しているかは「完了条件を定義できるか」で判断します。

• 請負契約: 成果物の完成を約束する契約。対象範囲と完了条件を明確に定義できる場合に適する。発注側は完成物に対して対価を払う
• 準委任契約: 作業の遂行を約束する契約。作業内容が探索的で、着手前に完了条件を固めきれない場合に適する。発注側は作業時間に対して対価を払う

IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」第二版では、実際の契約で準委任とするか請負とするかは、成果物の特定について当事者間に事前の共通理解が成立しているかによるとされています（情報システム・モデル取引・契約書 第二版）。リファクタリングはまさに「成果物の特定が難しい」作業であるため、この観点が判断の助けになります。

実務的な使い分けの目安としては、次のようになります。

• 対象機能が特定され、テスト整備と構造改善の内容が明確になっている → 請負契約で完了条件を定義する
• 現状調査から始めるフェーズ、または改善内容を進めながら決める段階 → 準委任契約で工数枠を決める

段階発注と組み合わせると、調査フェーズは準委任、改善フェーズは請負という形も取れます。契約形態を工程ごとに分けることで、不確実性が高い段階で完成責任を負わせない代わりに、実行段階では完了条件を明確にできます。

既存ベンダーに頼む場合と別ベンダーに頼む場合の判断軸

リファクタリングを現在の保守ベンダーに依頼するか、別のベンダーに依頼するかは、発注者が迷いやすい論点です。それぞれの性質を整理します。

既存ベンダーに依頼する場合

既存ベンダーはコードの経緯を把握しているため、調査工程の工数を抑えられます。また、改修案件に相乗りさせる形で進めやすく、保守契約との整合も取りやすいという利点があります。一方で、負債を蓄積させた当事者であるため、改善の優先順位が自社の都合に寄る可能性は意識しておく必要があります。

別ベンダーに依頼する場合

第三者の視点で現状を評価してもらえる点が利点です。既存ベンダーの提案が妥当かを検証する目的で、現状調査だけを別ベンダーに依頼するという使い方もあります。ただし、コードの理解に時間がかかるため調査工程の工数が増え、また保守ベンダーとの責任分界が複雑になります。リファクタリング後に障害が発生した場合、原因の切り分けで両者の主張が食い違うリスクも考慮が必要です。

判断の目安としては、既存ベンダーとの関係が良好で改修も継続的に発生している場合は既存ベンダーに依頼するのが効率的です。既存ベンダーの提案内容に疑問がある場合、または将来的にベンダー変更を検討している場合は、調査フェーズだけを別ベンダーに切り出して比較材料を得る方法が現実的です。

小さく始めて継続する進め方

リファクタリングを「一度やれば終わる作業」として扱うと、数年後に同じ問題が再発します。改修を続ける限り負債は再び蓄積するため、継続的に返済する仕組みを運用に組み込むのが本来の姿です。

運用に組み込む方法として、次のような選択肢があります。

• 改修案件に組み込む: 新しい改修を依頼する際に、対象箇所のリファクタリングを工程に含める。改修に必要な調査・テストと重複するため効率がよく、単独の投資判断を毎回起こす必要がない
• 保守契約に工数枠を設ける: 月間の保守工数のうち一定割合（例: 10〜20%）を改善作業に充てる取り決めを契約に入れる。範囲が小さいため完了条件の問題も生じにくい
• 年次の予算枠として確保する: 年間 IT 予算の中に改善用の枠を設け、優先度の高い箇所から順に消化する

いずれの方法でも、ベンダーとの間で「何を優先するか」を定期的に見直す場が必要です。残課題の一覧を年に 1〜2 回棚卸しし、事業計画上の改修予定と照らして優先順位を更新する——この運用が回れば、改修見積の上昇に歯止めをかけられます。

まとめ｜発注者が確認すべき4つのポイント

リファクタリングとは、動作を変えずにソースコードの構造を整え、将来の改修を速く安全にするための作業です。機能が増えるわけではないため社内説明が難しい支出ですが、確認すべきポイントを押さえれば、金額の根拠を自分の言葉で説明できるようになります。

本記事で整理した 4 点を、実務で使えるチェックリストとして再掲します。

1. 保守契約の範囲か、追加発注か

• 保守契約書の業務範囲・「軽微な修正」の定義・範囲外作業の取り扱い・工数枠の有無を確認する
• ベンダーには「業務範囲のどの項目に該当する想定か」という形で分類の根拠を質問する
• 分類は着手前に文書で合意する

2. 見積の内訳（4 工程）

• 「一式」ではなく、調査・テスト整備・構造改善・検証の工程別に工数を提示してもらう
• テスト整備の工数比率を確認する（既存テストがない場合は大きくなるのが自然）
• 対象範囲を機能単位・画面単位で合意する
• 上限工数・中間報告・範囲変更時の合意手順を発注前に取り決める

3. 費用の組み立て方

• 相場ではなく「工数 × 単価」で自社の概算を立てる
• 月額保守に含まれる作業と個別見積の作業を一覧で切り分け、二重払いを防ぐ
• 社内説明には改修リードタイム・改修見積の推移・障害件数など、将来の支出抑制を示す指標を使う
• 調査フェーズの先行発注や機能単位の分割発注で、段階的に投資判断する

4. 検収基準

• 回帰テストの実行結果と、発注側が手動確認する範囲を発注前に決める
• 改善を示す指標は、着手前の測定値を取ってから作業を始めてもらう
• 対象範囲の一覧・変更概要・テスト結果・残課題一覧の 4 点を報告成果物として受領する
• 検収基準の議論は、見積の精度を上げる作業でもある

リファクタリングは、改修を続ける限り再び必要になる継続的な取り組みです。単発の支出として毎回決裁を取るのではなく、改修案件への組み込みや保守契約の工数枠といった形で運用に組み込めると、負債の蓄積と改修費用の上昇に歯止めをかけられます。まずは目の前の見積と保守契約書を開き、上記 4 点を照らし合わせることから始めてみてください。

システム開発の発注・契約に関する判断材料を体系的に整理したい場合は、お役立ち資料 もご活用いただけます。発注者向けのテーマ別資料をダウンロードいただけます。

既存システムの改善範囲の切り分けや、提示された見積の妥当性について第三者の意見が必要な場合は、お問い合わせフォーム からご相談いただけます。現状の整理段階からご相談いただけます。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。