システム運用保守を外部に発注・委託したいものの、「どこに依頼すればよいのか」「契約形態は何が適切か」「今支払っている保守費用は妥当なのか」といった疑問を抱えている情報システム担当者や経営者の方は少なくありません。運用保守は一度発注すると長期にわたって関係が続くため、最初のパートナー選びと契約内容の詰め方が、その後の安定稼働とコスト管理を大きく左右します。発注先選定の段取りを誤ると、ベンダーロックインや費用の高止まり、障害時の責任の押し付け合いといったトラブルに発展しかねません。
本記事では、システム運用保守の発注・外注・委託を検討している方に向けて、依頼先の種類と選び方、ベンダー選定の具体的なプロセスと所要期間、準委任契約と請負契約の使い分け、契約書で必ず押さえるべき条項、そして見落としがちな契約の落とし穴までを実務目線で解説します。保守費用が適正かどうかを見抜く監査の視点や、SLA交渉の進め方など、他ではあまり語られない踏み込んだノウハウも盛り込みました。この記事を読めば、自社にとって最適な発注の進め方が具体的にイメージできるようになります。
システム運用保守の発注・外注とは｜依頼先の種類と特徴
システム運用保守の発注を検討する前に、まず「運用」と「保守」の違い、そして委託できる業務の範囲を整理しておくことが大切です。発注範囲が曖昧なまま契約に進むと、後から「これは契約外です」と追加費用を請求されるトラブルが頻発します。ここでは依頼先の種類と、それぞれの特徴を押さえていきます。
委託できる運用業務と保守業務の範囲
運用とは、システムを正常に稼働させ続けるための定常業務を指します。具体的には、サーバーやネットワークの稼働監視、データのバックアップ、アクセス権限の管理、ユーザーからの問い合わせ対応などが含まれます。一方の保守とは、障害が発生した際の原因究明と復旧対応、あるいは法改正や業務変更に伴う仕様変更・機能改修を指します。発注時にはこの両者のどこまでを委託するのかを明確にする必要があります。
たとえば「監視と問い合わせ対応は委託するが、機能改修は都度見積もりで対応する」といった切り分けが一般的です。委託範囲を曖昧にしたまま契約すると、軽微な改修まで追加費用として請求されたり、逆にベンダー側が「それは対象外です」と対応を拒否したりする原因になります。発注前に運用と保守の境界線を文書で定義しておくことが、トラブル防止の第一歩となります。
発注先の種類｜開発元・専門ベンダー・SIerの違い
発注先は大きく3つに分けられます。1つ目はシステムを開発した会社にそのまま保守を依頼する方法です。仕様を熟知しているため障害対応が早い反面、他社への乗り換えが難しくベンダーロックインに陥りやすい傾向があります。2つ目は運用保守を専門とするベンダーです。複数システムの監視やヘルプデスクを得意とし、コスト効率が高い一方、開発当初の経緯を知らないため引き継ぎに時間を要します。
3つ目は幅広い領域を一括で請け負うSIerやITコンサルティング企業です。インフラから業務システムまで横断的に管理でき、戦略的な改善提案まで期待できますが、費用は相対的に高くなりがちです。自社のシステム規模や内製リソースの有無、求めるサービスレベルに応じて、これらの選択肢を比較検討することが重要です。発注先ごとの判断軸については、システム運用保守の進め方を解説した記事もあわせてご確認ください。
内製か外注かの判断基準
運用保守を外部に発注するか、社内で内製するかは、コストだけでなく属人化リスクや事業継続性まで含めて総合的に判断すべきテーマです。ここでは外注に向くケースと、内製を残すべきケースの見極め方を整理します。
外注に向くケースとメリット
社内に運用保守を担える人材が不足している、あるいは特定の担当者に業務が集中して属人化している場合は、外注が有力な選択肢となります。ソフトウェアのライフサイクル全体にかかるコストのうち、運用保守が占める割合は40〜80%、平均で約60%にのぼると言われており、内製で抱え込むと人件費負担が重くのしかかります。経済産業省の調査でも、既存システムの運用に対する支出と新規構築への支出はおおむね2対1の比率とされ、保守領域の負担の大きさがうかがえます。
外注すれば、専門人材の確保や育成のコストを抑えつつ、24時間監視や障害時の即応体制を整えられます。また、担当者の退職によって業務が止まるリスクを軽減できる点も大きなメリットです。自社のコア業務にリソースを集中させたい企業ほど、運用保守の外注効果は高くなります。
内製を残すべき業務の見極め方
すべてを外注すればよいわけではありません。自社の事業競争力に直結する基幹ロジックや、機密性の高いデータを扱う領域については、最終的な意思決定や監督機能を社内に残すべきです。完全に外部任せにすると、システムの中身を社内の誰も把握していない状態に陥り、ベンダーの言い値で費用を払い続けることになりかねません。
現実的な解は、定型的な監視・運用は外注しつつ、ベンダーをマネジメントする役割や仕様変更の優先順位付けは社内に残すハイブリッド型です。委託先に丸投げするのではなく、発注側がサービスの品質をチェックできる体制を維持することが、長期的なコスト最適化につながります。
発注先（ベンダー）選定の進め方と所要期間
運用保守の発注先選定は、思いつきで進めると失敗します。要件の整理から契約締結、引き継ぎまでを含めると、全体で4〜6ヶ月を要するのが一般的です。現在の契約満了や担当者交代を見越して、逆算したスケジュールで動き出すことが成功の鍵となります。
要件定義からRFI・RFPまでの流れ
選定の出発点は、自社が委託したい業務範囲と求めるサービスレベルを言語化する要件定義です。続いて、候補となる複数のベンダーに情報提供を求めるRFI（情報提供依頼書）を送り、各社の対応領域や実績を把握します。その上で、具体的な提案と見積もりを求めるRFP（提案依頼書）を提示し、各社からの提案を集めます。
ここで効果的なのが、現在契約している既存ベンダーもRFPに参加させることです。競争原理が働くことで、既存ベンダーが契約条件を大幅に見直して提案してくるケースがあり、結果として既存ベンダーの継続が30〜40%の確率で発生するとも言われています。新規切り替えありきではなく、まず現状の条件を市場価格と照らし合わせる材料として活用するのが賢明です。
評価表の作り方と配点のコツ
提案を比較する際は、感覚ではなく評価表を用いて定量的に採点します。評価軸は技術力、実績、サポート体制、SLAの保証内容、そして価格などに分けます。ここでのコツは、価格の配点を全体の20点以下に抑えることです。価格の比重を上げすぎると、安かろう悪かろうの低品質ベンダーが選ばれてしまうリスクが高まります。
採点は「○は5点、△は2点、×は0点」のように差が開く配点にすると、評価のブレを抑えられます。中間点を多用すると各社が横並びになり判断材料にならないためです。契約前にはPoC（概念実証）や試験的な業務委託を挟み、提案書だけでは見えない実対応力を確認しておくと、ミスマッチを防げます。
契約形態の選び方｜準委任契約と請負契約
運用保守の委託では、準委任契約と請負契約のどちらを選ぶかが法務上の重要な分岐点になります。両者は完成責任の有無や費用の扱いが異なり、業務の性質に応じて使い分ける必要があります。誤った契約形態を選ぶと、責任の所在が曖昧になりトラブルの火種となります。
準委任と請負の違いと使い分け
準委任契約は、業務を継続的に遂行することそのものに対価を支払う形態で、成果物の完成責任は負いません。監視業務や問い合わせ対応、定期点検といった、明確な完成形を定義しにくい定常業務に適しています。一方の請負契約は、特定の成果物を完成させることを約束する形態です。機能改修やバージョンアップなど、納品物がはっきりしている業務はこちらが向いています。
実務では、月額定額の運用監視を準委任、都度発生する改修案件を請負として、1つのベンダーと2つの契約を併用するケースも多く見られます。それぞれの業務の性質に合わせて契約形態を選ぶことで、責任範囲が明確になり、後々のトラブルを回避できます。
印紙税の扱いという見落としがちな論点
契約形態の選択には、印紙税という実務的なメリットも絡みます。保守契約を準委任契約として締結した場合、課税文書である第7号文書に該当せず、収入印紙が不要になるケースが多くあります。これに対して請負契約は課税文書となり、契約金額に応じた収入印紙の貼付が必要です。
継続的な運用監視を準委任で契約することで、印紙税コストを抑えられる可能性があるわけです。ただし、契約の名称だけで判断されるのではなく、契約の実態によって課税区分が決まる点には注意が必要です。判断に迷う場合は、税理士や法務担当者に確認した上で契約形態を決めるのが安全です。
契約書で必ず押さえるべき条項と落とし穴
運用保守の発注トラブルの多くは、契約書の記載不備に起因します。発注時に勢いで契約を交わしてしまうと、いざ障害やデータ漏えいが発生したときに「責任は誰にあるのか」「どこまでが対象なのか」で揉めることになります。契約段階で詰めておくべき条項を確認しましょう。
保守対象範囲・免責・解除条件の明記
契約書には、保守対象範囲、費用と支払い方式、免責事項、契約解除条件の4点を最低限明記すべきです。とりわけ免責事項は、ベンダー有利になりすぎていないかを発注側がチェックする必要があります。免責の範囲が広すぎると、障害が起きても「免責に該当する」として一切の補償が受けられない事態になりかねません。
契約解除条件も重要です。乗り換えを決断したときにスムーズに契約を終了できるよう、解約予告期間やデータ返却の手続きをあらかじめ定めておきます。ここが曖昧だと、解約時にデータの引き渡しを渋られたり、高額な移行支援費用を請求されたりするベンダーロックインのリスクが残ります。契約や費用の妥当性をさらに深掘りしたい場合は、システム運用保守の費用相場を解説した記事も参考にしてください。
ハードウェア保守の所有権という盲点
意外に見落とされがちなのが、ハードウェア保守における故障部品の所有権です。たとえばHDD（ハードディスク）を交換した場合、取り外された故障部品の所有権は保守会社に帰属するのが一般的です。つまり、機密データが記録されたままのディスクが、保守会社の手に渡る可能性があるということです。
個人情報や機密情報を扱うシステムでは、故障部品の確実なデータ破棄や物理的な廃棄証明を求めるために、別途の契約や覚書が必要になります。標準の保守契約には盛り込まれていないことが多いため、発注時に必ず確認しておきたいポイントです。クラウド利用時には、責任共有モデルに基づいて、どこまでが自社責任でどこからがベンダー責任かをRACIチャートなどで明文化しておくと、障害時の責任の押し付け合いを防げます。
SLAと費用妥当性のチェック方法
発注後の品質とコストを管理するうえで、SLA（サービスレベル合意）の設定と費用の妥当性チェックは欠かせません。ここを詰めておかないと、サービス品質が下がっても改善を求める根拠がなく、費用が適正かどうかも判断できないまま支払いを続けることになります。
SLAの目標値設定とペナルティ交渉
SLAでは、サーバーやアプリの稼働率、障害時の応答・復旧時間などをKPIとして定量化します。たとえば、自治体のガイドラインでは、稼働率99.8%以上、基準応答時間の達成率93%（3秒以内）、重大障害は年2回まで、障害発生後30分以内の通知遵守率100%、ヘルプデスクの電話応答率97%以上といった具体値が示されています。自社にとって必要なサービスレベルを、こうした数値を参考に設定します。
さらに踏み込むなら、目標未達時のペナルティ条項を契約に盛り込む交渉が有効です。一方的にペナルティを課すだけでは合意が得られにくいため、目標を上回った場合のインセンティブ報酬とセットで提案すると、ベンダー側も受け入れやすくなります。他社の契約事例を交渉材料として持ち込むことも、条件を有利に進める実践的なテクニックです。
保守費用が適正かを見抜く監査の視点
「今支払っている保守費用は妥当なのか」という疑問は、多くの発注担当者が抱える本音です。これを相見積もり以外で見抜く方法として、作業報告書やサーバーログから実際の稼働時間を算出し、適正価格を割り出す監査の視点が有効です。月額固定で支払っているにもかかわらず、実際の対応がほとんど発生していなければ、料金の見直し交渉の余地があります。
また、新ベンダーの月額が安く見えても、引き継ぎや移行に300〜500万円のコストがかかる場合、5年間のTCO（総保有コスト）で計算すると逆転してしまうことがあります。乗り換え判断は月額だけでなく、移行コストを含めた総額で評価することが鉄則です。発注先選定から運用立ち上げまでの一連の流れは、システム運用保守の完全ガイドで体系的に整理していますので、全体像を把握したい方はあわせてご覧ください。
スムーズな引き継ぎと属人化対策
発注先を切り替える、あるいは新たに外注を始める際に、引き継ぎの失敗は致命的なトラブルにつながります。とりわけドキュメントが整備されていないシステムでは、知見が特定の担当者に集中する属人化が進んでおり、引き継ぎが難航しがちです。ここでは円滑な移行のための実務ポイントを解説します。
引き継ぎ体制とスケジュールの組み方
引き継ぎは、新担当者をいきなり一人立ちさせるのではなく、現行担当者のサポートを重ねながら段階的に進めるのが効果的です。具体的には、新担当者を1.0人月程度投入しつつ、現行担当者が週2日程度サポートに入る体制が、知見の移転を確実にします。OJT形式で2ヶ月ほどの引き継ぎ期間を設けると、障害対応の勘所まで含めて移転しやすくなります。
このスケジュールを確保するためにも、前述のとおりベンダー選定は契約満了の6ヶ月前には動き出す必要があります。引き継ぎ期間を圧縮すると、移行直後に障害が起きても新ベンダーが対応しきれず、サービス停止のリスクが高まります。余裕を持ったスケジュール設計が、安定稼働の前提となります。
属人化崩壊時の緊急対応とAI活用
最悪のケースは、ドキュメントが皆無の状態でキーマンが突然退職してしまう事態です。この場合、明日からシステムを解読しながら維持しなければなりません。緊急時には、稼働中の挙動やログから仕様を逆算するリバースエンジニアリングが必要になります。発注先の選定時に、こうした緊急対応の経験があるベンダーかどうかを確認しておくと安心です。
近年では、開発当初の仕様を知る人材がいないレガシーシステムに対し、AIに既存コードを解析させてブラックボックス化を解消する手法も登場しています。ただし、AIによる運用効率化はスモールスタートが鉄則で、いきなりワークフロー全体を刷新すると現場が混乱します。アラートの一次切り分けといった小さな業務から導入し、徐々に範囲を広げていくのが現実的です。発注先のベンダー比較を具体的に進めたい場合は、システム運用保守のおすすめ会社を比較した記事が参考になります。
まとめ
システム運用保守の発注・外注を成功させるには、まず運用と保守の委託範囲を明確に定義し、開発元・専門ベンダー・SIerといった発注先の特性を理解することが出発点となります。内製か外注かはコストと属人化リスクの両面から判断し、ベンダー選定は4〜6ヶ月の余裕を持って、要件定義からRFI・RFP、評価表による定量比較へと段取りよく進めることが重要です。
契約段階では、準委任と請負を業務の性質に応じて使い分け、印紙税の扱いも踏まえて契約形態を選びます。保守対象範囲・免責・解除条件を明記し、HDDの所有権やクラウドの責任分界といった盲点まで押さえることで、後々のトラブルを未然に防げます。さらに、SLAの目標値設定とペナルティ交渉、作業報告書やログを用いた費用妥当性の監査、そして余裕を持った引き継ぎ体制の構築が、長期にわたる安定稼働とコスト最適化を実現します。本記事を参考に、自社にとって最適な発注の進め方を設計していただければ幸いです。
株式会社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を創業。