開発会社の返信が遅い・つかまりにくい。関係が壊れる前にできる対処

以前は、メールを送ればその日のうちに返信があった。ちょっとした質問をチャットで投げれば、担当者がすぐに反応してくれた。ところがここ数ヶ月、明らかに様子が違う。メールの返信は数日待たされるようになり、電話をかけても「担当者が席を外している」と言われることが増えた。緊急の不具合報告を送っても、一次返信すら来ない日がある。

「担当者が忙しいだけだろう」「そのうち落ち着くだろう」と自分に言い聞かせながら、心のどこかで不安が募っていく。この開発会社との関係は大丈夫なのか。何か自社が知らないところで問題が起きているのではないか。かといって、いきなり強く問い詰めれば関係が気まずくなるかもしれない。かといって黙って我慢し続ければ、いざというときに助けてもらえない。そんな板挟みの中で、多くのシステム担当者が動けずにいます。

結論から言うと、返信が遅くなる兆候に気づいた段階で「様子見」を続けるのは得策ではありません。関係が完全に壊れてから動くのと、兆候の段階で手を打つのとでは、取れる選択肢の数がまったく違います。この記事では、開発会社の返信が遅くなってきたと感じたときに、感情的にならずに状況を切り分け、関係を壊さずに改善を働きかける具体的な手順を、初動から中長期の備えまで順を追って解説します。

この記事で分かること

この記事では、次の3つの段階に分けて、返信の遅さへの向き合い方を整理します。第一に、「本当に遅くなっているのか」を客観的に確認する方法。第二に、遅れの背景にある典型的な原因を見極める視点。第三に、関係を壊さずに改善を申し入れる具体的な伝え方と、それでも改善しない場合のエスカレーションの手順です。

先に要点を挙げておきます。

• 感覚ではなく記録で判断する: 「遅い気がする」を、いつ・何を送って・いつ返信が来たかの記録に変える
• 原因を決めつけない: 担当者の問題とは限らず、契約範囲・体制・自社側の伝え方に原因があることも多い
• いきなり強く出ない: 事実確認から入り、感情的な対立を避けながら改善を申し入れる
• 改善しない場合の道筋を用意しておく: エスカレーション・契約確認・乗り換え検討まで、段階を踏んで備える

この記事は、今まさに開発会社とのやり取りが滞っていて不安を感じている方はもちろん、まだ深刻ではないが「最近ちょっと遅いな」と引っかかりを覚え始めた方にこそ読んでいただきたい内容です。早い段階で手を打てるかどうかが、その後の関係を大きく左右します。

なお、この記事の運営元である株式会社ゼットリンカーはシステムの受託開発を事業としており、関係が悪化した発注者にとっての乗り換え先の選択肢になり得る立場でもあります。ただし、ここで書く内容は特定のベンダーへの乗り換えを煽るものではなく、公正取引委員会の実態調査や民法など公的な一次情報に基づいた中立的な整理であることを断っておきます。自社に不利な情報であっても、事実として重要であれば書きます。

まず「本当に遅くなっているのか」を記録で確認する

担当者が変わってから返信が遅い気がする、以前より対応がそっけない気がする。こうした感覚は、多くの場合正しい兆候を捉えていますが、「気がする」のままでは開発会社に改善を申し入れる際の説得力に欠けます。まず最初にやるべきは、感覚を記録に変換する作業です。

やり方は難しくありません。直近1〜2ヶ月分のメールやチャットのやり取りを遡り、次の3つを書き出してください。

1. こちらが送った連絡の日時と内容
2. 相手から一次返信があった日時(内容の解決ではなく、最初の反応があった時点)
3. 実際に対応・解決に至った日時

これを5〜10件程度並べるだけで、「以前は翌営業日以内に返信があったのに、直近では3営業日以上かかっている」といった変化が具体的な数字として見えてきます。この記録は、後で開発会社に改善を申し入れる際にも、社内で状況を説明する際にも、説得力のある根拠になります。

