システム開発の途中で連絡が途絶えたらどうなるか｜凍結後の支払い・ソースコード・再開の扱い

システム開発を依頼する側にとって、「途中で事情が変わって進められなくなったらどうなるのか」は、契約前に聞きにくい話です。開発会社の側でも、発注側の都合で案件が止まった経験を書いた記事はあまりありません。FUNBREWでは、開発の途中で凍結の話が出て、その後連絡が来なくなった案件が実際にありました。倒産や廃業かどうかは分かりません。ただ「止まった案件で何が起きたか」は、そのまま書けます。

この記事では、その一件で作業・支払い・ソースコード・再開の4点がどう扱われたかを整理します。読み手として想定しているのは、これから開発を発注する担当者と、進行中の案件を一時的に止めざるを得なくなった担当者です。

途中で止まった案件で、実際に何が起きたか

結論から言うと、作業は止めましたが、支払いの問題も成果物の問題も起きませんでした。順を追って書きます。

凍結の話が出た後、連絡が来なくなった

案件は開発の途中でした。ある時点で開発を凍結する話が出て、その後、連絡が途絶えました。それ以降は特に連絡がありません。理由は分かりません。倒産や廃業なのか、社内の優先度が変わったのか、担当者が異動したのか、確かめる手段がないためです。

開発会社の側から見ると、「連絡が来ない」という状態は「凍結が続いている」と同じ扱いになります。中止と決まったわけではないので、案件そのものは閉じていません。

作業は止めた

凍結の話が出た時点で、開発作業は止めました。連絡が取れない相手のために開発を進めても、要件の確認や検収ができないので、進めた分が無駄になる可能性が高いためです。「勝手に進めて後から請求する」ということはしていません。止めた時点の状態を保った形で、案件を保留にしています。

支払いは、着手金と中間金の約束どおりに済んでいた

この案件では、契約の時点で着手金と中間金をいただく約束をしていました。作業を止めた時点で、その取り決めに沿った支払いは受けていたため、未払いは発生していません。

これは偶然ではなく、分割で支払いを受ける形にしていたことの効果です。もし「納品後に全額」という契約だったら、作業した分がそのまま回収できない形になっていました。発注側にとっても、止まった時点までの作業に対して支払っている状態なので、後から「ここまでの分を払ってください」と請求されて揉めることがありません。

ソースコードは今も保管している

止まった時点までに書いたソースコードは、FUNBREWが今も保有しています。そして、お客様に渡す用意はあります。連絡があって「ここまでのものを引き取りたい」と言われれば、その時点の成果物としてお渡しできる状態にしてあります。

連絡があれば、続きから再開する

この案件は、こちらから閉じてはいません。連絡があり次第、止めた時点の続きから開発を再開することになります。ソースコードは残っているので、ゼロからやり直す必要はありません。

発注側が事前に確認しておくとよいこと

上の一件から言えるのは、「途中で止まる可能性」への備えは、契約の段階でほとんど決まるということです。止まってから交渉するのではなく、止まる前に決めておく項目を3つに絞って書きます。

支払いのタイミングを分割にしておく

着手金・中間金・残金のように、作業の進み具合に合わせて支払いを分ける形にしておくと、途中で止まったときに「どこまで払ったか」「どこまで作業したか」が対応します。開発会社にとっては作業分の回収、発注側にとっては払った分の成果物の確保、という両方の意味で効きます。

支払いの区切りをどう置くかは契約形態によっても変わります。請負と準委任の違いについてはシステム開発の契約形態｜請負と準委任の違いで整理しています。

凍結・中断のときの成果物の扱いを決めておく

途中で止まったとき、その時点のソースコードや設計資料を誰が持つのか、引き渡すのかを決めておきます。上の案件では、FUNBREWとしては保管したうえで渡す用意をしています。ただ、これは開発会社の方針次第で変わる部分なので、発注前に「途中で止まったら、そこまでの成果物はもらえますか」と聞いておくのが確実です。

関連して、納品後の無償対応の範囲についてはシステム開発の保証期間はどこまで無償かで書いています。止まる前と納品後で、開発会社の扱いがどう変わるかを対で見ておくと分かりやすいと思います。

止めるときは、止めると伝える

これは技術の話ではなく連絡の話です。上の一件では、凍結の話が出た後に連絡が途絶えました。開発会社の側は、それを「中止」とは受け取れません。凍結が続いているものとして案件を保留し、ソースコードも保管し続けます。

発注側の事情で止めざるを得ないときは、「一時的に止める」「今のところ再開の予定はない」「中止にする」のどれなのかを一言伝えてもらえると、開発会社の側もその前提で動けます。中止であれば成果物の引き渡しと精算をして閉じますし、凍結であれば再開に備えて残します。伝えないまま止まると、開発会社は「いつ連絡が来てもよいように」保留を続けるしかありません。

開発会社が倒産した場合との違い

「途中で相手がいなくなる」という意味では、開発会社の側が倒産や連絡不能になるケースの方が、発注側にとっては深刻です。その場合はソースコードや本番環境の情報を取り戻すところから始める必要があり、進め方は開発会社が倒産・連絡不能になったときの緊急保守引き継ぎで書いています。

逆に、この記事で扱った「発注側が止まる」ケースは、成果物が開発会社の手元に残っているので、発注側が再び動けるようになれば続きから始められます。支払いを分割にしておくことと、止めるときに一言伝えることの2つで、ほとんどの問題は起きません。

まとめ

• 開発の途中で凍結の話が出て、その後連絡が途絶えた案件が実際にありました。倒産かどうかは分かりません。
• 作業は止めましたが、着手金と中間金の取り決めがあったので、未払いは発生していません。
• 止まった時点までのソースコードはFUNBREWが保管しており、お客様に渡す用意があります。
• 連絡があれば、止めた時点の続きから再開します。
• 発注側が事前にできる備えは、支払いを分割にしておくこと、途中の成果物の扱いを聞いておくこと、止めるときに一言伝えることの3つです。

進行中の案件を一時的に止めたい、あるいは以前止まった案件を再開したいという場合は、お問い合わせから状況をお知らせください。止めた時点の成果物の引き渡しも、続きからの再開も、どちらにも対応します。