この記事で分かること

次の開発会社への乗り換えを決めた。候補会社との商談も進んだ。あとは今の開発会社に「解約します」と伝えるだけ——のはずが、いざその一言を切り出す段になって、手が止まっていないでしょうか。

「今までお世話になったのに、どう切り出せば角が立たないだろうか」「解約を伝えた瞬間、対応が急に悪くなったりしないだろうか」「メールで済ませていいのか、電話や訪問が必要なのか」。こうした迷いは、担当者が不誠実だからではなく、日常的に何度も経験することではないからこそ生まれるものです。

この記事は、乗り換え自体を「するかどうか」「いつ動くか」を判断する記事ではありません。乗り換えを決めた後、実際に今の開発会社へ解約を伝えるという一場面に絞り、次の3点を具体的に解説します。

  • 解約を伝える前に確認しておくべきこと(契約条件・伝える順序)
  • 実際に何を、どの順番で、どんな言葉で伝えるか(文面例つき)
  • 伝えた後、関係が悪化しないように何を続けるか

なお、そもそも今の開発会社を乗り換えるべきかどうかの判断や、乗り換え全体の時系列フローについては、別記事「開発会社の乗り換え判断フロー」で詳しく解説しています。すでに乗り換えを決めていて、今まさに解約の伝え方で悩んでいる方は、この記事から読み進めて問題ありません。

なぜ「伝え方」がこれほど重要なのか

解約の意思決定そのものは、社内で完結する作業です。しかし解約を「伝える」という行為は、相手のある一つのコミュニケーションであり、伝え方次第でその後の展開が大きく変わります。

具体的には、解約の伝え方が悪いと、次のような事態を招くことがあります。

長年の不満を一気にぶつけるように解約を告げたところ、相手の態度が硬化し、残りの契約期間中の対応が事務的かつ最低限のものになった。引き継ぎに必要な資料の提供も「契約範囲外」を理由に渋られ、結局は追加費用を払って個別に依頼することになった。

逆に、伝え方に配慮があれば、残りの契約期間中も通常どおりの対応を受けられ、引き継ぎにも協力的な姿勢を得やすくなります。契約が終わるからといって、相手との関係の質が契約の最後まで保守や引き継ぎの質に影響しないとは限らないのです。

ここで押さえておきたいのは、「角を立てない」ことと「言うべきことを言わない」ことは別だという点です。この記事が目指すのは、事実を曖昧にしたまま関係だけを取り繕う対応ではありません。解約という決定は変えずに、伝え方と手順によって、相手の協力を引き出しやすい形に整えるという実務上の工夫です。

感情と実務を分けて考える

解約を伝える場面では、これまでの不満(レスポンスの遅さ、見積もりへの不信感など)がどうしても頭をよぎります。ですが、解約の伝達という実務の場で、過去の不満を蒸し返すように伝えることは得策ではありません。

  • 不満を伝えたい気持ち → 社内の記録として残す、または別の機会に整理する
  • 解約を伝える実務 → 事実(契約終了の意思と時期)を淡々と、しかし明確に伝える

この2つを混ぜてしまうと、相手は防御的になり、円満な引き継ぎへの協力度が下がりやすくなります。不満があったとしても、解約を伝える場では「これまでの対応への評価」と「契約終了の事実」を切り分けて考えることをおすすめします。

伝える前に必ず確認しておくこと

解約を伝える行動そのものに入る前に、次の3点を確認しておく必要があります。ここを飛ばして先に口頭で「もう他社に切り替えます」と伝えてしまうと、後から訂正や補足が必要になり、かえって印象を悪くすることがあります。

解約を伝える前に確認すべき「契約書の解約条件」「新しい開発会社との合意状況」「社内の決裁・関係者への根回し」の3項目を示す概要図

1. 契約書の解約条件

まず契約書を再確認し、次の項目を把握してください。

確認項目見るべきポイント
契約形態請負契約か準委任契約か。解除のルールが異なる
解約予告期間何ヶ月前までに通知が必要か
通知方法の指定書面・内容証明など、契約書が指定する方法があるか
自動更新条項更新拒否の通知期限はいつまでか
中途解約時の費用精算違約金や既払い費用の扱いはどうなっているか