実務上のコツ: この記録は開発会社に見せるための資料である以前に、自分自身が冷静に状況を把握するための資料でもあります。感覚だけで「遅い、遅い」と焦っていると、実際には妥当な範囲の遅れなのか、明らかに異常な遅れなのかの判断がつかなくなります。数字にして初めて、次に取るべき行動の強さが決まります。

記録を取る際は、単純な日数だけでなく「緊急度」も一緒にメモしておくと、後の分析に役立ちます。障害報告のような緊急性の高い連絡と、機能追加の相談のような緊急性の低い連絡を同じ基準で比較すると、実態を見誤ります。

遅れの深刻度を3段階で切り分ける

記録が取れたら、次はその遅れがどの程度深刻なのかを切り分けます。すべての「返信が遅い」を同じ危機感で扱う必要はありません。目安として、次の3段階で考えると整理しやすくなります。

この切り分けが重要なのは、対応の強さを段階に合わせて調整する必要があるからです。軽度の段階でいきなり「契約解除も検討している」と強い態度を示せば、関係がこじれるだけで得るものがありません。逆に重度の段階になっても「様子を見よう」を続けていると、システムに障害が起きたときに致命的な初動の遅れにつながります。

自社の状況がどの段階に近いか、記録を見ながら一度冷静に位置づけてみてください。段階が分かれば、次に取るべき行動もおのずと見えてきます。

返信が遅くなる背景にある典型的な原因

返信が遅くなる原因は、担当者の怠慢や関係の悪化だけとは限りません。開発会社側の事情、契約上の位置づけ、自社側の伝え方など、複数の要因が絡んでいることが多く、原因を決めつけて感情的に反応すると、的外れな抗議になってしまうことがあります。ここでは典型的な背景をいくつか整理します。

開発会社側に起因する要因としては、次のようなものがよくあります。

• 担当者が退職・異動し、後任への引き継ぎが不十分なまま案件を抱えている
• 会社全体が繁忙期で、他の案件に人員が集中している
• 自社案件の優先順位が、契約金額や案件規模の観点から相対的に下がっている
• 社内体制の変化(組織再編、担当チームの縮小など)が起きている

一方、契約や自社側の要因としては、次のようなケースが考えられます。

• そもそも契約上、対応時間や返信期限に関する取り決めがなく、開発会社側の裁量に委ねられている
• 過去の追加要望や仕様変更が積み重なり、開発会社側の作業負荷が想定以上に膨らんでいる
• 問い合わせの内容が曖昧で、開発会社側も何から手をつけてよいか判断しかねている
• 連絡手段が分散しており(メール・チャット・電話が入り乱れる)、対応の優先順位がつけにくくなっている

「相手が悪い」と決めつける前に、この記事に挙げた項目を一つずつ自社の状況に照らし合わせてみることをおすすめします。原因の所在によって、次に取るべきアプローチはまったく変わってきます。

特に見落とされがちなのが、契約形態そのものが遅れの背景になっているケースです。次の章で詳しく見ていきます。

契約形態によって「報告義務」の位置づけが違う

開発会社との契約が準委任契約である場合、実は法律上、発注者側には状況を報告させる根拠があります。民法第645条は「受任者は、委任者の請求があるときは、いつでも委任事務の処理の状況を報告し、委任が終了した後は、遅滞なくその経過及び結果を報告しなければならない」と定めています。つまり、準委任契約においては、発注者が求めれば開発会社は状況を報告する法律上の義務を負っているのです。

さらに民法第644条では、受任者(開発会社側)は「委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う」とされています。これは、単に作業をこなせばよいというものではなく、専門家としての相応の注意を払って業務を遂行する義務があることを意味します。返信が極端に遅く、緊急の連絡にも応答がない状態が続くことは、この注意義務との関係でも問題になり得る事態です。

一方、契約が請負契約である場合は、開発会社が約束しているのは「決められた成果物を完成させること」であり、日々の報告や応答の速さそのものは、契約書に明記がない限り法律上の直接的な義務にはなりにくい面があります。ただし、この場合でも成果物の完成に向けた進捗の説明を求めることは、発注者として当然の行為であり、遠慮する必要はありません。

