システム開発会社を変更したいときは？保守引き継ぎと再構築の判断

システム開発会社を変更したいときは、先に「誰に任せるか」と「何を変えるか」を分けて整理します。対応の遅さや保守費への不満があっても、稼働中のシステムを全面的に作り直す必要があるとは限りません。いまの会社との契約・役割を見直す、保守を他社へ引き継ぐ、一部の機能だけ改修する、といった選択肢もあります。

この記事は、受注・請求・予約・顧客管理など、業務で使っているシステムの委託先を計画的に見直したい方向けです。開発会社と連絡が取れず、停止やデータ消失が迫っている場合は、比較検討より業務継続と権限・データの保全を優先してください。

まず「対応が遅い」「保守費が高い」の中身を分ける

不満を会社名や印象だけで伝えると、次の会社も必要な体制を判断できません。直近の依頼について、いつ何を伝え、いつ返答があり、どの業務に影響したかを整理します。最初の返答までの時間と、調査・修正が終わるまでの時間は別に扱いましょう。

困っていること	先に確認したい点	見直しの方向
返事が遅く、予定が分からない	受付窓口、対応時間、優先度、進捗報告の約束	連絡・役割分担の改善、保守先の変更
毎月の保守費が高く感じる	監視、バックアップ、障害対応、更新作業の内訳と実施記録	同じ範囲での比較、不要作業の整理
小さな変更でも見積もりが大きい	影響する機能、試験範囲、古い技術、仕様の不明点	局所改修、保守性改善、段階的な置換
現場の業務に合わなくなった	二重入力、使わない機能、必要な帳票、残したい操作	業務整理、SaaS比較、必要範囲の再構築

例えば月次請求だけが遅いなら、問い合わせ対応の問題と、締め処理の仕組みの問題では対策が異なります。保守費の比較も、対応範囲が違えば単純に高い・安いとは判断できません。現会社への改善相談で解消する可能性も含めて考えます。

会社の変更とシステムの再構築を別々に判断する

現在の機能で業務が回り、ソースコード・環境・契約条件を確認できるなら、システムを維持したまま保守先を変えられる可能性があります。一方、技術の対応終了や仕様の複雑さが原因なら、担当会社を変えるだけでは改善しないこともあります。

外部連携だけを別会社に任せる案では、障害時に誰が原因を切り分けるかも必要です。窓口を増やすだけでは、責任の境目で対応が止まるおそれがあります。再構築を選ぶ場合も、請求・予約・顧客管理を一度に切り替えるか、機能ごとに移すかを検討します。

SaaS・パッケージ・個別開発で引き継げるものが違う

開発会社を変える話でも、利用している仕組みによって交渉先と確認事項が変わります。IPAのモデル取引・契約書も、受託開発・保守運用と、パッケージやSaaS・ASPを活用する取引を分けて資料を用意しています。

仕組み	変更時に確認すること
SaaSの利用・設定を委託	提供事業者と支援会社の違い、契約名義、管理者変更、データ出力、連携設定。支援会社の変更とSaaS自体の乗換えを分ける。
パッケージを導入・カスタマイズ	利用許諾、改修可能な範囲、製品保守、追加部分の権利、他社が扱える条件。
自社向けに個別開発	契約上の納品物・利用権・改変権、ソースコード、構築手順、本番環境、外部サービス契約の所在。

開発費を支払ったという事情だけで、すべての権利やアカウントを自由に移せると決めつけないでください。締結済み契約、個別見積書、利用規約を確認し、不明な権利関係は契約担当者や専門家に確認します。

画面だけでなく、裏側の処理まで棚卸しする

引き継ぎ資料では、使っている画面に加え、入力から最終的な出力までを追います。受注が登録できても、在庫連携や請求書発行が動かなければ業務は完了しません。毎日使う機能だけでなく、月末・年度末にだけ動く処理も対象です。

AWSのアプリケーション調査ガイドは、資料と実際の構成・通信を照合し、外部依存や運用条件を確認する考え方を示しています。AWS移行向けの資料ですが、以下はその観点を業務システムの引き継ぎ判断に応用した整理です。

• 業務：担当部署、締め日、承認手順、停止できる時間、手作業で代替できる範囲。
• 構成：プログラム、データベース、ファイル保存先、本番・検証環境、構築・更新手順。
• 連携：会計、決済、配送、メール、API、ファイル受け渡し、定期実行の時刻と実行元。
• 運用：監視、バックアップ、証明書や契約の更新、障害時の連絡先、復旧手順。

仕様書がない場合は、現場の操作、帳票、設定、承認された範囲のログなどから確認します。「資料がないから引き継げない」と即断する必要はありませんが、調査すれば必ず全部分かるとも限りません。確認済みと不明点を分けて残します。

見積もりは月額だけでなく、移るための費用を分ける

比較したいのは、同じ業務を維持する条件での負担です。現状調査、環境準備、データ移行、試験、切替支援、切替後の保守を分け、見積もりに含む範囲と別途になる条件を確認します。旧契約との重複期間、ライセンス、社内担当者の確認作業も見落とせません。

IPAの再構築に関する説明でも、現在の仕様を明らかにする調査には技術・時間・コストが必要とされています。「いまと同じもの」を依頼しても、現状確認が不要になるわけではありません。先に調査範囲を合意し、その結果から引き継ぎ・改修・再構築の案を比べると、前提が異なる見積もりを並べずに済みます。

契約終了より先に、引き継ぎの完了条件を決める

変更先が決まったら、作業の順序と「引き継げた」と判断する条件を現会社・新会社・自社で確認します。環境をコピーして画面が開くだけでは、完了とはいえません。

1. 対象業務、契約上の条件、資料と権限の引渡し方法を確認する。
2. 必要な環境・データを保全し、検証環境で復元と主要業務を確かめる。
3. 日次・月次処理、外部連携、権限、監視、問い合わせ対応の担当を確認する。
4. 切替時点のデータ差分、失敗時に戻す条件、再開時の二重処理防止を合意する。
5. 切替後の確認と契約条件を満たしてから、不要な旧環境・旧契約を整理する。

AWSの復元試験の指針も、保存されたデータを実際に戻せるか確かめることを重視しています。復元先から本番の請求・通知・定期処理が誤って動かないよう、試験の通信先と実行条件を技術担当者が管理してください。

調査を依頼する際に確認したい項目

「調査一式」という名前だけでは、どこまで判断できるか分かりません。次の項目は、調査を依頼するときの確認例です。実際の調査範囲と報告内容・費用は、着手前に依頼先と確認してください。

• どの資料・環境を確認でき、何が未確認なのか。
• 現状維持・保守移管・一部改修・再構築の各案を選ぶ条件。
• 引き継ぐ資産、権限、外部依存と、それぞれの担当者。
• 移行時の業務影響、復元・受入確認の方法、追加調査が必要な点。

いまの業務と、変えたい理由から相談する

ENOLでは、Laravelを中心とした業務システム開発・既存システムからの乗り換えを案内しています。現状の画面、帳票、データ、運用ルールを確認し、段階移行を含めて検討する進め方です。保守引き継ぎの可否や必要な調査は、技術・権利・資料の状況に応じて確認します。

システムの改修・保守の見直しを相談するには、業務の種類、変えたい理由、現在の会社と連絡できるか、資料や管理権限の所在、希望時期をお知らせください。パスワード、秘密鍵、個人情報を含む本番データはフォームに貼り付けず、共有が必要になった段階で方法を確認します。企業サイト自体の引き継ぎは、ホームページ制作会社と連絡が取れない場合のガイドで扱っています。