資料が5日遅れて、公開は3日遅れ。システム開発の納期は何で決まる？

たとえば、資料が5営業日遅れたのに、公開の遅れは3営業日。この差は、公開前に置いた2営業日の予備で説明できます。逆に、移行できる日が月に一度しかなければ、数日の遅れが翌月への持ち越しになることもあります。

納期を読むには、作る日数に加え、「何がそろうと次の仕事を始められるか」と、動かせる日程を見ます。受付アプリの6週間計画（想定例）で、資料待ちが公開日までどう届くかを追います。実際の日程は、機能・資料・担当者・移行条件から決めます。

作り終える日と、業務で使い始める日

「納品日」と「業務で使い始める日」を区別する

まず、見積書の「納期」が何を指しているかを確かめます。開発したものを渡す日なのか、利用者が試し終える日なのか、データを移して本番利用を始める日なのかで、逆算する出発点が違います。契約上の納品・検収と、運用上の公開・利用開始を、同じ意味だと決めつけないことが出発点です。

作業を整理すると、要件では目的・利用者・例外の扱いを決め、設計では画面やデータの形に落とし込み、実装でプログラムを作ります。その後、開発側のテストと利用者による業務上の確認を経て、既存データや運用を新しい仕組みに移します。公開後の問い合わせや初期不具合への対応も、担当と期間を別に決めておきます。始まった後に予定どおり進んでいるかを見分ける目安は、開発の遅れの兆候と確かめるものにまとめています。

この整理では、実装完了と利用開始を分けて扱います。たとえば「顧客一覧が表示される」ことを確かめる作業と、「元の台帳と件数・内容が合い、担当者が使える」ことを確かめる作業は同じではありません。試験や移行を省いた日付を、利用開始日として受け取らないようにします。

IPA「システム開発の健全化に向けて」（PDF）は、アジャイル型開発向けモデル契約の説明で、役割分担・協力、体制、スケジュールを扱っています。一方、この部分のモデルは本番リリース作業とシステム運用を含みません。以下の工程例では、業務で使い始める日まで見通すため、移行・公開・初期対応も含めています。

全部を直列に並べても、人数で割っても決まらない

資料の確認と環境の準備を並行できるなら、それぞれの日数を足すだけでは全体が長すぎる計画になります。反対に、先に入力項目が決まらなければ作れない部分は、担当者を増やしてもそのまま並行化できません。先行する作業が終わる条件と、実際に担当者を確保できる日を合わせて見ます。

何を待っているのか、誰が決めるのか

「資料待ち」とだけ書くと、誰が何を返せば進むのかが分かりません。資料をそろえる際には、ファイルとともに、項目の意味、例外時の扱い、使ってよい範囲も聞きます。

たとえばCSVの見本が届いていても、空欄が「未入力」なのか「対象外」なのか未確定なら、その扱いを決める必要があります。窓口担当者が回答を集める役割なのか、業務ルールを決められる責任者なのかも分けます。開発側は質問と回答期限、発注側は決定者と代理者を明らかにします。

外部サービスを使う案件なら、申込みや審査、接続情報の発行を別の予定として組みます。サービス名・契約プラン・必要書類・本番接続の条件を提供元の案内や窓口で確かめ、開発の予定だけから完了日を置きません。社内のアカウント発行やアクセス権限も、申請した日と実際に使える日を分けます。

利用者が試す段階では、画面ができるだけでは足りません。試すためのデータ、試す操作、期待する結果、回答する人、修正後にもう一度見る時間が必要です。「担当者が代表的な受付と取消を金曜までに試し、業務責任者が結果を返す」のように、操作・期限・終わり方まで決めます。

依頼時の記入例は、「CSV見本と項目の意味を、発注側のデータ担当がD5までに提供し、業務責任者が内容を確定。開発担当は不足を洗い出して返す」です。Dは着手から数えた営業日を表す、このあとの架空例の記号です。必要な資料を開発側が具体化する役割もあり、遅れを発注者だけの問題にしないことが前提です。

資料が5日遅れると、公開日はどう変わるか

比較する条件をそろえる

