IT運用保守の発注は、委託範囲の決定から費用の監査と引継ぎまで、次の順に進めます。運用保守は一度委託すると数年単位の付き合いになるため、発注先の選定や契約条件の詰め方を誤ると、後から取り返しのつかないコストを背負い込むことになります。
- 運用と保守の範囲、内製と外注の判断
- RFI・RFP、評価表、SLAの設計と交渉
- 準委任と請負、契約書の落とし穴
- 費用監査と新ベンダーへの引継ぎ
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
IT運用保守を外注する前に押さえる委託範囲と判断の目安
発注の巧拙は、何をどこまで委託するのかという範囲の定義で、ほぼ決まります。委託範囲が曖昧なまま見積もりを取ると、各社の提案の前提がばらばらになって比較ができず、契約後に「それは対象外です」と言われるトラブルの原因になります。そこで、まずは自社の運用保守業務を洗い出し、外注する領域と内製で残す領域を切り分けます。
「運用」と「保守」を分けた委託範囲の定義
IT運用保守は、性質の異なる二つの業務の集合体です。「運用」は、システムを正常に稼働させ続けるための定常業務です。その中には、稼働監視、データバックアップ、アクセス権限の管理のほか、ユーザーからの問い合わせ対応も含まれます。
一方の「保守」は、障害が発生した際の原因究明と復旧、あるいは仕様変更に伴う改修やアップデートを指します。発注書では、この二つを明確に分けて記述することが、後のトラブルを防ぐ第一歩になります。
委託範囲の定義は、見積もり精度と契約の安全性を同時に高める作業です。たとえば、「監視」は運用に含めて準委任で継続的に委託し、「機能改修」は保守のなかでも成果が明確なため、都度の請負契約とする、といった切り分けが現実的です。反対に、この境界線を曖昧にしたまま「運用保守一式」で発注すると、想定外の改修依頼が「追加費用」として跳ね返り、予算超過を招きます。
内製で残すか外注するかの判断基準
ソフトウェア全体のコストのうち運用保守が占める割合は、40〜80%で、平均では約60%にのぼると言われます。経済産業省の調査でも、「従来システムの運用」と「新規構築」への支出は、全産業平均でおよそ2対1の構造になっています。つまり運用保守は企業のIT予算の主役で、どこを外注するかによってコスト構造が大きく変わります。
外注する業務は、業務ごとに選んで決めます。判断の目安としては、自社の競争力に直結するコア業務の知識が要る領域は内製で残し、定型的で属人性の低い監視や一次対応などは外注に回すのが基本です。
ただし、社内に運用保守の知見が乏しく、属人化やブラックボックス化のリスクが高い場合は、むしろ外注を機にドキュメントを整備し、知識を見える形にする好機と捉えるとよいでしょう。発注の進め方そのものについては、IT運用保守の進め方/やり方/流れや方法/手法/工程/手順もあわせて参考にしてください。
発注先ベンダーの選定プロセスと評価表の作り方
発注先の選定は、行き当たりばったりで進めると失敗します。要件定義に始まり、RFI、RFPを経て、評価と契約へと段階的に進めるのが定石で、全体では4〜6ヶ月を要するのが一般的です。
逆算すると、現契約の満了6ヶ月前には動き出さないと、十分な比較検討も引継ぎもできずに既存ベンダーへ追随更新せざるを得なくなります。そのため、最初にスケジュールを確保しておくことが、有利な発注の前提条件になります。
RFI・RFPの準備と記載すべき項目
選定の起点は、候補ベンダーへ情報提供を求めるRFI（情報提供依頼書）と、具体的な提案を求めるRFP（提案依頼書）です。RFPには、委託対象システムの構成と、現行の運用保守業務の範囲を書きます。そのうえで、求めるSLAの水準と対応時間帯、報告体制を明記し、契約形態の希望も書き添えます。
前段で定義した委託範囲をそのまま落とし込めば、各社は同じ前提で提案でき、提案を横並びで比べられます。ここで効果的なのが、現行ベンダーもRFPに参加させる方法です。
競争原理が働くと契約条件の大幅な見直しが起こり、結果として既存ベンダーが継続するケースが30〜40%の確率で発生すると言われます。新ベンダーへの切り替えを前提にしなくても、相見積もりの場を作るだけで条件改善の交渉材料が手に入ります。
提案を比較する評価表の配点設計
技術力、実績、価格といった評価軸を設け、各軸に配点を割り振った評価表で、複数社の提案を定量的に比べます。SLAの保証水準とサポート体制も、評価軸に加えます。発注先の比較検討にはIT運用保守でおすすめの開発会社/ベンダー6選と選び方も役立ちます。
運用保守は、価格よりも継続的な品質が成否を分けるため、価格の配点は全体の20点以下に抑えておきます。そうすれば、安さだけで品質の低いベンダーが上位に来る事態を防げます。
点数の付け方にもコツがあり、「○は5点、△は2点、×は0点」のように差を大きく開かせると、各社の優劣が明確になり評価のブレを抑えられます。一方で、1点刻みの細かい採点は評価者の主観が入り込みやすく、結局は印象で決まってしまいがちです。また、契約前には、PoC（概念実証）として一部業務を試行してもらい、提案書だけでは見えない実力を確認することも有効です。
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とペナルティ条項には根拠を持たせ、契約形態と落とし穴にも目を配ることが大切です。
さらに、作業報告書やログから実稼働を割り出す監査の視点を持てば、費用の妥当性も自分の目で判断できるようになります。これらを順序立てて進めることで、発注後のトラブルを大幅に減らせます。
運用保守は数年単位で続く関係だからこそ、発注時の準備が後々のコストと安心を大きく左右します。自社だけで進めるのが不安な場合は、コンサルティングから開発・運用までを一貫して支援できるパートナーに相談しながら、発注プロセスを設計していくのが確実です。本記事を、自社の委託準備を一歩前に進めるための実務指針として活用してください。
▼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を創業。