運用保守を外部に発注しようと考えたとき、「どこに、どの契約形態で、どこまでの範囲を任せればよいのか」が分からず手が止まってしまう担当者は少なくありません。開発は無事に終わったものの、その後のシステムを社内だけで支え続けるのは難しく、かといって既存ベンダーに言われるまま保守契約を更新し続けてよいのか不安が残る、というのが多くの企業の本音ではないでしょうか。運用保守の発注は、単に「作業をやってくれる会社を探す」こととは違い、契約形態の選択・SLAの設計・責任分界の取り決めといった実務知識がそのまま費用とリスクに直結します。
本記事では、運用保守を外注・委託する際の具体的な進め方を、発注実務の観点から徹底的に解説します。委託先の種類と選び方、準委任契約と請負契約の使い分け、SLAやペナルティ条項をベンダーにのませる交渉術、そして「今の保守費用が適正か」を相見積もり以外で見抜く監査の考え方まで、契約担当者が知っておくべき勘所を網羅しました。読み終えるころには、発注の全体像と「後で揉めないための契約のつくり方」が具体的にイメージできるはずです。
運用保守の発注・外注とは何か
運用保守の発注とは、システムの稼働を維持し続けるための業務を外部の専門会社に委託することを指します。ここで重要なのは、発注の前提として「運用」と「保守」という性質の異なる二つの業務をどこまで任せるのかを線引きすることです。この境界が曖昧なまま発注すると、後から「それは契約範囲外です」「追加費用が必要です」というトラブルに発展しやすくなります。発注実務の出発点は、業務範囲の言語化にあると言っても過言ではありません。
「運用」と「保守」を分けて発注範囲を決める
運用とは、システムの正常稼働を維持するための定常業務を指します。具体的には、稼働監視、データのバックアップ、アクセス権限の管理、ユーザーからの問い合わせ対応などが該当します。一方の保守とは、障害が発生した際の原因究明と復旧、あるいは法改正や業務変更に伴うプログラムの改修といった、非定常で技術的な対応を指します。前者は「止めないための仕事」、後者は「直す・変える仕事」と整理すると分かりやすいでしょう。
発注の際にこの二つを明確に分けるべき理由は、求められるスキルも費用構造も大きく異なるからです。運用は手順化しやすく比較的安定したコストになりますが、保守は障害の規模や改修の難易度によって工数が大きく変動します。委託契約書では「監視と一次対応までを運用として定額で、二次対応以降の改修は別途見積りで」といった具合に、どこまでが定額の範囲でどこからが追加費用なのかを発注段階で握っておくことが、後のトラブル防止につながります。
内製と外注の判断基準
発注を検討する前に、そもそも運用保守を外注すべきなのかを判断する必要があります。判断軸となるのは、社内に対象システムを理解した人材がいるか、24時間365日の対応が必要か、そして運用保守に人を割くことが自社の本業にとって合理的か、という三点です。社内SEが一人しかおらず、その人が退職すればシステムがブラックボックス化してしまうような状況であれば、外注によって属人化リスクを下げる意義は大きいといえます。
外注のメリットは、専門人材の採用・育成コストを抑えながら、安定したサービス品質と障害対応体制を確保できる点にあります。一方で、システムの内部知識が社外に蓄積されるため、ベンダーへの依存度が高まりやすいという側面もあります。発注の段階から、定期報告やドキュメント納品を契約に盛り込み、自社側にも知見が残る仕組みを設計しておくことが、健全な委託関係を保つうえで欠かせません。
委託先の種類と選び方
運用保守の委託先は、大きく分けて「開発を担当したベンダーへの継続委託」「開発元とは別の保守専門会社への移管」「自社の情シスを補完するITアウトソーシング会社」の三類型があります。それぞれにメリットと注意点があり、どの委託先が適しているかはシステムの複雑性や社内体制によって変わります。発注先を選ぶ際は、価格だけでなく対応範囲・体制・引継ぎコストを総合的に評価することが重要です。
開発元への継続委託か、別会社への移管か
開発を担当したベンダーにそのまま保守を任せる場合、システムの内部仕様を熟知しているため引継ぎコストがかからず、障害対応も迅速になりやすいという利点があります。その反面、競争原理が働かないために保守費用が高止まりしやすく、「言い値」で契約を更新し続けてしまうリスクがあります。発注側としては、開発元の利便性を享受しつつも、定期的に費用の妥当性を検証する仕組みを持つことが大切です。
一方、開発元とは別の保守専門会社へ移管する場合は、相見積もりによってコストを最適化できる可能性があります。ただし、新しいベンダーがシステムを理解するための引継ぎが必要で、ここに想定外の時間と費用がかかる点に注意が必要です。仮に新ベンダーの月額が安くても、移行コストが300万〜500万円規模になると、5年間のトータルコスト（TCO）で見ると逆転してしまうこともあります。目先の月額だけでなく、移行費用まで含めた総額で比較する視点が欠かせません。
評価表の作り方と価格の配点
複数の委託先候補を客観的に比較するには、評価表を用いた採点が有効です。評価軸には、技術力、対応体制、SLAの保証水準、実績、そして価格を設定します。ここで意外と知られていないコツが、価格の配点を全体の20点以下に抑えるという点です。価格の比重を高くしすぎると、品質や体制が不十分でも安いベンダーが上位に来てしまい、結果として障害対応で苦労するケースが起こりがちだからです。
採点の際は、各項目を「○は5点、△は2点、×は0点」のように差が開く配点にすると、評価のブレを抑えながらベンダー間の優劣を明確にできます。中間点を細かく刻みすぎると、どの会社も似たような総合点になってしまい、決め手を欠くことになります。発注の意思決定を社内で説明する際にも、こうした明確な評価表があれば説得力が増し、稟議も通りやすくなります。
委託先の具体的な比較については、運用保守でおすすめの開発会社・ベンダー6選と選び方もあわせてご覧ください。発注の進め方全体を確認したい場合は、運用保守の進め方・流れ・手順が参考になります。
契約形態の選び方と発注の進め方
運用保守の発注では、契約形態の選択が費用と責任の所在を大きく左右します。主に用いられるのは準委任契約と請負契約の二つで、業務の性質に応じて使い分けるのが基本です。発注のプロセス全体としては、要件定義から始まり、RFI・RFPによる提案募集、評価・選定、そして契約締結と引継ぎへと進みます。この一連の流れは、契約満了の6ヶ月前には動き出しておくと余裕を持って進められます。
準委任契約と請負契約の使い分け
準委任契約とは、継続的にサービスを提供することを約束する契約で、完成責任を負わない点が特徴です。監視や問い合わせ対応といった、明確な成果物が定義しにくい定常業務に適しています。一方の請負契約は、明確な成果物の完成を約束する契約で、特定機能の改修やバージョンアップといった「やり切る」性質の作業に向いています。運用保守では、定常的な運用を準委任で、個別の改修を請負で発注するというハイブリッドな組み方が現実的です。
契約形態の選択には、税務上のメリットも関わってきます。保守契約を準委任契約として締結すると、印紙税法上の第7号文書として扱われ、収入印紙が不要になるケースが多いのです。請負契約の場合は契約金額に応じた収入印紙が必要になるため、年間契約や長期契約では無視できない差になることもあります。契約形態は責任の所在だけでなく、こうしたコスト面も踏まえて選ぶとよいでしょう。
RFP作成から選定までの手順
発注の中核となるのがRFP（提案依頼書）の作成です。RFPには、対象システムの概要、求める運用保守の範囲、希望するSLAの水準、対応時間帯、報告体制、そして提案してほしい体制と費用の内訳を明記します。ここを曖昧にすると、各社の提案がバラバラの前提で出てきてしまい、横並びの比較ができなくなります。ベンダー選定全体には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チャートです。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事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。