LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

保守の見積もりが毎年「一式」で届き、何にいくらかかっているのかが分からない。契約を更新するたびに金額が変わるのに、その理由を社内で説明できない——。システムの保守を委託している企業では、こうした悩みが起こりがちです。システム保守費用の根拠とは、その金額がどんな作業と体制に対して支払われているのかを示す内訳と前提のことです。

根拠が分かれば、見積もりの妥当性を発注する側で確かめられるようになります。ただし根拠を確かめる方法も万能ではなく、内訳を分けただけで、ふさわしい金額が一つに決まるわけではありません。本記事では、保守を委託している発注担当者に向けて、費用の内訳、見積もりの考え方、見積書で確かめたい点、そして相場の使い方と費用を見直すときの注意点を整理します。

システム保守費用の内訳とは

保守費用の妥当性を確かめる出発点は、見積もりを「一式」のまま受け取らず、中身を分けて見ることです。保守費用は、障害対応・問い合わせ対応・軽微な改修・監視・定期作業・ライセンス・人件費の7つに分けると整理しやすくなります。この7つは、毎月決まってかかる費用と、障害や依頼が起きたときにかかる費用の2つに分かれます。

障害対応と軽微な改修は、日本産業規格のJIS X 0161が分けている保守の種類に当てはまります。同規格は保守を、是正保守・適応保守・完全化保守・予防保守の4つに分けています。^*1 是正保守は、引き渡した後に見つかった問題を訂正するための修正です。適応保守は、使う環境が変わってもソフトウェアを使い続けられるようにするための修正、予防保守は、まだ表に出ていない障害を、運用中の障害になる前に見つけて直すための修正とされています。^*1

完全化保守は、同規格の注記で、利用者のための改良や性能の強化につながる修正と説明されています。^*1 保守費用の7つに当てはめると、障害対応の多くは是正保守に、軽微な改修の多くは適応保守か完全化保守に当たります。見積書の項目がどの種類の作業を指しているのかが分かると、保守事業者と認識を合わせやすくなります。

監視・アラート対応は、システムの状態を続けて確かめる作業です。IPA（情報処理推進機構）が公開している非機能要求グレード（性能や運用の要件の一覧）でも、「運用・保守性」という項目で扱われています。^*2 ライセンス費用は、外部のソフトウェアを使うことに伴ってかかる費用で、保守事業者の作業とは別に計上されることも珍しくありません。人件費は、いつでも対応できる体制を保つための費用なので、実際に作業した時間の分だけでは金額を説明できません。監視の仕組みそのものを委託して作るときの進め方は「Zabbixでインフラ監視基盤を外注構築」で扱っています。

見積書を読むときは、毎月決まってかかる費用が固定の金額で示されているか、障害や依頼のたびにかかる費用が対応の件数や工数（作業にかかる時間の量）に応じて増減する仕組みになっているかを分けて見ます。両方がまとめて「保守費用一式」と書かれていると、費用が増えたり減ったりした理由を追えません。契約を更新するときに、内訳を分けて出し直してもらうよう頼むのも一つのやり方です。

費用はどう見積もられるのか

保守費用の見積もりには、主に3つの考え方があります。1つ目は、開発費に対する年間の保守費用の割合で見る考え方です。開発費の一定の割合を年間の保守費用の目安にする考え方は実務で語られることがありますが、適正な水準は、システムの規模、稼働してからの年数、ほかのシステムとの連携の複雑さによって大きく変わります。割合だけでは「高い」「安い」は判断できません。

2つ目は、工数で見る考え方です。月あたりに見込む対応時間に技術者の単価を掛けて金額を出す方法で、どの作業に何時間かかるかと金額の関係が分かりやすくなります。IPAは、ソフトウェア開発の工数・工期（完成までの期間）・生産性などの数値データを集めて分析し、データ集として公開しています。^*3 保守契約でも、見込みの工数と実際にかかった工数を比べられる形にしておくと、費用の説明がしやすくなります。

3つ目は、体制で見る考え方です。担当者が専任か兼任か、何人で対応するか、対応するのは平日の日中だけか24時間かによって、費用は大きく変わります。同じ「保守費用一式」でも、その裏にある体制が違えば、ふさわしい金額も違います。3つの考え方はどれも単独では足りないので、組み合わせて見ます。

組み合わせ方の例を挙げます。見込みの対応時間を月20時間として契約したのに、ここ数か月の実績が35時間前後で続いているなら、体制や契約時間そのものを見直すきっかけになります。反対に、実績が見込みを大きく下回り続けているなら、契約時間が多すぎるのかもしれません。どちらも、開発費に対する割合という1つの数値だけでは見えてこないことです。

なぜ根拠を確かめるのか

保守費用が「一式」のまま出され続けると、何にいくら払っているのかが分からなくなります。発注する側が内訳を知らないまま契約の更新を重ねると、費用がふさわしい水準かどうかを確かめる機会そのものがなくなります。その結果、必要以上の費用を払い続けるおそれと、必要より少ない人数の体制で契約してしまうおそれの両方が生まれます。

費用が多すぎる例は、必要以上の人数を常に配置していることや、システムの重要さに見合わない長さの対応時間帯を設定していることです。少なすぎる例は、見積もりの安さを優先した結果、障害が起きたときに対応する人が足りなくなり、復旧までの時間が延びてしまう場合です。どちらも、費用の内訳と体制の根拠を確かめない限り気づきにくい問題です。

