システム保守を他社から引き継ぐ前に確かめる4つ｜資料が無いと調査に4〜9人日

この4つがそろうと、別の開発会社でも保守と改修を続けられます。欠けているものがあると、調べ直しや作り直しの費用が加わります。

この記事では、引き継ぐ前に確かめることと、改修で続けるか作り直すかの決め方を説明します。前の開発会社に頼むことと、今日できる一歩も書きます。

※ 当社の数字は2026年10月時点の自社実績です。

他社が作ったシステムの保守は別の会社へ引き継げる

他社が作った業務システムの保守は、権利と資料と管理の権限を受け取れれば、別の開発会社へ引き継げます。作った会社でなければ直せない、という決まりはありません。

CONFLUX PARTNERS では、2024年から2026年9月までに、他社が開発した顧客管理・予約システム（CRS）を保守ごと引き継ぎました。機能を追加した案件は6件あります。

引き継ぎを考えるきっかけには、今のシステムの保守が終わる、改修の費用が高い、の2つがあります。きっかけが違っても、最初に見るものは同じです。

私は2003年に HP 制作会社を創業し、事業の経営を23年続けてきました。2022年から2025年までは、AI・システム開発会社2社の代表取締役も務めました。作る側として契約を交わしてきた立場から見ると、引き継ぎの難しさは技術より、何を受け取れるかで決まります。

システム保守の引き継ぎ前に確かめる4つ

システム保守を他社から引き継ぐ前に確かめるのは、ソースコードの権利・設計書と手順書・管理の権限・今の不具合の4つです。この順に見ると、引き継げるかどうかが早く分かります。

4つの中身と、確かめる相手を表にまとめます。

1のソースコードの権利は、最初に見てください。権利が前の会社に残っていると、資料がそろっていても改修できません。

2025年4月には、飲食店（5店舗）の予約システムを他社から引き継ぎました。ソースコードの権利が前の開発会社に残っていて、改修できない状態でした。権利の譲渡を交渉するより作り直すほうが早いと判断し、3か月で新しく作り直しています。

3の管理の権限は、見落とされやすい項目です。サーバーやドメインのアカウントが前の会社の名義だと、保守の契約が終わった日に触れなくなります。アカウントの名義が自社か、ログインの情報を受け取れるかを確かめてください。

4の困りごとは、使っている社員に聞くのが近道です。経営者が知らない回避の手順が、現場で続いていることがあるためです。

資料が無いシステムは調査に1件4〜9人日かかる

資料が無いシステムを引き継ぐと、中身を調べる作業が増え、当社の例では1件あたり4〜9人日が追加でかかりました。資料がある場合より、改修を始める日が遅れます。

当社が2023年から2025年に引き継いだ6件のうち、資料が無かったのは4件です。この4件では、調査に合計約25人日（1件あたり4〜9人日）が追加でかかりました。人日は、1人が1日で進める作業の量を表す単位です。

調査で手間がかかるのは、業務の決まりがプログラムの中にだけ書かれている部分です。引き継いだシステムで、給与計算の締め日の処理がどこに書かれているか、資料から分からないことがありました。本番のデータで動かしながら確かめるしかなく、そこで日数が増えます。

自社のシステムに当てはめるときは、次の試算を使ってください。

試算：資料の無い画面が10画面あり、1画面を半日で調べる前提とすると、調査は5人日です。

仮に資料の無い画面が20画面なら、同じ前提で10人日です。当社の4件の幅（4〜9人日）を超えるときは、調査だけを先に頼んでください。

画面の数は、メニューに並ぶ画面を数えると分かります。1画面の調べる時間は、外部サービスとのつながりが多いほど長くなります。

当社の判断では、資料が無いと分かった時点で、調査を見積りの別の行に分けてもらうのがよいと考えます。調査の後に改修の範囲が変わることが多く、まとめた見積りでは後から金額が動くためです。

改修で続けるか作り直すかの分かれ道

引き継いだシステムを改修で続けるか作り直すかは、ソースコードの権利・資料の有無・足りないものの大きさの3つで決まります。3つとも左の列に当てはまるなら、改修で続けてください。

2023年6月には、製造業の会社（従業員約80名）の在庫管理システムを、前の開発会社から引き継ぎました。「拠点間の移動」の要件が抜けていて、月末の棚卸しで数字が合わない状態が続いていました。

在庫管理システムの引き継ぎでは、作り直しではなく、移動の登録画面を足す改修で対応すると判断しました。足りないのが一部の画面で、ほかの機能は使えていたためです。改修は2か月・追加約120万円で、数字が合わない状態を解消しました。

反対に、権利が前の会社に残る場合は、作り直しを選んだほうが早く済むことがあります。先ほどの飲食店の予約システムは、この理由で作り直しました。

• 権利を受け取れて、足りないのが一部なら、改修で続けてください
• 権利は受け取れるが資料がほとんど無いなら、調査の日数を見積もってから、改修と作り直しを比べてください
• 権利が前の会社に残るなら、譲渡の交渉と作り直しの期間を並べて比べてください

2つ以上に当てはまるなら、ソースコードの権利の答えを先に使ってください。権利が無いと、資料があっても改修できないためです。

顧問パッケージの内容と料金を見る →ここまでの内容が自社に当てはまるか、確認しませんか。要件の確認だけでもご利用いただけます

開発会社を変えないほうがよい場合

