システム開発のトラブルで納期がずれた時の調整の進め方

「納期に間に合いません」と言われた、その瞬間から

システム開発を進めていたある日、開発会社から「トラブルが起きて、当初の納期には間に合いません」という連絡が入る。予定していた稼働日はもう社内に告知済みで、関連する業務や取引先とのやり取りもその日程を前提に動いている——。発注側にとって、これは頭が真っ白になる瞬間です。

こうしたとき、多くの発注者はまず感情が先に立ちます。「なぜ今になって言うのか」「約束したはずだ」「とにかく予定通りに間に合わせてほしい」。その気持ちは当然ですが、残念ながら、怒りや叱責をぶつけるだけでは納期は戻ってきません。すでに遅れが確定した状況で必要なのは、犯人を追及することではなく、ここからいかに傷を浅くして着地させるかという、冷静な調整です。

納期がずれること自体は、システム開発では決して珍しくありません。本当に問われるのは、ずれたときにどう振る舞うかです。この記事では、納期遅延というトラブルに直面した発注側が、感情的な対立に陥らず、事態を前に進めるための調整の進め方を解説します。

「予定通りにしろ」と迫っても、事態は改善しません

納期がずれたと知らされたとき、発注側が「とにかく当初の予定を守れ」と押し切ろうとするのは、実は最も事態を悪化させやすい対応です。すでに物理的に間に合わない状況で無理を通そうとすれば、開発現場はさらに追い詰められます。

追い詰められた開発チームは、テストを省略したり、確認を飛ばしたりして、見かけ上の納期に間に合わせようとしがちです。その結果、リリースはできても不具合だらけで、稼働後に次々と問題が噴出する——納期は守ったが品質が崩壊するという、より深刻な事態を招きます。無理な短縮は、遅延という問題を、品質トラブルという別の問題にすり替えているにすぎません。

また、遅延の原因を一方的に開発会社の責任と決めつけて対立姿勢を取ると、必要な情報が上がってこなくなります。本当は何が起きているのか、どこまでなら現実的に間に合うのか——正確な状況把握こそが調整の出発点なのに、対立はその情報の流れを止めてしまいます。だからこそ、遅延が起きた局面で発注側に必要なのは、感情的な圧力ではなく、事実を冷静に把握し、そこから最善の着地点を一緒に探す姿勢なのです。

犯人探しではなく、「傷を最小化する着地」を設計する

この記事で提案するのは、納期がずれたという事実を受け止めたうえで、発注側が主導して「今から取れる最善の着地点」を設計するという進め方です。目的は、誰が悪いかを決めることではなく、事業への影響を最小化することに置きます。

発注側が主導し、事実確認と優先順位の再設定で最善の着地点を設計する

なぜこの姿勢が有効かというと、遅延が確定した後にコントロールできるのは「過去の原因」ではなく「これからの進め方」だけだからです。すでに起きた遅れを巻き戻すことはできませんが、残りをどう組み立てるかは、発注側の判断でいくらでも変えられます。何を優先し、何を後回しにし、いつ・どの形で世に出すか——ここに主体的に関わることで、被害の大きさは大きく変わります。

この着地設計ができると、二つの効果が生まれます。ひとつは、無理な短縮による品質崩壊を避けつつ、事業として許容できる範囲に遅延を収められること。もうひとつは、開発会社と対立せず同じゴールを向くことで、正確な情報が共有され、以降の進行が安定することです。次の章から、その具体的な進め方を3つのステップで見ていきます。

納期がずれた時に発注側が踏むべき3ステップ

やるべきことは、技術的な巻き返し策を考えることではありません。事実を正確に把握し、優先順位を組み直し、現実的なスケジュールに落とす——この3つを押さえることで、混乱を着実な調整に変えられます。

ステップ1：何が・なぜ・どれだけ遅れているのかを切り分ける

まず最初にやるべきは、遅延の状況を正確に把握することです。感情的な「間に合うのか間に合わないのか」ではなく、「どの機能が・なぜ・あとどれくらい遅れる見込みなのか」を、開発会社と一緒に具体的に洗い出します。全体が一律に遅れているのか、特定の難所だけが詰まっているのかで、打てる手はまったく変わります。