契約書に「解約は書面による」といった指定がある場合、口頭やメールだけで済ませると契約上の解約通知として有効に成立しない可能性があります。まずは契約書の文言どおりの方法で通知することを優先してください。

契約の法的な性質も、解約のしやすさに直結します。民法上、準委任契約は各当事者がいつでも解除できるのが原則です(民法第651条1項)。ただし、相手方に不利な時期に解除した場合や、相手方の利益(報酬を得ることのみを目的とするものを除く)をも目的とする委任を解除した場合は、やむを得ない事由がない限り、相手方の損害を賠償する義務が生じます(同条2項)。一方、請負契約では、請負人が仕事を完成しない間であれば、注文者はいつでも損害を賠償して契約を解除できます(民法第641条)。

どちらの契約形態であっても「いつでも解除できる」こと自体は共通していますが、「損害賠償が必要になるかどうか」の条件が異なります。実務上は、契約書に定められた解約予告期間を守って通知すれば、この損害賠償リスクは大きく下がります。契約書の解約条項が民法の原則より発注者に有利・不利のどちらに調整されているかも、あわせて確認しておきましょう。

2. 新しい開発会社との合意状況

解約通知を出すタイミングは、新しい開発会社との合意状況と連動させる必要があります。基本的には、次の順序を守ることをおすすめします。

  1. 新しい開発会社とおおむね契約内容の合意ができている(正式契約はまだでも可)
  2. 現行の開発会社に解約予告期間を守って通知する
  3. 並行して新しい開発会社との正式契約を締結する
  4. 引き継ぎ作業を開始する

新しい会社との合意より先に解約を通知してしまうと、万が一その交渉が破談した場合、システムを保守する会社が一時的にいなくなるリスクがあります。逆に解約通知が遅れすぎると、新しい会社の稼働開始が遅れ、保守が空白になる期間が生じかねません。乗り換え全体のスケジュール設計については、別記事の判断フローで詳しく扱っています。

3. 社内の決裁・関係者への根回し

解約は自社にとっても意思決定であり、担当者が独断で進めるべきものではありません。伝える前に、次の関係者への説明を済ませておきましょう。

  • 上長・決裁者への報告(すでに乗り換え自体の承認は得ているはずですが、解約通知のタイミングを共有)
  • システムの主要な利用部門への事前連絡(業務への影響が出る可能性がある場合)
  • 経理・法務など、契約解除の手続きに関わる部門への連携

社内調整が済んでいない状態で解約を伝えてしまうと、後から「やはり時期を延ばしたい」といった変更が必要になり、相手に対してさらに印象を悪くする二度手間が発生します。

誰が、いつ、どう伝えるか

確認が済んだら、実際に伝える準備に入ります。ここでは「誰が」「いつ」「どの手段で」伝えるかを整理します。

伝える相手

解約の意思は、日常的にやり取りしている担当者ではなく、契約上の窓口(営業担当、契約書に記載された連絡先、または先方の管理職)に伝えるのが基本です。日常の担当者だけに口頭で伝えて終わらせてしまうと、社内共有が漏れて「聞いていない」という行き違いが生じることがあります。

可能であれば、日常の担当者には先に一言伝えたうえで、正式な通知は契約上の窓口宛てに書面またはメールで送るという二段構えにすると、驚かせずに、かつ正式な手続きとしても成立させやすくなります。

伝えるタイミング

解約予告期間から逆算し、余裕を持ったタイミングで通知します。予告期間ぎりぎりに通知すると、相手側の引き継ぎ準備の時間も圧迫され、結果として自社の引き継ぎ品質にも跳ね返ってくることがあります。

  • 予告期間が3ヶ月であれば、可能な限り4〜5ヶ月前を目安に一次的な意思表示を行う
  • 正式な書面通知は、予告期間の起算日を明確にするため、契約書の指定方法に従って送付する
  • 繁忙期(決算期、大型リリース直前など)を避けられるなら避ける

伝える手段の使い分け

伝える手段は一つに絞る必要はなく、次のように段階を踏むと角が立ちにくくなります。

  1. 口頭またはオンライン会議で一次的に伝える: いきなり書面が届くと、相手は驚きと同時に不信感を持ちやすくなります。先に人対人で状況を共有し、心の準備をしてもらう
  2. 正式な書面・メールで通知する: 契約解除の意思表示として、日付・解約希望日・根拠となる契約条項を明記した書面を送る
  3. 引き継ぎに向けたキックオフの場を設ける: 通知後、感情的なわだかまりを引きずらないよう、早めに実務的な引き継ぎの打ち合わせを設定する

