先代の代からの開発会社、角を立てずに関係を終える伝え方

結論から言えば、先代の代から付き合いのある開発会社との関係を終えるときに一番やってはいけないのは「黙って発注を止める」ことです。角を立てずに終えるには、①契約書を確認して解除の権利と手続きを把握する、②切るタイミングを繁忙期や更新月からずらす、③理由を先代や古参社員のせいにせず自社の事業判断として説明する、④データと業務知識を引き渡してもらう約束を先に取る、という順序を守ることです。感情の整理と手続きの整理は分けて考える必要があります。

こんな状態に当てはまる人に、この記事は特に読んでほしいと思っています。先代が創業した頃からシステムを作ってもらっている開発会社があり、社長が変わっても契約は自動更新のままになっている。担当者は先代の顔しか知らず、今の社長である自分とはどこか距離がある。システムは古いが「あの会社に頼めば動く」という安心感だけで契約を続けてきた。しかし最近、見積もりの根拠が不透明だったり、レスポンスが遅かったり、他社の話を聞くと明らかに割高だと感じるようになった。それでも「先代の代からお世話になっている会社を切るなんて」と言い出せず、古参の総務担当者からも「あそこは長年やってもらっているから」と言われて動けない。そういう二代目・三代目の経営者に向けて書いています。

承継社長が抱える「相談先がない」という孤独

会社を継いだ社長の多くは、株式の承継や登記の変更については税理士や司法書士という専門家が付いています。事業承継計画を立てるときも、事業承継・引継ぎ支援センターや商工会議所が相談窓口として機能します。ところがシステムやITベンダーとの関係については、相談する専門家が実質的にいません。顧問弁護士がいても契約書のチェックはしてくれますが、「この開発会社との関係を続けるべきか」という経営判断そのものには答えてくれません。結果として、システムの契約継続・解除の判断は社長一人が抱え込むことになりがちです。

株式や登記であれば、法務局や税務署という明確な手続きの窓口があります。しかしベンダーとの契約は相手も人間であり、感情と力関係が絡みます。先代が「あの社長には世話になった」と言っていた会社を、代替わりした自分が切るというのは、単なる契約の見直しではなく、先代の人間関係を引き継ぐか整理するかという判断でもあります。この孤独感は、承継社長特有のものだと言っていいでしょう。

なぜ「先代の代から」の関係ほど整理しづらいのか

長年の付き合いには、独特の粘着性があります。理由は大きく三つあります。

• 人間関係が契約より先に成立している。先代と開発会社の社長が個人的に親しい、あるいはゴルフや飲み会での付き合いがある場合、契約解除は「取引の終了」ではなく「関係の断絶」として受け取られやすい。
• 業務知識がベンダー側に偏在している。長年同じ会社に発注していると、仕様書やドキュメントが整備されておらず、担当者の頭の中にしか業務ロジックが残っていないことがある。
• 古参社員が間に立っている。総務や経理の担当者がベンダーの担当者と長年やり取りしており、社長よりも先代やその担当者との関係が深い場合がある。

この三つが絡み合うと、「システムの話」のはずが「人間関係の話」にすり替わり、経営判断として動けなくなります。まず自分の中で、この二つを意識的に分けることが出発点になります。

契約を確認する前にやるべき棚卸し

感情の話をする前に、まず事実を確認します。多くの承継社長は、今どんな契約がどんな条件で結ばれているかを正確に把握していません。以下を最初に確認してください。

1. 契約書の原本または控えの有無(先代の書斎や倉庫に眠っていることが多い)
2. 契約形態(開発時の請負契約か、保守・運用の準委任契約か)
3. 契約期間と自動更新条項の有無
4. 解除条項(解除できる条件、通知期限、違約金の有無)
5. データやソースコードの所有権・提出義務に関する条項
6. 月額・年額の支払い実態と、直近の見積もり根拠

