保守運用を外注したい時の選び方（納品後に困らない契約の作り方）

保守運用の外注で「納品後に困る」典型パターン

システムを納品してもらった直後は動いていても、数ヶ月後に「誰に何を頼めばいいのか分からない」「軽微な修正のはずが見積が高い」「障害が起きたのに原因が追えない」といった相談が増えます。これは担当者の能力不足というより、外注の設計（体制・役割・契約・情報の残し方）が曖昧なままスタートしてしまうことが主因です。

よくあるのが、開発会社に「保守もお願いします」と口頭で伝えただけで、実際には保守運用の範囲（どこまでが月額で、どこからが追加費用か）が定義されていないケースです。例えば、サーバの監視は入っているが、OSやミドルウェアのアップデート対応は含まれていない。問い合わせ対応はするが、調査の工数は別。こうした“抜け”は、トラブル時に初めて顕在化します。

また、納品物としてアプリやソースコードは受け取っていても、運用に必要な情報（環境構成、アカウント、監視設定、バックアップ、復旧手順、障害対応手順、連絡網など）が残っていないことも多いです。結果として、別のベンダーに引き継ぎたくても引き継げず、ベンダーロック（特定会社に依存して身動きが取れない状態）になります。

この記事では、ITに詳しくない立場でも判断できるように、外注先の選び方と、納品後に困らない契約・運用の作り方を実務レベルで整理します。

外注前に決めておくべき「保守」と「運用」の線引き

保守運用と一言で言っても、中身は幅広いです。最初にやるべきことは、依頼したい内容を「やることの種類」で分解し、重要度と頻度で整理することです。専門知識がなくても、業務シーンに落とすと判断しやすくなります。

運用は「日々の安定稼働のための作業」です。例として、監視（死活監視・エラー監視）、障害一次対応、バックアップ確認、アカウント発行、定例レポート、問い合わせ受付などがあります。保守は「壊れた・変えたい時の対応」です。例として、障害調査・修正、脆弱性対応、OSやライブラリ更新、軽微な改修、仕様変更の影響調査、性能改善などです。

ここでポイントは、「月額に含めたい作業」と「都度見積でもよい作業」を分けることです。例えば、問い合わせ窓口と障害一次対応は月額、機能追加は都度見積、という分け方は現実的です。一方で、セキュリティパッチ適用や証明書更新など、時期が読めないが必ず発生するものは、“含めない”と運用が止まりやすい領域です。最低限どこまでを月額で担保するかを決めておくと、後の交渉がスムーズになります。

加えて、システムの重要度に応じて「止まったら困る度」を言語化しておきましょう。ECや予約のように売上に直結するなら、夜間や休日も含めた対応が必要かもしれません。社内向けの申請システムなら、平日日中だけでも許容できる場合があります。必要以上に手厚い契約はコスト増になりますし、薄すぎる契約は事故につながります。最適化のために、優先順位を最初に置くのがコツです。

外注先を選ぶときに見るべきポイント（技術より「運用設計」）

開発に詳しくない読者ほど「有名な会社」「安い」「早い」で選びがちですが、保守運用では日々のコミュニケーションと体制設計が成果を左右します。選定では、技術スタックの一致よりも「運用の型」を持っているかを見てください。

確認したいのは、まず窓口と責任の所在です。問い合わせは誰が受け、一次切り分けは誰が行い、必要なら誰が二次対応するのか。属人化していないか。担当者が休んでも回るか。“担当者が優秀”より“担当者が変わっても回る仕組み”が重要です。

次に、情報管理と引き継ぎ能力です。運用手順書、構成図、アカウント台帳、監視項目、バックアップとリストア手順、障害履歴、改修履歴などを、どのツールで、どの粒度で残すのか。ここが弱い会社は、対応も場当たりになりがちです。提案段階で「運用ドキュメントの一覧（納品物）」を提示できるかを確認しましょう。

さらに、セキュリティと権限設計も必須です。特にクラウド（AWS、Azure、GCP等）では、アカウント管理がずさんだと、退職者がアクセスできたままになる、誰が何をしたか追えない、といった事故につながります。最小権限（必要な人に必要な範囲だけ）、操作ログ、二要素認証、鍵の管理方針など、運用の基本を説明できるかを見てください。