自社の契約がどちらの形態になっているか、この機会に契約書を確認してみてください。契約形態が分かれば、「報告を求めることは正当な権利である」という前提で、次のアクションに臨むことができます。

契約書・見積書に「対応時間」の取り決めがあるか確認する

契約形態の確認と合わせてチェックしたいのが、SLA（サービス品質保証）に相当する取り決めが契約書や見積書、あるいは基本契約に付随する覚書に存在するかどうかです。対応時間や返信期限についての明文化された取り決めがあれば、それが遅れを指摘する際の最も強い根拠になります。

確認すべき項目の例を挙げます。

• 問い合わせに対する一次返信までの目安時間(例: 平日1営業日以内)
• 障害・緊急対応時の対応時間の取り決め
• 対応可能な時間帯(平日日中のみか、休日・夜間も含むか)
• 対応時間の取り決めが守られなかった場合のペナルティや協議事項の有無

多くの中小企業向けシステム開発の契約では、こうした対応時間の取り決めが明文化されていないことも珍しくありません。もし契約書を確認して何も定めがなかった場合、それ自体が今後の課題として認識すべきポイントです。今回の遅れをきっかけに、次回の契約更新や保守契約の見直しのタイミングで、対応時間の目安を明文化しておくことを検討する価値があります。

契約書の該当箇所が見当たらない場合は、契約時に受け取った提案書やSOW（作業範囲記述書）に、対応範囲や体制についての記載がないかも合わせて確認してみてください。

記録が整ったら、まず「事実確認」の連絡を入れる

状況の記録と契約内容の確認が済んだら、いよいよ開発会社への連絡です。ここで大切なのは、いきなり不満や不信感をぶつけるのではなく、事実確認というかたちで切り出すことです。相手を責める姿勢で入ると、たとえ正当な指摘であっても、相手が防御的になり建設的な対話が難しくなります。

事実確認の連絡で押さえるべき要素は、次の3つです。

1. 具体的な事実を示す: 「最近対応が遅い気がします」ではなく、「〇月〇日に送ったメールについて、返信をいただくまで5営業日かかりました」と、記録に基づいて伝える
2. 心配していることを伝える: 「何か体制に変化があったのではないかと心配しています」など、詰問ではなく懸念として伝える
3. 今後の見通しを尋ねる: 「今後の対応の見通しについて、教えていただけますか」と、相手に説明の機会を与える

この連絡は、可能であればメールなど記録の残る手段で行い、かつ感情的な表現を避けて事実ベースの文面にすることをおすすめします。電話や口頭だけで済ませると、後になって「言った・言わない」の水掛け論になりかねません。

実務上のポイント: この段階での連絡は、相手を追い詰めるためのものではなく、「状況を正しく把握したい」という姿勢を示すためのものです。多くの場合、開発会社側にも何らかの事情があります。頭ごなしに責めるのではなく、事情を聞く余地を残しておくことで、その後の関係修復がしやすくなります。

相手の回答から見極めるべきポイント

事実確認の連絡に対して、開発会社側から何らかの回答があった場合、その内容の質を見極めることが次のステップです。誠実に状況を説明しようとしている回答か、それとも曖昧にごまかそうとしている回答かで、その後の対応方針が変わってきます。

誠実な対応が期待できる回答の例としては、次のようなものが挙げられます。

• 具体的な理由(担当者交代、繁忙期、体制変更など)を説明したうえで謝罪がある
• 今後の対応方針(担当者の再アサイン、対応期限の目安など)が示される
• 改善に向けた具体的な期日や約束が提示される

一方、注意が必要な回答のパターンもあります。

• 「大丈夫です、問題ありません」という一言で済まされ、具体的な説明がない
• 謝罪はあるが、今後どう改善するかの言及がない
• 話をはぐらかされ、別の話題にすり替えられる

