システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説

システム保守とは、開発して稼働を始めたシステムを、障害の修正や環境変化への対応を通じて安定して使い続けられる状態に保つ仕事です。日々の稼働を見守るシステム運用と混同されがちですが、両者は担う役割が異なります。この記事では、システム保守と運用の違い、JIS X 0161が定める4つの保守タイプ、初期開発費に対する比率で見る費用相場と見積もりの根拠、準委任と請負の契約形態とSLAの決め方を、発注する側の視点で整理します。そのうえで、開発元・第三者保守・自社内製のどれに任せるかの判断軸と、外注で失敗しやすい典型パターン、引き継ぎで揃える資料までを具体的に示すのがこの記事のねらいです。規格や契約書のひな形、サポート期限のような判断の根拠になる資料は、公開元のページを本文中からたどれるようにしました。

まとめ：システム保守の全体像と、運用の違い・費用・委託先の判断軸

システム保守は、リリース後のシステムに手を入れて不具合を直し、法制度やOSの変化に追随させ、使い勝手を改善する作業の総称です。障害が起きていないかを監視し日々の稼働を維持するシステム運用とは役割が分かれ、運用が「動かし続ける」のに対し、保守は「直して変えて追随させる」ところを受け持ちます。ソフトウェアの保守はJIS X 0161で是正・予防・適応・完全化の4つに整理され、この分類で自社に必要な作業の範囲を切り分けられます。

費用は、初期開発費に対する年間の比率で見ると相場観をつかみやすくなります。一般には年5〜15%程度が目安とされ、24時間365日の対応やSLAで復旧時間を短く縛るほど上振れする傾向です。契約は準委任と請負のどちらを選ぶかで責任範囲が変わり、応答時間・復旧時間・保守範囲を契約前に取り決めておくと、リリース後の認識ずれを防げます。契約書の条項や保守要求の項目立てをゼロから起こす必要はなく、IPAが公開する情報システム・モデル取引・契約書（第二版）のように、受託開発と保守運用を対象にしたひな形が無償で公開されています。

委託先は、開発元・第三者保守サービス・自社内製の三択で考えると整理しやすくなるはずです。仕様に精通した開発元は初動が速い一方で費用は下げにくく、第三者保守は費用を抑えられても内部構造の把握に時間がかかります。自社の要件と体制を踏まえて保守まで含めた発注を検討したいときは、保守運用と内製化支援のサービスで、どこまでを委託しどこから社内で持つかを切り分けるところから相談できます。

システム保守とは｜システム運用との違いと保守が担う役割の全体像

システム保守は、開発工程の後に続く「作った後」のフェーズです。まず保守が何を指すのかと、隣り合うシステム運用との線引きを押さえておくと、見積書に並ぶ「運用保守」という一括りの費用を分解して読めるようになります。

システム保守の定義と、システムを安定稼働させ続ける目的と範囲

システム保守の目的は、稼働中のシステムを想定どおりに使い続けられる状態に維持することです。具体的には、発生した障害の修正、セキュリティパッチの適用、法改正やOSのバージョンアップへの追随、利用者からの改善要望への対応が含まれます。開発が「新しく作る」行為なら、保守は「作ったものを直し、変化に合わせて手を入れる」行為だと考えると分かりやすくなります。システム開発そのものの全体像はシステム開発とは何かを工程から整理した解説が参考資料です。保守は、その開発が終わった地点から始まります。

紛らわしいのが、設備や機械を対象にした「保守管理」との混同です。工場設備やビル設備を管理する業務では、点検・保全・修繕を計画的に回す業務を保守管理と呼び、対象が物理設備である点がソフトウェアの保守と異なります。両者は考え方が近く、予防的に手を入れる発想は共通するため、設備側の枠組みから整理したい場合は保守管理と保全・点検の違いを整理した記事を先に読むと、自社で使う言葉の指す範囲を揃えられます。

保守と運用の違い｜変更を伴う修正と、日々の稼働を保つ運用の分担

保守と運用は、現場では「運用保守」とまとめて呼ばれますが、担当する作業は分かれています。運用は、サーバーの死活監視、バックアップの取得、ジョブの実行監視など、システムを止めずに動かし続ける定常業務です。運用の具体的な業務範囲や、内製で回すか委託するかの判断軸はシステム運用とは何かで詳しく整理しました。保守は、その運用中に見つかった不具合の修正や、環境変化に合わせたプログラムの改修など、システムに手を加える変更を伴う業務を指します。

