開発会社と連絡が取れなくなる本当の理由

お疲れ様です。株式会社MemoriaLabの田中です。

システム開発会社と連絡が取れなくなった。
納品後に修正をお願いしたいのに、返事がない。
担当者が辞めて、誰も中身を分かっていない。

こういった話を聞くことがあります。

もちろん、連絡を絶つこと自体は望ましい対応ではありません。
開発会社として誠実ではないと思います。

ただ一方で、なぜそういう状態が起きるのかを考えると、単に「開発会社が悪い」で終わらないケースもあります。

特に問題だと思っているのは、発注時点では見えにくかった曖昧さや無理が、納品後の保守・改修のタイミングで一気に表面化してしまうことです。

その結果、発注者は「対応してもらえるはず」と考え、開発会社は「そこまでは含まれていない」と考える。
この認識のズレが積み重なることで、少しずつ連絡が取りづらい関係になっていきます。

この記事では、少し厳しめにその構造を書いてみます。

「連絡が取れない」は、ある日突然起きるわけではない

開発会社と連絡が取れなくなる。

この状態だけを見ると、開発会社が一方的に不誠実に見えます。
もちろん、実際にそういうケースもあります。

ただ、多くの場合は、納品後に少しずつ関係性が悪くなっています。

最初は軽微な修正。
次に、仕様確認。
その後、追加要望。
たまに障害対応。
さらに、過去の経緯を知らない担当者からの問い合わせ。

このあたりの対応範囲が曖昧なまま進むと、発注者と開発会社の認識がズレていきます。

発注者は、
「保守費を払っているから対応してもらえる」
と思う。

開発会社は、
「この金額ではそこまで含まれていない」
と思う。

このズレが続くと、返信が遅くなり、対応の優先度が下がり、やがてほとんど対応されなくなります。

理由1：保守範囲が曖昧なまま、採算が合わなくなる

たとえば、こういう要望があります。

発注者側の気持ちは分かります。
できるだけ安く、できるだけ良いものを作りたい。
これは自然な考えです。

ただ、開発会社側にも人件費があります。

たとえば、月額保守費が1万円だったとします。
時給5,000円のエンジニアが対応する場合、2時間作業すればほぼ終わりです。

一見「ちょっと直すだけ」に見える作業でも、実際にはコード確認、影響範囲の調査、本番反映などが発生します。

そう考えると、低額の保守費の中で、修正・相談・障害対応まで何でも柔軟に対応し続けるのは、構造上かなり難しいことが見えてきます。

ここを曖昧にしたまま契約すると、関係性は崩れます。

ただし、採算が合わないからといって、連絡を返さなくてよいわけではありません。

対応範囲外なら、対応範囲外だと伝える。
追加費用が必要なら、見積もりを出す。
継続が難しいなら、引き継ぎの相談をする。

そこを曖昧にして黙ってしまうのは、開発会社側の不誠実な対応です。

理由2：雑に作ったシステムから逃げる

個人的に一番問題だと思っているのがこれです。

雑に作ったシステムを納品し、後から面倒を見られなくなるケースです。

これは、発注者からすると見抜きにくい問題です。
なぜなら、納品直後は「画面が動いている」ように見えるからです。

ここが厄介です。

システムは、納品時点で動いていることも大切です。
ただ、それと同じくらい、半年後や1年後に別の人が安全に直せる状態で残っているかどうかも重要です。

私自身の肌感として、決して珍しい話ではありません。

• 安い見積もりで受注する

• 短期間で作る

• とりあえず動く状態にする

• 仕様書はない

• 設計資料もない

• サーバー構成も属人的

• 将来の改修性は考えていない

でも、画面上は動いている。

だから納品時点では、発注者も「ちゃんと完成した」と感じます。

しかし、半年後や1年後に問題が出はじめてきます。

この段階になって初めて、裏側がぐちゃぐちゃだったことに気づきます。

そして、開発会社側も触りたくなくなります。

なぜなら、作った本人しか分からないからです。

その本人が退職しているかもしれません。
外注先だったかもしれません。
そもそも当時から場当たり的に作っていたかもしれません。

そうなると、開発会社の中でも「誰も触りたくない案件」になります。

結果として、返信が遅くなったり、対応が後回しになったり、見積もりが高くなってしまいます。
これはとても不健全なことだと思います。

発注する側で取れる対策

発注する側でできることは、大きく３点です。

• 成果物を自社で管理する
  コードや仕様書など、作ったものはすべて受け取っておくこと。
  他社に引き継ぎを依頼する際も、これがあるかないかで、受け入れのハードルや単価が大きく変わります。

• サービスの契約を自社で持つ
  手間はかかりますが、サーバーや各種サービスの契約は自社名義で保持しておくのが理想的です。
  開発会社が倒産して契約を解除され、コードも残らず使えなくなったという事例は実際に見たことがあります。

• 保守契約の範囲を明文化する
  「月額保守」と書いてあっても、その中身は会社によって違います。
  月に何時間まで対応してもらえるのか。返信の目安はどれくらいか。障害時の対応時間は決まっているのか。軽微な修正は含まれるのか。仕様変更は別料金なのか。
  ここが曖昧だと、発注者と開発会社の間で認識がズレてしまいます。

おわりに

「開発会社と連絡が取れなくなった」という話は、表面的には開発会社の不誠実さに見えます。

もちろん、本当に不誠実な会社もあります。それは間違いありません。

安く作ること自体は悪くありません。
小さく始めることも大切です。

でも、安く作るなら、何を削っているのかを理解する必要があります。

システムを作ること自体の難しさはもちろんですが、それを継続的に更新し続けられるよう設計することは、また別の難しさがあります。

発注前の契約内容の確認や、現在の開発会社との付き合い方に不安がある場合は、第三者目線で整理することもできます。

「この保守契約でどこまで対応してもらえるのか」
「ソースコードやサーバー権限は自社で持てているのか」
「この見積もりは安すぎないか」

こういった点を確認するだけでも、後々のトラブルはかなり減らせます。
必要であれば、弊社でもセカンドオピニオン的なご相談を受け付けています。