ここで大切なのは、責める口調ではなく、状況を共有してもらうための問いかけをすることです。「なぜ遅れたんだ」と詰めるのではなく、「今どこで詰まっていて、何があれば進むのか」を聞く。正確な現状が分かって初めて、次の判断ができます。曖昧な「頑張ります」で終わらせず、事実ベースの見通しを引き出すことが、調整の土台になります。

ステップ2：全機能を諦めず「まず出すもの」と「後回し」を分ける

次に、当初予定していた機能を、優先順位で仕分けます。納期がずれたとき、「全部を予定通り」か「全部が遅れる」の二択で考えてしまうと、身動きが取れなくなります。そうではなく、「事業に不可欠で、まず出すべき機能」と「後からでも間に合う機能」を切り分けるのです。

コア機能だけを予定に近いタイミングで先行リリースし、優先度の低い機能は次の段階に回す。この段階的な着地ができれば、遅延の影響を事業の本丸から遠ざけられます。ここで判断の主導権を握れるのは、何が事業にとって重要かを知っている発注側だけです。開発会社に「どれを優先しますか」と委ねるのではなく、発注側が優先順位を明確に示すことが、現実的な着地への近道になります。

ステップ3：現実的なリスケジュールと、社内外への影響調整を同時に進める

最後に、仕分けた優先順位に基づいて、無理のない新しいスケジュールを開発会社と合意します。再び守れない納期を設定しては意味がないので、バッファを含んだ現実的な線を引くことが重要です。あわせて、遅延によって影響を受ける社内の関係者や取引先への説明・日程調整も、発注側の役割として並行して進めます。

新しいスケジュールと影響範囲が固まれば、混乱は「管理された遅延」に変わります。そのうえで、なぜ遅れたのかと再発防止策を記録に残しておけば、次の開発に活かせます。とはいえ、遅延の最中に事実確認・優先順位づけ・リスケジュールを発注側だけで回しきるのは、専門知識の面でも負荷の面でも簡単ではありません。状況の切り分けや現実的な工程の引き直しに不安がある場合は、アトリエ・バイナリ（atelier binary）のような開発の伴走支援に相談し、着地設計を一緒に組み立ててもらうのも、傷を浅くする現実的な選択肢です。

現実的なリスケジュールと社内外への影響調整で、混乱を管理された遅延に変える

こんな場面では、冷静な調整が事態を分けます

以下のような状況にあるなら、感情的な対応ではなく、この記事で示した調整の進め方が着地の質を大きく左右します。

開発会社から「納期に間に合わない」と告げられ、どう対応すべきか迷っている
稼働日を先に社内外へ告知しており、遅延の影響が広範囲に及ぶ
全機能を予定通りに揃えることに固執し、身動きが取れなくなっている
つい開発会社を責めてしまい、正確な状況が共有されていない

納期遅延というトラブルは、起きてしまった以上は戻せません。しかし、その後にどう調整するかは、発注側の振る舞い一つで大きく変わります。犯人探しに時間を使うほど着地は遠のき、冷静な調整に切り替えるほど傷は浅くなります。

まとめ

発注側と開発側が同じゴールを向き、管理された着地にたどり着く

システム開発のトラブルで納期がずれたとき、「予定通りにしろ」と迫るだけでは事態は改善しません。無理な短縮は品質崩壊を招き、対立姿勢は正確な情報の流れを止めてしまいます。遅延が確定した局面でコントロールできるのは過去ではなく、これからの進め方だけです。

傷を最小化する鍵は、犯人探しではなく着地設計に切り替えることです。何が・なぜ・どれだけ遅れているのかを事実ベースで切り分け、全機能を諦めず「まず出すもの」と「後回し」を仕分け、現実的なリスケジュールと社内外への影響調整を同時に進める。この3ステップで、混乱を「管理された遅延」に変えられます。

もし今まさに納期遅延に直面しているなら、まずは「どの機能が・なぜ・あとどれだけ遅れるのか」を開発会社と具体的に洗い出すところから始めてみてください。事実が見えれば、次の一手は必ず見つかります。自社だけで着地を設計しきれないと感じたら、開発の伴走支援に相談するのも有効な一手です。納期に振り回される開発から、ずれても立て直せる開発へ——その分かれ目は、遅延を知った瞬間の冷静な調整から始まります。