情シス向け：保守運用まで見据えた外注先の選び方（SLA/監視/体制）

なぜ「開発が終わってから」では遅いのか：情シスが外注選定で見るべき全体像

外注先を選ぶとき、つい「機能が作れるか」「見積が安いか」に意識が寄りがちです。しかし情シスの仕事は、リリース後に始まります。障害対応、問い合わせ対応、アップデート、セキュリティ対応、契約更新、社内調整……。ここを見落とすと、開発は成功したのに運用が破綻するという状態になりやすいです。

特に中小企業や、予算はあるがITに詳しい人が多くない情シスでは、運用を属人化させないことが重要です。外注先が「作って終わり」だと、社内にナレッジが残らず、トラブル時に誰も判断できません。逆に、保守運用まで設計してくれる外注先なら、情シスは「意思決定」と「全社最適」に集中できます。

本記事では、外注先の選び方を「保守運用まで見据える」観点で整理します。具体的には、SLA（サービスレベル合意）、監視設計、運用体制（オンコールやエスカレーション）の3本柱に加え、引き継ぎ・ドキュメント、セキュリティ、契約・費用の考え方まで踏み込みます。専門用語は噛み砕きながら、情シスが社内説明に使えるチェックポイントとしてまとめます。

SLA（サービスレベル合意）で揉めないために：数字より「前提条件」を固める

SLAは「どの程度の品質で運用するか」を決める約束事です。よくあるのは「稼働率99.9%」「一次回答は2時間以内」などの数値ですが、情シスの現場では数値だけ決めてもトラブルは減りません。重要なのは、SLAが成立する前提条件（何を対象に、どこまでやるか）を明確にすることです。

例えば「障害の一次回答2時間以内」と書いてあっても、対象が「サーバ障害」だけなのか、「アプリの不具合」も含むのか、「利用者の操作質問」も含むのかで、運用負荷は大きく変わります。また、対応時間が「平日9-18時」なのか「24/365」なのかで、必要な体制も費用も変わります。まずは、情シス側で次の観点を棚卸しし、外注先と合意できる形にします。

また、SLAは「守れること」よりも「守れない時にどうするか」が大切です。例えば、優先度Sの障害で目標復旧時間を超過した場合、報告の頻度、エスカレーション先、原因分析レポートの期限、再発防止策のレビュー会の実施などをセットで決めると、情シスが社内に説明しやすくなります。

外注先選定の場では、SLAのテンプレを提示してもらい、前提条件が丁寧に書かれているかを確認しましょう。「何をやらないか」が明記されている会社ほど、運用で揉めにくい傾向があります。

監視は「入れて安心」ではない：検知→判断→連絡→復旧の流れで設計する

監視は、保守運用の要です。ただし監視ツールを入れるだけでは、障害対応は速くなりません。大事なのは、アラートが鳴った後に「誰が」「何を基準に」「どう動くか」を設計することです。監視は、検知（気づく）だけでなく、判断（優先度を決める）、連絡（関係者に伝える）、復旧（対処する）まで含めて初めて価値が出ます。

情シスが押さえるべきは、アラートの品質です。アラートが多すぎると「またか」と無視され、少なすぎると気づけません。外注先には、監視設計の考え方を必ず聞いてください。例えば「CPU高騰」だけを見ていても、業務影響は判断できません。業務上の重要指標（ログイン失敗増加、決済失敗、APIエラー率、バッチ遅延など）と結びつける必要があります。

監視の成果物としては、「監視一覧（何を・どの閾値で）」「アラートごとの対応手順（ランブック）」「障害時の連絡フロー」が揃っている状態が理想です。情シスがITに詳しくない場合でも、ランブックがあれば初動の質が上がり、外注先への依頼も的確になります。

なお、監視はコストがかかります。24/365の監視・一次対応を外注に求めるのか、夜間休日はクラウドの自動復旧に寄せるのか、重要システムだけ手厚くするのか。監視の厚みは「業務停止の損失」と釣り合うように設計すると、社内説明が通りやすくなります。

運用体制（オンコール/エスカレーション/窓口）を見える化する：属人化を防ぐ質問集

外注先選定で一番差が出るのが「体制」です。同じSLA・同じ監視ツールでも、体制が弱いと現場は回りません。情シスが確認すべきは、担当者個人の能力よりも、仕組みとして回る体制かどうかです。

具体的には、夜間休日のオンコール有無、一次対応の担当（運用担当か開発担当か）、障害時に開発者へエスカレーションする経路、窓口の一本化（チケット管理）、定例会での改善サイクルなどです。特に「担当者が休むと止まる」状態は危険です。複数名での引き継ぎ、交代要員、手順書の整備があるかをチェックします。

また、情シスの負担がどこに残るかも重要です。例えば「問い合わせ一次受付は社内で行い、技術的な二次対応を外注する」形は、社内ヘルプデスクが整っている企業には向きます。一方、情シスが少人数で兼務が多い場合、一次受付も外注に寄せたほうが現実的です。社内の体制に合わせて、外注先の運用体制を“組み合わせる”発想が失敗を減らします。

引き継ぎ・ドキュメント・ソース管理：運用できる納品物の条件

