「保守費は一式」のままでは、交渉の土俵にすら乗れない
MESのランコスト見直しの相談を受けて最初に確認するのは、現在の保守費の内訳明細です。そして多くの場合、明細は存在しません。「年間保守一式 ○○○万円」という1行が、導入時の見積からそのまま毎年引き継がれています。
一式契約の問題は、金額の高低以前に、何にいくら払っているか分からないため、何を交渉すればよいかも分からないことです。総額に対して「下げてほしい」と言えば、ベンダーは「ではサービスレベルを下げます」としか答えられず、交渉は平行線になります。まずやるべきは値下げ要求ではなく、内訳の開示要求です。次回更新の見積時に費目別の明細を依頼することは、契約上も商慣習上も正当な要求であり、これを断るベンダーとの関係はそれ自体が見直しの対象になります。
ランコストの構造は、ライセンス体系がCapex型（買い切り＋保守料）かOpex型（サブスクリプション）かで見え方が変わります。サブスク型では「保守費」が利用料に溶け込むため、分解はむしろ難しくなります。体系ごとの構造はMESのライセンス体系で扱っているため、本記事は費目の分解と交渉に集中します。
ランコストを6つの費目に分解する
| 費目 | 中身 | 費用の性質 |
|---|---|---|
| 1. 製品保守（ベンダーサポート） | パッチ・バージョンアップの提供、問い合わせ窓口 | ライセンス額に対する定率（目安15〜22%）が相場 |
| 2. アプリケーション保守 | カスタマイズ部分の障害対応・軽微改修 | 委託先の工数ベース。月額固定か都度か |
| 3. インフラ費 | サーバ・OS・DB・クラウド利用料・回線 | 構成に比例。クラウドは従量部分あり |
| 4. 運用作業費 | 監視、バックアップ、マスタ登録代行、ヘルプデスク | 作業範囲の定義次第で大きく変わる |
| 5. ライセンス追加・変動費 | 端末・ユーザー増減、オプション追加 | 業務の変化に連動 |
| 6. 改善・小規模開発の枠 | 画面改修、帳票追加などの年間予算枠 | 投資に近い性質。削ると不満として蓄積 |
分解して初めて見える典型的な発見が3つあります。第一に、使っていないものへの支払い。解約したはずのオプションモジュールの保守、撤去済み端末のライセンス、退職者のユーザーライセンスが数年分積もっていることは珍しくありません。第二に、重複。ベンダーの運用サービスと自社情シスの作業が重なっている領域（監視、バックアップ確認）です。第三に、空振りの枠。月額固定のアプリケーション保守で、実際の問い合わせ・改修実績が枠の数分の1しかない状態です。
逆に、分解すると足りていないことが見つかる場合もあります。よくあるのは、バージョンアップ作業がどの費目にも含まれておらず、実施のたびに大型の追加見積になっているケースです。年間コストが安く見えて、数年ごとのスパイクで回収されている構造は、単年の明細だけでは見えません。5年程度の実支払額を並べて初めて比較可能になります。
削れる費目、削ってはいけない費目
分解の次は仕分けです。すべての費目が削減候補ではありません。
削減の筋がよい費目は、5番（未使用ライセンスの整理）、3番（インフラの適正化──過剰スペックの見直し、クラウドのインスタンス最適化）、4番のうち自社化できる定型作業（マスタ登録、一次ヘルプデスク）です。特に4番の自社化は、コスト削減と同時にMES技術者を社内で育てるで述べた育成の実地教材になるため、一石二鳥の性質があります。2番の月額固定枠は、実績データ（過去2〜3年の問い合わせ・改修件数）を根拠に枠の縮小か都度精算への変更を交渉できます。
削ってはいけない費目は、1番の製品保守と、6番の改善枠です。製品保守を解約するとパッチ・セキュリティ修正・バージョンアップの権利を失い、数年後に再加入しようとすると遡及金を請求される契約が一般的です。実質的に老朽化MESの延命へ片道切符で入ることを意味し、削減額に対してリスクが釣り合いません。6番の改善枠をゼロにする削減も、現場の改善要望が数年分滞留し、システムへの不満と迂回運用（Excel回帰）として返ってくるため、見かけの削減効果より劣化コストが大きくなりがちです。
交渉の材料とタイミング──更新期限の3か月前では遅い
費目分解ができたら、交渉です。効く材料は次の4つです。
- 利用実績データ:問い合わせ件数、改修依頼件数、障害件数の推移。枠と実績の乖離は、最も反論されにくい交渉材料です
- 相場情報：製品保守の料率、クラウド費用、運用委託単価の水準。複数社と付き合いのあるコンサルタントや、同業他社との情報交換が源泉になります
- 代替手段の実在：インフラの他クラウドへの移行可能性、運用の内製化計画、サードパーティ保守の存在。実行可能な代替がある費目だけが、実質的な交渉力を持ちます。逆に代替が構造的にない費目（製品保守）は、金額よりもサービス内容（対応時間、担当者の継続性）の改善を求めるほうが実りがあります
- 中期の刷新計画：あと3年で刷新するのか10年使うのかで、双方にとっての合理的な契約は変わります。長期継続の意思を示して複数年契約で単価を下げる交渉は、ベンダー側にも予見性のメリットがあるため成立しやすい型です
タイミングは更新期限から逆算します。内訳開示の依頼→分解と分析→交渉→（不調時の）代替検討まで見込むと、更新の12か月前に着手が標準です。3か月前では、ベンダー側も「今期の見積は確定済み」となり、翌年送りになります。この時間軸は保守契約で確認すべき8項目で述べた更新プロセスと同じであり、契約条項の点検とコスト交渉は同じ場で行うのが効率的です。
交渉が数字だけの叩き合いになりそうなときは、ベンダー側のコスト構造を下げる提案に切り替える手もあります。問い合わせの一次切り分けを自社で行う、リモート接続環境を整備して現地訪問を減らす、定例会を隔月化する──ベンダーの工数が実際に減る変更は、値下げの原資になります。関係を消耗させずに総額を下げる交渉とは、実務ではこの形です。
よくある質問
ランコストの適正水準はどれくらいですか？
「初期投資額の何%」という一般論は、カスタマイズ量・運用委託範囲・インフラ形態で大きく振れるため、単独では判断材料になりません。実務的には、①製品保守料率がライセンス定価の15〜22%程度の範囲か、②アプリケーション保守の月額固定枠が過去実績と釣り合っているか、③5年総額でスパイク（バージョンアップ等）を含めて比較したか、の3点で自社の構造を点検するほうが有益です。なお、この料率レンジはサオスの導入支援経験にもとづく目安であり、公表された統計ではありません。
サードパーティ保守（ベンダー以外による保守）は選択肢になりますか？
アプリケーション保守（2番）と運用作業（4番）については、製品知識を持つSIerが複数いる製品なら現実的な選択肢で、競争原理を働かせる意味でも有効です。一方、製品保守（1番）の代替はできません。パッチとバージョンアップの提供元はベンダーだけだからです。また、切り替え時にはシステムの経緯情報の引き継ぎコストが必ず発生するため、ドキュメント整備の水準が低い状態での切り替えは、削減額を引き継ぎ費用と品質低下で相殺しがちです。
サブスクリプション型に移行すればランコストは下がりますか？
下がるとは限りません。サブスク型は初期投資が小さくなる代わりに、長期の累計では買い切り型を上回ることが多く、「ランコスト」としては恒常的に高く見えます。サブスク型の利点はコスト総額ではなく、バージョンアップが利用料に含まれることによるスパイクの平準化と、利用規模の増減への追随性です。比較するなら単年ではなく、バージョンアップ費を含めた5〜7年の総保有コストで並べてください。