口頭・オンライン会議での一次連絡、正式な書面・メール通知、引き継ぎキックオフという3段階で解約を伝える手段を示すステップ図

電話やチャットだけで解約の意思を伝え、正式な書面を後回しにしてしまうと、「言った・言わない」の水掛け論になりやすく、解約予告期間の起算日も曖昧になります。口頭での一次連絡と、書面での正式通知は必ずセットで行ってください。

実際に何を伝えるか: 構成と文面例

伝える内容は、感情を排して事実ベースで構成することが基本です。ここでは口頭での一次連絡と、書面通知それぞれの構成を示します。

口頭・オンライン会議で伝える際の構成

以下の順序で伝えると、相手に不要な警戒心を与えずに、事実を明確に伝えられます。

  1. 感謝を簡潔に伝える(長々と述べる必要はない)
  2. 契約終了の意思を明確に伝える(曖昧な言い回しを避ける)
  3. 理由を簡潔に伝える(詳細な批判は避け、事実ベースで一言)
  4. 今後のスケジュール感を共有する
  5. 引き継ぎへの協力をお願いする

文面例は次のとおりです。

「本日はお時間をいただきありがとうございます。率直にお伝えしますが、弊社では今後のシステム運用体制を見直すこととなり、〇年〇月末をもって、貴社との保守契約を終了させていただきたく存じます。これまで長期間にわたりご対応いただき、感謝しております。今回の判断は、社内の体制変更に伴うもので、貴社の対応品質そのものへの不満が主因ではございません(※事実に即して調整)。正式な解約通知は追って書面にてお送りいたします。つきましては、引き継ぎに向けて、今後どのようなスケジュールで進めていただけるか、ご相談させてください。」

理由を伝える部分は、事実に忠実であることが大前提です。対応品質への不満が実際の理由であれば、無理に取り繕う必要はありません。ただし、感情的な表現(「もう限界だった」「ずっと不満だった」など)は避け、「体制の見直し」「事業方針の変更」「機能要件の変化」など、事実に基づいた中立的な表現を選ぶことをおすすめします。

理由の伝え方: 中立的な言い回しの例

理由をどう伝えるかで悩む担当者は多いものです。実際の理由と、伝える際の言い回しを分けて整理しておくと、その場で言葉に詰まらずに済みます。

実際の理由伝える際の言い回しの例
対応の遅さに不満があった「システムの重要度が増す中で、より迅速な対応体制を求めることになりました」
見積もりが不透明で高額だった「コスト構造を見直す中で、体制を変更することといたしました」
担当者交代が頻繁で不安だった「継続的に同じ体制でご対応いただける会社と長期的な関係を築きたいと考えました」
事業拡大で対応範囲が合わなくなった「事業の拡大に伴い、対応いただける領域の広い会社への切り替えを検討しました」

嘘をつく必要はありませんが、事実の中から「関係を悪化させにくい角度」を選んで伝えることは、円満な関係終了のための正当な工夫です。

書面・メールで通知する際の構成

正式な通知は、口頭で伝えた内容を書面として残す位置づけになります。次の要素を含めることをおすすめします。

  • 件名: 「保守契約終了のご通知」など、内容が一目で分かるもの
  • 契約の特定: 契約名・契約番号・契約締結日
  • 解約の意思表示: 「〇年〇月〇日をもって解約いたします」という明確な文言
  • 根拠条項: 契約書のどの条項に基づく解約かを明記
  • 今後の進め方: 引き継ぎに関する打ち合わせの提案
  • 連絡先: 今後のやり取りの窓口

書面は、契約解除の意思表示として後から証拠にもなるため、曖昧な表現を避け、日付と条項を明確に記載することが重要です。感謝の言葉を一文添えることは問題ありませんが、書面全体は簡潔にまとめ、長文の説明や言い訳を書き連ねる必要はありません。

伝えた後、関係を保つためにすること

解約を伝えた瞬間がゴールではありません。むしろ、そこから引き継ぎが完了するまでの期間の対応こそが、円満な関係終了を左右します。

通知直後の対応

