SaaSやWebサービスを安定して提供し続けるためには、リリース後の運用保守をどう体制化するかが事業の成否を左右します。自社にエンジニアが十分にいない、あるいは本来注力すべきプロダクト改善にリソースを割きたいという理由から、サービス運用保守を外部のベンダーへ発注・外注したいと考える企業は年々増えています。しかし「どこまでを委託範囲とするか」「どの契約形態が適切か」「将来内製化したくなったときにスムーズに引き継げるか」といった論点を曖昧にしたまま発注してしまうと、想定外の追加費用やベンダーロックイン、撤退時のデータ返却トラブルに直面しがちです。
この記事では、サービス運用保守（SaaS・継続的な機能改善を伴う運用）を外部へ発注・外注・委託する際の具体的な進め方を、契約形態の選び方からRFP（提案依頼書）の作り方、準委任契約における評価指標の設計、改善ロードマップの合意形成、そしてExit条項やデータ返却までの実務に沿って解説します。東京地裁の保守契約をめぐる裁判例や、SLAの具体的な数値目安も交えながら、発注後に「こんなはずではなかった」とならないための判断軸を提示します。サービス運用保守の外注を検討している事業責任者・情シス担当者の方が、自社に最適な委託先と契約条件を見極められるようになることを目指した内容です。
サービス運用保守を発注・外注する前に押さえる全体像
サービス運用保守の外注は、単に「障害が起きたら直してもらう」という保守だけを切り出すのとは性質が異なります。SaaSやWebサービスは公開して終わりではなく、ユーザーの利用状況を見ながら継続的に機能を改善し、稼働を監視し続ける必要があるためです。発注前に「日常運用」「障害対応の保守」「継続的な改善開発」という3つの領域のどこまでを委託するのかを明確にしておくことが、後のトラブルを防ぐ第一歩となります。
内製と外注の判断基準
サービス運用保守を内製するか外注するかは、社内のエンジニアリソースとサービスの成長フェーズで判断します。立ち上げ直後で改善のスピードが命のフェーズでは、機能開発に社内エンジニアを集中させ、監視・障害対応・定型的な保守を外注へ振り分けると効率的です。逆に、サービスがある程度安定し、業務知識が事業の競争力に直結する段階では、運用ノウハウを社内に蓄積する内製化が選択肢になります。
外注の最大のメリットは、24時間365日の監視体制や専門人材を自社で抱えずに済む点です。一方で、運用を完全に外部任せにすると、サービスの内部構造や運用手順が社内に残らない「ブラックボックス化」が進みます。外注を選ぶ場合でも、構成図や運用手順書を自社で保有し続ける契約にしておくことが、将来の選択肢を狭めないための重要な条件となります。
委託範囲の3分類を切り分ける
発注内容を整理する際は、業務を「運用」「保守」「改善開発」の3つに分けて考えると委託範囲が明確になります。運用は稼働監視・バックアップ・アカウント管理などの日常オペレーション、保守は障害復旧・セキュリティパッチ適用・ライブラリ更新などの維持作業、改善開発は新機能の追加やUI改善といったプロダクトの進化に関わる作業です。
このうち、改善開発をどこまで月額の保守費用に含めるかは、トラブルの火種になりやすい論点です。SaaSは継続的な改善が前提のため、「保守込みだと思っていた軽微な機能追加」が想定外の追加見積もりになるケースが後を絶ちません。発注時点で「月◯時間までの軽微改修は保守費に含む」「それを超える開発は別見積もり」といった線引きを文書で合意しておくことが欠かせません。
サービス運用保守そのものの進め方や工程を体系的に把握したい場合は、サービス運用保守の進め方を解説した記事もあわせてご覧ください。委託範囲を切り分ける前提として、運用保守全体のライフサイクルを理解しておくと発注内容を整理しやすくなります。
契約形態の選び方｜準委任と請負の違い
サービス運用保守の発注では、契約形態の選択が後の評価方法や責任範囲を大きく左右します。運用保守は「完成物を納品する」のではなく「業務を継続的に遂行する」性質が強いため、一般的には準委任契約が選ばれます。ただし改善開発が大きく絡む場合は請負契約の要素も加わるため、契約の混在をどう整理するかが実務上のポイントになります。
準委任契約が運用保守に適する理由
準委任契約は、特定の成果物の完成ではなく、業務を適切に遂行すること自体を目的とする契約です。サービス運用保守は、監視や障害対応のように「いつ何が発生するか予測できない業務」が中心となるため、あらかじめ成果物を定義する請負契約にはなじみません。月額固定で一定の稼働を確保し、その範囲内で運用・保守を任せる準委任が実態に合っています。
一方で準委任は成果保証がない分、業務の質をどう担保するかが課題になります。ここで後述するSLA（サービス品質保証）や評価指標を契約に組み込むことで、「準委任だが品質基準は数値で約束する」という運用が可能になります。準委任契約だからといって品質を曖昧にしてよいわけではない点を、発注側がしっかり認識しておく必要があります。
裁判例に学ぶ追加費用トラブルの回避
保守契約をめぐっては、追加作業の費用負担が争点になった裁判例があります。東京地裁の平成24年4月25日判決では、ベンダーが見積工数を超過した分の報酬を請求したものの、超過原因がユーザー側の追加指示に起因する部分のみがユーザー負担と認められ、請求の一部しか認容されませんでした。この判決は、作業範囲と追加指示の責任所在を契約時に明文化しておくことの重要性を示しています。
この教訓を発注実務に落とし込むなら、「どこまでが契約内の作業か」「追加作業が発生したときの単価と承認フローはどうするか」を契約書に具体的に書き込んでおくことが肝心です。口頭やチャットでの依頼が積み重なって工数が膨らみ、後から費用負担で揉めるケースは珍しくありません。追加依頼は必ず見積もりと承認をワンセットにする運用ルールを発注側から提示しておくと、双方にとって安全です。
RFPと発注前ドキュメントの準備
発注の精度は、ベンダーに渡す情報の質で決まります。サービスの構成や運用状況を曖昧なまま見積もり依頼をすると、各社の見積もり前提がバラバラになり比較が難しくなるうえ、契約後の認識ズレも生じます。RFP（提案依頼書）を整え、的確な質問リストを用意することで、開発・運用後の手戻りコストを大幅に削減できることが実務上知られています。
RFPに必ず記載すべき項目
運用保守のRFPには、サービスの概要だけでなく「現状の技術スタック」「想定するユーザー数とアクセス規模」「求める稼働率と障害対応時間」「委託したい業務範囲」「改善開発の想定ボリューム」を盛り込みます。特に技術スタックの情報は、ベンダーが対応可能かどうかを判断する要となるため、利用しているクラウド・フレームワーク・データベースの種類とバージョンまで具体的に示すことが望ましいです。
あわせて、月次レポートの提供有無や定例会の頻度といった情報共有の期待値も記載しておきます。準委任契約では業務の進捗が見えにくくなりがちなため、どのような形で報告を受けたいかを発注側から提示しておくと、提案段階で各社の運用スタイルの違いが浮き彫りになります。これにより、価格だけでなくコミュニケーションの相性まで含めて比較できます。
引き継ぎ資料と属人化の解消
外注を成功させるうえで、引き継ぎ資料の整備は見落とされがちですが極めて重要です。ドキュメントに残らない属人化した手順は、引き継ぎ時の致命的なトラブル要因になります。たとえば「特定の順番でサーバーを再起動しないと立ち上がらない」「月初だけ特別なバッチを手動実行している」といった暗黙知が、担当者の頭の中だけにある状態は危険です。
発注前に、システム構成図・運用手順書・障害時の連絡フロー・各種アカウント情報といった引き継ぎ資料を棚卸ししておくと、ベンダー側も正確な見積もりと安全な引き継ぎが可能になります。仮に資料が不十分な場合は、初期フェーズで「現状把握とドキュメント整備」を委託項目として切り出すのも有効です。属人化を解消するこの初期投資が、後々のベンダー変更や内製化の自由度を高めます。
SLAと準委任での評価指標の設計
準委任契約で品質を担保する鍵は、SLA（サービス品質保証）として評価指標を数値で約束させることです。成果物がない準委任だからこそ、稼働率や障害対応時間を具体的な数字で合意し、未達時の対応まで定めておくことで、業務の質を客観的に評価できるようになります。SaaSのように改善が続くサービスでは、運用品質と改善のスピードの両面を指標化すると効果的です。
SLAの具体的な数値目安
IT運用アウトソーシングのSLAでは、重大障害時に「初回応答15分以内・解決4時間以内」、通常障害時に「応答2時間以内・解決8時間以内」といった水準が一つの目安になります。これらの応答・復旧時間を契約に明記し、ベンダーがどのレベルを約束できるかを提案段階で確認しておくことで、いざというときの対応スピードが担保されます。
稼働率についても具体的な水準を定めます。ミッションクリティカルなサービスでは、行政の防災アプリのように「年間稼働率99.99%以上・システム停止は年1回以内・累計停止時間1時間以内」といった厳格な基準が設定される例もあります。自社サービスの重要度に応じて、99.9%なのか99.99%なのかを判断し、その達成にどれだけのコストがかかるかをベンダーと擦り合わせることが、過剰品質や品質不足を避けるポイントです。
改善ロードマップの合意と評価
サービス運用保守の外注で見落とされがちなのが、改善開発の進め方をどう評価するかです。SaaSは機能改善の継続が競争力に直結するため、単に障害なく動いているだけでは不十分です。発注時に、四半期や半年単位の改善ロードマップをベンダーと合意し、どの機能をいつまでに改善するかを共有しておくと、運用が「現状維持」に留まらず前進し続けます。
評価の際は、ユーザーフィードバックの反映件数やリリース頻度、改善による主要KPIの変化などを定期的に振り返ります。準委任契約では成果が保証されない代わりに、こうした改善のプロセスと結果を定例会で可視化することで、ベンダーが事業の成長に貢献しているかを判断できます。改善提案力のあるベンダーかどうかは、発注後の事業インパクトを大きく左右する要素です。
Exit条項とデータ返却・内製化への備え
発注の段階では「契約が終わるとき」のことまで考えにくいものですが、運用保守の外注で最もトラブルになりやすいのが、ベンダー変更や内製化に伴う引き継ぎです。サービス運用保守は事業の継続性に直結するため、いつでも安全に乗り換えられる状態を契約で担保しておくことが、ベンダーロックインを避ける決定的な条件になります。
Exit条項とデータ返却義務
契約書には、契約終了時のデータ返却義務と引き継ぎ支援を明記したExit条項を盛り込みます。具体的には、サービスのソースコード・データベースのエクスポート・構成図・運用手順書・各種アカウント情報を、どのような形式で・いつまでに返却するかを定めます。これが曖昧だと、契約終了時に「データの形式が独自仕様で移行できない」「引き継ぎに別途高額な費用を請求された」といった事態に陥ります。
あわせて、ベンダー変更時に新旧ベンダーが並行稼働する期間や、責任分界点も定めておくと安全です。障害発生時に「ネットワークは新ベンダー」「サーバーは旧ベンダー」「アプリは社内」と責任を押し付け合い、復旧が大幅に遅延した実例もあります。誰がどこまでを一次対応するかを移行前に文書化しておくことが、こうした混乱を防ぎます。
内製化を見据えた発注設計
将来的にサービス運用保守を内製化したい場合は、外注の段階からそれを見据えた発注設計をしておくと移行がスムーズになります。具体的には、ドキュメントを常に最新の状態に保つこと、運用に使うツールやインフラをできるだけ標準的で汎用的なものに揃えること、そして定例会に自社エンジニアを同席させてノウハウを吸収していくことが有効です。
内製化はある日いきなり完全移行するのではなく、まず監視や一次対応から段階的に社内へ取り込み、徐々に委託範囲を縮小していくロードマップを描くと現実的です。外注中に蓄積したドキュメントと、自社エンジニアの育成計画をセットで進めることで、中長期的な運用コストの削減とノウハウの内部蓄積を両立できます。発注先のベンダーには、こうした内製化支援に協力的かどうかも選定基準として確認しておくとよいでしょう。
発注先の選定と費用の考え方
発注先を選ぶ際は、価格の安さだけで判断しないことが鉄則です。安さを優先して選んだ結果、障害時の復旧が大幅に遅れたという失敗は典型的なパターンです。サービス運用保守は事業の継続性を支える業務であるため、技術力・対応スピード・改善提案力・契約の透明性を総合的に評価する必要があります。
失敗しない選定基準
選定では、自社の技術スタックに精通しているか、SLAを具体的な数値で約束できるか、24時間365日の対応体制があるか、月次レポートなどで情報共有をしてくれるかを確認します。加えて、SaaSの運用保守では改善提案力が重要なため、過去にどのようなサービスをどう成長させてきたかの実績を、具体的なエピソードで聞き出すことが有効です。
もう一つ重要なのが、エース人材の継続性です。契約後に優秀なエンジニアが別案件へ移り、経験の浅いメンバーばかりになるという失敗も起こりえます。提案時に体制図と主要メンバーの経歴を確認し、キーパーソンの稼働を契約でどこまで担保できるかを擦り合わせておくと、品質のばらつきを抑えられます。複数社を比較したい場合は、サービス運用保守でおすすめの開発会社を比較した記事も参考になります。
費用構造と妥当性の判断
運用保守の費用は、目安として開発費用の15%程度が年間の保守費として見込まれます。費用は「維持費（サーバー・ドメインなど）」「管理費（更新・障害対応・メンテナンスなど）」「運用費（改善開発・コンサルなど）」の3つに分類して整理すると、見積もりの妥当性を判断しやすくなります。月額固定型か従量課金型かによっても費用感は変わるため、自社の利用変動に合った課金体系を選ぶことが大切です。
各社の見積もりを比較する際は、同じ前提条件で見積もってもらうことが欠かせません。RFPで委託範囲とSLA水準を統一しておけば、金額の差がどこから生まれているかを正しく読み解けます。費用の詳しい内訳やレンジについては、サービス運用保守の費用相場を解説した記事で具体的に整理しています。発注額の妥当性を判断する材料として活用してください。
まとめ
サービス運用保守の発注・外注を成功させるには、委託範囲を「運用・保守・改善開発」の3つに切り分け、準委任を基本としつつSLAで品質を数値化し、RFPで各社を同条件で比較することが基本となります。SaaSは継続的な改善が前提のため、障害なく動かすだけでなく、改善ロードマップを合意して事業を前進させてくれるパートナーかどうかを見極めることが重要です。
そして、契約終了時のデータ返却を定めたExit条項と、属人化を防ぐドキュメント整備を発注段階から組み込んでおくことで、ベンダーロックインを避け、将来の内製化やベンダー変更の自由度を確保できます。東京地裁の裁判例が示すように、作業範囲と追加費用の責任所在を契約で明文化しておくことが、後の追加費用トラブルを防ぐ最善策です。これらの観点を押さえ、自社のサービスに最適な発注先と契約条件を選び抜いてください。運用保守全体を体系的に理解したい場合は、サービス運用保守の完全ガイドもあわせてご覧ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。