保守運用まで見据えた外注選びでは、「納品物＝ソースコード」では不十分です。情シスが本当に欲しいのは、運用可能な状態です。たとえば、障害が起きたときにどこを見ればよいか、環境を再現できるか、設定変更の影響を判断できるか。これを支えるのがドキュメントと運用設計です。

最低限、次の成果物が用意されるかを確認しましょう。外注先が「ドキュメントは別途」と言う場合でも、運用に必要な範囲を契約に含めることが大切です。ドキュメントはコストではなく、将来の保守費の削減策です。

• システム構成図：クラウド/サーバ/ネットワーク/外部サービスの関係が一枚で分かる
• 運用手順書：定常作業（アカウント追加、権限変更、データ修正の手順と注意点）
• 障害対応手順（ランブック）：よくあるアラートごとの確認項目、暫定復旧、連絡テンプレ
• リリース手順：本番反映、ロールバック、メンテ告知、影響範囲の確認方法
• ソース/設定の管理方法：リポジトリ権限、ブランチ運用、Secrets（鍵）の取り扱い
• バックアップ/復元手順：バックアップ対象、世代、復元テストの頻度

ここでの落とし穴は、「外注先しか触れない構成」になっていることです。例えば、クラウドアカウントが外注先名義、監視ツールの管理権限が外注先のみ、運用用の管理画面アカウントが共有されていない、などです。これでは契約終了時に詰みます。情シスとしては、最低限「資産の名義」「管理者権限」「ソースコードの所在」「ライセンスの帰属」を契約書・運用設計に落とし込みましょう。

セキュリティとコンプライアンス：情シスが押さえるべき現実的な線引き

運用フェーズでは、脆弱性対応や権限管理が継続的に発生します。外注先選定時に、セキュリティを「頑張ります」で済ませると、後から監査や事故対応で苦労します。ここでは、情シスが専門家でなくても確認できる、現実的な線引きを整理します。

まず、権限管理。運用担当が本番にアクセスできるのは必要ですが、無制限は危険です。最小権限（必要なことだけできる権限）と操作記録（監査ログ）が設計されているか確認します。次に、脆弱性対応。OSやライブラリのアップデート方針（頻度、緊急時の手順、影響確認）を明文化できる外注先は信頼できます。

「厳格にしすぎて運用が回らない」問題もあります。例えば、軽微な設定変更まで都度稟議にするとスピードが落ちます。おすすめは、変更管理を3段階に分けることです。①定型（手順書通りでリスクが小さい）②準定型（影響が限定的でレビューすればよい）③重大（承認・計画・メンテが必要）。この線引きを外注先と合意すると、情シスの統制と現場のスピードを両立できます。

見積と契約の勘所：保守費の「安さ」より、変更と障害の「扱い」を決める

保守運用の見積は比較が難しい分野です。「月額○万円で保守します」と言われても、含まれる作業が会社ごとに違うからです。情シスとしては、安さよりも、障害・変更・問い合わせが発生したときの扱いを明確にすることが重要です。

例えば、次のような観点は契約で曖昧になりやすいポイントです。

• 保守の範囲：監視、一次対応、原因調査、復旧、再発防止、問い合わせ対応は含まれるか
• 軽微改修の扱い：月次の保守枠で対応できる作業量（例：月○時間）／超過時の単価
• 障害対応の課金：夜間休日は割増か、定額に含むか、優先度で変わるか
• クラウド費用：クラウド利用料は誰が契約・支払い、コスト最適化は誰が責任を持つか
• 成果物の帰属：ソースコード・設計書・設定の所有権、納品物の範囲
• 契約終了時：引き継ぎ支援、アカウント移管、ドキュメント更新の条件

また、見積比較の際は「運用の前提」が揃っているか確認してください。たとえば、A社は24/365オンコール込み、B社は平日日中のみ、という条件で月額だけ比較すると誤判断します。比較表を作るなら、SLA（対応時間・優先度）と監視（対象・通知）と体制（窓口・オンコール）を横並びにして、同条件に揃えた上で金額を見ます。

最後に、契約の形もポイントです。開発は請負、運用は準委任（工数ベース）になるケースが多いですが、どちらが良い悪いではなく「期待値を一致させる」ことが重要です。準委任の場合は、月次での作業報告と改善提案が出るか、KPI（障害件数、平均復旧時間、問い合わせの傾向など）を一緒に見られるかが、良い運用の分かれ目です。

まとめ

情シス向けの外注先選びは、「作れる会社」ではなく「運用できる状態を一緒に作れる会社」を選ぶのが本質です。開発後に苦労しないためには、SLAで前提条件を固め、監視を検知だけで終わらせず、体制（オンコール・エスカレーション・窓口）を仕組みとして確認する必要があります。さらに、引き継ぎ可能なドキュメントと権限設計、現実的なセキュリティ線引き、契約での範囲定義まで整えることで、属人化と炎上を防げます。

迷ったら、次の3点を外注候補に投げてみてください。①SLAのテンプレと例外条件を見せてください ②監視一覧とアラート対応手順（ランブック）の雛形はありますか ③障害時の体制図（一次対応→エスカレーション→報告）を図で出せますか。この3つを具体的に出せる会社は、運用に強い可能性が高いです。

保守運用まで含めた外注の設計は、情シスの負担を減らし、事業スピードを上げる投資です。社内の状況（体制・リスク許容度・重要システム）に合わせて、無理のない運用像を一緒に描けるパートナーを選びましょう。