解約を伝えた直後は、相手も心理的に動揺していることがあります。次のような配慮が有効です。

  • 通知後、すぐに次の話(引き継ぎスケジュールなど)に踏み込みすぎず、相手の反応を見る余地を残す
  • 相手からの質問や確認事項には、できるだけ早く丁寧に回答する
  • 感謝を伝える場面では、これまでの具体的な成果や助けられた場面を一つでも挙げると、形式的でない印象を与えられる

引き継ぎ期間中に心がけること

引き継ぎ期間中は、旧開発会社の協力度が円満な伝え方の成果として表れる期間です。次の点を意識してください。

  1. 依頼事項は一度に大量に投げず、優先順位をつけて段階的に依頼する
  2. 資料提供や質問への回答に時間がかかっても、催促は事実確認のトーンで行う(「お忙しいところ恐れ入りますが、〇月〇日までにご確認いただけますでしょうか」)
  3. 新開発会社とのやり取りが必要な場面では、自社の担当者が間に立ち、直接の摩擦を避ける
  4. 引き継ぎが完了した段階で、あらためて感謝を伝える

引き継ぎに必要な資料の具体的な一覧や、旧開発会社への依頼の進め方そのものについては、別記事「開発会社の乗り換え手順: 引き継ぎに必要な資料一覧」で詳しく解説しています。この記事では、あくまで依頼する際の伝え方・トーンに焦点を当てています。

相手が非協力的になった場合の対応

配慮して伝えても、相手の対応が事務的、あるいは非協力的になることはあります。その場合の対応は次のとおりです。

  • 感情的に反応せず、契約書に定められた義務(引き継ぎ協力義務など)を根拠に、事実として依頼を継続する
  • 契約書に引き継ぎ協力義務の明記がない場合、強制することは難しいため、粘り強く文書での依頼を重ねる
  • 明らかに悪質な対応(正当な理由のない資料提供拒否など)が続く場合は、専門家への相談も検討する

感情をぶつけたくなる場面ですが、ここで感情的な対応に転じてしまうと、それまでの丁寧な伝え方の効果が薄れてしまいます。トラブルが発生した際の交渉の基本姿勢については、別記事「トラブル時の交渉術」でも詳しく扱っているので、あわせて参考にしてください。

やってはいけない伝え方

最後に、実際によくある「角が立つ伝え方」のパターンを挙げておきます。振り返りのチェックとして活用してください。

  • 前触れなく書面だけを一方的に送る: 相手にとって寝耳に水となり、以降のやり取りが硬直化しやすい
  • 他社と比較して批判する: 「〇〇社の方が対応が早い」といった直接的な比較は、相手の感情を強く刺激する
  • 担当者個人を名指しで批判する: 会社の体制の問題であっても、特定の個人を名指しすると、組織対応であるべき解約が個人攻撃の様相を帯びる
  • 理由を一切説明しない: 理由を伏せすぎると、相手は不信感を募らせ、逆に詮索や引き止めの交渉を招くことがある
  • 引き継ぎへの協力を当然の権利のように要求する: 契約上の義務であっても、高圧的な依頼の仕方は協力度を下げる

これらはいずれも、解約の意思そのものではなく「伝え方」の問題です。同じ解約の決定であっても、伝え方次第で相手の対応が大きく変わることを、あらためて意識しておいてください。

社内向けの説明: 稟議・利用部門への伝え方

社外の開発会社への伝え方に意識が向きがちですが、社内向けの説明も同時に整えておく必要があります。特に、決裁者や利用部門への説明が不十分だと、後になって「なぜ今の会社を切るのか」という疑問が蒸し返され、解約通知を出した後で社内の合意が揺らぐという事態を招きかねません。

決裁者への説明で押さえるべき点

決裁者への説明では、感情的な不満の羅列ではなく、次の3点を簡潔に示すことを意識してください。

  1. なぜ乗り換えが必要か(現行体制のままではどんな支障が続くか)
  2. 乗り換えに伴うリスクと、その対策(引き継ぎ期間の重複設計など)
  3. 想定されるスケジュールと費用(解約予告期間、二重コストの見込みなど)

決裁者がITに詳しくない場合、専門用語を避け、業務への影響という観点で説明すると伝わりやすくなります。「レスポンスが遅い」ではなく「障害発生時に業務が〇時間止まる状態が続いている」のように、具体的な影響で語ることをおすすめします。