今の開発会社が保守を続けられ、困りごとが返事の遅さや頼み方だけなら、引き継ぎより頼み方を直すほうが早く済みます。会社を変えると、新しい会社が中身を調べる日数が加わるためです。

次の場合は、引き継ぎを急がないでください。

• 今の会社の保守の契約が続いていて、不具合にも対応してもらえている
• 困りごとが、依頼の窓口が決まっていないことから来ている
• 1年以内に、業務のやり方そのものを変える予定がある

3つ目に当てはまる会社は、今のシステムを引き継ぐより、業務が決まってから新しく作るほうが無駄が出ません。

頼み方を直すなら、まず変更の依頼を書面で残してください。2024年2月には、人材サービスの会社（従業員約30名）の勤怠システムで、仕様変更が口頭だけで進みました。納品の直前に「言った・言わない」になり、変更点を一覧にして双方で確かめ直しました。納期を1か月延ばして納品し、以後は変更をすべて書面で残す運用にしています。

仕様の変更は、追加の費用にもつながります。YW がこれまでに手がけた案件は500件以上あり、そのうち34件は契約後の仕様変更で追加の見積りになりました。34件（2022年4月〜2026年9月）の追加額は10万〜180万円で、中央値は約35万円です。

自社で使えるか、相談する →今のシステムの状態をうかがい、引き継ぐか、今の会社と続けるかを一緒に決めます。何を頼むか決まっていなくても大丈夫です。

前の開発会社に頼む引き継ぎの資料と権利

前の開発会社には、ソースコード・設計書・手順書・管理の権限の受け渡しと、改修できる権利の範囲の確認を頼みます。保守の契約が終わる前に頼むと、受け取りやすくなります。

頼むものは、次の5つです。

1. ソースコード（システムを動かしているプログラムの本体）
2. 設計書（どの画面が何を記録しているかの説明）
3. 操作の手順書（社員が日々使うときの手順）
4. サーバー・ドメイン・外部サービスのログイン情報と名義の変更
5. 改修できる権利が自社にあるかの確認

5の権利は、契約書の書き方で変わります。著作権法第61条第2項では、翻案などの権利（第27条・第28条の権利）を契約で特に書かないと、譲渡した側に残ると推定されます。条文はe-Gov法令検索の著作権法で読めます。

2026年11月に当社が2つのAI（ChatGPT・Gemini）に本記事の論点5問を聞き、10件の答えを集めました。10件の答えのうち、公的機関の資料にある「著作権法」に触れたものは0件でした。（出典: 当社調べ）

同じ調べでは、10件の答えのうち、触れていたのは専門家への相談は0件、費用の金額（◯円）は1件、期間（◯か月・◯日など）は6件でした。（出典: 当社調べ）

新しい開発会社と保守の契約を結ぶなら、情報処理推進機構（IPA）の情報システム・モデル取引・契約書が条文の形の参考になります。契約書の読み方は、次のように分けてください。

• 契約書に第27条・第28条の権利の記載があるなら、ソースコードの受け取りへ進んでください
• 記載が無い、または契約書が見つからないなら、前の会社に権利の範囲を書面で確かめてください
• 前の会社と権利の扱いで意見が分かれたら、その判断は弁護士に確認してください

権利と資料の決め方は、システム開発の内製と外注は4つの条件で決めると、システム開発を外注するデメリット5つと契約前に決める対策でも説明しています。

引き継ぎから保守を始めるまでの流れと今日の一歩

システム保守の引き継ぎは、聞き取り・権利と権限の受け取り・調査と資料づくり・小さな改修の順で進めます。大きな改修は、調査が終わってから始めてください。

最初に小さな改修を1つ終えると、新しい会社がそのシステムを直せることを確かめられます。大きな機能の追加は、その後に段階的に出す計画にしてください。

当社が2022年1月から2026年9月までに手がけた開発案件は約48件です。そのうち予定どおり終わったのは約30件でした。段階的に出す計画にしておくと、想定外があっても主要な機能を予定日に使い始められます。

2025年の案件では、納期の問題で、外部 API の仕様変更により連携部分が動かないと2週間前に分かりました。機能を段階的に出す形に切り替え、主要な機能を予定日に公開しました。残りは3週間後に納品しています。

引き継ぎを考え始めたら、まず次の3つを確かめてください。

1. 前の開発会社との契約書が手元にあるか
2. サーバーとドメインのアカウントの名義が自社か
3. 今の保守の契約がいつ終わるか

3つの答えがそろえば、引き継ぎの相談で必要な情報がほぼそろいます。契約の終わりまで3か月を切っているなら、資料と権限の受け渡しを先に頼んでください。3か月は当社の判断です。予約・管理画面など小規模な開発でも、当社の代表的な5件（2020年〜2026年9月）で1.5〜3か月かかったためです。

改修の費用の決まり方は業務システム開発の費用、見積りの並べ方はシステム開発の見積もり比較で説明しています。

予約システムの引き継ぎは予約システム開発の費用は権利と引き継ぎで変わるもご覧ください。

CONFLUX PARTNERS のシステム開発では、他社が作ったシステムの調査・資料づくりから保守・改修までお手伝いします。

開発をほかの相談とまとめて任せたい場合は、CONFLUX 顧問パッケージもご覧ください。

自社で使えるか、相談する →契約書とアカウントの状況をうかがい、引き継げるか、改修か作り直しかをお伝えします。ご契約を前提としたご案内ではありません。