システム開発のリリース日が遅れると言われたら？最初の48時間でやることと「期日を守るか・延ばすか」の決め方

イベントや新年度の開始日に合わせて準備してきたシステムについて、開発会社から「リリース日が遅れそうです」と連絡が来た。社内への説明、告知済みのお客様、イベントの準備……頭が真っ白になるのは当然です。システム開発の納期遅延は珍しいことではありませんが、最初の動き方で、その後の選択肢の数が大きく変わります。

先に結論をお伝えします。最初の48時間は、責任を問うより「何が・どれだけ・なぜ遅れるのか」と「新しい見通しの根拠」を確かめることに使ってください。そのうえで「範囲を絞って期日を守る」「段階的にリリースする」「期日を延ばす」「暫定運用でしのぐ」などの選択肢を並べて比べ、決めたことは書面に残します。

この記事では、リリース日の遅れを告げられた発注者が、事実確認から社内説明、契約の確認、再発防止までに何をすればよいかを順番に解説します。遅れの「兆し」に気づく方法は、システム開発の進捗報告が「順調です」ばかりで不安なときは？で紹介しているので、ここでは「遅れると言われた後」に絞ります。

システム開発のリリースが遅れるのはなぜか

遅れの原因は、開発会社の力不足だけとは限りません。日本情報システム・ユーザー協会（JUAS）の調査では、工期（＝開発期間）が予定どおりにならなかった要因として、複数回答で次の項目が上位に挙がっています。

📰 出典：JUAS（日本情報システム・ユーザー協会）「企業IT動向調査報告書 2026」

• 計画時の考慮不足（52.5％）
• 想定以上の現行業務・システムの複雑さ（48.8％）
• 仕様変更の多発（42.4％）

これは2025年度調査で、工期が「予定より遅延」と回答した企業に聞いた結果です。計画の甘さ、作り始めてから分かる業務の複雑さ、途中の変更といった、発注者と開発会社の双方が関わる要因が上位に並んでいることが分かります。

つまり、遅れへの対応は「誰が悪いか」を決める作業ではなく、「残りの期間で何を実現するか」を一緒に組み直す作業です。この前提に立つと、次の一手が選びやすくなります。

最初の48時間でやること：遅れの「中身」を確かめる

「遅れます」という一言だけでは、判断材料になりません。まずは次の4点を、開発会社にできるだけ具体的に確認しましょう。

1. 何が、どれだけ遅れるのか

システム全体が遅れるのか、特定の機能だけが遅れるのかで、打てる手はまったく違います。

• 遅れるのはどの機能・どの作業か（画面、外部サービスとの連携、データ移行、テストなど）
• 予定どおり終わる部分はどこか
• 遅れは何日（何週間）の見込みか

「予約機能だけが2週間遅れる」と分かれば、その機能を後回しにして期日を守るという選択肢が生まれます。

2. なぜ遅れるのか

原因によって、今後さらに遅れるかどうかが変わります。「技術的な問題が見つかった」「想定より業務が複雑だった」「担当者が抜けた」「こちらの回答待ちが続いた」など、なるべく具体的に聞きましょう。

IPA（情報処理推進機構）と経済産業省が公開しているモデル契約書のひな型でも、定期的な協議の場で開発会社が進捗の報告を出し、遅れている事項があるときはその理由と対応策を確認することが想定されています。遅れの理由を尋ねるのは、発注者として自然な確認です。

📰 出典：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」

3. 新しい見通しの根拠は何か

いちばん大事なのがここです。「◯月◯日には出せます」という新しい日付が、何を根拠に出されたものかを確かめてください。

• 残りの作業を洗い出したうえでの日付か、希望的な目安か
• その日付を守るための前提条件は何か（発注者の回答期限、テストへの参加など）
• さらに遅れるとしたら、どんなリスクが考えられるか

根拠の薄い日付で社内やお客様に再告知すると、二度目の延期が起きたときの信頼の傷はずっと深くなります。

4. 自社側に原因や打てる手はないか

仕様の質問への回答や、テストデータの準備が止まっていないかも確認しましょう。自社のボールが残っているなら、まずそれを片づけるのが最も早い対策です。

確認すること	聞き方の例
遅れる範囲	「予定どおり終わる機能と、遅れる機能を分けて教えてください」
遅れる期間	「何日遅れる見込みで、その幅はどのくらいありますか」
原因	「遅れの主な原因は何ですか。今後も影響しそうですか」
新しい日付の根拠	「その日付は、残り作業をどう見積もって出したものですか」
自社側の課題	「こちらの回答や準備で止まっているものはありますか」

