毎年決まった時期に、保守料の支払い稟議が回ってくる。金額は前年とほぼ同じか、少し上がっている。決裁のどこかで「これは何に使っているのか」と質問が出て、情シスは「サポートを受けるための費用です」と答え、経理は「そういうものか」と押印する。稼働から五年も経つと、実際に問い合わせた件数は年に数件しかない、ということも珍しくない。保守料が無駄になるのは金額が高いからではなく、更新を取り込む工程が社内に無いからだ。 保守契約で買っているのは、障害時の窓口だけではない。標準機能に加わった更新を自社の環境に取り込む権利が含まれている。権利は毎年発生するが、取り込む工程を持っていない会社では、その権利が一度も行使されないまま流れていく。差が出るのは五年目からで、そのときには「取り込まなかった分」が一括で請求される。

POINT
保守料の価値は、更新の中身では決まらない。同じ契約を結んでいる二社でも、取り込む工程を持っている会社と持っていない会社では、数年後の状態がまったく違う。追従を止めている真因は、アドオンが存在すること自体ではなく、更新のたびに必要になる回帰テストの量が読めないことにある。テストが重いから当てない、当てないから差分が積み上がる、差分が積み上がるからテストがさらに重くなる。この循環に入ると自力では抜けられず、最後は移行プロジェクトとして外から手を入れることになる。抜け方は三つの工程で決まる。第一に、テストを毎回ゼロから作らず資産として持つ。第二に、適用の時期を年次のカレンダーに固定し、締めの繁忙期を外した窓を先に押さえる。第三に、更新内容を読む人・影響を判定する人・テストを回す人の役割を分けて名前で置く。この三つが揃うと、取り込みは判断ではなく作業になる。判断のままにしておくと、毎年「今年は見送る」という結論が出る。

保守料で買っているのは、更新そのものでなく「取り込む権利」だ

保守契約の中身は、契約の水準と締結の時期によって変わる。含まれるサービスの範囲も料率の算定基礎も、契約書を読まなければ確定しない。だから金額の妥当性を一般論で語ることに意味はない。ここで扱いたいのは、金額ではなく行使率のほうだ。

保守料の対価は三つに分けて考えるとよい。障害が起きたときの窓口と修正、法制度の変更に対応するための更新、そして機能の追加・改善である。一つ目は使うか使わないかが受け身で決まる。二つ目も、制度対応には期限があるので嫌でも取り込む。問題は三つ目だ。機能の追加は取り込まなくても今日の業務が止まらない。止まらないから後回しになり、後回しにする理由は毎年見つかる。

取り込まない状態が続くと、自社の環境と標準の距離が開いていく。開いた分は消えるのではなく、次に大きく手を入れるときにまとめて精算される。制度対応だけを最小限に当て続けた環境は、五年後には「標準に戻すためのプロジェクト」が必要な状態になっている。保守料を「保険料」だと説明すると社内は納得しやすいが、実態は逆だ。使わなければ使わないほど、後の支出が増える種類の費用である。

追従を止めているのは、アドオンではなく回帰テストの量だ

「アドオンが多いから更新に追従できない」という説明は、半分しか当たっていない。アドオンがあること自体は更新を止めない。止めるのは、更新を当てたときに何が壊れるか分からないという状態だ。

理由ははっきりしている。どのアドオンが標準のどの機能に依存しているかの一覧が無いこと。そして、壊れていないことを確認するためのテストが毎回ゼロから作られていること。この二つが揃うと、更新の適用は毎回フルスクラッチのテストプロジェクトになる。工数が読めないので予算が取れず、予算が取れないので見送られる。

裏を返せば、アドオンが同じ本数あっても、依存関係の一覧とテスト資産を持つ会社は追従できる。現場でアドオンの本数を減らす議論をするとき、本当に減らしたいのは本数でなく依存の見えなさだ。標準の拡張点を使って作られたアドオンと、標準の内部に手を入れて作られたアドオンでは、更新時の危険度がまったく違う。前者は影響範囲が限定され、後者は毎回全部を疑うことになる（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。

同じ契約・同じアドオン本数でも、追従できる会社とできない会社に分かれる。
追従できる工程を持っている会社
適用の予測可能性 ●●●
1回あたり工数 ●○○
数年後の移行費 ●○○
アドオンと標準機能の依存一覧を持ち、回帰テストをシナリオとして保管している。適用の窓は年次カレンダーに固定済み。更新の取り込みが判断でなく作業になっているため、毎年同じ工数で回る。
追従できない工程を持っていない会社
適用の予測可能性 ●○○
1回あたり工数 ●●●
数年後の移行費 ●●●
依存関係はベンダーの記憶の中にあり、テストは毎回ゼロから作る。工数が読めないので毎年「今年は見送る」という結論が出る。差分は消えず、数年後に移行プロジェクトとして一括で精算される。
分けているのはアドオンの本数でなく、依存関係の一覧とテスト資産の有無である。

