業務システムの保守、月額固定と実働ベースはどっちが得か｜中小企業のための選び分け

今月、ベンダーに依頼した作業はゼロだった。先月は問い合わせを1件しただけだった。その割に、毎月の金額は変わらない。「これは本当に妥当な払い方なのか」という違和感は、中小企業で業務システムの保守を任されている方からよく伺います。

月額固定か、実働ベース（従量課金）か。この二者択一は、自社の業務システムへの依頼量と、求めるSLAの水準で決まります。依頼量が安定していて待機の必要性が高い基幹系は、月額固定が向きます。一方、稼働量に波があって過剰なSLAになっている中小企業の業務システムは、実働ベースが向きます。本記事は、その選び分けの判断材料と、月額固定が損になりやすい3つのサイン、切り替えるときの現実的な手順を、開発と保守の両方を手がける立場から整理します。

なぜ「月額固定の中身が見えない」状態が起きるのか

業務システムの保守契約は、ほぼ月額固定が業界標準です。請求書には「システム保守料月額○○円」とだけ書かれ、内訳は出てこない。これはベンダーが意図的に隠しているというより、構造的にそうなりやすい事情があります。

ひとつは、保守の値付けが「人月」で組まれてきた歴史です。エンジニアの稼働時間を月単位で押さえ、その対価として固定額を請求する形が長く続いてきました。実際に作業した時間ではなく、対応できる体制を確保している時間に対して支払う構造です。この「対応できる体制」の中には、障害時に即応するための待機時間（オンコール費）が含まれます。月によって依頼がゼロでも、待機している以上は費用が発生する、という考え方です。

もうひとつは、受発注の慣習です。中小企業の側からすると、毎月の固定費は予算が読みやすく、決裁も通りやすい。「使わない月は0円」の契約より、「毎月一定額」のほうが社内説明に馴染みます。ベンダー側にとっても、月次の売上が安定するメリットがあります。両者の都合が一致するため、月額固定が業界の既定値になりました。

この記事は、料金モデルそのものの選び分けに焦点を絞ります。保守費の内訳・業界の相場感・契約書のチェックポイントは、保守費が妥当か分からない業務システム――内訳・相場・打ち手の順で見直すで詳しく扱っています。また、月次の保守費の話と、一時費用としての全面リプレース見積もりの妥当性は、判断軸が異なります。後者は業務システムのリプレース見積もりが高すぎる時の妥当性を見極める3つの基準に整理しているので、必要に応じて読み分けてください。

月額固定の保守 — メリットとデメリット、向くケース

月額固定の保守とは、毎月一定額を支払うことで、契約範囲内の作業・問い合わせ対応・待機を継続的に受けられる契約形態です。定額制とも呼ばれます。

メリットは3つあります。まず、予算が読めること。年間の保守費が事前に確定するので、稟議も決算予測もブレません。窓口が安定する点も大きく、同じ担当者が継続的に張り付くため、システムの履歴を一から説明し直す手間が減ります。さらに、優先対応が前提に組まれているため、障害が起きたときは待機中のエンジニアがそのまま対応に入り、一次応答が早くなります。

デメリットも3つあります。いちばん分かりやすいのは、依頼がほとんどない月でも同じ金額を払い続けることになる点です。先月チケットが1件もなくても、請求は変わりません。内訳がブラックボックスになりやすい点も見逃せません。月次レポートが「問題なく稼働しました」の一行で終わるケースは少なくなく、何にいくら払っているのかが分からないと、契約見直しの議論に踏み込めません。そしてもうひとつが、価格改定への対抗手段の乏しさです。値上げ通告を受けたとき、内訳の見えない固定費は、根拠を確かめにくいまま飲むことになりがちです。

月額固定が向くのは、次のようなケースです。