両者の境目は「システムに変更を加えるかどうか」に置くと切り分けられます。ログを見て異常がないか確認するのは運用、異常の原因となったバグを直すのは保守です。この線引きを見積もり段階で共有しておくと、どちらの作業がどの費用に含まれるのかが明確になります。

境目をまたぐ作業として扱いに迷いやすいのが、障害が起きた後の一連の流れです。検知して一次対応し、暫定復旧させるところまでは運用側の手順に載りますが、原因となったコードや設定を直すところからは保守の領域に入ります。この受け渡しをどう設計するかは、インシデント管理のプロセスを整理した記事で扱う考え方が土台になり、窓口・記録・エスカレーションを一本の線としてつないでおくと、責任の空白が生まれません。

システム保守の業務内容と、JIS規格に基づく4つの保守タイプ

保守と一言でいっても、その中身は性質の違う作業に分かれます。ソフトウェアの保守はJIS X 0161（国際規格ISO/IEC 14764に対応）で4つに分類されており、この枠組みで自社が必要とする保守の範囲を言語化できます。

是正・予防・適応・完全化｜JIS X 0161が定める保守の4分類

JIS X 0161は、ソフトウェア保守を目的別に4種類へ整理しています。是正保守は、顕在化した障害を取り除く修正です。予防保守は、まだ表面化していない潜在的な欠陥を、障害になる前に手当てします。適応保守は、OSの更新や法改正、業務環境の変化にシステムを合わせるための改修です。OSやハードのサポート終了に伴ってシステムを別環境へ移す場合は、マイグレーションの種類・手法・費用を発注者視点で整理した解説もあわせて確認できます。完全化保守は、性能や保守のしやすさを高めるための改善です。

この4分類のうち、契約でまず対象になりやすいのは是正保守と適応保守です。予防保守と完全化保守はどこまで含めるかで費用が動くため、範囲を明示しておくと後の見積もり交渉がぶれません。

規格の版にも触れておきます。JIS X 0161:2008の対応国際規格であるISO/IEC 14764:2006は、ISOの規格ページ上でWithdrawn（廃止）と表示され、ISO/IEC/IEEE 14764:2022によって改訂された旨が示されています（2026年9月時点の表示）。4分類の考え方そのものは引き継がれているため実務の整理には引き続き使えますが、契約書や社内規程で規格番号を引用するなら、国際規格側は2022年版が現行である前提で版を書き分けておくと、後からの指摘を避けられます。

障害対応・パッチ適用・法改正対応まで含む具体的な作業項目の範囲

4分類を日々の作業に落とすと、保守の作業項目は次のように並びます。稼働中に発生した障害の切り分けと復旧、セキュリティパッチやミドルウェアの更新適用、インボイス制度や電子帳簿保存法のような法改正への対応、利用者からの改善要望を受けた小規模な機能改修です。

• 障害の一次切り分けと復旧、原因調査と再発防止
• OS・ミドルウェア・ライブラリのパッチ適用と検証
• 法改正・制度変更に合わせたプログラムの改修
• 利用者要望に基づく画面や帳票の小規模改修

これらの作業をどこまで一契約に含めるかは会社ごとに幅があります。「システム保守 作業項目」で具体を探す発注担当者が多いのは、契約書の「保守」という言葉だけでは何をしてもらえるのかが読み取れないからです。作業項目を一覧で突き合わせておくと、必要な範囲と不要な範囲を仕分けられます。

適応保守の分量を読むときは、制度側の情報源を自分で押さえておくと見積もりの妥当性を判断しやすくなります。たとえば帳票や証憑を扱うシステムなら、国税庁の電子帳簿保存法関係のページは、概要・法令通達・一問一答・JIIMA認証済みシステムの一覧をまとめた情報源です。ベンダーから「法改正対応で追加費用が必要」と言われたときに、対象の要件が原文のどこに書かれているかをたどれる状態にしておくと、追加費用の議論が根拠のあるものに変わります。

OS・ミドルウェアのサポート期限を棚卸しして改修時期を逆算する

適応保守の中でも時期が読めるのが、OSやミドルウェアのサポート終了に伴う改修です。提供元が公開するライフサイクル情報には終了日が明示されており、たとえばMicrosoftのWindows Server 2016のライフサイクルページでは、メインストリームサポートが2022年1月、延長サポートが2027年1月（太平洋時間表記で2027年1月13日）に終了すると表示されています（2026年9月時点）。CentOSのようにディストリビューション自体の方針が変わった例もあり、その経緯と移行先の考え方はCentOSの終了と後継OSへの移行判断で整理しています。