追従できている会社が回している、年次の五工程

取り込みを作業に変えるには、工程として固定するしかない。年に一度、決まった時期に決まった手順で回す。

更新の取り込みは、年次で回すこの五工程に落とすと予測可能になる。
STEP 1
更新内容を読む
リリース情報から自社の使用モジュールに関わる項目だけを抜き出し、一覧にする。全部読む必要はなく、使っている機能に絞る
→
STEP 2
影響範囲を判定する
抜き出した項目ごとに、依存するアドオン・帳票・インターフェースを依存一覧から引き当てる。ここが一覧の無い会社で止まる
→
STEP 3
回帰テストを回す
保管してあるテストシナリオを実行する。新規に作るのは、今回の更新で新しく影響が出た範囲だけに絞る
→
STEP 4
適用の窓で当てる
年度計画に先に押さえた窓で本番適用する。締めの繁忙期と期末を外し、翌月の締めまでに余裕を持たせる
→
STEP 5
標準に戻せる箇所を棚卸しする
更新で標準機能に追いついた領域を洗い、対応するアドオンを廃止する。ここを回さないとアドオンは増える一方になる
土台土台＝適用の窓を年度計画に先に置くこと。空いた時期を探す運用にすると、探している間に一年が終わる。
五工程目まで回して初めて、保守料は「取り込む権利」から「実際に減った運用負荷」に変わる。

三工程目のテスト資産化が最も効く。回帰テストのシナリオは、導入時のUATで一度作られているはずのものだ。それを検収の証跡としてだけ保管し、次に使える形で残していない会社が多い。テストデータ、実行手順、期待結果の三点セットで保管しておけば、二回目以降の適用工数は大きく下がる（SAPの受入テスト（UAT）で経理は何を見るか｜シナリオの粒度とテストデータの決め方）。逆にここを残さなかったプロジェクトは、稼働の瞬間にテスト資産をゼロに戻したことになる。

五工程目は忘れられがちだが、年次サイクルの中で最も金額に効く。標準機能が追いついた領域のアドオンを廃止しないと、アドオンは増えるだけで減らず、そのまま毎年のテスト工数として跳ね返る。年に一度、廃止候補を出す場を持つ。

役割を三つに割らないと、この工程は誰の仕事にもならない

五工程を書いても回らない会社がある。原因は体制だ。「情シスがやる」では決まったことにならない。役割は三つに割る。

役割やること置き場所年間の関わり方
更新を読む人リリース情報から自社に関わる項目を抜き出す情シスまたは運用ベンダー年1回、数日
影響を判定する人抜き出した項目と依存一覧を突き合わせ、テスト範囲を決める情シスとアドオンを作ったベンダー年1回、一〜二週間
テストを回す人保管したシナリオを実行し、業務として問題ないか判定する経理・購買・販売の各部門年1回、部門ごとに数日

三つ目を業務部門に置くことが要点になる。更新が問題ないかどうかは、画面が開くかどうかでなく、月次が同じ手順で締まるかどうかで判定されるからだ。情シスだけで完結させたテストは、後から業務側に「挙動が変わっている」と指摘されて結局やり直しになる。

そして三つの役割のうち少なくとも一つは社内に置きたい。全部を外に出すと、取り込むかどうかの判断そのものが外部の見積に依存し、見積が高ければ見送るという結論に収束する（SAP移行後の経理運用を内製で回す｜ベンダー依存を減らす体制づくり）。

追従しなかった判断は、何年後にどの費目で跳ね返るか

見送るという判断は、その年の予算では正しく見える。工数が出ない、繁忙期に当たる、今の機能で困っていない。どれも本当だ。跳ね返るのは数年後である。

見送った内容数年後に現れる費目出てくる時期
機能更新の取り込み標準に戻すための移行プロジェクト費用四〜六年目に一括
標準に追いついたアドオンの廃止増え続けるアドオンの回帰テスト工数二年目以降、毎年増加
テストシナリオの資産化適用のたびに作り直すテスト設計工数適用のたび
依存関係一覧の整備影響調査という名目の調査費用改修のたび
業務部門のテスト参加稼働後の手戻りと、業務側の不信適用直後

一行目が最も重い。制度対応だけを最小限に当て続けた環境は、次の大きな移行で機能差分の吸収と業務の作り直しを同時にやることになる。毎年少しずつ回していた会社は、同じ移行を差分の少ない状態で迎えられる（SAP ERP 2027年問題とは｜いつ何を決めるべきか、移行の全体像）。

契約の更改が近い会社は、金額の交渉に入る前に次を確認しておきたい。

