kintone工程管理の設計方法｜工程計画・作業指示・実績を分ける構成

kintoneで工程管理を作るとき、最初に考えやすいのは工程表です。

製品名、工程名、担当者、設備、予定開始日、予定終了日、ステータス、進捗率。

これをアプリに入れて一覧化すれば、工程管理らしい画面は作れます。

ただし、実務で困るのは、工程表が表示できないことではありません。

本当に崩れやすいのは、次のような状態です。

• 受注や製造オーダと工程計画がつながっていない
• 工程計画と作業指示が同じレコードに混ざっている
• 進捗ステータスはあるが、実績時間や完了数量が残らない
• 遅延した事実は分かるが、原因と次工程への影響が分からない
• 担当者や設備の負荷を見ずに予定を組んでいる
• 部材在庫や入荷予定を確認せずに工程を開始している
• 品質確認や差し戻しが工程の履歴に残らない
• 出荷予定、納期回答、基幹システムと数字がずれる
• 専用の生産スケジューラやMESに任せるべき範囲までkintoneで抱えている

kintoneで工程管理を作るなら、最初に設計すべきなのは「工程表の見た目」ではありません。

受注、製造オーダ、工程計画、作業指示、進捗、作業実績、遅延理由、在庫、品質、出荷をどこで分けるかです。

kintone工程管理で最初に決めるべきなのは、ガントチャートを入れるかどうかではなく、「工程計画・作業指示・実績をどのレコード単位で分けるか」です。

この記事では、kintoneで工程管理を崩れにくい業務システムとして設計する方法を整理します。

kintone在庫管理の設計方法はこちら
kintoneタスク管理の設計方法はこちら

先に結論：工程管理は「計画」「指示」「実績」を分ける

kintoneで工程管理を作るとき、工程アプリ1つだけでも始めることはできます。

ただし、現場で使い続けるなら、最初から次の情報を分けて考えます。

分けるもの	1レコードの意味	役割
受注・製造オーダ	1つの製造対象、注文、案件	何を、いくつ、いつまでに作るかを示す
工程計画	1製造オーダの工程順・予定	どの工程を、いつ、どの順番で行うか決める
作業指示	1工程の作業指示	担当者、設備、手順、注意点を現場へ渡す
進捗	1工程の状態	未着手、着手、保留、完了、差し戻しを管理する
作業実績	1回の作業結果	作業時間、完了数量、不良数量、実施者を残す
遅延理由	1つの遅延・保留の原因	原因、影響、対策、責任範囲を記録する
負荷・能力	担当者、設備、時間枠	工程計画が現実的か確認する
品質確認	1回の検査・確認	不良、手直し、差し戻しを工程へ戻す
連携ログ	1回の外部連携	基幹、在庫、出荷、MESとのズレを追う

工程表は、工程管理の一部です。

しかし、工程表だけでは、現場は動きません。

現場に必要なのは、今日どの作業をすべきか。

どの部材がそろっているか。

どの設備を使うか。

どの作業が遅れているか。

遅れた場合、次工程と納期にどの影響があるか。

この情報です。

アディエムのGROW工程管理 on kintoneでも、見積、受注、生産計画、工程計画、作業指示、進捗管理、実績登録、出荷、請求/入金までの範囲が紹介されています。

アディエム：GROW工程管理 on kintone

この範囲をすべて自社で一気に作る必要はありません。

ただし、どこまでをkintoneで持ち、どこから専用システムへ逃がすかは最初に決めます。

kintone工程管理が向く業務と向かない業務

kintoneは、工程管理にも使えます。

特に、Excelや紙の工程表を使っていて、現場の進捗、遅延理由、作業実績が後から追えない会社には向いています。

kintoneに向く工程管理	理由
小規模な製造・加工工程	工程、担当、予定、進捗をレコードで管理しやすい
受注生産の進捗管理	受注、納期、工程、出荷予定をつなげやすい
工程ごとの作業指示	担当者、設備、手順、注意点を現場へ渡せる
遅延・保留理由の蓄積	原因、影響、対策を次回計画に活かせる
検査・手直しの履歴管理	品質確認と差し戻しを工程に戻せる
Excel工程表からの段階移行	まず進捗・実績・遅延理由をDB化しやすい
基幹システムの周辺管理	受注や出荷の前後にある現場調整を補える