発注担当者にとって大切なのは、金額の大小そのものより、その金額がどんな作業と体制への対価なのかを説明できる状態にしておくことです。根拠を確かめる作業は、保守事業者を疑うためのものではありません。双方が納得できる契約を続けるための手続きと考えると、社内への説明や予算の相談も進めやすくなります。

見積書で確かめたい点

内訳を分けたら、次は妥当性を判断するための確認です。見積書や契約書を読むときは、次の4つを確かめます。表のSLAは、稼働率や復旧までの時間といったサービスの品質を、発注側と保守事業者のあいだで取り決めたものです。

デジタル庁が公開している「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」には、保守計画書や保守実施要領のひな形が載っており、保守の作業内容や体制を文書にまとめる考え方が示されています。^*4 民間の保守契約でも、体制と作業内容を文書で確かめられるようにしておくと、妥当性を判断しやすくなります。

4つの点は、1つずつではなく組み合わせて見ます。たとえば、SLAの復旧目標時間が短いのに、対応体制が兼任の数名だけなら、費用と体制が見合っていないのかもしれません。反対に、対応する時間帯が限られているのに費用が高いなら、体制と実績工数を開示してもらって確かめる価値があります。4つの点のあいだに食い違いがないかを見ることが、実務では大切です。

相場はどこまで参考になるのか

相場を知っておくことは、見積もりを検討するうえで役立ちます。JISA（一般社団法人情報サービス産業協会）は会員企業を対象に、人件費・外注費・営業利益などの経営指標を含む基本統計調査を毎年行っています。^*5

ただし、業界の統計や世の中に出ている相場の情報は、規模も業種も対応する作業も違う多くのシステムをまとめた数値であることが多く、自社のシステムにそのまま当てはめるのは難しいものです。相場より高いからといってすぐに不当とは言えず、相場より低いからといって、必要な体制がそろっているとも言えません。

相場は「大きく外れていないか」を確かめる参考の値として使い、最後の判断は自社システムの内訳、SLA、体制と照らし合わせて行います。相場だけを根拠に値下げを求めると、対応する作業や体制の違いを見落としたまま話し合いが進んでしまいます。

費用を見直すときの注意点

内訳と妥当性を確かめた結果、費用を見直す場面もあります。このとき気をつけたいのは、費用を下げると対応の品質も下がりやすいことです。監視の回数を減らしたり、対応する時間帯を狭めたりすれば費用は下がりますが、同時に障害に気づくまでの時間や、復旧までの時間が延びるおそれがあります。

見直しそのものを避ける必要はありません。ただ、どの項目を減らすとどの品質に影響するかを、先に整理しておくのが望ましいでしょう。契約の棚卸しやSLAの見直しといった具体的な削減の方法は論点が多いので、本記事では深く扱いません。削るかどうかを決める前に、まず根拠を確かめるという順序を守ることが、後悔しない見直しにつながります。

見直す場合も、すべての項目を一度に変えるのではなく、影響の小さい項目から少しずつ変え、対応の品質への影響を確かめながら進めるのが現実的です。

まとめ：システム保守費用で確かめておきたい3つの点

システム保守費用の妥当性を見極めるうえで、確かめておきたい点は3つに整理できます。第一に、見積もりを障害対応・問い合わせ対応・軽微な改修・監視・定期作業・ライセンス・人件費の7つに分けて、どこに費用がかかっているかを見ること。第二に、開発費に対する割合・工数・体制という3つの考え方を組み合わせて、金額の根拠を確かめること。第三に、SLA、対応する時間帯、対応体制、実績工数の開示を確かめ、相場は大きく外れていないかを見る目安にとどめることです。この3点を踏まえておけば、「毎年同じように払っているのに、何に使われているのか誰も説明できない」という事態を避けやすくなります。見積もりの読み方や保守の体制に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：JIS X 0161:2008「ソフトウェア技術－ソフトウェアライフサイクルプロセス－保守」（https://kikakurui.com/x0/X0161-2008-01.html）。出典：JIS X 0161:2008 3.2 是正保守、3.4 適応保守、3.7 完全化保守（注記）、3.8 予防保守の定義を参照（2026年9月確認）
2. *2　参考：IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」（IPA アーカイブ）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）。出典：IPA「非機能要求グレード」紹介ページ。大項目「運用・保守性」を参照（2026年9月確認）
3. *3　参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：IPA「ソフトウェア開発分析データ集2022」。工数・工期・生産性等の定量データの収集・分析を参照（2026年9月確認）
4. *4　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/ae9a37b7/20250619_resources_standard_guidelines_guideline_05.pdf）。出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」。保守計画書・保守実施要領のひな形を参照（2026年9月確認）
5. *5　参考：JISA（一般社団法人情報サービス産業協会）「情報サービス産業基本統計調査 統計データ」（https://www.jisa.or.jp/it_info/statistics/tabid/769/Default.aspx）。出典：JISA「情報サービス産業基本統計調査」。会員企業を対象とした年次の調査で、人件費・外注費・営業利益などの経営指標を含むことを参照（2026年9月確認）

Tweet