大規模・基幹系で常時の待機が必要な企業。受注処理や会計が止まると業務全体が止まるシステムは、待機費を月額に組み込んででも即応体制を維持する価値があります。
SLAが厳しい契約。夜間障害の一次応答30分以内、稼働率99.9%以上といった水準を求めるなら、待機の人件費を月額で確保するのが現実的です。
予算管理を最優先する企業。年間の保守費を確定させたい、IT統制上の理由で固定費が望ましい、といった内部事情がある場合は、月額固定の安心感が利きます。
依頼量が月によってあまり変わらないシステム。常に月20〜30時間の改修・問い合わせ対応が安定して発生する場合、結果的に月額固定のほうが単価が安くなることもあります。

月額固定が一律で悪いわけではありません。「その月額が稼働量とSLAの水準に見合っている」と納得して払えているかが、見直しの分かれ目です。

実働ベース（従量課金）の保守 — メリットとデメリット、向くケース

実働ベースの保守とは、エンジニアが実際に作業した時間に対してだけ請求する契約形態です。タイムチャージ、従量課金とも呼ばれます。時間単価（たとえば1時間あたり○円）または人日単価を決めておき、月次で実働時間を集計して請求する形が一般的です。

こちらのメリットも3つです。最大のものは、依頼量に支払いが連動すること。使わない月の出費がなく、繁忙期だけ集中して使うこともできます。加えて、作業ログが請求の根拠になる性質上、何にどれだけの時間を使ったかが月次で明示されます。チケット単位で時間が記録されるため、内訳がブラックボックスになりません。契約の柔軟性も利点で、月次レポートを見ながら、依頼の優先順位や対応範囲を都度すり合わせていけます。

デメリットも3つ挙げておきます。依頼量に連動する裏返しで、年間コストは事前に読みにくくなります。障害や改修が重なった月は、想定より請求が跳ねます。待機体制の前提が薄い点にも注意が必要です。「実際に動いた時間だけ」を原則にすると、待機費を別枠で持たない契約が多くなり、夜間障害の即応を求めるなら、SLAをどう書くかを別途詰めることになります。最後に、関係が淡白になりやすい点。依頼があったときだけ動く間柄なので、何も依頼しない期間が続くと、やり取りの頻度そのものが落ちていきます。

実働ベースが向くのは、次のようなケースです。

業務システムへの稼働量に波がある中小企業。月によって依頼が0件から数十時間まで振れる場合、月額固定では待機費を払い続けることになります。
月額固定で過剰SLAになっている場合。夜間停止しても翌朝に直れば業務上は支障がないシステムに、24時間対応のSLAが付いていて、その分の待機費を払い続けているケースです。
保守内容を見える化したい場合。経営層・情シスの立場で、内訳の説明責任が必要なときは、作業ログがそのまま請求根拠になる仕組みのほうが説明しやすくなります。
ベンダーロックインを緩めたい場合。実働ベースは依頼のたびに関係を見直せるため、相性が合わなければ次の月から切り替えやすい構造になっています。

ここまでの月額固定と実働ベースの違いを、表に整理します。

観点	月額固定（定額制）	実働ベース（従量課金）
支払いの考え方	体制確保への対価。待機費を含む	実働時間への対価。使った分だけ
メリット	予算が読める／一次応答が早い／窓口が安定	使わない月は0円／作業ログで内訳が見える／柔軟
デメリット	依頼ゼロの月も同額／内訳が見えにくい／値上げを飲みやすい	年間コストが読みにくい／待機の前提が薄い／温度が下がりやすい
向くケース	大規模・基幹系／厳しいSLA／予算管理優先	稼働量に波がある中小企業／過剰SLAの見直し／見える化重視

「どちらが優れているか」ではなく、「自社の稼働量とSLAの水準にどちらが合うか」で選ぶのが現実的です。

月額固定が損になりやすい3つのサイン

ここからは、現在月額固定で契約している方に向けて、契約の実態と支払いがずれていないかを点検する3つのサインを紹介します。ひとつでも当てはまるなら、見直しの議論に入る価値があります。

サイン1: 月次の作業ログ・チケットが出てこない

毎月届く月次レポートが「問題なく稼働しました」の一行で終わっている、あるいはそもそもレポート自体が来ていない場合は、注意したいサインです。

