システム保守費用の目安と根拠｜IPA統計で読み解く費用比率

「保守費用は、開発費の15〜20%が相場です」。ベンダーからこう説明され、年間で数十万円から数百万円の保守費を払い続けている。けれども、その数字がどこから来ているのか、自社の請求額が本当に妥当なのかを、自分の言葉で説明できるでしょうか。

来期予算の査定で経営や経理から「この保守費の根拠は？」と問われたとき、「相場だからです」としか答えられない。ベンダーに内訳を聞いても「一式で15%です」と返ってくるだけで、それ以上の説明が得られない。多くの発注担当者が、この「根拠を持てないまま固定費を払い続ける」状態に置かれています。

問題は、保守費用の比率そのものよりも、その比率の「中身」が見えないことにあります。15〜20%という数字は決して根拠のない数字ではありません。公的統計や国際規格に裏打ちされた、れっきとした実態の反映です。逆に言えば、その根拠を理解すれば、ベンダー提示額を区分ごとに分解し、「この部分にこの金額は妥当か」と自分の言葉で問い返せるようになります。

本記事では、システム保守費用の目安である「開発費の15〜20%」が何を根拠にしているのかを、IPA（独立行政法人情報処理推進機構）の統計と、国際規格にもとづく保守の4分類から解き明かします。さらに、その4分類を積み上げて15〜20%を「検算」する手順までを示し、見積もりの内訳をベンダーに問える判断軸をお渡しします。

なお、相場一覧や規模別の費用感、妥当性チェックの網羅的な手順については、関連記事のシステム保守費用の相場と算出方法で詳しく扱っています。本記事は「なぜその比率なのか」という根拠の深掘りに絞って解説します。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

システム保守費用の目安は「開発費の15〜20%」その数字の正体

まず結論からお伝えします。システムの年間保守費用の一般的な目安は、初期開発費の15〜20%です。対象や運用条件によっては15〜25%程度まで幅を持って語られることもあります。

年間保守費用の目安は開発費の15〜20%

具体的な金額に落とすと、イメージがつかみやすくなります。

たとえば開発費1,000万円のシステムであれば、年間150〜200万円、月額にして12.5〜16.7万円が一つの目安になります。多くのベンダーが見積もりの根拠として持ち出すのが、この比率です。

ここで押さえておきたいのは、この15〜20%という数字が「経験則」や「なんとなくの相場」ではなく、ソフトウェア保守の実態を反映した数字だという点です。なぜその比率に落ち着くのかは、のちほど公的統計と保守の分類から順を追って説明します。

「相場だから」の落とし穴｜比率だけでは妥当性は判断できない

一方で、注意していただきたいのは、比率だけを見て妥当性を判断することはできない、という点です。

同じ「開発費の20%」でも、その中身がどう積み上がっているかは、システムによって大きく異なります。24時間365日の障害対応を含むのか、年に数回の法改正対応が前提なのか、機能改善を継続的に行う想定なのか。これらの条件次第で、適正な比率は12%にも25%にもなり得ます。

つまり、「15〜20%だから妥当」「25%だから高すぎる」という判断は、本来は成り立ちません。妥当性を語るには、その比率がどんな保守作業の積み上げなのか、つまり「内訳の根拠」を理解している必要があります。

ベンダーの「相場で15%です」という説明に違和感を覚えるとすれば、それはこの内訳が示されていないからです。次の章からは、この比率の根拠を、まず公的統計で、続いて保守の分類で分解していきます。

なぜ「開発費の15〜20%」なのか｜IPA統計が示す保守の実態

「15〜20%」という比率を根拠で裏づけるとき、最も信頼できる出発点が、IPA（独立行政法人情報処理推進機構）が公開しているソフトウェア開発の統計データです。

IPA「ソフトウェア開発分析データ集」とは

IPAは、国内のソフトウェア開発プロジェクトから収集した定量データを分析し、その結果を継続的に公開してきた公的機関です。その集大成が、2022年に公開された「ソフトウェア開発分析データ集2022」です。

このデータ集は、2004年から蓄積されてきた5,546プロジェクトの開発データをもとに、工数・工期・規模・生産性・信頼性などを分析したものです（IPA ソフトウェア開発分析データ集2022）。一企業や一ベンダーの経験ではなく、業界横断の大規模な実データにもとづく点に、出典としての信頼性があります。

