先代の代からの開発会社の返信が遅い。関係が壊れる前にできる対処
「基幹システムの画面が固まって動きません」とメールを送ったのが月曜の朝だった。返事が来たのは水曜の夕方。「確認します」という一文だけで、実際の対応が始まったのは金曜だった。その間、現場は紙の帳票と電話で受発注を回し続けた。承継してまだ半年のあなたは、この光景を何度も見ている。先代の時代からの開発会社は、たしかに社歴が長く、社内のどのシステムがどう繋がっているかを一番よく知っている。しかし、その関係の中身をよく見ると、返信までの時間が年々延びていることに気づく。以前は半日で返ってきたメールが、今は2日、3日かかる。電話をしても「担当者が席を外している」で終わる。チャットツールを提案しても「うちはメールでお願いします」と断られる。
先代は生前、この会社を「昔からの付き合いだから」と評していた。実際、創業当初からの縁で、価格も相場より安く、無理を言えば多少は聞いてくれる。だからこそ、後継社長であるあなたは、この関係にメスを入れることに強い抵抗を感じている。ベンダーを変えれば、システムの中身を知る人間がいなくなる。古参社員からは「先代が大事にしてきた会社なのに」と言われるかもしれない。だが、返信が遅いという事実は、日々の業務の中で確実に組織の生産性を削っている。トラブル対応が遅れれば現場の不満が募り、それがやがて後継社長自身への不信につながっていく。この記事では、なぜ先代の代からの開発会社の返信が遅くなるのか、その構造を整理し、関係を断ち切らずに改善する実務的な手順を示す。
なぜ「先代の代からの開発会社」ほど返信が遅くなるのか
返信の遅さは、単に「その会社が不真面目だから」という個人的な資質の問題として片付けられがちだが、実際にはもっと構造的な原因が積み重なっている。承継後の後継社長がこの構造を理解しないまま担当者個人を責めても、関係は改善しない。むしろ角が立って余計にこじれる。まず、この構造を丁寧に分解しておく必要がある。
優先順位の中で埋没しているという構造
開発会社にとって、既存の古い取引先はどうしても優先順位が下がりやすい。理由は単純で、新規の商談や大型案件のほうが売上への貢献度が高く見えるからだ。先代の時代に契約した保守契約は、契約時の金額のまま何年も更新されず、当時のシステム規模に対しては適正だった保守料が、今のシステム規模や問い合わせ頻度に対しては割安になっていることが多い。担当者からすれば、割安な既存契約への対応より、単価の高い新規案件を優先するインセンティブが働く。これは担当者の性格や誠意の問題ではなく、開発会社という組織の中での案件の重み付けの問題だ。後継社長が「なぜ対応が遅いのか」と担当者個人を問い詰めても、担当者自身が上長からそのように優先順位を指示されている場合、個人の裁量では変えられない。
さらに、多くの中小の開発会社は、案件を抱える担当者一人あたりの許容量が限られている。ベテラン担当者ほど多くの取引先を抱え、新規案件にも呼ばれる。先代の代からの長い付き合いの会社ほど、担当者が独立採算的に多くの顧客を持つベテランであることが多く、結果としてその担当者のスケジュールは常に埋まっている。返信が遅いのは、悪意ではなく単純な物理的なキャパシティ不足であるケースが非常に多い。
属人化した情報が「この人に聞かないと分からない」を生む
先代の時代から続くシステムは、多くの場合、仕様書やドキュメントが整備されておらず、担当者の頭の中に知識が蓄積されている。この状態を放置していると、担当者は「自分が対応しないと会社が困る」という認識を持つ一方で、「自分にしか分からないから、じっくり考える時間が必要だ」という言い訳も同時に成立してしまう。属人化は、対応の遅さを正当化する土壌にもなる。後継社長からすれば「すぐ分かるはずなのに、なぜ即答してくれないのか」と感じる場面でも、担当者本人は本当に思い出す作業に時間がかかっている可能性がある。これは決して大げさな話ではなく、10年以上前に作られたシステムの改修履歴や設定変更の記録が残っていない開発会社は珍しくない。
この属人化構造の厄介な点は、後継社長にとって「関係を変えたくても変えられない」という縛りを生むことだ。担当者を切り替えてもらいたくても、その担当者しかシステムの全体像を知らないため、切り替えれば対応がさらに遅くなるリスクがある。結果として、多少の不満があっても現状維持を選び続け、返信の遅さがどんどん常態化していく。
契約形態が「対応の速さ」を保証していない
保守契約や運用委託契約の多くは、月額いくらで何時間まで対応する、あるいは何回まで問い合わせに応じる、という枠組みで結ばれている。しかし、先代の時代に結ばれた契約書を読み返すと、対応時間や返信までの目標時間(いわゆるレスポンスタイムやSLA)が明記されていないことが非常に多い。「障害発生時は速やかに対応する」といった曖昧な文言だけで、「速やか」が具体的に何時間を指すのか誰も定義していない。契約に速さの基準がなければ、開発会社側にとって「遅い」という状態は契約違反ではなく、単なる印象の問題にすぎない。後継社長が「対応が遅い」とクレームを入れても、開発会社側は「契約上は問題ない」という立場を取れてしまう。
この契約の曖昧さは、先代がその開発会社を信頼しきっていたために、細かい条件を詰めずに口約束や慣習で運用してきた結果であることが多い。先代の時代は経営者同士の人間関係で対応の速さが決まっていた面もあり、契約書に明文化する必要性を誰も感じなかった。しかし、経営者が代わり、人間関係の蓄積がリセットされた今、口約束に依存した運用は簡単に崩れる。後継社長との関係はまだ浅く、先代のときのような「頼めば無理してくれる」関係性が薄れているため、契約書に書かれていない部分では優先度が下がりやすい。
承継直後は「様子見」の期間になっている
開発会社側の視点に立つと、経営者が代わった直後は、その開発会社にとっても不安な時期だ。新しい社長が自社との契約を継続してくれるのか、それとも見直しをして他社に切り替えるのか、様子を見ている期間でもある。この様子見の間、開発会社は積極的に関係を深めるための提案や大掛かりな改善提案を控える傾向がある。下手に提案して「余計なことをするな」「費用が増えるだけだ」と拒絶されるリスクを避けたいという心理が働くためだ。結果として、必要最低限の対応にとどめ、それが後継社長からは「以前より対応が薄くなった」「返信が遅くなった」という印象につながる。
これは開発会社側の消極性の表れであると同時に、後継社長がまだ自社の方針を明確に伝えていないことの結果でもある。承継直後にどのような関係を望むのか、後継社長自身がまだ言語化できておらず、開発会社側も何を基準に動けばいいのか分からないという、双方の不確実性が重なった状態だ。この状態を放置すると、双方が様子見を続けたまま、対応の質は徐々に劣化していく。
「昔からの付き合い」という言葉が改善提案を止めている
古参社員や先代自身が「昔からの付き合いだから」と繰り返し口にすることが、実は改善の機会を潰していることがある。後継社長が対応の遅さに疑問を持ち、契約内容を見直そうとした瞬間、「先代がお世話になった会社に失礼だ」という空気が社内から発生する。この空気を恐れて、後継社長は問題を指摘すること自体を控えるようになる。結果、開発会社側には何のフィードバックも届かず、対応の遅さが放置され続ける。開発会社にとっても、クレームが来ないということは「今のままで問題ない」というメッセージに等しい。後継社長の遠慮が、意図せず現状維持を強化してしまうという悪循環が生まれる。
ケーススタディで見る典型パターン
ここまでの構造的な説明を、実際に起こりやすい3つの場面に当てはめて見ていく。いずれも中小企業の承継の現場で繰り返し見られるパターンであり、後継社長が「これは自分の会社だけの問題ではない」と認識するための参考にしてほしい。
ケース1 障害対応が「まず確認します」で止まる会社
製造業を営むある企業では、先代の時代から受発注システムの保守を地元の開発会社に委託していた。あるとき、システムの検索機能が正常に動かなくなり、営業担当者が受注データを目視で探すはめになった。後継社長はすぐにメールで状況を伝えたが、返ってきたのは「確認いたします。分かり次第ご連絡します」という一文だけで、いつまでに分かるのかという見通しが示されなかった。翌日になっても連絡がなく、電話をかけると担当者が外出中で、代わりに出た事務員も状況を把握していなかった。結局、原因が判明し修正が完了するまで4日を要し、その間、営業部門は手作業での受注管理を強いられた。
後日、後継社長がこの一件を振り返ったところ、契約書には「障害発生時は速やかに対応する」としか書かれておらず、初回応答までの時間や原因調査の目標時間が定義されていないことが分かった。開発会社側からすれば、4日かけて修正したことは契約上の義務を果たした結果であり、遅いという指摘自体が想定外だった。この事例が示すのは、後継社長の感覚での「遅い」と、開発会社の契約上の「問題ない」が、そもそも異なる基準で測られているという事実だ。感覚のズレを解消するには、まず両者が共有できる具体的な数字の基準を作る必要がある。こうした場面で感情的にならずに交渉を進める技術は、トラブル時の交渉術。感情的にならずに解決するで詳しく取り上げている。
ケース2 担当者の異動でノウハウが引き継がれず対応が遅くなった会社
ある小売業の企業では、先代の代から20年近く同じ担当者がシステムを見てきたが、その担当者が開発会社の中で異動し、後任に引き継がれた直後から、対応のスピードが目に見えて落ちた。後任の担当者はシステムの構造を一から理解する必要があり、簡単な問い合わせにも「一旦社内で確認します」という返答が続くようになった。後継社長は最初、後任者の能力を疑ったが、実際には引き継ぎ資料がほとんど存在せず、後任者自身が過去の改修履歴を追いかけながら対応していたことが判明した。
この会社が取った対応は、開発会社に対して過去の改修履歴・設定変更履歴・仕様書の提出を正式に依頼することだった。当初、開発会社側は「そこまでの資料は作成していない」と難色を示したが、契約更新のタイミングと合わせて、今後の保守契約に「主要な改修内容は都度ドキュメント化する」という条項を加えることで合意した。結果として、資料が整うまでの数か月は対応の遅さが続いたものの、その後は担当者が変わっても一定の品質で対応が継続する体制に近づいた。この事例は、返信の遅さの原因が担当者個人ではなく、情報の引き継ぎ不備にあった典型例であり、対処の焦点を「人」ではなく「情報」に当てることの重要性を示している。
ケース3 遠慮を続けた結果、現場が独自の裏ルートを作ってしまった会社
建設関連の企業では、後継社長が開発会社への不満を口にしないまま数年が経過し、現場の担当者たちが独自の対処法を作り出してしまった。具体的には、システムが不具合を起こしたときに正規の問い合わせ窓口を通さず、開発会社の担当者の個人の携帯電話に直接連絡するという運用が、いつの間にか社内の暗黙のルールになっていた。この裏ルートは一時的には対応が早く感じられたが、担当者が休暇や出張で電話に出られないときには完全に機能不全になり、しかも正規の問い合わせ記録が残らないため、後継社長は自社のシステムに何が起きているかを正確に把握できない状態が続いていた。
後継社長がこの実態を知ったのは、担当者の携帯電話が長期間つながらなくなり、現場が完全にお手上げになった事件がきっかけだった。この一件を受けて、後継社長は正規の問い合わせ窓口を再整備し、現場に「今後は必ず窓口経由で連絡すること」を周知した上で、開発会社側にも「窓口を経由しない対応はしないでほしい」と申し入れた。この事例が示すのは、後継社長が問題を放置している間に、現場が現場なりの解決策を作り出してしまうリスクだ。その裏ルートは表面的には便利に見えても、組織としての管理を失わせ、後継社長の目の届かないところで関係が変質していく危険性を持つ。
実務対応のステップとチェックリスト
ここからは、実際に何をすればよいかを、順を追って整理する。関係を断ち切ることを前提とせず、まずは改善の余地を探るという立場で書く。段階を踏まずに一気に強い態度で臨むと、長年の関係が一気に壊れるリスクがあるため、順番を守ることが重要だ。
ステップ1 現状を客観的な記録として残す
最初にやるべきことは、感覚ではなく記録に基づいて現状を把握することだ。「最近対応が遅い気がする」という印象だけでは、開発会社との交渉においても、社内での意思決定においても説得力を持たない。
- 過去3か月から半年分の問い合わせと、それに対する初回返信までの時間、解決までの時間を一覧化する。メールの送受信時刻を並べるだけでも十分な資料になる
- 障害の内容と重要度(業務が完全に止まったか、一部の機能だけの不具合だったか)を分けて記録する。重要度が高い障害への対応が遅いのか、日常的な問い合わせ全般が遅いのかで、次の対応が変わる
- 対応してくれた担当者名を記録する。特定の担当者に依存している場合は、後述する属人化対策の優先度が上がる
- 現場のメンバーにも「対応が遅くて困った場面」を聞き取り、経営者の目に入らない現場レベルの不満も洗い出す
この記録作業は地味だが、後の交渉の土台になる。感情的な「遅い」という訴えを、具体的な日数と件数に変換することで、開発会社側も無視できない事実として受け止めやすくなる。
ステップ2 契約書を読み返し、対応時間の基準があるか確認する
記録と並行して、現在結んでいる保守契約や運用委託契約の契約書を読み返す。先代の時代に結ばれた契約書が手元にない場合は、開発会社に写しの提供を依頼する。ここで確認すべき点は次の通りだ。
- 障害発生時の初回応答までの時間が明記されているか。明記されていない場合、口頭の約束や慣習に依存している状態であり、後の交渉で最初に取り決めるべき項目になる
- 対応可能な時間帯(平日日中のみか、休日や夜間も対象か)が明記されているか。承継後に業務時間が延びた、あるいは店舗営業などで休日対応が必要になった場合、契約時の前提と現状がずれている可能性がある
- 保守料の対象範囲(何が保守料に含まれ、何が追加費用になるか)が明確か。追加費用が発生する作業を無償対応だと思い込んでいたことが、後のトラブルの火種になることがある
- 契約の更新時期と、更新の何か月前までに条件変更の申し入れが必要かという条項があるか。更新のタイミングを逃すと、望まない条件で1年間縛られることになる
契約書に基準がない場合、それは開発会社の問題というより、先代の時代に基準を定めずに運用してきたことの結果だ。これを機に基準を作ることは、決して開発会社を責める行為ではなく、双方にとって明確なルールを持つための前向きな作業だと位置づけるとよい。
ステップ3 担当者個人ではなく、会社としての窓口に問題提起する
対応の遅さを指摘する際、いきなり担当者個人に強い言葉で不満を伝えると、個人的な対立に発展しやすい。担当者は組織の中で優先順位を割り当てられている立場であることが多く、個人を責めても構造は変わらない。効果的なのは、担当者の上司や、開発会社の営業窓口・経営層に対して、記録に基づいた事実を伝えることだ。
- 「対応が遅い」という抽象的な表現ではなく、「先月の障害対応で初回返信まで2日、解決まで4日かかった」という具体的な事実を提示する
- 担当者個人の資質を批判する表現は避け、「体制として改善できないか」という視点で相談する
- 承継直後であることを伝え、「先代の時代からの関係を今後も大事にしたいので、そのために対応の基準を明確にしたい」という前向きな意図を明示する
- 一度の申し入れで解決しない場合は、日を置いて定期的に状況を確認する場を設ける
この段階での目的は、開発会社を糾弾することではなく、双方が同じ基準を共有する土台を作ることにある。強い言葉で一方的に要求するよりも、事実と意図を丁寧に伝えるほうが、長期的な関係の改善につながりやすい。
ステップ4 対応時間の基準を契約に明文化する
口頭でのやり取りだけでは、時間が経つとまた元に戻ってしまう。改善の合意ができたら、必ず契約書または覚書の形で明文化することが重要だ。
- 障害の重要度に応じた初回応答時間の目安(例、業務停止レベルは当日中、軽微な不具合は翌営業日中)を書面に残す
- 連絡手段を明確にする。電話・メール・チャットツールなど、どの手段でどのくらいの時間内に反応があるかを定める
- 担当者が不在の場合の代替連絡先やエスカレーション先(担当者の上司など)を明記する
- 対応記録を双方で確認できる形(問い合わせ管理シートの共有など)にすることを提案する
契約の明文化は、開発会社にとっても「どこまで対応すればよいか」という基準が明確になるという利点がある。曖昧な期待に応え続けるよりも、明確な基準に沿って対応するほうが、開発会社側の負担感も軽減されることが多い。月額の保守費でどこまでの対応が含まれるのかを整理したい場合は、月額保守費で何をやってもらえるのか。相場の考え方も参考になる。
ステップ5 属人化のリスクを下げる情報整理を依頼する
返信の遅さの背景に、担当者個人への依存があると分かった場合は、情報の引き継ぎと文書化を進める。
- 過去の改修履歴、設定変更履歴、システム構成図など、既存の資料の提出を依頼する。資料が存在しない場合は、今後の改修から記録を残すルールを新設する
- 主要な機能や設定について、担当者以外でも参照できる簡易的な手順書の作成を依頼する。全てを一度に整備するのは難しいため、優先度の高い機能から段階的に進める
- 自社の側でも、日常的な問い合わせの内容と回答を記録し、社内にナレッジとして蓄積する。開発会社に依存する部分と自社で対応できる部分を切り分ける第一歩になる
この作業は開発会社にとって手間がかかるため、無償で全てを求めるのではなく、必要であれば追加費用の負担も検討する姿勢を示すと、協力を得やすくなる。
ステップ6 それでも改善しない場合の判断基準を決めておく
契約の明文化と情報整理を進めても改善が見られない場合、関係の継続そのものを見直す判断が必要になる場面もある。この判断を後回しにしないために、あらかじめ基準を決めておくとよい。
- 明文化した対応時間の基準を、一定期間(例えば3か月)守れているかを定期的に確認する
- 基準を大きく下回る対応が続いた場合、どのタイミングで他社への相談や乗り換え検討を始めるかを、自分の中で先に決めておく
- 乗り換えを検討する場合に必要な情報(ソースコードの所在、データのエクスポート可否、契約の解約条件)を事前に把握しておく
判断基準を先に決めておくことで、感情的な決裂ではなく、冷静な経営判断として関係を見直すことができる。決めておかないと、不満が積み重なった末に突発的な決裂に至り、後任の会社探しやデータ移行の準備が不十分なまま関係が切れてしまうリスクがある。
よくある失敗パターン
失敗パターン1 いきなり乗り換えを切り出して交渉の余地をなくす
対応の遅さに我慢の限界を感じた後継社長が、事前の相談や改善の申し入れを一切せず、突然「他社に切り替える」と通告してしまうケースがある。この進め方の問題は、開発会社側に改善の機会を与えないまま関係を終わらせようとする点にある。長年の関係を持つ開発会社ほど、システムの詳細な仕様やデータ構造を深く理解しており、突然の関係終了は、必要な資料の引き渡しやデータのエクスポートといった協力を得にくくする。感情的な決裂に至った状態では、開発会社側も協力に消極的になりやすく、結果として乗り換え作業そのものが難航する。まずは改善の機会を提示し、それでも改善が見られない場合に限って乗り換えを検討するという順序を踏むことで、いざ乗り換える際の協力も得やすくなる。
失敗パターン2 古参社員や先代の顔色をうかがい続けて何も言わない
対応の遅さに問題意識を持ちながらも、「先代がお世話になった会社だから」「古参社員が昔から仲良くしているから」という理由で、一切の指摘をせずに放置してしまうケースも多い。この失敗の本質は、遠慮が問題を先送りするだけで、何も解決しないという点にある。開発会社側からすれば、クレームが来ない状態は「現状で満足されている」というメッセージにしか受け取れない。後継社長が本当に改善を望むのであれば、社内の空気を気にして黙り続けるのではなく、事実に基づいた冷静な申し入れという形で意思表示をする必要がある。古参社員の理解を得るためには、「関係を切るのではなく、より良くするための提案だ」という趣旨を丁寧に説明し、社内の協力を取りながら進めることが望ましい。
失敗パターン3 契約の見直しをせず、口頭のお願いだけで済ませようとする
対応の遅さについて開発会社と話し合い、改善の約束を得たにもかかわらず、それを契約書や覚書という形で残さずに口頭だけで終わらせてしまうケースがある。この失敗の問題は、約束が時間の経過とともに風化してしまう点にある。担当者が異動したり、双方の記憶が薄れたりすると、口頭での約束は簡単に元の状態に戻ってしまう。特に、対応の基準となる時間や連絡手段については、必ず書面に残すことが重要だ。書面化の手間を惜しんで口約束で済ませることは、短期的には手軽に見えるが、長期的には同じ問題を繰り返す原因になる。
よくある質問
対応が遅いことを理由に、すぐに契約を解除してもよいのでしょうか
契約書に対応時間の基準が明記されていない場合、対応の遅さだけを理由にした一方的な契約解除は、法的な観点からもトラブルの火種になりやすい。まずは記録に基づいた事実を示し、改善の機会を提示することが優先される。契約解除を検討する場合は、解約に関する条項(通知期間、違約金の有無など)を事前に確認し、必要であれば専門家に相談した上で進めることをお勧めする。
担当者を変えてほしいと直接開発会社に言ってもよいのでしょうか
担当者の変更を希望すること自体は、取引先として当然の要望であり、伝えて問題ない。ただし、担当者個人の資質を一方的に批判する形で伝えると、関係がこじれやすい。「今の対応体制では業務に支障が出ているため、体制の見直しを相談したい」という形で、会社としての課題として提示するほうが、建設的な話し合いにつながりやすい。
古参社員が開発会社の担当者と個人的に親しい場合、どう進めればよいですか
古参社員の人間関係を無視して一方的に進めると、社内の反発を招きやすい。まずは古参社員に「対応の遅さで現場が困っている」という事実を共有し、改善の必要性について理解を得ることから始めるとよい。古参社員が担当者との個人的なつながりを活かして、非公式に状況を伝えてくれる場合もあり、社内の協力を得ながら進めるほうが、結果的にスムーズに話が進むことが多い。
対応の基準を明文化したいと申し入れたら、開発会社に嫌がられませんか
明確な基準を求めることは、真っ当な取引先であれば拒否する理由がない要望だ。むしろ、基準が明確になることで、開発会社側にとっても「どこまで対応すればよいか」が分かりやすくなり、双方の負担が軽減される場合が多い。申し入れに消極的な反応を示す開発会社であれば、それ自体が今後の関係を見直す判断材料になる。
まとめ
先代の代からの開発会社との関係で返信が遅いという問題は、担当者個人の資質だけに原因があるわけではない。優先順位の埋没、属人化した情報、契約に明記されていない対応基準、承継直後の様子見、そして社内の遠慮という、複数の構造が絡み合って生まれている。後継社長がこの構造を理解せずに感情的な対応に走ると、長年の関係が一気に壊れるか、逆に何も変わらないまま不満だけが積み重なるという、どちらも望ましくない結果に至りやすい。
大切なのは、記録に基づいた事実の把握、契約書の見直し、会社としての窓口への冷静な問題提起、対応基準の明文化、属人化リスクを下げる情報整理という順序を踏むことだ。契約更新のタイミングで開発会社から何を受け取っておくべきかについては、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。この順序を守ることで、関係を切ることを目的にせず、まずは改善の可能性を最大限に探ることができる。それでも改善が見られない場合に備えて、乗り換えの判断基準をあらかじめ決めておくことも欠かせない。先代が築いた関係を尊重しながら、今の会社の実情に合った形に更新していく。それが、承継後の後継社長に求められる、開発会社との向き合い方だ。
