運用保守の発注は、まず運用と保守の業務範囲を線引きし、内製か外注かを判断したうえで、委託先と契約形態を決めていく流れで進みます。
RFPで各社の提案を比べ、SLAと責任分界、契約書の条項を取り決めたあとに、引継ぎへ進みます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運用保守の発注・外注の定義
運用保守の発注とは、システムの稼働を維持し続けるための業務を、外部の専門会社に委託することです。
発注するときは、「運用」と「保守」という性質の異なる二つの業務を、どこまで任せるかを先に線引きしておく必要があります。
この境界が曖昧なまま発注すると、後になって「それは契約範囲外です」「追加費用が必要です」と言われ、トラブルになりやすくなります。そのため、発注実務の出発点は、業務範囲を言葉にして決めることにあります。
「運用」と「保守」の発注範囲の分け方
運用は、システムの正常稼働を維持するための定常業務で、稼働監視、データのバックアップ、アクセス権限の管理、ユーザーからの問い合わせ対応などが該当します。一方、保守は、障害時の原因究明と復旧や、法改正・業務変更に伴うプログラムの改修といった、非定常で技術的な対応を指します。
前者は「止めないための仕事」、後者は「直す・変える仕事」と考えると分かりやすいです。運用は手順化しやすく、比較的安定したコストになります。これに対して保守は、障害の規模や改修の難易度によって工数が大きく変動します。
発注時にこの二つを分けるべきなのは、必要なスキルも費用の構造も大きく異なるからです。そのため、委託契約書では「監視と一次対応までを運用として定額で、二次対応以降の改修は別途見積りで」のように、定額の範囲と追加費用の線を発注段階で決めておくことが大切です。
内製と外注の判断基準
発注の前に、そもそも運用保守を外注すべきかを判断しておく必要があります。判断の観点は、社内に対象システムを理解した人材がいるか、24時間365日の対応が必要か、運用保守に人を割くことが本業にとって合理的か、という三点です。
たとえば、社内SEが一人しかおらず、その人が退職するとシステムがブラックボックス化してしまうような状況であれば、外注によって属人化リスクを下げる意義は大きいといえます。外注のメリットは、専門人材の採用・育成コストを抑えながら、安定したサービス品質と障害対応体制を確保できる点です。
一方で、システムの内部知識が社外に蓄積されるため、ベンダーへの依存度が高まりやすい面もあります。そのため、発注の段階で定期報告やドキュメント納品を契約に盛り込み、自社にも知見が残る仕組みを設けておくことが、健全な委託関係を保つうえで欠かせません。
委託先の種類と選び方
運用保守の委託先は、大きく三つの類型に分けられます。開発を担当したベンダーへの継続委託、開発元とは別の保守専門会社への移管、自社の情シスを補うITアウトソーシング会社です。
それぞれにメリットと注意点があり、どの委託先が合うかは、システムの複雑さや社内体制によって変わります。そのため、発注先を選ぶ際は、価格だけでなく対応範囲・体制・引継ぎコストを合わせて評価することが大切です。
開発元への継続委託と別会社への移管
開発を担当したベンダーにそのまま保守を任せると、システムの内部仕様を熟知しているため引継ぎコストがかからず、障害対応も迅速になりやすいという利点があります。その反面、競争が働きにくく保守費用が高止まりしやすいため、「言い値」で契約を更新し続けてしまうおそれがあります。
発注側は、開発元の利便性を享受しつつ、定期的に費用の妥当性を検証する仕組みを持つことが大切です。一方、開発元とは別の保守専門会社へ移管する場合は、相見積もりによってコストを見直せる可能性があります。
ただし、新しいベンダーはシステムを理解するための引継ぎが必要で、そこに想定外の時間と費用がかかる点に注意が必要です。仮に新ベンダーの月額が安くても、移行コストが300万〜500万円規模になると、5年間のトータルコスト（TCO）で見ると逆転することもあります。そのため、目先の月額だけでなく、移行費用まで含めた総額で比べる視点が欠かせません。
評価表の作り方と価格の配点
複数の委託先候補を客観的に比べるには、評価表を使った採点が有効です。評価軸は、次の5項目です。
- 技術力
- 対応体制
- SLAの保証水準
- 実績
- 価格
価格の配点を全体の20点以下に抑えるのが、意外と知られていないコツです。価格の比重が高すぎると、品質や体制が不十分でも安いベンダーが上位に来て、障害対応で苦労するケースが起こりがちだからです。
採点では、「○は5点、△は2点、×は0点」のように差が開く配点にすると、評価のブレを抑えつつ、ベンダー間の優劣を明確にできます。反対に、中間点を細かく刻みすぎると、どの会社も似た総合点になり、決め手を欠いてしまいます。
社内で意思決定を説明する際にも、明確な評価表があれば説得力が増し、稟議も通りやすくなります。
委託先を具体的に比べたい場合は、運用保守でおすすめの開発会社・ベンダー6選と選び方もあわせてご覧ください。発注の進め方全体は、運用保守の進め方・流れ・手順が参考になります。
契約形態の選び方と発注の進め方
運用保守の発注では、契約形態の選び方が費用と責任の所在を大きく左右します。主に使われるのは準委任契約と請負契約の二つで、業務の性質に応じて使い分けるのが基本です。
発注の流れは、要件定義から始まり、RFI・RFPによる提案募集、評価・選定を経て、契約締結と引継ぎへと進みます。特に、契約満了の6ヶ月前には動き出しておくと、余裕を持って進められます。
準委任契約と請負契約の使い分け
準委任契約は、継続的にサービスを提供することを約束する契約で、完成責任を負わない点が特徴です。監視や問い合わせ対応のように、何を完成させるかを定めにくい定常業務に適しています。一方、請負契約は、成果物を完成させることを約束する契約で、特定機能の改修やバージョンアップといった「やり切る」作業に向いています。
運用保守では、定常的な運用を準委任で、個別の改修を請負で発注する、ハイブリッドな組み方が現実的です。また、契約形態の選択には、税務上のメリットも関わってきます。
保守契約を準委任契約として締結すると、印紙税法上の第7号文書として扱われ、収入印紙が不要になるケースが多いのです。これに対して請負契約では、契約金額に応じた収入印紙が必要になるため、年間契約や長期契約では無視できない差になることもあります。契約形態は責任の所在だけでなく、こうしたコスト面も踏まえて選ぶとよいでしょう。
RFP作成から選定までの手順
発注の中核となるのが、RFP（提案依頼書）の作成です。RFPには、対象システムの概要、求める運用保守の範囲、希望するSLAの水準を明記します。さらに、対応時間帯、報告体制、提案してほしい体制と費用の内訳も書き込みます。
RFPの条件を曖昧にすると、各社の提案がバラバラの前提で出てきて、横並びの比較ができなくなります。また、ベンダー選定全体には4〜6ヶ月程度を見込んでおくと、慌てずに進められます。
有効なのは、既存ベンダーもあえてRFPに参加させ、発注を条件見直しの機会として使うことです。新規候補と並べて競わせると競争原理が働き、既存ベンダーが条件を大幅に見直してくることがあります。実務上、こうしたコンペを経て既存ベンダーが継続するケースは30〜40%程度あるとされ、乗り換えなくても保守費用の適正化という成果が得られます。
発注時のSLAと責任分界の取り決め
発注時に特に力を入れて取り決めたいのが、SLA（サービスレベル合意）と責任分界です。SLAは、サービス品質を定量的に約束させる仕組みで、曖昧なまま契約すると、障害が起きても「契約上の義務違反ではない」と言われかねません。
クラウド利用が当たり前になった今、どこまでがベンダーの責任で、どこからが自社の責任かを明確にしておくと、いざというときの押し付け合いを防げます。
SLAとペナルティ条項をのませる交渉術
SLAでは、サーバーやアプリの稼働率、障害発生時の応答時間と復旧時間、ヘルプデスクの応答率といった項目を、数値で約束させます。参考になるのは自治体の公開ガイドラインで、たとえば大阪市の例では、稼働率99.8%以上、基準応答時間（3秒以内）の達成率93%、重大障害は年2回までといった水準が示されています。
ほかにも、障害発生後30分以内の通知遵守率100%、ヘルプデスクの電話応答率97%以上（平均20秒以内）の水準があります。こうした既存の基準を交渉の出発点にすると、ベンダーも「公的なガイドラインに準じている」と納得しやすくなります。加えて、他社で同水準のSLAを締結している事例を交渉材料として提示するのも、有効な一手です。
SLAを実効性のあるものにするには、未達時のペナルティ条項をセットで取り決めることが欠かせません。たとえば、目標未達が続いた場合に保守費用の一部を減額する、あるいは改善勧告を行うといったルールを契約に盛り込みます。さらに、交渉が難航する場合は、減額だけでなく、目標を上回った際のインセンティブ報酬を組み合わせると、ベンダー側も前向きに受け入れやすくなります。
クラウド時代の責任分界とRACIの考え方
AWSやAzureなどのパブリッククラウドを使う場合、クラウド事業者、保守ベンダー、自社の三者の間で責任が分かれます。クラウドには責任共有モデルという考え方があり、物理基盤の管理は事業者が担う一方、OSやミドルウェア、アプリケーションの設定はユーザー側の責任となります。
このユーザー責任を、自社の情シスが負うか保守ベンダーに委託するかを発注時に決めておかないと、障害時に「それはそちらの領域です」という押し付け合いが起こります。責任分界を整理する実務ツールとして有効なのがRACIで、各作業について「実行責任者（R）」「説明責任者（A）」「相談先（C）」「報告先（I）」を一覧にする手法です。
監視・パッチ適用・バックアップ・障害一次対応といった項目ごとに、誰が何を担うかを表にまとめます。これを契約書の別紙として添付すると、責任の所在が一目で分かり、いざというときの判断も迅速になります。さらに、発注の段階でこの表をベンダーと共同で作り込むことは、信頼関係を築くうえでも役立ちます。
契約書の落とし穴と費用の妥当性チェック
発注の最終段階である契約書の取り交わしには、見落とされがちな落とし穴がいくつもあります。また、契約後も、今支払っている保守費用が本当に適正かを継続的に検証する視点を持つことが、無駄なコストを防ぐことにつながります。
契約書で押さえたい条項と、相見積もり以外で費用の妥当性を見抜く監査の考え方を、順に確認していきます。
契約書で見落としがちな条項
運用保守契約書には、保守対象範囲、費用と支払い方式、免責事項、契約解除条件を必ず明記します。特に免責事項は、トラブルの火種になりやすいため、ベンダー有利に書かれすぎていないかを発注側が確かめる必要があります。たとえば、「天災を含む不可抗力」の範囲が広すぎたり、ベンダーの過失による障害まで免責に含まれていたりすると、いざというときに泣き寝入りになりかねません。
意外と知られていない落とし穴として、ハードウェア保守における故障部品の所有権があります。HDDなどを交換した際、取り外した故障部品の所有権は保守会社に帰属するのが一般的です。そのため、機密データが記録された部品の確実な破棄を求めるなら、その旨を別契約や特約として明記しておく必要があります。
これを怠ると、データを含んだ部品が保守会社の手元に残り、情報漏洩のリスクになりかねません。発注時にこうした細部まで詰めておくことが、後顧の憂いを絶つことにつながります。
保守費用の妥当性の監査
「今の保守費用が割高になっていないか」という不安は、多くの発注担当者が抱えるものです。相見積もりを取るのが王道ですが、それ以外にも、費用の妥当性を見抜く方法があります。その方法が、実際の稼働時間を割り出す監査です。
月額の定額契約であっても、作業報告書の対応内容と、サーバー側のログに残る作業履歴を突き合わせれば、おおよその実稼働工数を逆算できます。この実稼働工数に市場の人月単価を掛け合わせれば、支払っている費用が実態に見合っているかを定量的に評価できます。保守は、ソフトウェア全体コストの40〜80%（平均で約60%）を占めるといわれるほど大きな支出です。
また、保守作業のうち最も時間を要するのは調査・分析で、全体の約30%を占めるとされています。この構造を踏まえ、報告に調査・分析の記録が適切に残っているかを確かめると、費用の透明性を高められます。費用相場の詳細は、運用保守の見積相場や費用についてで解説しています。
引継ぎと発注パートナーの選定
発注先が決まったあとに意外と軽視されがちなのが、引継ぎです。特に既存ベンダーから新しいベンダーへ移管する場合は、引継ぎの巧拙がその後の運用品質を大きく左右します。また、属人化が進んだシステムでは、キーマンが突然退職する事態に備えて、平時から知見を残す体制を発注時に組み込んでおくことも大切です。
スムーズな引継ぎと属人化への備え
引継ぎを成功させるには、十分な期間と並走体制を確保することが鍵です。実務的には、新しい担当者を1.0人月程度投入し、現行の担当者には週2日程度のサポートに入ってもらう形が効果的とされています。また、一定期間は両者が並走することで、ドキュメントに残しきれない暗黙知やトラブル時の勘所が自然に移転されます。
発注時に、この並走期間とサポート体制を契約条件として明記しておくと、引継ぎの空白期間によるサービス低下を防げます。さらに、ドキュメントがほとんどない状態でキーマンが退職した場合の備えも、考えておきたいところです。近年は、既存のソースコードをAIに解析させて仕様を読み解く、リバースエンジニアリングの代行も使われています。
発注の段階で、こうしたブラックボックス化の解消まで支援できるパートナーかどうかを確認しておくと、いざというときの安心感が変わります。なお、属人化対策やAIの活用を含めた全体像は、運用保守の完全ガイドで網羅的に解説しています。
発注先選びで迷ったら相談できるパートナー
運用保守の発注は、契約形態の選択からSLA設計、責任分界の取り決めまで、検討すべき論点が多岐にわたります。そのため、単に作業を請け負うだけでなく、上流の要件整理や契約面の助言まで含めて相談できるパートナーを選ぶと、発注の成功確率が高まります。
株式会社riplaは、コンサルティングから開発・運用まで一気通貫で支援できる企業です。IT事業会社として自社のDXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みを持っています。また、riplaは、営業・顧客・生産・販売管理といった幅広い基幹システムの構築・導入実績があり、業務要件に合わせて柔軟に対応できます。
これから運用保守を外注したい、あるいは今の保守体制を見直したいといった段階から、業務範囲の整理や契約条件の検討を一緒に進められるのが強みです。特に、発注の進め方に不安がある場合は、早い段階で専門家に相談することで、後から発生しうるトラブルやコストの無駄を未然に防ぐことができます。
まとめ
運用保守の発注・外注は、作業を引き受ける会社を探すことよりも、運用と保守の範囲を線引きして、契約形態、SLA、責任分界を取り決める設計の仕事です。
準委任と請負は業務の性質に応じて使い分け、SLAにはペナルティ条項を、クラウド利用時にはRACIによる責任分界を盛り込みます。これにより、後のトラブルを大きく減らせます。
契約満了の6ヶ月前から動き出し、4〜6ヶ月かけて評価表を用いた選定を進めると、余裕を持って進められます。
既存ベンダーをあえてコンペに参加させて条件を見直すことや、作業報告書とログから実稼働工数を逆算して費用の妥当性を監査することも、保守コストの適正化につながります。
免責事項やHDDの所有権といった契約書の細部まで目を配り、引継ぎ時には並走期間を確保します。こうした対応が、安心して任せられる委託関係を築くことにつながります。
この内容を参考に、自社に合った発注の形を組み立ててください。発注先選びや契約面で迷ったときは、上流から相談できるパートナーに早めに声をかけることをおすすめします。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。