はじめに ― なぜ「交渉」で失敗する後継社長が多いのか

先代から会社を引き継いだばかりの社長にとって、システムやITベンダーとのトラブルは想像以上に精神的な負荷が大きいものです。特に、先代の時代から付き合いのある開発会社や、社内の情シス担当者との間で「言った・言わない」の対立が起きたとき、後継社長は次のような感情に襲われます。

「先代が長年付き合ってきた相手だから、強く言えない」 「自分がITに詳しくないから、言いくるめられているのではないか」 「関係を壊したら、システムが止まって業務が回らなくなるのではないか」

こうした不安が先に立つと、交渉の場で感情的になってしまい、逆に不利な条件を受け入れてしまったり、あるいは怒りのままに関係を断ち切ってしまったりします。どちらも会社にとって望ましい結果ではありません。

この記事では、システム開発・運用に関するトラブルが起きたときに、後継社長がどのように冷静に交渉を進めればよいかを、具体的な会話例・チェックリスト・失敗パターンとともに解説します。感情論に流されず、事実と契約書をベースに交渉する技術は、事業承継後のIT実務において必ず身につけておくべきスキルです。

トラブル交渉がこじれる本当の原因

感情が先走る3つの引火点

システムトラブルの交渉が感情的にこじれる背景には、多くの場合、次の3つの「引火点」があります。

第一に、業務停止による焦りです。 基幹システムが止まった、受発注ができない、顧客への請求が滞っているといった状況では、経営者は「今すぐ何とかしてほしい」という切迫感に支配されます。この切迫感が、相手への攻撃的な言葉や、逆に相手の言い分をすべて受け入れてしまう卑屈な態度につながります。

第二に、先代との関係性への配慮です。 先代社長が個人的な信頼関係で契約してきたベンダーの場合、後継社長は「先代の顔を潰したくない」「長年のお付き合いを壊したくない」という気持ちから、明らかに不利な条件でも強く言えないことがあります。これは日本の中小企業では非常によくある構造で、開発会社側も「先代の頃からのお付き合いですから」という言葉を交渉の武器として使うことがあります。

第三に、専門知識の非対称性への劣等感です。 「サーバーの設定ミスです」「これは仕様通りです」といった技術的な説明を受けたとき、後継社長がITに詳しくない場合、反論する材料を持たず、結果として「専門家の言うことだから正しいのだろう」と丸め込まれてしまいます。

この3つの引火点は、いずれも「事実の確認」より先に「感情の処理」が優先されてしまうことで発生します。交渉術の第一歩は、この構造を自覚することです。

感情的な交渉がもたらす実害

感情的になった交渉がもたらす実害は、想像以上に大きいものです。

まず、怒りに任せて相手を強く叱責すると、開発会社側の担当者が防衛的になり、以後の情報開示が消極的になります。トラブルの原因究明において最も重要なのは相手からの正確な情報提供ですが、感情的な対立が生じるとこの情報の流れが止まってしまいます。

逆に、相手の主張をすべて受け入れて泣き寝入りすると、同種のトラブルが再発したときにも同じ対応を迫られる「前例」を作ってしまいます。一度「今回は無償対応でお願いします」と下手に出てしまうと、次回以降も同じ交渉力しか持てなくなるのです。

さらに深刻なのは、社内の従業員や古参社員が、社長の交渉の様子を見ています。感情的に怒鳴る社長を見れば「頼りない」「品格がない」と評価され、逆に一方的に言いくるめられる社長を見れば「あの社長は舵取りができない」と不信感を持たれます。トラブル対応時の交渉態度は、社内の信頼構築にも直結しているのです。

交渉の前に整えるべき「事実の土台」

まず契約書を確認する

感情的にならずにトラブル交渉を進めるための準備段階を、事実整理から交渉本番前までの手順として示すフロー図。

感情的にならずに交渉するための最大の武器は「契約書」です。トラブルが発生したら、まず何よりも先に契約書、特に保守契約を読み直してください。

保守契約には通常、以下のような項目が定められています。

  • 対応時間帯(平日9時〜18時のみ対応、24時間対応など)
  • 対応内容の範囲(軽微な不具合修正のみか、機能追加も含むか)
  • 責任範囲(どこまでが開発会社の責任で、どこからが発注者側の責任か)
  • 障害発生時の対応フロー・報告義務
  • 追加費用が発生する条件

