「この案件、リードタイムはどれくらい？」――会議でそう聞かれて、「納期は今月末です」と答えたら、微妙な間が流れた。聞かれているのは期日ではなかったらしい。でも、納期と何が違うのか、その場では説明できなかった――こんな経験はないでしょうか。
結論から言えば、リードタイムとは「発注（依頼）から納品（完了）までにかかる時間の総量」です。納期が「いつまでに」というカレンダー上の期日を指すのに対し、こちらは「どれくらいかかるか」という所要時間を指します。似ているようで、指しているものがまったく違う言葉です。
私はAIタスク管理アプリ「するたす」を開発・運営しています。本記事では、この言葉の意味と納期との違い、製造・物流・開発それぞれでの使われ方、そして「短縮はどこから考えるか」を、専門用語を正確に保ちながら平易に整理します。最後に、個人の仕事への応用までつなげます。
仕事の流れを組み立てる基本から知りたい方は「段取りとは？意味と組み立て方の基本」を、工程の流れを見える化する方法は「ガントチャートの作り方と使い方」を併せてご覧ください。
リードタイムとは｜発注から納品までにかかる時間の総量
まず正面からお答えします。リードタイムとは、あるプロセスの起点（発注・受注・依頼・着手など）から終点（納品・完了・到着など）までに経過する時間の総量のことです。「発注から納品まで5日」「受注から出荷まで3日」のように、通常は日数や時間の長さで表します。
ポイントは「実作業だけでなく待ちも含む」こと
定義で見落とされやすいのが、この時間には実際に手が動いている作業時間だけでなく、承認待ち・順番待ち・輸送中などの「待ち時間」もすべて含まれるという点です。作業そのものが2日で終わる仕事でも、途中に3日の承認待ちが挟まれば、起点から終点までは5日。外から見た「かかった時間」は、この5日の方です。後述する短縮の話は、すべてこの性質が出発点になります。
納期との違い：納期は「期日」、こちらは「所要時間」
納期は「7月31日までに納める」というカレンダー上の点（期日）です。一方リードタイムは「発注から納品まで10日かかる」という長さ（所要時間）です。この2つは逆算でつながります。納期が7月31日で、所要時間が10日なら、遅くとも7月21日には発注しなければ間に合わない――このように、期日から着手時点を割り出すための物差しとして使われます。冒頭の会議で聞かれていたのは「期日はいつか」ではなく「頼んでからどれくらいで手元に来るのか」だった、というわけです。
サイクルタイム・タクトタイムとの違い
製造の現場では似た言葉が並ぶので、簡単に整理しておきます。サイクルタイムは1つの工程・1個の製品にかかる実際の作業時間、タクトタイムは需要量から逆算した「1個あたりに割ける時間」です。これらが個々の工程のペースを表すのに対し、こちらは工程間の待ちも含めた、起点から終点までの全体の経過時間を表す点が違います。
製造・物流・開発での使われ方｜代表的な4つの区分
一口に言っても、どこからどこまでを指すかは分野や文脈で変わります。代表的な区分を押さえておくと、会話の行き違いが減ります。
代表的な4つの区分
- 発注（調達）リードタイム：資材や商品を発注してから、自分の手元に届くまでの時間。仕入れ計画や在庫管理の基準になります。
- 生産（製造）リードタイム：製造に着手してから製品が完成するまでの時間。工程ごとの作業と、工程間の待ちの合計です。
- 配送（出荷）リードタイム：出荷してから届け先に到着するまでの時間。ECや物流の「お届けまでの日数」はこれにあたります。
- 開発リードタイム：開発の依頼（または着手）から、リリース・納品までの時間。ソフトウェア開発では、着手から本番反映までの時間を指すことが多い区分です。
全体の流れで見ると、「発注→生産→配送」の各区間の合計が、顧客から見た「頼んでから届くまで」になります。区間ごとに分けて把握しておくと、どこで時間を使っているかを特定しやすくなります。
起点・終点・数え方は現場ごとに確認する
注意したいのは、起点と終点の定義、営業日で数えるか暦日で数えるかは、会社や取引先によって異なることです。「発注日を含むのか」「着荷までか検収までか」で数日ずれることは珍しくありません。数字だけをやり取りせず、「どこからどこまでを、何日単位で数えているか」を最初にすり合わせておくのが、行き違いを防ぐ一番確実な方法です。
リードタイム短縮の考え方｜作業を速くする前に「待ち」を見る
「短縮したい」と考えたとき、多くの人がまず思い浮かべるのは「作業を速くする」ことです。けれど、手をつける順番はそこではありません。
経過時間の内訳をたどると、たいてい「待ち」が見つかる
最近「思ったより時間がかかった」仕事をひとつ思い出して、起点から終点までの内訳を書き出してみてください。承認が返ってくるのを待っていた日、先方の返信を待っていた日、他の案件が先に詰まっていて順番を待っていた日――実際に手が動いていた時間より、何かを待っていた時間の方が長い、という共通点がたいてい見つかります。
だとすれば、短縮の第一歩は作業スピードを上げることではなく、「どこで・何を・どれだけ待っているか」を特定することです。作業を1割速くする努力より、数日単位の待ちをひとつ消す方が、全体はずっと大きく縮みます。
ボトルネックを特定する：全体は「一番詰まる工程」に引きずられる
待ちを特定するときの軸になるのが「ボトルネック」の考え方です。工程が直列につながっているとき、全体の流れる速さは一番処理が詰まる工程で決まります。ボトルネック以外の工程をいくら速くしても、詰まる場所の手前に待ち行列ができるだけで、起点から終点までの時間は縮みません。だからこそ、まず工程の並びと依存関係を見える化して、どこで滞留が起きているかを目で確認するのが先です。この見える化にはガントチャートがそのまま使えます。
並行化と分割：直列を崩し、塊を小さくする
待ちの場所が見えたら、打ち手は大きく2つです。ひとつは並行化。「Aが終わってからBを始める」と直列に並んでいる工程のうち、本当はAを待たなくても始められるBを、先に並行して走らせます。もうひとつは分割。大きな塊のまま次工程に渡すと、全部が終わるまで次が動けません。塊を分けて、できた分から先に流せば、後工程の待ちが減ります。どの順番で何を並べ、何を同時に走らせるか――これはまさに段取りの設計そのものです。
🎯 「着手までの待ち」を縮める仕組みが「するたす」です
- ✅ 入力はタスク名だけ → AIが今日できる最初の一歩に自動分解
- ✅ 最初の一歩が小さく具体的 → 依頼を受けたその日に手をつけられる
- ✅ 着手が早まる → 頼まれてから返すまでの時間が縮む
※登録不要で体験フォームが使えます
📱 PCの方はスマホで読み取り
個人の仕事にもリードタイムはある
ここまでの話は製造や物流だけのものではありません。デスクワークにも、まったく同じ構造があります。
「頼んでから返ってくるまで」があなたの所要時間
依頼する側から見れば、あなたに何かを頼んだ瞬間が起点で、成果物が返ってきた瞬間が終点です。メールの返信、資料の作成、確認の依頼――そのすべてに「頼んでから返ってくるまでの時間」があり、相手はそれを体感で覚えています。まずは自分の代表的な仕事について、依頼を受けてから返すまでに実際どれくらい経過しているか、直近の数件を振り返ってみてください。把握するだけでも、「いつ着手すれば間に合うか」の逆算が効くようになります。
一番長い待ちは、たいてい「着手待ち」
振り返ってみると、時間の内訳には共通のパターンが見つかるはずです。作業そのものに何日もかかっていたのではなく、「手をつけるまで」に一番時間が経っていた――依頼がメモのまま数日置かれ、「そろそろやらなきゃ」と思いながら他の仕事に流され、締切が近づいてようやく着手する。工場の待ち時間にあたるものが、個人の仕事では「着手待ち」として現れます。
だとすれば、個人の仕事でこの時間を縮める一番のレバーは、作業を速くすることではなく着手を早めることです。着手が遅れる典型的な理由は、依頼が「資料まとめておいて」のような大きく曖昧な塊のままで、最初の一歩が見えないこと。受け取った時点で「まず構成案を3行書く」のような小さな一歩まで分解しておくと、着手のハードルが下がり、起点から終点までが自然に縮みます。分解した一歩を日々の予定に落とす手順は「タスク分解からスケジュールへの落とし込み方」で詳しく解説しています。
焦って速く働くことではない
誤解のないように添えると、これは「急いで働け」という話ではありません。焦って作業を詰めると確認が甘くなり、手戻りが発生します。手戻りは工程のやり直しですから、待ち時間と同じように起点から終点までの時間を延ばします。着手を早め、待ちを減らし、作業そのものは落ち着いた速度で確実に――この組み合わせが結果として一番速い、というのが本記事の立場です。この考え方は「ゆっくり働くほうが速く終わる仕組み」でも掘り下げています。
よくある質問（FAQ）
Q1. リードタイムと納期の違いを一言で言うと？
納期は「いつまでに納めるか」というカレンダー上の期日、こちらは「起点から終点までどれくらいかかるか」という所要時間です。期日（納期）から所要時間を引き算すると、いつまでに着手・発注すべきかが逆算できます。この逆算に使うのが実務での主な役割です。
Q2. 営業日と暦日、どちらで数えますか？
会社や取引先によって異なります。営業日で数える現場も暦日で数える現場もあり、起点（発注日を含むか）や終点（着荷か検収か）の定義も組織ごとに違います。数字だけを受け取らず、「どこからどこまでを・何日単位で数えているか」を相手と最初にすり合わせるのが確実です。
Q3. 短縮はどこから手をつければいいですか？
まず直近の案件で、起点から終点までの内訳を書き出してみてください。振り返ると、実作業より承認待ち・返信待ち・順番待ちなどの待ち時間の方が長いことが多いはずです。だとすれば手をつける順番は、①待ちの特定、②一番詰まっている工程（ボトルネック）の解消、③並行化・分割、の順です。作業スピードを上げるのはその後で構いません。
Q4. 個人のデスクワークにも当てはまりますか？
当てはまります。依頼を受けてから返すまでが、相手から見たあなたの所要時間です。振り返ると、作業そのものより「手をつけるまで」が一番長いことが多いはず。依頼を受け取った時点で最初の一歩まで分解して着手を早めると、全体が縮みます。分解をAIに任せると、この一手がさらに軽くなります。
まとめ：期日（納期）と所要時間を区別し、「待ち」から縮める
- リードタイムとは、発注（依頼）から納品（完了）までにかかる時間の総量。実作業だけでなく待ち時間も含む
- 納期は「期日（点）」、こちらは「所要時間（長さ）」。期日から引き算して着手時点を逆算する物差しになる
- 代表区分は 発注（調達）・生産（製造）・配送（出荷）・開発。起点・終点・数え方は現場ごとに定義を確認する
- 短縮の順番は 待ちの特定 → ボトルネック解消 → 並行化・分割。作業を速くするのは最後でいい
- 個人の仕事では「着手待ち」が一番長いことが多い。依頼を最初の一歩まで分解して着手を早めるのが最大のレバー
仕事の流れの組み立ては「段取りとは？意味と組み立て方の基本」、工程と依存関係の見える化は「ガントチャートの作り方と使い方」、分解した一歩を予定に落とす手順は「タスク分解からスケジュールへの落とし込み方」も併せてどうぞ。
🚀 「するたす」を無料で試す
「頼まれてから返すまで」を縮める第一歩は、着手を早めること。タスク名を入れるだけで、AIが今日できる最初の一歩に自動分解します。
📱 PCの方はスマホで
この記事をシェア：
著者：藤岡 拓也（Takuya Fujioka）
AIタスク管理アプリ「するたす」開発者・運営者
タスク分解の”摩擦”をゼロにすることをテーマに、プロダクトを日々磨いています。
