システム開発プロジェクトを途中で中止・解約する場合に確認すべきこと

システム開発プロジェクトを途中で中止・解約する場面は、事業方針の変更や予算の見直しなど、どの会社にも起こり得ます。しかし多くの発注者は、契約時に「順調に完成させること」だけを想定しており、途中で止める場合の条件を確認しないまま契約を結んでいます。いざ中止が必要になった際、それまでの成果物が引き渡されるのか、支払済みの費用はどう精算されるのかが曖昧なままだと、想定外のトラブルに発展します。この記事では、途中解約時に確認すべきポイントと、契約時にあらかじめ決めておくべきことを整理します。

なぜ途中解約の条件は見落とされやすいのか？

理由は大きく3つあります。

• 契約時は「完成させる前提」で話が進む：発注者・開発会社ともに、プロジェクトが順調に完成することを前提に契約交渉を進めるため、中止時の条件にまで意識が向きにくくなります。
• 途中解約の話を持ち出しにくい心理的な壁がある：契約前から「途中でやめるかもしれない」という前提を持ち出すことに、発注者側が抵抗を感じることがあります。
• 成果物の範囲が曖昧なまま契約されている：どこまで完成すれば「成果物」として引き渡し対象になるのかが契約書に明記されていないことがあります。

条件を確認しないまま中止すると、どうなるか？

成果物の引き渡し範囲が不明確だと、それまで支払った費用に見合う成果物を受け取れないまま契約が終わることがあります。逆に開発会社側も、着手済みの作業分の費用を回収できないリスクを抱えることになります。どちらの立場であっても、条件が曖昧なままの中止は、その後の関係悪化や、場合によっては法的な紛争にまで発展するリスクを抱えています。

自社の場合に当てはめて整理したい方は、システム開発について相談する →

途中解約時に確認すべきこととは、何を指すのか？

解約そのものを避けるための話ではありません。まず押さえるべきは、いつ中止しても損失を最小限にできる状態を、契約の段階で作っておくという発想です。

着手済み分の費用精算方法を確認する

作業の進捗度合いに応じた費用精算の計算方法（工数按分等）が契約書に明記されているかを確認します。

未完成の成果物・ソースコードの引き渡し条件を確認する

完成に至らなくても、それまでに作られたソースコードやドキュメントを引き渡してもらえる条件になっているかを確認します。

中止の申し出から契約終了までの手続き・期間を確認する

解約の意思表示から実際に契約が終了するまでの手続きと期間があらかじめ決まっていることで、中止の判断をした際にスムーズに進められます。

条件を決めている場合と決めていない場合、何が違う？

契約時に確認しておきたいポイントは？

1. 契約書に中断・解約に関する条項があるかを確認する：完成・納品の条件だけでなく、途中解約時の取り扱いが明記されているかを事前に確認します。
2. フェーズを区切った契約にできないか相談する：一つの大きな契約ではなく、フェーズごとに区切った契約にすることで、各フェーズの区切りで中止の判断がしやすくなります。
3. 中止の判断基準を社内であらかじめ決めておく：どのような状況になったら中止を検討するのかを発注者側で事前に整理しておくと、いざという時の判断が早くなります。

よくある質問

Q. 契約書に中止条件の記載がない場合、今から追加できますか？
A. 契約の変更として、双方合意の上で条項を追加することは可能です。進行中の契約であっても、早めに相談することをおすすめします。

Q. 途中解約を切り出すと、開発会社との関係が悪化しませんか？
A. 事前に条件を決めておけば、感情的な対立にはなりにくくなります。むしろ条件を曖昧にしたまま進める方が、いざという時の対立を招きやすくなります。

Q. 着手済みの費用はどのように計算されるのが一般的ですか？
A. 進捗度合いに応じた工数按分が一般的ですが、契約形態（準委任・請負）によって考え方が異なります。契約時に計算方法を具体的に確認しておくことをおすすめします。

Q. まずは何から確認すればいいですか？
A. 現在進行中の契約書に、中断・解約時の取り扱いに関する条項があるかを確認するところから始めてください。記載がなければ、次の契約更新や新規契約の際に条項化することをおすすめします。

あわせて読みたい：システム開発が納期に間に合わないとき、発注側が最初に確認すること

発信：株式会社オルアナ（新規事業開発・システム開発・AIエージェント開発・バックオフィス業務支援）