もし後者のような曖昧な回答しか得られなかった場合、それ自体が一つの重要なサインです。前の記事で扱った進捗報告の危険な兆候と同様、具体的な説明ができない状態が続くこと自体が、体制上の問題を抱えている可能性を示しています。この場合は、次の段階として、より公式なエスカレーションを検討する必要があります。

改善が見られない場合のエスカレーションの手順

事実確認の連絡をしても改善が見られない、あるいは曖昧な回答が続く場合は、エスカレーションを検討する段階に入ります。エスカレーションというと、対決的な響きに聞こえるかもしれませんが、実際には「窓口レベルでは解決できない問題を、より広い視野を持つ立場の人に相談する」という、ごく実務的な手続きです。

エスカレーションを進める際は、次の順序を踏むことをおすすめします。

1. 窓口担当者に、上長への相談を提案する: 「今の状況について、御社の上長の方にもご相談いただくことは可能でしょうか」と、対立ではなく協力を求める形で伝える
2. 自社側の窓口も一本化する: 自社の複数の担当者がバラバラに問い合わせている場合、それ自体が優先順位を分かりにくくしている可能性があるため、窓口を一本化してから相談する
3. 書面での経緯共有を用意する: これまでの記録(いつ、何を、どう連絡し、どう返信があったか)を簡潔にまとめ、双方の認識合わせの材料にする
4. 双方の上位者を交えた場を設定する: 必要であれば、自社側の上司・経営層と、開発会社側の上長が同席する場を設け、状況を共有し改善策を協議する

エスカレーションは、関係を壊すための最終手段ではなく、むしろ関係を立て直すための正式な手続きだと捉えてください。窓口担当者個人の問題として押し付けるのではなく、組織対組織の課題として扱うことで、双方が冷静に向き合いやすくなります。

エスカレーションの際のポイント: 「誰が悪いか」を追及する場にしないことが重要です。目的はあくまで「今後どう改善するか」の合意形成であり、過去の責任追及に時間を使いすぎると、かえって関係修復の機会を失います。

エスカレーションしても改善しない場合、何を検討すべきか

窓口レベルでの改善申し入れ、上長を交えたエスカレーションを行ってもなお状況が改善しない場合は、より根本的な対応を検討する段階に入ります。この段階での選択肢は、大きく分けて次の3つです。

• 契約内容の見直しを正式に協議する: 対応時間や体制についての取り決めを、契約書や覚書に明文化する交渉を行う
• 保守・運用の一部を切り出す: すべてを1社に依存する体制(マルチベンダーの対極にある状態)を見直し、緊急対応だけでも別のリソースを確保できないか検討する
• 開発会社の乗り換えを視野に入れる: 関係の修復が見込めないと判断した場合、他社への切り替えを段階的に検討する

これらはいずれも軽い決断ではありません。特に長年付き合ってきた開発会社であればあるほど、乗り換えには心理的にも実務的にも大きなハードルがあります。ただし、覚えておいていただきたいのは、これらの選択肢を「検討し始めること」と「実行すること」は別だということです。まずは選択肢を並べて比較検討するところから始めれば十分です。

自社のシステムがどの程度、特定の開発会社に依存した状態にあるか(内製化とアウトソースの観点も含めて)を、この機会に整理しておくことをおすすめします。依存度が高いほど、乗り換えのハードルは上がりますが、それを把握しておくこと自体が、次に交渉する際の材料になります。

関係が完全に壊れる前に、記録しておくべきこと

エスカレーションが必要になるかどうかにかかわらず、返信の遅さに気づいた段階から、次の記録は継続して残しておくことを強くおすすめします。これは開発会社を疑ってかかるためではなく、万が一関係が悪化した場合に、自社を守るための備えです。

• 連絡日時・内容・返信までにかかった日数の一覧
• 事実確認の連絡を送った日付とその内容
• 開発会社からの回答内容(可能な限りメールなど記録が残る形で)
• 契約書・見積書・SOWなど、対応範囲や体制に関する取り決めの控え