保守対象の一覧と終了日を1枚の表にしておくと、どの年度にどれだけ改修予算が要るかを先に置けます。手元で回すなら、資産名と終了日を並べたCSVから残り日数を出すだけで十分です。次のコードは、保守対象の棚卸し表を読んで期限までの日数を表示します。

import csv, datetime, io

src = """asset,eol
Windows Server 2016,2027-01-13
CentOS 7,2024-06-30
"""

today = datetime.date.today()
for row in csv.DictReader(io.StringIO(src)):
    eol = datetime.date.fromisoformat(row["eol"])
    print(row["asset"], (eol - today).days, "日")

2026年9月15日に実行すると、Windows Server 2016は残り120日、CentOS 7は807日超過という結果になります。マイナスの値が出た資産は、すでにセキュリティ更新が届かない状態で動いていることを意味し、予防保守ではなく緊急の移行案件として扱う対象です。棚卸しを年1回の定例にしておくと、突然の「サポートが切れるので今期中に移行してください」という相談が減ります。

システム保守費用の相場と、開発費に対する比率で見る見積もりの根拠

保守費用は、金額の絶対値だけを見ても高いか安いか判断できません。初期の開発費に対する比率と、対応レベルという二つの軸で捉えると、提示された見積もりの妥当性を検討しやすくなります。保守を続ける場合と刷新する場合を同じ費目で並べる比べ方は、レガシーシステム脱却の判断基準と進め方で示しています。

保守費用は初期開発費の年5〜15%が一般的とされる相場の目安

システム保守の費用は、初期開発費を基準にした年間比率で語られることが多く、一般には年5〜15%程度が目安とされます。1,000万円で開発したシステムなら、年50万〜150万円、月額にして数万〜十数万円が一つの目安です。この比率は要件によって上下する概算であり、断定できる固定値ではありません。対応の手厚さと、保守に含める作業範囲で変わります。

開発費と保守費は本来ひと続きのコストです。開発時に費用を切り詰めてテストや設計を省くと、リリース後の是正保守が増え、保守費が膨らむ逆転が起こります。開発と保守を通した総額で見る観点は、システム開発費用の相場と内訳を発注者視点でまとめた解説と合わせて押さえておくと、初期費用だけに引きずられずに判断できます。

対応時間帯・SLA水準・システム規模で保守費用が上下する要因

同じシステムでも、保守費用は三つの要因で大きく動きます。第一に対応時間帯で、平日日中のみと24時間365日では、待機する体制の人件費が変わるため費用が数倍になることもあります。第二にSLAの水準で、障害発生から復旧までの時間を短く縛るほど、常時待機の要員が必要になり、費用も上がる仕組みです。第三にシステムの規模と複雑さで、連携する外部システムやデータ量が多いほど保守の手間が増えます。

費用を抑えたいなら、まず対応時間帯を業務の実態に合わせて絞るのが現実的です。夜間に誰も使わない社内システムに24時間対応をつける必要はありません。守るべき稼働時間を業務から逆算し、それに見合うレベルを選ぶと、過剰な保守費を避けられます。

SLAの稼働率を年間の停止許容時間に換算して費用と釣り合わせる

見積書に「稼働率99.9%」と書かれていても、その数字が業務にとってどれだけの余裕なのかは、百分率のままでは伝わりません。年間の許容停止時間に直すと、支払う金額と守られる水準を同じ物差しで比べられます。次のコードは、稼働率から1年あたりの停止許容時間を計算します。

for sla in (99.0, 99.5, 99.9, 99.95, 99.99):
    down_min = 365 * 24 * 60 * (100 - sla) / 100
    print(sla, "%:", round(down_min, 1), "分",
          round(down_min / 60, 1), "時間")

実行すると、99.0%で年87.6時間、99.5%で年43.8時間、99.9%で年8.8時間、99.95%で年4.4時間、99.99%で年0.9時間という値が並びます。99.9%と99.99%の差は年8時間ほどですが、この8時間を縮めるために必要なのは冗長化した基盤と24時間の待機要員で、費用は段違いに跳ね上がるという関係です。基幹業務が止まって1日で失う金額と、上位のSLAに毎年払う差額を並べると、どこで線を引くべきかが見えてきます。

