システム保守費用は、新しい機能を足していない年でも少しずつ上がっていきます。原因も、ベンダーからの値上げ要請、担当者の退職で進む属人化、古い基盤の延命と1つではありません。
この記事では、運用と保守の中身を分解し、日本とベトナムで費用の決まり方がどう違うかを公的統計で比べます。そのうえで、ベトナムのチームに移せる業務と日本に残す業務、引き継ぎの進め方、個人情報保護法の確認事項、見積もりの確認点を整理します。自社の保守費を点検するときの材料としてお読みください。
運用と保守は何をしているのか
見積書では「運用保守一式」とまとめられがちですが、運用と保守は別の仕事です。運用は、いまのシステムを止めずに動かし続ける仕事です。保守は、システムそのものに手を入れる仕事を指します。
運用の主な作業
- 監視：サーバーやアプリケーションの稼働状況、ログ、アラートの確認
- 障害対応：原因の切り分け、手順書に沿った復旧、関係者への連絡
- 問い合わせ対応：利用部門からの質問や依頼の受付と調査
- 定期作業：バックアップやバッチ処理の結果確認、アカウントの登録・削除、証明書の更新
保守の4つの種類
ソフトウェア保守は、JIS X 0161（ISO/IEC 14764）で4つに分類されています。定義はIPAの解説資料で確認できます（IPA「共通フレーム2013の概説」）。
| 種類 | 内容 | 例 |
|---|---|---|
| 是正保守 | 引き渡し後に見つかった問題を直す | 不具合の修正 |
| 予防保守 | 潜在的な障害が表に出る前に見つけて直す | データ量の増加への備え、セキュリティ対策 |
| 適応保守 | 環境が変わっても使い続けられるようにする | OSやミドルウェアの更新、法改正への対応 |
| 完全化保守 | 性能や保守性を高める | 処理速度の改善、プログラムや文書の整理 |
では、保守の現場は何に時間を使っているのでしょうか。JUASの「ソフトウェアメトリックス調査2020」は、保守作業の内訳を次のように報告しています（2018〜2020年の累積、68件の平均値）。
| 保守作業の理由 | 割合 |
|---|---|
| 利用者からの問い合わせ対応（ヘルプデスク） | 24.5% |
| 改良保守（使い勝手の向上、担当者の要望への対応） | 20.5% |
| 適応保守 | 12.5% |
| 是正保守（バグの修正） | 10.4% |
| 基盤整備（ハードウェア・ミドルウェア変更への対応） | 9.3% |
| 予防保守 | 6.5% |
| 完全化保守 | 5.6% |
| その他 | 10.7% |
出典：JUAS「ソフトウェアメトリックス調査2020 システム開発・保守調査」
バグの修正は全体の1割ほどです。問い合わせ対応と要望への対応を合わせると45%になります。保守費の多くは、日々の質問や細かな要望への対応で使われています。この点は、後半で扱う業務の切り分けに関わります。
システム保守費用はIT予算のどれくらいを占めるか
JUASの「企業IT動向調査報告書2026」（2025年度調査、回答957社）によると、IT予算の75.9%は「ランザビジネス予算」でした。現行ビジネスの維持・運営にあてる予算です。新しい施策にあてる「バリューアップ予算」は24.1%にとどまります（JUAS「企業IT動向調査報告書2026」）。
各社は、3年後にバリューアップ予算を32.7%まで高めたいと答えています。ところが、同じ水準の目標は3年前の調査でも掲げられていました。実際の比率は、21年度から24%前後のまま動いていません。
IT予算が増える理由として、2025年度計画で最も多かったのは「既存システム・基盤の刷新・更新・増強」（66.3%）でした。2番目は「円安・人件費高騰・ベンダー提供価格の値上げなどによる影響」（46.6%）です。保守費の上昇は、多くの企業に共通しています。
経済産業省の「DXレポート」（2018年）は、既存システムの問題を解決できない場合について、次のように警告しました。
この課題を克服できない場合、DXが実現できないのみでなく、2025年以降、最大12兆円／年（現在の約3倍）の経済損失が生じる可能性（2025年の崖）。
同レポートは、システムの維持管理費が高額になり、IT予算の9割以上を占めるおそれがあるとも指摘しています。レガシーシステムの保守・運用が属人的になり、継承が難しいと考える事業者が6割以上いるという調査結果も載っています（経済産業省「DXレポート（サマリー）」）。
「保守費は開発費の15%」は本当か
保守費の目安として「年間で開発費の15%前後」という数字をよく見かけます。ただ、根拠となる調査が示されていることはほとんどありません。実績にもとづくデータとしては、先ほどのソフトウェアメトリックス調査2020があります。
| 開発の形 | 稼働後に毎年かかる費用（5年間の年平均） | 5年間の総費用 |
|---|---|---|
| 自社開発（スクラッチ） | 初期開発費に対し、保守7.8%＋追加開発12.0% | 初期開発費の約2倍 |
| パッケージ本体 | 本体・導入費用に対し、追加導入と保守で10.9% | 本体・導入費用の約1.54倍 |
| パッケージのカスタマイズ部分 | カスタマイズ・導入費用に対し、追加導入と保守で31.4% | カスタマイズ・導入費用の約2.57倍 |
自社開発では、狭い意味の保守が年7.8%、稼働後の追加開発が年12.0%で、合わせると約20%です。「15%」という目安は、追加開発をどこまで含めるかで意味が変わります。自社の保守費を点検するときは、契約に何が含まれているかを先に確かめてください。
なお、この調査の対象はJUAS会員企業を中心としたシステムで、集計に使われた自社開発の初期開発費は約7.4億円です。小規模なシステムにそのまま当てはまるとは限りません。
保守費が下がりにくい3つの理由
1つ目はベンダーロックインです。最新の設計書やソースコード、本番環境の権限が開発元にしかないと、他社に相談する材料がそろいません。その結果、値上げを受け入れるほかなくなります。
2つ目は属人化です。「あの人に聞かないとわからない」作業は、手順書がないために、単価の高いベテランの時間を使い続けます。担当者が退職すると、次の人は調査から始めることになります。
3つ目はレガシー化です。サポートが切れた言語や基盤は、扱える技術者が年々減り、人件費が上がります。根本から直すにはモダナイゼーションが必要です。考え方はモダナイゼーションとは？マイグレーションとの違いで解説しています。
3つに共通するのは、作業の中身が見えていないことです。中身が見えれば、すべてを同じ単価の人に任せる必要はなくなります。
日本とベトナムで費用の決まり方はどう違うか
運用・保守の費用は、クラウドやライセンスの利用料を除けば、ほぼ人件費です。そこで、公的な賃金データを並べます。
| 指標 | 日本 | ベトナム（ハノイ） |
|---|---|---|
| エンジニア（中堅技術者）の月額基本給 | 横浜2,878米ドル、東京2,636米ドル | 520米ドル |
| 賞与 | 月給の4.50か月分（横浜） | 基本給の1.6か月分 |
| 社会保険の雇用者負担率 | 13.222〜25.272%（横浜） | 21.5% |
| 情報通信業の賃金（月額の所定内給与） | 406.0千円（全産業の平均は340.6千円） | 該当する統計なし |
出典：上の3行はJETRO「2024年度 アジア大洋州・日本投資関連コスト比較調査」（2025年3月）、4行目は厚生労働省「令和7年賃金構造基本統計調査 結果の概況」。いずれも市場データで、MOHAの料金を示すものではありません。
JETROの調査では、中堅技術者の月額基本給は横浜がハノイの約5.5倍です。ただし、この倍率がそのまま保守費の差になるわけではありません。理由は3つあります。
1つ目は、統計の定義がそろっていないことです。日本側は横浜の「技術係長」（平均45.8歳）、ベトナム側は日系企業で働く実務経験5年程度の技術者の値です。どちらも製造業の数字で、ITエンジニアの賃金そのものではありません。
2つ目は、ベトナム側に、日本語で対応するPMやブリッジSEの費用が加わることです。
3つ目は、作業場所で変わらない費用があることです。クラウド利用料、ライセンス料、製品の保守サポート料がこれにあたります。
ベトナムに移して下がるのは、保守費のうち人の作業時間に比例する部分です。見積もりを読むときは、費用を次のように分けて考えてください。
| 費用の項目 | 主な中身 | ベトナムに移したときの変化 |
|---|---|---|
| 定常の運用・保守 | 監視、問い合わせの調査、軽微な改修、テスト | 賃金水準の差が反映されやすい |
| 管理と橋渡し | PM、ブリッジSE、定例会議、報告 | 新たに加わる |
| 引き継ぎ | ドキュメント化、並行運用 | 初年度に一時的に増える |
| 基盤と製品 | クラウド利用料、ライセンス料、製品の保守料 | 変わらない |
| 日本側に残る業務 | 業務判断、承認、利用部門との調整 | 変わらない |
ベトナムに移せる業務、日本に残す業務
手順と判断基準を文書にできる作業ほど、移しやすくなります。
| 業務 | 担当の目安 | 条件や理由 |
|---|---|---|
| 定型運用（バッチ結果の確認、アカウントの棚卸し、定期レポート） | ベトナム | 手順書があれば、場所を問わず同じ品質で回せる |
| 監視の一次対応（アラートの切り分け、手順書に沿った復旧） | ベトナム | エスカレーションの基準を先に決めておく |
| 軽微な改修、是正保守 | ベトナム | 影響範囲が小さく、レビューで品質を確認できる |
| テスト（回帰テスト、基盤更新後の動作確認） | ベトナム | テストケースを資産として残せる |
| 問い合わせ対応 | 分担 | 利用部門との窓口は日本側、原因の調査はベトナム側 |
| 業務判断（優先順位、リリースの可否） | 日本 | 事業への影響を判断できるのは発注側だけ |
| 重大障害の指揮（復旧方針、経営層や取引先への報告） | 日本 | 説明責任を外部に移すことはできない |
| 個人情報を含む本番データを直接扱う作業 | 日本 | 後述する個人情報保護法第28条の確認が必要 |
MOHAのオフショア開発センターでは、Web・モバイルアプリの開発に加えて、テスト、QA、メンテナンスをお引き受けしています。保守・運用のように続く業務には、専属チームモデルが合います。この場合も、指揮命令はMOHA側のPM／ブリッジSEを通じて行います。お客様に決めていただくのは、依頼の内容と優先順位、リリースの可否です。
監視の一次対応には、人手だけに頼らない方法もあります。MOHAは、サーバーやアプリケーションのログをAIで解析する「AMI Bot」を自社で開発しました。エラーの分類と密度をダッシュボードに表示し、原因の診断と対処案を添えてTelegramやGmailに通知します。現在はMOHAの社内システムで運用し、人による確認を組み合わせて精度を高めている段階です。
ベトナムへの移管が向かないケース
次のような場合は、移管の効果が出にくくなります。
- 夜間・休日も即時の対応が必要で、日本側でも待機の体制を組めない場合
- ほぼすべての作業で、本番の個人データを直接見る必要がある場合
- 月々の作業量がごく少なく、PMやブリッジSEの管理分が相対的に重くなる場合
- 現行ベンダーから資料も引き継ぎの協力も得られず、ソースコードも手元にない場合
日本とベトナムの時差は2時間で、日本の日中の業務時間は大部分が重なります。一方、日本の深夜はベトナムでも深夜です。夜間の対応が必要なら、その範囲と連絡の方法を最初に決めておきます。
引き継ぎの進め方
移管で最も手間がかかるのは、最初の引き継ぎです。急ぐと、切り替えた直後に問い合わせへの回答が遅れます。次の4段階で進めます。
| 段階 | 行うこと |
|---|---|
| 1. 棚卸し | 過去の問い合わせ、障害、改修の記録を集め、作業を種類ごとに数える |
| 2. ドキュメント化 | システム構成図、運用手順書、障害時の連絡フロー、リリース手順を文書にする。担当者の頭の中にある判断基準も書き出す |
| 3. 並行運用 | 現行の担当者と新しいチームが同じ依頼を並行して処理し、回答の内容と所要時間を突き合わせる |
| 4. 切り替えと拡大 | 定型運用から移し、問題がなければ軽微な改修、テストへと範囲を広げる |
並行運用の間は、費用が二重にかかります。この期間が見積もりに含まれているかどうかで、初年度の総額は変わります。
引き継ぎを始める前に、現行の契約も確認してください。確認するのは、ソースコードと設計書の権利、本番環境のアカウント、契約終了時の引き継ぎ協力の条項です。契約書の読み方はオフショア開発サービス契約の基本構成と注意点にまとめています。
セキュリティと個人情報保護法の確認事項
保守・運用では、本番のデータに触れる場面があります。顧客や従業員の情報が含まれるなら、個人情報保護法第28条（外国にある第三者への提供）の確認が必要です。
個人情報保護委員会のガイドライン（外国にある第三者への提供編）によると、外国の第三者へ個人データを提供するには、原則としてあらかじめ本人の同意が要ります。例外は次の3つです。
- 提供先が、日本と同等の水準の制度を持つと認められた国（EUと英国）にある
- 提供先が、日本の事業者と同等の措置を続けるための体制（基準適合体制）を整えている
- 法令に基づく場合など、第27条第1項各号にあたる
ベトナムは1つ目にあたりません。業務委託であっても、相手が外国の事業者なら同じ規律がかかります。本人の同意を取り直すのが難しい既存システムでは、2つ目の基準適合体制を検討することになります。ガイドラインは、外国の事業者に個人データの取扱いを委託する場合の方法として「提供元及び提供先間の契約、確認書、覚書等」を挙げています。この方法を取ると、提供元には、相手の措置が続いているかを確認し続ける義務が生じます。
契約の窓口が日本法人でも、ベトナムの開発拠点は別の法人です。ガイドラインは、外資系企業の日本法人が外国の親会社に個人データを提供する例を挙げ、親会社は「外国にある第三者」にあたるとしています。日本法人との契約だから対象外、とはなりません。
委員会は、ベトナムの制度に関する調査結果も公開しています。ただし内容は2022年2月15日時点のもので、その後の改正が反映されていない可能性があると委員会自身が注記しています（個人情報保護委員会「外国制度（ベトナム社会主義共和国）」）。
法的な手当てと並んで考えたいのが、ベトナム側で個人データを扱わずに済む設計です。
- 調査や改修は、個人情報をマスキングした検証環境で行う
- 本番環境へのアクセス権は日本側に残し、本番作業は日本側の承認を経て実施する
- ログや問い合わせ票に個人情報を書かない運用にする
MOHAのオフショア開発センターが公開している対策は、データの暗号化、アクセス制御、VPNの利用、セキュリティ教育の4点です。自社の業務が第28条の対象になるかどうかは、法務部門や専門家にもご確認ください。
システム保守費用の見積もりで確認する点
保守・運用の見積もりは、総額よりも前提を読むことが大切です。次の点は、商談の際にMOHAへそのままご質問ください。
- 対象範囲：運用と保守のどの作業が含まれ、どこからが追加開発として別の扱いになるか
- 作業量の前提：月あたりの問い合わせ件数や改修件数を、どの実績から見積もったか
- 体制：PM、ブリッジSE、エンジニア、テスターの役割と、専任・兼任の別
- 対応時間帯：日本時間の何時から何時までか。時間外の障害は誰に連絡し、誰が動くか
- 引き継ぎ：ドキュメント化と並行運用の期間、その間の費用の扱い
- 個人データ：ベトナム側が触れる範囲と、契約上の取り決め
- 見直し：作業量が増減したときに、体制をどう変えられるか
現行の保守費と比べるときは、範囲をそろえてください。現行の契約にクラウド利用料や製品の保守料が含まれているなら、それを除いた人の作業分どうしで比べます。
よくある質問
システム保守費用は開発費の何%が適正ですか？
一律の適正値はありません。JUASの調査では、自社開発システムの保守費は年平均で初期開発費の7.8%、追加開発を含めると約20%でした。この比率との高低よりも、費用が何の作業に使われているかを確かめるほうが見直しにつながります。
現行ベンダーとの契約を残したまま、一部だけ移せますか？
範囲を切り分ければ可能です。たとえば、基盤や製品の保守は現行ベンダーに残し、問い合わせの調査、軽微な改修、テストを別のチームに移します。責任の境界があいまいにならないよう、障害時にどちらが一次対応するかを先に決めておきます。
設計書がほとんど残っていません。それでも引き継げますか？
引き継ぎの最初の工程で、ソースコードと稼働中の環境から現状を調べ、文書を起こします。その分、引き継ぎの期間と費用は増えます。どこまで調査が必要かは、現状を伺ったうえでご提案します。
保守費の見直しを検討中の方へ
保守費は上がり続けているのに、何から手をつければよいかわからない。その段階でのご相談も歓迎します。現行の契約範囲と月々の作業内容を示す資料があれば、移せる部分と残す部分を一緒に整理できます。お問い合わせ・ご相談からご連絡ください。ご契約の窓口は、横浜・みなとみらいの日本法人、合同会社MOHAジャパンです。