こうした記録は、関係が良好なまま推移すれば使う機会がないかもしれません。しかし、万が一検収前の重要な局面で連絡が取れなくなったり、システム障害の対応が滞ったりする事態に発展した場合、これらの記録があるかないかで、その後の対応の選択肢が大きく変わります。

記録を残すことは、相手を疑う行為ではなく、どんな関係においても実務上当然のリスク管理です。良好な関係が続く限り、この記録は単なる保険として引き出しにしまっておけばよいだけの話です。

定例ミーティングがあるなら、そこで軽度の段階から扱う

もし開発会社との間で定例ミーティングを実施している場合、返信の遅さについては、深刻化する前の軽度の段階からアジェンダに乗せておくことをおすすめします。個別のメールで指摘するよりも、定例の場でオープンに扱うほうが、相手にとっても「個人攻撃ではなく、プロジェクト運営上の議題」として受け止めやすくなります。

定例ミーティングで扱う際の伝え方の例です。

• 「直近の連絡対応について、少し確認させてください」と、議題として明示的に切り出す
• 具体的な件名や日付を挙げて、事実ベースで状況を共有する
• 「体制に何か変化がありましたか」と、原因を決めつけずに尋ねる
• 今後の対応の見通しについて、次回までの宿題として持ち帰ってもらう

定例ミーティングがまだ設定されていない、あるいは形骸化している場合は、この機会に定例の場そのものを見直すことも検討してください。返信の遅さという個別の問題の背景に、そもそも定期的なコミュニケーションの機会が不足しているという、より構造的な課題が隠れていることも少なくありません。

自社側の伝え方が遅れの一因になっていないかも点検する

ここまで開発会社側の要因を中心に扱ってきましたが、公平を期すために、自社側の伝え方に改善の余地がないかも一度点検しておくことをおすすめします。返信が遅い背景に、自社からの問い合わせの仕方自体が、開発会社にとって対応しづらいものになっているケースも実際にあります。

点検したいポイントを挙げます。

• 一つのメールに複数の異なる用件を詰め込んでいないか(優先順位がつけにくくなる)
• 緊急度が伝わる書き方になっているか(「至急」「通常対応で構いません」などの明示)
• 問い合わせ内容が具体的か、それとも「なんとなく調子が悪い」といった曖昧な表現にとどまっていないか
• 連絡窓口が社内で統一されているか、複数の担当者がバラバラに連絡していないか

もし自社側にも改善の余地が見つかった場合、それを認めたうえで開発会社との対話に臨むと、相手も「一方的に責められている」という印象を持ちにくくなり、建設的な話し合いがしやすくなります。関係改善は、多くの場合、双方の歩み寄りによって成立します。

緊急の不具合報告なのに応答がないときの初動

これまで扱ってきたのは、通常連絡の遅れを中心とした話です。しかし、最も緊急性が高いのは、システム障害や不具合の報告に対して応答がない状態です。このケースだけは、記録を整えてから動くという悠長な手順を踏んでいる余裕がありません。ここでは緊急時に絞った初動対応を整理します。

まず、業務に支障が出ている、あるいは出る恐れがある不具合を報告した場合、次の時系列で行動してください。

1. 報告直後: メール・チャットに加えて、契約書に緊急連絡先の記載があれば電話でも一報を入れる。記録が残る手段(メール・チャット)は必ず並行して使う
2. 半日〜1営業日たっても応答がない場合: 別の連絡手段(電話をしていなければ電話、担当者個人にしか送っていなければ会社の代表窓口にも)で再度連絡する
3. 担当者と連絡が取れない状態が続く場合: 契約書に記載されている別の連絡先(営業担当、代表番号など)に、担当者と連絡が取れない旨を伝えて状況を確認する
4. それでも応答がない場合: 社内の経営層に状況を報告し、自社としてどこまで自力対応できるか、外部の応援を求めるかを判断する

緊急時は、平時であれば避けるべき「複数の窓口に同時に連絡する」という行動も、状況によっては正当化されます。業務影響が大きいと判断される場合は、遠慮なく複数のルートから連絡を試みてください。

