SE・SIerの運用保守は、費用の内訳、SLA、委託範囲を見ると、改善策を選ぶ手がかりが得られます。発注企業の立場から、5つの場面の事例をまとめました。最初はベンダー乗り換えで、障害の立て直し、委託、責任分界と続き、最後に予防保守を取り上げます。
▼全体ガイドの記事
・SE/SIerの運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ベンダー乗り換えで保守費TCOを圧縮した事例
保守費の高止まりを理由に、乗り換えてよいか迷う相談は少なくありません。年間保守費は一般に開発費の15〜20%が目安です（出典：ripla）。この水準と比べれば、今の保守費が重いかを判断する手がかりになります。
たとえば開発費5,000万円のシステムなら、年750万〜1,000万円が相場感です。ただし、多重下請けや待機要員のコストが上乗せされ、相場を大きく超えて請求されるケースもあります。乗り換えの検討は、払いすぎに気づく起点になります。
保守費の内訳を可視化して交渉余地を見つけた事例
中規模システムを抱える企業では、月額の保守費が一式で請求され、何にいくら払っているのか分からない状態でした。見直しの出発点は、この内訳を明細にすることでした。
- 見積もりの条件にする：相見積もりは費目別に依頼し、現行費の内訳も開示してもらう。
- 相場と照合する：内訳比率を物差しにして、膨らんでいる費目を洗い出す。
- 現行費を測り直す：移管そのものより、相場を使った現状把握を交渉の材料にする。
保守費の標準的な構成は、定期保守が20〜30%、監視が15〜25%、障害対応が25〜35%です（出典：ripla）。このほか、問い合わせ対応は10〜20%、軽微改修は10〜15%、管理報告は5〜10%です。
内訳比率と照合したところ、ほとんど発生していない障害対応に高い固定費が積まれていることが分かりました。現行ベンダーが費目を開示したことで、乗り換え前の交渉だけで月額を圧縮できました。
二重コストを織り込んで移管した乗り換え事例
ベンダー移管には通常2〜3か月かかり、その間は旧ベンダーの既存保守費と、新ベンダーの学習・調査費を並行して支払うことになります。
- 初年度の費用：移管中の二重コストで、TCOは一時的に上がる前提で考えます。
- 複数年で判断：単年の月額だけでなく、2年目以降の削減効果も合わせて比べる。
- 成果物を定める：手順書、障害対応履歴、ソースコードのコメント整備を契約に含める。
この企業は、初年度のTCO上昇を経営層に説明したうえで、複数年で判断しました。単年の月額だけを比べると、二重コストに驚いて移管が頓挫することがあります。
移管の2年目からは年間保守費を圧縮できました。加えて、ドキュメントを再整備する機会にしたことも、長期的なTCO圧縮につながりました。
乗り換えの評価は、目先の月額だけでなく、複数年のTCOとドキュメント資産を基準にします。
障害頻発を立て直した火消し・改善事例
障害が頻発する状態を立て直した火消し事例は、運用保守のなかでも学びの多い分野です。リリース直後の障害、夜間バッチの頻繁な停止、原因の分からない再発は、保守体制の設計不良が背景にある場合があります。
SE・SIerを入れた立て直しでは、応急処置に加えて、SLAと運用プロセスの再設計が改善につながります。
SLAを定量化して初報応答を改善した事例
障害対応が遅いという不満は、SLA（サービス品質保証）の基準が曖昧なことから生じていました。そこで立て直しでは、対応時間を数値で定義し直しました。
- 初報応答：重大障害は15分、通常障害は2時間を目安とする。
- 連絡と恒久対応：エスカレーションは30分、回答は24時間、恒久対応は5営業日が目安です。
- 復旧と稼働率：復旧目標は重大障害が4時間、通常障害が8時間です。99.9%の水準なら月の停止許容は約43分、99.5%ならより緩やかです。
これらの実務水準は、あくまで一つの目安です（出典：ripla）。「いつ連絡が来るか分からない」状態を数値基準に変えたことで、現場が感じる品質が改善しました。
復旧時間は結果を測る指標で、初報応答は途中経過を測る指標です。状況が分からない不安を減らすため、重大障害では15分以内に第一報を返すようにしました。
対応の良し悪しを判定するには、「迅速に対応します」より具体的な数字が要ります。数値のSLAに変えることが、火消しの第一歩です。
再発防止と恒久対応で障害件数を減らした事例
障害が頻発する現場では、再起動やパッチで急場をしのいだまま、根本原因が放置されることがあります。その結果、同じ障害が再発します。そこで立て直した企業は、障害ごとに原因分析（RCA）を義務づけました。
- 恒久対応の方針：保守契約に、障害発生から5営業日以内の提示期限を盛り込みます。
- 履歴と傾向の共有：障害の記録を蓄積し、月次報告で種類、件数、減少の理由を伝える。
- 効果の評価：件数と平均復旧時間から、対応工数がどう変わったかを確かめる。
このルールにより、月単位で障害件数は下降傾向になりました。なお、運用要員の人月単価は60万〜150万円が相場とされます（出典：ripla）。
火消しの効果は、単価の安さよりも、障害件数の減少による対応工数の圧縮に表れます。その分、同じ予算で軽微改修や予防保守に工数を回せました。
火消しでは、暫定対応で終わらせず、恒久対応まで完了させる仕組みを作ることが大切です。消火の速さよりも、火事を起こさない体制へ転換することが本質です。
ひとり情シスが委託で本来業務を取り戻した事例
中小・中堅企業には、情報システムの担当が実質1名の「ひとり情シス」体制が多くあります。そうした企業では、問い合わせや障害の一次受けに追われ、DX推進や業務改善に手が回らない事例も見られます。
SE・SIerへの運用保守の委託は、担当者への属人化と疲弊を解消する手段になります。委託で生まれた時間は、本来業務に振り向けられます。
一次受けを委託して属人化を解消した事例
ある中堅企業では、ひとり情シスの担当者が、「動かない」「使い方が分からない」といった問い合わせの一次受けに、1日の大半を費やしていました。
- 委託範囲：問い合わせの一次受けと障害の一次切り分け、定型対応を外部に任せる。
- 社内に残す業務：要件の判断や予算に関わる意思決定は、自社の担当者が行う。
- 範囲の決め方：定型・反復・属人化している業務に絞り、担当者の負荷を抑える。
サービス委託型の保守を月20万〜50万円で導入し、問い合わせ対応と障害の一次切り分けを外部に移しました（出典：ripla）。これにより、担当者が休暇を取ると業務が止まる属人化のリスクも解消されました。
委託費は一見すると人件費の追加に見えます。しかし、担当者の退職時に引き継げないリスクへの保険として価値があると判断されました。
この事例は、委託の成否が範囲の設計によって左右されることを示しています。委託範囲を決める際の好例といえます。
委託で生まれた時間をDX推進に充てた事例
委託で空いた時間を何に使うかで、委託の価値は変わります。この企業は、基幹システムの刷新計画づくりや、業務プロセスを見える形にする作業に時間を充てました。
- 生まれた時間を生かす：委託の価値は費用の削減だけでなく、空いた時間で上流業務を進められる点にもあります。
- 報告から課題を捉える：問い合わせ傾向や障害原因を、次の改善投資を決める根拠にする。
- 判断を社内に残す：委託先に丸投げせず、報告を読んで、システムへの理解と改善の主導権を保つ。
JUASの2025年調査では、IT予算を増額する企業が49.5%にのぼります（出典：JUAS）。
委託をしても、自社がシステムを理解しなくてよいわけではありません。時間を作り、理解を深める循環を回せたことが、この事例の成功要因でした。
クラウド・SaaS時代の責任分界でこじれた事例と立て直し
SaaS、クラウド、AI連携が関わると、ベンダーの管理が及ばない障害で責任の所在がこじれることがあります。たとえば、クラウド事業者のリージョン障害、連携先SaaSのAPI仕様変更、生成AIのハルシネーションがあります。
保守ベンダーが直接直せない事象で、責任外だとして沈黙してしまうと、ユーザー企業だけが取り残されます。そのため、役割と報告の責任を契約であらかじめ決めておくことが重要です。
連携SaaSのAPI仕様変更で押し付け合いになった事例
ある企業では、予告されていたAPI仕様変更のあと、基幹システムと外部決済SaaSのAPI連携が停止しました。保守ベンダーは自社コードの不具合ではないと主張し、ユーザー企業は復旧を求めました。
- 保守側の基本対応：原因の所在にかかわらず、一次切り分け、状況報告、復旧後の動作確認まで担う。
- 追従改修の費用：月額に一定の工数までを含め、超過分は都度見積もる。
- 費用枠の考え方：軽微改修の内訳比率を参考に、連携追従の予算を決める。
契約には、連携先APIの変更への追従改修を誰がどの費用区分で担うかが書かれていませんでした。技術的にできるかどうかより、役割の取り決めが抜けていたことが混乱を生みました。
立て直しでは、ベンダーの管理が及ばない事象であっても保守側が必ず行う対応を、契約に追記しました。そのうえで、軽微改修の枠を連携追従の予算とし、役割をはっきりさせました。
軽微改修は、費用相場の内訳で10〜15%を占めます（出典：ripla）。この枠を設けたことで、同種の障害が起きても、押し付け合いがなくなりました。
クラウド障害時の「報告だけは必ずする」を契約に入れた事例
別の企業では、クラウド基盤のリージョン障害で、システムが数時間停止しました。連絡がないまま何も分からない時間が続き、そのストレスがユーザー企業の不信を深めました。
- 初報：クラウド側の障害であっても、15分以内に状況を連絡する。
- 復旧見込み：現在の状況と先の見通しを、定期的に報告する。
- 復旧後：動作確認まで、保守側の対応に含める。
SLAで稼働率99.9%（月の停止許容は約43分）を合意していても、基盤障害が免責となり、状況報告もないままでは、保守費を払う意味が見えません（出典：ripla）。
直せない障害でも、状況と復旧の見込みを伝えることに保守の価値があります。その後に起きた障害では、ベンダーが速やかに報告し、復旧後の動作確認まで行いました。
この企業は、初報と復旧見込みの定期報告を、契約上の義務にしました（出典：ripla）。同じ障害でも、ユーザー企業の評価は変わりました。
責任分界の設計には、直す責任だけでなく、報告と確認の責任も含めます。
守りから攻めへ・予防保守で障害を未然に防いだ事例
予防保守の事例では、障害後に対応する守りの保守から、未然に防ぐ攻めの保守へ転換しました。費用内訳では、定期保守が20〜30%を占めます（出典：ripla）。
運用保守は障害対応の印象が強いものの、予防作業にも相応の比重がかかる領域です。
保守の重心を事後対応から事前の予防へ移し、障害件数とコストの両方を下げた事例です。
定期点検とパッチ適用で重大障害をゼロにした事例
ある企業は、故障してから直す保守に終始し、OSやライブラリのバージョンを放置していました。セキュリティパッチも、未適用のままでした。
- 定期点検と更新：月次の点検とパッチ適用を、標準作業として組み込む。
- 安全な適用準備：検証環境で事前に確かめ、ロールバック手順を整えておく。
- 効果を測る：重大障害の件数と緊急対応費の推移を追いかける。
脆弱性を突かれた障害や、サポート終了（EOL）による不具合が散発しました。そのたびに、緊急対応の追加費用が発生していました。
Before/Afterを数値で比べると、導入前は月あたり数件の重大障害があり、緊急対応の追加費用がかさんでいました。定期点検後は、重大障害がほぼゼロに近づき、緊急対応も減りました。
定期保守に予算を回した結果、総コストは下がりました。障害件数と緊急対応費を追えば、予防保守の費用対効果を説明できます。
月次報告を改善のPDCAに使った事例
予防保守を回す土台として、この事例では月次報告を、改善のPDCAを始める材料に使いました。費用内訳では、管理報告が5〜10%を占めています（出典：ripla）。
- 状況を数値で把握：障害件数と平均復旧時間、稼働率を記録し、問い合わせ傾向と軽微改修の状況も残す。
- 翌月の改善につなぐ：報告に次月の提案を含め、傾向に応じて対応を組み立てる。
- 社内で理解を保つ：委託先の報告を自ら読み込み、改善の判断を自社で続ける。
問い合わせの傾向から、同じ操作でつまずく人が多いと分かれば、画面の改善につなげました。特定機能のエラーが頻発した場合は、予防改修を計画しました。
予防保守と月次報告は、一体で考えるものです。運用を委託しても、システムへの理解と改善の主導権は社内に残し、報告データを次の対応に生かします。
まとめ
成功や立て直しの事例に共通するのは、相場で現状を測り、数値のSLAで品質を定め、委託範囲を設計するという原則です。
乗り換えでは、年間保守費が開発費の15〜20%という相場と、内訳比率を使って現行費を点検し、複数年のTCOで判断しました（出典：ripla）。
火消しでは、初報応答15分と重大障害の復旧目標4時間、そして恒久対応で障害を減らしました。ひとり情シスは、一次受けを委託して上流業務に時間を使いました。
まずは、自社の保守費を内訳比率に照らしてみることで、SLAや委託範囲のどこを見直すべきかが見えてきます。
改善の第一歩は、自社の保守費を内訳に分け、SLAを数値で定め、委託する定型業務を見極めることです。そのうえで、どの数字を基準にし、どこまでを委託するかを決めていきます。
riplaは、フルスクラッチ受託と国内運用保守の立場から、相場とSLAに基づく現状診断や、現場に定着する伴走型の保守体制づくりを支援します。全体像は完全ガイドをご覧ください。
▼全体ガイドの記事
・SE/SIerの運用保守の完全ガイド
▼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を創業。