ベンダーの「相場です」が一社の経験則だとすれば、IPAの統計は業界全体の実態を映した客観的な数字です。発注者として根拠を問うとき、この違いは大きな意味を持ちます。

統計が示す「保守・改修が開発の主役」という現実

このデータ集が示す事実のうち、保守費用の根拠として重要なのが、開発プロジェクトに占める「改修・保守」の比重の大きさです。

IPAの分析によれば、調査対象プロジェクトのうち新規開発は3割弱（約29%）にとどまり、改修・保守が5割強（約51%）を占めています。この2つで全体の8割弱に達します。さらに、2014〜2019年度と2016〜2021年度を比較すると、新規開発が32.5%から29.1%へ減少する一方、改修・保守は45.8%から51.5%へと増加しています（IPA ソフトウェア開発分析データ集2022）。

この数字が意味するのは、ソフトウェアの一生において、最初に作る費用よりも、作った後に維持・改修する費用のほうが大きくなりうる、という現実です。システムは「作って終わり」ではなく、稼働してからのほうが長く、そこに継続的な費用が発生し続けます。

保守費用が「開発費の15〜20%」という決して小さくない比率を毎年占めるのは、こうした保守の比重の大きさを反映していると理解できます。

なお、IPAが「保守費＝開発費の15%」という比率そのものを定義しているわけではない点には注意が必要です。IPAの統計が裏づけるのは、あくまで「保守・改修の比重が大きい」という実態であり、15〜20%という比率は、後述するハードウェア保守の慣行や人月単価の積み上げと組み合わせて成り立つ、業界の経験値です。統計はこの経験値を「妥当な水準だ」と補強する位置づけになります。

比率が15〜20%に収束する背景

では、なぜその比率が「15〜20%」という具体的な水準に落ち着くのでしょうか。背景には、いくつかの業界慣行があります。

一つは、ハードウェアやパッケージソフトの保守料率の慣行です。サーバー機器やソフトウェアライセンスの年間保守料は、購入額の15〜20%程度に設定されることが一般的で、システム全体の保守料率もこの水準が一つの基準になっています。

もう一つは、人月単価との関係です。保守には、障害対応の待機要員、定期的な状態確認、問い合わせ対応などに一定の工数が継続的に必要です。これを担当者の人月単価で積み上げると、開発時の総工数に対して年あたり15〜20%程度の工数になることが多く、結果として費用も同程度の比率に収束します。

つまり「15〜20%」は、IPAが示す保守比重の大きさという実態を土台に、ハードウェア保守の慣行と人月工数の積み上げが組み合わさって導かれる水準だと整理できます。次の章では、この比率の中身をさらに具体的に分解していきます。

保守費用の正体を分解する｜保守4分類と費用比率

「15〜20%」を根拠で語るうえで、もう一つの強力な武器が、保守作業を性質ごとに分類する考え方です。これにより、漠然とした「保守一式」を、目的の異なる4つの区分に分解できます。

保守を4つに分ける国際規格 ISO/IEC 14764

ソフトウェアの保守は、国際規格 ISO/IEC 14764（日本では JIS X 0161 として規格化）によって、4つのタイプに分類されています（JIS X 0161:2008）。

この4分類のうち、是正保守と予防保守は「訂正」のための作業、完全化保守と適応保守は「改良」のための作業と整理されます。重要なのは、これらが性質も発生タイミングも費用構造もまったく異なる、ということです。ベンダーの見積もりが「保守一式」とまとめられていると、この違いが見えなくなります。

参考として、保守作業がこの4分類でどう配分されるかについては、ソフトウェア工学の古典的な調査結果があります。Lientz と Swanson による1978年の調査では、保守工数のうち是正保守が17.4%、適応保守が18.2%、完全化保守が60.3%、その他が4.1%という分布が示されました（Lientz and Swanson on Software Maintenance）。この比率は、その後数十年の研究を経ても大きくは変わらないことが知られており、保守工数の半分以上が「完全化保守（改良系）」に費やされるという傾向は、現在でも一つの目安になります。

以下、各区分が何のための費用なのかを順に見ていきます。

是正保守｜障害・バグ修正は予測しにくいが必須の費用

是正保守は、システムを稼働させたあとに見つかった不具合やバグを修正する作業です。

この区分の特徴は、いつ・どれだけ発生するかが事前に読みにくいことです。だからこそ、年間契約のなかに「一定時間までの障害対応」として、いわば保険的に費用が組み込まれます。障害がほとんど起きなくても、対応できる体制を維持するための費用が発生する、という点を理解しておくと、見積もりの読み方が変わります。