利用部門への事前連絡

システムを日常的に使っている利用部門に対しては、解約や乗り換え自体の詳細を伝える必要はありませんが、次の点だけは事前に共有しておくと、移行期のトラブルを避けやすくなります。

  • 保守窓口が一時的に変わる可能性があること
  • 引き継ぎ期間中、通常より対応に時間がかかる場合があること
  • 何か不具合が起きた際の緊急連絡先(この期間中は誰に連絡すればよいか)

利用部門への連絡が遅れると、移行期に発生したトラブルの問い合わせが、担当者一人に集中してしまうことがあります。事前に周知しておくことで、そうした負荷の集中を防げます。

ケース別: 伝え方の調整ポイント

ここまでの基本形を踏まえたうえで、状況によって伝え方を調整すべきケースを整理します。

長年の付き合いがある会社の場合

数年以上にわたって付き合いのある会社の場合、事務的な通知だけで終わらせると、これまでの関係の重みに見合わないと受け取られることがあります。可能であれば、書面での通知に加えて、直接の挨拶の機会(訪問やオンライン会議)を設けることをおすすめします。

相手の対応にすでに強い不満がある場合

対応の悪化が著しく、円満な関係を維持する動機自体が薄い場合でも、伝え方の基本(事実ベース・感情を排する)は崩さないことをおすすめします。感情的に伝えてしまうと、契約書に明記されていない協力(引き継ぎの融通など)を得にくくなり、結果的に自社が損をする可能性があるためです。

同業界・狭い業界で今後も接点がありうる場合

業界内の評判が回り回って、将来別の取引先経由で再び関係が生じる可能性がある場合は、特に丁寧な伝え方を心がける価値があります。解約の伝え方そのものが、自社の評判として業界内に伝わることもあり得ます。

解約通知の前後で使えるチェックリスト

ここまでの内容を、実務で使えるチェックリストとして整理しておきます。解約通知の前後で、抜け漏れがないか確認する際に活用してください。

通知前の確認事項

  • 契約書の解約予告期間・通知方法の指定を確認したか
  • 新しい開発会社との合意状況(正式契約はまだでも実質合意)を確認したか
  • 社内の決裁者・利用部門への事前説明を済ませたか
  • 伝える理由を、中立的な言い回しに変換して準備したか
  • 口頭での一次連絡と、書面での正式通知、両方のタイミングを決めたか

通知時の確認事項

  • 契約上の正式な窓口宛てに通知しているか(日常の担当者だけで済ませていないか)
  • 通知の文面に、解約希望日と根拠条項を明記したか
  • 感情的な表現を避け、事実ベースの言い回しになっているか
  • 引き継ぎに向けた次の打ち合わせを提案したか

通知後の確認事項

  • 相手からの質問・確認事項に、期限内に丁寧に回答しているか
  • 引き継ぎの依頼を、優先順位をつけて段階的に行っているか
  • 新開発会社とのやり取りで、自社の担当者が調整役として機能しているか
  • 引き継ぎ完了後、あらためて感謝を伝える機会を設けたか

このチェックリストは一度で完璧にこなす必要はありません。むしろ、抜けている項目に気づいた時点で、慌てずに一つずつ対応していく姿勢の方が、結果として円満な関係終了につながります。

まとめ

開発会社の解約を伝える場面は、感情的な蓄積があるからこそ、つい勢いで伝えてしまいたくなる瞬間です。しかし、伝え方一つで、残りの契約期間中の対応品質も、引き継ぎへの協力度も大きく変わります。

この記事で示したポイントを振り返ると、次のようになります。

  • 伝える前に、契約書の解約条件と新しい会社との合意状況を確認する
  • 伝える相手・タイミング・手段を段階的に設計する(口頭での一次連絡 → 書面での正式通知)
  • 理由は事実に基づきつつ、中立的な言い回しに変換して伝える
  • 伝えた後の引き継ぎ期間こそ、円満な関係終了の成果が問われる期間である

もし今、解約を伝える前の段階であれば、まずは契約書を開き、解約予告期間と通知方法の指定を確認するところから始めてみてください。乗り換え全体の進め方や、引き継ぎに必要な資料の詳細については、関連記事もあわせて参考にしてください。