保守契約を切り替える前に確認すべき技術論点
「今の保守会社の対応が遅い」「障害のたびに原因説明がなく再発する」「毎月の保守費用に見合う仕事をしている実感がない」——保守契約の切り替えを検討する理由の多くはこの3つに集約されます。ただし、いざ切り替えようとすると「技術的に何を確認すればいいか分からないまま、なんとなく不安」という状態で止まってしまう発注者が少なくありません。
保守契約の切り替えは、開発会社そのものを変更する場合（要件定義から作り直すような大きな移管）とは性質が異なります。すでに動いているプロダクトの運用を、止めずに、事故なく引き継ぐという一点に技術論点が集中します。この記事では、切替でつまずきやすい技術論点、契約面の確認事項、切替前チェックリスト、新しい保守先の見極め方を整理します。
切替でつまずく技術論点
1. アクセス権限の所在
保守運用に必要な権限が「旧保守会社の個人アカウント」に紐づいていないかをまず確認します。
- 本番サーバーへのSSH鍵・踏み台サーバーのアカウントが誰名義か
- クラウド（AWS/GCP等）のIAMユーザーが会社共有アカウントか、担当者個人のアカウントか
- ドメイン・DNS管理画面（お名前.com、Route53等）のログイン情報を発注者側が把握しているか
- SSL証明書の更新権限・自動更新の仕組みがどこにあるか
これらが発注者名義のアカウントに紐づいていない場合、旧保守会社との関係が悪化した状態で切り替えると、権限を取り戻すだけで数週間かかることがあります。切替を決めたら、まず「発注者が全アカウントの管理者権限を持っているか」を洗い出すのが最初の一手です。
2. インフラの所有権とアカウント名義
サーバー・クラウドサービスの契約者が誰かも重要な論点です。
- AWS/GCPのアカウント自体が旧保守会社名義で契約されている場合、解約と同時にインフラごと消える可能性がある
- ドメイン・SSL証明書・外部API（決済、メール配信、地図等）の契約者名義が発注者かベンダーか
- 費用の請求が発注者に直接来ているか、ベンダー経由で再請求されているか（後者は名義がベンダー側にあるサイン）
インフラがベンダー名義のままだと、切替は「引き継ぎ」ではなく「新規移設」相当の作業になり、想定より工数と費用がかさみます。契約前にクラウドの請求書名義を確認するだけで、この論点はほぼ判定できます。
3. デプロイ手順の再現性
新しい保守先が最初にぶつかる壁がここです。
- デプロイがコード化（CI/CDやCapistrano等）されているか、担当者が手順書もなく手動で行っているか
- デプロイ手順書が存在しても、実際に新しい担当者がそれだけで再現できるか（環境変数、シークレット、ミドルウェアのバージョンまで書かれているか）
- ロールバック手順が確立しているか
「デプロイは前任者の頭の中にしかない」状態で保守先を切り替えると、切替直後の最初のリリースで事故が起きやすくなります。旧保守会社に実際にデプロイを1回見せてもらう、あるいは手順書通りに新保守先が試せる期間を並走期間中に確保できるかが分かれ目です。
4. 監視・オンコール体制の引き継ぎ
障害対応の実効性を決めるのがここです。
- 死活監視・エラー監視（New Relic、Sentry等）が誰のアカウントで、誰に通知が飛んでいるか
- 障害発生時の一次対応者と連絡フローが文書化されているか、口頭の暗黙知か
- ログの保管場所・保管期間（アプリログ、アクセスログ、DBのスロークエリログ等）と、新保守先がアクセスできるか
監視ツールの通知先が旧保守会社の個人メール・Slackのままだと、切替後に障害が起きても誰にも気づかれない空白期間が生まれます。切替日に監視の通知先を新体制へ切り替える作業は、意外と見落とされがちなので明示的にタスク化すべきです。
5. ナレッジ（暗黙知）の引き継ぎ
コードやインフラの設定は引き継げても、「なぜこうなっているか」という経緯は文書化されていないことがほとんどです。
- 一見不自然なコード・設定（例外的な条件分岐、特定顧客向けの特別処理）の背景
- 過去に起きた障害とその対応履歴、再発防止策
- 「触ると危険な箇所」の暗黙知（本CLAUDE.mdでいう地雷情報に相当するもの）
これは並走期間中に旧保守会社へのヒアリングセッションを設けて言語化してもらう以外に確実な引き継ぎ方法がありません。文書だけを受け取って終わりにすると、切替後数ヶ月してから「なぜこの処理があるか誰も分からない」状態のコードに当たります。
契約面で確認すべきこと
技術論点と並行して、契約上も詰めておくべき点があります。
- 解約予告期間: 保守契約は「解約の何ヶ月前に通知が必要か」が定められていることが多い。切替スケジュールはこの予告期間を起点に逆算する
- データ引き渡しの範囲と形式: ソースコード一式・DBダンプ・設定ファイル・ドキュメントを、どの形式でいつまでに渡してもらえるか契約書または解約合意書に明記する
- 並走期間の設定: 旧保守会社と新保守会社が一定期間重複して稼働できるよう交渉できるか。並走がゼロだと、上記の暗黙知やデプロイ手順の引き継ぎが実質不可能になる
- 切替直後の障害対応の責任分界: 切替直後に旧環境由来の不具合が出た場合、誰がどこまで対応する契約になっているかを事前に握る
円満な関係のまま切り替えられるなら理想ですが、そうでない場合ほどこれらの契約条項が引き継ぎの成否を左右します。
切替前チェックリスト
実際に着手する前に、以下を発注者自身で（または新保守先と一緒に）確認してください。
- 本番サーバー・クラウドの管理者権限を発注者アカウントで持っているか
- ドメイン・SSL証明書・主要な外部API契約の名義が発注者になっているか
- デプロイ手順が文書化され、実際に再現できることを確認したか
- 監視・アラートの通知先リストを把握しているか
- 障害対応履歴・暗黙知のヒアリング機会を並走期間中に確保したか
- 解約予告期間とデータ引き渡し条件を契約書で確認したか
- ソースコード・DBダンプ・設定ファイル一式のバックアップを発注者側でも取得したか
このリストが全部埋まらない状態で見切り発車すると、切替直後の1〜2ヶ月で障害対応が遅れる、あるいは誰も対応できない期間が生まれるリスクが高くなります。
新しい保守先の見極め方
切替先を選ぶ際は、開発力だけでなく「運用を任せられるか」を見ます。
- 初回の技術ヒアリングで、上記のような論点（権限・デプロイ・監視・暗黙知）を向こうから質問してくるか。聞かれないまま見積もりだけ出してくる会社は、引き継ぎの解像度が低い可能性がある
- 障害対応の一次窓口・対応時間帯（平日日中のみか、オンコール対応があるか）が発注者の事業要件と合っているか
- 保守費用の内訳（監視・軽微な修正・問い合わせ対応・定期アップグレードのどこまでが含まれるか）が明確か
見積もりの金額だけで比較すると、切替後に「思っていたより対応範囲が狭かった」というギャップが起きやすい領域です。
既存プロダクトの改善に着手する前に確認すべき観点はこちらの記事でも整理しています。また、保守運用先を変えるのではなく開発会社そのものを変更する場合の論点は開発会社を変更するときの引き継ぎチェックリスト、切替を検討する背景としてよくある「保守品質への不満」については外注保守の品質問題も参考にしてください。
まとめ
- 保守契約の切替は「権限・インフラ所有権・デプロイ手順・監視体制・暗黙知」の5点が発注者名義／再現可能な状態になっているかで成否が決まる
- 解約予告期間・データ引き渡し・並走期間は契約面で事前に握っておかないと、技術的な引き継ぎ自体が物理的に不可能になる
- 新しい保守先を選ぶ際は、見積もり金額より「引き継ぎの論点を向こうから聞いてくるか」を見極めの基準にする
torcheeesでは、保守契約の切替に伴う技術診断（現状の権限・インフラ所有権・デプロイ再現性の棚卸し）と、切替後の継続的な改善支援を行っています。今の保守体制に不安がある方は、お問い合わせフォームからご相談ください。切替のタイミング相談だけでも構いません。保守サービスの詳細は保守運用サービスページをご覧ください。