稼働率をどの単位で測るか、計画停止を分母から除くかどうかでも数字の意味は変わります。SLAとSLO・SLIの関係や、指標の決め方そのものはSLAとSLO・SLIの違いと稼働率の決め方で扱っており、契約前にここを合わせておくと、後から「その停止は稼働率に数えない」という食い違いが起きにくくなります。

システム保守契約の主な形態と、契約前に取り決める範囲の確認点

保守の費用と品質は、契約の形態と、そこで何を約束するかで決まります。契約書に「保守」とだけ書かれていると、いざ障害が起きたときに対応の可否をめぐって認識がぶつかりがちです。形態の違いと、事前に文書化しておくべき項目を押さえておきます。

準委任と請負の契約形態の違いと、SLAで定める応答・復旧時間の水準

保守契約は、準委任契約と請負契約のどちらかを土台にすることが多く、責任の重さが異なります。準委任は、決められた工数や体制で保守作業を提供する契約で、受託側は善良な管理者としての注意義務を負いますが、特定の成果の完成までは保証しません。請負は、修正の完成という結果に責任を持ち、納品物に不具合があれば契約不適合責任を問えます。月々の保守は準委任、個別の大きな改修は請負と、作業の性質で使い分けるのが一般的です。

この違いは条文に書かれています。民法では、請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約とし（第632条）、準委任は法律行為でない事務の委託に委任の規定を準用すると定めます（第656条）。受任者が負う義務は「委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する」ことです（第644条）。さらに請負では、注文者が不適合を知った時から1年以内に通知しないと、追完・報酬減額・損害賠償・解除を請求できなくなる期間制限が置かれています（第637条）。改修を請負で発注したなら、受け入れ後に不具合を見つけた時点から1年という時計が動く前提で、検収のやり方を決めておくのが実務的です。

契約形態と合わせて、SLA（サービス品質保証）で応答時間と復旧時間の水準を数値化しておきます。「障害連絡から30分以内に一次応答、4時間以内に復旧着手」のように具体的な時間を約束事にすると、対応の速さを費用と釣り合った形で管理する仕組みです。請負と準委任の使い分けは、契約形態による費用の違いを整理した費用相場の解説でも触れています。

保守範囲・対応窓口・エスカレーション体制を契約前に確定する項目

契約前に文書で確定させておきたいのは、保守の対象範囲、連絡窓口、そして緊急時のエスカレーション経路です。保守範囲では、どのサーバー・どのアプリケーションまでを面倒見るのか、OSやミドルウェアの更新は含むのかを線引きします。対応窓口は、誰がいつ連絡を受け、どのくらいで折り返すのかを決めます。

1. 保守対象の範囲（サーバー・アプリ・連携先の線引き）
2. 連絡窓口と受付時間、一次応答までの時間
3. 重大障害時のエスカレーション経路と責任者

この三点があいまいなまま契約すると、深夜の障害時に「その対応は契約外」と押し問答になります。特にエスカレーション経路は、担当者が不在でも判断できる代替の連絡先まで決めておくと、初動が止まりません。

IPAのモデル契約書と非機能要求グレードで保守要求を文書化する

契約条項も要求項目も、白紙から書き起こす必要はありません。IPAは情報システム・モデル取引・契約書（第二版）を公開しており、受託開発と保守運用を対象にしたひな形と解説が無償で手に入ります。第二版は2020年12月22日に公表され、ページ上では2025年4月8日の更新が示されています（2026年9月時点）。パッケージやSaaS／ASPの利用を前提にした第二版追補版、アジャイル開発版も同じ場所からたどれるため、自社の調達方式に近いものを土台にすると、条項の抜けを減らせます。

要求の側で使えるのが、IPAの非機能要求グレードです。可用性や運用・保守性といった非機能の要求を、項目とグレードの形で並べた資料一式が公開されており、稼働率・復旧時間・保守の作業時間帯といった数字を、発注側と受注側が同じ用語で埋められます。項目の構成や使いどころは非機能要求グレードの概要を解説した記事で整理しました。見積もりを依頼する段階でこのシートを埋めて渡すと、各社の提案が同じ土俵に乗り、価格差の理由を比べられるようになります。

開発元・第三者保守・内製のどれを選ぶか｜保守委託先を決める判断軸