トラブルが起きたとき、感情的になる前に「これは契約上、誰の責任範囲なのか」を確認する作業が、交渉の土台を作ります。この確認作業を怠ると、開発会社側の「これは契約に含まれていないので追加費用が発生します」という主張に対して、感情的な反発しかできなくなってしまいます。

事業承継直後で契約書の存在自体を把握していない後継社長は少なくありません。先代が個人的なやり取りで契約していた場合、契約書自体が存在しない、あるいは口約束で済ませていたというケースも実務ではよく見られます。この場合はまず「契約書が存在するか」「存在するならどこにあるか」を確認するところから始める必要があります。

契約不適合責任という視点を持つ

トラブルの内容が「納品されたシステムが仕様通りに動かない」「バグが多発している」といった品質面の問題である場合、契約不適合責任という考え方を理解しておくことが交渉の武器になります。

これは、納品されたものが契約で定めた内容と異なっていた場合に、発注者が開発会社に対して修補や損害賠償を求めることができるという法律上の考え方です。感情的に「使えないものを納品されて頭に来ている」と伝えるのではなく、「これは契約内容と異なる納品物なので、修補を求める根拠がある」という枠組みで話すことで、交渉の質が変わります。

ただし、この責任には期間の制限があることや、発注者側が検収時に気づけたはずの不具合については主張が難しくなる場合があることにも注意が必要です。トラブルの内容によっては、専門家(弁護士)への相談が必要になるケースもあります。特に金額が大きい場合や、開発会社が明確に責任を認めない場合は、感情的な直接交渉だけで解決を図ろうとせず、早い段階で第三者の意見を挟むことも検討してください。

記録を取ることが交渉力になる

トラブル対応の交渉において、記録の有無は交渉力を大きく左右します。以下の記録は必ず残しておきましょう。

  • トラブル発生日時、発生した現象の詳細(画面キャプチャ、エラーメッセージ)
  • 誰が最初に気づいたか、どのように報告されたか
  • 開発会社への最初の連絡日時と、連絡した内容
  • 開発会社からの回答内容(できればメールやチャットの文面で。電話の場合は直後に「先ほどお電話でいただいた内容の確認です」とメールで要約を送り返す)
  • 対応にかかった時間、業務への影響額(売上損失、残業代など)

記録を取る最大の目的は、後日の交渉で「言った・言わない」の水掛け論にならないようにすることです。感情的な口頭でのやり取りだけで進めてしまうと、後になって「そんなことは言っていない」と言われたときに反論できなくなります。逆に、記録がしっかりしていれば、冷静に「このメールで御社はこう回答しています」と事実を提示するだけで交渉が進みます。

交渉の場で使える具体的な技術

「事実」と「感情」を分けて話す型を持つ

感情的な交渉と事実ベースの交渉を対比し、話し方や結果の違いを左右に並べる比較図。

交渉の場で感情的にならないための最も実践的な技術は、発言を「事実」と「要望」の2階建てにする型を持つことです。

悪い例:「またシステムが止まって、本当に困っているんですよ。いつもこんな調子で、もう信頼できません。」

これは事実(システムが止まった)と感情(信頼できない)が混ざっており、相手は防衛的な反応をしやすくなります。

良い例:「8月10日の14時から16時まで、受注システムが停止していました。この間、電話での注文対応に切り替えざるを得ず、約30件の注文処理が手作業になりました。この原因と再発防止策を教えてください。」

これは事実の提示と、具体的な要望(原因と再発防止策の説明を求める)だけで構成されています。感情の言葉を使わなくても、影響の大きさは十分に伝わります。むしろ感情の言葉を削ることで、相手はこちらの主張をまっすぐ受け止めるしかなくなります。

事業承継直後の社長は、先代のようにベンダーとの人間関係の蓄積がない分、「感情に訴えて動いてもらう」という手段が使いにくい立場にあります。だからこそ、事実ベースの交渉術を身につけることが、先代以上に重要になるのです。

沈黙と間を使う

交渉の場で緊張すると、多くの人は「間」を怖がって喋り続けてしまいます。しかし、相手からの回答が不十分だったり、言い逃れのように聞こえたりしたときは、あえて何も言わずに数秒間黙ることが効果的です。

