他社開発システムの保守引き継ぎ｜確認すべき5つのポイントと成功の秘訣

保守引き継ぎが必要になる3つのパターン

システム保守の引き継ぎが発生する場面は、主に3つあります。

開発会社への不満

対応が遅い、費用が高い、コミュニケーションが取りにくい。こうした不満が蓄積して、保守会社の変更を検討するケースです。最も多いパターンですが、引き継ぎの準備をしっかり行えば、スムーズに移行できます。開発会社を変更する際の具体的な手順と注意点は「開発会社を変更するときの手順と注意点」で解説しています。

開発会社の廃業・担当者の退職

開発会社が廃業した、またはキーパーソンが退職して対応品質が著しく低下した場合です（開発会社が倒産した場合の緊急対応も参照）。このパターンは緊急性が高く、事前準備が十分にできないケースが多いため、引き継ぎのハードルが上がります。

コスト最適化

現在の保守費用が市場相場より高い、または保守の対応範囲に対して費用が見合っていないと感じた場合です。相見積もりを取った結果、より良い条件の保守会社に乗り換えるパターンです。

ポイント1: ドキュメントの有無と品質

引き継ぎの難易度を最も左右するのがドキュメントの存在です。

最低限必要なドキュメント

• システム構成図: サーバー、データベース、外部サービスの構成
• 環境情報: 本番・ステージング・開発環境の接続情報
• デプロイ手順: コードの反映方法
• アカウント情報: 各サービスのログイン情報

ドキュメントがない場合

中小企業のシステムでは、ドキュメントがほぼ存在しないケースも珍しくありません。その場合は、ソースコードの解析からスタートし、保守会社側でドキュメントを新規作成します。初期費用は増えますが、この投資は今後の保守効率を大幅に向上させます。なお、引き継ぎ後に自社で揃えておくべきドキュメントの種類や整備の進め方は「システム保守に必要なドキュメント一覧と整備方法｜発注者が揃えておくべき資料と管理のコツ」にまとめています。

ポイント2: ソースコードの管理状況

ソースコードへのアクセスは引き継ぎの大前提です。

確認すべき項目

特に重要なのはソースコードの所有権です。契約上、ソースコードの著作権が開発会社に帰属している場合、引き渡しを拒否されるリスクがあります。契約書を確認し、必要であれば法的な対応を検討してください。

ポイント3: インフラ構成の把握

システムがどこで、どのように動いているかを正確に把握する必要があります。

確認すべきインフラ情報

• ホスティング: AWS、GCP、さくら、ConoHa等のサービスとプラン
• ドメイン管理: DNS設定、SSL証明書の管理者
• データベース: 種類（MySQL, PostgreSQL等）、バックアップの有無
• 外部サービス: メール配信、決済、API連携先のアカウント情報
• 監視: 既存の監視設定があるか

インフラのアカウント情報が前任の開発会社の個人メールに紐づいている場合、引き継ぎ後にアクセスできなくなるリスクがあります。自社のメールアドレスに変更することを最優先で行いましょう。

ポイント4: 契約上の注意点

前任との契約終了時に確認すること

• 解約通知の期限を守っているか
• 引き継ぎ期間中の保守責任はどちらにあるか
• ソースコードの引き渡し義務はあるか
• 秘密保持義務の範囲

新しい保守会社との契約で確認すること

• 引き継ぎ期間の費用（初期調査費用）
• 引き継ぎ完了の定義（何をもって引き継ぎ完了とするか）
• 保守開始後の対応範囲

前任と新任の保守期間が重複する「並行稼働期間」を設けることをお勧めします。新しい保守契約を結ぶ際の注意点もあわせて確認しましょう。1〜2ヶ月の並行期間があれば、引き継ぎ漏れがあっても前任に確認できます。

システム保守打ち切りの通知を受けたら、期限までに何をすればよいか

FUNBREWでは、保守打ち切りの通知を受けた発注者に対し、期限までに①ソースコード・サーバー・ドメインなどのアクセス権の確認、②直近の障害・不具合の記録の引き継ぎ、③新しい保守会社との並行稼働期間の確保、の3点を優先するようお伝えしています。とくに①のアクセス権が揃っていないと、期限内に次の保守会社が決まっても着手できないため、通知を受けたらまず確認すべき項目です。具体的な確認項目は上記の「ポイント2: ソースコードの管理状況」「ポイント3: インフラ構成の把握」で解説している内容と同じです。

ポイント5: 引き継ぎスケジュールの目安

急いで引き継ぎを行うと、見落としが発生しやすくなります。特にドキュメントがない場合は、初期調査に十分な時間を確保することが重要です。

FUNBREWが引き継ぐときの実際の流れと期間

FUNBREWが他社の作ったシステムを引き継ぐときは、まず調査から入ります。全体の流れは次のとおりです。

サーバー移行をしないなら、調査がいちばん大きい

サーバーの移行を伴わない引き継ぎでは、工程の中で調査の部分がいちばん大きくなります。現在の担当者からマニュアルをもらい、ヒアリングをして、システムの使われ方と中身を引き継ぎます。資料が揃っていない場合の進め方はシステム引き継ぎで用意する資料は何かに書きました。

期間は、早ければ1ヶ月、リプレース込みなら1年以上

引き継ぎにかかる期間は、正直なところ案件によってまちまちです。早ければ1ヶ月で終わることもあれば、リプレース（作り直し）も込みであれば1年以上かかることもあります。上の目安表は保守会社を切り替えるだけの場合の目安で、システムの状態や作り直しの有無によって大きく変わります。調査を省いて見積もりが甘くなった例は引き継ぎの見積もりが甘くなるのはどんなときかをご覧ください。

まとめ

システム保守の引き継ぎは、事前の確認と準備が成功の鍵です。ドキュメント・ソースコード・インフラ・契約・スケジュールの5つのポイントを押さえれば、リスクを最小限に抑えた移行が可能です。

「今の保守会社に不満がある」「開発会社と連絡が取れなくなった」など、保守の引き継ぎを検討している方は、まずは現状の整理から始めてみてください。

FUNBREWの保守サービスでは、引き継ぎから安定運用まで一貫して対応しています。お問い合わせはこちらから。

複数社が関わっているシステムを引き継ぐ場合の責任の切り分けは、複数の開発会社が1つのシステムに関わるときもあわせてご覧ください。