一方で、次のような条件が強い場合は、kintoneだけで完結させない方がよいです。

kintoneだけでは重い工程管理	理由
秒単位・分単位の設備制御	現場端末、IoT、PLC、MESの領域になる
高度な自動スケジューリング	制約条件、前後関係、能力計算が複雑になる
多品種大量工程の山積み・山崩し	負荷調整ロジックが専用化しやすい
MRP・所要量計算	部材展開、発注、仕掛、在庫引当が絡む
原価計算・標準原価管理	会計・生産管理システムとの整合が必要
現場端末での高速実績入力	UI、バーコード、タブレット、設備連携が重要になる

日立システムズの生産管理ソリューションでも、製造業向けの基幹ノウハウとkintoneを組み合わせ、工程進捗やプロセス管理で次工程への引き渡しを扱う考え方が示されています。

日立システムズ：生産管理ソリューション

この考え方は、中小企業でも同じです。

kintoneを、すべての生産管理を置き換えるシステムとして使うのではありません。

工程計画、進捗、遅延理由、現場確認、周辺連携を整理する場所として使います。

kintone工程管理は、専用生産管理システムの代わりではなく、現場の工程状況と例外対応を業務データとして残すために使うと強いです。

受注・工程計画・作業指示・実績を分ける

工程管理で最初に分けるべきなのは、受注、計画、指示、実績です。

これらを1レコードにまとめると、運用がすぐに重くなります。

受注は、何を作るかです。

工程計画は、どう作るかです。

作業指示は、現場に何をしてもらうかです。

実績は、実際にどうなったかです。

アプリ	1レコードの単位	主な項目
受注・製造オーダアプリ	1つの注文、製造指示、案件	品目、数量、納期、顧客、優先度
工程計画アプリ	1オーダの1工程	工程名、順序、予定開始、予定終了、前工程
作業指示アプリ	1つの現場作業	担当、設備、手順、材料、注意点
作業実績アプリ	1回の作業結果	開始、終了、作業時間、完了数、不良数
遅延・保留アプリ	1つの遅延・停止理由	原因、影響、対策、責任者、再開予定
品質確認アプリ	1回の検査・手直し	検査結果、不良内容、差し戻し先

受注・製造オーダに持たせる項目

受注・製造オーダは、工程全体の親になります。

フィールド	型	設計意図
オーダ番号	文字列、採番	工程や実績の親キーにする
顧客・案件	ルックアップ、関連レコード	案件や受注とつなげる
品目	ルックアップ	製品マスタとつなぐ
数量	数値	製造数、ロット数を持つ
希望納期	日付	顧客要求の納期
社内納期	日付	工程計画上の締切
優先度	ドロップダウン	特急、通常、保留など
オーダ状態	ステータス	未計画、計画済み、製造中、完了、出荷済み
備考・注意点	文字列複数行	特殊仕様や注意点を残す

ここで重要なのは、受注・製造オーダを工程そのものにしないことです。

1つのオーダには、複数の工程があります。

工程が複数あるなら、工程計画は別レコードにします。

工程計画に持たせる項目

工程計画には、予定と前後関係を持たせます。

フィールド	型	設計意図
関連オーダ	ルックアップ、関連レコード	どの製造オーダの工程か
工程番号	数値	工程順を明確にする
工程名	ドロップダウン、ルックアップ	切断、加工、組立、検査など
前工程	関連レコード	前工程完了後に進む制御に使う
予定開始日	日付、日時	着手予定を持つ
予定終了日	日付、日時	完了予定を持つ
担当者・担当チーム	ユーザー選択、組織選択	作業責任を示す
設備	ルックアップ	使用設備を持つ
標準時間	数値	負荷や実績比較に使う
工程状態	ステータス	未着手、着手可、作業中、完了、保留

工程計画では、前工程と後工程の関係をどこまで厳密に扱うかを決めます。