例えば、開発会社の担当者が「まあ、そのあたりはシステムの仕様上、致し方ない部分もありまして……」と曖昧に濁したとき、すぐに「そうですか、わかりました」と流してしまうと、それが既成事実になってしまいます。ここで一度黙って相手の顔を見る、あるいは「それは具体的にどういうことでしょうか」と静かに聞き返すことで、相手は説明を続けざるを得なくなります。

感情的な交渉が下手な人ほど、この「間」を怖がって早口で妥協案を口にしてしまう傾向があります。冷静な交渉者は、むしろゆっくり喋り、間を恐れません。相手の回答が遅い、あるいは連絡そのものが滞りがちなベンダーとの付き合い方については、先代の代からの開発会社の返信が遅い。関係が壊れる前にできる対処でも具体的に取り上げている。

「持ち帰る」という選択肢を常に持つ

交渉の場でその場で結論を出さなければならないという思い込みも、感情的な判断を招く原因です。特に、開発会社側が「今日中にご判断いただけますか」と迫ってくる場面では、後継社長はプレッシャーを感じて即答してしまいがちです。

しかし、金額や責任範囲に関わる重要な判断は、その場で即答する必要はありません。「持ち帰って社内で検討し、○日までに回答します」と一度区切ることで、感情に流されずに冷静な判断ができる時間を作れます。開発会社側が過度に即答を迫ってくる場合、それ自体が交渉上の駆け引きである可能性も念頭に置いてください。

先代社長の時代からの付き合いだと、「即答しないと失礼だ」という感覚を持ちやすいですが、これは思い込みです。むしろ重要な判断を丁寧に検討する姿勢は、まっとうな経営判断として評価されます。

複数人で対応する

トラブル対応の交渉は、できる限り一人で受けないことをお勧めします。社長一人で電話やオンライン会議に出てしまうと、感情のコントロールが難しくなるだけでなく、後から「そちらの社長がこう言った」と一方的な解釈をされるリスクもあります。

社内の情シス担当者や、経理・総務の責任者など、もう一人を同席させることで、以下のメリットが生まれます。

  • 冷静な第三者の目線が入り、社長自身が感情的になりかけたときにブレーキがかかる
  • 会話の内容を客観的に記録できる(社長は交渉に集中し、同席者がメモを取る)
  • 後日「言った・言わない」の争いになったときに、証言者が複数になる

古参の従業員に同席してもらうことは、単に記録係としての意味だけでなく、「社長は一人で抱え込まず、チームとして対応している」という姿勢を社内に示すことにもつながります。事業承継直後は特に、社長が孤立せずに社内を巻き込む姿勢が、従業員からの信頼獲得にも寄与します。

よくある失敗パターンとその回避策

失敗パターン1: 「先代の代からのお付き合いなので」に流される

開発会社側が「先代社長の頃からずっとお付き合いさせていただいておりますので」という言葉を使ってくることがあります。これは決して悪意のある発言ではなく、単なる社交辞令であることも多いのですが、後継社長がこの言葉に弱いことを見透かして交渉材料に使われる場合もあります。

回避策としては、関係性の話と契約・費用の話を意識的に切り分けることです。「長いお付き合いに感謝している」という気持ちと、「今回のトラブルの責任範囲がどちらにあるか」という判断は、別の軸で考えるべきものです。感謝の言葉を伝えることと、シビアな条件交渉をすることは矛盾しません。「これまでのお付き合いには感謝していますが、今回の件については契約書に基づいて整理させてください」という言い方で、両方を両立させることができます。

失敗パターン2: 技術的な説明に圧倒されて反論できない

「DNSの伝播に時間がかかっている」「キャッシュのパージが必要」「サーバーサイドのタイムアウト設定の問題」といった技術用語を並べられると、ITに詳しくない後継社長は、それが本当に妥当な説明なのか判断できず、そのまま受け入れてしまいがちです。

回避策は、「技術的な正しさ」と「契約上・ビジネス上の合意」を分けて考えることです。技術的な説明が正しいかどうかを社長自身が判断できなくても構いません。重要なのは「その技術的な事象によって、どれだけの業務影響が出て、それは契約上どちらの責任なのか、今後どう対策するのか」という点です。分からない技術用語が出てきたら、恥ずかしがらずに「その説明が事実として正しいかどうかは専門家に確認しますが、まず業務影響と今後の対策を教えてください」と切り分けて質問することが有効です。

