保守費の値上げを打診されたときの判断基準
先代の葬儀から半年が過ぎたある月曜日の朝、後継社長の机には一枚のメールが届いていた。差出人は先代の時代から付き合いのある開発会社。件名には「システム保守契約更新のご案内」とだけ書かれている。開いてみると、来期からの保守費が現行の月額八万円から月額十四万円へ引き上げられる旨の通知だった。根拠として「エンジニアの人件費上昇」「サーバー費用の増加」「対応範囲の見直し」という三行の説明があるだけで、詳細な内訳はどこにも書かれていない。
後継社長は先代からこのシステムについて詳しい説明を受けていない。何のシステムがどこで動いていて、月八万円が高いのか安いのかすら判断がつかない。手元にある資料は、数年前の見積書のコピーと、担当者の名刺が一枚だけである。パソコンの中を探しても契約書の原本が見当たらず、総務の引き出しの奥からようやく古い紙のファイルを見つけたが、そこに書かれている条項は今のシステム構成とはすでに一致していないように見える。しかも取引先である開発会社の担当者は先代の代から二十年近い付き合いがあり、経理担当の古参社員は「先代の時代からずっとお願いしている先だから、もう慣れているし変えない方がいい」と言う。値上げ額はそのまま受け入れるべきなのか、交渉すべきなのか、あるいは他社への切り替えを検討すべきなのか。判断材料が手元にないまま、返信の期限だけが近づいてくる。
この後継社長の頭の中には、いくつもの疑問が同時に浮かんでいる。今のシステムは本当にこの金額に見合う価値を生んでいるのか。先代はこの開発会社との関係をどう評価していたのか。もし断ったら、業務に使っている基幹システムが止まってしまうのではないか。逆に、何も言わずに受け入れてしまえば、この先も言われるままに値上げを重ねられていくのではないか。こうした疑問に一つも答えを持たないまま、メールの返信ボタンを押す指が止まっている。同じ部屋の壁には、先代が長年使っていたホワイトボードがそのまま残されており、そこには数年前の業務フロー図が消えかけた字で書き残されている。後継社長は、そのホワイトボードを見ながら、自分がこの会社のどれだけの部分をまだ理解できていないかを痛感する。この光景は事業承継の現場で繰り返し起きている典型的な場面であり、多くの後継社長が同じ迷いを抱えたまま、結局は「今まで通りでいいか」と値上げを黙って受け入れてしまう。あるいは逆に、代替わりの勢いだけで「先代の時代のものは全部見直す」と一方的に切り替えを決めてしまい、後になって業務に支障が出るという事態も少なくない。どちらの結末を選んだとしても、後継社長自身がその判断の根拠を説明できないままでは、次に同じような打診が来たときにまた同じ迷いを繰り返すことになる。
しかし、保守費の値上げ打診は、実は後継社長がシステムの実態を初めて自分の目で確かめる貴重な機会でもある。値上げの是非を判断するプロセスそのものが、これまで先代と開発会社の間だけで成立していた「ブラックボックスの関係」を、後継社長自身が管理できる関係に変えていく第一歩になる。値上げの通知一枚をきっかけに、契約書を読み直し、内訳を尋ね、社内の実務担当者に話を聞き、他社の相場を確認する。この一連の作業を経ることで、後継社長は初めて「自社のシステムに何が起きているのか」を自分の言葉で説明できるようになる。これは値上げの是非を判断するためだけの作業ではなく、事業承継後の情報システム管理全体を後継社長主導のものに変えていくための、最初の実践演習でもある。本記事では、なぜ保守費の値上げが起こりやすいのか、その構造的な背景から、実際に値上げを打診されたときにどう調査し、どう判断し、どう交渉すればよいのかを、具体的なステップとチェックリストで解説する。
なぜ保守費の値上げが起こりやすいのか
保守費の値上げという事象は単発の出来事に見えるが、その背景には複数の構造的な要因が積み重なっている。後継社長がこの構造を理解しておくことは、目の前の値上げ額そのものを評価する以前に重要な準備になる。値上げの通知を「担当者の一存」や「会社の都合」として片付けてしまうと、本当は交渉の余地があるはずの部分まで見えなくなってしまう。逆に、なぜ値上げが起こるのかという構造を理解していれば、通知の裏側にある事情を推測しながら、どこまでが妥当でどこからが交渉可能な余地なのかを見分けやすくなる。
要因一 見積もりの前提が古くなっている
多くの中小企業のシステムは、導入から五年、十年、時には十五年以上が経過している。導入当初に結ばれた保守契約の金額は、その時点でのシステム構成、稼働環境、対応範囲を前提に決められている。しかし時間が経つにつれてシステムには機能が追加され、連携する外部サービスが増え、扱うデータ量も増加していく。会計システムと在庫管理システムを連携させる、顧客管理に新しい項目を追加する、モバイル端末からもアクセスできるようにする。こうした変更は一つひとつは小さな依頼として発生し、その都度「今回は特別に」という形で保守費の範囲内で対応されてきたことが多い。開発会社側からすれば、当初の契約金額のままでは実際にかかる保守工数を吸収できなくなっていくのは自然な流れである。特にサーバーやクラウドサービスの利用料は、データ量やアクセス数に応じて段階的に上昇する仕組みになっていることが多く、これが保守費全体を押し上げる要因になる。加えて、当初はオンプレミスのサーバーで運用していたシステムをクラウドに移行した場合、月額の課金体系そのものが変わり、使用量に応じて変動するコスト構造に置き換わっていることもある。この変化を後継社長が把握していなければ、値上げの理由を正しく評価することはできない。
要因二 人件費と技術者不足による市場価格の上昇
システム開発・保守を担うエンジニアの人件費は、この十年で継続的に上昇している。特に古い言語やフレームワークで書かれたシステムを保守できる技術者は年々減少しており、そうした技術者を確保・維持するためのコストは開発会社にとって重い負担になっている。新しい技術を学んだ若手エンジニアほど、古い言語で書かれたレガシーシステムの保守業務を避けたがる傾向があり、結果としてそうした業務を担える人材は限られた層に集中し、単価が上がっていく。開発会社が値上げの理由として「人件費の上昇」を挙げるとき、それは多くの場合誇張ではなく、実際に市場価格が変化している結果である。ただし、この事情が値上げの必要性を説明することと、値上げ額そのものが適正であることは、別の問題として分けて考える必要がある。市場価格が上昇しているという事実と、今回提示された値上げ幅がその上昇分に見合っているかどうかという評価は、常に切り分けて確認しなければならない。
要因三 先代と開発会社の間にあった「口約束」の蓄積
先代の時代、保守契約は書面よりも人間関係で成立していることが少なくない。「多少の追加作業は保守費の範囲でやってもらう」「急なトラブルは電話一本で駆けつけてもらう」といった口約束が積み重なり、実際の対応範囲は契約書に書かれた内容よりもずっと広くなっていることがある。先代と開発会社の担当者が長年の付き合いの中で築いた「多少のことなら大丈夫」という暗黙のルールは、書面には一切残っていない。それでも実務は問題なく回っていたため、誰もそのズレを問題視することなく年月が過ぎていく。開発会社側からすれば、こうした無償の対応を長年続けてきた結果、実質的な採算が合わなくなっているケースは多い。後継社長への代替わりは、開発会社にとって「関係をいったん契約書ベースに戻す」きっかけとして機能しやすく、値上げ打診のタイミングが代替わり直後に集中する背景にはこうした事情がある。
要因四 代替わりを機に関係を見直そうとする開発会社側の思惑
開発会社にとっても、先代との関係が長く続くほど値上げの言い出しにくさは増していく。長年の付き合いがあるからこそ「今さら値上げは言いにくい」という空気が生まれ、本来必要な価格改定が先送りされてきたケースも多い。担当者としては、毎年のように「来年こそは値上げの相談をしよう」と考えながらも、先代との人間関係の中でその話を切り出せずに何年も見送ってきたという事情を抱えていることもある。そこに後継社長への代替わりという転機が訪れると、開発会社側は「新しい経営者になったこのタイミングで、適正な価格に戻したい」と考える。これは決して不誠実な態度ではなく、長年抑えられていた価格の歪みを正す自然な動きである場合が多い。後継社長はこの構造を理解した上で、値上げそのものを「先代への裏切り」や「関係悪化の兆候」と捉える必要はない。
要因五 後継社長側の情報の非対称性
最も重要な構造的要因は、後継社長がシステムの実態について情報を持っていないことである。先代がどのような経緯で今の開発会社と契約したのか、保守費に何が含まれているのか、実際にどれくらいの頻度で保守作業が発生しているのか。これらの情報は先代の頭の中、あるいは古参社員と開発会社担当者の間だけに存在していて、契約書や記録として整理されていないことが多い。先代がすでに引退している場合、この情報の多くは事実上失われており、社内に残る資料と古参社員の記憶だけを頼りに、後継社長が一から実態を組み立て直さなければならない状況に置かれることもある。この情報の非対称性があるために、後継社長は値上げ額が妥当かどうかを判断する土台を持てず、「今まで通りで」という思考停止に陥りやすくなる。値上げ打診への対応の本質は、まずこの情報の非対称性を解消することにある。
要因六 契約書と実態のずれ
保守契約書自体が存在していても、そこに書かれた対応範囲・対応時間・対応方法、いわゆるSLA（サービス品質保証）に相当する部分が、実際の運用と一致していないことは非常に多い。契約書上は「平日日中のみ対応」となっていても、実際には休日や夜間のトラブルにも開発会社が対応してくれていた、というようなケースである。逆に、契約書には「二十四時間対応」と書かれていても、実際に休日にトラブルが起きたときには翌営業日まで対応が遅れていたという食い違いが判明することもある。このズレが放置されたまま値上げの話だけが進むと、後継社長は「何にお金を払っているのか」を正確に把握できないまま契約更新のサインを求められることになる。値上げを判断する前に、この契約書と実態のズレを洗い出す作業が欠かせない。
要因七 業務の成長そのものがコストを押し上げている場合がある
見落とされがちな要因として、値上げの背景に自社の事業成長そのものが影響していることもある。取引先が増え、扱う受注データの件数が増え、システムにアクセスする社員の数が増えれば、システムにかかる負荷そのものが大きくなり、保守に必要な工数も比例して増えていく。この場合の値上げは、開発会社側の一方的な都合というよりも、自社の成長に伴って発生する自然なコスト増という側面が強い。後継社長は、値上げの背景が「開発会社側の事情」なのか「自社の成長に伴う必然」なのかを見極めることで、交渉の方向性を適切に定めることができる。
要因八 業界全体の値上げの波に乗っている場合がある
保守費の値上げが、個別の開発会社の事情だけでなく、業界全体で同時期に進んでいる価格改定の流れに乗っている場合もある。クラウドサービスの利用料が全世界的に上昇したり、ソフトウェアのライセンス費用の改定が一斉に行われたりすると、その影響を受ける開発会社は一様に保守費の見直しを進めることになる。このような場合、値上げの打診を受けたのが自社だけではなく、同じ開発会社と契約している他の取引先にも同時期に同様の通知が送られていることが多い。後継社長が同業者や商工会などのネットワークを通じて、他社にも似たような打診が来ていないかを確認できれば、今回の値上げが業界全体の流れによるものなのか、自社に限った特別な事情によるものなのかを見分ける手がかりになる。
ケーススタディ
ケース一 内訳を尋ねたら三年放置されていたサーバーが判明した金属加工業の例
従業員三十二名の金属加工業を営むある後継社長は、代替わりの翌年に保守費を月額九万円から月額十五万円に上げたいという打診を受けた。担当者からの説明は「システムの規模が大きくなったため」という一言だけだった。先代からは「あの会社は昔からしっかりやってくれているから、値上げが来たら受け入れておけばいい」とだけ言われていたが、後継社長はその場で承諾せず、開発会社に対して保守費の内訳を項目別に開示してもらうよう依頼した。開発会社の担当者は最初こそ「これまでそういった依頼を受けたことがない」と戸惑った様子を見せたが、後継社長が「経営として金額の根拠を把握したいだけで、疑っているわけではない」と丁寧に趣旨を伝えたところ、一週間後に項目別の内訳資料を送ってくれた。
開示された内訳を見ると、保守費の半分近くが「予備系サーバーの維持費」に割かれていることが分かった。調べてみると、この予備系サーバーは五年前に導入されたものの、実際には一度も本番切り替えに使われたことがなく、稼働実績のないまま費用だけが発生し続けていたことが判明した。後継社長が開発会社に確認したところ、当時の担当者は既に退職しており、なぜこの予備系サーバーが必要だったのかを説明できる人間が社内にも開発会社側にもいない状態だった。当時の経緯を知る古参社員に尋ねてみても、「昔、大きな受注が急に増えたときに、システムが落ちたら困るという話になって導入したと思う」という程度の曖昧な記憶しか出てこなかった。
後継社長は、現在の業務量であれば予備系サーバーを縮小した構成でも十分に運用できると判断し、開発会社と協議した上で構成を見直した。開発会社側も、実際に過去のアクセスログを確認した結果、予備系サーバーへの切り替えが発生した記録が一件もないことを認め、縮小案に応じてくれた。結果として保守費は月額十一万円まで抑えられ、当初提示された十五万円よりも四万円低い水準で合意に至った。この例が示すのは、値上げ打診を「はいかいいえかの二択」で受け止めるのではなく、内訳を開示させることで初めて見えてくる無駄が存在するという点である。値上げの理由が正当であっても、その中に見直せる要素が混在していることは珍しくない。この後継社長は後日、「もし内訳を確認せずに十五万円で承諾していたら、使われていないサーバーの費用を何年も払い続けることになっていた」と振り返っている。
ケース二 相見積もりを取って初めて自社の保守費の位置づけが分かった食品小売業の例
従業員十八名の食品小売業を営む後継社長は、先代が開業当初から付き合っている個人事業主のエンジニアから、保守費を月額五万円から月額十万円に倍増したいという打診を受けた。値上げ幅の大きさに驚いた後継社長は、値上げの是非を判断する材料として、他の開発会社二社から同等のシステム保守について相見積もりを取ることにした。相見積もりを依頼する際には、現在使っている受発注システムの機能一覧、利用しているユーザー数、過去のトラブル対応の頻度を資料としてまとめ、できるだけ条件を揃えた比較ができるように準備した。
相見積もりの結果、A社からは月額八万円、B社からは月額十二万円という見積もりが提示された。この結果から、後継社長は今回の打診額である十万円がおおむね市場相場の範囲内であることを理解した。同時に、これまでの月額五万円という金額が、実際には市場相場よりもかなり低い水準で維持されてきたことも分かった。これは先代個人との人間関係によって長年維持されてきた「特別価格」であり、契約を担っていたエンジニアが高齢化し、後継者もいない個人事業であることを考えると、この関係がいつまでも続く保証はないことも見えてきた。相見積もりを取る過程で、A社の担当者からは「個人で長年一社のシステムを見続けている場合、その方に何かあったときの引き継ぎが非常に難しくなる」という指摘も受け、後継社長はこれまで気づいていなかった事業継続上のリスクに初めて向き合うことになった。
後継社長は最終的に、打診された十万円をそのまま受け入れる代わりに、対応時間の明確化と、緊急時のバックアップ担当者を確保することを条件に加えて契約を更新した。具体的には、現在のエンジニアが対応できない場合に備えて、システムの構成図とソースコードの保管場所、緊急連絡先を文書化してもらい、万が一の際に他の技術者が引き継げる状態を整えることを契約書に明記した。値上げそのものは受け入れたが、その過程で「単独の技術者に依存したリスク」という、値上げ額とは別次元の重要な問題を発見できたことが、このケースの本質的な成果だった。相見積もりは値上げ額の妥当性を判断するだけでなく、現在の契約構造に潜むリスクを浮き上がらせる効果も持つ。もし相見積もりを取らずに「倍額はさすがに高すぎる」という感覚だけで拒否していたら、この後継社長は市場相場を知る機会を逃し、単独の技術者に依存するリスクにも気づかないまま、より不安定な関係を続けていたことになる。
ケース三 対応範囲の線引きが曖昧だったために起きた運送業の交渉決裂と再構築
従業員四十五名の運送業を営む後継社長は、配送管理システムの保守費について、開発会社から月額十二万円から月額二十万円への値上げを打診された。八万円という値上げ幅は、これまで受けたことのある打診の中でも最も大きく、後継社長は当初、この金額を見た瞬間に「明らかに不当な値上げだ」と感じたという。後継社長は値上げ額の根拠を尋ねたが、開発会社からは「対応範囲が当初の想定より大幅に広がっているため」という回答しか得られず、具体的な内訳を示す資料も提示されなかった。
詳しく調べてみると、この配送管理システムには、先代の時代に現場の要望で追加された細かなカスタマイズが十数件蓄積されていた。ドライバーごとの休憩時間管理、季節ごとの配送ルート優先度の切り替え、取引先ごとの請求書フォーマットの個別対応など、いずれも当初の契約範囲を超えた追加開発として口頭で依頼され、そのまま保守費の範囲内で無償対応されてきたものだった。配送現場の管理者に話を聞くと、「困ったことがあれば電話一本で開発会社に頼んでいた、費用が発生するという意識はなかった」という証言が相次いだ。開発会社にとっては、これらの積み重ねが実質的な対応工数を大きく膨らませており、値上げはその負担を正常化するための措置だった。
後継社長はこの実態を理解した上で、開発会社との交渉に入った。しかし交渉の初期段階では、後継社長が「値上げ額が高すぎる、根拠を示せ」という姿勢で臨んだため、開発会社側も防御的になり、話が感情的にこじれる場面があった。開発会社の担当者は「これまで無償で対応してきた分をようやく請求できるようになっただけだ」と反論し、後継社長は「先代の時代に合意していない追加費用を今になって払わされるのは納得できない」と応じ、一時は電話を切るような形で交渉が決裂しかけた。感情的な応酬に陥りかけたこの局面は、トラブル時の交渉術。感情的にならずに解決するで扱っているような交渉の基本にも通じる。交渉が一度決裂しかけたところで、後継社長は方針を切り替え、値上げの是非そのものではなく「どの機能にどれだけの保守工数がかかっているか」を一緒に整理する場を設けることを提案した。この機能別の工数整理を通じて、双方は初めて同じ情報を共有した状態で話し合うことができ、休憩時間管理機能や請求書フォーマットの個別対応が、それぞれどの程度の保守工数を要しているのかが具体的な数字として可視化された。最終的には基本保守費を月額十四万円とし、大規模な追加改修は別途見積もりとする形で合意に至った。この例は、値上げ交渉が決裂しかけたときに有効な打開策として、対立の構図を「金額の攻防」から「工数の可視化」に切り替えることの効果を示している。感情的な応酬に陥りそうになったとき、いったん金額の話から離れて事実の整理に立ち戻ることが、双方にとって納得できる合意への近道になる。
実務対応のステップとチェックリスト
保守費の値上げ打診を受けたとき、感情的に反応せず、順序立てて調査・判断・交渉を進めることが重要である。以下のステップに沿って対応することで、後継社長は限られた情報の中でも合理的な判断に近づくことができる。ここで紹介するステップは、必ずしも一直線に進む必要はなく、状況に応じて前後したり同時並行で進めたりしても構わない。重要なのは、感覚や関係性だけで結論を出さず、事実を集めるプロセスを一つずつ踏んでいくという姿勢そのものである。特に代替わり直後は、社内の誰もがシステムの実態を正確に把握していないことが多いため、後継社長自身がこの調査の主導役を担う必要がある。時間がかかる作業に見えるかもしれないが、一度この調査の型を作っておけば、次回以降の値上げ打診や、他の取引先との条件交渉においても同じ型を使い回すことができ、長期的には大きな時間の節約になる。
ステップ一 現在の契約書と請求実績をすべて確認する
まず最初に行うべきことは、現在結ばれている保守契約書の内容を一字一句確認することである。対応範囲、対応時間、対応方法、契約期間、解約条件、そして現在の金額に何が含まれているのかを、担当者に聞く前に自分の目で確認する。合わせて過去一年から三年分の請求書・支払い履行の実績を突き合わせ、契約書に書かれた金額と実際に支払っている金額が一致しているかを確認する。契約書が見つからない、あるいは古すぎて現状と合っていないという場合には、その事実自体を記録しておく。これは後の交渉における重要な手がかりになる。契約書が見当たらない場合は、開発会社に対して控えを再送してもらうよう依頼することも忘れてはならない。開発会社側が契約書を保管していないという事態は稀だが、もし相手側にも控えが残っていないとすれば、それ自体が契約管理の甘さを示す事実として記録しておく価値がある。
ステップ二 値上げの根拠となる内訳を開発会社に開示してもらう
値上げの打診を受けたら、金額の是非を即答する前に、必ず内訳の開示を依頼する。「人件費上昇のため」「サーバー費用増加のため」という一行の説明だけで判断することは避け、具体的にどの作業・どの費用が増えているのかを項目別に示してもらう。誠実な開発会社であれば、この依頼に対して具体的な回答をしてくれるはずである。依頼をする際には、疑いの姿勢を前面に出すのではなく、「経営として金額の根拠を正確に把握したいので、内訳を教えてほしい」という趣旨を丁寧に伝えることが、その後の関係を良好に保つ上で重要である。回答が曖昧であったり、開示自体を渋る態度が見られた場合、それは今後の関係を見直す一つのシグナルとして受け止める必要がある。
ステップ三 過去の保守対応の実績を振り返る
契約書や見積もりの内訳だけでなく、実際にどれくらいの頻度で保守対応が発生していたかを振り返ることも欠かせない。過去のメールやチャットの履歴、対応記録を遡り、月に何件の問い合わせやトラブル対応があったのか、そのうち緊急性の高いものはどれだけあったのかを整理する。可能であれば、直近一年分の対応履歴を一覧表にまとめ、依頼内容・対応日・対応にかかった時間を並べて可視化すると、感覚ではなく数字で実態を把握できるようになる。対応実績が非常に少ないにもかかわらず大幅な値上げが打診されている場合は、金額の根拠を厳しく確認する必要がある。逆に、記録以上に頻繁な対応が実際には発生していたことが分かれば、値上げにも一定の合理性があると判断できる。
ステップ四 社内の実務担当者から実態を聞き取る
経理担当や現場の実務担当など、実際にこのシステムを日常的に使っている社員から、システムの使い勝手や困っていること、開発会社との実際のやり取りの様子を聞き取る。古参社員は先代の時代からの経緯を知っている貴重な情報源であると同時に、変化を好まない立場から「今まで通りでいい」という結論に誘導しがちな面もある。聞き取りの際には、事実の確認と意見の確認を分けて捉え、事実部分は記録として整理し、意見部分は参考情報として扱う姿勢が大切である。聞き取りは一人だけでなく、部署をまたいで複数人から行うことで、特定の担当者の思い込みや記憶違いに引き寄せられるリスクを減らすことができる。
ステップ五 相見積もりを取り、市場相場を確認する
可能であれば、現在の開発会社以外に一社から二社程度、同等のシステム保守について見積もりを依頼する。相見積もりの目的は必ずしも乗り換えを前提とするものではなく、現在提示されている金額が市場相場に対してどの位置にあるのかを知ることにある。月額保守費で何が対応範囲に含まれるのかという相場観そのものは、月額保守費で何をやってもらえるのか。相場の考え方で詳しく整理している。長年同じ相手と付き合ってきた場合、相場感を持たないまま値上げの是非を判断してしまうリスクが大きいため、このステップは特に重要である。相見積もりを依頼する際には、現在のシステム構成や対応範囲をできる限り具体的に伝え、条件を揃えた比較ができるようにしておく。見積もり依頼の段階で、現在の開発会社名を明示する必要はなく、あくまで自社のシステム保守として一般的な条件を提示すれば十分な比較材料が得られる。
ステップ六 値上げ額を機能・工数単位に分解して評価する
内訳の開示や相見積もりの結果が揃ったら、値上げ額を一つの塊としてではなく、機能単位・工数単位に分解して評価する。どの機能の保守にどれだけの工数がかかっているのか、そのうち自社が実際に使っている機能はどれか、逆に使っていないのに保守費が発生している機能はないかを一つずつ確認する。この作業を通じて、値上げ額全体を受け入れるか拒否するかという二択ではなく、部分的に見直すという選択肢が見えてくることが多い。機能ごとに分解した結果は、社内で共有できる資料としてまとめておくと、次回以降の値上げ打診にも再利用できる。
ステップ七 交渉の落としどころを複数用意して打診に応じる
調査と評価が終わったら、値上げ打診への回答として複数の落としどころを事前に用意しておく。全額そのまま受け入れる案、対応範囲を見直すことで金額を抑える案、段階的な値上げに変更してもらう案、契約期間を長くする代わりに単価を下げてもらう案など、複数の選択肢を持って交渉に臨むことで、感情的な対立を避けながら合理的な合意に近づきやすくなる。交渉の場では、値上げの必要性そのものを否定するのではなく、「妥当性を一緒に確認したい」という姿勢で臨むことが、長期的な関係を維持する上でも有効である。交渉相手が長年の付き合いのある担当者である場合、金額の話に入る前に、これまでの対応への感謝を一言添えるだけでも、その後の対話の雰囲気が大きく変わることがある。
ステップ八 合意内容を必ず書面に残す
交渉の結果どのような結論に至ったとしても、その内容を必ず書面で残す。口頭やメールでのやり取りだけで済ませてしまうと、次の値上げ打診が来たときに再び同じ調査を一からやり直すことになる。合意した金額、対応範囲、見直しのタイミング、次回契約更新の時期などを契約書または覚書として明文化しておくことで、後継社長自身の負担を将来にわたって軽減できる。書面化の際には、次回の契約更新時に確認すべき項目もあらかじめリストアップしておくと、数年後の自分や後任者への引き継ぎもスムーズになる。
チェックリスト 値上げ打診を受けたときに確認すべき項目
現在の契約書に記載されている対応範囲と金額を確認したか。過去一年から三年分の請求実績と契約内容が一致しているかを確認したか。値上げの根拠となる内訳を項目別に開示してもらったか。過去の保守対応の実績（頻度・内容・緊急度）を振り返ったか。実務担当の社員からシステムの使用実態を聞き取ったか。他の開発会社から相見積もりを取り、市場相場を確認したか。値上げ額を機能単位・工数単位に分解して評価したか。契約書に書かれた対応範囲と実際の運用にズレがないか確認したか。値上げに応じる場合の複数の落としどころを用意したか。合意内容を書面として残す準備をしたか。値上げの通知に記載されている返信期限を確認し、必要であれば延長を依頼したか。業界全体の値上げの流れに乗っているものかどうかを、可能な範囲で確認したか。
これらの項目を一つずつ確認していくことで、後継社長は情報不足のまま値上げを受け入れる、あるいは根拠なく拒否するという両極端を避け、根拠に基づいた判断にたどり着くことができる。すべての項目を一度に完璧にこなす必要はなく、時間的な制約がある場合には、契約書の確認と内訳の開示依頼という最も基本的な二項目だけでも押さえておくことで、判断の土台を最低限確保することができる。慣れてくれば、これらの確認作業は数時間程度で終えられるようになり、値上げ打診が来るたびに一から悩む必要もなくなっていく。
よくある失敗パターン
失敗パターン一 古参社員の意見だけで即決してしまう
経理担当や総務担当の古参社員が「先代の時代からのお付き合いだから」という理由で値上げの受け入れを強く勧めてくることがある。後継社長がこの意見をそのまま採用し、内訳の確認や相見積もりといった調査を一切行わずに値上げを承諾してしまうケースは非常に多い。古参社員の意見は先代との関係性や過去の経緯を知る貴重な情報である一方、金額の妥当性そのものを判断する材料にはならない。意見と事実を分けて扱わないまま即決してしまうと、後から市場相場より大幅に高い金額で契約を続けていたことが判明し、後継社長自身の判断力が社内で疑問視される事態にもつながりかねない。実際に、値上げを即決してから半年後に別件で相見積もりを取ったところ、当初の打診額が市場相場の一・五倍近くであったことに気づいたという例もある。このとき、すでに新しい契約期間に入ってしまっていたため、再交渉のタイミングを逃し、次の契約更新まで割高な金額を払い続けることになった。値上げの是非は関係性の話ではなく、事実に基づく評価の話として扱う必要がある。
失敗パターン二 値上げ拒否を先に決めてから根拠を探しにいく
先代からの代替わりを機に「コストは全部見直す」という方針を掲げる後継社長も少なくないが、この方針が先行しすぎると、値上げを拒否するという結論を先に決めてから、それを正当化する根拠だけを探しにいくという逆転した進め方になりやすい。この進め方では、開発会社が提示する説明を最初から疑いの目で見てしまい、本来正当な値上げ理由であっても受け入れられなくなる。結果として開発会社との関係が不必要に悪化し、契約解除に至ったものの、後継作業の引き継ぎが不十分なまま保守が途切れ、システムトラブルへの対応が遅れるという事態を招くこともある。ある事例では、値上げを拒否して開発会社との契約を打ち切った直後に基幹システムに不具合が発生し、後任として選んだ開発会社がシステムの構造を理解するまでに一か月以上を要し、その間の業務に大きな支障が出たという記録も残っている。判断の順序は、まず事実を集め、その上で結論を出すという流れを守る必要がある。
失敗パターン三 値上げ交渉を担当者個人との関係に依存させてしまう
長年付き合いのある担当者と後継社長個人が信頼関係を築いている場合、値上げの交渉もその個人的な関係の中だけで進めてしまい、契約書や書面での記録を残さずに口頭の約束で済ませてしまうことがある。この進め方は一見スムーズに見えるが、担当者が異動や退職をした瞬間に、それまでの約束事がすべて無効になり、後任の担当者との間で同じ交渉をゼロからやり直す事態に陥る。特に開発会社側の担当者が変わるタイミングと保守費の再値上げのタイミングが重なることは多く、書面化を怠ったことのしわ寄せが数年後に一気に表面化するケースは珍しくない。個人的な信頼関係と契約上の合意は、常に分けて記録しておく必要がある。
失敗パターン四 値上げの通知を放置し、返信期限を過ぎてしまう
値上げの通知を受け取ってから、判断材料が手元にないことに戸惑い、調査を始める前に時間だけが過ぎてしまうという失敗パターンも見られる。多くの保守契約では、値上げ後の金額に異議を申し立てられる期限が設けられていることが多く、この期限を過ぎてしまうと、たとえ調査の結果値上げ額に問題があると分かっても、次の契約更新のタイミングまで交渉の機会を失ってしまう。値上げの通知を受け取った時点で、まず返信期限を確認し、必要であれば「検討のための時間をいただきたい」と一言連絡を入れておくだけで、この失敗は避けられる。
よくある質問
値上げの打診を受けたら、すぐに他社への切り替えを検討すべきですか
すぐに切り替えを決める必要はない。まず行うべきは値上げの根拠を確認し、内訳を開示してもらうことである。相見積もりを取ることは有効な手段だが、それは切り替えを前提とするものではなく、現在の金額が市場相場に対してどの位置にあるかを知るための調査として活用するのが基本の姿勢である。切り替えは、現在の開発会社との関係が根本的に見直せない場合の最終的な選択肢として検討すべきものであり、システムの移行にはコストとリスクが伴うことも踏まえて判断する必要がある。
開発会社が内訳の開示に応じない場合はどうすればよいですか
内訳の開示に応じない、あるいは説明が一貫しないという態度が続く場合は、今後の関係を見直す材料として重く受け止めるべきである。誠実な開発会社であれば、値上げの根拠を具体的に説明することに支障はないはずである。開示に応じない理由が単なる説明不足であれば、時間をかけて丁寧に依頼を重ねることで解決する場合もあるが、繰り返し依頼しても状況が変わらない場合は、相見積もりを進めて他の選択肢を用意しておくことが望ましい。返信そのものが遅く、関係の温度感に不安を感じ始めている場合は、先代の代からの開発会社の返信が遅い。関係が壊れる前にできる対処も参考になる。
古参社員が値上げの即決を強く勧めてくるとき、どう対応すればよいですか
古参社員の意見をむげに否定せず、まずその意見の背景にある事実、つまり先代との経緯や過去のトラブル対応の実態を丁寧に聞き取ることが大切である。その上で、金額の妥当性については別途調査を行うことを伝え、意見と事実を分けて判断する姿勢を社内に示す。古参社員の協力を得ながら調査を進めることで、対立を避けつつ合理的な判断に近づくことができる。
値上げ額が市場相場と比べて明らかに高すぎる場合、どう伝えれば関係を壊さずに交渉できますか
金額そのものを否定する言い方ではなく、「妥当性を一緒に確認したい」という姿勢で伝えることが有効である。具体的には、相見積もりの結果や機能単位の工数分解といった事実を提示しながら、開発会社側にも説明の機会を与える形で対話を進める。対立の構図を「金額の攻防」にせず、「工数や範囲の可視化」に置き換えることで、双方が納得できる合意点を見つけやすくなる。交渉の場に入る前に、こちらが確認したい論点をあらかじめ整理し、感情的な言葉ではなく具体的な数字や事実を並べて話すことで、開発会社側も防御的な姿勢を取らずに対話に応じやすくなる。返信期限が迫っていて十分な調査の時間がないと感じる場合には、金額の是非を即答する前に、まず「検討のための時間が必要なので期限を延長してほしい」と率直に伝えることも忘れてはならない。多くの開発会社はこうした申し出に応じてくれるものであり、拙速な回答よりも、落ち着いて事実を確認した上での回答の方が、結果的に双方にとって納得感のある合意につながりやすい。
まとめ
保守費の値上げ打診は、後継社長にとって単なるコストの問題ではなく、先代の時代からブラックボックスのまま維持されてきたシステムとの関係を、自分の目で確認し直す重要な機会である。値上げが起こる背景には、システム規模の拡大、人件費や市場価格の上昇、口約束の蓄積、代替わりを機にした関係の見直し、そして自社の事業成長そのものといった構造的な要因が複数重なっている。これらの背景を理解した上で、契約書と実態の確認、内訳の開示依頼、過去の対応実績の振り返り、実務担当者からの聞き取り、相見積もりによる市場相場の確認、そして機能単位での評価という段階を踏むことで、後継社長は感情や関係性だけに頼らない、根拠に基づいた判断にたどり着くことができる。
値上げを全額受け入れるか拒否するかの二択で捉えず、複数の落としどころを用意して交渉に臨み、最終的な合意は必ず書面に残すという姿勢を徹底することが、開発会社との関係を長期的に健全な形で維持するための土台になる。古参社員の意見に流されて即決すること、拒否の結論を先に決めて根拠を後から探すこと、個人的な信頼関係だけに頼って書面化を怠ること、そして返信期限を放置してしまうことは、いずれも後になって後継社長自身の負担として跳ね返ってくる失敗パターンである。これらの失敗の多くは、時間的な余裕がない中で焦って結論を出そうとすることから生まれている。値上げの通知を受け取った直後に即答する必要はなく、まずは検討のための時間を確保し、落ち着いて事実を集めることが、結果的に最も確実な近道になる。
事業承継の初期段階では、後継社長は先代が築いてきたあらゆる関係を一度に理解しようとして、情報量に圧倒されがちである。保守費の値上げという一つの出来事に丁寧に向き合うことは、こうした状況の中で自分なりの判断の型を作っていく良い練習にもなる。今回学んだ調査の手順や交渉の考え方は、システムの保守費だけに限らず、賃借契約や取引先との条件交渉など、事業承継後に繰り返し訪れる別の判断の場面でも同じように活用できる。
一つの値上げ打診に丁寧に向き合った経験は、社内にも良い影響を与える。古参社員は、後継社長が感情や関係性だけでなく事実に基づいて判断する姿を見て、次第に安心して新しい経営のやり方を受け入れるようになっていく。開発会社の担当者にとっても、根拠を尋ねられ、丁寧に説明を求められるという経験は、これまでの緩やかな関係を、双方にとって健全で長続きする関係へと更新するきっかけになる。目の前の値上げ額そのものよりも、それを判断するプロセスを自分の手に取り戻すことこそが、事業承継における情報システムの管理を後継社長主導のものに変えていく本質的な一歩になる。
