作り直す前に、保守だけを移す選択肢を検討する
「障害が起きても一次対応が遅い」「監視やバックアップが実施されているのか分からない」「ライブラリの更新を頼んでも進まない」。作った会社の保守対応への不満は、システムそのものではなく、保守の体制から生まれていることがよくあります。それなのに、不満が溜まった結果として「いっそ作り直そう」と大きな判断へ進んでしまう例は少なくありません。
システムが業務に合っていて、技術的にもまだ保守できる状態なら、作り直さずに保守・運用だけを別の会社へ移す方法があります。作り直しに比べて初期の費用も期間も小さく、業務を止めるリスクも抑えられます。ただし、引き継ぎ先に保守をそのまま引き受けてもらえるとは限りません。コードや権限がそろっていない、使っている技術がサポートを終えている、といった理由で断られることもあります。
保守を移すきっかけは不満だけではありません。保守会社の廃業や担当者の退職で、保守の打ち切りを告げられ、引き受け先を探さなければならなくなることもあります。本記事では、どちらの事情であっても、保守・運用を他社へ移す発注担当者に向けて、判断の軸、引き継ぎ先が行う調査、資料のそろえ方、並行期間の置き方と障害対応の分担を扱います。開発会社の乗り換え全体の流れは システム引き継ぎの進め方 に、ソースコードを渡してもらえないときの考え方は システム開発の著作権は誰のもの？ にまとめています。
FIXIT保守に不満があるなら、作り直すのが早いんじゃないの？
Dodai早くはないです。作り直しは設計から移行まで時間がかかり、業務を止めるリスクも抱えます。
FIXITじゃあ、保守だけ移せば解決する？
Dodai不満の原因が体制にあるなら解決します。まず原因を切り分けます。
保守だけの引き継ぎが向くケース、作り直しを選ぶべきケース
最初に、不満の原因が「保守の体制」なのか「システムの作り」なのかを切り分けます。体制の問題は保守会社を替えれば改善しますが、作りの問題は誰が保守しても残ります。
| 判断軸 | 保守の引き継ぎが向く状態 | 作り直しを視野に入れる状態 |
|---|---|---|
| 不満の中身 | 返信が遅い、担当者がいない、単価が高い | 小さな改修でも影響範囲が広く、費用が毎回膨らむ |
| 業務との適合 | 今の業務フローに合っていて、画面の使い勝手も許容 | 業務が変わり、システムの外で表計算や手作業が増えている |
| 技術のサポート状況 | 言語・フレームワーク・OS にサポート期間が残る | 主要な技術がサポートを終え、脆弱性の修正が提供されない |
| ソースコードと権限 | コード一式と本番環境の管理権限を受け取れる | コードが入手できず、権利関係の整理にも時間がかかる |
| 今後 3〜5 年の改修の予定 | 小さな改修と日々の保守が中心 | 大きな機能追加や他システムとの連携が控えている |
技術のサポート状況は、公式の情報で確かめられます。たとえば PHP は Supported Versions で、各バージョンがリリースから 2 年間の通常のサポートと、その後 2 年間の重大なセキュリティ修正に限ったサポートを経て終了することと、その期限を公開しています。サポートを終えたバージョンの一覧 (Unsupported Branches) では、古いバージョンを使い続けると、新しいバージョンで修正済みの脆弱性やバグにさらされる可能性があるとして、更新を強く勧めています。他の言語やフレームワークも、多くは同じようにサポート期間を公開しています。
表の右側に当てはまる項目が多い場合は、保守を移しても費用がかさみ続けます。作り直しの進め方は システムリプレイスの進め方 を、全部作り直すか部分的に直すかの分岐は 技術的負債の返済戦略 を参照してください。どちらとも言い切れない場合は、次の現状調査の結果を見てから判断するのが確実です。
引き継ぎ先が最初に行う現状調査
保守の引き継ぎを相談すると、慎重な引き継ぎ先ほど、月額の見積もりを出す前に現状調査を求めます。調べないまま引き受けると、障害が起きたときに直せるかを保証できないからです。調査の対象は、主に次の 6 つです。
| 調査対象 | 何を確かめるか | 調査で見つかりやすいこと |
|---|---|---|
| ソースコード | 本番で動いているものと手元のコードが一致するか、ビルドして起動できるか | 本番だけに直接加えられた修正、手元にない設定ファイル |
| 依存ライブラリ | 言語・フレームワーク・ライブラリのバージョンと、サポート期限、既知の脆弱性 | 数年更新されていないライブラリ、開発を終えた部品 |
| インフラ構成 | サーバー・クラウド・DB・ドメイン・証明書の構成と、管理権限を誰が持つか | 旧保守会社名義のアカウント、期限が近い証明書 |
| 監視 | 障害を誰がどう検知しているか、通知がどこへ届くか | 監視がない、通知先が退職者や旧保守会社のアドレスのまま |
| バックアップ | 取得の頻度と保管先、実際に戻せるか | 取得はしているが、戻す手順を一度も試していない |
| 障害・問い合わせ | 過去の障害と対応内容、繰り返し起きている不具合 | 同じ不具合への場当たり的な対応が続いている |
バックアップと監視の要件を整理するときは、IPA の 非機能要求グレード が参考になります。非機能要求グレードは 2010 年に初版、2018 年に改訂版が公開された、機能以外の要求を発注者と開発者で確認するための項目一覧です (紹介ページは現在 IPA のアーカイブに置かれています)。どの時点のデータまで戻せればよいか (RPO、項目番号 A.1.3.1)、どれくらいの時間で復旧すればよいか (RTO、項目番号 A.1.3.2) といった項目が段階的なレベルで示されています。現状を調べたうえで、これらの項目を新しい保守契約の条件に落とし込むと、引き継ぎ後の発注者と保守会社の期待値がそろいます。
調査で見落としやすいのは、コードと本番の食い違いです。保守を長く続けたシステムでは、急ぎの修正が本番へ直接反映され、手元のコードに残っていないことがあります。これを知らずにコードから本番へ反映すると、過去に直したはずの不具合が戻ります。調査の段階で、本番と手元のコードを突き合わせておく必要があります。
仕様書がなく、コードからしか振る舞いが分からないシステムの調査は、仕様書のないレガシーを AI で読み解く で詳しく扱っています。
引き継ぎ資料のチェックリスト
現状調査と並行して、旧保守会社から受け取る資料と権限を集めます。ここでは、障害に対応し日々の保守を回すために必要なものに絞っています。開発会社を乗り換えるときに確保する資産の全体像は システム引き継ぎの進め方 の 7 つの資産を参照してください。資料がない項目は、ないこと自体を記録しておけば、引き継ぎ先が調査や資料作成の見積もりに反映できます。次のチェックリストを、依頼の前に発注者側で埋めてみてください。
1. ソースコードと開発環境
- 本番と一致する最新のソースコード一式 … 受領 / 未受領
- コードの管理場所 (リポジトリ) の管理者権限 … 受領 / 未受領
- ビルド・起動の手順と、必要な設定値の一覧 … 受領 / 未受領
2. 本番環境とアカウント
- サーバー・クラウドの管理者権限 (発注者名義か) … 確認 / 未確認
- ドメイン・SSL 証明書の管理権限と更新期限 … 確認 / 未確認
- DNS の設定内容と、変更できる管理画面の権限 … 確認 / 未確認
- データベースの接続情報 … 確認 / 未確認
- 外部サービス (メール送信・決済・地図など) の契約名義 … 確認 / 未確認
- 外部 API のキー・シークレットの一覧と保管場所 … 確認 / 未確認
- 業務で使う SaaS の管理者権限 … 確認 / 未確認
3. 設計と運用の資料
- システム構成図・データベースの設計 … 有 / 無
- 本番への反映手順 … 有 / 無
- 定期処理 (日次・月次のバッチなど) の一覧と実行時刻 … 有 / 無
4. 監視・バックアップ・障害対応
- 監視ツールのアカウントと、監視の設定内容・通知先 … 有 / 無
- バックアップの取得先と、復元手順 … 有 / 無
- 過去の障害・問い合わせの記録 … 有 / 無
- 障害時の緊急連絡先 (自社側・旧保守会社側) … 有 / 無
5. 契約
- 開発・保守の契約書 (成果物の範囲と権利の帰属) … 確認 / 未確認
- 保守契約の期間と解約の申し入れ期限 … 確認 / 未確認
- SLA (応答時間などの約束) と秘密保持契約の控え … 確認 / 未確認最優先は 1 と 2 です。設計資料がなくてもコードと権限があれば調査で補えますが、コードと権限が無ければ調査そのものを始められません。ドメイン、証明書、SaaS の管理者権限は、契約が終わると取り戻しにくくなるため、早い段階で受け渡しを依頼します。
パスワード、API キー、データベースの接続情報は、受け取った時点では旧保守会社も知っています。切り替えにあわせて再発行して古いものを無効にし、旧保守会社のアカウントとアクセス権は、契約を終える前に削除します。契約の雛形として、IPA は受託開発と保守運用のモデル契約を収めた 情報システム・モデル取引・契約書 (第二版) を公開しています。成果物の範囲や権利の考え方を確認するときの比較材料になります。
並行期間を置いて切り替える
旧保守会社の契約を終える日と、新しい会社が保守を始める日を同じにすると、問題が起きたときに頼れる相手がいなくなります。両社が同時に関わる並行期間を置き、新しい会社が単独で保守を回せることを確かめてから切り替えます。
flowchart LR
A[資料と権限の確保] --> B[現状調査]
B --> C[並行期間]
C --> D{切り替え判定}
D -- 条件を満たす --> E[新しい会社で単独保守]
D -- 未達の項目あり --> C並行期間では、次の 3 つを新しい会社が実際にやり切ることを切り替えの条件にします。
- 軽微な修正を 1 件行い、テストを通して本番へ反映する
- 監視の通知を新しい会社で受け取り、アラートへの一次対応を行う
- バックアップからの復元を、本番とは別の環境で一度試す
期間の長さは、そのシステムで起きる定期業務から決めます。月末の締め処理があるなら月末を、年度末の集計があるならその時期を、一度は並行期間のなかで経験しておくと安心です。一律の日数ではなく、「どの業務を一周させるか」で決めてください。
引き継ぎ全体の期間も同じで、システムの規模、資料と権限のそろい具合、本番環境をすぐ引き渡してもらえるか、旧保守会社がどこまで協力するか、定期業務の周期で変わります。全体の日数をまとめて見込まず、資産の確保、現状調査、並行期間、切り替えの段階ごとに見積もってもらってください。
並行期間中の旧保守会社の対応は、通常の保守契約の範囲外になることがあります。問い合わせへの回答や立ち会いを有償で依頼するかどうかと、その費用と範囲を事前に取り決めておくと、期間の途中で協力が止まる事態を避けられます。
FIXIT並行期間って、保守費を二重に払うことになるよね？
Dodaiなります。ただ、並行期間なしで切り替えて障害が出るほうが高くつきます。
FIXITどこまで確かめたら、もう切り替えていいの？
Dodai本番への反映、アラート対応、バックアップからの復元の 3 つです。
並行期間中に障害が起きたときの分担
並行期間に障害が起きると、両社がそれぞれ相手が動くと考えて初動が遅れることがあります。並行期間を前半と後半に分け、役割ごとに誰が持つかを事前に決めておきます。分け方の一例は次のとおりです。
| 役割 | 前半 (旧保守会社が主) | 後半 (新しい会社が主) |
|---|---|---|
| 一次対応 | 旧保守会社。新しい会社は通知を受けて立ち会う | 新しい会社。旧保守会社は問い合わせに答えられるよう待機 |
| 原因調査 | 旧保守会社が行い、新しい会社が手順を記録する | 新しい会社が行い、不明点を旧保守会社に確認する |
| 本番へ反映するかの判断 | 旧保守会社の提案を受けて、発注者が決める | 新しい会社の提案を受けて、発注者が決める |
前半から後半へ移る時点は、日付ではなく「旧保守会社の一次対応に立ち会い、その手順を新しい会社が記録にまとめ終えた」のような条件で決めます。あわせて、障害の連絡を最初に受ける窓口、どちらの会社へどの順で連絡するか、発注者側で判断する人と不在時の代わりを文書にし、3 者で共有してから並行期間に入ります。
切り替えたあとに確認すること
旧保守会社との契約を終えたら、次の 4 つが済んでいるかを確かめます。
- サーバー、クラウド、リポジトリ、監視ツール、SaaS から、旧保守会社のアカウントとアクセス権を削除した
- 旧保守会社が知っていたパスワードや API キーの再発行を終え、古いものを無効にした
- 新しい会社が、問い合わせや障害に契約で約束した応答時間どおりに対応している
- 現状調査で作った資料と引き継ぎ資料を、切り替え後の構成と担当に合わせて更新した
応答時間は、切り替え直後の問い合わせや障害の記録で確かめます。約束と実際がずれていれば、同じ不満が繰り返される前に新しい会社と条件を見直してください。
保守費用の構成要素 ─ 固定の保守契約と都度対応の違い
保守会社を替えるときに比べたいのが費用ですが、月額の数字だけを並べても比較になりません。保守費用は、契約の建て方と対応範囲で中身が変わるためです。保守費の相場観や SLA と費用の関係は 開発後の保守・運用・追加開発の見積 で整理しているので、ここでは引き継ぎのときに確認したい構成の違いに絞ります。
| 契約の建て方 | 中身 | 向いている状態 |
|---|---|---|
| 固定の保守契約 | 月額で、監視・障害対応・ライブラリ更新などの定常作業と体制を確保 | 業務で毎日使い、止まると困る。問い合わせが定期的 |
| 都度対応 (スポット) | 依頼のたびに見積もり、作業した分だけ支払う | 利用頻度が低く、止まっても数日は業務が回る |
| 組み合わせ | 監視と障害の一次対応は固定、改修や調査は都度見積もり | 定常の保守は小さいが、改修の依頼が不定期に発生する |
引き継ぎでは、このほかに一度だけ発生する費用があります。現状調査、資料の作成や整備、並行期間の二重の保守費用、そして必要なら旧保守会社への引き継ぎ協力の費用です。これらの費用は、資料がどれだけ残っているか、本番環境をすぐ引き渡してもらえるか、システムの規模と複雑さで増減します。月額が今より下がっても、これらを含めた総額で比べないと判断を誤ります。
見積もりを比較するときは、現在の契約で月額に含まれている作業と、都度見積もりになっている作業を書き出し、同じ条件で依頼してください。不満の原因が応答の遅さなら、何時間以内に誰が動くかを条件に入れておかないと、乗り換えても同じ不満が残ります。
引き継ぎを断られやすいシステムの特徴と、その場合の選択肢
保守の引き継ぎを相談しても、受け手が見つからないことがあります。断られやすいシステムには共通する特徴があり、特徴ごとに打てる手も変わります。
| 断られやすい特徴 | 理由 | 取れる選択肢 |
|---|---|---|
| ソースコードがない、または最新か分からない | 障害時に原因を調べられず、修正も反映できない | 契約を確認してコードを回収する。回収できなければ作り直しを検討 |
| 本番環境の管理権限を発注者が持っていない | 調査も保守作業も始められない | 名義変更か、発注者名義の新しい環境への移設を先に行う |
| 主要な技術のサポートが終わっている | 修正が提供されないため、引き受ける会社が限られる | 保守を続けながら、サポートの切れた部分から段階的に置き換える |
| 独自に作られた部品が多く、知る人がいない | 調査の工数が読めず、保守の範囲を約束できない | 保守契約の前に、現状調査だけを先に依頼して範囲を確定させる |
| 旧保守会社の協力が得られない、連絡が取れない | 資料や権限を受け取れず、本番の状態が分からない | 受け取れる権限と資料から順に回収し、足りない部分は調査で補う |
特徴が複数重なっていても、すぐに作り直しを決める必要はありません。現状調査だけを独立した依頼にすれば、どこまで保守できて、どこから作り直しが必要かが分かります。コードを渡してもらえない問題の扱い方は システム開発の著作権は誰のもの？ を、作り直しになった場合の費用感は レガシー刷新の費用と期間 を参照してください。
要点
断られたときは、理由を具体的に聞いてください。「コードが最新か分からない」「管理権限がない」など不足している項目が分かれば、その項目を埋めてから再び相談できます。
保守会社から終了を告げられたとき、連絡が取れなくなったとき
保守会社の廃業や担当者の退職で、保守の打ち切りを告げられることがあります。このときに最優先で受け取るのは、管理権限、ソースコード、アカウント、障害履歴です。契約が終わると相手に協力する理由がなくなり、名義変更や資料の受け渡しが進みにくくなります。
次に、並行期間を置けるよう、終了時期を延ばせないか交渉します。引き受け先を探す時間と、引き受け先が保守に慣れる時間の両方が必要だからです。延長が難しくても、資料と権限の受け渡しを終える日だけは先に合意しておきます。
引き受け先が決まる前でも、現状調査だけを先に依頼できます。調査で本番の状態と不足している資料が分かれば、引き受け先を探すときに条件を具体的に伝えられます。すでに連絡が取れない場合は、手元の権限で入れる範囲から回収し、足りない部分を調査で補います。
ここで扱うのは、稼働しているシステムの保守の担い手がいなくなった場合です。開発の途中で開発会社と連絡が取れなくなった場合は、システム開発の失敗から立て直す を参照してください。
FIXIT の運用 ─ 保守の引き継ぎでは、並行期間の切り替え条件まで決める
FIXIT は AI 駆動開発のクリエイティブスタジオとして、他社が作ったシステムの保守の引き継ぎをお受けしています。保守を引き継ぐ相談では、いきなり月額の保守契約を結ぶことはせず、まず手元にあるコード・権限・資料を伺い、現状調査の範囲を決めます。
調査では、コードの読み解きや依存ライブラリの洗い出しに AI を使い、人が確認すべき箇所を早く絞り込みます。一方で、本番の構成が正しいか、業務上その処理がいまも必要かといった判断は、人が環境と業務を確かめて決めます。調査の結果をもとに、保守を引き継ぐ、一部を作り直す、全体を作り直す、のどれが妥当かを整理します。引き継ぐ場合は、並行期間に新しい会社が何をやり切れば切り替えてよいか、旧保守会社に何を依頼するかまで決めることを、調査の目的にしています。
保守をどこへ移すにしても、最初の一歩は、手元にあるものを把握することです。本記事のチェックリストで、ソースコードと本番環境の権限が発注者の手元にあるかを確かめてください。この 2 つがそろっていれば、保守の引き継ぎを検討する前提が整います。
そろっていない項目がある場合、保守を移すか作り直すかで迷っている場合、保守会社から終了を告げられて引き受け先を探している場合は、お問い合わせ から現状をお聞かせください。手元の資料と権限の状況を伺い、現状調査の進め方をご提案します。作り直しまで視野に入れる場合は システム刷新・リプレイス もあわせてご覧ください。