期日を守るか・延ばすか：5つの選択肢を比べる

事実が分かったら、選択肢を並べて比べます。どれか1つに決める必要はなく、組み合わせることもよくあります。

選択肢	内容	向いている場面	注意点
範囲を絞って期日を守る	遅れている機能を外し、必須の機能だけで予定日に出す	期日が動かせず、遅れが一部の機能に限られる	外した機能を「いつ・いくらで」入れるかを決めておく
段階リリース	予定日に第1弾、数週間後に残りを出す	イベント当日に最低限の機能があれば成り立つ	2回分のテスト・告知・社内説明が必要になる
人員を追加する	開発の担当者を増やして巻き返す	作業が分けやすく、まだ期間に余裕がある	終盤の追加は引き継ぎに時間を取られ、効果が出にくいと一般的に言われる。費用も増える
期日を延ばす	品質を確保したうえで新しい日付を決め直す	期日を動かしても事業への影響が小さい	新しい日付の根拠を確認する。関係者への再告知が必要
暫定運用でしのぐ	当面はExcel・紙・既存のサービスなどで業務を回す	イベント期間だけ乗り切れればよい	現場の手間が増える。データを後で新システムへ移す方法を決めておく

イベントに合わせていた場合は「イベントに最低限必要なもの」から逆算する

イベント日程にリリースを合わせていた場合、日付をずらすのは簡単ではありません。そこで考えたいのが、「イベント当日に、これさえ動いていれば成り立つ」ものは何かです。

たとえば申し込みの受付さえできれば、確認メールの自動送信や管理画面の集計は、当面は手作業で代わりにできるかもしれません。イベントの目的に立ち返って「必須」を絞り込むと、範囲の縮小・段階リリース・暫定運用を組み合わせた現実的な案が見えてきます。機能を入れる・外す・後に回すという考え方は、システム開発の途中で仕様変更したい！どこまで変えていい？でも詳しく紹介しています。

「『全部はムリでも、ここまでなら確実に間に合います』と一緒に線を引けると、開発側も品質を落とさずに全力を出せます」

一方で、テストを削って無理に期日に間に合わせるのは避けたい選択です。リリース後に不具合が出ると、イベント当日にかえって大きな混乱につながります。

社内とお客様への説明：相手ごとに伝える中身を変える

方針の候補が見えたら、関係者に説明します。相手によって知りたいことが違うので、伝える中身を分けると話が早く進みます。

相手	知りたいこと	伝える内容の例
経営層	事業への影響と、判断してほしいこと	遅れの範囲と原因、選択肢ごとの費用・リスク、いつまでに何を決めてほしいか
現場（使う部署）	自分たちの業務がどう変わるか	使える機能と使えない機能、暫定運用の手順、問い合わせ先
顧客・取引先	自分たちへの影響と代わりの手段	何がいつから使えるか、それまでの代替手段、お詫びと連絡窓口

経営層への報告では「遅れます」だけで終わらせず、選択肢と、決めてほしい期限をセットで持っていくのがポイントです。お客様への告知は、新しい見通しの根拠を確認してから出しましょう。確定していない日付を公表すると、再延期のときに説明が難しくなります。

契約で確認しておきたいこと（一般論）

遅れの影響が大きいと「損害賠償を請求できるのか」が気になるかもしれません。ここでは一般的な考え方だけを紹介します。実際の判断は契約書の内容と個別の事情によって大きく変わるため、必ず弁護士などの専門家に確認してください。

遅延の責任と損害賠償

民法では、債務者（ここでは約束した仕事をする側）が約束どおりに履行しないとき、債権者は損害の賠償を請求できるとされています。ただし、その不履行が契約や取引上の社会通念に照らして債務者の責めに帰することができない事由によるときは、この限りでないとされています（第415条）。また、損害の発生や拡大に債権者側の過失があった場合には、それが考慮されるという定めもあります（第418条）。

📰 出典：e-Gov法令検索「民法」

さらに、多くの開発契約では、損害賠償の範囲や上限額、請求できる期間を個別に定めています。前述のIPAのモデル契約書のひな型でも、損害賠償の累計額の上限や請求期間を、契約ごとに決める形になっています。まずは自社の契約書で、納期の定め方と損害賠償の条項を確認しておきましょう。

発注者の「協力義務」

