システム運用保守の発注・外注は、委託範囲と依頼先を整理し、内製か外注かを判断したうえで、選定、契約、引き継ぎへと進むのが全体の流れです。
一度発注すると長く続く運用保守では、最初の選定と契約の詰め方が、安定稼働とコスト管理を左右します。選定を誤ると、ベンダーロックインや費用の高止まりを招きかねません。
- 委託できる運用業務と保守業務の範囲
- 開発元、専門ベンダー、SIerの特徴と選び方
- RFI・RFP、評価表、契約形態、SLAの設計
- 費用監査、引継ぎ、ガバナンスの実務
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システム運用保守の発注・外注とは｜依頼先の種類と特徴
発注を検討する前に、「運用」と「保守」の違いと、委託できる業務の範囲を整理しておくことが大切です。発注範囲が曖昧なまま契約に進むと、後から「これは契約外です」と追加費用を請求されるトラブルが頻発します。
委託できる運用業務と保守業務の範囲
運用とは、システムを正常に稼働させ続けるための定常業務のことです。サーバーやネットワークの稼働監視、データのバックアップ、アクセス権限の管理、問い合わせ対応などがこれにあたります。
一方の保守は、障害発生時の原因究明と復旧対応、法改正や業務変更に伴う仕様変更・機能改修を指します。発注時は、この両者のどこまでを委託するかを明確にしておく必要があります。たとえば、「監視と問い合わせ対応は委託し、機能改修は都度見積もりで対応する」といった切り分けが一般的です。
委託範囲を曖昧にしたまま契約すると、軽微な改修まで追加費用として請求されたり、逆にベンダー側が「それは対象外です」と対応を断ったりする原因になります。そのため、発注前に運用と保守の境界線を文書で定義しておくことが、トラブル防止の第一歩です。
発注先の種類｜開発元・専門ベンダー・SIerの違い
発注先は大きく3つに分けられます。1つ目は、システムを開発した会社にそのまま保守を依頼する方法です。仕様を熟知しているため障害対応が早い反面、他社への乗り換えが難しく、ベンダーロックインに陥りやすい傾向があります。
2つ目は、運用保守を専門とするベンダーです。複数システムの監視やヘルプデスクを得意とし、コスト効率が高い一方、開発当初の経緯を知らないため引き継ぎに時間を要します。3つ目は、幅広い領域を一括で請け負うSIerやITコンサルティング企業です。
SIerは、インフラから業務システムまで横断的に管理でき、戦略的な改善提案も期待できますが、費用は相対的に高くなりがちです。自社のシステム規模や内製リソースの有無、求めるサービスレベルに応じて、3つの選択肢を比べることが大切です。発注先ごとの判断の仕方は、システム運用保守の進め方を解説した記事もあわせてご確認ください。
内製か外注かの判断基準
運用保守を外部に発注するか、社内で内製するかは、コストだけでなく、属人化リスクや事業継続性まで含めて判断する必要があります。
外注に向くケースとメリット
社内に運用保守を担える人材が足りない場合や、特定の担当者に業務が集中して属人化している場合は、外注が有力な選択肢になります。ソフトウェアのライフサイクル全体にかかるコストのうち、運用保守が占める割合は40〜80%、平均で約60%にのぼると言われています。そのため、内製で抱え込むと人件費の負担が重くのしかかります。
さらに、経済産業省の調査でも、既存システムの運用に対する支出と新規構築への支出は、おおむね2対1の比率とされています。保守領域の負担の大きさがうかがえます。
外注すれば、専門人材の確保や育成にかかるコストを抑えつつ、24時間監視や障害時の即応体制を整えられます。また、担当者の退職によって業務が止まるリスクを減らせる点も大きなメリットです。自社のコア業務にリソースを集中させたい企業ほど、運用保守を外注する効果は大きくなります。
内製を残すべき業務の見極め方
事業競争力に直結する基幹ロジックや、機密性の高いデータを扱う領域は、最終的な意思決定と監督機能を社内に残すべきです。完全に外部任せにすると、システムの中身を社内の誰も把握できない状態になりかねません。そうなると、ベンダーの言い値で費用を払い続けることにもなります。
現実的な解は、定型的な監視・運用を外注しつつ、ベンダーを管理する役割と仕様変更の優先順位付けは社内に残す、ハイブリッド型です。発注側がサービスの品質をチェックできる体制を保つことで、委託先に任せきりにせず、長期的に費用を適正に保つことにつながります。
発注先（ベンダー）選定の進め方と所要期間
運用保守の発注先選定は、思いつきで進めると失敗しやすい作業です。要件の整理から契約締結、引き継ぎまでを含めると、全体で4〜6ヶ月を要するのが一般的です。そのため、現在の契約満了や担当者の交代を見越して、逆算したスケジュールで動き出すことが成功の鍵となります。
要件定義からRFI・RFPまでの流れ
選定の出発点は、委託したい業務範囲と求めるサービスレベルを明らかにする要件定義です。続いて、候補となる複数のベンダーに情報提供を求めるRFI（情報提供依頼書）を送り、各社の対応領域や実績を把握します。
そのうえで、具体的な提案と見積もりを求めるRFP（提案依頼書）を提示し、各社から提案を集めます。ここで効果的なのは、現在契約している既存ベンダーにもRFPへ参加してもらうことです。
競争原理が働くと、既存ベンダーが契約条件を大幅に見直して提案してくるケースがあります。結果として、既存ベンダーの継続が30〜40%の確率で発生するとも言われています。新規切り替えを前提にせず、まずは現状の条件を市場価格と照らし合わせる材料として活用するのが賢明です。
評価表の作り方と配点のコツ
提案を比べる際は、感覚ではなく評価表を使って定量的に採点します。評価の項目は、技術力と実績、サポート体制などに分けます。加えて、SLAの保証内容や価格も評価に入れます。
ここでのコツは、価格の配点を全体の20点以下に抑えることです。価格の比重を上げすぎると、安かろう悪かろうの低品質なベンダーが選ばれてしまうおそれがあります。
採点は、「○は5点、△は2点、×は0点」のように差が開く配点にすると、評価のブレを抑えられます。中間点を多用すると各社が横並びになり、判断材料になりにくいためです。さらに、契約前にはPoC（概念実証）や試験的な業務委託を挟み、提案書だけでは見えない実対応力を確かめておくと、ミスマッチを防げます。
契約形態の選び方｜準委任契約と請負契約
運用保守の委託では、準委任契約と請負契約のどちらを選ぶかが法務上の重要な分岐点になります。両者は完成責任の有無や費用の扱いが異なり、業務の性質に応じて使い分ける必要があります。誤った契約形態を選ぶと、責任の所在が曖昧になり、トラブルの火種になります。
準委任と請負の違いと使い分け
準委任契約は、業務を継続的に遂行すること自体に対価を支払う形態で、完成させる責任は負いません。監視業務や問い合わせ対応、定期点検など、明確な完成形を定義しにくい定常業務に適しています。
一方の請負契約は、特定の納品物を完成させることを約束する形態です。機能改修やバージョンアップなど、完成形がはっきりしている業務には、こちらを選ぶのが自然です。実務では、月額定額の運用監視は準委任、都度発生する改修案件は請負として、1つのベンダーと2つの契約を併用するケースも多く見られます。
それぞれの業務の性質に合わせて契約形態を選ぶと、責任範囲が明確になります。その結果、後々のトラブルを回避できます。
印紙税の扱いという見落としがちな論点
契約形態の選択には、印紙税という実務上のメリットも関わります。保守契約を準委任契約として締結した場合は、課税文書である第7号文書に該当せず、収入印紙が不要になるケースが多くあります。一方、請負契約は課税文書となり、契約金額に応じた収入印紙の貼付が必要です。
継続的な運用監視を準委任で契約すれば、印紙税のコストを抑えられる可能性があります。ただし、課税区分は契約の名称ではなく、契約の実態によって決まる点に注意が必要です。判断に迷う場合は、税理士や法務担当者に確認したうえで契約形態を決めるのが安全です。
契約書で必ず押さえるべき条項と落とし穴
運用保守の発注トラブルの多くは、契約書の記載不備に起因します。発注時に勢いで契約を交わすと、障害やデータ漏えいが起きたときに「責任は誰にあるのか」「どこまでが対象なのか」で揉めることになります。そのため、契約段階で詰めておくべき条項を確認しておく必要があります。
保守対象範囲・免責・解除条件の明記
契約書には、保守対象範囲と費用・支払い方式を最低限明記すべきです。加えて、免責事項と契約解除条件も定めておく必要があります。なかでも免責事項は、ベンダー有利になりすぎていないかを、発注側がチェックすべき項目です。
免責の範囲が広すぎると、障害が起きても「免責に該当する」として一切の補償を受けられない事態になりかねません。契約解除の条件も欠かせません。乗り換えを決めたときに円滑に契約を終えられるよう、解約予告期間とデータ返却の手続きをあらかじめ定めておきます。
ここが曖昧だと、解約時にデータの引き渡しを渋られたり、高額な移行支援費用を請求されたりする、ベンダーロックインのリスクが残ります。契約や費用の妥当性をさらに深掘りしたい場合は、システム運用保守の費用相場を解説した記事も参考にしてください。
ハードウェア保守の所有権という盲点
意外と見落とされやすいのが、ハードウェア保守における故障部品の所有権です。たとえば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の目標値とペナルティを交渉し、作業報告書やログで費用を監査し、余裕を持った引き継ぎ体制を組むことで、長期にわたる安定稼働と適正なコストを両立できます。
本記事を参考に、自社にとって最適な発注の進め方を設計していただければ幸いです。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。