こうした基礎情報がないまま「切りたい」という感情だけで動くと、後で違約金を請求されたり、データが引き渡されないまま業務が止まったりするリスクがあります。システム管理台帳を作っておくと、この棚卸し自体が一度きりの作業でなく、次の見直しのときにも使える資産になります。台帳といっても難しいものではなく、契約名・ベンダー名・契約形態・更新月・年間コスト・担当者名を一枚の表にまとめるだけで十分です。

契約形態によって「切り方」が変わる

開発会社との契約は、大きく請負と準委任の二種類に分かれます。この違いを理解しておくと、解除の進め方がまったく変わってきます。

請負契約は「仕事の完成」を約束する契約で、民法第641条では「請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる」と定められています(e-Gov法令検索・民法)。つまり開発途中のシステムであれば、発注者側からいつでも解除できますが、その時点までの損害を賠償する必要があります。

一方、保守や運用のように継続的な業務委託は準委任契約にあたることが多く、民法第651条では「委任は、各当事者がいつでもその解除をすることができる」とされています。ただし同条第2項では、相手方に不利な時期に解除した場合や、受任者(ベンダー側)の利益をも目的とする委任を解除した場合は、損害を賠償しなければならないと定められています。ただし「やむを得ない事由があったとき」はこの限りでないとも書かれています。

委任は、各当事者がいつでもその解除をすることができる。前項の規定により委任の解除をした者は、次に掲げる場合には、相手方の損害を賠償しなければならない。ただし、やむを得ない事由があったときは、この限りでない。(民法第651条)

つまり法律上は「いつでも解除できる」のが原則ですが、実務上は「不利な時期を避ける」「損害賠償の話にならないよう手順を踏む」ことが、円満な終わり方につながります。契約書に個別の解除条項がある場合はそちらが優先されるため、まずは契約書の文言を確認することが先決です。

切るタイミングの選び方

角を立てずに関係を終えるには、タイミングの選定が実務上もっとも影響が大きい要素です。避けたいタイミングと、選びたいタイミングを整理します。

契約更新の2〜3ヶ月前に動き出すのは、単に礼儀の問題ではありません。準委任契約は「不利な時期」の解除に損害賠償リスクが生じるため、更新のタイミングに合わせて「更新しない」という選択をするのが、法的にも心理的にも一番自然な切り方です。自動更新条項がある契約は、多くの場合「更新月の何ヶ月前までに通知すれば更新されない」という条件が定められているので、この期限を過ぎないことが最優先です。

角を立てない伝え方の順番

伝え方には順番があります。いきなり「もう他社に切り替えます」と言うのではなく、次の順番で進めると受け手の心理的な負担が小さくなります。

1. 感謝を言葉にする。「先代の代から長年支えていただいたことには感謝しています」という前置きを、社交辞令ではなく本気で伝える。
2. 自社側の事情として説明する。「事業の方向性が変わった」「社内の体制を見直している」など、相手の仕事の質を否定しない理由を選ぶ。
3. 具体的な今後の予定を伝える。いつまでにどう移行するのか、引き渡しに何が必要かを明確にする。
4. 感情的な議論を避ける。相手が不満や反論を口にしても、その場で反論せず「検討させてください」と持ち帰る余地を残す。

このとき絶対に避けたいのが、相手のシステムやサポートの「悪さ」を理由として並べることです。たとえ事実であっても、長年の担当者にとっては人格否定に近く受け取られ、円満な引き渡しが遠のきます。理由は常に「自社の変化」に置き、相手の仕事を否定しない言葉を選ぶことが、その後のデータ引き渡しや過渡期のサポートを円滑にする実務上のコツです。

古参社員をどう扱うか

社長本人が「切る」と決めても、実務担当の古参社員がベンダーの担当者と長年の関係を築いている場合、社員側の抵抗が想像以上に大きいことがあります。ここで社長がやるべきことは、決定事項を一方的に通告することではなく、決める前に相談の形を取ることです。

• 「切る・切らない」を既定事項として伝えるのではなく、「今の契約についてどう思うか」を先に聞く
• 社員が知っているベンダー側の事情(担当者の異動、会社の体制変化など)を先に集める
• 移行作業の実務は古参社員が担うことが多いため、その負担への配慮を先に示す
• 「あなたの今までの付き合いのおかげで大きな問題なくやってこられた」という功労を認める言葉を挟む