必要であれば、顧問のITコンサルタントや、信頼できる別のエンジニアにセカンドオピニオンを求めることも検討してください。事業承継後は、先代が個人的に信頼していた一社に技術判断を依存させず、第三者の視点を持てる体制を整えることが望ましいです。

失敗パターン3: 怒りに任せて契約解除・取引停止を口にする

トラブルが重なると、「もうこの会社とは付き合いたくない」「別のベンダーに切り替える」という言葉が口をついて出ることがあります。しかし、これを感情的にその場で口にしてしまうのは危険です。

システムの移行には相応の時間とコストがかかります。特に基幹システムや顧客データベースを別の開発会社に移行する場合、数ヶ月から1年単位の期間と、決して小さくない移行費用が必要になることも珍しくありません。感情的に「もう切る」と口にした後、実際には簡単に切れないことに気づいて、逆に立場が弱くなってしまうケースもあります。

回避策としては、契約解除や取引停止という選択肢は、あくまで冷静に検討した上での「最終手段」として保持し、交渉の場でカードとして安易に切らないことです。本当に契約解除を検討するのであれば、まず移行の実現可能性・コスト・期間を社内で精査し、その上で「解除する場合、どういう手順・費用になるか」を開発会社に問い合わせるという段取りを踏みましょう。感情的な脅しとして使うと、いざ実行するときに足元を見られてしまいます。

失敗パターン4: すべてを無償対応させようとする

トラブルが発生すると、「これは御社の責任だから当然無償で対応してもらう」という主張を強くしすぎることがあります。もちろん、契約不適合責任が明確な場合はその主張は正当ですが、責任の所在がグレーな場合や、双方に一部の原因がある場合に、感情的に「全部無償」を押し通そうとすると、交渉が決裂しやすくなります。

回避策は、「何割が開発会社側の責任で、何割が自社側の運用の問題か」を事前に整理し、落としどころのイメージを持っておくことです。交渉は白黒つけるだけの場ではなく、双方が受け入れられる合意点を探るプロセスでもあります。特に今後も付き合いを続ける前提であれば、短期的な金額の勝ち負けよりも、中長期的な関係の健全化を優先する判断も必要になります。

失敗パターン5: 担当者個人を攻撃してしまう

開発会社の窓口となっている担当者を、感情的に個人攻撃してしまうケースも見られます。「あなたが担当してから問題が増えた」「あなたの説明はいつも分かりにくい」といった発言は、たとえ事実であっても、相手を萎縮させ、以後の情報共有を消極的にさせるだけで、問題解決には近づきません。

回避策は、批判の対象を「会社としての対応プロセス」に置くことです。「担当者個人の能力」ではなく「御社の障害対応フローや報告体制」に問題があるという枠組みで話すことで、相手も個人的な防衛姿勢を取らずに、組織として改善策を検討しやすくなります。窓口担当者と敵対関係になってしまうと、日常のちょっとした相談や早期の情報提供が滞り、結果的に自社が不利益を被ります。

交渉前チェックリスト

トラブル交渉に臨む前に、以下のチェックリストで準備状況を確認してください。

トラブル交渉に臨む前に準備しておくべき項目を整理したチェックリスト図。

  • [ ] トラブルの発生日時・現象・影響範囲を具体的な記録(画面キャプチャ、ログ、業務への影響額)としてまとめたか
  • [ ] 保守契約書・開発契約書を読み直し、対応範囲と責任範囲を確認したか
  • [ ] これまでのやり取り(メール、チャット)を時系列で整理したか
  • [ ] 電話でのやり取りがあった場合、内容を要約してメールで送り、記録として残したか
  • [ ] 社内で同席者(情シス担当者や幹部社員)を用意したか
  • [ ] 自社側にも運用上の問題がなかったか、フラットに振り返ったか
  • [ ] 交渉で目指す「最低ライン」と「理想のライン」を事前に決めたか
  • [ ] 即答を求められた場合に「持ち帰る」と言える心の準備をしたか
  • [ ] 感情的な言葉(信頼できない、いつもこうだ等)を使わない言い方に事前に言い換えたか
  • [ ] 契約解除や取引停止を口にする場合、その実現可能性とコストを事前に精査したか
  • [ ] 専門家(弁護士、他のITコンサルタント)への相談が必要な規模かどうかを判断したか