何にいくら払っているかが見えない契約は、内訳を確認しようとした瞬間に交渉が止まります。本来は、チケット単位で「いつ・誰が・何時間・何の作業をしたか」が記録されているはずです。それが共有されていないということは、ベンダー側にも記録がないか、共有する文化がないかのどちらかです。前者なら待機費が支配的、後者なら見えない箇所にコストが乗っている可能性があります。

まずは「月次の作業ログを送ってほしい」と依頼してみてください。これに対する反応で、契約の温度がかなり見えます。

サイン2: 過去12か月で実依頼ゼロの月が複数ある

直近12か月分の依頼履歴を書き出してみてください。問い合わせも改修依頼もゼロだった月が複数あるなら、その月の支払いは実質的に待機費に充てられていたことになります。

待機費そのものは悪ではありません。「いつ止まってもおかしくないシステムを、止まったら30分以内に直してほしい」という前提があるなら、依頼ゼロの月の支払いは保険として意味があります。問題は、その前提が今も成り立っているかです。導入当初は厳しいSLAが必要だったシステムでも、業務の変化で「半日止まっても運用でカバーできる」状態になっていることは珍しくありません。

依頼ゼロの月が複数ある事実と、現在のSLA水準を並べて、「この水準の待機が、今も必要か」を経営側で問い直すフェーズです。

サイン3: SLAの水準が実際の業務影響と釣り合っていない

契約書のSLA条項を読み直してみてください。「一次応答30分以内」「24時間365日対応」「稼働率99.9%以上」といった水準が書かれている一方で、実際に夜間や休日に障害対応をした記録がほとんどない場合、過剰SLAの可能性があります。

過剰SLAは、待機費を月額の中に大きく組み込みます。業務時間内の対応で十分なシステムに、24時間対応のSLAが付いているなら、その分の人件費を払い続けていることになります。

「現状の業務影響に対して、必要十分なSLA水準はどこか」を、現場のオペレーションから逆算して書き直すと、月額のどこを削れるかが見えてきます。

月額固定から実働ベースへ切り替えるときの現実的な手順

サインに該当して「切り替えを検討したい」となったとき、いきなり今のベンダーに解約を伝えるのは得策ではありません。準備期間を3〜6か月とって、現契約の更新タイミングに合わせて動くのが現実的です。順に手順を整理します。

手順1: 解約予告期間と次回更新月を契約書から逆算する

最初にやることは、契約書を開いて「解約予告期間」「自動更新の条項」「次回更新月」を確認することです。多くの保守契約は、3〜6か月前までに書面で解約予告をしなければ自動更新される、と定められています。

ここで予告期間を見落とすと、もう1年間、月額固定の契約に縛られる事態になります。「次回更新月の6か月前」を逆算し、その時点までに切り替え先を決めて引き渡し条件を詰める、というスケジュールで動きます。

手順2: 直近12か月の依頼内容と所要工数を書き出す

切り替え先に実働ベースで見積もりを取るには、実態のデータが必要です。直近12か月分について、月ごとに「依頼件数」「依頼内容」「所要工数（時間または人日）」を書き出します。

メールの履歴やチケット管理ツールが残っていれば、そこから拾えます。記録がまったく残っていない場合は、現場の担当者に聞き取って復元します。完璧でなくて構いません。「月に何時間くらい、どんな種類の依頼が出ているか」の輪郭が掴めれば、見積もりの精度は十分上がります。

このデータは、切り替え後に実働ベースで運用するうえでも、月次の請求が想定範囲に収まっているかを判断する基準になります。

手順3: 切り替え先に求める引き渡し条件を整理する

引き渡しで握る項目を、先にこちらで整理しておきます。最低限、次の3点は押さえます。

ソースコードと設計書の所在: 現ベンダーから受け取れるもの、受け取れないものを切り分ける。受け取れないものは現バージョンから読み解く前提で見積もる。
インフラ・アカウントの引き渡し: サーバー、ドメイン、SSL、外部サービスの管理アカウントを、誰の名義で持っているかを確認する。
SLA水準の再定義: 過剰SLAになっているなら、ここで「業務時間内対応」「一次応答営業日翌日」など、実態に合った水準に書き直す。