一つの部署で使う、受付入力・一覧・CSV取込を備えた業務アプリを考えます。希望する公開日はD30です。D1を着手日とし、1週を5営業日、6週間を30営業日として数えます。休日を含む暦日や特定のカレンダー日付には換算していません。相談・契約にかかる期間も、この着手後の計画とは別です。

各期間は、担当者の作業や試験を確保する日程上の枠です。一人の稼働量を表す人日とは区別します。環境・権限準備はD4〜17で完了し、外部審査による追加の遅れはないと仮定します。試験で生じる修正は予定の枠内に収まり、後工程の担当者や移行日もずらせる条件です。

図1　資料の確認・提供が予定どおり進む場合。公開はD30、公開前の予備はD28〜29の2営業日です。

図2　資料の確認・提供だけが5営業日遅れる場合。後工程は5営業日ずれますが、予備2日分を吸収し、公開はD30からD33へ3営業日ずれます。

二つの工程図で変わる点は、次の三つです。

• 動いた工程：資料を待つ実装と、その後のテスト・利用者確認・移行は5営業日ずれます。
• 動かない工程：要件・設計・環境準備は同じ日に終わります。資料を待たない仕事までずらす必要はありません。
• 使った予備：公開前の2営業日を使うため、公開はD30からD33へ3営業日の遅れになります。初期対応はD34〜38です。

資料の追加待ちが2日以内なら、同じ条件ではD30を維持できますが、その分だけ予備が減ります。後工程の担当者や移行日をずらせることが、この計算の前提です。

工程A〜Jの開始・終了日と計算の内訳

予定どおりなら、公開前に2営業日の予備を残す

要件確認AはD1〜3、資料確認・提供BはD1〜5です。要件確認後の設計CをD4〜5に行い、BとCの両方が終わると、実装DをD6〜15に進められます。環境・権限準備EはAの後、D4〜17に別担当も交えて並行します。

開発側テストFはD16〜20です。FとEが終わった後、利用者確認・修正・再確認GをD21〜23、移行リハーサル・本番移行HをD24〜27に行います。D28〜29を予備として残し、D30に公開I、D31〜35に公開後の初期対応Jを行う計画です。初期対応は、6週間の公開計画の外に明示しています。

資料の確認・提供が5営業日遅れると、公開は3営業日後ろへ

比較するのは同じ案件です。違いは、Bの資料がD5に確定せず、D6〜10の5営業日を追加で待ち、D10に提供が完了する点だけです。A・C・Eの予定と、後工程に必要な日数は変えません。利用者確認を含む後工程には、新たな待ちを加えていません。

Bを待つ実装DはD11〜20となり、テストFはD21〜25、利用者確認GはD26〜28、移行HはD29〜32へ移ります。設計Cと環境・権限準備Eは、それぞれD5とD17に終わるままです。資料に依存しない準備まで、機械的に後ろへ動かす必要はありません。

公開は、もとの希望日D30と移行完了翌日のD33の、遅い方になります。結果はD33で、公開の遅れは3営業日です。資料の遅れ5日のうち、公開前の予備2日分を吸収したためです。初期対応もD34〜38へ移ります。

短縮するなら、まず何を動かすか

この例で先に相談するのは、実装の増員より、Bの資料を確定できる人と期限です。データ担当が見本を用意し、業務責任者が意味や例外を判断できれば、実装開始を妨げる条件を外せます。ただし、不明点を仮置きしたまま作り始める場合は、後で変わる部分と作り直しの可能性を共有します。

範囲を絞るなら、初回に移す過去データの範囲や、利用する部署を減らせるかを検討します。CSV取込が業務切替に必要な本例では、それを単に後回しにすると移行条件を満たしません。必要な試験やデータの整合を残しつつ、何を後に回せるかを決め、変更後の日数を改めて計算します。短縮できる日数は、変更後の条件から確かめます。

工程の計算には、工程計算と日程確認のExcelを使えます。予定どおり・資料遅延の見本と空欄の記入用シートを収録しています。追加待ちや期間を変えると見本の公開日・予備が更新されます。空欄版の開始日は、先に必要な作業と担当者の予定を確認して記入してください。

