システム改修の進め方｜依頼前に確認すること・期間と費用の考え方

システム改修とは、いま動いているシステムを活かしながら、不具合の修正や機能の追加、法改正への対応などを行うことです。

改修は「開発会社に要望を伝えれば進むもの」と思われがちですが、実際に期間と費用を大きく左右するのは、ソースコードや設計書がそろっているか、変更がどこまで影響するかといった、依頼する前の状態です。この記事では、改修で済むかの判断軸、依頼前に確認すること、進め方、期間と費用の考え方、依頼先の選び方を整理します。

⇒ 自社の担当者で作り、自分たちで改善し続けたい方へ。AI駆動セルフ開発ツール「S-MASE」の詳細を見る

システム改修とは

システム改修とは、稼働中のシステムの土台を残したまま、必要な部分に手を入れて直したり機能を足したりすることです。ゼロから作る新規開発とも、土台ごと作り直す刷新とも違い、「今あるものを使い続ける」ことが前提になります。

システム改修の意味

身近なたとえでいえば、住んでいる家のリフォームに近いものです。柱や基礎はそのままに、壊れた設備を直したり、部屋の使い方に合わせて間取りを一部変えたりします。建て替えとは違い、住みながら工事を進めるため、工事中も生活（業務）を止めない工夫が求められます。

対象になるのは、受発注や勤怠などの社内の業務システム、顧客が使う会員サイトや予約サイトなどのWebシステム、マッチングサービスのようなプラットフォームまでさまざまです。業務システムそのものの作り方は「業務アプリ開発とは」で解説しています。

保守・刷新・新規開発との違い

改修と混同しやすい言葉に、保守・刷新（リプレイス、更改）・新規開発があります。違いは、システムのどこまでを変えるかです。

保守は、障害対応や監視、軽微な設定変更などで、システムを今の状態のまま動かし続けることが目的です。改修はそこから一歩進んで、機能や画面に変更を加えます。刷新は、古くなった技術や構成を新しい土台に置き換えることで、更改やリプレイスとも呼ばれます。境目があいまいなのは保守と改修で、どこまでが保守契約の範囲かは契約書で確認する必要があります。

改修の主な種類

改修は、目的によって大きく5つに分けられます。不具合や障害を取り除く「不具合の修正」、税率や制度の変更に合わせる「法改正への対応」、業務の変化に合わせて機能を足す「機能の追加」、画面や操作を使いやすくする「UIの改善」、OSやミドルウェアの更新に合わせる「動作環境への対応」です。

どの種類にあたるかによって、テストの範囲や、後で触れる会計上の扱いが変わります。そのため、依頼の段階で「今回の改修はどれか」を言葉にしておくと、開発会社との認識のずれを減らせます。

システム改修が必要になるタイミング

改修のきっかけは、外から求められるものと、社内から生まれるものに分かれます。前者は期限が決まっていることが多く、後者は優先順位を自社で決める必要があります。

法改正・制度変更

税率や帳票の様式、個人情報の扱いなど、法律や制度が変わると、それに合わせてシステムを変える必要があります。施行日が決まっているため、逆算して計画を立てることになります。直前になると開発会社の手が埋まりやすいため、改正の内容が公表された段階で影響範囲を確かめておくと安心です。

不具合・性能の低下

エラーが出る、処理が遅い、データが合わないといった問題は、業務に直接影響するため優先度が高くなります。ただし、原因がプログラムではなくデータ量の増加やサーバーの設定にあることもあります。いきなり改修を依頼するより、まず原因の調査を依頼する方が、結果として費用を抑えられる場合があります。

業務の変化と機能の追加

組織や商品、取引先が変わると、システムの前提も変わります。紙やExcelでの回避策が増えてきたら、改修を検討するサインです。この場合は「何に困っているか」を業務の言葉で整理することが、改修の出発点になります。

OS・ミドルウェアのサポート終了

