システム保守費用の計算方法｜IPA基準15〜20%の根拠と業種別相場一覧

1. システム保守費用の基本的な計算方法

システム保守費用を見積もる際には、主に3つのアプローチがあります。それぞれの特徴と使いどころを理解することが、適正な費用管理への第一歩です。

開発費ベースの算出（IPA基準）

最も広く使われているのが、開発費に一定の比率を掛ける方法です。IPA基準では年間保守費用 ＝ 開発費 × 15〜20%が目安とされています。

たとえば、開発費1,000万円のシステムであれば、年間150〜200万円（月額12.5〜16.7万円）が保守費用の目安です。この方法はシンプルで比較しやすいため、予算計画やベンダー見積もりの妥当性チェックに向いています。

FP（ファンクションポイント）法

FP法はシステムの機能規模を数値化し、保守工数を算出する手法です。入力画面・出力帳票・外部連携などの機能を点数化して合計し、「1FPあたりの保守単価 × 総FP数」で費用を計算します。

この手法はシステムの機能規模が明確な場合に精度が高く、大規模システムや追加開発が多い場合に適しています。ただし、FPの計測には専門知識が必要で、中小企業が単独で算出するには難易度が高い面もあります。

工数ベースの算出

保守に必要な人月（man-month）を積み上げて費用を計算する方法です。月次保守費用 ＝ 月間保守工数（人月） × エンジニア単価の式で算出します。

月0.5人月のエンジニア（単価80万円/月）なら40万円、という形で算出できます。保守範囲が明確で、作業内容が定型的な場合に適しています。実際の契約では、この工数積算に「管理費・間接費（15〜20%程度）」を加算して提示されるケースが多いです。

2. IPA基準「15〜20%」の根拠と背景

「開発費の15〜20%」という数字は、どこから来ているのでしょうか。単なる業界慣習ではなく、調査データに基づいた根拠があります。

IPAソフトウェアメトリクス調査の概要

IPA（情報処理推進機構）は、国内のソフトウェア開発・保守プロジェクトのデータを継続的に収集・分析し、「ソフトウェア開発分析データ集」として公開しています。この調査では数千件以上の実プロジェクトデータをもとに、保守費用の実態が統計的に集計されています。

調査の結果、国内企業のシステム保守費用は開発費の10〜25%の範囲に大半が収まり、中央値が15〜20%付近に集中していることが確認されました。これがIPA基準として広く参照されるようになった背景です。

なぜ15〜20%なのか

ソフトウェアは稼働後も継続的なコストが発生します。主な要因は以下の3点です。

• ソフトウェアの経年劣化：OSやフレームワークのバージョン変化により、定期的な対応が必要になります。一般的に5〜7年でシステムの大幅刷新が必要とされ、それまでの維持コストが年15〜20%に相当します。
• 技術負債の蓄積：開発時の設計判断が後々の保守コスト増につながります。技術負債の解消（リファクタリング）も保守コストに含まれます。
• 外部環境の変化対応：法改正・セキュリティ脅威・業務フローの変化など、システム外部からの変化への対応コストが常に発生します。

海外との比較（Gartner基準等）

Gartnerなどの国際的な調査機関でも、ITシステムの保守費用について類似の基準が示されています。米国では「Total Cost of Ownership（TCO）」の観点から、年間運用・保守費用を初期開発費の20〜25%と見る調査もあります。日本のIPA基準がやや低めなのは、国内市場での人件費水準や、保守範囲の定義の違いが影響しています。

3. 業種別・規模別の保守費用比率一覧

IPA基準の15〜20%はあくまで平均値です。業種・システム特性・規模によって実態は大きく異なります。

業種別の保守費用比率

以下は一般的な目安です。実際の費用はシステムの複雑性や保守範囲によって変動します。

中小企業 vs 大企業の違い

規模によっても保守費用の構造が異なります。大企業は専任の保守チームを抱えるため固定費が高くなる一方、スケールメリットで単価を抑えられます。中小企業は外注に頼るケースが多く、保守範囲を絞ることでコストを最適化する必要があります。

中小企業の場合、月額5〜20万円の定額保守契約が一般的です。この金額帯では「緊急障害対応・月次定期メンテナンス・セキュリティパッチ適用」が含まれるケースが多く、機能改修は別途見積もりになることがほとんどです。

クラウド vs オンプレの保守費用差