最後に、見積と説明の透明性です。月額費用に含まれる作業時間の考え方、追加費用が発生する条件、調査と修正の切り分け、緊急対応の単価などを、非エンジニアにも分かる言葉で説明できる会社は、運用でも揉めにくい傾向があります。

契約で必ず押さえるべき条項：SLA・範囲・変更・引き継ぎ

納品後に困らないための核心は契約です。契約書に落とし込むことで、担当者が変わっても運用品質を維持でき、トラブル時の判断がブレません。法務の専門領域に踏み込みすぎず、現場で効く観点に絞って解説します。

SLA（サービスレベル）と受付時間を「数字」で決める

SLAは「どれくらいの速さ・品質で対応するか」の約束です。例えば、障害の重要度を3段階に分け、一次応答までの時間と復旧目標を決めます。ここが曖昧だと、夜間に障害が起きたときに「明日対応でいいですか？」となり、事業側は困ります。

• 受付時間：平日9-18時、もしくは24/365
• 一次応答：重大障害は30分以内、通常は4時間以内など
• 復旧目標：暫定復旧と恒久対応を分けて定義

“復旧”の定義が曖昧になりがちなので、「サービスが再開し、業務が再開できる状態」を暫定復旧とする、など言葉を揃えておきましょう。

保守運用の範囲（インシデント・監視・改修）を明文化する

月額に含まれる範囲は、箇条書きで列挙し、含まれないものも合わせて書きます。特に揉めやすいのは「軽微改修」「調査」「原因分析」「第三者サービス起因」の扱いです。

• 含める例：監視、アラート一次対応、バックアップ確認、障害一次切り分け、月次レポート
• 条件付きの例：障害調査（◯時間まで月額内、それ以上は追加）、軽微改修（チケット月◯件まで）
• 含めない例：新規機能追加、大幅なUI刷新、利用規約改定に伴う要件変更

ポイントは「追加費用になる条件」を先に決めることです。追加費用の発生条件が不明確だと、毎回交渉が必要になり運用が遅れます。

変更管理（仕様変更の手順）を契約と運用ルールに落とす

運用中は必ず「こうしたい」「やっぱり戻したい」が発生します。そこで、変更の受付方法（チケット・メール）、優先度、影響調査、承認者、リリース手順、ロールバック手順を定めます。非エンジニアでも、稟議や承認フローに似ているので理解しやすいはずです。

また「緊急変更（本番での即時対応）」と「計画変更（定例リリース）」を分けましょう。緊急変更はリスクが高いので、誰が決裁するか、ログと事後報告を必須にするなど、事故を防ぐ仕組みが必要です。

引き継ぎ（ベンダー変更）条項を最初から入れる

ベンダー変更は珍しいことではありません。にもかかわらず契約に引き継ぎが入っていないと、ドキュメントが出てこない、アカウントが渡らない、引き継ぎに法外な費用がかかる、という問題が起こります。

契約で押さえるべきは、運用に必要な情報の納品物、引き継ぎの作業範囲、協力義務、費用の考え方です。理想は、運用ドキュメントを「常に更新し、いつでも引き継げる状態」にしておくことです。これにより、外注先も緊張感を持って品質維持しやすくなります。

見積・料金体系の読み解き方（月額の「安さ」に潜む落とし穴）

保守運用の費用は、月額固定、時間従量（工数課金）、チケット制（一定件数込み）、ハイブリッド（基本月額＋追加）などがあります。どれが正解というより、システムの成熟度と、問い合わせ・変更の多さに合わせて選ぶのが現実的です。

月額固定が安い場合、よくあるのは「監視ツールの通知を転送するだけ」「一次受付のみで実作業は別見積」「稼働時間が極端に短い」など、実は守備範囲が狭いケースです。もちろん、社内で対応できるならそれで十分ですが、情シスが少人数だったり、システムが売上に直結する場合は、“安いが止まる”契約になりやすいので注意が必要です。

見積の妥当性を見るコツは、「待機」と「実作業」を分けて説明してもらうことです。運用は、何も起きない時間も含めて体制を維持する必要があります。24/365のような要件なら、担当者1人では回らず、交代要員も含めた体制コストが乗ります。逆に平日日中だけなら、コストを抑えられます。

