「納品されてから返事が来ない」「電話に出てくれなくなった」「LINEを既読スルーされる」——システム発注した経営者の方から、こうした声を耳にする頻度は減りません。納品後の業者連絡不通は、契約書を交わしていても起きる現象で、特に小規模ベンダーや個人開発者に発注したケースで目立ちます。本記事では、なぜシステム会社が連絡を絶ってしまうのか、その前兆はどこに出ていたのか、いま連絡が取れない状況にある場合の打ち手を、経営者目線で整理します。
この記事の結論（3行）
- 業者が連絡を絶つ原因は「逃げる」より「対応できない」が大半。受注時点の体制と契約の作りに前兆が出る
- 発注前に7つの前兆（属人化・運用契約なし・ソースコード非開示など）を見抜けば回避できる
- いま連絡が取れない場合は、ソース・ドキュメント・データの3点を確保したうえで第三者ベンダーに引き継ぐ
なぜ納品後にシステム会社と連絡が取れなくなるのか
「逃げた」と感じる現象の裏側には、実は2つの構造があります。1つは本当に意図的に連絡を絶つケース、もう1つは「対応したいけれど物理的にできない」ケースです。後者のほうが実は多く、業者側の体制不備が根本原因になっています。
- 担当エンジニアが1人しかおらず、その人が病気・退職・別案件で動けない
- 受注時に運用フェーズの契約を結んでおらず、無償対応を続ける余力が尽きた
- 受注金額が小さく、追加対応の都度赤字になる構造で「優先度を下げざるを得ない」
経営者から見ると「逃げた」と映りますが、業者側は「対応する物理的な余裕がない」と感じている、というすれ違いが起きています。発注時点で構造を整理しておかないと、納品後に連絡不通へ陥るリスクが残り続けます。
「逃げる」より「対応できない」体制になっている
中小ベンダーや個人開発者の現場では、1人のエンジニアが10〜20案件を抱えていることが珍しくありません。その人が体調を崩したり別案件のトラブル対応に追われたりすると、優先度の低い案件は「後回し」になり、結果として返信が途絶えます。これは悪意ではなく、属人化したオペレーションの帰結です。
運用契約を結んでいないので無償対応の余力が尽きる
発注時に「保守契約」「運用契約」を結ばず、初期構築だけの契約で終わっているケースは中小企業の発注で頻繁に見られます。納品後の問い合わせや細かな修正は「サービスで対応」となり、業者側は無償で稼働を割きます。これが3カ月・半年と続くと、業者の心理的・経営的余力が尽き、自然と返信が遅くなる構造です。
受注金額が小さくて優先度を上げられない
300〜500万円規模の案件は、ベンダーから見ると「受注額に対して納品後の手間がかかりすぎる」状態に陥りがちです。同じ業者が1,000万円超の案件を並行で抱えていれば、優先度は当然そちらに寄ります。受注額の大小だけが原因ではありませんが、業者側の優先順位が透けて見えるサインの1つです。
業者の心理を理解しておくと、発注時の交渉でも有効に働きます。受注金額に対して納品後の運用負荷が見合わない構造を、業者側が「経営上の課題」として抱えていることを把握しているか否かで、保守契約の組み方や窓口設計の交渉余地が変わってきます。発注者と受注者の利害が一致する契約構造を作れるかどうかが、納品後の連絡継続性を左右します。
「逃げる」業者の前兆7つ
連絡不通に陥る業者には、発注前から見えるサインがあります。代表的な7つを挙げます。
| 前兆 | 危険度 | 確認方法 | |---|---|---| | 担当者が1人しかいない | 高 | 名刺・体制図・打ち合わせ参加者を確認 | | 運用・保守契約のメニューがない | 高 | 見積もり書に保守項目があるか確認 | | ソースコードの所有権が曖昧 | 高 | 契約書に「成果物の所有権」条項があるか | | 過去案件の運用継続率を答えられない | 中 | 「3年以上運用継続中の案件数」を質問 | | ドキュメントを納品物に含めない | 中 | 見積もり書に設計書・運用手順が含まれるか | | 連絡手段がLINEや個人メールのみ | 中 | 法人窓口メール・電話番号があるか | | 見積もりが相場の半額以下 | 中 | 他社見積もりとレンジ比較 |
7つ全てに当てはまる業者は稀ですが、3つ以上に当てはまる場合は発注を慎重に検討してください。前兆を可視化する手順を項目別に整理してから判断する流れをお勧めします。
担当者が1人しかいない
提案・見積もり・開発・運用まで全て1人で対応しているベンダーは、その人の体調や離職で全機能が止まります。中小ベンダーでは珍しくない構造ですが、「営業窓口」「開発担当」「運用担当」が分かれている体制かを確認してください。3人未満の組織体制で「全責任を負う担当者」が固定されている場合は、納品後の継続性が読みづらくなります。
運用・保守契約のメニューがない
「初期構築のみ」で見積もりが完結している業者は、納品後の対応を体系化していない可能性があります。保守契約のメニュー（月額・スポット・SLA水準）が用意されていない場合は、納品後の問い合わせ対応も曖昧になりがちです。月額3〜8万円程度の保守メニューが提示できない業者は、運用フェーズの体制が組まれていないと判断できます。
ソースコードの所有権が曖昧
成果物のソースコード所有権が契約書に明記されていない場合、業者と連絡が取れなくなった後にソースを引き出せず、別ベンダーへの引き継ぎができません。「成果物の所有権は発注者に帰属する」「ソースコードはGitHubの発注者管理リポジトリに納品する」と明記されているかが、後の打ち手の幅を決めます。
過去案件の運用継続率を答えられない
「3年以上運用継続中の案件数はいくつありますか」と質問してみてください。即答できる業者は運用フェーズに本気で取り組んでいる証拠です。曖昧な回答や即答できない場合は、納品後のサポート体制が機能していない可能性が高くなります。
加えて、運用継続中の案件のうち月額保守費用を払い続けている顧客の割合も確認できれば理想です。納品後に保守を打ち切られているケースが多い業者は、顧客満足度に課題を抱えている可能性が読み取れます。逆に、5年・7年と継続している顧客が複数いる業者は、納品後の対応品質が安定しているサインです。
ドキュメントを納品物に含めない
設計書・運用手順書・テーブル定義書などのドキュメントを納品物に含めない業者は、別ベンダーへの引き継ぎを難しくします。これは意図的というより、ドキュメント作成工数を見積もりに含めないことで価格競争力を出している場合が大半です。発注前に「ドキュメント納品の範囲」を見積もり書に明記してもらってください。
経営者目線で考える「業者選びの判断軸」
経営者がシステム会社を選ぶときの判断軸は、技術力・価格・実績の3つだけでは足りません。「納品後に連絡が取り続けられる構造」をどう担保するか、という4つ目の軸を加えてください。
第一に、「窓口の冗長性」です。営業窓口・技術窓口・経営窓口の3つが分かれているか。担当者が1人で全てを兼ねている体制は、その人の都合で全機能が止まるリスクを抱えます。第二に、「契約の構造化」です。初期構築契約と運用保守契約を分けて結べるか。運用契約を結んだ瞬間に業者側のインセンティブが「納品後も丁寧に対応する」に切り替わります。第三に、「成果物の可搬性」です。ソースコード・ドキュメント・データを発注者側で持てる契約か。引き継ぎが必要になったときの「資産の可搬性」が、業者依存リスクを下げます。
特に2つ目が肝心です。保守契約は「業者を縛るもの」ではなく「業者の対応インセンティブを設計するもの」と捉えてください。月額3〜8万円の保守費用は、納品後の連絡可否を担保する保険料と考えれば妥当です。発注を判断する前に、業務改善・システム見積もりAI適正診断で契約条件を整理しておくと、納品後のリスクを大幅に下げられます。
ぷらすわんの実例：保守契約と窓口設計で連絡不通を防ぐ
ぷらすわん合同会社が中小企業のシステム発注を支援するときに、必ず確認するのが「納品後の窓口」と「契約の構造」です。ある製造業A社の場合、別ベンダーで300万円のシステムを納品済みでしたが、3カ月後に担当者と連絡が取れなくなり、データ抽出すらできない状況に陥っていました。
A社の事例で起きていたのは、3つの構造的問題でした。1つ目、契約書にソースコード所有権の条項がなく、ベンダーが「うちの資産です」と主張したこと。2つ目、保守契約を結んでおらず、無償対応の限界をベンダーが超えたこと。3つ目、ドキュメントが納品物に含まれず、別ベンダーが引き継ぐ判断材料が不足したこと。最終的に弁護士を通じてソースコードの引き渡しを請求し、別ベンダーで運用を再開しましたが、半年間の業務停滞と100万円超の追加コストが発生しました。
A社が発注前に「ソース所有権の明記」「保守契約」「ドキュメント納品」の3点を整えていれば、半年の停滞と追加コストはほぼ回避できた事例です。ぷらすわんでは、こうした構造リスクを発注前に整理し、業者選定の判断軸を可視化する支援を行っています。
いまシステム会社と連絡が取れない場合の打ち手
すでに業者と連絡が取れない状況にある経営者の方へ、現実的な打ち手を5つ整理します。被害を最小化するには、感情的に追いかけるより、資産確保と引き継ぎ準備を並行で進める動き方が有効です。
- ソースコード・ドキュメント・データの3点を確認する
- 契約書の所有権条項とSLA条項を読み返す
- 法人登記情報を確認し、実在性と稼働状況を確認する
- 第三者ベンダーに引き継ぎ可能性をヒアリングする
- 内容証明郵便で対応依頼を出す
この5つは並行で進めてください。1つずつ順番にやっていると、月単位で時間を失います。
ソースコード・ドキュメント・データの3点を確認する
手元にソースコード・ドキュメント・データの3点が揃っているかを最初に確認します。3点が揃っていれば、業者が連絡不通でも別ベンダーへ引き継げます。揃っていない場合は、契約書を根拠に開示請求するか、サーバー・データベースから自社管理権限で抽出できるかを確認してください。
契約書の所有権条項とSLA条項を読み返す
契約書のなかで「成果物の所有権」「ソースコードの帰属」「障害対応のSLA」がどう書かれているかを確認します。明記されていれば、後の交渉や法的措置の根拠になります。明記されていない場合でも、業務委託契約の一般則として「成果物は発注者に帰属する」と解釈される判例が多いので、弁護士に相談する価値があります。
法人登記情報を確認し、実在性と稼働状況を確認する
国税庁の法人番号公表サイトや法人登記情報で、業者の実在性と最新の登記状況を確認します。登記が抹消されている場合は倒産・解散の可能性があり、別の打ち手に切り替える判断が必要です。代表者名で別法人を設立しているケースもあり、登記情報から実態をある程度把握できます。
第三者ベンダーに引き継ぎ可能性をヒアリングする
ソースコードとデータが手元にあるなら、別ベンダーへの引き継ぎ可能性を3社程度にヒアリングしてください。技術スタックや構成によっては「引き継ぎ不可」となるケースもありますが、多くの場合は調査費用50〜100万円で引き継ぎ判断ができます。複数社に比較を依頼することで、引き継ぎ後の運用コストも見通せます。
内容証明郵便で対応依頼を出す
連絡が完全に途絶えた場合、内容証明郵便で「ソースコード・ドキュメント・データの引き渡し」を期日付きで請求します。法的拘束力は弱いですが、業者側の動きを引き出すきっかけになります。期日を過ぎても応答がない場合は、弁護士を通じた正式な請求や調停に進む流れが定石です。
まとめ
納品後にシステム会社と連絡が取れなくなる現象は、業者の悪意よりも体制不備が原因の大半を占めます。属人化・運用契約なし・ソースコード非開示など、発注前に見抜ける7つの前兆を確認しておけば、リスクは大きく下げられます。いま連絡が取れない状況にある場合は、ソース・ドキュメント・データの3点確保と、第三者ベンダーへの引き継ぎ準備を並行で進めてください。
経営者がやるべきことは、業者を疑うことではなく「連絡が取れる構造」を発注前に設計することです。窓口の冗長性、契約の構造化、成果物の可搬性——この3つを整えれば、納品後のトラブルは大幅に減らせます。業者選定の判断軸を整えたい場合は、現状を診断する流れから始めてください。