同じモデル契約書の解説では、システム開発は発注者と開発会社の共同作業と分担作業で進むものとされ、それぞれが自分の分担作業を遅らせたり実施しなかったりした場合には、相手方に対して責任を負うという条文例が示されています。解説の中では、開発会社のプロジェクトマネジメント（＝進行を管理し、妨げになる要因に対処すること）の義務と、発注者の協力義務がどちらも裁判で問題になることが多いと紹介されています。

つまり、遅れの原因に発注者側の回答の遅れや大量の追加要望が含まれていれば、責任の考え方にも影響しうるということです。責任の話を急ぐより、まずは事実を記録に残し、冷静に確認することをおすすめします。

合意したことは書面に残す

範囲の縮小、日程の変更、追加の費用などが決まったら、変更内容・新しい日程・費用の扱いを書面（変更の合意書や記録票など）に残し、双方の責任者が確認しましょう。口頭の約束だけでは、後から認識がずれたときに確かめる手段がありません。

遅れを告げられたときにやりがちな失敗

• 感情的に責めてしまう：その後の悪い知らせが上がりにくくなり、次の遅れに気づくのが遅れます
• 根拠を確かめずに新しい日付を告知する：二度目の延期は、一度目よりずっと信頼を損ないます
• 「人を増やせば間に合うはず」と決めつける：終盤の増員は、引き継ぎの負担で逆効果になることもあります
• テストを削って期日に合わせる：リリース後の不具合で、イベント当日の混乱が大きくなりかねません
• 変更を口頭で済ませる：何を外し、何をいつ入れるのかが曖昧なまま進んでしまいます

次のプロジェクトで遅れに備える方法

今回の対応が落ち着いたら、次に向けて次のような備えを検討しましょう。

• 期日の理由と「動かせる度合い」を最初に伝える：イベントなど動かせない期日があるなら、発注時点で開発会社と共有します
• 「必須」と「あれば嬉しい」を最初から分けておく：遅れたときに外せる機能が、すぐに分かります
• イベント日の直前ではなく、余裕を持ったリリース日にする：テストや手直しの期間を確保できます
• 途中の目標日（マイルストーン）を置く：「◯日までに画面のデモ」のように区切ると、遅れに早く気づけます
• 自社側の回答期限と判断する人を決めておく：発注者の回答待ちによる遅れを防げます
• 暫定運用の手段を事前に用意しておく：万一のときの「逃げ道」があるだけで、判断に余裕が生まれます

発注者がやることチェックリスト

• ☐ 遅れる機能・作業と、予定どおり終わる部分を分けて確認した
• ☐ 遅れの原因と、今後さらに遅れるリスクを聞いた
• ☐ 新しい見通しの日付と、その根拠・前提条件を確認した
• ☐ 自社側の回答待ち・準備の遅れが残っていないか確認した
• ☐ イベント当日に最低限必要な機能を洗い出した
• ☐ 選択肢（範囲の縮小・段階リリース・増員・延期・暫定運用）を比べた
• ☐ 経営層・現場・お客様への説明内容を分けて準備した
• ☐ 契約書の納期・変更手続・損害賠償の条項を確認し、必要に応じて専門家に相談した
• ☐ 決まった変更内容・日程・費用を書面に残した

開発会社への質問例

• 「予定どおり終わる機能と、遅れる機能を分けて教えていただけますか？」
• 「新しいリリース日は、残りの作業をどのように見積もって出したものですか？その日付を守るために、こちらが守るべき期限はありますか？」
• 「遅れている機能を外して予定日に出す場合と、全部そろえて延期する場合で、品質・費用・日程はどう変わりますか？」
• 「今から人を増やした場合、実際にどのくらい効果が見込めますか？逆効果になる心配はありますか？」
• 「こちらの回答や準備で止まっているものがあれば、すべて教えてください」

まとめ：遅れは「事実確認」と「選択肢の比較」で乗り切る

リリース日の遅れを告げられたら、次の順番で進めるのがおすすめです。

• 最初の48時間で「何が・どれだけ・なぜ遅れるのか」と「新しい見通しの根拠」を確認する
• 範囲の縮小・段階リリース・増員・延期・暫定運用を並べ、イベントに最低限必要なものから逆算して選ぶ
• 経営層・現場・お客様には、相手ごとに伝える内容を分けて説明する
• 契約の扱いは自己判断せず、契約書を確認のうえ専門家に相談する
• 決めたことは書面に残し、次のプロジェクトの備えにつなげる

遅れの連絡は、早く届くほど打てる手が多く残ります。開発会社と「残りの期間で何を実現するか」を一緒に組み直す姿勢で臨めば、イベントの成功という本来の目的に近づけるはずです。

あわせて読みたい関連記事