システム開発は、計画どおりに進むとは限らない。要件の追加や認識のずれ、検証の手戻りなどによって、当初の納期からずれることは珍しくない。問題は遅延そのものよりも、遅延が起きたときに「誰の責任で、どう対応するか」が契約に定められていないことである。決め事がないまま遅延が長引くと、双方が相手の責任を主張し合い、関係も成果物も宙に浮きやすい。

本記事は、納期遅延や開発の中断・解除が起きたときに備えて、契約に定めておきたい取り決めを発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門の担当者である。なお、遅延の責任や契約解除の可否は民法などに関わる論点を含み、個別の判断は弁護士などの専門家への確認を前提としてほしい。本記事は一般的な備えの整理にとどまる。

結論：遅延・中断・解除の3場面を、起きる前に決めておく

納期や中断をめぐるトラブルを抑えるうえで、発注前に整理しておきたいのは次の3点である。

  • 遅延が起きたときの連絡・原因共有・対応のルールを決めておく
  • 開発を中断・解除する場合の条件と手続きを契約に書いておく
  • 途中で終わったときの成果物・支払い・データの扱いを明確にする

これらは「起きてほしくないこと」だが、起きてから決めようとすると合意が難しい。穏やかなうちに決めておくほど、いざというときの対応がスムーズになる。

納期遅延が起きる主な要因

遅延の責任を一方的に決めつける前に、遅延がどこから生じやすいかを整理しておくと、契約での備え方が見えやすい。

遅延の要因主に関わる側備えの方向性
要件の追加・変更発注者・委託先の双方変更管理のルールを定める
仕様の認識のずれ双方要件定義の確定と記録
委託先の体制・進捗管理委託先進捗報告と早期共有
発注者側の確認・回答の遅れ発注者確認の期限を双方で設定
外部要因（連携先の都合など）双方の管理外影響時の協議ルール

遅延は委託先だけの問題とは限らない。発注者側の確認の遅れや、要件変更も原因になる。だからこそ、責任を一方に押し付ける前提ではなく、原因を共有して対応を協議する仕組みを契約に持たせておきたい。変更が遅延につながる流れは変更管理の進め方で詳しく扱う。

遅延が起きたときの取り決め

遅延が生じたとき、何をどう進めるかをあらかじめ決めておくと、感情的な応酬を避けやすい。契約や運用ルールに含めておきたい観点を整理する。

早期共有のルール

遅延が見込まれた段階で、できるだけ早く共有する仕組みを設けておく。遅れが確定してから報告されるより、兆候の段階で共有されるほうが、リカバリーの選択肢が広い。定例の進捗報告と、想定からの乖離が出たときの臨時報告を分けて考えるとよい。

原因の切り分けと協議

遅延の原因が、要件変更によるものか、委託先の体制によるものか、発注者側の確認遅れによるものかを切り分け、対応を協議する。原因に応じて、スケジュールの見直しや費用の扱いを決める枠組みを契約に持たせておきたい。

スケジュール見直しの手続き

納期を見直す場合、口頭での合意にとどめず、変更後のスケジュールと前提を書面で残す。これは後の認識のずれを防ぐためにも重要である。

中断・解除に備える

開発を最後まで続けられず、途中で中断・解除に至ることもある。このとき備えが薄いと、成果物も支払いも宙に浮く。次の点を契約で確認しておきたい。

  • 中断・解除できる条件：どのような場合に、どちらの側が中断・解除を申し出られるか
  • 手続き：解除する際の通知の方法や、是正を求める猶予期間を置くか
  • 解除時の成果物の扱い：それまでに作られた成果物を、発注者が受け取れるか
  • 費用の精算：途中までの作業に対する支払いをどう清算するか

とくに重要なのが、途中で終わったときに「それまでの成果物を引き取り、他社や自社で続けられるか」である。ソースコードや設計書、関連する権利の扱いが曖昧だと、続きを作れず、最初からやり直しになりかねない。成果物に関わる権利については著作権・知的財産の扱いも確認しておきたい。

途中で終わったときの成果物・データ

中断・解除のときに、発注者が最も困るのが「続きを誰かに頼めるか」である。これを左右するのが、成果物とデータの扱いである。

項目確認したいこと
ソースコード途中段階でも引き渡しを受けられるか
設計書・仕様書第三者が続きを担える程度に整っているか
著作権・利用権続きの開発・改変に必要な権利があるか
データ投入済みのデータを返却・移行できるか
環境・アカウント開発・運用環境への移行が可能か

これらが整理されていれば、たとえ途中で関係が終わっても、別の体制で開発を続ける道が残る。逆に曖昧だと、成果物がありながら使えない、という事態になりうる。

解除をめぐって対立しやすい論点

中断・解除の場面は、双方の利害が真正面からぶつかりやすい。だからこそ、起きる前に取り決めておく価値が大きい。実際にもめやすい論点を整理しておく。

  • 解除の理由が正当か：一方が解除を申し出ても、相手がそれを正当と認めず、対立することがある
  • 是正の機会を与えたか：問題があった側に、改善のための猶予を与えたかが論点になりやすい
  • 途中成果物の評価：途中までの作業にどれだけの価値があったかで、支払いの認識がずれやすい
  • 損害の扱い：遅延や中断によって生じた損害を、どちらがどこまで負うか

