約 18 分で読めます
編集部イチオシタスク・担当・期日をひとつのボードで見える化
- かんばん・ガントチャート・カレンダーなど複数ビューをワンクリックで切替
- 日本語UI・日本語サポート対応（東京オフィスあり）
- 通知・担当割り当て・期日リマインドを自動化
- ダッシュボードで複数プロジェクトの進捗を一括把握
Delivery date（デリバリーデート）とは、製品・サービス・成果物を顧客に届ける約束の期日、つまり日本語の「納期」にあたる言葉です。この記事では、英語表現としての意味から出荷日（Shipping date）との違い、納期の計算方法、遅延を防ぐ4ステップの管理法、そしておすすめのツールまでを実務目線で解説します。
1. Delivery dateの意味 ｜ 英語と日本語「納期」の対応
Delivery date（デリバリーデート）とは、製品・サービス・プロジェクトの成果物を完成させ、顧客に納品する予定日を指します。 英語の直訳は「配達日・納品日」で、ビジネス文書や契約書では「the delivery date shall be…（納期は〜とする）」のように、履行期限を明確にする語として使われます。日本語では「納期」と訳すのが一般的で、「納期 英語」で検索すると必ずこの delivery date が出てきます。読み方はそのまま「デリバリーデート」です。
英語圏の Eコマースや物流システムでは、注文完了画面に「Delivery date: July 20」のように表示され、顧客が「いつ届くか（納期・届く日）」を判断する基準になります。一方、ソフトウェア開発や製造業といったプロジェクト管理の現場では、成果物を関係者に引き渡す期日という意味で使われ、すべてのステークホルダーの期待をそろえる「約束」として機能します。
納期を語るときは、次の三要素を分けて考えると管理がぐっと楽になります。
- 締め切り日（Deadline）：明確に合意された最終納品日。ここがブレると全体が崩れます。
- マイルストーン：最終納品に至るまでの中間目標。進捗を測る節目になります。
- 依存関係（Dependency）：納品前に完了しておくべき先行タスクやプロセス。ここを見落とすと連鎖遅延が起きます。
この三要素を最初に切り分けておくと、納期管理はぐっと現実的になります。私たちのチームでは、締め切り日・マイルストーン・依存関係をツール上のボードで可視化してから、進捗確認の抜け漏れが目に見えて減りました。
2. Delivery date・Shipping date・EDDの違い ｜ 比較表で一目
「Delivery date 出荷日」と検索する人が多いのは、この2つを混同しやすいからです。結論から言うと、出荷日（Shipping date）は商品が倉庫を出る日、Delivery date は顧客の手元に届く日であり、両者の間には「リードタイム（輸送日数）」が存在します。
Ship date（出荷日）とDelivery dateの違い
Ship date（出荷日）は、商品や成果物が発送元を離れるタイミングです。ここから輸送日数を加えたものが Delivery date（納期）になります。たとえば7月15日出荷・輸送3日なら、Delivery date は7月18日です。物流のトラッキング画面で「Shipped（出荷済み）」と「Delivered（配達完了）」が別々に表示されるのはこのためで、「Delivered date meaning（配達完了日の意味）」を調べる人は、実際に届いた日を確認したいケースが大半です。
Order date（注文日）とDelivery dateの違い
Order date（注文日）は顧客が注文を確定した日です。ここから Delivery date までを計算するには、次の2要素を足します。
Delivery date ＝ Order date ＋ 注文処理時間（order processing time）＋ 輸送日数（lead time）
注文処理時間は在庫引き当てや梱包にかかる社内リードタイム、輸送日数は配送業者が運ぶ期間です。この分解ができると、「なぜ注文から到着まで5日かかるのか」を顧客にもチームにも説明できます。
Estimated delivery date（EDD）とは
Estimated delivery date（EDD／配達予定日）は、確定値ではなく「見込みの納期」です。ECサイトの「お届け予定日」がこれにあたり、あくまで予測なので実際の Delivery date とはズレることがあります。約束値（commit）と予測値（estimate）を区別することが、顧客への正しい期待値設定につながります。
なお「Estimated date of delivery（EDD）」は妊娠の分野では「出産予定日」を意味し、最終月経開始日から約280日で算出されます（Delivery day pregnancy＝出産日）。医療の文脈では意味が変わりますが、ビジネスや物流では「配達予定日」を指すと覚えておけば十分です。
| 用語 | 日本語対応 | 定義 | 主に管理する人 | 変更可否 |
|---|---|---|---|---|
| Delivery date | 納期・配達日 | 顧客が受け取る期日 | PM・営業 | 交渉により変更可 |
| Shipping date | 出荷日 | 商品が倉庫を出る日 | 物流・倉庫担当 | 出荷準備次第で調整可 |
| Order date | 注文日 | 注文が確定した日 | 顧客・受注担当 | 変更不可（実績日） |
| Estimated delivery date | 配達予定日（EDD） | 到着の見込み日 | システム自動算出 | 状況で随時更新 |
| Delivery date（金融） | 受渡日・決済日 | 契約の履行日 | 取引所・約定条件 | 契約で確定 |
こうした日付の流れを一本のタイムライン上に並べると、どこで遅れが生じやすいかが直感的に見えるようになります。
3. Delivery dateの3つのビジネス文脈 ｜ EC・PM・金融
同じ Delivery date でも、業界によって意味合いが変わります。代表的な3つの文脈を押さえておきましょう。
Eコマース・物流での使い方
ECでは Delivery date（正確には EDD）が購買の意思決定に直結します。「明日届く」と表示されれば購入率が上がり、逆に「2週間後」なら離脱が増える——このくらい影響が大きい指標です。計算式は前述のとおり「注文日＋注文処理時間＋輸送日数」で、たとえばカットオフ時刻前の注文なら当日出荷、過ぎれば翌日出荷となり、着日が1日ずれます。
納期遅延のダメージは想像以上です。あるアパレルECでは、繁忙期に倉庫処理が滞り、表示上の配達予定日を3日超過しました。その結果、注文の一定数がキャンセルされ、レビュー評価も下がり、リピート購入の機会を失いました。EC事業では「表示した Delivery date を守れるか」が、そのまま信頼と売上に跳ね返ります。
プロジェクト管理（ソフトウェア・製造業）での使い方
当サイトの主戦場がこの文脈です。ソフトウェア開発では、Delivery date はスプリントやリリースの成果物を引き渡す期日を指します。製造業では、製品を顧客に納品する「製品納期」を意味します。どちらも共通するのは、要件定義の段階で成果物と期日を握り、キックオフミーティングで関係者全員に共有しておくことが遅延防止の第一歩だという点です。曖昧なまま走り出すと、後工程で必ず認識のズレが表面化します。
金融・先物取引でのDelivery date
「Delivery date 金融」で検索されるのは、先物取引の文脈です。ここでは Delivery date は「受渡日（決済日）」を意味し、先物契約で対象資産の受け渡しと決済が行われる期日を指します。契約時点であらかじめ確定しており、EC のように後から柔軟に変更できるものではありません。同じ英単語でも、金融では「約定にもとづく履行日」という厳格な意味を持つ、と覚えておけば混乱しません。
4. 納期に影響する主要因子 ｜ 遅延リスクを先読みする
納期を守れるかどうかは、次に挙げる因子をどれだけ事前に把握できているかで決まります。「予期せぬ遅延」の多くは、実は事前に読めるリスクの見落としです。
リードタイムとカットオフタイム
リードタイム（lead time）は、着手から完了までにかかる標準的な所要期間です。物流なら「出荷から到着まで」、開発なら「タスク着手から完了まで」を指し、これを正確に見積もれないと納期そのものが絵に描いた餅になります。
カットオフタイム（cut-off time）は「その日の処理を締め切る時刻」です。物流では出荷締め時刻を過ぎると翌営業日扱いになり、着日が1日後ろへずれます。ここで重要なのが、プロジェクト計画書の段階でバッファ（緩衝期間）を組み込むこと。私たちは、クリティカルなタスクには工程全体の10〜15%程度の余裕を持たせるようにしています。ギリギリの計画は、小さな遅れひとつで崩壊します。日々の作業の進み具合を追う工程管理の精度が、そのままバッファ設計の精度になります。
リソース制約と工数の優先順位
人員・予算・ツールといったリソースの制約は、納期遅延のもっとも一般的な原因です。対処の鍵は優先順位づけにあります。すべてを同時に進めようとせず、「重要度×緊急度」のマトリックスでタスクを4象限に振り分け、重要かつ緊急なものから着手します。あわせて工数管理で各タスクの必要工数を実数で把握しておくと、「この人員でこの納期は無理」という判断を早い段階で下せます。
通関・天候・祝日の影響（越境プロジェクト対応）
海外案件を扱うPMは、社内でコントロールできない外部リスクを事前チェックすべきです。着手前に必ず確認したい因子は次のとおりです。
- 通関（Customs）：書類不備や検査で数日単位の遅延が発生する
- 天候（Weather）：悪天候による輸送・現地作業の停止
- 祝日・ブラックアウト日：相手国の祝日や配送業者の稼働停止日
- 時差と稼働カレンダー：先方の営業日と自社のズレ
これらを納期計算の前提に織り込んでおくだけで、「想定外」の遅延は大幅に減らせます。
5. 納期を守る4ステップ ｜ 今日から回せる管理法
因子を把握したら、次は実際に納期を守るためのプロセスに落とし込みます。以下の4ステップは、そのまま日々の運用に組み込める形にしてあります。
Step1 スコープ確認と現実的な納期設定
まずプロジェクトスコープを確定し、そこから必要な作業量を見積もります。「非現実的な締め切り」は失敗の温床です。判断基準として、当初の見積もり工数を20%以上超える納期要求が来たら、その場で受けずに再交渉することをおすすめします。チームメンバーを巻き込んで見積もりの妥当性を検証し、達成可能なラインで合意する——これが後の全工程を安定させます。
Step2 クリティカルパスを活用したタイムライン設計
次にクリティカルパス（プロジェクト完了までの最長経路）を特定します。ここに乗っているタスクが1日遅れれば、納期も1日遅れる——だからこそ重点管理すべき経路です。ガントチャートで全工程を可視化し、依存関係を明示しましょう。中間マイルストーンは2〜3週間に1つのリズムで置くのが目安です。節目が近いほど軌道修正が効き、遠すぎると気づいたときには手遅れになります。
Step3 進捗追跡とステークホルダーへの定期報告
タスクとマイルストーンの進捗状況を定期的に追跡します。報告頻度は、動きの速い開発案件なら週次、長期の製造・建設案件なら月次が基本です。リソース制約が見えてきたら、この報告の場で早めに配分を見直します。ステークホルダーとのオープンで透明なコミュニケーションこそが、納期変更を「事故」ではなく「調整」に変える鍵です。
Step4 遅延発生時のエスカレーション手順
どれだけ準備しても遅延は起きます。大切なのは、感覚ではなく明確な基準で動くことです。私たちのチームでは次のルールを使っています。
- 予測遅延が3営業日を超えたら → 即時にステークホルダーへ通知
- 全体工期の10%を超える遅延が見込まれるなら → 納期そのものを再交渉
この基準をあらかじめチームとステークホルダーで共有しておけば、遅延の報告が遅れて問題が肥大化する事態を防げます。エスカレーションは「悪い知らせ」ではなく、早いほど価値があります。
6. 納期管理ツール比較 ｜ チームに合うのはどれ？
ここまでの4ステップを手作業やExcelで回すのは、チームが大きくなるほど無理が出ます。ツール選びの基準はシンプルで、チーム規模と必要な機能（依存関係・自動アラート・可視化）の2軸です。当サイトが実際に使っている2つを紹介します。
monday.com｜部門横断チームの納期管理に
monday.comは、当サイトのイチオシツールで、私たち自身が日々の業務管理に使っています。納期管理で効くのは次の3点です。
- 依存関係設定：先行タスクが遅れると後続の期日が自動でずれ、クリティカルパスの崩れが一目でわかる
- 自動期限アラート：期限接近や遅延を担当者へ自動通知
- ダッシュボードによる進捗可視化：複数プロジェクトの納期状況をひと目で把握
実際に私たちは、「タスクが2日以上遅延したら担当者へ自動通知される」自動化ルールを1つ設定しました。この仕組みは半年で20回以上作動し、そのたびに問題が大きくなる前に手を打てました——以前は週次会議まで気づけなかった遅れです。10人以上の部門横断チームに特に向いています。
料金は無料プラン（最大2ユーザー・3ボード）から、ベーシックUS$9/月、スタンダードUS$12/月、プロUS$19/月、エンタープライズは要問い合わせです。世界で25万社以上が利用し、東京にオフィスがあり日本語UI・日本語サポートにも対応しています。有料機能もプロプランの14日間無料トライアルで試せるので、まず使い勝手を確かめてから判断できます。
Notion｜個人・小規模チームのドキュメント一元化に
Notionは次点のおすすめで、ドキュメントとタスクを1か所にまとめたいチームに最適です。納期管理の観点では以下が強みです。
- Timeline ビュー：タスクを時間軸で並べ、納期の重なりを可視化
- データベース連携：仕様書・議事録・タスクをひとつのワークスペースで紐づけ
- 柔軟なカスタマイズ：チームのやり方に合わせて自由に設計できる
1〜10人のスタートアップやフリーランスなど、「まずドキュメントとタスクを一元化したい」段階のチームにぴったりです。料金はフリー（US$0）から、プラスUS$10/月、ビジネスUS$20/月、エンタープライズは要問い合わせ。年間プランで最大20%お得になります。
ClickUp｜依存関係と納期アラートを細かく組みたいチームに
ClickUpはタスクの依存関係設定と納期の自動通知を標準で備え、遅延が後工程に与える影響を追いやすいのが特徴です。無料プランでもメンバー数・タスク数が無制限なので、まずチーム全員で納期管理の運用を試すハードルが低い点も魅力です。有料プランは Unlimited が US$7/月（年間払い表示）からで、最新の料金は公式サイトでご確認ください。
機能比較表とチーム別の選び方
| ツール | 納期アラート | ガントチャート | 依存関係設定 | 無料プラン | はじめる |
|---|---|---|---|---|---|
| monday.com | 自動通知あり | あり | あり | あり（2名まで） | 無料トライアル → |
| Notion | リマインダー | Timelineビュー | データベース連携 | あり | 無料で始める → |
| ClickUp | 自動通知あり | あり | あり | あり（無制限） | 無料で始める → |
自分のチームがどれに当てはまるか、目安は次のとおりです。
- 5人以下・個人、はじめての納期管理 → まずNotionの無料プランから
- 5〜15人の部門横断コラボレーション → monday.com（当サイトイチオシ）
- 開発チームでScrum運用 → ClickUp（無料プランでもタスク・メンバー数無制限）
- 15人以上の大規模プロジェクト → monday.comのエンタープライズ
まとめ
Delivery date（納期）は、顧客満足と効率的なプロジェクト管理を左右する最重要指標です。要点を整理します。
- Delivery dateとは、成果物を顧客に届ける約束の期日（日本語の「納期」）で、業界により意味が少し変わる
- Shipping date（出荷日）は倉庫を出る日、Delivery dateは顧客に届く日で、両者の差がリードタイム
- 納期は「注文日＋処理時間＋輸送日数」で計算でき、EDD（配達予定日）は予測値である
- 遅延はリードタイム・カットオフ・リソース制約・通関・天候・祝日など、多くが事前に読める因子から生じる
- スコープ確認 → クリティカルパス設計 → 進捗追跡 → エスカレーションの4ステップで、納期は守れる
- 一貫して納期を守ることが、クライアントとの長期的な信頼構築につながる
次のアクションは明確です。まずmonday.comでテンプレートから新しいボードを作り、プロジェクトの成果物・締め切り日・依存関係を埋めてみてください。10分ほどで最初の納期管理の骨組みが完成し、この記事の4ステップをそのまま運用に乗せられます。有料機能もプロプランの14日間無料トライアルで試せるので、リスクなく始められます。
よくある質問（FAQ）
Delivery dateとShipping dateは何が違いますか？
Shipping date（出荷日）は商品や成果物が発送元を離れる日、Delivery date（納期）は顧客が実際に受け取る日です。両者の間には輸送日数（リードタイム）があり、たとえば出荷日が3日前でも、到着日が Delivery date になります。
納期が守れない場合、どうすればいいですか？
早い段階でのエスカレーションが基本です。予測遅延が3営業日を超えたら即座にステークホルダーへ通知し、全体工期の10%を超える遅延が見込まれる場合は納期そのものを再交渉します。遅延を隠さず、原因と対応策をセットで共有することが信頼維持の鍵です。
Estimated delivery dateはどのように計算しますか？
「注文日＋注文処理時間＋輸送日数（リードタイム）」で算出します。カットオフ時刻前の注文なら当日出荷、過ぎれば翌営業日出荷となり着日がずれます。EDDはあくまで予測値なので、通関や天候、祝日などの外部要因で実際の納期と前後することがあります。
「Delivery date」は英文契約書でどう使いますか？
契約書では履行期限を示す語として「The delivery date shall be July 20（納期は7月20日とする）」のように使います。納期の遅延に対する違約金条項とセットで規定されることが多く、確定した期日を意味するため、後から一方的に変更できない性質を持ちます。
プロジェクト管理とeコマースで、Delivery dateの定義は同じですか？
基本の意味は「顧客に届ける期日」で共通しますが、対象が異なります。ECでは商品が顧客に到着する日を指し、多くは予測値（EDD）です。プロジェクト管理では成果物を関係者に引き渡す期日を指し、要件定義やキックオフで合意した確定的な約束として扱われます。