月曜の朝、社長室に届く一本の見積書
月曜の朝九時、後継社長の机には先週金曜の夜に届いた開発会社からの見積書が置かれている。件名は「基幹システム改修（追加要望対応）のお見積り」。金額を見た瞬間、思わず声が出そうになる。先代がこの開発会社と付き合い始めたのは十五年前だという。当時のシステムは今でも現場の在庫管理を支え、担当者は代替わりしても会社は変わっていない。だが後継社長にとっては、先代が築いた「あの会社に任せておけば大丈夫」という関係を、そのまま引き継ぐべきなのか、それとも自分の代でゼロから見直すべきなのか、判断がつかない。
先代は生前、事あるごとに「あの開発会社の社長には世話になった」と口にしていた。取引先の紹介で知り合い、創業期の資金繰りが苦しかった時期にも支払いを待ってもらった逸話まで残っている。だからこそ後継社長は、契約内容を精査して「この保守料は高すぎるのでは」と指摘することにすら、どこか罪悪感を覚えてしまう。先代の顔に泥を塗るのではないか、恩を仇で返すことにならないか。そうした感情が、本来なら当然行うべき条件交渉やベンダー評価の足を止めてしまうのだ。
一方で、経営者としての責任は別の重さで肩にのしかかる。保守料は年々上がっているのに、対応スピードは落ちている気がする。担当者に連絡しても「持ち帰って検討します」という返事が続き、システムの中身がどうなっているのか誰も説明してくれない。古参の総務部長は「先代の時代からずっとこの会社にお願いしてきたので、変えるという話は聞いたことがない」と言うばかりで、現場の従業員も新しいやり方に切り替えることに漠然とした不安を抱いている。後継社長は、先代の人間関係への敬意と、経営としての合理的判断のあいだで、身動きが取れなくなっている。
この状況は、事業承継を経験する多くの後継社長が通る道である。開発会社との関係は、単なる業務委託契約ではなく、先代の個人的な信頼関係の延長線上に成立していることが多い。だからこそ、契約を見直すという実務的な行為が、感情的には「先代を否定する行為」に変換されてしまう。しかし実際には、先代の顔を立てながら、開発会社との関係を長期的かつ健全な形に更新していくことは十分に可能であり、むしろそれこそが後継社長の重要な役割の一つである。
後継社長という立場の難しさは、経営としての合理性と、家族・地域・取引先という人間関係の網の目の両方を同時に背負わなければならないところにある。先代が存命であればなおのこと、先代の交友関係、取引先との義理、地域の商工会での立ち位置といった、決算書には表れない資産と負債の両方を、後継社長は無言のまま受け継いでいる。開発会社との関係もその一部であり、単純に「損得だけで判断すればいい」と割り切れるものではない。だが同時に、経営者としての責任は待ってくれない。保守料の上昇、対応品質の低下、システムの老朽化といった問題は、感情的な事情とは無関係に、確実に会社の利益とリスクに影響を与えていく。
本稿では、まずなぜこの問題が構造的に起こるのかを整理し、次に実際に承継後の企業で起きた三つの具体的な事例を紹介する。そのうえで、先代の顔を立てながら開発会社との関係を健全化するための実務的なステップと、チェックリストとして使える確認項目を提示する。さらに、この種の見直しでよくある三つの失敗パターン、そして後継社長からよく寄せられる質問への回答をまとめる。開発会社との関係は、契約書の一枚で完結する話ではなく、感情・人間関係・実務判断が絡み合う複合的な課題である。だからこそ、場当たり的に対応するのではなく、構造を理解した上で、順序を守って進めることが何より重要になる。
なぜ「先代の顔」が開発会社との関係を縛るのか
属人的信頼が契約書に落ちていない構造
中小企業と開発会社の関係が長期化すると、多くの場合、取引の実態は「契約書」ではなく「先代個人と担当者(あるいは開発会社の社長)個人の信頼関係」の上に成立するようになる。契約書自体は初回の基本契約書と、その後の個別の見積書・請求書だけで、業務範囲・保守内容・対応時間・費用の算定根拠といった重要事項が明文化されていないケースが非常に多い。先代が「あの人はよくやってくれるから」という理由で発注を続けてきた結果、口頭の約束や暗黙の了解が積み重なり、誰も文書化していない「非公式な取引条件」が形成されている。
この状態で先代が引退し、後継社長に経営がバトンタッチされると、後継社長は文書化されていない部分を読み取ることができない。見積書の内訳が粗い、保守範囲が曖昧、緊急対応の優先順位づけが不明確といった状況に直面しても、それが「先代の時代からの慣習」なのか「単に契約が甘いだけ」なのかを判別する手段がない。結果として、後継社長は「何か問題がある気がするが、指摘してよいものか分からない」という宙ぶらりんの状態に置かれる。これが、開発会社との関係を見直すことへの心理的ハードルを高める最初の構造要因である。
先代との関係が「取引」ではなく「恩義」として語られる
多くの後継社長が口にするのは、「先代がお世話になった会社だから」という言葉である。これは単なる感傷ではなく、実際に創業期や経営危機の際に、開発会社側が無理を聞いてくれた、支払いサイトを延ばしてくれた、休日対応をしてくれたといった具体的な出来事の積み重ねに基づいている場合が多い。こうした経験は先代にとって「恩義」として記憶され、その恩義は取引条件の見直しを妨げる強い抑止力として機能する。
後継社長がこの構造を理解せずに、単純に「コストが高いから」「対応が遅いから」という経営的合理性だけで契約見直しに動くと、古参の従業員や、場合によっては先代本人(存命であれば)から「恩を忘れたのか」という反発を受けることになる。逆に、この構造を理解した上で、恩義への敬意と契約の透明化を両立させるアプローチを取れば、周囲の理解を得ながら関係を健全化することができる。重要なのは、「関係を切る」ことと「関係を透明化する」ことは全く別の行為であり、後継社長がやるべきは基本的に後者だという認識を持つことである。
さらに厄介なのは、恩義の記憶が世代を経るごとに曖昧になっていくという点である。先代本人であれば「あのとき支払いを延ばしてもらった」という具体的な出来事を語れるが、後継社長がそれを聞くのは伝聞であり、開発会社の担当者がそれを語るのはさらに伝聞の伝聞である。具体的な事実がぼやけたまま、「とにかく世話になった会社だから大事にしなければ」という抽象的な感覚だけが残る。この抽象化された恩義は、実務的な検証を拒む一種の禁忌のように機能してしまい、後継社長が「なぜこの金額なのか」を確認することさえ、恩を軽んじる行為のように感じられてしまうのである。恩義そのものは否定すべきものではないが、それが具体的な事実を離れて抽象的な圧力になっているのであれば、後継社長は一度その恩義を具体的な出来事のレベルに分解し、「その恩義は今のどの取引条件に反映されるべきものなのか」を冷静に考える必要がある。
情報の非対称性が固定化されている
先代の時代に構築されたシステムは、多くの場合、開発の経緯や設計判断の理由が文書として残っていない。仕様書はあっても更新されておらず、実際の稼働システムとの差異が生じている。担当していた開発会社の担当者だけが、システムの全体像と過去の経緯を把握している状態、いわゆる「知識の一点集中」が起きている。
この状態で後継社長が「保守料の内訳を教えてほしい」「なぜこの改修にこれだけの工数がかかるのか説明してほしい」と尋ねても、開発会社側から専門用語を交えた説明が返ってくるだけで、経営判断に足る情報として理解できないことが多い。これは開発会社が意図的に情報を隠しているというより、単に「説明を求められる機会がこれまでなかった」ために、分かりやすく伝える準備ができていないケースがほとんどである。先代は長年の付き合いの中で「察する」ことができていたが、後継社長にはその蓄積がない。この情報の非対称性を放置すると、後継社長は永久に「言われた金額を払うだけの立場」に固定化されてしまう。
現場従業員が開発会社との関係を「変わらないもの」として認識している
古参の従業員、特に先代の時代から総務や情報システムを担当してきた社員は、開発会社との関係を「会社の一部」のように認識していることが多い。担当者の名前を下の名前で呼び、年末には互いに贈り物を交換し、システムのちょっとした不具合も電話一本で「いつもの感じ」で対応してもらう。こうした関係性は業務効率の観点では悪いことではないが、後継社長が関係を見直そうとした瞬間、現場従業員にとっては「自分たちが築いてきた関係性への介入」と受け取られやすい。
これは開発会社との関係の問題であると同時に、後継社長と古参社員との信頼構築の問題でもある。後継社長が「システムの契約を見直したい」と言った瞬間に、古参社員が「先代のやり方を否定するのか」と身構えてしまえば、そこから先の対話は難しくなる。逆に、古参社員が長年培ってきた開発会社との関係性を尊重する姿勢を見せつつ、あくまで「会社を守るための健全化」であることを伝えられれば、古参社員は後継社長の理解者になり得る。開発会社との関係見直しは、実は社内の人間関係構築と地続きの課題なのである。
契約更新のタイミングが構造的に「先送り」されやすい
多くの中小企業では、開発会社との契約は自動更新か、あるいは明確な更新タイミングを設けずに事実上継続している。見積書や請求書が定期的に発行されるだけで、契約条件そのものを見直す機会が制度として組み込まれていない。これは、先代の時代に「わざわざ見直す必要がない」という判断がされていたことの名残であり、後継社長が代替わりしても、その慣習がそのまま引き継がれてしまう。
後継社長からすれば、事業承継直後は取引先への挨拶回り、金融機関との関係構築、社内体制の整備など、優先すべき事項が山積みである。開発会社との契約見直しは「緊急ではないが重要」なタスクに分類されがちで、結果として何年も先送りされる。先送りが続くほど、「今さら見直すのは変だ」という心理的抵抗も強まり、いよいよ着手しづらくなる。この先送りの構造そのものが、問題を大きくしている最大の要因といえる。
加えて、開発会社側にも契約更新を積極的に持ちかけるインセンティブが乏しいという事情がある。既存の契約がそのまま継続すれば、開発会社にとっては安定した売上が確保でき、条件を見直すことでむしろ料金が下がる可能性すらある。開発会社が悪意を持って現状維持を望んでいるわけではないが、「向こうから言い出さないなら、こちらも言わなくていい」という均衡が双方の沈黙の中で自然に成立してしまう。この均衡を破るのは、基本的に発注側、つまり後継社長からの働きかけしかない。開発会社が自発的に「そろそろ契約を見直しませんか」と提案してくることは稀であり、後継社長がこの事実を理解していないと、「向こうから何も言ってこないのだから、今のままで問題ないのだろう」と誤って解釈し、さらに先送りを重ねてしまう。
ケーススタディで見る、承継後の開発会社との関係
ケース1:製造業の後継社長が保守料の内訳を初めて確認した事例
金属加工業を営むある企業では、先代が二十年前に受発注管理システムを開発会社に依頼して以来、同じ会社に保守を委託し続けていた。後継社長が就任して二年目、年間保守料が創業時の三倍近くになっていることに気づいた。担当者に理由を尋ねると「システムが古くなっているので、その分の対応コストが上がっている」という説明だったが、具体的な作業内容の提示はなかった。
後継社長は、先代の代からの付き合いを尊重しつつ、まずは「保守内容の可視化」を目的とした面談を申し入れた。感情的に「高すぎる」と切り出すのではなく、「経営者として保守料の内訳を正確に理解したい、今後の予算計画に必要なので教えてほしい」という実務的な依頼として伝えた。結果、開発会社側から作業ログの提示があり、実際には保守料の半分近くが、もはや使われていない旧機能のための待機コストであることが判明した。これは開発会社が悪意を持って過大請求していたわけではなく、単に長年見直しの機会がなかったために、不要な保守項目が積み残されていたのだった。
後継社長はこの結果を先代(顧問として会社に残っていた)に報告した際、「お前がちゃんと会社を見てくれている証拠だ、よくやった」という評価を受けた。先代自身も、内心では保守料の高さに疑問を持っていたが、長年の付き合いから言い出せなかったという。この事例が示すのは、後継社長が疑問を持つこと自体は、先代の顔を潰す行為ではなく、むしろ先代が言えなかったことを代わりに言語化する行為として受け止められる場合があるということである。重要なのは、伝え方が対立的ではなく、協力的な姿勢で行われたことである。承継社長が良い発注者であるために身につけたい習慣は、承継社長が良い発注者になるための7つの習慣にまとめている。
この事例をさらに深く見ると、後継社長が可視化を進める過程で、開発会社側の担当者も実は内心では説明に窮していたことが分かってきた。担当者自身、なぜ二十年前の設計をベースにした保守項目がそのまま残っているのか、社内で引き継がれた資料からは把握できていなかったのである。つまりこのケースは、開発会社が意図的に不透明にしていたわけではなく、双方が「聞かれないから答えない」「聞かないから分からない」という状態のまま長年を過ごしてしまった結果だった。後継社長が最初の問いを発したことによって、開発会社側も自社の保守業務を棚卸しする機会を得られ、結果的に開発会社にとってもプラスの効果があったと後日担当者から感謝の言葉があったという。この後継社長は、保守料の圧縮によって浮いた予算の一部を、システムの現代化に充てる提案を新たに行い、開発会社との関係はむしろ以前より活性化した。
ケース2:食品卸業で開発会社の担当者変更をきっかけに関係が悪化した事例
食品卸業を営む企業では、先代の時代から二十五年にわたり同じ開発会社に発注していたが、その関係を実質的に支えていたのは、特定の担当者一人だった。その担当者は先代の右腕的な存在で、会社のシステムのあらゆる経緯を把握していた。しかし後継社長が就任してから一年後、その担当者が開発会社を退職し、別の担当者に引き継がれた。
新しい担当者は熱心ではあったものの、システムの経緯を十分に理解しておらず、簡単な改修依頼に対しても「調査に時間がかかる」という回答が続いた。後継社長は当初、これを「開発会社の質が落ちた」と判断し、他社への切り替えを検討し始めた。しかし詳しく調べると、そもそも先代の時代から仕様書がほとんど整備されておらず、退職した担当者の頭の中にしか存在しない情報が大量にあったことが分かった。つまり問題の本質は開発会社の能力ではなく、自社側が長年「担当者依存」の体制を放置してきたことにあった。
後継社長はここで方針を切り替え、開発会社に「担当者が誰であっても対応できるよう、仕様書とシステム構成図を整備してほしい」と依頼した。これは開発会社にとっても本来望ましい提案であり、双方の合意のもとでドキュメント整備が進められた。担当者の交代自体に後継社長がどう向き合うべきかは、開発会社の担当者交代、後継社長が引き継ぎで確認すべきことで詳しく解説している。結果として、開発会社を切り替えることなく、関係を維持しながら再発防止策を講じることができた。この事例が示すのは、開発会社との関係に問題が生じたとき、それが「会社を変える理由」なのか「関係を整備する理由」なのかを冷静に見極める必要があるということである。安易な切り替えは、既存のシステムの経緯を知る唯一の窓口を失うリスクを伴う。
後継社長は当初、他社への切り替えを検討していた段階で、実際に二社から提案を受けていた。しかし提案を精査する過程で、いずれの会社も「まずは現行システムの調査だけで数ヶ月、相応の費用が必要」という前提を置いていることが分かった。長年蓄積されたシステムの経緯を、外部の新しい会社がゼロから理解し直すことのコストは決して小さくない。この現実を踏まえた上で、後継社長は「担当者個人への依存」という本質的な課題を解決する方向に方針を転換した。もし当初の勢いのまま他社に切り替えていたら、移行コストと混乱がさらに大きくなっていた可能性が高い。この事例からは、開発会社への不満が生じた際、感情的な反応で即座に切り替えを決断するのではなく、まず問題の所在を正確に特定することの重要性が読み取れる。古参社員も、この過程で仕様書整備に協力し、結果的に社内のシステム理解も深まるという副次的な効果も生まれた。
ケース3:建設関連業で先代同席のもと契約を見直した事例
建設関連の設備工事業を営む企業では、後継社長が就任して三年目に、開発会社との契約を全面的に見直す決断をした。きっかけは、システムの一部がクラウド移行の対象から漏れていて、他の取引先とのデータ連携がうまくいかない事態が続いたことだった。開発会社に相談したところ、対応には相応の追加費用が必要だという回答があり、後継社長はこれを機に契約全体を見直したいと考えた。
このとき後継社長が取った方法は、先代を交渉の場に同席させることだった。先代はすでに経営から退いていたが、開発会社の社長とは今でも個人的な付き合いが続いていた。後継社長は先代に、「これから契約内容の見直しについて話をするが、あくまで会社の将来のための話であり、これまでの関係への感謝は変わらない」という趣旨を事前に伝え、同席をお願いした。実際の交渉の場では、先代がまず開発会社の社長に長年の感謝を伝え、その後、後継社長が具体的な見直し内容を説明するという流れで進めた。
この進め方によって、開発会社側も「関係を切られるのではなく、次の世代に合わせて更新されるのだ」という受け止め方をすることができ、交渉は円滑に進んだ。最終的に、保守範囲の明確化、対応時間の目安の設定、費用算定根拠の開示という三点について合意書を新たに作成することができた。この事例の教訓は、契約見直しという実務的な作業に、先代という象徴的な存在を「橋渡し役」として活用することで、感情的な軋轢を最小化できるという点である。すべての企業で先代が同席可能とは限らないが、可能な場合は非常に有効な手段となる。
この後継社長は交渉の場を設ける前に、社内でも準備を重ねていた。総務担当の古参社員に事前に相談し、これまでの取引の中で気になっていた点、逆に評価している点をヒアリングしてから交渉に臨んだという。結果、古参社員からは「対応が遅いと感じることはあるが、無理な要望にも応えてくれることが多く、総合的には満足している」という意見が出され、これが交渉の中で「切る」ではなく「整える」という方向性を選ぶ根拠の一つになった。また、開発会社の社長も、先代との個人的な関係を後継社長にも引き継ぎたいという意向を持っていたことが交渉の中で明らかになり、双方にとって望ましい形で契約が更新された。この事例は、後継社長が一人で全てを決めるのではなく、社内外の関係者から事前に情報を集めた上で交渉に臨むことの有効性を示している。
実務対応のステップとチェックリスト
先代の顔を立てながら開発会社との関係を健全化するためには、感情面への配慮と、実務面での手順を分けて考える必要がある。以下、段階を踏んで進めるべき実務対応を整理する。
ステップ1:現状の契約・取引実態を可視化する
まず最初にすべきことは、現在開発会社とどのような契約関係にあるのか、書面として何が残っているのかを確認することである。基本契約書、業務委託契約書、保守契約書、過去数年分の見積書・請求書を一箇所に集め、記載内容を整理する。この作業自体は開発会社に何かを尋ねる必要がなく、社内だけで完結できるため、心理的な負担が少ない最初の一歩として適している。
- 基本契約書・個別契約書の有無と内容を確認する。契約書が存在しない、または古い契約書しかない場合は、その事実自体を記録しておく。
- 過去三年分程度の請求書を並べ、金額の推移と内訳の変化を確認する。金額が上昇している場合、その理由が明記されているかを確認する。
- 保守範囲(対応時間、対応内容、緊急時のエスカレーション先)が文書化されているかを確認する。
- 誰が実際の窓口担当者で、その担当者が退職・異動した場合の引き継ぎ体制がどうなっているかを確認する。
- 現在稼働しているシステムの構成図・仕様書が最新の状態を反映しているかを確認する。
この段階では、開発会社を批判する目的ではなく、単に「自社が何を契約しているのかを正確に把握する」ことが目的である。多くの後継社長は、この可視化作業を行うだけで、これまで漠然と感じていた不安の正体が具体的な課題として見えてくる。
可視化の作業は、できれば経理担当者や総務担当者など、実務に近い社員と一緒に行うことが望ましい。後継社長一人だけで書類を読み解こうとすると、業界特有の用語や過去の経緯が分からず、正確な理解に至らないことがある。一方で、古参社員だけに任せてしまうと、長年の慣習に染まった視点からしか状況を評価できず、問題点に気づきにくいこともある。後継社長自身が「素朴な問い」を投げかけながら、古参社員の知識を借りて整理していくという協働の形が、最も実効性が高い。この段階で分かった事実は、感情を交えずに、単純な表としてまとめておくと、後の対話や交渉の場でも冷静な資料として使うことができる。
ステップ2:先代に「見直しの目的」を事前に共有する
先代が存命かつ会社との関わりが残っている場合、契約見直しに着手する前に、目的を丁寧に共有しておくことが重要である。ここで大事なのは、「先代の判断が間違っていた」というニュアンスを一切含めないことである。あくまで「時代が変わり、会社の規模やシステムの使い方も変わってきたので、今の実態に合わせて更新したい」という説明に徹する。
- 先代に「開発会社との関係を切るつもりはない」ことを明確に伝える。
- 先代がこれまで開発会社に感じてきた恩義や感謝を、後継社長自身も引き継ぐ意思があることを伝える。
- 見直しの目的が「コスト削減」だけではなく、「経営としての説明責任を果たすため」「次の担当者が誰であっても対応できる体制を作るため」といった、会社の持続性のための取り組みであることを伝える。
- 可能であれば、先代に交渉や説明の場への同席、あるいは事前の一声を依頼する。
この共有を怠ると、後継社長が開発会社と直接交渉した内容が、先代の耳に間接的に(古参社員経由や開発会社経由で)伝わり、「相談もなく話を進めた」という不満につながることがある。先に共有しておくことで、こうした事後的なトラブルを防ぐことができる。
先代への共有の仕方も重要である。改まった場を設けて「これから契約を見直します」と宣言のように伝えると、先代によっては身構えてしまうこともある。むしろ日常の会話の延長で、「最近システムの契約内容を整理していて、いくつか確認したいことが出てきた」という軽いトーンで切り出し、先代の反応を見ながら徐々に本題に進めていく方が、自然に受け入れられやすい。先代が具体的な懸念や思い出を語り始めたら、それをしっかりと聞く時間を取ることも大切である。先代にとって、開発会社との関係は単なる業務上の付き合いではなく、経営者として苦労した時代の記憶と結びついている場合が多く、その記憶を丁寧に扱うことが、結果的に見直しへの理解を得る近道になる。
ステップ3:開発会社との対話を「感謝」から始める
実際に開発会社との対話に入る際は、いきなり契約条件の話に入るのではなく、まず感謝を明確に言葉にすることが有効である。長年支えてもらったことへの感謝を伝え、その上で「今後も長く付き合っていきたいからこそ、いくつか確認させてほしいことがある」という文脈で本題に入る。この順序を守るだけで、開発会社側の受け止め方が大きく変わる。
- 対話の冒頭で、先代の時代からの支援に対する感謝を具体的に述べる。
- 「関係を見直す」ではなく「関係を次の世代に合わせて更新する」という言葉を使う。
- 質問は批判ではなく確認の形で行う。「なぜこんなに高いのか」ではなく「内訳を教えてほしい、今後の予算計画のために正確に理解したい」という聞き方にする。
- 一度の対話で全てを決めようとせず、複数回に分けて段階的に進める。
- 対話の最後には、次回までに双方が準備すべき事項を確認し、宿題を明確にしてから終える。
対話の場は、できれば対面で設定することが望ましい。メールや電話だけでのやり取りは、文面や声のトーンから意図が伝わりにくく、些細な言い回しが誤解を招くことがある。対面であれば、後継社長の表情や態度から「敵対的ではない」という空気を伝えることができ、開発会社側も安心して率直な情報を出しやすくなる。また、複数回に分けて進めることで、開発会社側にも社内で情報を整理する時間を与えることができ、次回の対話までにより正確な回答を用意してもらえる可能性が高まる。急いで一度に結論を出そうとすると、開発会社側が防衛的な回答に終始してしまい、本来得られるはずの有益な情報が引き出せなくなることがある。
ステップ4:契約条件を文書化し、双方合意のもとで更新する
対話を通じて課題が明らかになったら、それを口頭の約束のままにせず、必ず文書として残す。これは開発会社を疑っているからではなく、後継社長自身の代、そしてその次の代に引き継ぐための資産づくりである。
- 保守範囲、対応時間、費用算定根拠を明記した保守契約書を新たに作成、または既存の契約書を更新する。
- 緊急時のエスカレーション先と対応の優先順位を明文化する。
- システムの仕様書・構成図の整備を、開発会社との共同作業として計画に組み込む。
- 更新した契約内容を、開発会社の担当者だけでなく、その上司や経営層とも共有し、担当者変更時にも引き継がれる体制を作る。
- 契約内容の見直しを定期的に行う仕組み(たとえば年一回のレビュー機会)をあらかじめ設定しておく。
- 見直しの過程で判明した「暗黙のルール」(たとえば特定の時期は対応を避けてほしい、特定の担当者経由でないと話が通らないなど)も、可能な範囲で文書に反映しておく。
文書化にあたっては、いきなり分厚い契約書を作ろうとせず、まずは簡潔な確認書やメモの形で合意事項を残すところから始めても構わない。重要なのは形式の立派さではなく、双方が合意した内容が、記憶や口頭の約束に依存せず、後から誰が見ても分かる形で残っているかどうかである。契約更新の前に開発会社から具体的に何を受け取っておくべきかは、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。特に、費用算定の根拠については、後継社長だけでなく、将来その会社を引き継ぐ次の世代や、経理を担当する社員が見ても理解できる粒度で記載しておくことが望ましい。開発会社によっては、社内フォーマットの契約書テンプレートを持っている場合もあるため、こちらから項目を提示しつつ、開発会社側の標準的な形式も参考にしながら、双方にとって運用しやすい文書を作成するとよい。
ステップ5:社内(古参社員・現場)への説明を行う
契約内容が更新された後は、社内の古参社員や現場の従業員にも、その経緯と内容を分かりやすく共有する。ここでも「変える」という表現ではなく「整える」「引き継ぐ」という表現を使うことが望ましい。
- 古参社員に対しては、先代の時代からの関係性への敬意を示しつつ、変更の目的を丁寧に説明する。
- 現場の従業員に対しては、実務上の変更点(対応窓口や対応時間の変化など)があれば、具体的に伝える。
- 開発会社側の担当者が変わる予定がある場合は、事前に周知し、混乱を防ぐ。
- 質問や不安の声が出た場合は、個別に丁寧に対応する場を設ける。
- 見直しによって現場の日常業務にどのような変化があるのか(あるいは変化がないのか)を明確に伝え、不要な不安を残さないようにする。
社内説明の場では、後継社長が一方的に説明するだけでなく、古参社員からの質問や意見を受け止める時間を十分に確保することが望ましい。特に、長年開発会社とのやり取りの窓口を担ってきた社員にとっては、契約内容の変更が自分の役割そのものに影響するのではないかという不安を抱きやすい。後継社長は、その社員がこれまで担ってきた役割の価値を明確に認め、見直し後も引き続き重要な役割を担ってもらいたいという意思を伝えることで、不安を和らげることができる。逆にこの説明を省略すると、古参社員は「自分は蚊帳の外に置かれた」と感じ、その後の協力が得られにくくなるおそれがある。
よくある失敗パターン
失敗パターン1:感情を避けて事務的に進めすぎる
後継社長の中には、「感情的な話は避けて、契約は契約として事務的に進めるべきだ」と考える人もいる。合理的な判断としては理解できるが、これは古参社員や、場合によっては先代自身の反発を招くことがある。開発会社との関係は、単なる契約書上の取引ではなく、長年にわたる人間関係の蓄積であり、その蓄積を無視して事務的な文書だけで進めようとすると、「会社を私物化している」「先代を軽視している」という印象を与えてしまう。実際には、事務的な正確さと、感情への配慮は両立できる。文書化を進めながらも、対話の場では感謝や敬意をしっかりと言葉にすることが、円滑な見直しのために欠かせない。事務処理を急ぐあまり、この順序を省略してしまうことが、最も多い失敗の一つである。この失敗パターンに陥りやすいのは、特に経営コンサルタントや士業から助言を受けて契約見直しに着手した後継社長である。専門家の助言は実務面では正しいことが多いが、そこには長年の人間関係という変数が織り込まれていないことがある。専門家の指摘を鵜呑みにして、そのまま事務的な通知文を送るような進め方をすれば、開発会社側も身構えてしまい、本来得られたはずの協力的な関係が損なわれてしまう。専門家の助言は「何を確認すべきか」の参考にしつつ、「どう伝えるか」は後継社長自身が、自社と開発会社との関係性を踏まえて判断する必要がある。
失敗パターン2:先代に何も伝えずに水面下で進めてしまう
もう一つ多い失敗は、先代との軋轢を避けようとするあまり、先代に何も相談せず、開発会社との交渉を水面下で進めてしまうケースである。後継社長としては「余計な心配をかけたくない」「自分の判断で決めたい」という思いがあるのかもしれないが、結果として後から先代がその事実を知ったとき、「なぜ相談してくれなかったのか」という不信感を生むことになる。特に先代が今も顧問や相談役として会社に関わっている場合、この不信感は経営全体への信頼にも影響しかねない。先代への説明は「許可を取る」ためではなく「経緯を共有する」ためのものであり、この二つを混同しないことが重要である。後継社長が独立して判断する権利は当然あるが、それとは別に、先代への敬意としての情報共有は分けて考えるべきである。水面下で進めた結果、開発会社の社長が先代に「最近、後継社長さんから契約の見直しの話がありまして」と世間話のついでに触れてしまい、先代がそこで初めて事実を知るという事態も実際に起きている。このとき先代が受ける衝撃は、見直しの内容そのものよりも、「自分が知らないところで話が進んでいた」という事実そのものに向けられる。後継社長からすれば些細な配慮の欠如に過ぎなくても、先代にとっては経営の一線から退いたことを改めて突きつけられる出来事として重く受け止められることがあり、その後の関係修復に時間がかかるケースも見られる。
失敗パターン3:見直しを一度きりのイベントとして終わらせてしまう
契約の見直しに成功した後継社長の中には、それを「一度やったから終わり」と考えてしまう人もいる。しかし開発会社との関係は、担当者の変更、事業内容の変化、システムの老朽化など、時間の経過とともに再び不透明になっていく性質を持つ。一度契約を明文化しても、それを定期的に見直す仕組みを作らなければ、数年後には再び同じ問題が繰り返される。実際、過去に契約を整理したにもかかわらず、その後の見直しの機会を設けなかった結果、担当者が入れ替わってから再び保守内容が不透明になってしまったという相談は少なくない。見直しは一度きりのイベントではなく、年に一度など定期的なレビューの仕組みとして組み込むことが、長期的な関係の健全性を保つために欠かせない視点である。定期レビューを組み込む際は、大がかりな見直しを毎年繰り返す必要はなく、たとえば「保守料の内訳を確認する」「対応時間の実績を確認する」「システム構成図が最新の状態と一致しているかを確認する」といった、短時間で済む簡易チェックを年に一度のルーティンとして設定するだけでも十分な効果がある。重要なのは、見直しの機会そのものを組織の仕組みとして残すことであり、それがあれば後継社長が代替わりしても、次の世代がゼロから同じ苦労を繰り返す必要がなくなる。
よくある質問
先代がまだ経営に関与している場合、契約見直しの主導権は誰が持つべきですか。
原則として、現在の経営者である後継社長が主導権を持つべきである。ただし、先代がまだ会社に関与している場合は、事前の説明や場合によっては交渉への同席という形で協力を仰ぐことが有効である。主導権を持つことと、先代の理解や協力を得ることは矛盾しない。むしろ両方を実現することで、社内外からの理解を得やすくなる。先代に相談することは、決して後継社長の判断力が不十分であることを意味しない。むしろ、経営権の移行期においては、先代の持つ人間関係の資産を最大限に活用しながら、実務的な判断は後継社長自身が下すという分業を明確にすることが、双方にとって最も納得感のある進め方になる。時間が経ち、先代が完全に経営から離れた後は、この協力を仰ぐ工程は自然と不要になっていくため、あくまで承継期に特有の配慮と捉えておくとよい。
開発会社に契約見直しを申し出ると、関係が悪化するのではと不安です。
多くの開発会社は、長年の取引先からの正当な確認や見直しの申し出を、関係悪化の要因として受け止めることはない。むしろ、経営者が変わったタイミングで契約内容を確認し合うことは自然な流れであり、健全な取引関係の一部として受け入れられることが多い。関係悪化を招くのは、見直しの申し出そのものではなく、伝え方が一方的・批判的である場合である。感謝を伝えた上で、今後も長く付き合いたいという意思を明確にすれば、多くの場合は良好に進む。開発会社の立場から見れば、経営者が代替わりした後も取引が継続するかどうかは大きな関心事であり、後継社長からの丁寧な申し出は、むしろ「この会社とは長く付き合っていける」という安心材料として受け止められることも少なくない。不安に思う気持ちは自然なものだが、その不安の多くは実際にやってみると杞憂に終わるケースが大半である。
古参社員が開発会社との関係変更に強く反対しています。どう対応すべきですか。
古参社員の反対は、多くの場合、開発会社そのものへの思い入れというよりも、「これまで築いてきた関係が壊されるのではないか」という不安から来ている。対応としては、変更の目的が関係を壊すことではなく、次の世代に引き継ぐために整えることであると丁寧に説明し、古参社員自身がこれまで築いてきた関係性への敬意を明確に示すことが有効である。可能であれば、契約見直しの過程に古参社員を関与させ、当事者として参加してもらうことも、反対を和らげる効果がある。
契約書がそもそも存在しない場合、どこから手をつければよいですか。
契約書が存在しない場合は、まず現状の取引実態(発注の流れ、支払い条件、対応範囲)を書面として整理することから始める。開発会社に対しては、「これまでの経緯を正式な文書として残したい」という前向きな趣旨で、契約書の作成を提案するとよい。契約書がなかったこと自体を問題視するのではなく、今後のために整備するという姿勢で進めることが、開発会社との関係を損なわずに進めるための鍵となる。長年契約書なしで取引が続いてきたという事実は、裏を返せば、それだけ大きな問題が起きずに信頼関係だけで運用できてきたことの証でもある。その実績を否定せず、「これまでうまくやってきたからこそ、次の世代にもこの関係を安心して引き継げるように、形にしておきたい」という前向きな言葉で提案すれば、開発会社側も抵抗なく協力してくれることが多い。
まとめ
先代から会社を引き継いだ後継社長にとって、開発会社との関係は単なる業務委託の問題ではなく、先代が築いた人間関係と、経営者としての合理的判断のあいだで揺れる、感情的にも実務的にも難しい課題である。しかし、契約を見直すことと、先代の顔を潰すことは本質的に別の行為である。恩義への敬意を保ちながら、契約内容を可視化し、対話を感謝から始め、合意を文書として残し、社内にも丁寧に共有する。この一連のステップを踏むことで、後継社長は先代の遺した関係性を否定することなく、むしろその関係性を次の時代にふさわしい形へと引き継いでいくことができる。開発会社との関係は、一度整えれば終わりではなく、定期的な見直しを組み込むことで初めて長期的に健全なものとなる。先代への敬意と、経営としての説明責任は、決して対立するものではない。両方を同時に大切にする姿勢こそが、事業承継後の後継社長に求められる、開発会社との付き合い方の本質である。
月曜の朝に届いた見積書を前に立ち止まっていた後継社長も、最終的にはこの構造を理解し、一つずつ手順を踏んでいくことで、開発会社との関係を自分の代のものとして再構築していくことができる。承継1年目、古参の情シス担当・総務担当とどう関係を作るかについては、古参の情シス担当・総務担当と、1年目にどう関係を作るかも参考にしてほしい。最初の一歩は、決して開発会社に電話をかけることでも、先代に直談判することでもない。まずは自社の契約書と請求書を机の上に並べ、静かに現状を確認することから始まる。そこから見えてくる事実こそが、感情に振り回されずに次の一手を判断するための、最も確かな足がかりとなる。先代が築いた関係を土台にしながら、後継社長自身の目で会社の実務を見直していくその姿勢自体が、開発会社にとっても、社内の従業員にとっても、次の時代の経営者として認められていく過程そのものなのである。