クラウドシステムはインフラ保守（サーバー・ネットワーク管理）がクラウドベンダー側に移管されるため、オンプレと比べてアプリケーション保守に集中できます。一般的にクラウドの場合は保守費用比率が2〜5%程度低くなる傾向があります。ただし、クラウド利用料自体が運用コストとして加算されるため、総コストでの比較が重要です。

4. 保守費用に含まれる作業の内訳

保守費用の妥当性を判断するためには、何がコストに含まれているかを明確にする必要があります。JIS X 0161（ソフトウェアライフサイクルプロセス）では、ソフトウェア保守を4種類に分類しています。

予防保守（定期メンテナンス・セキュリティパッチ）

障害が発生する前に手を打つ予防的な作業です。定期的なログ監視・バックアップ確認・セキュリティパッチ適用などが含まれます。費用全体の20〜30%を占めるのが一般的です。サイバー攻撃が増加している現代では、この比率を下げすぎるとリスクが高まります。

是正保守（バグ修正・障害対応）

発生したバグや障害を修正する事後対応です。稼働中のシステムで最も頻繁に発生する保守作業で、費用全体の40〜50%を占めることが多いです。SLA（サービスレベル合意）で対応時間を定めることで、突発的なコストを予測しやすくなります。

適応保守（OS・ミドルウェアのアップデート対応）

OSやフレームワーク・ライブラリのバージョンアップへの追従作業です。特にEOL（サポート終了）を迎えたバージョンの更新対応は、放置するとセキュリティリスクに直結します。費用全体の15〜25%程度を見込むのが適切です。

完全化保守（機能改善・パフォーマンスチューニング）

既存機能の改善や処理速度の最適化など、「壊れていないが改善できる」部分への投資です。費用全体の10〜20%が目安ですが、ビジネス成長フェーズにある企業では比率が高くなります。この部分は追加開発と境界が曖昧になりやすいため、契約時に範囲を明確に定義することが重要です。

5. 保守費用を適正化する5つのポイント

ポイント1: SLA（サービスレベル合意）の明確化

保守費用の大部分は「いざというときの対応力」への対価です。SLAで「障害発生から○時間以内に初動対応」「月間稼働率99.5%以上」といった具体的な水準を合意することで、過剰な費用支払いや逆に対応が遅い状況を防げます。

SLAの詳細な読み方や交渉のコツについては、SLA（サービスレベル合意）の見方｜保守契約で確認すべき項目と交渉のコツもご参照ください。

ポイント2: 保守範囲の定義と優先度設定

「何でも保守に含む」という契約は、ベンダーにとって都合がよいですが、発注者側にとってはコスト管理が難しくなります。保守対象のシステム・機能・対応種別を明示し、優先度の高い作業から予算を配分することが重要です。

ポイント3: 自動化ツールの活用

監視・アラート・バックアップなどの定型作業は自動化することで保守工数を削減できます。クラウドサービスの監視ツール（CloudWatch・Datadog等）やCI/CDパイプラインを整備することで、エンジニアの手作業を減らし、実質的な保守コストを下げられます。

ポイント4: 定期的な見直しと再見積もり

保守費用は一度決めたら固定ではありません。システムの安定稼働が続き障害頻度が下がれば、是正保守の比率を下げて費用を削減できます。年1回程度の保守契約見直しを習慣化することで、数年で大幅なコスト最適化が可能です。

ポイント5: 外部委託 vs 内製の検討

システムの複雑さ・社内のエンジニアリソース・コスト感によって、外注と内製の最適なバランスは異なります。外注は専門性が高く安定しますが、固定コストがかかります。内製はコストを抑えやすいですが、属人化リスクが生じます。

判断基準の詳細は中小企業のシステム保守｜内製 vs 外注、どちらがコスパが良い？をご参照ください。

まとめ

システム保守費用の計算方法と、IPA基準「15〜20%」の根拠を整理しました。

• IPA基準は国内数千件の実プロジェクトデータに基づく統計的な目安
• 業種によって10〜30%と幅があり、金融・医療・行政は高め、製造・ITは低め
• 保守費用は是正保守（40〜50%）・予防保守（20〜30%）・適応保守（15〜25%）・完全化保守（10〜20%）で構成される
• SLAの明確化と保守範囲の定義が費用適正化の基本

保守費用の全体像（相場・契約形態・会社選び）については、システム保守の費用相場と選び方ガイドもあわせてご覧ください。システム保守のご相談はFUNBREWのサービスページからもお気軽にどうぞ。