古参社員は、ベンダーとの関係が終わることを「自分の仕事の否定」と感じることがあります。決定の正しさよりも、決定に至るプロセスに自分が関与できたかどうかが、その後の協力度合いを左右します。

引き渡してもらうべきものリスト

関係を終える交渉の中で、最も実務的に重要なのがデータと知識の引き渡しです。感情面の配慮に気を取られて、この部分を口約束で終わらせると、後になって「渡してもらえない」というトラブルに発展します。契約解除の合意と同時に、次のものを書面で確認してください。

• データベースの全データ(エクスポート形式、文字コードを含めて確認)
• ソースコード一式とその著作権・利用権の扱い
• システム構成図、インフラの接続情報、パスワード類
• 運用マニュアル、過去の障害対応記録
• ドメイン・サーバー・ライセンスなど契約者名義の確認と移管手順

ソースコードの権利関係は納品物からどこまで確認できるかが実務上のポイントになります。詳しくは先代システムのソースコードの権利は誰にあるか、納品物から確認する方法で解説しています。ライセンスの名義変更については先代の代からのライセンス契約、名義変更で困らないための確認事項も参考にしてください。これらはデータポータビリティの考え方に直結します。長年同じベンダーに任せてきたシステムほど、データの持ち出し方法自体が整備されておらず、いざ移行しようとすると「エクスポート機能がない」「独自形式でしか出力できない」という壁にぶつかることが少なくありません。契約終了の合意書に、引き渡す形式とその期限を明記しておくことが、後々のトラブルを防ぐ最も確実な方法です。

「切る」以外の選択肢も検討する

ここまで解除の進め方を説明してきましたが、実際には全面的な契約解除だけが選択肢ではありません。中小企業のシステム関係の見直しには、いくつかの段階があります。

• 契約範囲を縮小する: 保守契約は残しつつ、新規開発だけを別会社に発注する
• 並行運用する: 既存システムは維持しながら、新しいシステムを別建てで立ち上げ、段階的に移行する
• 役割を分担する: 基幹部分は既存ベンダーに残し、周辺のWebサイトや業務ツールだけを新規に発注する

これは実質的にマルチベンダーの体制に移行するということです。一社に依存していた状態から複数社に分散させることで、一社との関係を完全に断つ前に、リスクを抑えながら次の体制を試すことができます。「白か黒か」で決めなくても、段階的に関係を薄めていく道があることは、心理的なハードルを下げる意味でも知っておく価値があります。マルチベンダー体制のメリット・デメリットはマルチベンダー体制のメリット・デメリット、承継後の見直しどきで詳しく扱っています。

見積もりの不透明さをどう確認するか

「割高かもしれない」という疑念だけで関係を切るのは早計です。まずは根拠を確認する会話を持つことをお勧めします。

「最近の見積もりについて、内訳を詳しく教えてもらえますか。他社の相場観と比較検討したいので」

このように、疑いをぶつける言い方ではなく、情報を求める言い方にするだけで、相手の防御的な反応を避けられます。長年の付き合いだからこそ、値上げの理由や作業内容の変化について、きちんと説明を求める権利があります。この会話自体が、関係を続けるか終えるかの判断材料になります。説明が誠実であれば継続の理由になり、説明が曖昧であれば見直しの理由になります。

新しい相談先をどう選ぶか

関係を終えると決めたら、次にどこに相談するかという問題が出てきます。ここで注意したいのは、「今の会社の担当者と同じような距離感」をすぐに求めないことです。長年の付き合いで築かれた安心感は、初めて会った会社との間にすぐには生まれません。

比較検討の軸としては、次のような点が実務的に有効です。

• 見積もりの内訳が具体的で、質問に対して明確に答えられるか
• 既存システムのデータやコードを確認した上で提案してくれるか(現状を見ずに提案する会社は避ける)
• 契約形態と解除条件が明文化されているか
• 特定の技術・製品への依存を前提にした提案でないか