小規模なら、工程番号とステータスだけでも始められます。

前後関係、設備負荷、部材可否まで厳密に見るなら、計画ロジックが重くなります。

その場合は、kintoneで全部を計算するのではなく、生産スケジューラやMESとの分担を検討します。

作業指示に持たせる項目

作業指示は、現場が今日見る情報です。

フィールド	型	設計意図
関連工程	ルックアップ、関連レコード	どの工程の作業か
作業日	日付	現場の日次作業に使う
作業者	ユーザー選択、スタッフマスタ	誰が作業するか
使用設備	ルックアップ	どの設備を使うか
作業手順	文字列複数行、添付	手順や図面を参照する
必要部材	関連レコード、テーブル	部材の有無を確認する
注意事項	文字列複数行	品質、危険、顧客指定など
指示状態	ステータス	未発行、発行済み、作業中、完了、取消

工程計画と作業指示を分けると、計画変更と現場指示を分けられます。

計画上はA工程が明日でも、実際の指示は担当者や部材状況に応じて調整されることがあります。

ここを同じレコードで上書きすると、何が計画で何が現場判断だったのかが分からなくなります。

作業実績に持たせる項目

作業実績は、実際に起きたことです。

フィールド	型	設計意図
関連作業指示	ルックアップ、関連レコード	どの指示の実績か
作業者	ユーザー選択、スタッフマスタ	実施者を残す
着手日時	日時	実際の開始
完了日時	日時	実際の終了
作業時間	計算、数値	標準時間との差分を見る
完了数量	数値	進捗と出荷可否に使う
不良数量	数値	品質・歩留まりを見る
中断時間	数値	停止や待ち時間を把握する
実績メモ	文字列複数行	現場の補足を残す
確認状態	ステータス	未確認、確認済み、差し戻し

工程管理では、進捗率だけでは足りません。

「80%完了」よりも、何個完了し、何個不良が出て、何時間かかり、何が止まったかの方が次の改善に使えます。

工程ステータスと遅延理由

工程管理では、ステータスを増やしすぎない方がよいです。

ただし、遅延や保留は分けて記録します。

ステータス	意味	次に必要な行動
未計画	受注はあるが工程計画がない	工程計画を作る
計画済み	工程予定はある	作業指示を発行する
着手可	前工程や部材がそろっている	作業者へ指示する
作業中	現場が作業している	実績を更新する
保留	何らかの理由で止まっている	遅延理由と再開条件を決める
完了	工程が終わった	次工程、検査、出荷へ進める
差し戻し	品質確認などで戻った	再作業の指示を出す
取消	工程が不要になった	取消理由を残す

kintoneのプロセス管理では、レコードにステータスを持たせ、作業者やアクションを設定できます。

kintoneヘルプ：プロセス管理

工程管理でプロセス管理を使う場合は、承認フローのように重くしすぎない方がよいです。

現場では、工程状態をすばやく更新できることが重要です。

プロセス管理は、次工程への引き渡し、確認待ち、差し戻し、完了確認のように、状態が意味を持つところへ使います。

遅延理由は、ステータスとは別に持ちます。

遅延理由	例	次の判断
部材待ち	入荷遅れ、欠品	購買・在庫確認、代替部材検討
設備停止	故障、点検、段取り遅れ	設備担当、別設備への振替
前工程遅れ	前工程が未完了	全体リスケ、納期影響確認
人員不足	担当不在、応援不足	応援調整、優先順位変更
品質不良	検査NG、手直し	再作業、原因分析
仕様確認待ち	顧客確認、図面不明	営業・設計へ確認依頼
優先順位変更	特急案件割込	他案件の納期影響を確認

遅延理由を自由記述だけにすると、後から分析できません。

選択式の遅延カテゴリと、自由記述の補足を分けます。

遅延を責めるためではなく、次回の計画に反映するためです。

担当者・設備・負荷の扱い

工程管理で難しいのは、日付だけではありません。

担当者や設備の負荷です。

工程表上は予定が入っていても、同じ設備に作業が重なっていたり、特定の担当者に作業が集中していたりすると、現場では回りません。

