ソフトウェア運用保守の見積相場や費用/コスト/値段について

ソフトウェア運用保守の費用は、月額で5万円から50万円以上まで幅があります。その差を生むのは、保守範囲、ソフトウェア規模、SLA水準です。

また、月額の目安は規模と連携範囲で大きく変わり、改修費用は既存ソフトウェアの状態で左右されます。

ソフトウェア運用保守費用の全体像

ソフトウェア運用保守費用は、初期費用と並ぶ大きなコストです。そのため、開発後の運用まで見据えて費用を計画しておく必要があります。

ソフトウェアの総コスト(TCO)のうち、保守フェーズが占める平均はおよそ60%に達します。さらに、保守費用は内訳が見えにくく、提示された額が適正かを判断しづらい点が課題です。

ソフトウェア保守には、ハードウェアやインフラとは異なる特有の費用の決まり方があります。固定費と変動費が混在するため、種類ごとの性質を切り分けて理解することが欠かせません。

TCOの約60%を占める保守費用

開発費だけでなく、運用後の支出まで含めて投資を考える必要があります。

  • 保守割合:TCOのうち40〜80%を保守フェーズが占めます。
  • 支出比率:IT予算では、従来システムの運用と新規構築がおよそ2対1です。

この比率は、経済産業省の調査でも全産業平均として示されています。一例として、開発費1,000万円のソフトウェアでは、5年間の保守が開発費を上回る場合もあります。

保守費用は、独立した投資として年単位で計画するものです。その理解があるかどうかが、システム投資の成否を分けます。

保守の4分類とコストの性質

ソフトウェア保守は、国際規格ISO/IEC 14764で4つに分類されます。

  • 是正保守:バグや障害の修正です。
  • 適応保守:OS・ブラウザの更新や法改正への追従です。
  • 完全化保守:機能の改善と性能の向上です。
  • 予防保守:将来の障害を防ぐための、先回りの改修です。

是正保守と軽微な適応保守は、月額契約の固定費に含まれることが多くあります。一方で、機能追加や大きな仕様変更は完全化保守にあたり、スポット対応の変動費になるのが一般的です。

見積りが高いと感じたときは、固定の月額と改修のスポット費用を分けて、原因を確かめます。

ポイント

保守費用は、開発費とは別に年単位で計画する投資です。固定費と変動費を分けて捉えると、提示された額が妥当かどうかを判断できます。

月額保守費用の相場と内訳

小規模・中規模・大規模のソフトウェアについて、月額保守費用の目安を3枚のパネルで示した図解。
規模が大きくなるにつれて、目安となる月額の水準も上がります。

月額保守費用は、初期開発費の一定割合を目安に設定されることが多くあります。目安は、年間で開発費の5%前後、月額で0.5%前後です。ただし、保守の対応範囲によって金額は大きく変わります。

規模別の月額費用の目安

月額相場は、ソフトウェアの規模と連携範囲で次のように分かれます。

  • 小規模:Webアプリケーションや業務ツールは月額5万円〜15万円程度です。
  • 中規模:業務システムは月額20万円〜50万円程度です。
  • 大規模:複数システム連携を含む場合は月額50万円以上です。

これらは、バグ修正、軽微な問い合わせ対応、稼働監視を含む水準です。なお、同じ月額20万円でも、障害対応だけを含むか、月数時間の改修まで含むかで差が出ます。

金額だけでなく、含まれる作業範囲と対応時間(SLA)も見ておきます。

月額費用に含まれる作業の内訳

月額費用は、日常の稼働確認から修正記録まで、複数の作業で構成されます。

  • 稼働管理:稼働監視と定期バックアップの確認です。
  • 問い合わせ:利用者からの問い合わせへの対応です。
  • 不具合対応:軽微なバグの修正です。
  • 安全対策:セキュリティパッチの適用です。
  • 記録更新:対応に伴うドキュメントの更新です。

保守作業では、目に見える修正より調査・分析に時間がかかることもあります。その割合は、全作業時間のおよそ30%とされています。

不具合を1行直すだけでも、原因を既存コードから追う作業が必要です。

ソースコードやドキュメントが整理されているほど、調査時間は短くなります。反対に、ブラックボックス化したソフトウェアでは、同じ作業でも費用が膨らみます。自社ソフトウェアの読みやすさは月額費用に直結するため、あわせて確認しておきます。

ポイント

月額は規模と連携範囲で変わるため、同じ金額でも含まれる作業範囲が違えば比べられません。作業内容と対応時間を揃えてから、金額を見比べます。

改修・機能追加の見積りロジック

改修の難易度を、改造密度・改造分散度・改造母体錬度の3要素から説明する注釈図。
同じ機能追加でも、改修箇所の広がりや担当者の習熟度で工数が変わります。