最後の点は特に重要です。新しい会社に切り替えても、その会社の独自技術やパッケージに強く依存する形で作り直してしまうと、ベンダーロックインの状態を作り直すだけになります。関係を整理する目的が「一社依存から抜け出すこと」であるなら、次の依頼先を選ぶときも、汎用的な技術で作られているか、他社への引き渡しが将来できる設計になっているかを確認する視点を持つべきです。外部に任せ続けるべきか、一部を内製化すべきかという判断軸は、内製化とアウトソースの分岐点、承継社長が判断する視点で整理しています。

契約を終える前に「引き継ぎ書」を作ってもらう

関係を終える交渉の中で意外と見落とされがちなのが、口頭でのやり取りに依存した業務知識です。長年の担当者は、契約書やマニュアルに書かれていない細かな運用ルールを頭の中に持っています。たとえば「月末の締め処理はこの順番で行う」「このエラーが出たときは再起動すればよい」といった、いわば暗黙知です。

契約終了の合意をする際には、次のような引き継ぎ書を作成してもらうよう、早い段階で依頼しておくことをお勧めします。

1. システムの全体構成と、各機能がどの業務に対応しているかの一覧
2. よくある不具合とその対処方法
3. 過去に発生した大きな障害の記録と原因
4. 外部サービスとの連携がある場合、その認証情報や連携先の窓口
5. 今後発生しうる注意点(古い部品の在庫、特定の担当者しか知らない設定など)

これは新しい依頼先にとっても大きな助けになりますし、万が一自社で一時的に運用を引き継ぐ場面が発生した場合の保険にもなります。引き継ぎ書の作成は工数がかかるため、無償で依頼するのではなく、最終月の契約の一部として費用を認める姿勢を示すと、相手も協力的になりやすいという実務上の傾向があります。

移行期間中に起きやすい問題

契約終了の合意ができても、実際の移行期間には想定外のことが起きます。事前に想定しておくべき点を挙げます。

1. サポートの質が急に落ちる: 解除が決まった後、ベンダー側の優先度が下がり、対応が遅くなることがある。合意時に「移行完了までのサポート内容」を具体的に取り決めておく。
2. データ移行時の不整合: 長年運用されたデータには、フォーマットの揺れや重複が蓄積している。移行前にデータクリーニングの工程を見込む。
3. 社内の混乱: 古参社員が新しいベンダーとの関係構築に消極的になることがある。移行期間中は社長自身が新旧両方との連絡窓口を担う場面が増える。
4. 請求の重複: 新旧両方の契約が一時的に並走する期間が発生し、コストが一時的に増える。予算に組み込んでおく。

これらは「切る」と決めた瞬間ではなく、その後数ヶ月の実務の中で発生します。契約解除は交渉で終わるのではなく、移行完了まで見届ける必要がある、という前提を持っておくことが重要です。

契約解除の通知は誰が持っていくべきか

契約を終える意思を伝える方法にも、円満さを左右する要素があります。メールや電話だけで済ませるのか、直接会って伝えるのかは、関係の長さと重みに応じて選ぶべきです。先代の代から数十年続いているような関係であれば、電話一本やメール一通で済ませるのは、相手にとって軽く扱われたという印象を強く残します。

可能であれば、次の順番で進めることをお勧めします。

1. まず電話で「相談したいことがあるので、一度お時間をいただけますか」と伝える
2. 対面もしくはオンライン会議で、感謝と今後の方針を口頭で伝える
3. 話した内容を、契約終了の合意書または確認メールとして書面に残す

口頭だけで済ませると、後になって「そんな話だったか」という認識のズレが生まれることがあります。感謝や事情の説明は口頭で丁寧に、契約条件や引き渡し内容の確認は書面で、という役割分担を意識してください。書面を交わすことは、相手を疑っているからではなく、双方が後で困らないための備えだと説明すれば、多くのベンダーは違和感なく受け入れます。

承継直後に動くべきか、しばらく様子を見るべきか

