IT運用保守を外部に委託したいものの、「どこにどう発注すればよいのか」「いまの保守費用は適正なのか」「契約後に追加費用やトラブルが出ないか」といった不安から、なかなか一歩を踏み出せずにいる担当者は少なくありません。運用保守は一度委託すると数年単位の付き合いになるため、発注先の選定や契約条件の詰め方を誤ると、後から取り返しのつかないコストを背負い込むことになります。
本記事では、IT運用保守の発注・外注・委託の具体的な進め方を、RFP（提案依頼書）の準備から評価表の作り方、SLA（サービスレベル合意）の交渉術、準委任契約と請負契約の使い分け、そして引継ぎ実務まで一気通貫で解説します。さらに、現行の保守費用が「ぼったくり」になっていないかを相見積もり以外で見抜く監査の視点や、契約書に潜む落とし穴まで踏み込みます。読み終えたときには、自社で発注準備を進められる実務知識が身についているはずです。
IT運用保守を外注する前に押さえる委託範囲と判断軸
発注の巧拙は、何をどこまで委託するのかという「範囲の定義」でほぼ決まります。委託範囲が曖昧なまま見積もりを取ると、各社の提案前提がバラバラになり比較もできず、契約後の「それは対象外です」というトラブルの温床になります。まずは自社の運用保守業務を棚卸しし、外注すべき領域と内製で残す領域を切り分けることから始めます。
「運用」と「保守」を分けて委託範囲を定義する
IT運用保守は、性質の異なる二つの業務の集合体です。「運用」はシステムを正常に稼働させ続けるための定常業務で、稼働監視、データバックアップ、アクセス権限の管理、ユーザーからの問い合わせ対応などが含まれます。一方の「保守」は、障害が発生した際の原因究明と復旧、あるいは仕様変更に伴う改修やアップデートを指します。発注書ではこの二つを明確に分けて記述することが、後のトラブル防止の第一歩になります。
たとえば「監視」は運用に含めて準委任で継続的に委託し、「機能改修」は保守の中でも成果物が明確なため都度の請負契約とする、といった切り分けが現実的です。この境界線を曖昧にしたまま「運用保守一式」で発注すると、想定外の改修依頼が「追加費用」として跳ね返り、予算超過を招きます。委託範囲の定義は、見積もり精度と契約の安全性を同時に高める作業だと理解してください。
内製で残すか外注するかの判断基準
すべてを外注すればよいわけではありません。ソフトウェア全体のコストのうち運用保守が占める割合は40〜80%、平均で約60%にのぼると言われ、経済産業省の調査でも「従来システムの運用」と「新規構築」への支出は全産業平均でおよそ2対1の構造になっています。つまり運用保守は企業のIT予算の主役であり、どこを外注するかでコスト構造が大きく変わります。
判断軸としては、自社の競争力に直結するコア業務の知識が必要な領域は内製で残し、定型的で属人性の低い監視・一次対応などは外注に回すのが基本です。社内に運用保守の知見が乏しく属人化・ブラックボックス化のリスクが高い場合は、むしろ外注を機にドキュメントを整備し、知識を可視化する好機と捉えると良いでしょう。発注の進め方そのものについては、IT運用保守の進め方/やり方/流れや方法/手法/工程/手順もあわせて参考にしてください。
発注先ベンダーの選定プロセスと評価表の作り方
発注先の選定は、行き当たりばったりで進めると失敗します。要件定義からRFI、RFP、評価、契約までを段階的に踏むのが定石で、全体では4〜6ヶ月を要するのが一般的です。逆算すると、現契約の満了6ヶ月前には動き出さないと、十分な比較検討も引継ぎもできずに既存ベンダーへ追随更新せざるを得なくなります。スケジュールを最初に確保することが、有利な発注の前提条件です。
RFI・RFPの準備と記載すべき項目
選定の起点は、候補ベンダーへ情報提供を求めるRFI（情報提供依頼書）と、具体的な提案を求めるRFP（提案依頼書）です。RFPには委託対象システムの構成、現行の運用保守業務の範囲、求めるSLAの水準、対応時間帯、報告体制、そして契約形態の希望を明記します。前段で定義した委託範囲をそのまま落とし込むことで、各社が同じ前提で提案でき、比較可能性が担保されます。
ここで効果的なのが、現行ベンダーもRFPに参加させる方法です。競争原理が働くことで契約条件の大幅な見直しが起こり、結果として既存ベンダーが継続するケースが30〜40%の確率で発生すると言われます。新ベンダーへの切り替えを前提にしなくても、相見積もりの場を作るだけで条件改善の交渉材料が手に入るのです。
提案を比較する評価表の配点設計
複数社の提案を主観で並べても良い発注先は選べません。技術力、実績、SLAの保証水準、サポート体制、価格といった評価軸を設け、各軸に配点を割り振った評価表で定量的に比較します。ここで重要なのが価格の扱いです。価格の配点を全体の20点以下に抑えると、安さだけで品質の低いベンダーが上位に来る事態を防げます。運用保守は価格よりも継続的な品質が成否を分けるためです。
点数付けにもコツがあります。「○は5点、△は2点、×は0点」のように差を大きく開かせると、各社の優劣が明確になり評価のブレを抑えられます。1点刻みの細かい採点は評価者の主観が入り込みやすく、結局は印象で決まってしまいがちです。契約前にはPoC（概念実証）として一部業務を試行してもらい、提案書だけでは見えない実力を確認することも有効です。発注先の比較検討にはIT運用保守でおすすめの開発会社/ベンダー6選と選び方も役立ちます。
SLAの設定とベンダーに条件をのませる交渉術
発注における品質担保の要がSLAです。SLAとは、稼働率や障害復旧時間などのサービス水準を発注者とベンダーの間で定量的に合意するもので、これがなければ「ちゃんとやっています」という主観的な言い分に振り回されることになります。発注段階でSLAをどこまで具体的に詰め、未達時のペナルティをどう設計するかが、委託の成否を大きく左右します。
発注書に盛り込むSLAの具体的な目標値
SLAの目標値は感覚で決めず、公的なガイドラインを参照すると説得力が増します。たとえば大阪市のガイドラインでは、サーバ・アプリの稼働率99.8%以上、基準応答時間達成率93%（3秒以内）、重大障害は年2回まで、障害通知遵守率100%（発生後30分以内）、ヘルプデスクの電話応答率97%以上（平均20秒以内）といった水準が示されています。こうした実在の基準値を発注書に引用することで、ベンダーに対して根拠ある要求が可能になります。
設定する指標は、自社のシステムが止まったときの業務影響度に応じて優先順位を付けます。基幹システムなら稼働率と復旧時間を最優先に、問い合わせ対応が多いシステムなら応答率を重視するといった具合です。すべてを最高水準にすると費用が跳ね上がるため、メリハリのある設計が現実的です。
ペナルティ条項をのませる交渉のテクニック
SLAは目標値を定めるだけでは形骸化します。未達時のペナルティ（料金減額や改善勧告）と、目標を上回った場合のインセンティブ報酬を組み合わせることで、ベンダーに品質維持の動機を持たせられます。ペナルティ条項はベンダーが嫌がる項目ですが、「他社では同等のペナルティ条項を受け入れている」という事例を交渉材料に提示すると、のませやすくなります。
交渉では一方的にペナルティを押し付けるのではなく、達成時の評価とセットにするのが長続きのコツです。減点だけの関係はベンダーの疲弊と防衛的な対応を招き、結果的に質が下がります。SLAは合意（Agreement）であると同時に管理（SLM＝サービスレベル管理）であり、定期的なレビューの場で数値を確認し、必要に応じて見直す運用までを発注時に取り決めておきましょう。
準委任契約と請負契約の使い分けと契約書の落とし穴
発注の最終局面は契約です。運用保守の委託では、契約形態の選択と契約書の条項設計を誤ると、障害発生時の責任の所在や追加費用をめぐって深刻なトラブルに発展します。とくに免責事項がベンダー有利に書かれていないか、保守対象範囲が明確かといった点は、署名前に必ず確認すべきです。
準委任契約と請負契約の選び方
準委任契約は、継続的なサービス提供を約束するもので、成果物の完成責任は負いません。監視や問い合わせ対応といった、結果よりもプロセスの遂行が重要な業務に適しています。一方の請負契約は、明確な成果物の完成を約束するもので、機能改修やアップデートのように成果が定義できる作業に向いています。運用保守は両者が混在するため、業務ごとに契約形態を分ける、あるいは基本契約と個別契約を組み合わせる設計が実務的です。
契約形態の選択には税務上のメリットも絡みます。保守契約を準委任契約とすると、印紙税法上の第7号文書に該当せず、収入印紙が不要になるケースが多いのです。請負契約だと契約金額に応じた印紙が必要になるため、長期・高額の契約ほどこの差は無視できません。契約形態は法務・税務の観点も交えて決めるべき論点です。
契約書に潜む落とし穴と必須記載事項
契約書には、保守対象範囲、費用と支払い方式、免責事項、契約解除条件を必ず明記します。これらが曖昧だと、「その作業は対象外」という追加費用の請求や、解約時の高額な違約金といったトラブルが起こります。とくに見落としがちなのがハードウェア保守における所有権の問題です。HDD交換時、取り外した故障部品の所有権は保守会社に帰属するのが一般的で、機密データの確実な破棄を求めるなら別途の契約や条項が必要になります。
クラウド利用が前提の場合は、責任分界点の明確化が欠かせません。AWSやAzureなどのパブリッククラウドには責任共有モデルがあり、どこまでがクラウド事業者の責任で、どこからがユーザー側の責任かが定められています。このユーザー責任領域を自社情シスが負うのか、保守ベンダーに委託するのかを契約で切り分けておかないと、障害時に責任の押し付け合いが起きます。誰が何に責任を持つかを示すRACIチャートを作成し、契約書に添付しておくと安全です。
委託費用の妥当性を見抜く監査と引継ぎの実務
発注を決めても、提示された費用が適正かどうかは別問題です。とくに既存ベンダーへの継続発注では、「この保守費用は高すぎるのではないか」という疑念がつきまといます。相見積もりは有効な手段ですが、それ以外にも費用の妥当性を見抜く方法があります。あわせて、新ベンダーへ切り替える際の引継ぎ実務も、発注の成否を左右する重要工程です。
作業報告書とログから実稼働を割り出す監査
保守費用の妥当性を相見積もり以外で検証するには、ITデューデリジェンスの視点が役立ちます。具体的には、ベンダーから提出される作業報告書やサーバーログを突き合わせ、実際にどれだけの工数が稼働しているかを算出する方法です。月額固定で契約していても、実稼働時間が請求額に見合わないなら、適正価格への見直しを交渉する根拠になります。保守作業の中で最も時間を要するのは「調査・分析」で全作業時間の約30%を占めるとされ、この内訳を把握しておくと報告書の妥当性も判断しやすくなります。
費用を比較する際は、月額だけを見て新ベンダーが安いと飛びつかないことも大切です。新ベンダーの月額が安くても、移行コストが300〜500万円かかるなら、5年間の総保有コスト（TCO）では既存継続のほうが安くなる逆転現象が起こり得ます。発注判断は単年度ではなく数年スパンで行うべきです。費用相場の詳細はIT運用保守の見積相場や費用/コスト/値段についてで詳しく解説しています。
新ベンダーへのスムーズな引継ぎ体制
発注先を切り替える場合、引継ぎの巧拙が初期の安定稼働を決めます。効果的な体制は、新担当を1.0人月確保しつつ、現行担当者に週2日程度のサポートに入ってもらう形です。いきなり全業務を引き渡すのではなく、2ヶ月程度のOJTをかけて段階的に移管すると、暗黙知の取りこぼしを防げます。契約満了の6ヶ月前から動き出すべき理由の一つが、この引継ぎ期間の確保にあります。
万一、ドキュメントが整備されないまま属人化が進み、キーマンが突然退職するような事態に陥った場合は、緊急のサバイバル対応が必要です。近年は、当初の仕様を知るスタッフがいない古いシステムに対し、AIに既存コードを解析させてブラックボックス化を解消するリバースエンジニアリングの代行も現実的な選択肢になっています。発注先を選ぶ際には、こうしたレガシー解読の実績があるかも確認しておくと安心です。発注・委託の手順全体はIT運用保守の完全ガイドでも体系的に整理しています。
まとめ
IT運用保守の発注・外注・委託を成功させる鍵は、委託範囲の明確な定義、4〜6ヶ月を見込んだ選定スケジュール、定量的な評価表、根拠ある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を創業。