LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

システム保守費用の内訳を分解する——7つの構成要素

システム保守費用の妥当性を検討する出発点は、見積もりを「一式」のまま受け取らず、構成要素に分解して確認することです。保守費用は大きく、恒常的に発生する費用と、事象が起きたときに発生する費用の二系統に整理できます。

この整理は、日本産業規格であるJIS X 0161が示す保守の分類とも重なります。同規格は保守を「是正保守」「適応保守」「完全化保守」「予防保守」の型に分けており、是正保守は引渡し後に見つかった問題を訂正するための修正、適応保守は運用環境の変化に対応するための修正と定義しています^*2。完全化保守は性能や使いやすさを改良するための修正、予防保守は障害が表面化する前に手を打つ修正です^*2。障害対応の多くは是正保守に、軽微な改修の多くは完全化保守や適応保守に当てはまると考えられます。

監視やアラート対応は、システムの状態を継続的に把握する活動であり、IPAが公開する非機能要求グレードでも「運用・保守性」という観点で整理される領域に位置づけられます^*1。ライセンス費用は外部ソフトウェアの利用に付随して発生し、保守事業者の作業とは別枠で計上されることも珍しくありません。人件費は、対応可能な体制を維持するためのコストであり、実際に手を動かした時間だけでは説明できない部分です。この7要素のどれがどの比重を占めているかを見積書から読み取れるかどうかが、根拠確認の第一歩になります。

見積書を確認する際は、定常的にかかる費用が固定金額として明示されているか、都度発生する費用が実際の対応件数や工数に応じて変動する仕組みになっているかを分けて見ることが役立ちます。両者が渾然一体のまま「保守費用一式」と表記されている場合、費用が増減した理由を追跡しづらくなります。契約更新のタイミングで、内訳を分けて再提示してもらうよう依頼することも一つの選択肢です。

費用の考え方——比率・工数・体制の3つの物差し

保守費用の妥当性を検討する際、実務では大きく3つの物差しが使われる傾向があります。第一は、開発費に対する年間保守費用の比率で捉える考え方です。開発費の一定割合を年間の保守費用の目安とする発想が実務で語られることはありますが、これはあくまで一般的な考え方の一つであり、対象システムの規模・稼働年数・外部連携の複雑さによって実際の適正水準は大きく変わります。比率だけを基準に「高い」「安い」と判断するのは早計です。

第二は、工数ベースで捉える考え方です。月あたりの想定対応時間に技術者の単価を掛けて算出する方式で、対応内容と時間の対応関係が明確になりやすいという特徴があります。IPAはソフトウェア開発分析データ集として、工数・工期・生産性等の定量データを収集・分析する取り組みを継続しており^*5、工数を定量的に扱う考え方自体は業界に根付いている点です。保守契約でも、想定工数と実績工数を突き合わせられる形にしておくと、費用の説明がしやすくなります。

第三は、体制ベースで捉える考え方です。専任か兼任か、何人が対応に当たるか、対応時間帯は平日日中限定か24時間対応かといった体制の作り方によって、費用は大きく変動します。同じ「保守費用一式」という表現でも、内側にある体制が異なれば妥当な金額も異なるという点です。3つの物差しはいずれも単独では万能ではなく、組み合わせて確認することで、初めて根拠のある議論が可能になります。

3つの物差しを組み合わせる場合の一例を挙げると、想定対応時間を月20時間として契約したものの、直近数か月の実績が35時間前後で推移しているという状況が続いていれば、体制や契約時間そのものを見直す材料になります。反対に実績が想定を大きく下回り続けているのであれば、契約時間の設定が過大である可能性も考えられます。いずれの場合も、比率という単一の数値だけでは見えてこない実態です。

なぜ「根拠」を確認する必要があるのか

保守費用が「一式」で提示され続けると、内訳がブラックボックス化しやすくなります。発注側が構成要素を把握しないまま契約更新を重ねると、費用が適正な水準にあるかどうかを検証する機会そのものを失ってしまう点に注意が必要です。これは過大な費用を払い続けるリスクと、過小な体制で契約してしまうリスクの両方につながります。

過大なリスクとしては、必要以上の常駐人員や、実際の重要度に見合わない対応時間帯の設定が挙げられます。一方の過小なリスクは、見積もりの安さを優先した結果、障害発生時の対応体制が薄くなり、復旧までの時間が伸びてしまうという形で表面化する点です。どちらのリスクも、費用の内訳と体制の根拠を確認しない限り気づきにくいという共通点があります。

