システム保守費用の相場「開発費の 15〜20%」は、何の数字なのか
開発会社から受け取った見積書に、保守の月額が載っています。高いのか安いのかを調べると、「保守費用の相場は年間で開発費の 15〜20%」という数字がよく出てきます。ところが、検索上位の解説記事を確かめた範囲では、この数字の出どころを示したものは見当たりませんでした。上司から「なぜこの金額なのか」と聞かれたときに、根拠として出すには心もとない数字です。
業界団体の調査をたどると、日本情報システム・ユーザー協会 (JUAS) の 「ソフトウェアメトリックス調査 2020」 に、稼働後 5 年間の保守費の調査結果があります。自社開発システムの保守費は年平均で開発費の 7.8%、追加開発費は 12.0% でした。「15〜20%」は、保守だけでなく追加開発まで含めた数字と読むと、この調査と合います。5 年間では、開発費とほぼ同じ額が上乗せされます。
この記事では、保守費用の相場をこの調査で分解したうえで、内訳、金額を動かす条件、上司に説明するための数字の組み立て、見積書と契約書で確かめる項目、高いと感じたときの見直し方を順に扱います。開発費そのものの見積もりの考え方は、システム開発の見積もり完全ガイド で解説しています。
FIXIT保守は開発費の 15〜20% って聞くけど、それって毎年かかるの？
Kaname毎年です。ただ、その数字には追加開発の分まで入っていると読むのが実態に近いです。
FIXITじゃあ、保守だけならもっと安いってこと？
KanameJUAS の調査では、保守だけなら年 7.8% です。現場では、保守と追加開発を別の行に分けて見積もります。
システム保守費用とは ─ 保守・運用・追加開発の違い
まず用語をそろえます。現場では混同されがちですが、契約書と見積書の上では別枠で扱われることが多くあります。
保守・運用・追加開発の 3 区分
| 区分 | 内容の例 | 見積もりの建て方 |
|---|---|---|
| 保守 | バグ修正、脆弱性対応、OS / ライブラリのアップデート追随、軽微な仕様調整 | 月額固定または年額 |
| 運用 | 監視、障害の一次対応、バックアップ、アカウント管理、定型作業 | 月額固定 + 従量 |
| 追加開発 | 新機能の追加、既存機能の大幅な改修、他システムとの連携の追加 | 都度見積もり (人月ベース) |
保守と運用を明確に分ける会社と、まとめて「保守運用」と呼ぶ会社があります。呼び方は問題ではありません。何が含まれ、何が別料金なのかが文書になっているかどうかが本質です。
保守作業の種類 ─ 不具合の修正だけではない
保守費を「壊れたときに直してもらう費用」と捉えると、何も起きない月の支払いが無駄に見えます。JUAS の調査は、保守作業を次の 7 つに分けています (図表 H3-2)。
| 保守作業の種類 | 中身 |
|---|---|
| 保守の問い合わせ | 問い合わせの受付・調査・回答、作業の見積もりと優先度の調整 |
| 改良保守 | バグの訂正ではないソフトウェアの変更 (適応保守と完全化保守の 2 つを含む) |
| 適応保守 | 法律の改正、新しい受注・顧客の仕様、OS やネットワークなど新しい技術環境への対応 |
| 是正保守 | 開発時や保守作業時に生じた不良の原因を調べ、直す |
| 保守の基盤整備 | 再現テストの環境、文書の履歴、作業ツールなど、保守を続けるための環境の維持 |
| 予防保守 | 潜在的な障害が表に出る前に見つけて直す |
| 完全化保守 | 性能・保守性・セキュリティ対策など、既存ソフトウェアの品質を上げる |
不具合の修正 (是正保守) は 7 つのうちの 1 つにすぎません。外部の環境が変わればシステムも合わせる必要があり、その準備のための環境も維持し続けます。保守費に何が含まれているかを見積書で確かめるときは、この 7 つのうちどれが対象かを聞くと、話がかみ合いやすくなります。
「軽微な仕様変更」は保守か追加開発か
最もグレーゾーンになりやすいのがこの境目です。「文言の修正やボタンの色の変更は保守の範囲、画面の追加や業務ロジックの変更は追加開発」と契約書に書いていないと、依頼のたびにもめる原因になります。契約時に「1 回あたり何時間以内、月の累計で何時間まで」といった上限を数字で決めておくのが実務的です。
システム保守費用の相場 ─ 年間で開発費の何%か
JUAS の調査では、保守 7.8% と追加開発 12.0%
JUAS「ソフトウェアメトリックス調査 2020」の図表 H2-80 (保守費用分析) は、自社開発したシステムについて、稼働後 5 年間の保守費と追加開発費を、初期開発費に対する割合で示しています。
| 年度 | 保守費 ÷ 初期開発費 | 追加開発費 ÷ 初期開発費 |
|---|---|---|
| 初年度 | 7.8% | 16.8% |
| 2 年度 | 7.5% | 13.2% |
| 3 年度 | 7.8% | 11.9% |
| 4 年度 | 7.6% | 8.8% |
| 5 年度 | 8.3% | 9.2% |
| 年平均 | 7.8% | 12.0% |
保守費は 5 年間ほぼ横ばいで、追加開発費は初年度が最も多く、年を追って減ります。同じ調査では、自社開発のシステムの 73.0% で、稼働後 5 年間に追加開発の実績がありました。4 件に 3 件近くは、稼働後に追加開発の費用が発生しています。
JUAS は 5 年間の総額を、開発費 + 開発費 × (7.8% + 12.0%) × 5 = 開発費の 1.989 倍とまとめ、考察で「5 年間でほぼ開発費と同じ費用がかかる」と書いています。
「15〜20%」は保守と追加開発の合計に近い
保守 7.8% と追加開発 12.0% を足すと 19.8% です。よく言われる「年間で開発費の 15〜20%」は、軽微な改修や追加開発まで含めた目安と読むと、JUAS の調査結果と矛盾しません。逆に、保守だけで毎年 15〜20% と読むと、調査の約 2〜2.6 倍の水準になります。
JUAS も考察では、保守と追加開発の合計を「保守費用」と呼んでいます。「保守費 15〜20%」という言い方が広まっている理由の 1 つと考えられます。
見積書を読むときは、保守の行に追加開発の予算が含まれているのかどうかを先に確かめてください。含まれていないのに 15〜20% なら、条件 (後述) が厳しいのか、規模に対して体制の固定費が大きいのかを確かめます。含まれているなら、どれだけの改修を月額の中で引き受けるのかを確かめます。
開発費別の試算
JUAS の比率を、開発費 500 万円・1,000 万円・3,000 万円 (いずれも税抜) に当てはめた試算です。FIXIT の実案件の金額ではありません。調査対象との規模の違いは、後述の「この数字を使うときの注意」を参照してください。
| 開発費 (税抜) | 保守費 (年 7.8%) | 追加開発費 (年 12.0%) | 合計 (年 19.8%) | 5 年間の総額 (開発費を含む) |
|---|---|---|---|---|
| 500 万円 | 年 39 万円 (月 約 3.3 万円) | 年 60 万円 | 年 99 万円 | 995 万円 |
| 1,000 万円 | 年 78 万円 (月 6.5 万円) | 年 120 万円 | 年 198 万円 | 1,990 万円 |
| 3,000 万円 | 年 234 万円 (月 19.5 万円) | 年 360 万円 | 年 594 万円 | 5,970 万円 |
追加開発費は年平均で計算しています。年度別の表のとおり初年度は 16.8% と多いため、開発費 1,000 万円なら初年度に 168 万円ほどを見込んでおくと、稼働直後の要望に対応する予算を確保しやすくなります。年度別の比率で積み上げても、5 年間の合計は年平均で計算した額とほぼ同じです。
パッケージを使う場合
同じ図表には、パッケージを使った開発の値もあります。パッケージ本体の追加導入と保守は年平均で本体と導入費の 10.9%、カスタマイズ部分の追加導入と保守は年平均でカスタマイズと導入費の 31.4% でした。5 年間の総額は、本体が約 1.54 倍、カスタマイズ部分が約 2.57 倍です。
パッケージを使えば保守費は下がると考えがちですが、カスタマイズの部分は、比率で見ると自社開発 (保守と追加開発で 19.8%) より高くなります。見積書では、本体の保守とカスタマイズ部分の保守を分けて書いてもらってください。
この数字を使うときの注意
注意
JUAS の調査対象は大規模な案件が中心です。自社開発システムの稼働までの開発費は、平均が約 7.4 億円 (7 億 3,787 万円)、中央値が 1.5 億円でした (図表 H2-10-1-1、549 件)。開発費が数百万円〜数千万円のシステムに同じ比率が当てはまるかは、調査からは確かめられていません。
ほかにも、数字を使う前に知っておきたい前提が 3 つあります。
- 比率は、各年度の保守費の平均を開発費の平均で割ったもので、案件ごとの比率の中央値ではありません
- 調査は 2019 年 7〜9 月に、JUAS の会員企業を中心に行われました
- 確認した範囲では、2025 年版 (「ソフトウェア・メトリクス調査 2025」と名称が変わっています) と 2026 年版に、保守費の比率の表はありません
それでも、保守と追加開発を分けて集計した業界団体の調査結果は、確認した範囲ではこの調査のほかに見当たりません。「開発費の何%か」を説明する根拠としては、出典が分からない「15〜20%」より、条件付きでもこの数字を示すほうが確かです。
保守費用の内訳 ─ 何にお金を払っているのか
定常作業と、体制を確保する費用
保守費は、2 つに分けて考えると分かりやすくなります。1 つは、ライブラリの更新、セキュリティパッチの適用、バックアップの確認、問い合わせへの回答のように、毎月発生する定常作業の費用です。もう 1 つは、障害が起きたときにすぐ動けるよう、担当者と時間を空けておく体制の費用です。
何も起きない月にも払うのは、体制の費用があるためです。障害が起きてから人を探すのでは、復旧までの時間を約束できません。反対に、止まっても翌営業日の対応で困らないシステムなら、体制の費用は小さくできます。見積書に「体制固定費」とあれば、月あたりどれだけの体制を確保しているのかを確かめてください。
保守契約に含まれる項目・含まれない項目
保守契約でもめる原因になりやすいのは、「これは保守の範囲だと思っていた」という認識のずれです。契約書の案を作る段階で、次の表のような整理をしておくと安全です。
| 含まれることが多い | 別料金になることが多い |
|---|---|
| 障害の調査・原因の特定 | 大規模な不具合が見つかったときの全面的な改修 |
| 見つかった不具合の修正 (納品済みの仕様の範囲) | 仕様の変更を伴う修正 |
| OS・ミドルウェア・ライブラリのマイナー更新 | メジャーバージョンアップ (言語・DB の世代交代) |
| セキュリティパッチの適用 | 脆弱性の発覚に伴う構成の変更 |
| 定型的な問い合わせへの対応 (月の件数に上限あり) | エンドユーザーへの直接のサポート |
| バックアップの正常性の確認 | データの復旧作業 (有事の対応) |
| 月次レポートの提出 | 個別の分析・KPI ダッシュボードの新規作成 |
「別料金になることが多い」作業が発生したときの単価も、契約時に決めておきます。単価が決まらないまま追加の作業を頼むと、あとから想定外の請求が来る原因になります。
見積書に載らない月額費用
開発費と保守費の議論に集中すると、月額のランニングコストが抜け落ちがちです。次の費目は、開発会社の見積書に載らず、サービスの提供元から直接請求されることが多いものです。
| 費目 | 課金のされ方 | 例 |
|---|---|---|
| クラウドインフラ | 負荷やデータ量に応じた月額 | AWS / Google Cloud / Azure |
| 監視・ログ基盤 | 監視対象の数とログの量に応じた月額 | Datadog / New Relic |
| エラー通知・性能計測 | イベント数に応じた月額 | Sentry / Bugsnag |
| メール・SMS の送信 | 送信数に応じた従量課金 | SendGrid / Twilio |
| CDN・画像配信 | プランの月額または転送量 | Cloudflare / CloudFront |
| 外部 API | 月額または従量 | 地図・決済・認証 |
| 有料ライブラリ・SaaS | ライセンスの月額・年額 | 業務ロジックで使う商用 SDK |
| ドメイン・SSL 証明書 | 年額 | 独自ドメイン、有料の証明書 |
| ステージング環境 | 本番とは別にかかる月額 | 検証用のサーバーとデータベース |
契約の名義が誰か (発注側か開発会社か)、支払い方法 (クレジットカードか請求書か)、費用が想定を超えたときの通知まで、初期の段階で決めておくと、経費処理と稟議が滞りません。
コツ
クラウドインフラと外部 API の従量課金は、利用量が読みきれない稼働直後ほど金額がぶれやすい費目です。開発会社に「想定利用量での月額」と「利用量が 2 倍に伸びたときの月額」の両方を試算してもらうと、稟議で説明しやすい数字になります。
保守料の勘定科目と、修繕費・資本的支出の分かれ目
保守会社への支払いを経理でどう処理するかも、保守と追加開発を分ける理由の 1 つです。勘定科目の名前は会社が決めるもので、「保守料」「支払手数料」などが使われます。税務上の区分は、国税庁の 法人税基本通達 7-8-6の2 (ソフトウエアに係る資本的支出と修繕費) が目安になります。
通達は、プログラムの修正が「機能上の障害の除去、現状の効用の維持等」にあたるときは修繕費、「新たな機能の追加、機能の向上等」にあたるときは資本的支出としています。保守契約の中で行う不具合の修正や環境への追随は前者に、追加開発は後者に寄ります。保守の月額に追加開発が混ざっていると、経理の側で切り分けにくくなります。
補足
修繕費と資本的支出のどちらにあたるかは、修正の中身で個別に判断されます。実際の処理は、顧問の税理士に確認してください。
保守費用を動かす条件 ─ IPA の非機能要求グレードで確かめる
同じシステムでも、保守の条件によって必要な体制が変わり、保守費は大きく変わります。条件をそろえないまま複数社の見積もりを並べても比較になりません。
条件をそろえる物差しとして使えるのが、情報処理推進機構 (IPA) の 「非機能要求グレード 2018」 です。性能や運用など、機能以外の要求を項目ごとに段階 (レベル) で定義した資料で、IPA は効果の 1 つに「情報システム費用の説明根拠の明確化」を挙げています。運用時間の項目の備考には、運用・保守性に関する開発コストや運用コストを検討するうえでも必要な項目だと書かれています。
運用時間と稼働率
止めてよい時間帯があるか、どれだけの停止を許すかで、監視と待機の体制が変わります。非機能要求グレードの稼働率の項目 (A.1.5.1) は、24 時間 365 日動かすシステムについて、年間の停止時間の合計を次のように示しています。
| 稼働率 | 年間で業務が中断する時間の合計 |
|---|---|
| 99% | 87.6 時間 |
| 99.9% | 8.76 時間 |
| 99.99% | 52.6 分 |
99% と 99.9% では、許される停止時間が 10 分の 1 になります。高い稼働率を約束するほど、冗長な構成、常時の監視、夜間の待機が必要になり、保守費に反映されます。「とりあえず高いほうに」と決めるのではなく、業務が止まったときの影響から逆算して決めるのが妥当です。
監視・バックアップ・パッチ適用の水準
非機能要求グレードの運用・保守性 (C) には、保守費に直結する項目が並んでいます。
| 項目 | 段階の例 | 保守費への影響 |
|---|---|---|
| 運用監視 (C.1.3) | 監視なし / 死活監視 / エラー監視 / リソース監視 / 性能監視 | 監視の対象が増えるほど、設定と対応の作業が増える |
| バックアップ (C.1.2) | 復旧できるデータの範囲、取得する時点と頻度 | 復旧の範囲が広いほど、確認と復旧訓練の作業が増える |
| パッチ適用ポリシー (C.2.3) | パッチ情報の展開方法、適用の方針、適用のタイミング、検証の有無 | 全パッチを検証して適用するほど、作業が増える |
障害時の対応と一次対応の分担
障害が起きたときに誰が、いつまでに動くかは、保守費を大きく変える条件です。非機能要求グレードでは、システムの異常を検知したときの対応可能時間 (C.3.3.1) を「ベンダの営業時間内」「ユーザの指定する時間帯」「24 時間対応」の段階で、ベンダー側の対応時間帯 (C.5.6.2) を「対応無し」「定時時間内 (9〜17 時)」「夜間のみ非対応 (9〜21 時)」「24 時間対応」などの段階で定義しています。一次対応をユーザーとベンダーのどちらが担うか (C.5.5.1) も項目の 1 つです。
契約で決めるサービスレベル (SLA) では、次の 3 点を確認してください。
- 応答時間: 障害の連絡から一次応答までの時間。「営業時間内 30 分以内」のように定める
- 復旧目標時間 (RTO): どれだけの時間で復旧させるかの目標。「4 時間以内」のように定める
- 稼働率: 月間または年間の目標値。「99.5%」のように定める
3 点のうち 1 つが厳しくなるだけで、必要な待機の体制と監視の構成が変わり、保守費に反映されます。
上振れしやすいシステム、下振れしやすいシステム
保守費が上振れしやすいのは、次のようなシステムです。
- 24 時間 365 日の稼働が必要で、夜間の障害の一次対応が発生する
- 決済・個人情報など、高いセキュリティが求められる領域を含む
- 外部システムとの連携が多く、連携先の仕様変更で保守作業が発生する
- 独自のフレームワークや古い技術で作られている
- 利用者が多く、問い合わせへの対応が積み上がる
反対に、次のようなシステムは下振れしやすくなります。
- 社内利用のみで、営業時間内の対応でよい
- 標準的で新しい技術で作られ、アップデートへの追随が容易
- 外部との連携が少なく、閉じたシステム
- 利用者が少なく、問い合わせが限られる
「開発費の何%」という比率だけで判断せず、自社のシステムがどの条件に当たるかを見積もりの依頼時に伝えると、条件のそろった見積もりが返ってきます。
保守費用の根拠を上司に説明する ─ 稟議に書く 3 つの数字
保守費の稟議で求められるのは、「この金額が妥当だと言える理由」です。開発会社の提示額をそのまま上げるのではなく、次の 3 つの数字で組み立てると、第三者の調査と自分で確かめた条件の両方で説明できます。
| 書く数字 | 求め方 | 稟議での使い方 |
|---|---|---|
| 比率 | 保守の年額 ÷ 開発費 | JUAS の目安 (保守 7.8%) と並べ、差がある場合はその理由を条件で示す |
| 5 年総額 | 開発費 + 保守 + 追加開発の予算 + 月額固定費 (各 5 年分) | 作ったあとにかかる費用を、最初の稟議でまとめて承認してもらう |
| 中身 | 含まれる作業、対応時間帯、含まれない作業の単価 | 金額が何に対する支払いかを示し、後日の追加請求を防ぐ |
計算例 (架空のシステム)
開発費 1,000 万円 (税抜) の業務システムで、保守の見積もりが月 8 万円、クラウドなどの月額固定費が月 3 万円という架空の例で計算します。FIXIT の実案件の数字ではありません。
- 比率は、保守の年額 96 万円 ÷ 開発費 1,000 万円 = 9.6% です。JUAS の 7.8% より高い理由として、「平日 9〜21 時の対応」「エラー監視を含む」など、見積書の条件を添えます
- 追加開発の予算は、年度別の比率を当てると初年度 168 万円、2 年度 132 万円と年を追って減り、5 年間で約 600 万円 (年平均 12.0%) です
- 5 年総額は、1,000 万円 + 保守 480 万円 + 追加開発 600 万円 + 月額固定費 180 万円 = 2,260 万円です
5 年総額のうち、開発費は半分以下です。開発費だけで稟議を通すと、残りは毎年の予算で個別に通すことになります。最初に 5 年総額を示しておけば、追加の稟議を回す手間と、予算が足りずに改修が止まる事態を避けやすくなります。複数社の見積もりを期間総額で並べる表の作り方は、見積もりガイドの 保守費用まで足した期間総額で並べる を参照してください。
見積書と契約書で確かめること
保守費の出し方 ─ 比率で出しているか、作業と体制を積み上げているか
保守費の出し方は、大きく 2 つあります。1 つは開発費に比率を掛ける方法で、計算は簡単ですが、条件が反映されません。もう 1 つは、定常作業の時間と体制の量を積み上げ、単価を掛ける方法です。手間はかかりますが、条件を変えたときに金額がどう変わるかを説明できます。
見積書に「保守一式」と月額しか書かれていない場合は、どちらで出したのかを聞いてください。積み上げで出しているなら、作業ごとの時間と体制の量を見せてもらえます。参考までに、JUAS の同じ調査では、ユーザー企業が保守契約で払っている人月単価として、各社が回答した最低単価の平均が 74.6 万円、最高単価の平均が 132.8 万円でした (図表 H1-8-7、2018〜2020 年の累積、回答 35〜36 社)。
SLA と、含まれない作業の単価・最低契約期間・解約条件
契約書では、前の章の SLA の 3 点に加えて、次の項目を確かめます。
- 含まれない作業を頼んだときの単価と、見積もりの手順
- 月額に含まれる作業の上限 (問い合わせの件数、改修の時間) と、超えたときの扱い
- 最低契約期間と、解約の申し入れ期限
- 契約終了時の、ソースコード・資料・管理権限の受け渡し
最後の項目は、保守会社を替えたくなったときの選択肢を左右します。
追加開発の見積もりを確かめる 4 つの観点
JUAS の調査でも、自社開発のシステムの 7 割強に、稼働後の追加開発の実績があります。提示された追加開発の見積もりが妥当かは、次の 4 つの観点で確かめます。
- 工数の内訳が要件単位で示されているか。「一式で何人月」ではなく、要件ごと・テスト・リリース作業のそれぞれに何人日かかるのかまで分かれているかを確認します
- 既存のコードへの影響範囲が示されているか。追加開発では、既存機能の回帰テストが想定より大きくなりがちです。影響を受ける画面と機能、テストの範囲が書かれているかは、見積もりの質を見る指標になります
- 初期開発時の単価と整合しているか。同じ会社・同じ体制で単価が大きく上がっているなら、理由 (希少なスキルを持つ担当者の参加など) を説明してもらいます
- 別の会社に頼んだ場合と比べられるか。自社で工数を検算できないときは、相見積もりも選択肢です。ただし別の会社には既存コードを読み解く工数がかかるため、単純には比べられません
追加開発の見積もりは、保守の月額とは別の書類で受け取り、上の 4 つの観点で確かめてから発注してください。
保守費用が高いと感じたら ─ 見直しの順番
いま払っている保守費が相場から外れているように見えても、いきなり保守会社を替えるのは得策ではありません。次の順番で確かめると、関係を壊さずに条件を見直せます。
- 実績の開示を求める。過去 1 年の対応件数、作業時間、障害の件数と復旧時間を出してもらいます。使われていない条件 (夜間の待機など) が無いかが分かります
- 条件を見直す。業務への影響から考えて、対応時間帯・監視の水準・稼働率の目標を下げられるなら、その条件で再見積もりを依頼します
- 相見積もりを取る。条件を文書にして、ほかの会社にも同じ条件で見積もりを依頼します。乗り換えの初期には現状調査や並行期間の費用がかかるため、月額だけでなく総額で比べます
- 保守だけを他社へ移す、または内製化する。保守だけを移す判断と手順は システム保守の引き継ぎ で、開発会社の乗り換え全体は システム引き継ぎの進め方 で解説しています
FIXIT何も起きない月まで払うの、正直もったいなくない？
Kaname払っているのは待機の体制です。夜間の対応が要らないなら、条件から外せます。
FIXITふーん。じゃあ、いきなり保守会社を替えるのは？
Kaname先に保守会社から対応の実績を出してもらい、契約と照らし合わせます。替えるかどうかはその後です。
内製化も選択肢の 1 つです。FIXIT が支援した学校法人の事例では、外部に委託していた公式サイトの保守を教職員が担えるようにし、約 1 か月半の支援で、月額 30 万円の保守外注費が不要になりました (詳細は 公式サイトの保守を内製化した事例)。対象は Web サイトの保守で、業務システムとは条件が違いますが、日常の運用を手元に戻し、外部に頼む作業を絞るという考え方は共通です。
FIXIT に相談する場合 ─ 保守費は 5 年総額と条件をセットで見る
FIXIT は AI 駆動開発のクリエイティブスタジオとして、保守運用フェーズを含めた長期コストの試算をお渡ししています。ご相談いただければ、保守と追加開発を含めた 5 年間の費用の見通しを、対応時間帯・監視の水準・含まれる作業の条件付きでお出しします。条件を変えたときに金額がどう変わるかも、あわせてご説明します。
保守の定常作業には、AI に任せられる部分があります。一方で、障害がどこまで影響しているかの判断や、業務に合わせた優先順位の決定は人が担う領域です。保守費を抑えることと、止まったときに責任を持てる体制を残すことの釣り合いを、見積もりの条件として一緒に検討できます。
まとめ
システム保守費用の相場としてよく聞く「開発費の 15〜20%」は、JUAS の調査では保守 7.8% と追加開発 12.0% の合計に近い数字です。5 年間では開発費とほぼ同じ額が上乗せされ、総額は開発費の約 2 倍になります。調査対象は大規模な案件が中心なので、比率は目安にとどめ、運用時間・稼働率・監視・障害時の対応時間などの条件で金額を確かめてください。上司への説明は、比率・5 年総額・含まれる作業と対応時間の 3 つの数字で組み立てます。
次の一歩は、手元の見積書で保守の行に何が含まれているかを確かめることです。保守と追加開発が分かれているか、対応時間帯と含まれない作業の単価が書かれているかを見てください。判断がつかない場合は、FIXIT の 見積書の無料診断 で、保守の月額を含む見積書の抜け漏れを確認できます。開発費の相場から確かめたい場合は Web システム開発の費用と期間の相場 を、開発前から 5 年間の費用を含めて相談したい場合は AI 駆動開発 や お問い合わせ からご連絡ください。今の保守会社からの乗り換えを考えている場合は、開発会社の乗り換え・システム引き継ぎ もあわせてご覧ください。