交渉後にやるべきこと

交渉が一区切りついた後も、やるべきことは残っています。

まず、交渉で合意した内容は、必ず文書化してください。口頭での合意だけで終わらせると、後日また「言った・言わない」の争いになりかねません。メールで「本日お話しした内容を確認させていただきます」という形で要約を送り、相手からの返信で合意内容を確定させることが望ましいです。

次に、再発防止策が実際に機能しているかを一定期間後にフォローアップしてください。交渉の場では「今後は監視体制を強化します」といった約束を得られても、それが実行されているかを確認しなければ、同じトラブルが繰り返されるリスクが残ります。

最後に、社内への共有です。トラブル対応の経緯と結果を、関係する従業員に簡潔に共有しておくことで、「社長がきちんと対応してくれた」という安心感を社内に広げることができます。特に古参の従業員は、先代の時代からのトラブル対応の記憶を持っていることが多く、後継社長の対応ぶりを先代と比較して見ています。冷静で筋の通った交渉ができたという事実は、後継社長としての信頼を積み上げる重要な機会になります。

サービス品質保証(SLA)の視点を持つと交渉が楽になる

継続的な保守・運用契約を結んでいる場合、SLA(サービス品質保証)が定められているかどうかも確認しておくと、交渉の見通しが立てやすくなります。SLAは、システムの稼働率や障害対応時間などについて、開発会社が保証する水準を定めたものです。これが契約に含まれていれば、「今回の対応時間は、SLAで定められた水準を満たしていましたか」という具体的な問いを立てることができ、感情論に頼らずに交渉を進めることができます。

逆に、SLAが定められていない契約の場合、「何が合格水準か」という共通認識がそもそも存在しないため、トラブル時の交渉が水掛け論になりやすい構造があります。今回のトラブルを機に、今後の契約更新時にSLAの明文化を提案することも、再発防止の一環として検討する価値があります。そもそも月々の保守費でどこまでの対応が含まれるのかを整理しておきたい場合は、月額保守費で何をやってもらえるのか。相場の考え方を参考にしてほしい。

検収時の確認が交渉力を左右する

そもそもトラブルの多くは、システムを受け取る際の検収が甘かったことに起因している場合があります。納品時にきちんと動作確認を行い、問題点を洗い出しておけば、後になって「契約内容と違う」という交渉をする必要自体が減ります。

事業承継直後は、先代がどのように検収を行っていたか、あるいは検収の記録が残っているかを確認しておくとよいでしょう。今後新しいシステム開発やリニューアルを発注する際には、検収の基準をあらかじめ明確にしておくことが、将来のトラブル交渉を減らす最良の予防策になります。契約更新のタイミングで開発会社から何を受け取っておくべきかは、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。

ケーススタディ:先代の代からの開発会社とのトラブル

ここで、よくある事例を一つ紹介します。ある製造業の後継社長は、先代の代から20年近く付き合いのある地元の開発会社に、基幹システムの保守を委託していました。ある月、在庫管理システムに不具合が発生し、在庫数が正しく反映されず、誤った発注が続いてしまうという事態が起きました。

後継社長は最初、電話で担当者に強く抗議しましたが、担当者から「以前のバージョンからの仕様なので」という説明を受け、それ以上反論できずに電話を切ってしまいました。しかし、後で保守契約書を読み直したところ、「軽微な不具合の修正は無償対応」と明記されていることに気づきました。

そこで後継社長は、まず不具合の発生日時と影響(誤発注による過剰在庫の発生額)を記録にまとめ、社内の経理担当者にも同席してもらった上で、改めて開発会社との打ち合わせの場を設けました。そこでは「以前のバージョンからの仕様」という説明そのものを否定するのではなく、「契約上、これは軽微な不具合修正に該当するのではないか」という契約書ベースの指摘を行いました。結果として、開発会社側も契約内容を確認し、無償での修正対応に応じることになりました。