改修や機能追加のスポット対応は、運用保守費用の中でも見積りが難しい部分です。

新規開発は機能規模から工数を見積もりやすいのに対し、既存ソフトウェアの改修は、状態によって工数が数倍変わります。

改造密度・分散度・母体錬度の3次元評価

改修の難易度は、3つの軸で評価するマトリクスを使うと、数値で捉えられます。

  • 改造密度:10Kステップ(1万行)あたりの改造量です。
  • 改造分散度:改修が1か所にとどまるか、全体に散らばるかの度合いです。
  • 改造母体錬度:担当技術者の既存ソフトウェアへの習熟度です。

3軸を掛け合わせると、ボタンを1つ追加するだけの改修でも工数が変わります。たとえば、改修箇所が分散していて担当者が不慣れなら、影響範囲の確認とテストに工数がかかります。

反対に、改修が局所的で担当者が詳しければ、同じ要件でも工数を圧縮できます。

見積書に「機能追加一式」としか書かれていない場合は、3軸を内訳確認の材料として使えます。

人月単価とエンジニア区分の関係

改修費用は、工数(人月)と人月単価を掛けて算出されます。

  • 初級エンジニア:月50万〜70万円程度が目安です。
  • 中級エンジニア:月70万〜100万円程度が目安です。
  • 上級・スペシャリスト:月100万〜160万円程度が目安です。

高度な設計判断は上級者、定型的な修正は初級者が担当するため、単価も変わります。見積りでは、合計金額だけでなく、想定工数と単価を分けて提示してもらうことが大切です。

たとえば30万円の改修でも、上級者0.2人月(約32万円)か、初級者0.5人月(約30万円)かで、妥当性の見方が変わります。

工数と単価をまとめて示すベンダーには、内訳を求めることが過剰請求を防ぐ第一歩です。

工程ごとの工数を確かめたいときは、ソフトウェア運用保守の進め方が役立ちます。

ポイント

改修費用は、工数と人月単価に分けて提示してもらうと内訳が追えます。工数の根拠は3軸で確かめられ、「機能追加一式」の金額にも説明を求められます。

保守費用を左右する変動要因

同じ規模のソフトウェアでも、保守費用は会社や状況によって大きく異なります。要因を知っておくと、見積りが高い理由と、自社で抑えられる範囲を切り分けて考えられます。

ドキュメント整備状況と習熟度

ドキュメントの整備と担当者の習熟度が、調査工数と保守費用を左右します。

  • 文書の有無:設計書・仕様書・運用手順書があれば、調査を短縮できます。
  • 担当者の習熟度:既存ソフトウェアに詳しい担当者ほど、工数を抑えられます。

文書がない場合は、ソースコードを読み解くところから始まり、調査だけで工数の大半を使ってしまいます。

別の会社へ切り替える場合は、内部構造を理解するための立ち上がり期間が必要です。

新しい担当には1人月程度の習熟期間を確保し、現行の担当者が週2日程度支援する体制が効果的とされています。なお、安さだけで切り替えると、引き継ぎコストが想定以上に膨らむこともあります。

SLA水準と対応時間帯

SLA(サービスレベル合意)は、求める品質水準と対応時間を定める基準です。

  • 対応時間帯:平日日中か、24時間365日かの違いです。
  • 復旧目標:障害発生から何時間で復旧するかの目標です。
  • 厳格な水準:稼働率99.8%以上、重大障害は年2回まで、30分以内通知などです。

SLAの設定は必要な人員体制を左右するため、月額費用に直結します。たとえば、深夜帯に使わない社内向けソフトウェアに24時間対応を付けると、待機コストが増えます。

利用の実態に合わせて対応時間帯と復旧目標を絞れば、過剰なコスト増を防げます。

契約方法との関係を整理したいときは、ソフトウェア運用保守の発注・外注方法が役立ちます。

ポイント

会社を切り替えるなら、文書の有無と立ち上がりに必要な期間を先に見積もるのが目安です。安さだけで決めると、引き継ぎの負担が想定以上に膨らみかねません。

提示された保守費用の妥当性の見抜き方

作業報告書、サーバーログ、問い合わせ履歴の3種類を、実稼働を確かめる記録として整理した図解。
異なる記録を照らし合わせることで、契約工数と実作業の差を追えます。

多くの企業が気にするのは、保守費用が適正か、それとも払いすぎ(いわゆるぼったくり)かという点です。複数社から相見積もりを取るのが定番ですが、稼働中のソフトウェアは他社に見せにくい場合もあります。

作業実績と契約条件を確認する監査の視点が、費用の妥当性を見極めるのに役立ちます。

作業報告書とログによる実稼働の算出

