---
title: "工程管理と進捗管理の違い｜規格上の包含関係と現場で線を引く基準を解説"
url: "https://www.issoh.co.jp/column/details/17020/"
published: 2026-08-27
updated: 2026-09-27
categories: ["物流・製造"]
publisher: "株式会社一創"
---

# 工程管理と進捗管理の違い｜規格上の包含関係と現場で線を引く基準を解説

工程管理と進捗管理は、並んだ二つの管理手法として説明されることが多い言葉です。ただ、生産管理の用語規格をたどると、この二つは横並びではなく入れ子の関係にあります。それでも実務では対等な別物として扱う場面が残り、その食い違いが社内の議論を空転させる。この記事では、規格の条文が示す包含関係、混同の発生源、粒度が噛み合わないときの不具合、自社に足りないのが計画側か監視側かを切り分ける手順を順に扱います。製品の機能一覧と既製か自作かの選定軸は[工程管理システムとは何かを解説した記事](https://www.issoh.co.jp/column/details/15402/)に譲り、ここでは言葉の線引きと役割分担に絞ります。

## まとめ：工程管理と進捗管理は計画を持つ側と進み具合を直す側で分かれる

先に結論を置きます。規格の体系では、工程管理は生産統制の別称であり、進捗管理はその内側にある三つの機能の一つです。両者は並列ではなく、工程管理が進捗管理を含みます。一方、実務の会話では工程管理が計画の立案から改善までを指すため、話者によって範囲が二段階ずれます。

- 規格の位置づけ：工程管理＝生産統制、その中に現品管理・余力管理・進捗管理が並ぶ
- 実務の用法：工程管理は計画立案から改善までを含む業務の束を指すことがある
- 線を引く基準：予定を引き直す権限を持つ側が工程管理、当日の順序と応援で帳尻を合わせる側が進捗管理
- 投資判断：計画側が弱い現場と監視側が弱い現場では、入れる仕組みも費用も別物になる

社内文書や要件定義では、規格に寄せて「工程管理の中の進捗管理」と書くほうが後の混乱が少なくなります。ただし一人が計画も監視も兼ねる規模なら、呼び分けを持ち込まないほうが速い。区別が要るのは、要件定義書を書くとき、部門間で責任を分けるとき、投資の効果指標を説明するときの三場面です。

## 工程管理と進捗管理の違い｜規格の条文が示す包含関係と実務の用法

まず出典のある定義から押さえます。生産管理の用語はJIS Z 8141（生産管理用語）に番号付きで収録され、現行は2022年版です。条文を読むと、二つの言葉の関係が明確に出てきます。

### JIS Z 8141の条文が示す生産統制と進捗管理の位置づけ

規格には「工程管理」という独立した番号の定義項目がありません。代わりに1215の生産管理の備考に、狭義には生産工程における生産統制を意味し、工程管理ともいう、という一文が置かれています。つまり工程管理は生産統制の言い換えとして規格上に登場します。

その生産統制は4101で「ショップフロア（生産現場）が生産計画どおりに生産を実施するように、生産活動の進捗を管理する活動」と定義されています。続く4102が現品管理で資材・仕掛品・製品の運搬や停滞の状況を管理する活動、4103が余力管理で各工程や作業者の負荷と現有能力を把握して作業を再配分する活動、4104が進捗管理で「仕事の進行状況を把握し、日々の仕事の進み具合を調整する活動」です。番号の並びが構造を示していて、生産統制という枠の中に現品・余力・進捗の三機能が収まります。

ここから導ける線引きは一つ。進捗管理は工程管理の一部であり、対等な選択肢ではありません。加えて4104には「調整する活動」という語が入っています。進み具合を把握するだけでは規格の定義を半分しか満たしていない、と読めます。

### 工程管理が実務では計画立案から改善まで含む語として使われる理由

規格の工程管理には、生産計画そのものを立てる工程が含まれません。計画は別の体系として扱われ、統制は引かれた計画どおりに走らせる活動です。ところが実務の解説記事や社内の会議では、工程管理を計画立案・実施・評価・改善の四段階として説明することが一般的になっています。

この用法が定着した背景には、担当の実態があります。従業員100人未満の製造現場では、日程を引く人と現場を回す人が同一のことも珍しくありません。同じ担当者が計画も統制も持てば、その束をまとめて工程管理と呼ぶのが自然でしょう。加えて、工程管理システムと名乗る製品の多くが日程計画の作成機能を積むため、製品の機能範囲がそのまま言葉の範囲として広まりました。

どちらが正しいという話ではなく、実務の用法にも合理性があります。問題になるのは、規格寄りの理解を持つ人と実務寄りの理解を持つ人が、定義を言わないまま議論を進めた場合です。片方は統制の話をし、もう片方は計画立案を含めた話をして、要件が二段階ずれたまま合意されます。

### 二つの言葉を並べたときに残る三つの相違点と共通する管理の土台

用法の幅を踏まえると、実務で意味のある相違点は三つです。

| 観点     | 工程管理       | 進捗管理        |
| ------ | ---------- | ----------- |
| 扱う時間軸  | 先の予定を作り直す  | 当日から数日先を調整  |
| 持つ権限   | 納期回答と日程の変更 | 作業順と応援の投入   |
| 成果の測り方 | 納期遵守率と負荷率  | 遅れ時間と実績の到達率 |

共通するのは土台です。どちらも、予定と実績が同じ作業単位で記録されていなければ成立しません。工程管理は予定を引き直すために現在地を知る必要があり、進捗管理は遅れを測るために予定を知る必要があります。土台が無いまま名乗っても、実態は工程表の清書作業です。なお、設計・開発・テストのフェーズを扱うITプロジェクトの進捗管理は前提が異なるため、[プロジェクト進捗管理の方法と会議運用を扱った記事](https://www.issoh.co.jp/column/details/15672/)のほうが実務に近い内容になります。

## 混同が起きる三つの発生源｜規格の体系・現場の慣用・製品名の影響

言葉が食い違うのは、誰かの理解不足が理由ではありません。三つの発生源がそれぞれ別の方向へ意味を引っ張っています。どこから来たずれなのかが分かれば、社内で決め直すときの説得材料になります。

### 規格の体系と入門記事の説明が食い違ったまま伝わる第一の発生源

入門的な解説の多くは、工程管理を計画から改善までの一巡として図示します。この図は業務の流れを掴むには分かりやすい反面、規格の体系とは範囲が一致しません。読み手は工程管理を大きな傘として理解し、進捗管理をその下の一機能ではなく、隣に置かれた別の管理として受け取る。この理解のまま要件定義に入ると、機能一覧が二本立てになり、実装では同じ実績テーブルを共有する重複要件が生まれます。

### 現場が工程表の更新作業そのものを進捗管理と呼ぶ第二の発生源と影響

現場でよく耳にするのは、朝礼で工程表に赤ペンを入れる作業を進捗管理と呼ぶ用法です。実態は状況の書き写しであって、規格の4104が求める「進み具合を調整する活動」には届いていません。それでも作業名として定着しているため、進捗管理は既にやっているという認識が生まれます。

この認識が残ると、投資判断が歪みます。既にやっている領域には追加投資が不要だと判断され、調整の意思決定が誰にも割り当てられていない状態が温存されるためです。遅れが赤く見えていても、決裁が夕方の会議まで動かないなら、検知の速さは成果に変換されません。書き写しと調整を分けて呼ぶだけでも、この歪みは減らせます。

### 製品の名前が管理範囲を決めてしまう第三の発生源と選定時の歪み

三つ目は製品名です。工程管理システムを名乗る製品には、日程計画の作成を主機能とするものと、現場からの実績収集を主機能とするものが混在しています。前者は計画側、後者は監視側に寄っており、同じ名前でも解く課題が違います。

製品名を出発点にすると、自社の不足がどちら側なのかを検討する前に、比較表の項目が判断軸になってしまいます。結果として、計画を引く人が不在の現場に高機能なスケジューラが入り、誰も予定を引き直さないまま使われなくなります。製品タイプの分類と選定軸は[工程管理システムの機能と判断軸を整理した記事](https://www.issoh.co.jp/column/details/15402/)で扱っているので、比較に入る前に自社の不足側を先に決めてください。

## 管理対象と粒度の違い｜工程単位と作業者単位で変わる実績の取り方

ここからは実務で効く差です。二つの管理は扱うデータの粒度が違い、噛み合わないとどれだけ入力しても数字が使えません。

### 工程管理が受け持つ計画側の粒度と余力管理・現品管理の守備範囲

計画側が持つのは、大日程・中日程・小日程という三つの階層です。大日程は月単位で受注と能力の総量を合わせ、中日程は週単位で工程別の着手日を決め、小日程は日単位で作業順を確定する。この階層のどこまでを自社で持つかが、そのまま工程管理の重さになります。階層ごとの手法の当てはめ方は[工程管理の手法を計画の階層で選ぶ記事](https://www.issoh.co.jp/column/details/17016/)にまとめてあります。

加えて、規格が生産統制の中に置いた残り二機能も計画側の判断材料です。余力管理（4103）は各工程や作業者の負荷と現有能力を突き合わせ、余力または不足を出して作業を再配分します。現品管理（4102）は仕掛品がどこで止まっているかを押さえる活動です。進捗の数字だけで遅れを検知しても、余力が無ければ応援を出せず、現品の所在が分からなければ工程を飛ばした対処もできません。監視側だけを整えても打ち手が出ない理由がここにあります。

### 進捗管理の側が扱う実績の粒度と遅れを検知できる最小の入力単位

監視側が扱うのは実績です。何を最小単位として記録するかで、後から答えられる問いが決まる。工程単位で着手と完了を取れば「どの工程で詰まったか」に答えられ、作業者単位で取れば「誰の手が空いているか」に答えられます。両方を答えたいなら、両方の項目を入力してもらう必要があります。

ここで判断が要るのは、入力の負荷とのつり合いです。着手・完了・数量・不良の四項目なら、二次元コードの読み取りと数字入力で1分以内に収まる。停止理由の分類やコメント欄を足すと、繁忙期に飛ばされて到達率が落ち、集計値の信頼が失われます。実績を取る方式ごとの適合と、指標をいくつに絞るかの設計は[工程管理の見える化で予実対比の前提を整理した記事](https://www.issoh.co.jp/column/details/17018/)で詳しく扱っています。

### 粒度が噛み合わない現場で起きる按分の破綻と突き合わせ失敗の型

典型は、計画が受注番号ごとに引かれ、実績が作業者の日報で記録されている組み合わせです。一人が一日に三つの受注をまたいだ場合、その8時間をどう割り振るかは日報に書かれていません。按分しようとしても根拠が無く、結局は勘で配分された数字が原価計算まで流れます。

もう一つの型は、単位の名前だけが一致していて中身が違う場合です。計画側の「組立工程」が三つの作業をまとめた括りで、実績側の「組立」が最後の作業だけを指している。名前で突き合わせは通るのに、比較した数字は別物です。この型は集計エラーとして表面化せず、数か月にわたって誤った判断材料を出し続けます。防ぐには、突き合わせの鍵になる単位を一つ決め、計画側と実績側の双方でその単位のマスタを共有する設計が要ります。

## 【独自章】足りないのは計画側か監視側か｜症状から切り分ける診断

ここからが本題です。言葉の違いを知りたい人の多くは、その先に「では自社は何を整えればよいのか」という問いを持っています。症状から発生源を切り分ければ、投資の順番が決まります。

### 計画側が欠けている現場に共通する四つの症状と社内での確認手順

次の症状が二つ以上当てはまるなら、不足しているのは計画側です。

- 予定が受注の納期日しか無く、工程別の着手日と完了予定日が存在しない
- 能力を超えた受注がそのまま計画に載り、着手してから残業で吸収している
- 特急案件が入っても全体の日程が引き直されず、口頭で差し込まれる
- 営業への納期回答が担当者の記憶と経験だけで行われている

確認の手順は簡単です。直近一か月で日程を引き直した回数と、その作業にかかった時間を担当者に聞いてください。引き直しが月に一度も無いか、一回に半日以上かかっているなら、計画は運用に耐えていません。実績収集を先に入れても、集めた数字を反映する先が無いまま終わります。先に決めるのは大中小の日程階層と、負荷を平準化する手順です。

### 監視側が欠けている現場に共通する四つの症状と社内での確認手順

逆に、次の症状が二つ以上なら不足は監視側です。

- 予定はあるが、実績が翌日の日報でしか分からない
- 進捗率が作業者の自己申告で、根拠となる数量や時刻が残らない
- 仕掛品がどの工程で止まっているかを探しに行かないと分からない
- 遅れが見えても、誰がリスケを決めるかが決まっていない

確認の手順は、遅れの発覚から対処の決裁までの時間を三件分だけ測ることです。半日以上かかっているなら、検知の遅さではなく決裁の設計に原因があります。四つ目だけが該当する場合、必要なのはシステムではなく指標ごとの対応表でしょう。遅れ時間が8時間を超えたら班長が応援を確定、16時間超で外注枠を押さえる、といった三行の取り決めで動き始めます。運用の見直しで消える課題とシステム化が要る課題の境界は[工程管理の課題を原因別に整理した記事](https://www.issoh.co.jp/column/details/17014/)で切り分けの手順を示しています。

### 両方とも欠けている場合に先へ進める順序と着手する工程の絞り方

両方が該当する現場も珍しくありません。その場合は監視側から着手してください。理由は材料の順序です。計画の精度を上げるには工程別の実測時間が要り、その値は実績からしか得られません。標準時間が一件も無い状態で計画を精緻に作っても、根拠のない数字を積み上げることになります。

例外は一つ。納期回答ができずに失注しているなら、計画側を先に整えます。実績を集めても失注は止まらないためです。どちらから入る場合でも対象は一工程に絞ってください。全工程を同時に始めた現場では、入力の徹底とマスタ整備が並行して走り、二か月ほどで負荷が限界に達します。ボトルネックの一工程で二週間の実測を取り、数字が出てから隣へ広げる順序が最も戻りが少ない。

## 【独自章】呼び分けが要らない現場と区別が必須になる現場の線引き

ここまで区別の話を続けましたが、すべての現場で線を引く必要はありません。用語の整理に時間を使うより、予定と実績を一枚に並べるほうが早い規模があります。

### 一人が計画と監視を兼ねる規模で区別せずに運用してよい四つの条件

次の四条件をすべて満たすなら、呼び分けを持ち込まずに運用して構いません。

- 計画を引く人と現場を回す人が同一、または席が隣で常時会話できる
- 同時進行の受注が概ね30件以内で、工程数が5工程以内に収まる
- 外注に出す工程が無いか、あっても定常的な一社に限られる
- 納期の変更が起きたとき、その場の判断で全体を引き直せる

この規模では、表計算ソフト一枚に予定と実績を並べるだけで両方の役目が果たせます。用語を分けても担当が分かれないため、区別が実務上の意味を持ちません。むしろ社内文書に二つの言葉が登場すると、後から入った担当者が別々の仕組みだと誤解します。現場のスマートフォンから実績を上げる場合の要件は[工程管理アプリの選び方を整理した記事](https://www.issoh.co.jp/column/details/17012/)にまとめました。

### 区別を決めないまま進めた結果として投資が空振りする三つの場面

一方、次の三場面では区別を決めないまま進むと投資が空振りします。

第一に、システムの要件定義書を書くとき。日程を作る機能と実績を集める機能では、必要なマスタも開発規模も違います。両者を一語にまとめた要件は解釈の幅が生まれ、着手後に追加費用として表面化するでしょう。第二に、部門間で責任を分けるとき。予定を引き直す権限と当日の作業順を決める権限が同じ人に集中していると、遅れの原因が計画の甘さなのか現場の停滞なのかを切り分けられません。第三に、投資の効果指標を説明するとき。計画側は納期遵守率と負荷率、監視側は遅れ時間と実績の到達率で測ります。

## 役割分担とシステム化への翻訳｜誰が持つかと何から入れるかの順序

最後に、決めた線引きを組織と仕組みへ落とします。ここを飛ばすと、整理した用語が資料の中だけで終わります。

### 予定の引き直しと当日の応援投入について誰が決めるかの権限分担

分担の基準は、決裁が及ぶ時間の長さです。予定の引き直しと納期回答は数週間先の約束を変える行為なので、受注情報と外注枠を握る生産管理の担当が持ちます。当日の作業順と応援の投入は、その日のうちに結果が出る判断なので現場の班長が持つ。標準時間の設定と改訂は両方の判断材料になるため、生産技術の側に置くと収まります。

帳票の面でも規格が手がかりを与えています。4307の作業伝票は「工程管理の伝票制度で使用される伝票の総称」と定義され、計画から現場へ指示を渡す側の道具です。4308の作業日報と4305の現品票は実績を上げる側に属し、4301の管理盤は作業予定と作業余力の統制状況を表示する盤で、両者が同じ盤面を見る接点にあたります。仕組みへ移すときは指示系と実績系を混ぜないでください。同じ紙に指示と実績の記入欄を並べると、紙が現場に滞留する間はどちらの情報も見えません。さらに4306の実績情報管理は「日々の生産実績に関する情報を定期的に収集し、統計処理した上で、関係部門に提供する行為」と定義され、集めた実績を計画側へ戻す経路まで含みます。この経路が無いと、標準時間は初期値のまま残ります。

### 工程管理システムから入る条件と実績の収集から入る条件の分かれ目

仕組みの入り口は二つあります。計画側から入るのは、日程の引き直しに週数時間を取られている、工程間の依存が複雑で手作業のリスケが破綻している、同時進行の受注が30件を超えている、といった条件が揃う場合です。監視側から入るのは、予定はあるのに実績が翌日以降にしか分からず、遅れの発見が事後になっている場合になります。

費用の桁も違います。監視側は端末と読み取り機器、実績を受ける仕組みが中心で、一工程から始めれば小さく試せます。計画側は品目マスタと工程マスタ、標準時間の整備が前提になるため、初期の整備工数が本体費用を上回ることもあるでしょう。生産管理の全体像とERPやMESとの役割分担は[生産管理システムの機能と種類を解説した記事](https://www.issoh.co.jp/column/details/13633/)が全体地図になります。

### 既製のパッケージで足りる範囲と受託開発へ切り替える判断の三軸

既製品で足りるかどうかは、三つの軸で判断できます。第一に工程の並び。品目ごとに工程順が固定なら既製品の標準機能に収まりますが、受注ごとに順序が変わる個別受注生産では、製番単位の工程展開に対応する製品が限られます。第二に既存システムとの接点で、基幹側のBOMや製番と実績を突き合わせるなら連携の作り込みが避けられません。第三に入力の主体で、協力会社や派遣の作業者が実績を入力する運用では権限の分離と教育コストの見積もりが要ります。

三軸のうち二つ以上で既製品の標準機能から外れるなら、部分的な受託開発を含めた構成を検討する段階です。当社では、既存の基幹システムを残したまま工程の計画側と実績側だけを作る構成も引き受けています。現状の帳票と業務の流れをお持ちいただければ、どちらから着手すべきかの切り分けから[生産管理システム開発](https://www.issoh.co.jp/service/business%5Fsystem/production-management/)としてご相談を承ります。

## よくある質問

### 工程管理と進捗管理はどちらが上位の概念ですか？

規格の体系では工程管理が上位です。JIS Z 8141の1215生産管理の備考に、狭義には生産工程における生産統制を意味し工程管理ともいう、と書かれており、その生産統制（4101）の中に現品管理（4102）・余力管理（4103）・進捗管理（4104）が置かれています。進捗管理は工程管理の一機能という関係です。ただし実務では計画立案まで含む語として使う場面があるため、社内では「計画を含むかどうか」を先に確認してから話を進めてください。

### 進捗管理だけを先に入れても効果は出ますか？

条件付きで出ます。予定が工程別に引かれていて、遅れを検知した後の決裁者が決まっている現場なら、実績収集を足すだけで対処が半日から数時間へ短縮します。逆に、予定が納期日しか無い現場や、余力が把握できず応援を出せない現場では、遅れの数字が増えるだけで打ち手に届きません。規格が生産統制の中に余力管理と現品管理を並べているのは、進捗の把握だけでは調整できないからです。

### 進捗率で管理していれば進捗管理はできていますか？

判断材料としては足りません。進捗率60%という数字には、予定に対して早いのか遅いのかが含まれていないためです。同じ60%でも、予定どおりなら放置してよく、8時間遅れなら応援を出す判断になります。主指標には予定完了時刻と実績完了時刻の差、つまり遅れ時間を置いてください。規格の4104も、把握だけでなく日々の進み具合を調整する活動と定義しています。

### 工程管理と生産管理はどう違いますか？

生産管理のほうが広い概念です。JIS Z 8141の1215は、所定の品質・原価・数量および納期で生産するために人・物・金・情報を用いて行う手続き全体を生産管理としています。需要予測、生産計画、資材の調達、原価の管理までが範囲に入る。工程管理はその狭義にあたり、引かれた計画どおりに現場を走らせる統制の側を指します。

### エクセルで工程管理と進捗管理を兼ねられますか？

規模次第で成立します。同時進行の受注が概ね30件以内、入力者が5人以内、共有が一台のファイルサーバーで完結するなら、予定と実績を同じ作業単位で並べて差を時間で出す列を足すだけで両方の役目を果たせる。これを超えると同時編集の待ちと版の取り違えが起き、集計そのものに事務工数を取られ始めます。拠点をまたぐ工程や、協力会社が実績を入力する運用では、権限の分離ができない点が先に問題になります。

## 関連記事

- [工程管理システムとは？機能・選び方と既製か自作かの判断軸を解説](https://www.issoh.co.jp/column/details/15402/)：製品の機能一覧と選定軸が分かります。
- [工程管理の課題を原因別に整理｜運用の見直しで直る範囲とシステム化の境界](https://www.issoh.co.jp/column/details/17014/)：症状の発生源を切り分ける手順です。
- [工程管理の手法を計画の階層で選ぶ｜山積み山崩しとシステム要件への翻訳](https://www.issoh.co.jp/column/details/17016/)：計画側の階層設計と手法の当てはめ方。
- [工程管理の見える化｜予実対比が成立する実績データの取り方と指標の絞り込み](https://www.issoh.co.jp/column/details/17018/)：監視側の実績収集方式と指標の絞り方。
- [プロジェクト進捗管理とは？遅延を防ぐ見える化の方法と会議運用の実務](https://www.issoh.co.jp/column/details/15672/)：ITプロジェクト側の進捗管理の実務。

---

出典: [工程管理と進捗管理の違い｜規格上の包含関係と現場で線を引く基準を解説](<https://www.issoh.co.jp/column/details/17020/>)（株式会社一創）