ここからは、保守を誰に任せるかの判断です。競合記事の多くは「外注のメリット」を並べて終わりますが、実務では開発元・第三者保守・自社内製の三択を、費用と初動の速さ、内部構造の把握しやすさで天秤にかける場面がほとんどです。条件を示して、どの場合にどれを選ぶかを言い切ります。タイプを絞った後に候補会社を並べて1社へ決めるまでの手順は、システム運用保守の会社の選び方と相見積りの揃え方で整理しました。

開発元・第三者保守・内製をそれぞれ選ぶ条件と切り替えの損益分岐

開発元への委託は、システムの内部仕様を最も理解している相手に任せられるため、障害時の原因特定が速く、改修の手戻りも少なくなります。稼働から間もない時期や、頻繁に機能追加が続くシステムでは、開発元の継続保守が総合的に有利です。一方で費用は下げにくく、乗り換え先がない状態が続くと価格交渉力を失います。

第三者保守サービスは、開発元より保守費を抑えられる場合が多く、複数システムをまとめて任せて窓口を一本化できます。仕様が安定して大きな改修が少なくなったシステムでは、第三者保守への切り替えが費用面で効いてくる場面です。ただし内部構造の把握に時間がかかるため、切り替え直後は障害対応が遅くなる期間を見込む必要があります。内製は、社内にエンジニアがいて、システムがビジネスの中核で改修判断を素早く回したい場合に向く選択肢です。人件費を固定で抱える点が損益分岐で、月々の外注費が常勤エンジニアの人件費を上回るなら内製化を検討する目安になります。

保守を安易に外注すべきでない場面と、委託で失敗する典型パターン

すべてを外注すればよいわけではありません。外注を避けるべきなのは、システムが競争優位の源泉で、改修のたびに外部と仕様調整をしていては事業のスピードが落ちる場合です。ECの独自ロジックや、自社サービスの根幹を担うシステムは、保守の一部でも社内に残したほうが機動力を保てます。そもそもどのシステムを維持し、どこへ投資するかという上流の判断は、ITコンサルティングの考え方で切り分けられます。

委託で失敗する典型は、保守範囲をあいまいにしたまま安さだけで発注先を決めるパターンです。範囲が不明確だと、障害のたびに「これは契約外」と追加費用を請求され、結果的に高くつきます。もう一つは、開発を任せた会社にドキュメントを残させず、担当者の頭の中だけに仕様がある状態で保守契約を切ってしまうパターンで、引き継ぎ先が構造を読めず保守が事実上止まります。発注の段階から保守を見据えて設計と文書化を求めておくのが、こうした行き詰まりを避ける近道です。

保守を引き継ぐ準備と、社内側で保守作業を年間計画に落とすときの進め方

委託先を決めた後、実際に保守が回り始めるかどうかは引き継ぎの質で決まります。開発元から第三者保守へ乗り換えるときも、内製へ引き上げるときも、渡す資料と並走期間の設計が甘いと、契約は結べたのに障害時に誰も動けない状態が生まれます。

引き継ぎで渡す資料一覧と、切り替え期間を並走させる日程の組み方

引き継ぎで最低限そろえたいのは、システム構成図、環境ごとの接続情報とアカウントの棚卸し、過去の障害履歴と対処記録、デプロイ手順、そして未解消の不具合や技術的負債の一覧です。特に過去の障害履歴は、次の担当者が「このシステムはどこで壊れやすいか」を短時間で把握する材料になり、机上のドキュメントより実務で効きます。

• システム構成図と外部連携先の一覧
• 環境別の接続情報・権限・アカウントの棚卸し表
• 障害履歴と対処記録、恒久対策の未実施分
• デプロイとロールバックの手順、定例作業の年間カレンダー
• 未解消の不具合、既知の制約、技術的負債の一覧

日程は、旧ベンダーと新ベンダーが並走する期間を1〜3か月ほど確保すると、実際の障害やリリースを一度は一緒に経験させられます。並走なしで切り替えた場合、最初の重大障害で原因調査に数日かかり、その遅れが業務損失として跳ね返る例は珍しくありません。並走の費用は二重に見えても、切り替えリスクへの保険として見積もりに載せておく価値があります。

社内の情報システム担当と保守ベンダーで分担する作業の線引き方

外部に任せても、社内に残る仕事はあります。障害の業務影響を判断して優先順位を決めること、改修要望を集約して取捨選択すること、予算を確保して年度計画に載せることは、委託先には代われません。ここを空席にしたまま保守契約だけ結ぶと、ベンダーからの提案が宙に浮き、対応の遅れが社内不満に変わります。