毎月の作業報告書とサーバーログを突き合わせて、実際の稼働時間を逆算します。

  • 作業報告書:対応件数と作業時間の記録です。
  • サーバーログ:サーバーへのアクセス状況の記録です。
  • 問い合わせ履歴:報告された対応内容と実態を照合する材料です。

月額固定契約は、契約上は一定の工数を前提に金額が決められています。実作業が契約工数を大きく下回れば、その差額分は払いすぎの可能性があります。

月20時間の契約で実作業が毎月数時間なら、契約工数の見直しを交渉できます。逆に、報告時間が契約を恒常的に超えても追加請求がないなら、その姿勢は信頼の証とも言えます。

提示された費用の数字をそのまま受け取らず、実稼働の裏付けを求めることが、適正価格への第一歩です。

契約形態と隠れコストの落とし穴

運用保守の多くは、完成責任を負わず継続的なサービスを提供する準委任契約です。

  • 印紙税:準委任契約は課税文書に該当しないことが多く、収入印紙が不要なケースがあります。
  • 作業範囲:含まれる内容が曖昧だと追加費用につながります。
  • 対象外作業:大規模改修、サーバー移行、データ移行などがあります。

これらの項目は、契約書の文面で確認しないと判断しにくいものです。

見積りや契約書には、対象外作業と追加料金の算定方法を明記してもらいます。

保守範囲の線引きを文書にしておくと、都度の高額な追加請求を防ぎやすくなります。

会社選びの材料を集めるには、ソフトウェア運用保守でおすすめの開発会社・ベンダー6選と選び方が参考になります。

ポイント

払いすぎかどうかは、作業報告書とログで実稼働を逆算して判断します。あわせて、対象外作業と追加料金の算定方法を契約書に明記してもらうと、後の追加請求を防げます。

保守費用を適正化する具体策

保守費用は値切るより、コストが生まれる構造に手を入れるほうが、持続的に適正化できます。なかでも、調査・分析の時間を減らす取り組みは、費用削減に直結します。

ドキュメント整備への投資

ドキュメント整備は、改修や障害対応の調査時間を短縮する投資です。

  • 設計の意図:文書にしておけば、改修時の調査を進めやすくなります。
  • データ構造:記録があれば、確認にかかる時間を抑えられます。
  • 過去の改修履歴:変更内容を追えれば、調査の手戻りを減らせます。

文書化で調査時間が短くなれば、長期的に保守費用を下げられます。

属人化したソフトウェアでは、キーマンが退職すると内部構造を知る人がいなくなります。その場合は調査コストが跳ね上がるため、ドキュメント整備が欠かせません。

ドキュメント整備は一時的な出費ですが、保守工数の30%を占める調査時間に効きます。

近年は、AIに既存コードを解析させて仕様を再構築するリバースエンジニアリングも実用化が進んでいます。人手だけで読み解く場合と比べ、AI解析を併用して調査を省力化できる場面も増えています。この手法は、肥大化した保守費用を構造面から下げる選択肢の一つです。

契約の定期見直しと相見積もりの活用

同じ会社に長く任せていると、契約工数と実態が食い違うことがあります。

  • 年次確認:年に一度、作業実績と契約内容を照合する作業です。
  • 参考見積もり:他社の見積もりを使って、現行費用を評価する材料です。
  • 総額判断:月額だけでなく、移行費用を含めた総額で比べることです。

既存ベンダーを含めて再見積もりを取ると、条件が見直されることがあります。実際に、競争が働いて既存ベンダーが条件を改善し、そのまま継続するケースは30〜40%程度です。

月額が安くても、会社を切り替える移行コストが300万〜500万円規模なら、総額では順位が逆転します。

5年単位の総コストで判断し、自社に合う保守体制を設計することが欠かせません。

riplaのように、コンサルティングから開発・運用まで一気通貫で支援するパートナーに相談するのも選択肢です。

まとめ

ソフトウェア運用保守費用は、TCOの約60%を占める大きな投資です。内訳が見えにくいため、妥当性を判断しづらい領域でもあります。

毎月の固定費と改修ごとの変動費を分けて、それぞれの相場と決まり方を理解しておきます。初期開発費に対する目安は、年間で5%前後、月額で0.5%前後です。規模やSLA水準によって増減します。

改修費用は、改造密度・分散度・母体錬度の3軸と人月単価をもとに算出されます。

費用の適正さは、作業報告書とログから実稼働を逆算して確認できます。

準委任契約では、対象外作業と追加料金の算定方法を確認しておくことが大切です。

適正化には、ドキュメント整備による調査時間の削減が有効です。

契約の定期見直しでは、移行コストを含む総額で保守体制を判断します。

費用の考え方をもとに自社の水準を点検し、ベンダーと対等に向き合える選択につなげます。金額だけでなく、その理由まで理解しておけば、交渉で論点を整理しやすくなります。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。