保守契約の更改前に、社内で確定させておくこと
  • ① 直近3年で、機能更新を本番に取り込んだ回数（制度対応を除く）
  • ② 標準機能に追いついたことで廃止できたアドオンの本数
  • ③ 現在稼働しているアドオンの本数と、そのうち依存関係が文書化されている本数
  • ④ 回帰テストのシナリオが、次回そのまま実行できる形で保管されているか
  • ⑤ 更新を読む人・影響を判定する人・テストを回す人が、名前で決まっているか
  • ⑥ 契約に含まれるサービスの範囲（自社の契約書の該当条項を実物で確認する）

六番目は必ず契約書の原本に当たる。保守の水準も含まれるサービスも契約の時期によって条件が異なるので、社内の伝聞や過去の稟議書で判断しない。ERPを自社運用で持つかクラウドで受けるかによっても、更新の当たり方と自社側の裁量は変わる（RISE with SAPとオンプレ・自社運用の選択｜クラウド移行をどう決めるか）。

現場では
ある製造業では、稼働から六年間、法改正対応以外の更新を一度も本番に当てていなかった。理由は毎年同じで、影響範囲が読めないため見積が大きく出て、予算が通らないというものだった。転機になったのは、情シスの担当者が更新を当てることを一度あきらめ、代わりにアドオンの依存一覧を作る作業だけを半年かけてやったことだった。稼働中のアドオンを一本ずつ開き、どの標準機能に依存しているかを表に落とす。作ってみると、全体の半分以上は特定の三つの領域に集中しており、残りは互いに独立していた。翌年、影響が独立している範囲だけに絞って更新を当てた。テストは導入時のUATシナリオを掘り起こして再利用し、経理と購買の担当が月次の締めを一サイクル通して確認した。適用は決算期を外した時期に固定した。この年の工数は当初見積の半分以下で済み、翌年からは同じ手順の反復になった。三年目には、標準機能が追いついた領域のアドオンを四本廃止できた。保守料の金額は変わっていないが、稟議で「何に使っているのか」と聞かれたときの答えは変わった。

保守料の価値は、更新の中身でなく取り込む工程で決まる

保守料に見合う価値を出す方法は、値引き交渉ではない。取り込む工程を社内に作ることだ。順番も決まっている。まずアドオンの依存関係を一覧にする。次に、導入時のテストシナリオを掘り起こして再実行できる形に整える。それから適用の窓を年度計画に先に置き、最後に更新を読む人・影響を判定する人・テストを回す人を名前で決める。この四つが揃った時点で、取り込みは判断から作業に変わる。判断のままにしておく限り毎年「今年は見送る」という結論が出続け、見送った分は数年後に一括で返ってくる。工程を持つか持たないかは、どのERPを選んだかとは別の話でもある（SAP以外のERPという選択肢｜自社の規模でSAPが過剰になる分岐点）。作り切る順番は、依存一覧の一枚目から始まる。

まとめ
保守料が無駄になるのは金額が高いからではなく、更新を取り込む工程が社内に無いからだ。保守契約の対価は障害対応の窓口、制度対応の更新、機能の追加・改善に分かれるが、三つ目は取り込まなくても今日の業務が止まらないため後回しになる。取り込まない状態が続くと自社環境と標準の距離が開き、その差分は消えずに次の大きな移行でまとめて精算される。追従を止めている真因はアドオンの存在自体でなく、どのアドオンが標準のどこに依存しているかの一覧が無いことと、回帰テストが毎回ゼロから作られていることにある。工数が読めないので予算が取れず、予算が取れないので見送られ、差分が積み上がってテストがさらに重くなる。抜け方は五工程を年次で固定することだ。使用モジュールに関わる更新内容だけを抜き出し、依存一覧で影響範囲を判定し、保管したテストシナリオを回し、年度計画に先に置いた窓で適用し、標準機能が追いついた領域のアドオンを廃止する。五工程目を回さないとアドオンは増える一方になり、そのままテスト工数として毎年跳ね返る。体制は三つに割る。更新を読む人、影響を判定する人、テストを回す人。三つ目は業務部門に置く。更新の可否は画面が開くかどうかでなく、月次が同じ手順で締まるかで判定されるからだ。少なくとも一つの役割は社内に置く。全部を外に出すと、取り込むかどうかの判断が外部の見積に依存し、高ければ見送るという結論に収束する。見送りは数年後に費目として現れ、機能更新の見送りは移行プロジェクト費用として一括で、アドオンの廃止漏れは回帰テスト工数として毎年増加する形で返る。契約更改の前には、直近三年の取り込み回数、廃止できたアドオン本数、依存関係が文書化された本数、テストシナリオの保管状態、三役割の担当者名を確定させる。

関連記事