「現在使っているシステムに機能を追加したい」
「以前の開発会社と連絡が取れなくなった」
「不具合があるが、誰に修正を依頼すればよいか分からない」
「古いシステムを使い続けており、少しずつ改善したい」
このような場合は、既存システムの改修を外部のエンジニアやシステム開発会社へ依頼できます。
既存システムの改修では、ゼロから新しいシステムを作るのではなく、現在のソースコードやデータベースを確認しながら、必要な部分だけを変更します。
例えば、次のような改修が可能です。
- 入力項目を追加する
- 検索条件を増やす
- 管理画面を使いやすくする
- PDF・CSV出力を追加する
- メール通知を追加する
- API連携を追加する
- スマートフォン表示を改善する
- 処理速度を改善する
- 不具合を修正する
- AI機能を追加する
ただし、既存システムの改修は、新規開発とは異なる難しさがあります。
ソースコードの品質、使用している技術、ドキュメントの有無、サーバー構成などによって、改修できるかどうかが変わります。
この記事では、既存システムの改修を外注する方法、依頼できる内容、費用、外注前に確認するもの、依頼先の選び方を解説します。
既存システムの改修とは
既存システムの改修とは、すでに稼働しているWebシステムや業務システムに対して、機能追加・修正・改善を行うことです。
新規開発との違いは、すでに存在するシステムの仕様やコードを理解したうえで変更する必要がある点です。
例えば、顧客管理システムであれば、次のような改修があります。
現在
顧客登録
顧客一覧
検索
対応履歴
改修後
顧客登録
顧客一覧
詳細検索
対応履歴
担当者管理
CSV出力
メール通知
必要な部分だけを追加できれば、システム全体を作り直すより費用を抑えられる場合があります。
既存システムを改修する主な理由
業務内容が変わった
システム導入後に、会社の業務フローが変わることがあります。
- 新しい商品を扱うようになった
- 部署が増えた
- 承認フローが変わった
- 顧客管理項目が増えた
- 新しい帳票が必要になった
システムが現在の業務に合わなくなった場合は、改修を検討します。
利用者が増えた
最初は数人で利用していたシステムでも、社員や拠点が増えると新しい機能が必要になります。
- 権限管理
- 担当者管理
- 部署別表示
- 操作履歴
- 同時利用対策
- 検索機能
利用規模に合わせてシステムを拡張します。
手作業が残っている
システムを導入していても、その周辺でExcelやメールを使った手作業が残っている場合があります。
例えば、
システムからCSV出力
↓
Excelで加工
↓
PDFを作成
↓
メールに添付
↓
担当者へ送信
という業務です。
既存システムに帳票作成やメール送信を追加すれば、手作業を減らせる可能性があります。
外部サービスと連携したい
新しいクラウドサービスを導入した際に、既存システムと連携したい場合があります。
- 会計システム
- Slack
- Google Workspace
- 決済サービス
- CRM
- ECサイト
- AI API
- メール配信サービス
API連携を追加することで、二重入力を減らせます。
操作性が悪い
システム自体は動いていても、画面が使いにくい場合があります。
- 入力項目が多い
- ボタンの位置が分かりにくい
- 検索しにくい
- スマートフォンで使いにくい
- 必要な情報が一画面で確認できない
画面構成やUIを改善するだけでも、業務時間を短縮できる場合があります。
不具合が発生している
長年利用しているシステムでは、次のような不具合が発生することがあります。
- 特定の操作でエラーになる
- データが保存されない
- PDFが正しく出力されない
- メールが送信されない
- 一部画面が表示されない
- 処理に時間がかかる
- ブラウザ更新後に動かなくなった
原因を調査し、必要なコードを修正します。
既存システムで依頼できる改修
入力項目の追加・変更
業務変更に合わせて、フォームや管理画面の入力項目を変更します。
例えば、
- 顧客ランク
- 担当部署
- 契約日
- ステータス
- 備考
- 管理番号
などを追加します。
単純に画面へ項目を追加するだけでなく、データベースや検索処理も変更する必要があります。
一覧画面の改善
管理画面の一覧を使いやすくします。
- 表示列の追加
- 並び替え
- ページネーション
- 色分け
- ステータス表示
- 担当者表示
- 合計値表示
- 一括操作
業務システムでは、一覧画面の改善が作業効率に大きく影響します。
検索機能の追加
データ量が増えると、必要な情報を探しにくくなります。
次のような検索条件を追加できます。
- 顧客名
- 担当者
- 日付
- ステータス
- 商品
- 金額
- 地域
- 複数条件の組み合わせ
よく使う条件を保存する機能を追加することも可能です。
CSV出力・取り込み
システム内のデータをCSV形式で出力したり、外部データを取り込んだりします。
- 顧客一覧
- 売上データ
- 在庫データ
- 注文履歴
- 対応履歴
既存システムとExcelを併用している企業では、利用頻度の高い機能です。
PDF帳票の追加
システム内のデータから、PDF帳票を生成します。
- 見積書
- 請求書
- 作業報告書
- 顧客別明細
- 申込書
- 在庫一覧
- 月次レポート
現在手作業でPDFを作成している場合は、システム内で自動生成できるように改修します。
メール通知の追加
システム上の操作をきっかけにメールを送信します。
例えば、
案件を登録
↓
担当者へメール通知
または、
ステータスを「完了」に変更
↓
顧客へ完了メール
といった処理です。
メール本文へ顧客名や日時などを自動で差し込めます。
Slack・チャット通知の追加
重要なイベントをSlackなどへ通知します。
- 新規問い合わせ
- 新規注文
- 予約
- 在庫不足
- エラー
- 申請
- 承認待ち
担当者が管理画面を開いて確認する回数を減らせます。
API連携の追加
既存システムへ外部サービスとのAPI連携を追加します。
例えば、
既存システム
↓
API
↓
会計システム
または、
問い合わせフォーム
↓
API
↓
既存顧客管理システム
などです。
APIが提供されていない場合は、CSV、Webhook、GAS、Pythonなど別の方法を検討します。
権限管理の追加
利用者によって閲覧・操作できる範囲を分けます。
- 管理者
- 一般社員
- 営業担当
- 経理担当
- 閲覧のみ
例えば、
管理者
すべて閲覧・編集可能
営業担当
自分の顧客だけ編集可能
一般社員
閲覧のみ
といった設定です。
操作履歴の追加
誰がいつデータを変更したか記録します。
- 登録
- 編集
- 削除
- ステータス変更
- ログイン
複数人で利用するシステムでは、トラブル時の確認に役立ちます。
スマートフォン対応
パソコン向けに作られた画面を、スマートフォンでも操作しやすくします。
- ボタンサイズ
- 表の表示
- 入力欄
- メニュー
- レイアウト
営業先、倉庫、店舗などで利用するシステムでは特に重要です。
処理速度の改善
システムが遅くなっている場合は、原因を調査します。
主な原因は次のとおりです。
- データベース検索
- 不要なAPI通信
- 大量データの一括表示
- N+1問題
- 重い集計処理
- 画像サイズ
- フロントエンド処理
- サーバー性能
サーバーを高性能にする前に、コードやSQLを改善できないか確認します。
AI機能の追加
既存システムへ生成AI機能を追加することもできます。
- 顧客対応履歴の要約
- 問い合わせ分類
- メール返信案
- 社内資料検索
- PDFからの情報抽出
- 報告書作成
- データの説明
例えば、顧客管理システムに次の機能を追加できます。
過去の対応履歴
↓
AIが要約
↓
「これまでの対応概要」を表示
既存システムに組み込むことで、毎回ChatGPTへ情報をコピーする必要がなくなります。
既存システムの改修で必要になる調査
新規開発とは違い、既存システムの改修では最初に調査が必要です。
使用しているプログラミング言語
例えば、
- Java
- PHP
- Python
- Ruby
- TypeScript
- JavaScript
- C#
- VB.NET
などです。
依頼先が使用技術へ対応できる必要があります。
フレームワーク
例えば、
- Spring
- Django
- Laravel
- Rails
- React
- Next.js
- Vue.js
などです。
同じプログラミング言語でも、使用しているフレームワークによって構成が異なります。
データベース
- PostgreSQL
- MySQL
- Oracle
- SQL Server
- MongoDB
などを確認します。
改修内容によっては、データベース構造の変更が必要です。
サーバー・クラウド
- AWS
- Azure
- Google Cloud
- VPS
- レンタルサーバー
- Vercel
- オンプレミス
など、現在どこで動いているか確認します。
ソースコードの管理場所
GitHub、GitLab、社内サーバーなどにソースコードがあるか確認します。
ソースコードが存在しない場合、改修できる範囲が大きく制限されます。
既存システムのソースコードがない場合
「現在システムは動いているが、ソースコードがどこにあるか分からない」というケースがあります。
この場合、まず次の情報を確認します。
- 開発会社との契約
- 納品されたファイル
- GitHubなどのアカウント
- サーバー内のファイル
- バックアップ
- 担当者のパソコン
- 過去のメール
Webサーバー上にプログラムが残っている場合もありますが、それが開発可能な完全なソースコードとは限りません。
ビルド済みのファイルしか残っていない場合は、改修が難しいこともあります。
開発会社が分からない場合
以前作ったシステムで、開発会社や担当者が分からなくなっている場合があります。
この場合も、
- ドメイン
- サーバー
- ソースコード
- データベース
- 管理画面
- 契約情報
を確認し、引き継ぎ可能か判断します。
システムが動いているからといって、必ず改修できるとは限りません。
開発会社を変更しても改修できる？
技術的には、別の会社やエンジニアが改修できる場合があります。
ただし、次の条件が重要です。
- ソースコードへアクセスできる
- サーバーへアクセスできる
- データベースへアクセスできる
- 必要なアカウントがある
- 契約上問題がない
- 使用技術に対応できる
新しい開発者は、既存コードを理解するところから始めるため、最初に調査費用が発生する場合があります。
既存システム改修の費用
既存システムの改修費用は、変更内容だけでなく、既存コードの状態に大きく左右されます。
目安としては次のように考えます。
| 改修内容 | 費用の目安 |
|---|---|
| 文言・軽微な画面修正 | 数万円程度から |
| 入力項目・検索条件追加 | 5万円〜30万円程度 |
| CSV・PDF出力追加 | 10万円〜50万円程度 |
| メール・通知追加 | 5万円〜30万円程度 |
| API連携追加 | 20万円〜100万円以上 |
| 権限管理追加 | 数十万円以上 |
| 複数画面の機能追加 | 数十万円〜 |
| 大規模なコード改修 | 個別見積もり |
| 技術刷新・リプレイス | 数百万円以上になる場合もある |
実際の料金はシステムごとに異なります。
改修費用を左右する要素
既存コードの品質
整理されたコードであれば改修しやすくなります。
一方、
- 同じ処理が何度も書かれている
- コメントがない
- 不要なコードが大量にある
- テストがない
- 命名規則が統一されていない
場合は、調査に時間がかかります。
ドキュメントの有無
次の資料があると調査しやすくなります。
- システム構成図
- データベース定義
- API仕様
- 画面一覧
- 操作マニュアル
- 開発手順
- デプロイ手順
資料がなくても改修できる場合はありますが、調査工数が増えます。
使用技術の古さ
古いライブラリやフレームワークを使用している場合、現在の開発環境を準備するだけでも時間がかかることがあります。
セキュリティ上、先にバージョンアップが必要なケースもあります。
テスト範囲
一つの機能を変更したことで、別の機能へ影響が出る可能性があります。
既存システムでは、改修箇所以外の確認も必要です。
本番環境への反映方法
自動デプロイ環境が整っているシステムと、手動で本番サーバーへファイルを配置するシステムでは、作業量が変わります。
既存システムを改修するか作り直すか
長期間使っているシステムでは、
「改修を続けるべきか」
「新しく作り直すべきか」
という問題が発生します。
改修が向いているケース
- 現在の基本機能は問題なく使える
- 追加したい機能が限定的
- ソースコードが整理されている
- 使用技術が古すぎない
- 利用者が現在の操作に慣れている
- データ移行を避けたい
作り直しを検討するケース
- システム全体が遅い
- 不具合が頻繁に発生する
- 仕様変更のたびに別の箇所が壊れる
- 使用技術が極端に古い
- セキュリティ上の問題がある
- ソースコードが保守できない
- 新しい業務と大きく合わなくなっている
- 改修費用が積み重なっている
一部だけ新しいシステムへ置き換え、段階的に移行する方法もあります。
既存システムの改修を外注する流れ
1．改善したい内容を共有する
最初から技術仕様を決める必要はありません。
例えば、
- CSVを出せるようにしたい
- 検索を追加したい
- メールを自動化したい
- スマートフォンで使いたい
- 処理が遅い
- エラーが発生する
といった内容から相談できます。
2．現在のシステム情報を共有する
可能な範囲で次の情報を準備します。
- システムURL
- ソースコード
- GitHub
- 使用技術
- サーバー
- データベース
- 管理画面
- 開発資料
すべて分からなくても構いません。
確認できる範囲から調査します。
3．既存コードを調査する
新しい開発者が、
- システム構成
- コード
- データベース
- 外部サービス
- デプロイ方法
を確認します。
この調査結果から、改修可能か判断します。
4．影響範囲を確認する
例えば、「顧客に項目を一つ追加する」だけでも、
入力画面
↓
データベース
↓
顧客詳細
↓
検索
↓
CSV
↓
帳票
など、複数箇所へ影響する場合があります。
5．見積もりを確認する
次の内容を確認します。
- 改修内容
- 調査費用
- 開発費用
- テスト範囲
- 本番反映
- 納期
- 修正条件
- 保守
6．バックアップを取得する
改修前に、ソースコードとデータベースのバックアップを取得します。
本番環境だけにコードが存在する状態は避けます。
7．開発環境・テスト環境で修正する
可能な限り、本番環境を直接変更せず、別の環境で開発・確認します。
8．テストする
改修した機能だけでなく、関連機能も確認します。
9．本番へ反映する
利用者への影響が少ない時間帯などを選び、本番環境へ反映します。
10．導入後に確認する
本番環境で、
- エラー
- ログ
- データ
- 表示
- 処理速度
などを確認します。
改修を外注する前に準備したい情報
次の情報があるとスムーズです。
- システムのURL
- 管理画面
- 改修したい内容
- 発生しているエラー
- スクリーンショット
- 再現手順
- GitHubなどのソースコード
- サーバー情報
- データベース情報
- 使用サービス
- 過去の設計資料
- 開発会社との契約内容
- 希望納期
- 予算
すべて用意できなくても相談できます。
既存システム改修の外注先
元の開発会社
対応可能であれば、最もシステムを理解している可能性があります。
ただし、
- 費用が高い
- 返信が遅い
- 小さな改修へ対応してもらえない
- 会社がなくなった
などの理由で変更することもあります。
フリーランスエンジニア
小規模から中規模の改修であれば、フリーランスへ直接依頼できます。
メリット
- 開発者へ直接相談できる
- 小さな機能追加を依頼しやすい
- 開発会社より間接費を抑えやすい
- 継続的な改善を相談しやすい
- 技術的な判断を直接聞ける
注意点
- 対応できる技術に限りがある
- 大規模システムには向かない場合がある
- 24時間体制などには対応しにくい
- 既存システムの品質によっては改修できない
システム開発会社
複数人で調査・開発する必要がある場合に適しています。
特に、
- 大規模な基幹システム
- 高度なセキュリティ
- 大規模リプレイス
- 複数システム連携
では開発会社の方が適する場合があります。
既存システム改修の依頼先を選ぶポイント
使用技術へ対応できるか
JavaのシステムをPHP専門の開発者へ依頼することは難しい場合があります。
現在の技術構成を確認します。
既存コードの調査に対応できるか
新規開発だけでなく、他人が作ったコードを読み、構造を理解できる経験が重要です。
無理に改修しない判断ができるか
場合によっては、
「このシステムは改修より作り直した方がよい」
という判断が必要です。
受注のために無理な改修を続ける依頼先は避けます。
バックアップを取るか
既存システムを直接変更する場合、必ずバックアップを確認します。
テスト方法を説明できるか
「コードを書いて終わり」ではなく、どこまで影響確認するかを確認します。
Gitでソースコードを管理するか
変更履歴を残すことで、
「どこを変更したか」
を確認できます。
本番環境を直接変更しないか
可能であれば開発・テスト環境を用意し、確認後に本番へ反映します。
引き継げる状態にするか
ソースコード、設定、アカウントなどを自社でも管理できる状態が望まれます。
既存システム改修で失敗しやすいケース
本番環境を直接修正する
変更に失敗した際、すぐに戻せなくなる可能性があります。
バックアップと変更履歴を残します。
小さな修正だと思い込む
画面上では小さな変更でも、内部では複数機能へ影響する場合があります。
調査後に工数が増えることもあります。
ソースコードを確認せず見積もる
既存コードの状態が分からなければ、正確な見積もりは難しくなります。
最初に調査工程を設ける方法があります。
テストを省略する
既存機能を壊してしまう可能性があります。
関連する画面や処理も確認します。
データベース変更を軽視する
項目追加やデータ型変更では、既存データへの影響を確認する必要があります。
外部サービスへの依存を確認しない
既存システムがAPIや外部サービスへ依存している場合、改修内容へ影響します。
古い技術をそのまま延命する
毎回修正費用が高くなる場合は、バージョンアップや作り直しを検討します。
既存システムの改修費用を抑える方法
改修内容へ優先順位を付ける
要望を、
必須
できれば必要
将来的に必要
に分けます。
最初は業務への影響が大きいものだけを改修します。
小さな単位で依頼する
例えば、
第1段階
検索機能改善
第2段階
CSV出力
第3段階
API連携
のように分けます。
現在の資料を整理する
GitHub、サーバー情報、設計資料などを先にまとめると、調査時間を減らせる可能性があります。
不要な機能を削除する
使われていない機能を維持すると、改修やテスト範囲が増えます。
改修を続けるか定期的に判断する
古いシステムでは、改修費用が積み重なります。
一定のタイミングで、リプレイスとの費用比較を行います。
hiro-dev-labの既存システム改修支援
hiro-dev-labでは、中小企業向けのWebシステム・業務システムの改修や機能追加に対応しています。
主な対応内容は次のとおりです。
- 入力項目の追加
- 一覧画面の改善
- 検索機能の追加
- CSV入出力
- PDF帳票
- メール通知
- 権限管理
- API連携
- AI機能追加
- スマートフォン対応
- 不具合修正
- 処理速度改善
- データベース変更
- 既存コードの調査
- 継続的な機能改善
Java、Python、TypeScriptを中心に、Webシステムの開発経験を生かして既存コードを確認します。
すぐに改修作業を始めるのではなく、
- 使用技術
- ソースコード
- データベース
- サーバー
- 改修による影響
を確認し、対応可能か判断します。
無理に既存システムを延命するのではなく、必要に応じて部分的な作り直しや、新しいシステムへの段階的な移行も検討します。
千葉市内では、必要に応じて対面で現在のシステムや業務を確認できます。
オンラインであれば、千葉県内・全国から相談可能です。
既存システムの改修に関するよくある質問
他社が開発したシステムでも改修できますか？
ソースコード、使用技術、契約内容などを確認し、対応可能か判断します。
開発会社と連絡が取れなくても相談できますか？
相談できます。
現在保有しているソースコード、サーバー、アカウントなどを確認します。
ソースコードがどこにあるか分かりません
GitHub、サーバー、過去の納品物などを確認します。
ソースコードがない場合は、改修できない可能性もあります。
小さな機能追加だけでも依頼できますか？
対応可能です。
CSV出力、検索条件追加、メール通知など、小規模な改修から相談できます。
不具合の原因調査だけでも依頼できますか？
システムや契約内容によりますが、原因調査のみから対応できる場合があります。
古いJavaやPHPのシステムでも改修できますか？
使用しているバージョンやフレームワークを確認して判断します。
古すぎる場合は、バージョンアップが必要になることがあります。
API連携を追加できますか？
対象システムの構造と連携先のAPI仕様を確認し、実装可能か判断します。
AI機能を追加できますか？
既存システムへAI APIを追加し、要約、分類、文書作成などを実装できる場合があります。
改修と作り直しのどちらがよいか相談できますか？
対応できます。
現在のシステムの状態、改修費用、今後必要な機能を比較して判断します。
改修後も継続して保守できますか？
不具合修正、機能追加、業務変更に伴う改修などを継続的に支援できます。
今あるシステムを少しずつ改善したい方へ
業務システムは、一度作れば完成ではありません。
会社の業務、利用者、外部サービスが変われば、システムにも変更が必要になります。
- 現在のシステムに機能を追加したい
- 小さな不具合を直したい
- 管理画面を使いやすくしたい
- CSVやPDF出力を追加したい
- API連携を追加したい
- スマートフォン対応したい
- AI機能を追加したい
- 以前の開発会社へ依頼できなくなった
- 改修と作り直しのどちらがよいか分からない
このような段階から相談できます。
hiro-dev-labでは、既存システムを確認したうえで、必要な機能だけを小さく改修し、業務に合わせて継続的に改善します。
既存システムの改修・機能追加について相談する