分担を決めるときは、開発と運用の役割をどうつなぐかという視点も持っておくと整理しやすくなります。両者を分断せず一本の流れとして設計する考え方はDevOpsの実践と導入判断にまとまっており、保守の依頼が滞留する原因が体制側にあるのか手順側にあるのかを切り分けるための手がかりです。社内担当が窓口として機能し始めると、同じ保守費でも処理できる件数が増えていきます。

よくある質問

システム保守の検討でよく挙がる疑問を、発注する側の視点でまとめます。

システム保守と運用の違いは何ですか？

運用はシステムを止めずに動かし続ける定常業務で、監視・バックアップ・ジョブ実行などが含まれます。保守は運用中に見つかった不具合の修正や、環境変化に合わせた改修など、システムに変更を加える業務です。「動かし続ける」のが運用、「直して変える」のが保守と切り分けると分かりやすくなります。現場で両方をまとめて呼ぶときの名称が運用保守です。運用が担う監視について、主要な監視項目の種類や死活監視・性能監視の違いは、システム監視とは何かを発注者視点で解説した記事で詳しく扱っています。

システム保守費用の相場はどのくらいですか？

初期開発費に対して年5〜15%程度が一般的な目安とされます。1,000万円で開発したシステムなら年50万〜150万円が概算です。ただし対応時間帯が24時間365日か平日日中のみか、SLAで復旧時間をどこまで縛るかで数倍動くため、固定の相場としてではなく要件次第で上下する幅として捉えてください。

システム保守契約にはどんな形態がありますか？

月々の保守作業は準委任契約、個別の大きな改修は請負契約を土台にすることが多いです。準委任が責任を持つ対象は作業の遂行であり、請負が責任を持つ対象は成果の完成です。あわせてSLAで応答時間・復旧時間・保守範囲を数値化しておくと、費用と対応品質の釣り合いを管理できます。条項の書き方に迷う場合は、IPAのモデル取引・契約書のひな形を土台にすると抜けを減らせます。

開発した会社以外にシステム保守を頼めますか？

第三者保守サービスに切り替えれば、開発元以外にも委託できます。保守費を抑えやすく、複数システムの窓口を一本化できる利点があります。一方で内部構造の把握に時間がかかるため、切り替え直後は障害対応が遅くなる期間を見込んでください。ドキュメントが整っているほど、乗り換えはスムーズになります。

システム運用保守が「きつい」と言われるのはなぜですか？

夜間や休日の障害呼び出し、原因が特定しづらいトラブルの切り分け、属人化した古いシステムの引き継ぎなどが負担として挙げられます。裏を返せば、これらは社内の少人数で抱えると疲弊しやすい領域です。対応時間帯を業務に合わせて絞り、負荷の高い部分を外部の保守体制に委ねる判断が、内製と外注を分ける現実的な基準になります。監視や夜間対応を専業のMSPへ切り出す選択肢は、MSP（マネージドサービスプロバイダー）の役割と委託判断を整理した記事で詳しく解説しています。

保守契約を結ばず、障害が起きたときだけ都度依頼できますか？

スポット対応を受ける会社はありますが、着手までの待ち時間と単価は上がります。月額の保守契約は、要員を確保しておく対価という側面を持つためです。停止しても数日は業務が回るシステムなら都度依頼でも成り立ちますが、止まると受注や請求が滞る業務系なら、待たされる時間そのものが損失になります。停止1日あたりの業務影響を金額で見積もり、年間の保守費と比べて決めてください。

保守費用を下げたいとき、どこから見直せばよいですか？

最初に見るのは対応時間帯です。24時間365日を平日日中＋緊急時オンコールに変えるだけで、待機要員の費用が外れます。次に保守範囲で、完全化保守にあたる改善要望を年次のまとまった改修として別枠にすると、月額を薄くできます。監視や定型作業を社内へ戻す方法もあり、どこまで自社で持てるかは体制次第です。範囲を削るときは、削った部分が誰の担当になるのかを同時に決めておかないと、対応の空白が生まれます。

関連記事

• システム開発とは？種類・工程・依頼方法までの全体像をわかりやすく解説：保守の前段にあたる開発工程の全体像を確認できます。
• システム開発の費用相場は？内訳・人月単価と見積もりの妥当性を発注者視点で解説：初期開発費と保守費を通した総額で費用を捉えるための解説です。
• 保守管理とは？保全・点検との違いと業務範囲・システム化の判断基準：設備側の保守管理と用語の指す範囲を突き合わせられます。