他社システムの引き継ぎを断られることがあるのはなぜか｜開発会社が見ているポイント

他社が作ったシステムの保守・引き継ぎを開発会社に相談しても、必ず引き受けてもらえるとは限りません。お断りになりやすいのは「既存のシステムをそのまま使ってほしい」という要望に対して、システムの実際の状態がそれに応えられない場合です。この記事では、開発会社が引き継ぎを断る典型的なパターンと、逆に引き受けてもらいやすくするために発注側が用意できることを、実際の相談対応の経験をもとに解説します。

引き継ぎの相談が「お断り」になりやすいのはどんなときか

結論から言うと、最も多いのは「既存のものをそのままうまく使ってほしい」という要望と、システムの実際の状態にギャップがあるケースです。システムの資産をうまく流用したいという狙い自体は、発注側として自然な考えです。無駄なコストをかけたくない、動いているものを壊したくないという判断は、経営としてまっとうなものです。

ただし実際に調査してみると、長年手を入れられずに放置されたシステムであることが多く、結果として大幅な修正や作り直しの提案にならざるを得ないことがあります。「そのまま使えるはず」という発注側の期待と、「そのままでは維持が難しい」という調査結果の間にギャップが生まれ、そのギャップの大きさによってお断りにつながることがあります。

なぜ「そのまま使う」より「作り直す」提案になりやすいのか

開発会社の立場では、既存のシステムを把握してうまくパズルのように組み合わせて直すよりも、スクラップアンドビルド（作り直し）の方が作業として楽で、ミスも少ないという判断が働きます。これは開発会社側の都合ではなく、古いシステムの内部構造を正確に読み解く作業自体に、作り直しと同等かそれ以上の手間がかかることが多いためです。この判断の根拠になる「システムの状態をどう調査するか」については、システムを直すより作り直した方が早いと言われるのはなぜか｜引き継ぎ調査で見ている状態で詳しく解説していますので、あわせてご覧ください。

「なんで作り直しなんだ」「なんでそんなに費用がかかるんだ」と思ったときに起きていること

この判断がうまく伝わらないと、発注側から見て「なんで作り直しなんだ」「なんでそんなに費用がかかるんだ」という疑問や不満につながることがあります。これは発注側の理解不足というより、開発会社側の説明が十分に届いていないために起きる、双方の前提のズレです。

作り直しが必要だと判断した根拠は、サーバーの調査などによって具体的に示すことができます。ただし発注側に技術的な知識がない場合、その内容を理解してもらうのは簡単ではなく、ここに開発会社側の課題があります。金額や説明に納得できないときは、遠慮せずに「なぜその判断に至ったのか」を確認することをおすすめします。専門用語を避けて説明してもらえるかどうかも、その開発会社と長く付き合えるかどうかの目安になります。

何があれば引き受けてもらいやすくなるのか

開発会社が引き継ぎを引き受けやすくなる条件は、大きく2つあります。

条件1：余裕のある予算と納期

調査や作り直しの提案が必要になった場合でも、予算と納期に余裕があれば検討する余地が生まれます。逆に、予算も納期もぎりぎりの状態で「とにかく安く早く引き継いでほしい」という相談は、調査すら十分に行えず、開発会社としてもリスクを取りづらくなります。

条件2：専門家に委ねる覚悟

「信頼できる業者だ」と判断できた相手に対しては、システムの状態を含めてまるっと任せてもらう方が、結果として良いものができあがります。これは初めて取引する相手には難しい判断ですが、判断を委ねてもらえるかどうかが、引き受けられるかどうかの分かれ目になることがあります。信頼関係ができるまでは、小さな依頼から始めて実績を確認してもらうという進め方も一つの方法です。

断られたあと、発注側はどうなるのか

正直なところ、一度お断りした相談のその後がどうなったかを、開発会社側が把握できることはほとんどありません。ただし、別の形で関係が続くケースもあります。以前に相見積もりでFUNBREWが失注した発注者から、しばらく経ってから「以前依頼した業者とは合わなかったので、御社にお願いしたい」という相談を受けたことがあります。

話を伺うと、開発会社が普段行っているプロジェクトの進め方と、発注側が想定していた進め方に食い違いがあったとのことでした。このときは、新しい知識の取り入れ方や、専門家の判断を信頼して任せてもらえるかという点で、双方の前提がそろわなかったため、FUNBREWとしても丁重にお断りした経緯があります。相性がすべて悪かったわけではなく、進め方の前提を事前にすり合わせられていなかったことが、双方にとって遠回りになった一例です。