管理対象	持たせる項目	見ること
担当者	担当、スキル、勤務日、対応可能工程	作業の偏り、応援可否
チーム	チーム、作業枠、責任者	日ごとの負荷
設備	設備名、能力、稼働日、停止予定	設備の重複、停止影響
工程	標準時間、必要スキル、前後関係	計画の妥当性
作業枠	日付、時間帯、上限時間	山積み・山崩しの入口

小規模なら、kintoneの一覧とグラフで担当別・設備別の件数や予定時間を見るだけでも効果があります。

kintoneのグラフ機能では、アプリに登録されたレコードの内容や件数などを集計し、グラフや表で表示できます。

kintoneヘルプ：グラフと集計

ただし、負荷調整をkintoneだけで厳密にやろうとすると重くなります。

設備能力、段取り時間、前後工程、同時作業不可、作業者スキル、納期優先度を自動で最適化するなら、生産スケジューラの領域です。

GROW工程管理 on kintoneのような製造業向け製品でも、工程設計、日程計画、余力・負荷管理、ガントチャート、実績登録などが主要機能として整理されています。

kintone標準で作る場合は、まず次のレベルから始めるのが現実的です。

レベル	やること
レベル1	工程ごとの予定日、担当、状態を見える化する
レベル2	作業実績、遅延理由、不良数を残す
レベル3	担当者・設備別の負荷を一覧・グラフで見る
レベル4	前後工程、部材、品質、出荷と連携する
レベル5	生産スケジューラやMESと連携する

最初からレベル5を目指すと、設計が大きくなりすぎます。

まずは、工程状況と遅延理由が現場会議で使える状態を作ります。

在庫・出荷・品質とのつなぎ方

工程管理は、単独では完結しません。

在庫、購買、品質、出荷とつながります。

連携先	つなぐ理由	kintoneで見るべきこと
在庫管理	部材がそろっているか確認する	部材待ち、欠品、代替可否
購買管理	入荷予定が工程に影響する	入荷遅れ、発注漏れ
品質管理	不良や手直しが工程を戻す	検査結果、差し戻し、再作業
出荷管理	完了後に納品へ進む	出荷可否、梱包、納品日
案件・受注管理	顧客納期へ影響する	納期回答、優先度、顧客連絡
会計・原価管理	作業時間や不良が原価へ影響する	管理用の実績、正式原価との境界

kintone在庫管理の設計方法でも触れたように、在庫では「現在庫」だけでなく、入出庫履歴、引当、棚卸差異を分けることが重要です。

工程管理でも同じです。

部材があるかどうかを工程レコードに手入力するだけでは弱いです。

本当に必要なのは、工程開始前に、必要部材、入荷予定、欠品、代替可否を確認できることです。

品質確認も同じです。

検査結果を工程のメモに書くだけでは、どの工程で不良が出やすいか分かりません。

品質確認を別レコードにすると、工程、担当、設備、品目、不良理由を後から集計できます。

出荷との連携では、工程完了と出荷可否を分けます。

工程が完了しても、検査待ち、梱包待ち、書類待ち、顧客指定待ちが残ることがあります。

「工程完了 = 出荷可能」と短絡しない方がよいです。

アプリ同士のつなぎ方

kintoneで工程管理を作る場合、複数アプリをどうつなぐかが重要です。

主な選択肢は、ルックアップ、関連レコード一覧、アプリアクション、API連携です。

機能	向いている使い方
ルックアップ	品目、顧客、設備などのマスタ情報を入力時に取得する
関連レコード一覧	受注から工程一覧、工程から作業実績一覧を見る
アプリアクション	受注から工程計画、工程から作業指示などを作成する
API連携	基幹、在庫、MES、出荷システムと同期する

kintoneヘルプでも、アプリアクション、ルックアップ、関連レコード一覧は、複数アプリ間の連携機能として使い分けられると説明されています。

kintoneヘルプ：アプリアクションでできること

工程管理では、次のように使い分けます。