また、追加費用の単価（時間単価）だけでなく、最小課金単位（30分か1時間か）、緊急対応の割増、調査報告書の作成費、第三者サービス（決済、地図、メール配信等）に起因する障害の扱いも確認しましょう。想定外の請求が出るポイントは大抵ここです。

社内稟議に通す際は、「止まったときの損失」を簡単でよいので試算すると説得力が上がります。例えば、1日停止で失う売上、社内作業の滞り、顧客対応コストなどです。保守運用は“保険”の側面があるため、費用対効果の説明に役立ちます。

導入を成功させる運用の作り方：情報・体制・コミュニケーション

契約が整っても、運用の立ち上げでつまずくことがあります。成功の鍵は、情報を整え、連絡経路を一本化し、定例で改善を回すことです。特に非エンジニアの組織では、依頼の仕方がバラバラになりやすく、対応漏れの原因になります。

最初の1ヶ月でやるべきは、運用の「入口」を揃えることです。例えば、問い合わせはフォームかチケットに統一し、電話や個人メールは禁止にする。優先度（緊急・通常・相談）を決め、緊急時の連絡先を明確にする。受付が整うだけで、対応速度と品質が大きく上がります。

次に、運用に必要な情報を棚卸しします。最低限そろえたいのは以下です。

• システム構成図（どのサーバ・サービスで動いているか）
• 管理画面・クラウド・ドメイン等のアカウント一覧と権限
• 監視項目と通知先（何が起きたら誰に通知されるか）
• バックアップ方針とリストア手順（復旧できるかの確認）
• リリース手順とロールバック（戻せる手順）
• 過去の障害・改修の履歴（同じ事故を繰り返さない）

重要なのは「ドキュメントがあること」より、「更新される仕組み」です。改修したら手順書も更新、権限を変えたら台帳も更新、といったルールを運用に組み込みます。外注先に任せきりにせず、発注側も月1回の定例で「今月の変更点が反映されているか」を確認すると、長期的に安定します。

定例会では、障害の件数だけでなく、問い合わせの傾向（どこで迷っているか）、改善提案（監視追加、性能改善、UI改善など）を議題に入れると効果的です。保守運用は守りですが、改善が回り始めると“攻めのIT”に変わります。

トラブルを未然に防ぐチェックリスト（そのまま使える）

最後に、外注先選定・契約・立ち上げで最低限確認したい項目をまとめます。社内での合意形成や見積比較にも使えます。

• 範囲：月額に含む作業／含まない作業が箇条書きで明確か
• SLA：受付時間、一次応答、暫定復旧、恒久対応の目安があるか
• 体制：窓口、一次対応、二次対応、エスカレーション先が明確か
• 情報：構成図、アカウント、監視、バックアップ、手順書が納品物として定義されているか
• 変更：仕様変更の受付方法、承認、リリース、ロールバックが決まっているか
• セキュリティ：最小権限、ログ、二要素認証、退職・異動時の権限剥奪手順があるか
• 費用：追加費用の条件、単価、最小課金単位、緊急割増が明示されているか
• 引き継ぎ：ベンダー変更時の協力義務、納品物、費用が契約に入っているか

これらが揃っていれば、「納品後に困る」確率は大きく下がります。逆に、いくつも曖昧なまま契約すると、障害時に揉めるだけでなく、改善が進まず、結果的に費用も時間も増えてしまいます。

まとめ

保守運用を外注する際に大切なのは、技術力の高さだけではなく、運用が回るように範囲・体制・情報・契約を設計することです。特に、月額に含まれる作業範囲、SLA（応答・復旧の約束）、変更管理の手順、引き継ぎ条項は、納品後のトラブルを防ぐ“必須セット”になります。

外注先を選ぶときは、価格の比較に加えて、運用ドキュメントの整備、説明の透明性、セキュリティと権限管理、担当者が変わっても回る仕組みを確認してください。運用の入口（問い合わせ窓口）を統一し、定例で改善を回すだけでも、保守運用は「守り」から「安定と成長を支える基盤」へと変わります。