代替わりした直後は、社内外から「新しい社長がどう動くか」を見られている時期です。この時期にベンダーとの関係を急に変えると、「先代を否定する社長」という印象を持たれるリスクがあります。一方で、承継から数年が経ち、社内の体制が固まってから動こうとすると、契約は惰性で更新され続け、見直しのきっかけを失いがちです。

現実的な目安としては、承継後おおよそ半年から1年の間に、まずは前述の棚卸し(契約内容の確認)だけを済ませておくことをお勧めします。この段階では「切る」という判断はまだせず、事実を集めるだけにとどめます。判断そのものは、決算を一度締めて事業の全体像が見えた後、つまり承継後1〜2年の間に行うのが、社内外への説明もしやすく、無理のないタイミングになることが多いです。

急いで結論を出す必要はありません。むしろ、拙速に動いて古参社員や取引先との関係を損なうことのほうが、経営上のダメージとして残りやすいという点は覚えておいてください。

見積もり比較で気づく「本当のコスト構造」

複数社から見積もりを取ってみると、これまで見えていなかったコストの内訳が浮かび上がることがよくあります。長年同じ会社に発注していると、月額いくら、年額いくらという総額しか把握しておらず、その中身がどう構成されているかを深く考えなくなりがちです。

比較の際に確認しておきたい項目を整理します。

このような比較を一度やってみると、「なんとなく高い気がする」という感覚が、具体的にどの項目が割高なのかという形で言語化されます。これは相手との交渉材料になるだけでなく、関係を続けるにしても終えるにしても、次の判断の土台になります。

顧問税理士・商工会議所を「システムの相談窓口」として使う

株式や登記の相談先があるのにシステムの相談先がない、という孤独感を和らげる方法の一つが、すでにある相談先との関係を転用することです。顧問税理士や商工会議所の経営相談員は、システムの技術的な内容には詳しくなくても、契約書の読み方や、事業計画への投資の位置づけについては相談に応じてくれることが多くあります。

具体的には、次のような相談の持ち込み方が有効です。

• 「今のシステム関連の契約が、事業の実態に見合っているか、契約書を一緒に確認してほしい」
• 「ベンダーを切り替える場合、資金計画にどう影響するか一緒に考えてほしい」
• 「古い契約を整理する際、税務上・契約上の注意点があれば教えてほしい」

技術的な良し悪しの判断はできなくても、経営判断としての整理を手伝ってもらうことはできます。システムそのものの相談先がなくても、経営全体を見てくれる相談先を「システムの契約整理」という文脈で使うという発想の転換が、承継社長の孤独感を実務的に減らす一つの方法になります。

見直しの主導権を握るのは経営者自身であるべき理由

システムの契約見直しを、総務担当者や情報システム担当者に一任してしまう社長もいます。しかし、先代の代からの関係を整理するという判断は、単なる事務作業ではなく経営判断です。担当者に判断を委ねてしまうと、次のような問題が起きやすくなります。

• 担当者がベンダーとの個人的な関係を優先し、判断が先送りされる
• 担当者に決定権がないため、ベンダー側も本気の交渉に応じない
• 契約解除に伴う責任の所在が曖昧になり、後になって「誰が決めたのか」という社内対立が生まれる

もちろん、実務的な調整や日々のやり取りは担当者に任せてよいのですが、「契約を終える」という最終判断と、その判断を先代やベンダーに伝える場面には、社長自身が出ることが望ましいです。特に先代の代からの関係であれば、社長が自ら顔を出して話をすることそのものが、相手への敬意の表れとして受け取られます。逆に担当者だけに伝えさせると、「軽く扱われた」という印象を与え、円満な引き継ぎが遠のく場合があります。

感情を整理するための自分への問いかけ

契約の手続きを整理する一方で、社長自身の感情も無視できません。長年の関係を終えるという判断には、罪悪感や不安が伴うことが自然です。動き出す前に、自分自身に次のように問いかけてみることをお勧めします。

• この関係を続ける理由は、システムの品質か、それとも「切りづらいから」という消極的な理由か
• 先代がまだこの会社を選び続けているとしたら、今の条件でも同じ判断をするだろうか
• 自分が本当に不満に感じているのは、担当者個人か、それとも会社としての体制や価格か
• 5年後、この関係を続けていた場合と、今整理した場合とで、会社の状態はどう変わっているか