つなぎ方	例
受注から工程計画を作る	アプリアクション、または自動生成処理
工程計画から作業指示を作る	アプリアクション、プロセス管理、必要ならAPI
工程から実績を見る	関連レコード一覧
品目や設備を選ぶ	ルックアップ
基幹から受注を取り込む	API、CSV取込、連携ツール
作業実績を外部へ返す	API、CSV出力、連携ログ

アプリを分けるほど、つなぎ方の設計が重要になります。

ただし、アプリを1つにまとめすぎると、工程計画、作業指示、実績、品質、遅延理由が混ざります。

まずレコード単位を分け、その上でつなぎ方を選びます。

専用生産管理へ逃がすべきケース

kintone工程管理は便利ですが、万能ではありません。

次の条件があるなら、専用生産管理システム、生産スケジューラ、MESを検討します。

条件	kintoneだけで重くなる理由
工程数が多く、前後関係が複雑	依存関係の計算やリスケが重い
設備・担当者の負荷調整が重要	山積み・山崩し、能力計算が必要
部材所要量から発注まで自動化したい	MRPや在庫引当が絡む
現場端末でリアルタイムに実績を取る	UI、入力速度、バーコード、設備連携が必要
不良・トレーサビリティが厳格	ロット、シリアル、検査履歴の精度が必要
原価計算まで正確に行いたい	会計・生産管理との整合が必要
複数工場・複数ラインを横断する	権限、マスタ、計画ロジックが大きくなる

パソナ日本総務部の記事でも、kintoneで進捗管理・プロジェクト管理を行う際のメリットや、テンプレート、プラグイン、運用改善の考え方が整理されています。

パソナ日本総務部：kintoneで進捗管理・プロジェクト管理を行う方法

ただし、一般的な進捗管理と、製造業の工程管理は違います。

工程管理では、前後工程、設備、部材、品質、出荷、原価が絡みます。

そのため、kintone標準で工程表を作るだけでなく、どの時点で専用システムへ渡すかを決めておきます。

現実的な分担は次です。

領域	kintoneで持ちやすい	専用システムに任せやすい
受注後の工程見える化	オーダ、工程、担当、状態	詳細な自動スケジューリング
現場の進捗報告	着手、完了、保留、遅延理由	端末・設備連携、リアルタイム制御
作業実績の記録	時間、数量、不良、メモ	原価計算、標準原価、MES連携
例外対応	遅延、欠品、差し戻し、調整	高度な制約最適化
会議・改善	遅延理由、担当アクション	工場全体の最適化計算

kintoneは、現場と管理者の間にある情報の整理に向いています。

専用システムは、詳細な計画計算や現場端末との連携に向いています。

どちらか一方に寄せすぎず、責任範囲を分けます。

よくある失敗パターン

kintone工程管理でよくある失敗は、工程表の再現から始めることです。

失敗	起きること	対策
工程表を1アプリで再現する	計画、指示、実績、遅延理由が混ざる	受注、工程計画、作業指示、実績を分ける
ステータスだけで進捗を見る	完了数量や作業時間が残らない	作業実績アプリを作る
遅延理由をメモに書く	後から原因分析できない	遅延カテゴリと補足を分ける
担当者・設備負荷を見ない	現場で予定が詰まる	担当別・設備別の予定を一覧化する
部材在庫を確認しない	着手後に部材待ちで止まる	在庫・購買と工程開始条件をつなぐ
品質確認を工程外で扱う	不良や手直しが工程に戻らない	品質確認と差し戻しを設計する
出荷と工程完了を同一視する	検査・梱包・書類待ちが漏れる	出荷可否を別に管理する
専用システム領域まで抱える	計算や入力UIが重くなる	生産スケジューラやMESへ逃がす

特に避けたいのは、「Excelの工程表をそのままkintone化する」ことです。

Excelの列を移せば、予定日、担当者、ステータスは見えます。

しかし、作業指示、作業実績、遅延理由、品質、在庫、出荷の責任範囲は整理されません。

工程表の再現ではなく、工程が進み、止まり、戻り、出荷へつながる業務の流れを設計します。

1週間で始めるならこの順番

最初から高度なスケジューリングを作る必要はありません。