このケースのポイントは、最初の電話での感情的な抗議では何も解決せず、むしろ相手に防衛的な説明をされて終わってしまったのに対し、契約書を確認し、記録を整理し、同席者を用意した2回目の交渉では、事実に基づいた指摘だけで解決に至ったという点です。感情ではなく、契約と記録が交渉を動かした典型例といえます。

よくある質問(FAQ)

Q1. 開発会社の担当者から高圧的な態度を取られたとき、どう対応すればよいですか。

高圧的な態度に対しては、同じトーンで応戦しないことが最も重要です。感情的な応戦は、相手にさらなる高圧的な態度を許すきっかけになりかねません。まずは冷静に「その言い方だと今後の話し合いが難しくなりますので、事実の確認から進めさせてください」と、対応のトーンそのものを指摘して構いません。それでも改善されない場合は、担当者個人とのやり取りを一時中断し、その会社の上長や窓口責任者に対応を切り替えてもらうよう依頼することも検討してください。感情のぶつかり合いを続けても、問題の解決には近づきません。

Q2. 契約書が見つからない、または先代が口約束で契約していた場合はどうすればよいですか。

契約書が見つからない場合でも、諦める必要はありません。まず、これまでの請求書・発注書・メールのやり取りなど、契約内容を推測できる記録を集めてください。これらの記録が積み重なれば、「実質的にどのような合意があったか」を推測する材料になります。また、開発会社側に「契約書の控えがあれば共有してほしい」と依頼することも有効です。今後のトラブルを防ぐためにも、この機会に契約内容を書面化し直すことを提案するとよいでしょう。事業承継のタイミングは、こうした不透明な契約関係を整理する好機でもあります。

Q3. どうしても感情的になってしまう場合、どう自分を落ち着かせればよいですか。

交渉の直前に、事前に用意した「事実の記録」と「要望のリスト」を読み返し、話す内容を紙やメモに書き出しておくことをお勧めします。話す内容が決まっていると、その場の感情に引っ張られて余計なことを言うリスクが減ります。また、可能であれば交渉の場に一人で出席せず、同席者を用意することも効果的です。同席者がいることで、自分が感情的になりかけたときに「一度持ち帰りましょう」と声をかけてもらえる安全弁になります。どうしても自分一人での対応が怖い場合は、社労士や弁護士、ITコンサルタントなど第三者に同席・代理を依頼することも検討してください。

Q4. トラブルが解決した後、開発会社との関係を続けるべきか、切り替えるべきか、どう判断すればよいですか。

判断基準は「今回のトラブルへの対応姿勢」にあります。トラブル発生後、開発会社が事実を認め、誠実に再発防止策を提示してきたのであれば、関係を継続する価値は十分にあります。逆に、責任を認めず、曖昧な説明でやり過ごそうとする姿勢が繰り返されるのであれば、それは今後も同種のトラブルが再発するリスクの高いサインです。感情的な「もう嫌いだから切る」という判断ではなく、「対応の質」という客観的な基準で見極めることが重要です。切り替えを検討する場合は、移行にかかる期間・コスト・リスクを事前に精査した上で、段階的に進める計画を立ててください。刷新の途中で交渉が難航し、計画そのものを止めるべきか迷う場面については、刷新の途中で計画を止めるべきタイミングの見極め方も参考にしてほしい。

交渉が必要になる典型的な場面が、納品されたシステムの品質そのものへの不満だ。システムの品質が低いと感じたとき、古参のベンダーへの伝え方を参照。

まとめ:交渉は「人柄」ではなく「準備」で決まる

事業承継後の後継社長にとって、システム開発会社とのトラブル交渉は避けられない実務課題です。しかし、交渉の結果を決めるのは、社長の人柄や口の上手さではなく、事前の準備の質です。

契約書を読み込み、記録を整理し、事実と要望を分けて話す。この地味な積み重ねが、感情的にならずに交渉を進める最大の武器になります。先代からの付き合いという人間関係の重みに配慮しながらも、必要な場面では契約に基づいた筋の通った主張をする。この両立こそが、後継社長に求められる交渉の技術です。

トラブルが起きたときこそ、社内の従業員は社長の対応を見ています。感情に流されず、冷静に、しかし筋を通して交渉する姿を見せることが、事業承継後の社長としての信頼を積み上げる何よりの機会になるということを、ぜひ覚えておいてください。