ソフトウェア運用保守を外部に発注しようと考えたとき、多くの担当者がつまずくのは「どこに、どんな契約形態で、いくらで依頼すればよいのか」という最初の一歩です。開発と違って運用保守は終わりのない継続業務であり、いったん委託すると数年単位で付き合うことになります。だからこそ発注の段階でボタンを掛け違えると、毎月のコストが膨らみ続けたり、障害時に「それは契約対象外です」と突き放されたりと、後から取り返しのつかないトラブルにつながります。
本記事では、ソフトウェア運用保守の発注・外注・委託を成功させるための実務手順を、契約形態の選び方、ベンダー選定のプロセス、見積もりの妥当性を見抜く監査の視点、そしてSLA交渉や契約書の落とし穴まで踏み込んで解説します。単なる一般論ではなく、保守費用が適正かどうかを相見積もり以外で判断する方法や、ベンダーにペナルティ条項をのませる交渉術といった、現場で本当に役立つノウハウを中心にまとめました。これから委託先を探す方も、すでに委託していて契約を見直したい方も、判断材料として活用いただけます。
ソフトウェア運用保守を外注する前に押さえる全体像
発注先を比較する前に、まず「自社が何をどこまで委託したいのか」を言語化することが欠かせません。ここが曖昧なまま見積もりを取ると、各社の提案がバラバラになり、比較そのものが成立しなくなります。委託範囲の定義と内製・外注の判断という2つの土台を、最初に固めておきましょう。
委託範囲を「運用」と「保守」に分けて定義する
ソフトウェア運用保守の委託で最初にトラブルになりやすいのが、「運用」と「保守」の境界線です。運用とは、システムを正常に稼働させ続けるための定常業務を指し、稼働監視・データバックアップ・アクセス権限の管理・ユーザーからの問い合わせ対応などが含まれます。一方の保守は、障害が発生した際の原因究明と復旧、または仕様変更に伴うプログラムの改修やアップデートを指します。
この区別を曖昧にしたまま発注すると、「軽微なバグ修正は運用に含まれると思っていたのに、保守として別料金を請求された」といった食い違いが起きます。発注の段階で、監視やバックアップといった定常業務はどこまでか、障害対応は何分以内の初動を求めるのか、プログラム改修は月何件まで定額に含めるのか、を具体的に書き出してください。この範囲定義の精度が、そのまま見積もりの精度と契約後の安心感に直結します。
内製と外注の線引きをコスト構造から考える
外注を検討する背景には、社内に運用保守を担う人材や知見が足りない、特定の担当者に業務が集中して属人化している、といった課題があるはずです。ここで意識したいのは、ソフトウェアのライフサイクル全体にかかるコストのうち、運用保守が占める割合は40〜80%、平均でおよそ60%にのぼるという事実です。開発費だけを見て予算を組むと、その後に続く長い運用保守フェーズの費用を見誤ります。
すべてを丸ごと外注するか、監視のような定型業務だけを委託して改修は社内に残すか、判断は自社のリソースと機密性によって変わります。経済産業省の調査では、既存システムの運用に向けられる支出と新規構築への支出の割合は全産業平均でおよそ2対1とされ、いかに運用保守が経営の重荷になりやすいかが分かります。だからこそ、どの業務を外に出せば最も負荷とコストが下がるのかを冷静に見極めることが、発注設計の出発点になります。
発注時に選ぶべき契約形態と法務リスク
運用保守の委託では、どの契約形態を選ぶかが責任の所在とコスト、さらには税負担まで左右します。発注書や契約書に署名する前に、準委任と請負の違い、そして契約書に必ず盛り込むべき条項を理解しておくことが、後のトラブルを防ぐ最大の防御策になります。
準委任契約と請負契約の使い分け
準委任契約は、継続的にサービスを提供することを約束する契約で、完成責任は負いません。監視や問い合わせ対応、定常的な障害一次対応のように、明確な成果物が定義しづらい業務に適しています。一方の請負契約は、特定の機能改修や明確な成果物の完成を約束する契約で、納品物に対して責任が発生します。仕様が固まった改修案件を発注するなら請負が向いています。
多くの運用保守契約は準委任で結ばれますが、ここに見落とされがちな税務上のメリットがあります。保守契約を準委任契約として締結すると、印紙税法上の第7号文書に該当せず、収入印紙が不要になるケースが多いのです。請負契約として扱うと課税文書となり印紙が必要になる場合があるため、契約形態の選択は法務だけでなく経理の観点でも意味を持ちます。どちらの形態が自社の委託内容に合うのか、業務単位で切り分けて設計することをおすすめします。
契約書に必ず明記すべき条項と落とし穴
契約書には、保守対象範囲、費用と支払い方式、免責事項、契約解除条件を明確に記載する必要があります。とくに「対象外」と「追加費用」の線引きを曖昧にすると、契約後に「それは範囲外なので別途お見積もりです」というやり取りが頻発し、当初の予算が形骸化します。免責事項がベンダー有利に偏りすぎていないか、第三者の目でチェックすることも重要です。
見落とされがちな落とし穴として、ハードウェア保守を含む契約では故障部品の所有権の扱いがあります。HDD交換時など、故障した部品の所有権は保守会社に帰属するのが一般的で、機密データが残ったまま部品が持ち出される懸念があります。データの確実な破棄を求めるなら、別途その旨を定める契約が必要です。こうした細部こそ、発注前にベンダーへ確認すべきポイントだと言えます。
委託先を選定するプロセスと評価の進め方
委託先の選定は、思いつきで数社に声をかけて進めるものではありません。要件定義からRFP、評価表での比較まで、体系立てたプロセスを踏むことで、価格だけに引っ張られない適切な発注判断ができます。とくに既存ベンダーから乗り換える場合は、移行コストまで含めた総額で判断する視点が欠かせません。
RFPと評価表で価格偏重を避ける
選定は、自社の要件を整理したうえで、情報提供を求めるRFIを経て、提案を依頼するRFPを各社へ提示し、評価表で比較していく流れが基本です。この一連のプロセスには全体でおよそ4〜6ヶ月かかります。現行契約が満了する場合は、その6ヶ月前には動き出さないと、十分な比較検討の時間を確保できません。
評価表を作る際のコツは、価格の配点を全体の20点以下に抑えることです。価格の比重を高くしすぎると、品質や対応力に難があっても安いというだけで選ばれてしまい、結果的に障害対応の遅さや追加費用で割高になります。点数の付け方も「○は5点、△は2点、×は0点」と差が開くように設計すると、各社の優劣が明確になり、評価のブレを防げます。技術力、SLAの保証水準、サポート体制といった定性的な軸にこそ、しっかり配点しましょう。
既存ベンダーを競争に巻き込む乗り換え判断
すでに別のベンダーへ委託している場合、乗り換えの検討にはひとつ重要なテクニックがあります。あえて既存ベンダーもRFPに参加させるのです。競争原理が働くことで既存ベンダーが契約条件を大幅に見直し、結果として既存ベンダーの継続に落ち着くケースが30〜40%程度の確率で発生します。新規開拓の手間をかけずに、現行の条件を改善できる可能性があるわけです。
一方で、新ベンダーの月額が安く見えても、移行コストを無視すると判断を誤ります。たとえば新ベンダーの月額が魅力的でも、移行に300〜500万円かかるなら、5年間の総保有コスト（TCO）で計算すると逆転してしまうことも珍しくありません。発注の意思決定は、月額の安さではなく、移行費用と引き継ぎ負荷を含めた数年単位の総額で判断してください。
見積もりの妥当性を見抜く監査の視点
運用保守の発注で多くの担当者が抱える本音の悩みは、「今払っている保守費用が適正なのか、ぼったくられていないか」が分からないことです。相見積もりを取るのが定番の対策ですが、それだけでは見抜けない部分があります。ここでは、作業実態から適正価格を逆算する監査の視点を紹介します。
作業報告書とログから実稼働を割り出す
保守費用が適正かを判断する最も実効的な方法は、ベンダーから提出される月次の作業報告書と、サーバーやシステムに残るログを突き合わせ、実際にどれだけの作業時間が発生しているかを算出することです。月額固定で契約していても、実稼働がほとんどないのに高額な定額を払い続けているケースは少なくありません。報告書に書かれた作業内容が、ログ上の実際のアクセスや処理と整合しているかを確認するのが第一歩です。
運用保守作業の内訳を分解すると、最も時間を要するのは「調査・分析」で、全作業時間のおよそ30%を占めるとされています。逆に言えば、問い合わせもほぼなく障害も起きていない安定したシステムなら、保守工数は本来かなり小さくなるはずです。実稼働時間に対して人月単価を当てはめれば、適正な相場感が見えてきます。この監査の発想を持つだけで、ベンダーとの価格交渉のテーブルに、感覚論ではなく根拠を持って臨めるようになります。
改修見積もりの変動要因を理解する
機能改修を伴う保守の見積もりは、同じ規模でもベンダーや状況によって大きく変わります。その変動要因として、担当エンジニアの習熟度や、対象システムのドキュメント整備状況が挙げられます。ドキュメントが整っていない属人化したシステムほど、調査に時間がかかり見積もりは膨らみます。
改修開発の生産性を定量的に評価する手法として、改造する量を示す「改造密度」、改造箇所の数を示す「改造分散度」、担当者の経験を示す「改造母体錬度」という3つの軸でコストを算出するマトリクスもあります。発注側がこうした考え方を知っておくと、提示された改修見積もりが妥当な工数に基づいているのか、それとも余計なバッファが乗っているのかを見極めやすくなります。見積もりを鵜呑みにせず、根拠を問う姿勢が適正発注につながります。
SLA交渉と引き継ぎで委託を成功させる
発注先が決まっても、契約条件の詰めと引き継ぎを疎かにすると、委託のメリットを十分に引き出せません。サービス品質を担保するSLAをどう設定し、ベンダーにどう守らせるか、そして現行担当者からの引き継ぎをどう設計するかが、委託成功の最後の鍵を握ります。
ペナルティ条項をSLAに盛り込む交渉術
SLA（サービスレベル合意）は、サーバー稼働率や障害時の応答時間・復旧時間を定量的なKPIとして定める取り決めです。参考になるのが大阪市のガイドラインで、サーバやアプリの稼働率99.8%以上、基準応答時間の達成率93%（3秒以内）、重大障害は年2回まで、障害通知は発生後30分以内に100%遵守、ヘルプデスクの電話応答率97%以上（平均20秒以内）といった具体値が示されています。こうした数値を自社の要件に合わせて設定することで、抽象的な「がんばります」を、検証可能な約束に変えられます。
さらに踏み込むなら、目標未達時のペナルティ条項を盛り込みたいところです。ただしベンダーはペナルティを嫌うため、交渉には工夫が要ります。目標を上回った場合のインセンティブ報酬とペナルティをセットで提案すると、ベンダーも受け入れやすくなります。また、他社では同水準のペナルティ条項で契約しているという事例を交渉材料にするのも有効です。一方的に罰則を押し付けるのではなく、品質向上の動機づけとして設計することが、長期的に良好な関係を保つコツです。
属人化を防ぐ引き継ぎ体制の設計
委託の立ち上げで最もリスクが高いのが、現行担当者から新ベンダーへの引き継ぎ期間です。ここを軽視すると、システムの仕様がブラックボックスのまま委託先に渡り、障害時に誰も対応できないという最悪の事態を招きます。効果的なのは、新担当者を1.0人月で立ち上げつつ、現行担当者が週2日程度サポートに入る体制を、おおむね2ヶ月のOJTとして組むことです。
万が一、ドキュメントが整備されていない状態でキーマンが退職してしまった場合でも、打つ手はあります。近年は、開発当初の仕様を知るスタッフがいない古いシステムに対し、AIに既存コードを解析させてブラックボックス化を解消するリバースエンジニアリングの代行も現実的な選択肢になってきました。発注先を選ぶ際は、こうした属人化崩壊からの復旧力まで含めて、ベンダーの対応力を確認しておくと安心です。発注後の体制まで見据えた依頼が、結果的にトラブルの少ない委託を実現します。
ソフトウェア運用保守の関連記事
ソフトウェア運用保守の発注をより深く検討するために、関連するテーマの記事も用意しています。進め方の全体像や費用相場、委託先の選び方など、目的に合わせてあわせてご覧ください。
・ソフトウェア運用保守の進め方/やり方/流れや方法/手法/工程/手順
・ソフトウェア運用保守でおすすめの開発会社/ベンダー6選と選び方
・ソフトウェア運用保守の見積相場や費用/コスト/値段について
・ソフトウェア運用保守の完全ガイド
まとめ
ソフトウェア運用保守の発注・外注・委託を成功させる鍵は、依頼前の設計にあります。まず「運用」と「保守」の委託範囲を明確に定義し、準委任と請負を業務単位で使い分けたうえで、契約書には対象外の線引きや故障部品の所有権といった落とし穴まで盛り込むことが、後のトラブルを未然に防ぎます。
選定では、RFPと評価表で価格偏重を避け、移行コストを含めた数年単位の総額で判断することが重要です。さらに、作業報告書とログから実稼働を割り出す監査の視点を持てば、保守費用が適正かどうかを感覚ではなく根拠で見極められます。SLAにはペナルティ条項とインセンティブをセットで盛り込み、引き継ぎは2ヶ月のOJTで属人化を防ぐ。こうした実務の積み重ねが、長く安心して任せられる委託関係を築きます。本記事を、自社の発注設計を見直すきっかけとして役立てていただければ幸いです。
株式会社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を創業。