希望日を守るために動かせる条件

希望日には理由を添えます。「新しい部署の開始日なので動かせない」のか、「できれば月初に切り替えたい」のかで、選択肢が変わります。公開日に必要な機能・対象者・移行データと、後の公開に回せる範囲を分けて相談します。

先ほどの条件でD30の公開を守るには、移行を遅くともD29までに終える必要があります。後工程の日数を逆算すると、Bの提供はD7までが限界です。ただし、D7は予備をすべて使った場合の最終期限です。普段は予定のD5を守り、予備を残します。

この逆算が通用しない例は、移行できる日が月に一度しかない案件です。資料が数日遅れただけでも、その枠を逃せば次の実施日まで待ちます。承認会議や外部審査、担当者の再確保も同じです。利用部門の責任者、情報システム担当、開発側の担当者、外部サービス提供元から、実施可能日と変更条件を集めます。

段階公開できるなら、最初は一部署だけで使い、他部署や古い履歴の移行を後に回す方法があります。手作業を続ける場合は、どの記録を正とするか、二重入力を誰が照合するか、いつ新しい仕組みに統一するかを決めます。初回公開の範囲を減らしても、切替までの仕事がなくなるとは限りません。

一方、既存画面の小さな修正では、すべての工程を独立した会議や週単位の仕事にする必要はありません。必要な試験を短い往復にまとめられる場合もあります。「全工程を別々に足す」「どんな案件でも6週間」と考えず、変更の影響範囲に合わせて組み直します。

見積りの日程について聞く5つの質問

IPAの「情報システム・モデル取引・契約書（第二版）」は、契約時に仕様、プロジェクト管理方法、検収方法などについて、双方が共通理解のもとで対話することを促しています。見積りの日程では、次の5点を聞きます。

① その日は何が終わる日ですか。納品、利用者確認の完了、公開、初期対応の終了を分けて記録します。

② まだ決まっていない条件は何ですか。必要な資料・判断・環境と、それをそろえる人、回答期限を聞きます。

③ こちらが試すには何が必要ですか。試す操作と期待結果、試す人、返答の方法、修正と再試験の時間をそろえます。

④ 予備はどこにありますか。どの遅れを何日まで吸収でき、使ったことを誰に知らせるかを聞きます。

⑤ 遅れそうなとき、いつ何を相談しますか。未完了の作業、止まる後工程、公開への影響、範囲・日程・体制の代案を共有します。

変更を相談するときは、単に新しい日付だけを上書きせず、何を変え、何を残すか、費用や担当への影響も合わせて話し合います。資料が遅れたときの納期や費用の扱いは、責任者を含めて協議し、その案件の合意内容と契約上の変更手順に沿って決めます（出典：IPA講演資料（PDF））。

準備する内容がまだ曖昧なら、開発相談前の要件整理｜受注から出荷の記入例で目的・利用者・判断ルール・例外を整理できます。費用や終了条件なども含めて相談前に整理したい場合は、初めてのシステム開発依頼で聞く7つの質問も参照してください。

まず希望する利用開始日と、その日を動かせない理由を書いてください。初回に必要な範囲、資料を出せる日、試せる担当者を添えると、具体的な日程を相談できます。NeoLogicでは、現在の仕事と残したい道具を伺い、必要な範囲から開発する進め方をご案内しています。

利用者が試すのに必要な日数は、試す仕事と、説明前の操作を観察する方法まで決めて計算します（画面試作で使いやすさを確かめる利用者テスト）。

希望日と準備条件をそろえて日程の相談へ

参考出典

• IPA「システム開発の健全化に向けて」2025年4月24日、PDF44〜48ページ。アジャイル型モデルの役割・協力・変更手続・日程項目を参照。確認日：2026年9月15日。
• IPA「情報システム・モデル取引・契約書（第二版）」2020年12月22日公開。「背景」「見直しのポイント」「構成とダウンロード」「利用時の注意事項」を参照。確認日：2026年9月15日。個別契約への条文適用は対象外。