こうした問いに答えを出す過程そのものが、感情面の整理になります。惰性で続けているだけなのか、実際に価値を感じて続けているのかを自分の中で明確にすることが、その後の交渉での言葉のブレを減らし、相手にも一貫した姿勢として伝わります。

交渉の場で実際に使える言い回し

ここまで方針を説明してきましたが、実際の場でどう言葉にするかで迷う経営者は多いです。参考として、状況ごとの言い回しの例を挙げます。そのまま使う必要はありませんが、トーンの参考にしてください。

契約更新を伝えるとき:

「これまで長い間、支えていただき本当にありがとうございました。会社の体制を見直す中で、次の期間からは別の形で進めることにしました。急な話で申し訳ありませんが、移行にあたって必要なデータや資料があれば、ぜひ協力していただきたいと思っています。」

見積もりの根拠を尋ねるとき:

「今回の見積もりについて、どの部分の作業にどれくらいの時間がかかっているのか、内訳を教えていただけますか。社内で予算の説明をする必要があるので、詳しく把握しておきたいのです。」

古参社員に相談するとき:

「長年○○さんとのやり取りでシステムが動いてきたことは分かっています。その上で、今後の体制について一緒に考えてほしいのですが、今の状況をどう感じていますか。」

いずれの言い回しにも共通しているのは、相手を非難する言葉を使わず、自社側の事情や今後の協力を求める姿勢を前面に出している点です。相手に「悪者にされた」と感じさせないことが、円満な引き渡しへの一番の近道です。

よくある失敗パターン

実際に承継後にベンダーとの関係整理を試みた経営者が陥りやすい失敗を、パターンとして整理しておきます。

• 感情を先に伝えてしまう: 「正直、対応に不満がある」という言葉が先に出てしまい、交渉が対立構造になる
• タイミングを誤る: 決算期や大きなシステム更新の直前に話を切り出し、相手に強い抵抗を生む
• 引き渡し条件を後回しにする: 関係を終える合意だけを先に取り、データやコードの引き渡し条件を後で交渉しようとして難航する
• 社内への説明を省く: 古参社員への説明を後回しにし、現場の協力が得られず移行が滞る
• 次の依頼先を決めずに解除を通告する: 移行先が決まらないまま契約終了を伝え、システムが止まるリスクを抱えたまま交渉することになる

これらはいずれも、「感情の整理」と「手続きの整理」を同時に、しかも順番を誤って進めたことが原因です。冒頭で述べた通り、この二つを意識的に分けて、契約確認→タイミング選定→伝え方→引き渡し条件の確認、という順番を守ることが、失敗を避ける最も確実な方法です。

まとめ:関係を終えることは関係を否定することではない

先代の代からの開発会社との関係を終えることは、先代の判断が間違っていたと否定することではありません。その時代、その規模の会社にとって、その関係は正しい選択だった可能性が高いのです。事業を承継したあなたが今、会社の規模や事業内容に合わせて次の体制を選ぶことは、経営者としての当然の役割です。

角を立てずに関係を終えるための要点を、最後にもう一度整理します。

1. 契約書を確認し、解除条項と契約形態(請負か準委任か)を把握する
2. 更新月の2〜3ヶ月前など、相手にとって不利にならないタイミングを選ぶ
3. 感謝を先に伝え、理由は自社の事業判断として説明する
4. 古参社員には決定前に相談の形で関わってもらう
5. データ・コード・運用知識の引き渡し条件を書面で確認する
6. 移行期間中のサポート内容を具体的に取り決める
7. 先代には事後報告ではなく、判断の経緯を先に共有する

株式や登記の引き継ぎには専門家がいますが、システムやベンダーとの関係については、多くの承継社長が一人で判断せざるを得ない状況にあります。だからこそ、この記事で示した手順を一つのチェックリストとして持っておくことが、感情に流されず、かつ相手への敬意を保ったまま、次の体制へ進むための助けになるはずです。