適応保守｜環境変化への追従は放置するとリスク化する費用

適応保守は、システムそのものに問題がなくても、外部環境の変化に合わせてシステムを変更する作業です。

OSやミドルウェアのバージョンアップ、利用しているライブラリのサポート終了、税率変更や法改正への対応などが該当します。これらは「今は動いているから」と放置すると、ある日突然システムが動かなくなったり、法令違反のリスクを抱えたりする費用です。発生タイミングは外部要因に左右されるため、年によって変動します。

完全化保守｜比率が最も大きくなりやすい区分

完全化保守は、システムの性能を改善したり、使い勝手を良くしたり、軽微な機能を追加・改善したりする作業です。

先ほどの調査でも示したとおり、保守工数のなかで最も大きな比率を占めやすいのがこの区分です。システムを使い続けるうちに「ここを改善したい」「この処理を速くしたい」という要望は必ず出てきます。これらに継続的に応えるための費用が、保守費の相当部分を占めることになります。逆に言えば、自社が機能改善をほとんど求めないのであれば、この区分の比率を下げられる余地があります。

予防保守｜削られがちだが将来コストを左右する区分

予防保守は、まだ問題は起きていないものの、将来の障害につながりかねない潜在的なリスクに先回りして対応する作業です。

セキュリティ脆弱性への対応や、保守性を悪化させているコードの整理（リファクタリング）などが含まれます。目に見える効果が出にくいため、コスト削減の対象として真っ先に削られがちな区分ですが、これを怠ると将来の是正保守コストや障害リスクが膨らみます。比率としては小さくても、長期的なコストを左右する重要な区分です。

算出ロジック｜区分の積み上げで15〜20%を検算する

ここまでで、保守費用が4つの区分に分解できることを見てきました。この章では、その4区分を金額に落とし込み、「開発費×15〜20%」を自分で積み上げて検算する手順を示します。

ステップ式の検算手順

自社の保守費用が妥当かを検算するには、次の手順で考えます。

1. 基準となる開発費を確認する：検算の出発点は初期開発費です。仮に1,000万円とします。
2. 区分ごとに想定比率を当てはめる：保守4分類それぞれが、開発費に対してどの程度の比率になりそうかを置きます。下表は一つの目安です。
3. 積み上げて年間保守費を組み立てる：各区分の金額を合算し、開発費に対する総比率を確認します。

※ 上表の区分別比率は、保守工数の配分傾向（完全化保守の比重が大きい）を費用比率に置き換えた目安です。実際の比率は契約条件によって変動します。

この積み上げの結果、合計が14〜23%という幅に収まり、その中心が「15〜20%」になることがわかります。重要なのは、最初から「15%」という結論を受け取るのではなく、区分ごとに積み上げてその比率に至るプロセスを自分で再現できる、という点です。これができれば、ベンダー提示額の妥当性を区分ごとに語れるようになります。

なお、ここで示したのは「根拠の積み上げ方」に絞った検算ロジックです。開発費比率方式・人月方式・SLA方式といった代表的な算出方式の使い分けについては、システム保守費用の相場と算出方法で詳しく解説しています。

比率が15〜25%に振れる要因

検算をすると、自社の比率が目安の15〜20%から外れることがあります。その場合、比率を上下に振っている要因を特定することが大切です。比率を押し上げる主な要因は次のとおりです。

• システム規模・複雑性：システムが大きく複雑なほど、把握・対応に工数がかかり、是正・完全化保守の比率が上がります。
• 技術的負債：開発時の作りが急ごしらえだったり、ドキュメントが不足していたりすると、保守のたびに余計な工数がかかり、比率が高くなります。
• 24時間365日対応：夜間・休日も含めた監視・対応体制を求めると、待機要員のコストが乗り、是正保守の比率が大きく上がります。
• SLAの厳しさ：「障害発生から1時間以内に復旧」のような厳しい応答品質を求めるほど、体制維持コストが増え、比率が上がります。

逆に、平日日中のみの対応で十分、機能改善はほとんど求めない、といった条件であれば、比率は15%を下回ることもあります。SLAと費用の関係や契約形態の選び方については、システム保守契約の種類と内容も参考になります。

算出結果が相場から外れたときの読み解き方

検算した結果が目安から外れたとき、それが「問題」なのか「妥当な理由がある」のかを読み解く視点を持っておきましょう。