引き渡し条件を整理したら、現ベンダー1社だけでなく、第三者保守の見積もりも取って比較するのが現実的です。料金モデル、SLAの水準、引き渡しへの姿勢を横に並べると、切り替え先を選ぶ判断軸がブレません。

この準備の進め方は、運用管理を立て直す視点でレガシーシステムの運用管理を立て直す3つの手順：属人化からの脱却にまとめています。属人化と並行して契約も整理するなら、合わせて読んでみてください。

そして、もうひとつ。切り替えを検討する段階で、すでに「今のベンダーと連絡が取りづらい」状態に入っている場合は、準備の優先順位が変わります。連絡が完全に途絶える前にやっておくべきことを業務システムを頼んだ会社と連絡が取りづらい。今のうちにやっておきたい3つの備えで整理しているので、当てはまる方はそちらを先に確認してください。

three dots. が実働ベースを選んでいる理由

最後に、弊社（three dots.）がなぜ実働ベースを基本に選んでいるかを、設計思想として書きます。

弊社が引き取る案件の多くは、中小企業の業務システムです。月によって依頼量に波があり、繁忙期に集中して改修依頼が出る一方、何か月も依頼がゼロの時期もある、というシステムが多いです。こうした稼働量の波に対して、月額固定で過剰な待機費を払い続けるより、実際に動いた時間だけを請求するほうが、双方にとってフェアだと考えています。

具体的には、次の3点を契約の前提にしています。

使わない月は0円。依頼がない月は請求が発生しません。待機費を月額に組み込む発想を取りません。
使うほど単価が下がる。依頼が多い月ほど、1時間あたりの単価が下がる設計です。「使うと高くつく」従量課金とは、逆の発想です。
初回は成果保証。最初の依頼で問題が直らなければ、その分の費用は全額返金します。値引きではなく、初回のリスクをこちらが持つという考え方です。

具体的な時間単価や月次の上限の置き方、対象業務の範囲、SLAの水準は案件ごとに変わるため、お見積もりと打ち合わせのなかで個別にお示ししています。

実際にお引き受けした事例をひとつ紹介します。サービス業（従業員50名以上）のお客様で、20年前に内製した基幹システムに技術的負債が積み重なり、「もう作り替えるしかない」と諦めかけていた状態でした。診断のうえで既知のクリティカルな不具合のみを優先して対応することで全面リプレースを回避し、想定の約2割の費用で運用を継続しています。「全部を作り直さない」という選び方と、実働ベースの料金が組み合わさった結果です。

念のため書き添えると、実働ベースが必ず正解、という意味ではありません。冒頭で書いたとおり、大規模・基幹系で厳しいSLAが必要な企業は、月額固定で待機体制を確保するほうが筋が通ります。弊社の実働ベースは、業務システムへの稼働量に波がある中小企業に向く料金モデルだと考えています。

まとめ

月額固定と実働ベース、どちらを選ぶかは、自社の業務システムの稼働量と、求めるSLAの水準で決まります。基幹系で常時の即応が要るなら月額固定、稼働量に波があって過剰SLAになっているなら実働ベース、という分け方です。

今、月額固定で払い続けている方は、次の3点を点検してみてください。月次の作業ログが届いているか。直近12か月で依頼ゼロの月がいくつあるか。SLA水準が実際の業務影響と釣り合っているか。ひとつでも引っかかるなら、契約の見直しの議論に入る価値があります。

切り替えを検討するなら、解約予告期間から逆算して3〜6か月の準備期間を取り、依頼履歴の棚卸しと引き渡し条件の整理から始めます。料金モデルの切り替えは、それ自体が目的ではなく、業務システムを長く健全に運用するための手段です。

システムレスキュー｜実働ベースで業務システムを引き取る

月額固定ではなく、実際に動いた分だけお支払いいただく実働ベース（従量課金）の保守サービスです。他社が引き受けない古いシステム、連絡が取りづらくなったベンダーから引き取る案件も含めて、まずは無料相談から現状を整理します。

/service/system-rescue/