稼働から3年目の秋、IT予算の編成会議で情報システム部長が報告する。「来年、クラウドの契約が更新になります」。 CFOが当然の質問をする。いくらになるのか。部長の答えは、まだ先方から提示が来ていません、である。 そこでCFOは契約書を取り寄せた。更新後の価格について書かれている条項は、見つからなかった。 書いてあったのは、期間満了の何か月前までに通知がなければ自動更新されるという条項と、料金は別紙のとおりとする条項だけである。つまり、更新後の金額は相手が決めて、こちらは受けるか出ていくかを選ぶ。出ていく費用はいくらか。それも、どこにも書かれていない。 この会社が失ったのは交渉力ではない。交渉の材料を、3年前に作り損ねたのである。
本稿が数字を置かないところ
先に断っておく。SAPが個々の顧客と結ぶサブスクリプションの単価、更新時の改定率、キャパシティの増減に応じた価格の動き方は、公表されていない。 本稿はこれらを推測で数値化しない。公表されている事実として使えるのは、SAPが保守戦略として公表している期限である。SAP Business Suite 7の中核アプリケーションのメインストリーム保守は2027年末まで、任意の延長保守は2028年初から2030年末までの3年間で、保守ベースに2パーセントポイントのプレミアムが上乗せされる(SAP Maintenance Strategy)。ここで誤読しやすいのは、2030年末で保守が消えると読むことである。 同じページは、延長保守を選ばなかった利用者、および延長保守が終了した利用者は、SAP Business Suite 7のアプリケーションについてカスタマー固有保守(customer specific maintenance)を受けるとしている。 また、2040年まで、常に少なくとも一つのSAP S/4HANAのリリースが保守対象であり続けるとも明記されている。 打ち切りではなく、受けられる保守の質が段階的に変わるという話である(SAP ERP 2027年問題とは何か、保守期限までに決めることと移行の全体像)。もう一つ使えるのが、公正取引委員会の調査が示すクラウド一般の切替えの起きにくさである。
したがって本稿の軸は、いくらになるかの予想ではなく、何を契約で押さえておけば更新の席で話ができるかの設計に置く。 交渉の相場を語る記事より、自社の契約書に足りない条項を数える記事のほうが役に立つ。
同じ調査では、仮にIaaS又はPaaSの利用を拡大する場合に、原則として、あるいはどちらかというと現在利用しているクラウド提供事業者を選ぶと答えた利用者が、IaaSで62.5パーセント、PaaSで63.7パーセントに達している。 拡大するときも現状のまま、値上げされても現状のまま。この二つが揃うと、提供事業者から見た更新は、交渉ではなく通知になる。
初回契約で書かせる四つは、稼働後には書かせられない
更新の交渉力は、更新の前年ではなく、初回契約の時点で決まる。理由は単純で、稼働前は相手が受注を取りに来ているからである。 稼働後は、こちらが動けなくなっている。
書かせる論点は四つに絞れる。第一に、更新時の価格改定の上限である。 改定率そのものを固定できなくても、改定の算定根拠を示す義務、改定を通知する時期の下限、改定幅の上限を何らかの外部指標に紐づけること。上限の数字は交渉の結果であって、こちらが先に決めるのは「上限という概念を契約に入れる」という要求までである。
第二に、キャパシティを減らす方向の柔軟性である。 クラウドの契約は増やす方向の手続が整備されていることが多い。減らす方向がどう書かれているかを読む。 契約期間中に本番環境のリソースや利用者数を下方向に見直せるか、見直せるとしていつ、どの単位で、何か月前の通知でできるか。増やすのは簡単で減らすのは契約期間の満了までできない、という非対称は、実質的に上振れした見積りをそのまま払い続けることを意味する。
第三に、データ返還と移行支援の条件である。 公正取引委員会の報告書が提供事業者に推奨するのは、契約前に移行の可否と、移行元が設定する移行の方法・費用・条件・手続を通知することだった。裏を返せば、契約前に聞かなければ書かれないということである。 どの形式で、どの範囲のデータを、どのくらいの期間で返してもらえるのか。その作業に費用がかかるなら、算定の基準を先に文書にする。
第四に、契約終了時の並行稼働期間である。 移行先の環境で並行稼働する期間、旧環境を使える期間と、その間の課金の扱い。ここが空白だと、退去の日程は相手の都合で決まる(SAP導入の見積書と契約書の読み方、追加費用が生まれる前提条件の確認手順)。
稼働後に毎期やること、更新の前年にやること
初回契約で四つを書かせ損ねた会社でも、稼働後にできることは残っている。それは使用量の棚卸しである。
| 時期 | やること | 目的 |
|---|---|---|
| 毎期(決算と同じ周期) | 本番・非本番の環境数とサイズ、契約上の利用者数と直近90日の実ログイン数、外部システムとの連携本数を同じ様式で記録する | 実績と契約数量の差を、交渉の前に自社の言葉で持つ |
| 毎期 | 利用していない権限や連携がないかを確認する | 使っていない分に払い続ける状態を放置しない(SAPのライセンスとデジタルアクセス) |
| 毎期 | クラウド費用を事業別に配賦し、どの事業がどれだけ使っているかを出す | 削減の議論を情シスの中で閉じさせない(IT費用・クラウド費用の管理会計) |
| 更新の18か月前 | 許容できる費用増加の上限と、技術の陳腐化への対応方針等を社内で決議する | 公正取引委員会が利用者に推奨する取組のうち、更新交渉で効く1点(契約を終了させる条件)の中身。交渉の場で迷わないための自社の線 |
| 更新の18か月前 | 契約書から、価格改定・減量・データ返還・並行稼働の条項を抜き出して一覧にする | 空白がどこにあるかを先に知る |
| 更新の12か月前 | 契約数量を実績に合わせる要求を、こちらから議題として出す | 提示を待つと、提示された数字を起点に議論が始まる |
| 更新の6か月前 | 上限を超える提示が来た場合の社内の意思決定経路を確認する | 決裁が間に合わず、時間切れで受諾する事態を避ける |
棚卸しの着手時期には、別稿で示した下限がある。ライセンスの棚卸しは利用ログの1年分が要るため、着手は更改の半年前が下限になる(SAPのライセンスとデジタルアクセスを棚卸しする手順、未使用権限と外部連携)。本稿の表が18か月前・12か月前という目盛りを置いているのは、棚卸しそのものの所要期間ではなく、その結果を持って契約条項の交渉に入るまでを含めた日程だからである。 半年前は「数え始める」下限、18か月前は「交渉の議題を自分で作る」ための起点だと読み替えてほしい。
この表で一番効くのは、18か月前の二行である。 許容できる費用増加の上限を先に決めておくと、提示された金額が上限の内か外かという判断になる。決めていないと、前年比で何パーセント上がったかという感想になる。 感想には決裁ができない。
交渉は値下げ要求から始めない
更新の席で「安くしてほしい」から入ると、相手は値引きの可否だけを検討する。そして多くの場合、値引きの代わりに契約期間の延長か、追加サービスの抱き合わせが返ってくる。 出口はさらに遠くなる。
入口を変える。契約数量を実績に合わせてほしい、という要求から始める。 本番環境のサイズは契約時の想定業務量に基づいており、稼働3年の実績はこうなっている。非本番環境は4面契約しているが、うち1面は18か月間ログインがない。 利用者数は契約上1,200だが、直近90日にログインした利用者は830である。これらは値引きの要求ではなく、契約と実態の差の指摘である。 相手にとっても反論の形が限られる。
同時に、条項の空白を埋める要求を出す。 次の更新に向けて、価格改定の算定根拠を示す義務と通知時期の下限、データ返還の方法と費用の算定基準、終了時の並行稼働期間。費用の話と条項の話を同じ卓に載せると、片方を譲る形で他方を取れる余地が生まれる。
なお、一方的な条件変更が常に許されるわけではない。 独占禁止法第2条第9項第5号は、自己の取引上の地位が相手方に優越していることを利用して、正常な商慣習に照らして不当に、同号ハに掲げる行為、すなわち取引の相手方に不利益となるように取引の条件を設定し、若しくは変更し、又は取引を実施することなどを行うことを不公正な取引方法として定めている。公正取引委員会の報告書も、自己の取引上の地位が利用者に優越しているクラウド提供事業者が、一方的にサービスの値上げを行うなど利用者との取引の条件を一方的に変更することは、それらによって正常な商慣習に照らして不当に不利益を与える場合には独占禁止法上問題となるという考え方を示している。これは最後の逃げ道であって、交渉の一手目ではない。 持ち出す前に、自社が実績データを持っているかを確かめるほうが先である。
出口の値段を知らない会社に、更新の選択肢はない
更新で会社が選べるのは、原理的には三つしかない。受ける、条件を変えて受ける、出ていく。 このうち三つ目の値段を知らない会社は、実際には二つしか選べない。
出ていく値段は、契約に書かれた移行費用だけではない。データを取り出して別の形式に整える工数、周辺システムとの連携を作り直す工数、業務の再教育、そして移行期間中の二重の運用費用。 これらを一度も見積もったことのない会社は、更新の席で「出ていく」という選択肢を口にできない。口にできない選択肢は、相手にも見えている。
だから、退去の見積りは使う予定がなくても作る。報告書が推奨しているのは退去の実行ではなく、契約を終了させる条件(許容できる費用増加の上限、技術の陳腐化への対応方針等)をあらかじめ定めておき、当該条件に照らした検証を定期的に行うことである。 検証の結果として毎回「継続が合理的」という結論が出ても構わない。結論が同じでも、検証を持っている会社と持っていない会社では、更新の席の座り方が違う(SAPの第三者保守と延長保守の違い、移行の先送りを財務の数字で比べる方法)。
売上高1,100億円の産業機械メーカー。RISEでの稼働から3年目、初回契約の満了まで18か月という時点で、CFOが情報システム部と経理から二人ずつ出して小さな準備チームを作った。 きっかけは、IT予算の会議で更新後の金額を誰も答えられなかったことである。最初にやったのは契約書の条項の棚卸しで、価格改定の算定根拠を示す義務、契約期間中に数量を下方向に見直す手続、データ返還の方法と費用、終了時の並行稼働期間の四つが、いずれも記載されていないことが分かった。 次に使用量を数えた。本番環境のサイズは契約時に想定した業務量の1.4倍の余裕を見て見積もられていたが、稼働3年の実績は想定の0.8倍で推移していた。非本番環境は4面契約しており、うち1面は18か月間ログインの記録がない。契約上の利用者数は1,200で、直近90日にログインした利用者は830だった。約3割が使われていない計算になる。 ここでCFOは、交渉の前に自社の線を決めた。公正取引委員会の報告書が利用者に推奨する取組のうち更新交渉で効く1点、すなわち契約を終了させる条件としての、許容できる費用増加の上限と技術の陳腐化への対応方針である。 上限は、全社IT予算の伸びの範囲内に収めるという方針から、3年間の累計で15パーセント以内と定め、経営会議で決議して議事録に残した。技術の陳腐化への対応方針としては、次回以降の更新の判断材料とするため、退去する場合の費用を一度だけ見積もることにした。 データの取り出しと整形、周辺システムの作り直し、再教育、移行期間中の二重の運用費用を積み上げた概算である。使う予定はなかったが、金額が出た時点で、社内の議論の温度が変わった。 交渉は更新の12か月前に、こちらから議題を出す形で始めた。要求は値下げではなく、契約数量を実績に合わせること、そして書かれていない四つの条項を次期契約に入れることの二つである。 結果は二つに分かれた。単価の引下げは通らず、提示どおりの改定率を受け入れている。 動いたのは数量のほうで、非本番環境を4面から3面に減らし、利用者数の契約枠を1,200から900へ、本番環境のサイズを一段階下へ見直した。 この削減分が単価の改定分をほぼ相殺し、更新後の年間費用は更新前とほぼ同水準に収まっている。 条項については、価格改定の通知時期の下限と、データ返還の方法および費用の算定基準が次期契約に入った。並行稼働期間は次回に持ち越しとなっている。 情報システム部長が振り返って言ったのは、交渉が始まる前の18か月で結果の大半が決まっていた、ということだった。数えた実績と、決めた上限。この二つを持っていた側が、議題を出す側になる。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
決めるのは三つ
第一に、初回契約で四つを書かせる。 更新時の価格改定について算定根拠を示す義務と通知時期の下限と上限の概念、契約期間中にキャパシティや利用者数を下方向に見直す手続、データ返還の方法と費用の算定基準、契約終了時の並行稼働期間である。公正取引委員会が令和4年6月28日に公表したクラウドサービス分野の取引実態に関する報告書は、提供事業者に推奨される取組として、契約前に利用者へ移行の可否と移行の方法・費用・条件・手続を通知することを挙げている。裏を返せば、契約前に聞かなければ書かれない。 稼働後は交渉の力関係が反転するため、同じ条項を後から入れるのは難しい。
第二に、稼働後は使用量を毎期棚卸し、更新の18か月前に自社の線を決議する。 報告書が利用者に推奨する取組は複数あり、データを完全な形で取り出す方法の確認、ポータビリティの高い技術の優先的採用、専門知識を有する人材の確保・育成も含まれるが、更新交渉の席で直接効くのはこの1点である。契約する提供事業者のサービスから退去する必要が生じることも念頭において、契約を終了させる条件(許容できる費用増加の上限、技術の陳腐化への対応方針等)をあらかじめ定めておき、当該条件に照らした検証を定期的に行うこと。 棚卸しそのものの着手は利用ログの1年分が要るため更改の半年前が下限だが、その結果を持って条項の交渉に入るまでを含めると、起点は18か月前に置く。 上限を先に決めておけば、提示された金額を上限の内か外かで判断できる。決めていなければ、前年比の感想にしかならない。
第三に、交渉は値下げ要求ではなく、契約数量を実績に合わせる要求から始める。 同報告書の調査結果は、5〜10パーセントの仮想的な値上げでも利用者の大半が継続すると答えたことを示している(全クラウドの値上げで回答533社中315社、不明204社を除くと95.7パーセント。利用中のサービスの値上げで回答480社中263社、不明174社を除くと85.9パーセント)。この調査が主な対象としたのはIaaS及びPaaSであり、アプリケーションと運用サービスを束ねたRISEの契約に数字がそのまま当てはまるわけではないが、切替えが起きにくいという構造は同じである。 値下げを求めても相手は値引きの可否しか検討しないが、契約と実態の差の指摘には反論の形が限られる。一方的な条件変更については、独占禁止法第2条第9項第5号ハの優越的地位の濫用という枠組みがあるが、これは最後の逃げ道であって交渉の一手目ではない。
関連記事
- RISE with SAPとオンプレ・自社運用の違い、S/4HANAのクラウド移行の選び方
- SAP ERP 2027年問題とは何か、保守期限までに決めることと移行の全体像
- SAP導入の見積書と契約書の読み方、追加費用が生まれる前提条件の確認手順
- SAPのライセンスとデジタルアクセスを棚卸しする手順、未使用権限と外部連携
- SAPの第三者保守と延長保守の違い、移行の先送りを財務の数字で比べる方法
- SAP稼働後の保守運用契約は、維持の工数枠と改善の枠を分けないと改善が進まない
- IT費用・クラウド費用の管理会計、情シス予算を事業別の採算に返す配賦の方法
- ソフトウェアとクラウド利用料の会計処理、資産計上できる範囲は契約の切り方次第