まずは、工程計画、進捗、実績、遅延理由が現場で回るかを確認します。

日程	やること	成果物
1日目	対象工程を絞る	1製品、1ライン、1チームなど
2日目	受注・製造オーダの項目を決める	品目、数量、納期、優先度
3日目	工程計画のレコード単位を決める	工程番号、予定日、担当、設備
4日目	作業指示と作業実績を分ける	指示項目、実績項目、入力者
5日目	ステータスと遅延理由を決める	保留、遅延、差し戻し、原因カテゴリ
6日目	在庫・品質・出荷との境界を決める	部材確認、検査、出荷可否
7日目	実データで試す	入力負荷、進捗確認、遅延対応を検証

最初の検証では、複雑な全工程を対象にしない方がよいです。

遅延が起きやすい工程、見える化したいライン、現場の報告が紙で残っている工程など、効果が見えやすい範囲から始めます。

そこで、次の確認をします。

• 現場が作業指示を見て動けるか
• 作業実績を無理なく入力できるか
• 遅延理由が選択式で拾えるか
• 工程の遅れが次工程や納期に伝わるか
• 部材待ち、品質NG、出荷待ちを分けられるか
• 現場会議で一覧やグラフを見て判断できるか

この確認で詰まるところが、本格実装前に設計すべき論点です。

実装前チェックリスト

kintone工程管理を実装する前に、次の項目を確認します。

• 工程管理の対象が、製造、加工、検査、出荷準備のどこか決まっている
• 受注・製造オーダと工程計画を分けるか決まっている
• 工程計画と作業指示を同じレコードにするか、分けるか決まっている
• 作業実績として、時間、数量、不良、メモのどれを取るか決まっている
• ステータスが増えすぎていない
• 遅延理由を選択式と自由記述で分けている
• 担当者・設備・チームの負荷を見る単位が決まっている
• 前工程、後工程の関係をどこまで厳密に扱うか決まっている
• 部材在庫や入荷予定を工程開始前に確認する方針がある
• 品質確認、手直し、差し戻しを工程へ戻す設計がある
• 工程完了と出荷可能を分けている
• 基幹、在庫、出荷、MESとの正本分担が決まっている
• 連携ログで取込、出力、エラーを追える
• 高度な自動スケジューリングをkintone標準で無理に作ろうとしていない
• 現場がスマホ、タブレット、PCのどれで入力するか決まっている
• 現場会議で見る一覧とグラフが決まっている

このチェックリストで詰まるところが、kintoneの設定前に決めるべきことです。

特に、工程計画、作業指示、作業実績、遅延理由の分け方は後から直すと重くなります。

過去の工程履歴が積み上がる前に決めます。

まとめ

kintoneで工程管理を作ること自体は難しくありません。

製品、工程名、担当者、予定日、ステータスを入れれば、工程表は作れます。

しかし、実務で使える工程管理にするには、工程表だけでは足りません。

必要なのは、受注・製造オーダ、工程計画、作業指示、進捗、作業実績、遅延理由、負荷、品質、在庫、出荷の境界を決めることです。

kintoneは、現場の進捗、遅延理由、作業実績、例外対応を業務データとして残す場所に向いています。

一方で、高度な自動スケジューリング、設備制御、MES、MRP、厳密な原価計算は、専用生産管理システムに任せた方がよい領域です。

工程管理をkintoneで始めるなら、まず次の3つを決めてください。

• 受注・工程計画・作業指示・実績を、どのレコード単位で分けるか
• 遅延理由、品質NG、部材待ちを、どの状態で拾うか
• kintoneで持つ簡易工程管理と、専用システムへ逃がす範囲をどこで分けるか

この3つが決まっていれば、kintone工程管理は工程表の見える化ではなく、現場の判断と改善に使える業務システムになります。

逆に、ここを曖昧にしたまま工程表だけ作ると、予定は見えるのに、なぜ遅れているか、どこに負荷があるか、次に何を調整すべきかが見えません。

工程管理は、予定を並べる仕事ではありません。

工程が計画どおり進んでいるかを見て、止まった理由を拾い、次の工程と納期を守るために調整する業務です。