OSやデータベース、プログラミング言語の実行環境などには、提供元のサポート期間があります。サポートが終わると、セキュリティの更新が受けられなくなります。サポート終了への対応は、プログラムの小さな修正で済むこともあれば、土台の入れ替えが必要になることもあり、改修か刷新かの分かれ目になりやすい場面です。

改修で済むか、作り直すべきかの判断軸

変更が一部にとどまり、仕様とソースコードが手元にあるなら、まずは改修を検討するのが基本です。一方で、土台の技術が古くなっている場合や、直すたびに別の箇所が壊れる場合は、刷新も含めて比べた方がよいことがあります。

判断に迷う場合は、改修と刷新の両方で概算を出してもらい、今後数年の変更の頻度も含めて比べると判断しやすくなります。改修は1回あたりの費用を抑えられますが、変更のたびに費用がかかり続けます。刷新は初期の負担が大きい分、その後の変更がしやすくなることがあります。

パッケージ製品への乗り換えも選択肢の一つです。作り方ごとの違いは「パッケージ開発とスクラッチ開発との違い」をご覧ください。

改修を依頼する前に確認すること

改修の見積もりと期間を大きく左右するのは、システムの「中身がどこまでわかるか」です。情報処理推進機構（IPA）は、システムの作り直しで起きる問題の原因として、時間が経って不明瞭になった現行システムの仕様があいまいなまま開発に着手することを挙げています。改修でも同じで、依頼する前に、次の4点を社内で確かめておくことが、改修を早く正確に進める近道です。

確認すること	確かめる内容	わからない場合の対応
ソースコード	最新版はどこにあるか／自社が使える権利があるか	契約書と、元の開発会社への問い合わせで確認
設計書・仕様書	画面・データ・処理の資料があるか／最新か	現状の調査を改修の最初の工程に入れる
環境	本番以外に試せる環境があるか／サーバーの管理者は誰か	環境の準備を見積もりに含めてもらう
契約	保守契約で対応する範囲／改修を誰に頼めるか	契約書の「保守の範囲」「著作権」の条項を確認

ソースコードと権利の所在

改修するには、プログラムのもとになるソースコードが必要です。最新版が手元になく、元の開発会社だけが持っているという状況は珍しくありません。さらに、ソースコードの著作権が開発会社に残る契約になっていると、他社に改修を頼めない場合があります。

まずは開発時の契約書で、成果物の権利がどちらにあるかを確かめておきましょう。権利が開発会社にある場合でも、利用の許諾を得られることがあります。

設計書・仕様書がない場合の進め方

長く使われているシステムほど、設計書が古いまま更新されていなかったり、そもそも残っていなかったりします。その場合でも改修はできますが、ソースコードや画面の動きから現状を読み解く調査が必要になり、その分の期間と費用がかかります。

設計書がないこと自体より、ないことを伝えずに見積もりを取ることの方が、後のトラブルにつながりやすい点に注意が必要です。依頼の時点で資料の有無を正直に伝え、調査の工程を見積もりに含めてもらいましょう。

試せる環境と保守契約の範囲

本番のシステムを直接変えると、業務が止まるおそれがあります。本番と同じ構成で試せる「検証環境」があるかどうかで、テストの進めやすさが変わります。

保守契約を結んでいる場合は、どこまでが保守の範囲で、どこからが別料金の改修になるかも確認しておきます。「軽い修正だから保守の範囲だと思っていた」という食い違いは、費用の話でもめる原因になりやすいところです。

改修の目的と優先順位を整理する

「使いにくいので直したい」だけでは、開発会社はどこを直せばよいか判断できません。今の業務のどこで困っているか、改修後にどうなっていればよいかを、業務の言葉で書き出します。

要望が多い場合は、「期限があるもの」「業務が止まるもの」「あると便利なもの」に分けて優先順位を付けておくと、予算に合わせて範囲を調整しやすくなります。現状と理想を整理する方法は「As-Is/To-Beフレームワークによる要件定義」が参考になります。

システム改修の進め方

改修の進め方は新規開発と似ていますが、「今の動きを壊さない」ための現状把握とテストに、より多くの手間をかける点が違います。

①現状を把握する

