システムを本番稼働させた後、「何かトラブルがあったとき、誰が対応してくれるのか」という不安を持つ担当者は少なくありません。開発が完了しても、システムは運用・保守なしには安定して動き続けません。特に自社にITエンジニアがいない場合や、開発チームを保守に割けない場合は、外注先への委託が現実的な選択肢になります。
しかし、外注先選びを誤ると深刻な問題が起きます。「保守込みのはずが、実は軽微な修正も別料金だった」「担当者が退職してシステムの中身が誰も分からなくなった」「乗り換えたくてもデータを渡してもらえず身動きが取れない」——こうした事例は決して珍しくありません。
この記事では、保守運用の外注先を選ぶ際に確認すべき5つの基準と、ヒアリング時に使える実践的なチェックリストを解説します。外注化の検討を始めたばかりの方から、現在の委託先に問題を感じている方まで、判断の軸を持てるようになることを目指しています。
なお、保守と運用の違いや業務内容の詳細については、システムの保守と運用の違いとは？業務内容の違いを徹底解説をご覧ください。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
保守運用の外注先には3つのタイプがある
外注先を探し始めると、さまざまな会社や個人が選択肢として出てきます。まず大きく3つのタイプに分けて理解しておくことが重要です。タイプによって強みとリスクが異なるため、自社の状況に合ったタイプを選ぶことが選定の第一歩です。
開発会社（受託開発会社）
システムを最初から開発した会社、またはシステム開発を得意とする受託開発会社が保守・運用も担当するパターンです。システムの構造や仕様を把握しているため、障害発生時の原因究明が早く、コミュニケーションコストが低い点がメリットです。
一方、開発は得意でも継続的な監視・運用業務が不得手な会社もあります。「24時間365日の対応体制があるか」「専任の保守担当者がいるか」を事前に確認することが重要です。
MSP（マネージドサービスプロバイダ）
システムの保守・監視・運用を専門に行う会社です。24時間365日の監視体制を持ち、障害対応・アップデート・セキュリティ対策を一任できます。対応品質やSLAが明確に定義されていることが多く、スケールしやすいのが強みです。
コストが高めで、システム固有の事情を把握するまでに時間がかかる点がデメリットです。既存システムの構造が複雑な場合、引き継ぎコストも発生します。
フリーランス・個人エンジニア
単価が低く柔軟に動けるため、小規模なシステムや予算が限られたケースには有効です。しかし、担当者が退職・独立した場合の属人化リスクや、24時間対応が難しいケース、緊急時のリソース不足という課題があります。重要度の高いシステムの保守を個人に一任することは、継続性の観点からリスクを伴います。
保守運用の外注先を選ぶ5つの基準
外注先のタイプを理解した上で、実際に選定する際に確認すべき5つの基準を紹介します。各基準には「なぜ重要か」を示す失敗パターンも合わせて解説します。
1. 対応範囲と対応時間を文書で確認する
最も重要で、かつ最も見落とされやすい確認事項です。「保守・運用込み」という合意をしていても、契約書・仕様書に業務範囲が明記されていなければ認識のずれが生じます。
確認すべき具体的な範囲は以下のとおりです。
- サーバー・インフラの監視
- ログ確認・異常検知
- 不具合修正・バグ対応（件数上限があるか）
- セキュリティアップデート・パッチ対応
- ミドルウェア・ライブラリのバージョンアップ
- 機能改善・追加開発（別料金か否か）
対応時間については、24時間365日対応か、平日日中のみかを明確にします。業務システムや自社サービスであれば、休日・夜間の障害対応が発生する可能性を考慮する必要があります。
失敗パターン： 「保守込み」のはずが、実際には「監視のみ」で修正作業は都度追加料金となっていた。月次で発生する費用が当初の想定を大幅に超えた。
2. SLAの内容と違反時の対応を確認する
SLA（Service Level Agreement）とは、提供されるサービスの品質を数値で約束する取り決めのことです。稼働率・障害対応の応答時間・復旧時間（RTO）などが定義されます。
確認すべき主なSLA項目は以下です。
- システム稼働率（例：99.9%以上）
- 障害発生時の一次応答時間（例：1時間以内）
- 復旧対応完了の目標時間（例：翌営業日まで）
- 計画外メンテナンス時の事前通知ルール
SLAそのものの存在だけでなく、違反した場合のペナルティ条項があるかを必ず確認してください。「可能な限り対応する」「最善を尽くす」という記述だけでは実効性がありません。料金の減額規定や違約金条項がある契約を選ぶことで、サービス品質の担保につながります。
失敗パターン： SLAに「稼働率99%」と記載があったが、未達時の対応は「次回更新時の料金交渉の材料にできる」程度で、実質的なペナルティがなかった。
3. 実績・技術スタックの適合性を確認する
自社システムと同じ技術スタックの保守経験があるかどうかは、対応品質に直結します。例えばNode.js + PostgreSQLで構築されたシステムを、Javaが得意な会社に委託すると、障害対応や改修の品質が下がるリスクがあります。
確認すべき点は以下です。
- 自社システムの技術スタック（言語・フレームワーク・インフラ）での保守実績があるか
- 同規模・同業種のシステムを担当した経験があるか
- 具体的な事例として参照できるものがあるか
- 担当者と直接話す機会を設けてもらえるか
「実績あり」という回答に対して、具体的な内容（システム規模・技術・期間）を確認できるかが重要です。詳細を出せない会社は、実態が不明のまま委託することになります。
失敗パターン： 営業担当者が「同様の経験があります」と答えたが、実際の担当者は初めてのフレームワークで試行錯誤が続き、障害対応のたびに調査に時間がかかった。
4. 引き継ぎ・情報共有の仕組みがあるか確認する
外注先のシステムに対する理解が深まるほど、情報が外注先に集中し、自社では状況を把握できなくなるリスクがあります。これが「ブラックボックス化」です。担当者の退職・会社の廃業・契約解除時に、誰もシステムの中身を把握していないという状態は、ビジネス継続性の観点から深刻です。
確認すべき情報共有の仕組みは以下です。
- ドキュメント（設計書・構成図・手順書）の最新化と共有
- ソースコードの管理方法（自社が常にアクセスできる状態か）
- 定例ミーティング・月次報告の有無
- 担当者変更時の引き継ぎ手順
契約終了時に「ソースコード・データ・ドキュメント一式を返却する義務」が契約に含まれているかも重要な確認ポイントです。
失敗パターン： 担当エンジニアが退職し、誰もシステムの設定変更方法を知らなくなった。外注先への問い合わせを繰り返すしかなく、簡単な変更にも数週間かかるようになった。
5. 契約形態と途中解約のルールを確認する
保守運用の契約形態は大きく2種類あります。自社の状況に合った形態を選ぶことで、コストと柔軟性のバランスをとれます。
月額固定型（定額制）： 月々一定額で定められた業務を提供する形態です。対応内容が安定していて予算管理がしやすい反面、利用が少ない月も同額が発生します。月額20〜50万円程度が一般的な相場です。
従量課金型： 実際に発生した作業量・時間に応じて費用が発生する形態です。突発的な作業が少なく、コスト予測が難しいシステムに向いています。
どちらの形態でも、以下を契約前に確認してください。
- 最低契約期間（3ヶ月・6ヶ月・1年など）
- 解約予告の必要期間（30日前・60日前など）
- 解約時のデータ・ソースコードの引き渡し義務と形式
- 追加作業が発生した場合の単価・請求ルール
失敗パターン： 別の会社に乗り換えようとしたが、解約には3ヶ月の予告が必要だった上に、データ引き渡しの義務が契約に含まれておらず、新しい委託先への移行作業が困難になった。
外注前に確認すべき選定チェックリスト
以下のチェックリストは、外注先候補にヒアリングを行う際に活用してください。すべての項目に明確な回答が得られる会社が、信頼性の高い外注先の目安です。
対応範囲と体制
- 対応業務の範囲（監視・修正・バージョンアップ等）が契約書・仕様書に明記されているか
- 24時間対応か、対応可能な時間帯が明確か
- 障害発生時のエスカレーション先・連絡フローが決まっているか
SLA・品質保証
- SLAが稼働率・応答時間・復旧時間として数値で定義されているか
- SLA未達時のペナルティ条項（料金減額・違約金等）が含まれているか
実績・担当者
- 自社システムの技術スタックでの保守実績が確認できるか
- 担当者と事前に直接話せる機会があるか
- 参照できる具体的な事例（規模・技術・期間）があるか
情報共有・引き継ぎ
- ドキュメント・ソースコードを自社がいつでもアクセスできる状態か
- 担当者変更時の引き継ぎ手順が明確か
- 月次報告・定例ミーティングの仕組みがあるか
契約条件
- 最低契約期間・解約予告期間が明確か
- 解約時にデータ・ソースコードを返却する義務が契約に含まれているか
- 追加作業の単価・請求ルールが契約に含まれているか
保守運用の費用相場と契約形態の目安
保守運用費用の一般的な目安は、システム開発費の5〜15%／年です。例えば開発費用が500万円のシステムであれば、年間25〜75万円（月額2〜6万円）が目安になります。ただし、24時間365日対応・専任担当者のアサイン・複雑な技術スタックなどの条件が加わると、費用は上昇します。
相場より大幅に安い場合は、業務範囲が限定的（監視のみ、対応時間が平日日中のみ等）な可能性があります。見積もりを受け取ったら、どこまでが含まれているかを必ず確認してください。
費用相場の算出方法や内訳については、システム保守費用の妥当性を見極める！相場と算出方法の完全ガイドで詳しく解説しています。
まとめ：外注先選びで最も重要なポイント
保守運用の外注先を選ぶ際に、最も重要なのは「対応範囲の文書化」です。SLAの不備・ブラックボックス化・ベンダーロックイン——これらの問題の多くは、最初の契約時点で対応範囲が曖昧だったことが原因です。
- 対応業務の範囲を文書で明確にする
- SLAを数値で定義し、違反時のペナルティ条項を入れる
- 情報共有・引き継ぎの仕組みを契約に含める
- 解約時のデータ返却義務を確認する
これらを入念に確認した上で外注先を選ぶことが、長期的に安定した保守運用体制を構築する基盤になります。
秋霜堂株式会社のTechBandは、システム開発後の保守・運用を継続的にサポートするサービスです。担当者が変わらず、ドキュメント管理・月次報告・24時間の緊急対応体制を含む透明性の高い保守運用を提供しています。保守運用の外注先をお探しの方は、まずは無料相談からお気軽にお問い合わせください。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
