システム改修の発注・外注は、発注範囲と責任を明確にして進めます。機能追加、画面改善、法改正対応などが主な対象です。
全体の流れは、発注前の準備を起点に、契約形態、費用、発注先の選定へと進みます。外注先と見積もりを整理しておくと、費用と品質を管理しやすくなります。
▼全体ガイドの記事
・システム改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システム改修の発注・外注とは｜全体像とスコープの考え方
システム改修とは、既存システムを全面的に作り替えるのではなく、必要な範囲に絞って機能追加や仕様変更、不具合修正、性能改善などを行う取り組みを指します。改修は全面刷新に比べて対象が限られ、費用対効果を見極めやすい手法です。
ただし、範囲を誤ると影響が思わぬ所まで広がるため、切り分けが欠かせません。まず押さえたいのは、改修と刷新の違い、そして外注の前提になるスコープの考え方です。
改修・刷新・移行の違いとスコープの線引き
システムに手を加える行為は、改修・刷新・移行という連続したグラデーションの中で語られます。改修は既存の構造を活かして機能を追加・変更するもので、刷新は7Rに代表される全面的な近代化を指します。
7Rには、リホスト、リプラットフォーム、リファクタリングがあります。さらに、リアーキテクチャ、リビルド、リプレース、リタイアも含まれます。一方、移行はクラウドや新しい基盤へデータと環境を移すことが主軸です。
- 対象範囲：改修対象と移行データの範囲
- 検証手順：リハーサルと受入テストの流れ
このうち改修では、スコープの限定と費用対効果が最も大きな判断軸になります。投じる費用に対して業務効率化や売上貢献が見合うかを起点に、どこまで手を入れるかを決めます。
改修では、全機能を一度に直そうとせず、効果の大きい部分から段階的に手を付けることが、無駄な投資を避ける第一歩です。
線引きで大事なのは、「改修で済むのか、刷新が必要なのか」を冷静に見極めることです。たとえば、ソースコードがブラックボックス化し、少しの変更にも多大な工数がかかる状態であれば、部分改修を繰り返すより刷新のほうが結果的に安く済むこともあります。発注前にこの判断を外注先と共有しておくと、後の認識の食い違いを防げます。
外注での部分改修が増えている背景
経済産業省のDXレポートは「2025年の崖」を指摘しました。レガシーを放置したままだと、2025年以降に年間最大12兆円の損失が生じうるという問題です。
多くの企業は全面刷新の予算と人員を一度に確保できず、まずは喫緊の課題から部分改修で対応するという現実的な選択が広がっています。
- 現状把握：業務フローと既存機能の一覧づくり
- 要件整理：改修範囲と連携条件の線引き
背景には深刻なIT人材不足があります。IPAの調査では、2030年に最大で約79万人のIT人材が不足すると試算されており、社内エンジニアだけで改修需要をまかなうのは限界に達しつつあります。
だからこそ、必要な範囲を切り出して外部のベンダーに委託する発注スタイルが、現実的な解として選ばれているのです。
IPAは約4,000社を対象に調査し、799社が回答しました。CDOやCIOなどのCxOを置く企業ほど情報共有が円滑で、可視化と内製化が進む相関が見られます。外注を成功させるには、社内に改修の意思決定と要件整理を担う旗振り役を置くことが欠かせません。
発注前の準備｜現状の整理とRFPの作り方
発注の成否は、外注先を選ぶ前の準備段階でほぼ決まるといえます。改修内容が曖昧なまま見積もりを頼むと、ベンダーごとに前提の違う提案が返ってきて、比較もできなくなります。その準備の中心は、現状の整理と、依頼内容をまとめたRFP（提案依頼書）の作成です。
現状の整理と改修目的の明確化
最初に行うべきは、改修対象のシステムの現状を整理することです。現行の構成や使っている言語・フレームワーク、関連する周辺システムとの連携状況を一覧にしておきます。
ドキュメントが残っていない場合は、その旨を正直に伝えておくことが、後の見積もり精度を左右します。
- 費用内訳：人件費・開発・移行・運用の区分け
- 隠れコスト：教育・並行稼働・基盤費も含めた計上
次に、「なぜ改修するのか」という目的を言葉にします。たとえば、月次の集計に手作業が多く残業が常態化している、特定の操作でエラーが頻発する、法改正への対応が必要といった課題を、できるだけ定量的に書き表します。
改修によって削減できる工数や時間を数値で示せると、社内稟議でも投資対効果を説明しやすくなります。
このとき、本当にその機能が必要かを問い直す「勇気ある廃止」の視点も有効です。使われていない機能の改修をやめ、その予算を効果の大きい部分に集中させることで、限られた費用対効果を最大化できます。改修要望をすべて鵜呑みにせず、優先順位をつけることが、現状の整理における大切なゴールです。
RFP（提案依頼書）に盛り込むべき要素
RFPは、外注先に提案と見積もりを依頼するための文書です。まず、改修の背景と目的、対象範囲、実現したい機能や改善内容を書きます。さらに、現行システムの技術情報、希望する納期、想定予算の幅なども記載します。
部分改修であっても、影響を受ける周辺機能まで含めて記述しておくと、後から「それは見積もりに入っていない」という追加費用のトラブルを防げます。
- 業務理解：対象業務と連携知識の理解度
- 実績確認：移行経験と支援体制の比較
とくに重要なのが、スコープの内外を明確に切り分けることです。「この画面は改修するが、連携先のマスタは触らない」といった境界をRFPに明記しておくと、各社の見積もりが同じ前提で比べられます。境界の曖昧な依頼は、安く見えても後で膨らむ見積もりを誘発しがちです。
改修後の保守と運用を発注側と委託先のどちらが担うのか、ソースコードや設計書をどこまで納品物として受け取るのかも、発注側はこの段階で要求事項に入れておきます。
これらを後回しにすると、特定のベンダーしか手を出せないベンダーロックインの温床となります。そのため、発注前に要求として伝えておくことが大切です。
委託の進め方と契約形態の使い分け
外注を委託するときは、契約形態の選び方がリスク管理の要になります。準委任契約と請負契約の特性を理解し、フェーズごとに使い分けることで、不要なトラブルや費用の膨らみを抑えられます。あわせて、SLAや責任分界点、ベンダーロックインを避けるための契約上の工夫も押さえておきます。
準委任契約と請負契約の使い分け
準委任契約は、業務の遂行そのものに対して対価を支払う契約です。完成させる責任を負わないのが特徴で、改修内容がまだ固まっておらず、調査や要件整理を伴うアセスメントのフェーズに向いています。
柔軟に仕様を詰めながら進められる反面、稼働時間をもとに費用が積み上がるため、期間の管理が欠かせません。
- 契約切替：上流は準委任、開発は請負
- 責任分界：SLAと担当範囲の文書化
一方、請負契約は完成した納品物に対して対価を支払う契約です。ベンダーが完成責任と契約不適合責任を負い、改修内容と仕様が明確に固まった開発・実装フェーズに適しています。
仕様が確定していれば、費用が予算内に収まりやすく、品質の責任も明確になります。
実務では、調査と要件整理は準委任契約で進め、仕様が固まった後の開発は請負契約に切り替える、という二段構えが定石です。曖昧な段階で請負契約を結ぶと、仕様変更のたびに追加見積もりが必要になり、かえって割高になります。フェーズに応じて契約形態を使い分けることが、コストとリスクを同時に抑える鍵です。
SLA・責任分界点とベンダーロックイン回避
改修後の運用を見据えるなら、SLA（サービス品質保証）と責任分界点を契約に明記しておきます。障害発生時の一次対応の時間や復旧目標、稼働率の保証水準を定めることで、トラブル時の対応がスムーズになります。
どこまでが自社の管理範囲で、どこからがベンダーの責任なのかを線引きしておくと、無用な押し付け合いを防げます。
- 契約切替：上流と開発で異なる契約形態
- 責任分界：管理範囲の境目
とくに部分改修で見落とされがちなのが、ベンダーロックインのリスクです。改修を重ねるうちに、そのベンダーしか内部構造を把握できなくなり、保守も次の改修も同じ会社に頼らざるを得ない状態を指します。
発注側は、ロックインを避けるために、ソースコードの著作権の帰属、設計書や運用手順書の納品、運用権限の引き渡しを、契約条項に盛り込んでおきます。
特定の独自フレームワークやブラックボックス化した部品に依存させない設計を発注側が求めることも、ロックイン回避に有効です。
将来別のベンダーへ乗り換える可能性を残しておくこと自体が、価格交渉力や品質維持の担保になります。発注時点でこの観点を持てているかどうかが、長期的なコストに大きく影響します。
データ移行とFit to Standardの落とし穴
改修であってもデータ構造に手を入れる場合は、データ移行が思わぬ落とし穴になります。文字コードの差異や外字、既存データの不整合は、移行時に表面化しがちです。得意先ごとに複雑になったマスタ条件も、移行の段階で見えてきます。
移行では、本番切替の前に委託先と段取りを詰め、ダウンタイムを最小化しておくことが欠かせません。
- 対象範囲：改修対象と移行データの切り分け
- 検証手順：リハーサルと受入テストの順序
パッケージ製品を使う改修では、Fit to Standard（標準機能に業務を合わせる）の考え方が重要です。
現行業務の例外ルールをすべてカスタマイズで再現しようとすると、開発が肥大化し、費用も保守の負担も膨らみます。そこで、標準機能で吸収できる部分は業務の側を合わせるという判断が、費用対効果を守るうえで効いてきます。
現場から「前のシステムではできた」という反発が出ることもあります。こうした反発を抑えるには、改修の目的と効果を丁寧に説明するチェンジマネジメントが求められます。
自社の担当者が現場と外注先の橋渡し役を担えば、改修後の定着率は大きく変わります。
費用相場とコストの内訳｜隠れコストに注意
外注の費用は、改修の範囲と難易度によって大きく変わります。軽微な機能追加であれば数十万円規模に収まることもあれば、複数のシステムにまたがる改修では数百万円以上になることもあります。
全面刷新が500万円から2億円規模になることを踏まえると、スコープを絞った部分改修は、コストを抑える有効な手段になります。
人件費・工数と費用の内訳
システム改修の費用は、その大半がエンジニアの人件費（工数）で構成されます。一般的には、人月単価にかかる人月数を掛けて算出し、単価はエンジニアのスキルや役割によって変わります。
改修費用を見積もる際は、工程ごとに工数を分解して確かめるのが基本です。要件整理から設計、開発、テストを経て、移行とリリースまで、各工程にどれだけの工数がかかるかを見ていきます。
- 対象範囲：改修対象と移行データの確定
- 検証手順：リハーサルと受入テストの段取り
費用は、アセスメント、設計・開発、データ移行に分けて考えます。新旧システムの並行稼働による二重コストや、改修後の運用・保守費用も含めます。
部分改修では開発費用に目が行きがちですが、テストや移行にかかる工数を軽視すると、見積もりと実費が乖離する原因になります。
見積書を受け取ったら、工数の内訳が明示されているかを確認します。「一式」とだけ書かれた見積もりは、何にいくらかかっているのかが分からず、後の追加費用の温床になります。
工程ごとに工数と単価が分かれた見積もりを求めることが、適正価格を見抜く基本です。
初期費用以外のランニングコストと隠れコスト
外注費用を検討する際は、初期費用だけでなく、改修後に継続して発生するランニングコストまで見込んでおく必要があります。
保守費用、クラウドの利用料、改修で導入した新しいツールやミドルウェアのライセンス費用などは、毎月あるいは毎年積み上がっていきます。そのため、初期費用の安さだけで発注先を選ぶと、運用フェーズで割高になるケースは少なくありません。
- 業務理解：対象業務と連携知識の把握
- 実績確認：移行経験と支援体制の比較
とくに見落とされやすいのが隠れコストです。データクレンジングの工数や現場の教育・トレーニング費用、新旧システムの並行稼働による二重運用費がこれに当たります。これらは見積書に明示されにくく、後から発生して予算を圧迫しがちです。
経営層への稟議では、初期費用の比較だけでなく、運用コスト低減のシミュレーションで投資対効果を示すことが説得力につながります。たとえば、改修によって削減できる人件費や保守費を試算し、何年で投資を回収できるかを示すことで、部分改修であっても合理的な意思決定を引き出せます。
見積もりと発注先選定のポイント
発注先を選ぶ際は、価格だけで判断しないことが基本です。改修対象の業務をどれだけ理解しているかや過去の実績を見たうえで、プロジェクト管理体制や契約姿勢まで含めて総合的に評価します。
複数社比較と発注先の選び方
見積もりは、必ず複数社から同じRFPをもとに取ります。前提条件をそろえた相見積もりであれば、各社の価格水準だけでなく、提案内容の深さや課題のとらえ方の違いも見えてきます。極端に安い見積もりは、スコープの抜け漏れや、後からの追加請求を疑ってかかる必要があります。
- 業務理解：対象業務と連携知識への理解の深さ
- 実績確認：移行経験の有無と支援体制の厚み
選定で重視したいのは、自社の業務や既存システムへの理解度です。改修は既存資産の上に手を加える作業のため、現行システムを正しく読み解ける技術力と、業務の文脈を汲み取る理解力の両方が求められます。
提案の段階で的確な質問を投げかけてくるベンダーは、信頼に値する候補と言えます。
あわせて、コンサルティング、開発、運用まで一気通貫で対応できる体制があるかも、評価の対象になります。改修の上流から関わり、課題整理と実装を分断せず進められるパートナーであれば、要件のブレや手戻りを抑えられ、結果として費用対効果を高められます。
たとえば、株式会社riplaのように、社内DXの推進経験があり、ビジネス成果とシステム定着の両方を支援できる体制を整えている企業は、こうした要件に合う候補になりやすいと言えます。
注意すべきリスクと対策
発注後によく起きるトラブルの一つが、スコープの認識の食い違いによる追加費用です。RFPと見積もりで改修範囲を文書にし、変更が生じた場合の追加見積もりの取り決めを契約に含めておくと、想定外の請求を避けられます。口頭での合意は後のトラブルの種になるため、必ず書面に残しておきます。
- 契約切替：フェーズごとの契約の切り替え
- 責任分界：SLAと担当範囲の文書化
もう一つの大きなリスクが、改修を重ねるうちに進むベンダーロックインです。ソースコードや設計書の納品、運用権限の引き渡しを契約に盛り込み、いつでも別のベンダーに引き継げる状態を保っておきます。
これは将来の価格交渉力を守り、長期的なコストを抑える保険でもあります。
さらに、改修後の運用体制と内製化の方針も、発注時に見据えておきたいポイントです。IPAの調査でも、可視化と内製化の進み具合には相関が見られています。
社内に知見を蓄えながら進める姿勢が、IT人材不足の時代に改修を続けていくための鍵になります。
まとめ
システム改修の発注・外注は、スコープを限定して費用対効果を見極めることから始まります。全面刷新と部分改修の違いを理解し、効果の大きい範囲から段階的に手を付けていけば、限られた予算を無駄なく使えます。
「2025年の崖」やIPAが示す2030年のIT人材不足を背景に、必要な範囲を切り出して外部に委託する発注スタイルは、これからますます現実的な選択肢となります。
成功の鍵は、発注前の現状の整理とRFPです。そのうえで、準委任から請負へ契約を切り替え、ロックインを避ける条項も整えます。
費用は工数の内訳まで分解して確認し、データクレンジングや教育、二重運用といった隠れコストまで見込んでおくことで、見積もりと実費の乖離を防げます。
発注先は価格だけで決めず、業務理解や技術力に加えて、プロジェクト管理体制と契約姿勢を見て選びます。
運用コスト低減のシミュレーションで投資対効果を示し、内製化の視点も持ちながら進めることで、部分改修であっても確かな成果につながります。
ここで紹介した実務とPMの視点を、ぜひ自社の改修プロジェクトに生かしてください。
▼全体ガイドの記事
・システム改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。