比率が高すぎる場合（25%超）：24時間対応やSLAの厳しさなど、上記の押し上げ要因に該当する条件があれば、高い比率にも根拠があります。逆に、そうした条件がないのに比率が高いなら、内訳の説明をベンダーに求める余地があります。

比率が安すぎる場合（10%未満）：一見お得に見えますが、本来必要な予防保守や適応保守が契約範囲から外れている可能性があります。安さの裏で、いざというときの対応が「別料金」になっていないかを確認すべきです。

つまり、相場から外れていること自体が良し悪しを決めるのではなく、「なぜ外れているのか」を区分の言葉で説明できるかどうかが、妥当性判断の核心になります。

根拠を武器にする｜見積もりの内訳をベンダーに問う観点

ここまでで手に入れた根拠を、実際のベンダーとのやり取りでどう使うか。最後に、見積もりの内訳を「根拠で問う」ための具体的な観点を示します。

ベンダーに開示を依頼すべき内訳

ベンダーの見積もりが「保守一式 年間〇〇万円」とまとめられている場合、まず依頼すべきは、保守4分類ごとの内訳開示です。

具体的には、「この保守費用を、是正保守・適応保守・完全化保守・予防保守の4区分に分けると、それぞれどの程度の工数・金額の想定ですか」と尋ねます。この質問に明確に答えられるベンダーは、保守の中身を設計したうえで見積もっています。逆に答えに詰まるようであれば、その「一式」の妥当性そのものを問い直す根拠になります。

契約段階でこの内訳を担保しておくと、後々の追加請求トラブルも防ぎやすくなります。保守と運用の線引きが曖昧だと費用がグレーゾーン化する点については、保守と運用の違いで詳しく扱っています。

比率の根拠を確認する質問例

内訳の開示と合わせて、比率の根拠を確認する質問を用意しておくと、交渉の主導権を握りやすくなります。以下は、本記事の内容を踏まえた質問例です。

• 「この保守費（開発費の20%）は、4分類のどの区分がどの程度の比率で積み上がっていますか」
• 「完全化保守（機能改善）が含まれているなら、年間でどの程度の改善対応を想定した費用ですか」
• 「24時間対応やSLAは比率にどう反映されていますか。日中対応のみにすると比率は下がりますか」
• 「予防保守（脆弱性対応）は契約に含まれていますか。含まれていない場合、別料金の目安はどの程度ですか」

これらの質問の狙いは、ベンダーを問い詰めることではありません。保守費用を区分の言葉で会話できる状態をつくり、自社の利用実態に合った保守内容へと最適化していくことにあります。根拠を持って問えば、ベンダーも根拠で応えるようになり、結果として双方が納得できる保守契約に近づきます。

なお、保守費用そのものを抑えたい場合の打ち手については、システム開発のコスト削減で開発・契約・運用の各段階の工夫を解説しています。

まとめ｜「相場です」を根拠で検証できる発注者になる

システム保守費用の目安と根拠について解説してきました。要点を整理します。

• 年間保守費用の目安は、初期開発費の15〜20%（広めに見て15〜25%）です。
• この比率は経験則ではなく、IPAの統計が示す「保守・改修の比重の大きさ」という実態を土台にしています。
• 保守は国際規格 ISO/IEC 14764 にもとづき、是正・適応・完全化・予防の4分類に分解できます。
• この4分類を区分ごとに積み上げると、15〜20%という比率を自分で検算でき、相場から外れたときの読み解きもできます。
• 区分の内訳と比率の根拠をベンダーに問えば、「相場です」で押し切られず、自社に合った保守契約へと交渉できます。

「保守費は15〜20%が相場です」というベンダーの一言を、これからは「その20%は4分類のどの積み上げですか」と問い返せます。比率を結論として受け取る側から、根拠を持って分解・検算できる側へ。それが、固定費としての保守費用を、納得できる投資へと変える第一歩です。

次のアクションとして、まずは手元の保守見積もりを保守4分類に当てはめて分解してみてください。そのうえで、内訳が見えない部分があればベンダーに開示を依頼する。この2つを実行するだけで、来期予算の根拠説明は格段に説得力を増します。

なお、相場の規模別一覧、妥当性を多角的にチェックする手順、実際の成功・失敗事例については、システム保守費用の相場と算出方法で網羅的に扱っています。本記事の「根拠の理解」と合わせてご活用ください。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。