最初に、改修の対象となる機能が今どのように動いているかを確かめます。設計書があれば内容が最新かを確認し、なければ画面の操作やソースコードから読み解きます。この工程を省くと、後の見積もりの精度が下がります。

②影響範囲を調べる

システムの機能は互いにつながっています。ある画面の項目を1つ増やすだけでも、データベースや帳票、他システムとの連携に影響が及ぶことがあります。どこまで影響するかを洗い出すことで、変更する箇所とテストする箇所が決まります。

③要件定義と見積もり

何を、どこまで、いつまでに変えるかを決め、開発会社から見積もりを受け取ります。見積もりでは、作業の内訳に現状調査とテストが含まれているかを確認しましょう。この2つが抜けている見積もりは、一見安くても後から追加費用が発生しやすくなります。

④設計・開発

既存の作りに合わせて設計し、プログラムを変更します。新しい書き方を取り入れたくなる場面もありますが、既存部分と作りがそろっていないと、次の改修がしにくくなります。どこまで既存に合わせるかは、開発会社と方針をそろえておくと安心です。

⑤テストで「変えていない部分」も確かめる

改修のテストでは、変えた機能が正しく動くかに加えて、変えていない機能が以前と同じように動くかも確かめます。これを回帰テスト（デグレード確認）と呼びます。改修後に「別の画面がおかしくなった」というトラブルの多くは、この確認の不足から起こります。

利用部門の担当者が、実際の業務の流れに沿って操作してみる受け入れテストも欠かせません。開発会社のテストでは見つけにくい、業務ならではの使い方の問題が見つかることがあります。

⑥リリースと利用者への周知

本番に反映するタイミングは、業務への影響が小さい時間帯を選びます。うまく動かない場合に元に戻す手順も、事前に決めておきます。

あわせて、画面や操作が変わる点を利用者に伝え、マニュアルや業務フローも更新します。改修後は保守の体制に戻りますが、今回の改修で更新した設計書を残しておくことが、次の改修を楽にします。

システム改修にかかる期間の目安と左右する要因

改修の期間は、変更の大きさそのものより、影響範囲の広さとテストの量、そして仕様がどこまでわかっているかで決まります。同じ「項目を1つ増やす」改修でも、ほかの機能との連携が多いシステムでは、確かめる範囲が広がり期間が延びます。

要因	期間が短くなりやすい状態	期間が延びやすい状態
影響範囲	1つの画面・機能で完結する	データベースや他システムとの連携に及ぶ
仕様のわかりやすさ	最新の設計書がある	設計書がなく、現状調査から始める
テスト	自動テストや検証環境がある	手作業で全体を確認する必要がある
社内の決定	要望と優先順位が決まっている	進めながら要望が増える
依頼先	元の開発会社が対応できる	別の会社への引き継ぎが必要

おおまかな期間を知りたい場合は、要望を整理した段階で、開発会社に現状調査を含めた概算を依頼するのが確実です。期限が決まっている法改正への対応などは、社内での決定にかかる時間も計画に入れておきましょう。

システム改修の費用の考え方

費用は「どれだけの作業が必要か」で決まるため、同じ改修でもシステムの状態によって大きく変わります。また、改修の内容によって、会計上の扱いが変わる点も知っておくと、社内の稟議や予算の組み方に役立ちます。

費用は工数と影響範囲で決まる

改修の費用は、おおむね「作業にかかる人数×期間（工数）×単価」で計算されます。工数を増やすのは、変更する箇所の多さだけではありません。現状調査、影響範囲の確認、回帰テストなど、改修ならではの作業が積み上がります。

見積もりを比べるときは、総額よりも、現状調査とテストにどれだけの工数が見込まれているかを確認することが重要です。ここが少なすぎる見積もりは、後から追加費用が出るリスクがあります。

修繕費と資本的支出の違い

ソフトウエアの改修費用は、会計上、その年の費用として処理できる「修繕費」と、資産に加えて数年かけて償却する「資本的支出」に分かれます。国税庁の法人税基本通達7-8-6の2では、プログラムの不具合を取り除く修正や現状の効用を維持する修正は修繕費、新しい機能の追加や機能の向上にあたる修正は資本的支出とされています。

