ソフトウェア運用保守の発注は、委託範囲と契約形態を決めたうえで、委託先の選定、見積もりの確認、SLAと引き継ぎの設計へと進みます。
運用保守は数年単位で続くため、発注時の掛け違いは後から響きます。段階ごとに何を決めるかを、先に押さえておくことが大切です。
委託範囲の「運用」と「保守」への分け方
運用保守の委託で最初にトラブルになりやすいのが、「運用」と「保守」の境界です。運用は、システムを正常に稼働させ続けるための定常業務です。稼働監視やデータバックアップ、アクセス権限の管理などが含まれ、ユーザーからの問い合わせにも対応します。
一方の保守は、障害が発生した際の原因究明と復旧、または仕様変更に伴うプログラムの改修やアップデートを指します。この区別を曖昧にしたまま発注すると、「軽微なバグ修正は運用に含まれると思っていたのに、保守として別料金を請求された」といった食い違いが起きます。
そのため、発注の段階で、定常業務はどこまでか、障害対応は何分以内の初動を求めるか、プログラム改修は月何件まで定額に含めるかを、具体的に書き出しておきます。この範囲定義の精度が、見積もりの精度と契約後の安心感に直結します。
コスト構造から見た内製と外注の線引き
外注を検討する背景には、社内に運用保守を担う人材や知見が足りない、特定の担当者に業務が集中して属人化している、といった課題があるはずです。運用保守は、ソフトウェアのライフサイクル全体にかかるコストのうち40〜80%を占め、平均でおよそ60%にのぼります。
開発費だけで予算を組むと、後に続く運用保守の費用を見誤ります。経済産業省の調査では、既存システムの運用に向けられる支出と新規構築への支出の割合は、全産業平均でおよそ2対1とされています。だからこそ、丸ごと外注するか、監視などの定型業務だけを委託して改修は社内に残すかを、自社のリソースと機密性を見ながら見極めることが発注設計の出発点になります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注時に選ぶべき契約形態と法務リスク
運用保守の委託では、どの契約形態を選ぶかが、責任の所在とコストに加えて税負担まで左右します。発注書や契約書に署名する前に、準委任と請負の違い、そして契約書に必ず盛り込むべき条項を理解しておくことが、後のトラブルを防ぐうえで最も効果の大きい備えです。
準委任契約と請負契約の使い分け
準委任契約は、継続的にサービスを提供することを約束する契約で、完成の責任は負いません。監視や問い合わせ対応、定常的な障害の一次対応のように、何を完成させるかを決めにくい業務に適しています。
一方の請負契約は、特定の機能改修や、決まった内容の完成を約束する契約で、納品物に対して責任が生じます。仕様が固まった改修案件を発注するなら請負が向いており、どちらが自社の委託内容に合うかは、業務単位で切り分けて設計することをおすすめします。
多くの運用保守契約は準委任で結ばれますが、見落とされがちな税務上のメリットもあります。保守契約を準委任契約として締結すると、印紙税法上の第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で属人化を防ぎます。こうした実務の積み重ねが、長く信頼して任せられる委託関係を築きます。
本記事が、自社の発注設計を見直すきっかけになれば幸いです。
▼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を創業。