これらの多くは、契約に取り決めがあるかどうかで、対立の長さが大きく変わる。たとえば「解除の前に是正を求める猶予期間を置く」と決めておけば、いきなりの解除をめぐる争いを避けやすい。途中成果物の精算方法をあらかじめ定めておけば、価値の評価をめぐる対立も和らぐ。なお、解除が正当か、損害をどこまで負うかといった点は民法などに関わる論点を含み、個別の判断は弁護士などの専門家への確認を前提に考えてほしい。

発注前に決めておきたいことの整理

遅延・中断・解除に備えて、発注前に契約や運用ルールで確認しておきたい点を一覧で整理する。

場面決めておきたいこと
平常時進捗報告の頻度と、想定からの乖離時の報告ルール
遅延時原因の切り分けと、スケジュール見直しの手続き
中断・解除時条件、通知の方法、是正の猶予期間
終了時途中成果物の引き渡しと、対応する支払いの精算
データ投入済みデータの返却・移行の可否

これらは、関係が良好なうちに決めておくほど合意しやすい。トラブルが起きてから取り決めようとすると、双方が身構え、合意が難しくなる。発注の段階で「うまくいかなかったとき」の章を一通り確認しておくことが、結果的に最も安価な備えになる。

遅延を早く察知する仕組み

遅延への最良の備えは、そもそも遅れを早く察知することである。遅れが深刻になってから気づくと、打てる手は限られる。発注者として、遅れの兆候を早めにつかむ仕組みを持っておきたい。

  • 節目ごとの確認：開発を一気に進めるのではなく、いくつかの節目を設け、その都度進み具合を確認する
  • 動くものを早めに見る：完成を待つのではなく、途中段階でも動くものを見せてもらい、認識のずれを早く見つける
  • 課題の見える化：解決していない課題や、判断待ちの事項を一覧で共有してもらう
  • 発注者側の宿題の管理：発注者が回答や確認を滞らせていないか、自分たちの宿題も見える化する

これらは、委託先を監視するためではなく、双方で同じ景色を見るための仕組みである。途中で動くものを確認できれば、「思っていたものと違う」というずれを早期に修正でき、納期への影響も小さくできる。逆に、完成まで中身が見えない進め方は、最後にずれが一気に表面化しやすい。節目の置き方や確認のタイミングは、発注前に委託先と相談しておきたい。

発注者側にも遅延の責任が生じる場面

遅延というと委託先の問題と捉えられがちだが、発注者側の動きが原因になることも少なくない。これを自覚しておくと、責任の押し付け合いを避け、現実的な対応に進みやすい。

  • 確認や回答が遅れる：委託先が判断を仰いでいるのに、発注者の回答が滞り、作業が止まる
  • 要件を途中で増やす：当初の範囲に次々と追加を求め、結果として全体が後ろ倒しになる
  • 意思決定者が不在：その場で決められる人がおらず、判断のたびに時間がかかる
  • 検証に協力できない：途中の確認やテストに発注者側の協力が必要なのに、人手を割けない

これらは、発注者として意識すれば改善できる部分が多い。委託先に回答の期限を伝えてもらい、自社側も判断を滞らせない体制を整えておくと、遅延の芽を減らせる。遅延が起きたときに「どちらが悪いか」で消耗するより、双方の動きを見直して原因を取り除くほうが、結果的に早くリカバリーできる。要件の追加が遅延につながる流れは、変更管理の仕組みで抑えられる部分も大きい。

よくある質問

Q1. 納期に遅れたら、委託先に違約金を求められますか

契約に遅延に関する取り決めがあるかどうか、また遅延の原因が誰にあるかによって変わる。一律に求められるとは限らず、要件変更や発注者側の確認遅れが絡む場合は判断が複雑になる。個別の可否は、契約内容をふまえて専門家への確認を前提に考えてほしい。

Q2. 開発を途中でやめたい場合、支払いはどうなりますか

途中までの作業に対する精算をどうするかは、契約の定め方による。それまでの成果物の引き渡しと、対応する支払いをセットで整理しておくのが現実的である。あらかじめ解除時の精算ルールを契約に書いておくと、もめにくい。

Q3. 中断したプロジェクトを別の会社に引き継げますか

引き継げるかは、成果物・設計書・権利・データが引き渡せる状態かに大きく左右される。これらが整理されていれば引き継ぎやすく、曖昧だと難しくなる。発注前に「途中で終わっても続けられる状態」を意識して契約を確認しておきたい。

遅延・中断に備えた取り決めを、発注前に整理しませんか

GXOでは、システム開発の契約にあたり、遅延時の対応ルール、中断・解除の条件、途中成果物の引き渡しといった「うまくいかなかったとき」の備えを発注前に整理するご支援を行います。

発注前の契約相談をする

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。