1回の改修に両方が含まれることも多いため、見積もりの段階で作業の内訳を分けてもらうと、経理での処理がしやすくなります。実際の区分は個別の事情で変わるため、判断は税理士や経理担当者にご確認ください。

システム改修の依頼先の選び方

依頼先は、元の開発会社に頼めるかどうかで選択肢が変わります。まずは元の開発会社に相談し、難しい場合にほかの方法を検討する流れが一般的です。外注全般の注意点は「システム開発を外注する前に知っておくべきポイントと注意点」で詳しく解説しています。

元の開発会社に頼む

システムの中身を最もよく知っているのは、作った会社です。現状調査の手間が少なく、期間も費用も抑えやすいのが利点です。

ただし、担当者の異動や体制の変化で、当時の事情がわかる人がいないこともあります。見積もりが想定より高い場合や対応に時間がかかる場合は、その理由を具体的に尋ねてみましょう。

別の開発会社に頼む

元の会社が対応できない、あるいは費用や対応の速さに不満がある場合は、別の会社に依頼する方法があります。この場合、先に触れたソースコードの権利と所在、設計書の有無が、引き受けてもらえるかどうかを左右します。

別の会社に頼む場合は、まず現状調査だけを依頼し、その結果を見て改修を任せるか判断する、という段階的な進め方も有効です。調査の段階で、システムの状態について第三者の見立てを得られます。

自社で改修する・AIを使う

小さな改修が頻繁に発生する場合は、一部を自社で担う方法もあります。社内に開発の経験者がいなくても、画面の文言や設定の変更など、範囲を絞れば対応できることがあります。

最近は、AIを使ってソースコードを読み解いたり、修正案を作ったりする方法も広がっています。ただし、生成された変更が既存の動きを壊していないかを確かめる回帰テストの重要性は変わりません。

改修を繰り返さないために：変えやすい仕組みを選ぶ

改修の負担が重くなる背景には、システムの中身が特定の会社や担当者にしかわからない状態があります。日々の改修を丁寧に進めることに加えて、次にシステムを新しく作る・作り直すときに、変更しやすい仕組みを選ぶことも一つの方法です。

自社で変更できる状態をつくる

変えやすい仕組みとは、業務の変化に合わせた変更を、外部に頼りきりにせず自社でも進められる状態のことです。そのためには、設計書や仕様を最新に保つこと、作り方が標準化されていること、社内に判断できる人がいることが重要になります。

カスタメディアの支援

カスタメディアでは、新しくサービスやシステムを作る企業に向けて、カスタメディアプラットフォームを提供しています。900件以上の構築実績から生まれたプラットフォームの「型」を使い、AI駆動セルフ開発ツール『S-MASE』でお客様自身がシステムを作り、カスタメディアが伴走する方式です。作り直しを検討する際の選択肢の一つとしてご検討ください。

よくある質問

まとめ｜改修は「頼む前の確認」で決まる

システム改修は、稼働中のシステムを活かして、不具合の修正や機能の追加、法改正への対応などを行うことです。変更が一部にとどまり、仕様とソースコードが手元にあるなら改修が基本ですが、土台の技術が古い場合は刷新とも比べて判断します。

期間と費用を大きく左右するのは、ソースコード・設計書・環境・契約の4点が、依頼の前にどこまでわかっているかです。見積もりでは現状調査とテストの工数を確かめ、改修後は設計書を更新して、次の改修に備えましょう。

新しいサービス・システムづくりを相談したい方へ

カスタメディアでは、新規事業や顧客向けサービスのシステムを、お客様自身が作り、カスタメディアが伴走する形で支援しています。「次は変更しやすい仕組みで作りたい」「どこまで自社で担えるかを知りたい」といった段階からご相談いただけます。

⇒ 自社の担当者で作り、自分たちで改善し続けたい方へ。AI駆動セルフ開発ツール「S-MASE」の詳細を見る