発注担当者にとって重要なのは、金額の大小そのものではなく、その金額がどのような作業・体制に対する対価なのかを説明できる状態にしておくことです。根拠を確認する作業は、保守事業者を疑うための行為ではなく、双方が納得できる契約関係を維持するための手続きだと捉えると、社内での説明や予算折衝も進めやすくなります。

妥当性を見極める4つのチェックポイント

内訳を分解したうえで、次に確認したいのは妥当性を判断するための具体的な着眼点です。以下の4点は、見積書や契約書を精査する際の実務的な確認項目として整理できます。

デジタル庁が公開するデジタル・ガバメント推進標準ガイドラインの実践ガイドブックには、保守計画書や保守実施要領のひな形が示されており、対応内容や体制を文書として整理する考え方が反映されています^*3。民間の保守契約でも同様に、体制や作業内容を文書で確認できる状態にしておくことが、妥当性を判断する土台になります。

4つのチェックポイントは互いに独立しているわけではなく、組み合わせて見ることで初めて意味を持つという点です。たとえばSLAの復旧目標時間が短く設定されているのに対応体制が兼任の数名だけという場合、費用の見合いに無理があるかもしれません。逆に対応時間の範囲が限定的であるにもかかわらず費用が高い場合は、体制や実績工数の開示を求めて確認する価値があります。一つの項目だけを取り出して評価するのではなく、4項目を横断して整合性を見ることが実務上のポイントです。

相場観の掴み方と、相場だけで判断する危うさ

相場観を持つこと自体は、見積もりを検討するうえで役立ちます。JISA(一般社団法人情報サービス産業協会)は会員企業を対象に、人件費・外注費・営業利益などの経営指標を含む基本統計調査を年次で実施しており^*4、業界レベルでコストの実態を捉える調査の枠組みが存在すること自体は確認できます。

ただし、こうした業界統計や一般に流通する相場情報は、システムの規模や業種、対応範囲の前提が異なる複数の事例を集計したものであることが多く、自社のシステムにそのまま当てはめられるとは限りません。相場より高いからといって直ちに不当とは言えず、相場より低いからといって手厚い体制とは限らないというのが実情です。

相場情報は「大きく外れていないかを確認する参考値」として使い、最終的な判断は自社システムの内訳・SLA・体制と照らし合わせて行うという順序が、根拠に基づいた妥当性判断につながります。相場だけを根拠に交渉すると、対応範囲や体制の違いを見落としたまま議論が進んでしまう点には注意が必要です。

費用の最適化を検討する際の注意点

内訳と妥当性を確認した結果、費用の見直しを検討する場面もあります。その際に留意したいのは、コストの削減が対応品質とのトレードオフになりやすいという点です。監視の頻度を下げたり、対応時間帯を狭めたりすれば費用は下がりますが、同時に障害発見までの時間や復旧までの時間が延びる可能性があります。

削減の検討自体を避ける必要はありませんが、どの項目を削るとどの品質指標に影響するかを事前に整理しておくことが望ましいと言えます。契約の棚卸しやSLAの見直しといった具体的な削減手法は個別の論点が多いため、本稿では踏み込みませんが、削減判断の前提として「まず根拠を精査する」という順序を守ることが、後悔のない見直しにつながります。

見直しを進める場合も、対象範囲を一度にすべて変更するのではなく、影響が小さい項目から段階的に調整し、対応品質への影響を確認しながら進める進め方が現実的です。特に障害対応や監視のように事業影響が大きい領域は、費用の縮小を急がず、まず内訳と根拠を確認したうえで、必要な水準を見極める姿勢が求められます。

まとめ：保守費用の妥当性を見極める3つの視点

本稿ではシステム保守費用の根拠と妥当性を、発注側が精査する視点から整理しました。要点は3つに集約できます。第一に、保守費用は障害対応・問い合わせ対応・軽微改修・監視・定期作業・ライセンス・人件費という7要素に分解すると、内訳の妥当性を検討しやすくなります^*2。第二に、比率・工数・体制という3つの物差しはいずれも単独では判断材料になりきらず、組み合わせて確認する必要があります^*5。第三に、SLA・対応時間・体制・実績工数の開示状況を確認し、相場情報は参考値として位置づけることが、根拠に基づいた妥当性判断の実務的な手順になります^*3*4。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」（IPA アーカイブ）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）
2. *2　出典：JIS X 0161:2008「ソフトウェア技術－ソフトウェアライフサイクルプロセス－保守」（https://kikakurui.com/x0/X0161-2008-01.html）
3. *3　出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（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）
4. *4　出典：JISA（一般社団法人情報サービス産業協会）「情報サービス産業基本統計調査 統計データ」（https://www.jisa.or.jp/it_info/statistics/tabid/769/Default.aspx）
5. *5　出典：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）

Tweet