緊急時に備えるためのポイント: 平時のうちに、担当者個人の連絡先だけでなく、開発会社の代表電話番号や、担当者が不在の場合の連絡ルールを確認しておくことをおすすめします。担当者一人にしか連絡手段がない状態は、平時には気づきにくいものの、緊急時には致命的なボトルネックになります。

こんな状態になっていたら要注意という具体例

ここまで抽象的な手順を中心に説明してきましたが、実際にどのような状態になったら「これは軽度ではなく中度・重度に近い」と判断すべきか、具体的なイメージを持てるように整理しておきます。次のような状態が複数当てはまる場合は、この記事で紹介した事実確認・エスカレーションの手順に、早めに進むことをおすすめします。

• 担当者のメールアドレスに送っても、1週間以上まったく反応がない
• 担当者の携帯電話や会社の代表番号に電話しても、折り返しの連絡がない状態が何度も続いている
• 定例ミーティングが、開発会社側の都合で連続してリスケジュールされている
• 見積もりや請求のやり取りだけは滞りなく進むのに、技術的な問い合わせにだけ反応が薄い
• 以前は名指しで対応してくれていた担当者から、「担当が変わりました」という連絡だけがあり、後任からの連絡がその後途絶えている

これらはあくまで目安であり、これに当てはまったら即座に契約解除を検討すべきという意味ではありません。ただし、複数当てはまる状態が1ヶ月以上続いているのであれば、「もう少し様子を見よう」という判断を続けることのリスクのほうが大きくなっている可能性が高いです。この記事で紹介した記録と事実確認のステップに、早めに進んでください。

よくある失敗パターンを避ける

最後に、返信の遅さへの対応でありがちな失敗パターンを整理しておきます。以下のいずれかに心当たりがある場合は、この記事で紹介した手順に立ち返ることをおすすめします。

• 我慢を続けて、限界を超えてから一気に爆発する: 蓄積した不満を一度にぶつけると、相手も冷静な対応がしづらくなり、関係修復が難しくなります
• 記録を取らずに感覚だけで抗議する: 具体性を欠いた抗議は、相手に「感情的なクレーム」として受け止められ、真剣に取り合ってもらえないことがあります
• いきなり乗り換えを匂わせて脅す: 早すぎる段階での強い言葉は、かえって相手を硬化させ、対話の余地を狭めます
• 社内の複数の担当者がバラバラに催促する: 統制の取れていない催促は、開発会社側の対応の優先順位づけをかえって混乱させます

これらのパターンに共通するのは、いずれも「感情が先に立ち、事実の整理と段階的な対応が後回しになっている」という点です。この記事で紹介した、記録・切り分け・事実確認・段階的なエスカレーションという流れを意識するだけで、多くの失敗は避けられます。

まとめにかえて、次に読んでほしい記事について

開発会社の返信が遅くなってきたと感じたとき、大切なのは「気のせいかもしれない」と自分を納得させて様子見を続けることでも、いきなり強い態度で関係を壊すことでもありません。感覚を記録に変え、深刻度を切り分け、事実確認から段階的に働きかけていく。この順序を守ることが、関係を壊さずに状況を改善する最も現実的な道筋です。

この記事で紹介した手順を実践する中で、次のようなテーマについてもあわせて理解を深めておくと、今後同じような不安を感じたときに、より落ち着いて対応できるようになります。

• 「開発会社とのつきあいかた」カテゴリの他の記事(進捗報告の危険な兆候の見抜き方、定例ミーティングの回し方など)
• 保守契約の内容や対応範囲を確認する記事(月額保守費で何をやってもらえるのか)
• 開発会社との関係が本当に修復不可能と判断したときの、乗り換え判断の記事

返信の遅さは、それ単体では「まだ様子を見てよい段階」かもしれません。しかし、この記事で紹介したように早い段階で記録を取り、事実に基づいて対話を試みておくことが、万が一の事態への最良の備えになります。今日感じた小さな違和感を、記録という具体的な行動に変えるところから始めてみてください。