冒頭：作業場の壁に貼られた「進捗ボード」は、なぜいつもシステムより二日早く更新されるのか
ある機械加工工場を訪ねると、会議室の壁にはホワイトボードが掛けられ、色とりどりの付箋が貼られており、それぞれに作業指示書番号、当該班の工程、工作機械番号が記されている。毎晩、当直のマネジャーは付箋をすべて入れ替える。翌朝、社長が作業場にやって来て尋ねる。「昨日の仕事は全部納品できたか？」と。作業主任はそのボードを取り出し、目を細めて付箋を数える。
同じ工場でも、しばしば二種類の「進捗」が存在する。一つはホワイトボードと付箋によるもの、もう一つはERPやMESに記録された作業指示書のステータスだ。前者は現場の実情を示し、後者は財務や顧客向けの数字である。両者が一致しないのは日常茶飯事で、一致したときこそニュースになる。
これは特定の工場に限った話ではない。私たちが見てきた作業場では、従業員十数人の小さな工房から千人規模の完成品工場まで、いずれも同様の問題を抱えていた。
- 生産計画が作業台に届かない：計画担当者がシステム上で30枚の作業指示書を立てても、作業場では8枚しか見えず、残りは「システム上に掲示されたまま」になっている。
- 進捗は聞くしかない：調整担当者は一日に何十件もの電話で「この仕事はどこまで進んでいるのか」と問い合わせ、作業長もどの工程がどこまで進んだかを正確に把握できない。
- 労働時間と実績が合わない：報告担当者は4時間ごとに記録を入力するが、終業前2時間にまとめて補正するため、数字と実際の作業ペースには20％から40％の差が出る。
- 異常が誰にも気づかれない：ある工程で材料が三日間待たされても誰も気付かず、顧客からの催促があって初めて部品不足に気づく。
問題は、どのソフトウェアが使われていないかではなく、「現場」と「システム」の間の情報収集の環が途切れていることにある。壁のホワイトボードがERPよりも正確なのは、それが工作機械のそばに立ち、現場を直接見ている人が維持しているからであり、一方ERPは通常、三層の間に隔てられている。作業長→班長→調整担当者という流れで、各層でデータが再入力され、それぞれの段階で遅れや誤りが生じる可能性がある。
次に、このシステムをどのように設計し、どう実装すれば、壁のホワイトボードが徐々に不要になっていくのかを検討する。
01 業務をどう分解するか：「進捗」を最小単位の収集可能なアクションに切り分ける
多くのプロジェクトでは、最初から「工程進捗」という一語をひとつのフィールドとして扱ってしまう。しかし実際には「工程進捗」は複合的な状態であり、次の六つの要素を個別に収集しなければならない。すなわち、作業指示書がどの作業台に割り当てられているか、誰が作業を行っているか、すでにどれだけ進められたか、どれくらいの労働時間を費やしたか、品質は合格か不合格か、材料は揃っているか——これら六つの側面をそれぞれ独立して収集し、一つにまとめることはできない。 具体的に分解すると、以下のようになる。 作業台：各工作機械または作業台には固有の番号があり、バーコードやカードでスキャンすることで「現在この機械は誰の仕事を行っているのか」を特定できる。 作業者：各作業指示書の開始工程、移動工程、報告工程はすべて一人の作業番号に紐づけられる。師弟協力の場合でも、主操縦者が唯一の記録者となる。 既に処理済みの数量：工程には初回検査、工程中検査、完了時の計数がある。数量は状態ではなく、ボタンを押すかコードをスキャンして更新する必要がある。
実際の労働時間：開始工程と完了工程の時間差（自動収集）に加え、途中の停止（異常停留理由を手動で追記）も含む。
- 作業台：各工作機械または作業台には固有の番号があり、バーコードやカードでスキャンすることで「現在この機械は誰の仕事を行っているのか」を特定できる。
- 作業者：各作業指示書の開始工程、移動工程、報告工程はすべて一人の作業番号に紐づけられる。師弟協力の場合でも、主操縦者が唯一の記録者となる。
- 既に処理済みの数量：工程には初回検査、工程中検査、完了時の計数がある。数量は状態ではなく、ボタンを押すかコードをスキャンして更新する必要がある。
- 実際の労働時間：開始工程と完了工程の時間差（自動収集）に加え、途中の停止（異常停留理由を手動で追記）も含む。
- 品質状態：初回検査、工程中検査、最終検査の三段階の記録があり、合格・再作業・廃棄の流れは独立しており、合格率のみを記入することは認められない。
- 材料の揃い：BOM上の各材料について、揃っている・未揃い・欠品待ちの三つの状態を設定し、作業指示書の状態と連動させる。
これら六つの側面をすべて独立した「イベントフロー」として分解し、一つの状態フィールドとしてまとめない。イベントは逐次記録であり、誰がいつ、どの工作機械で、どの工程まで進めたか、どのような異常があったかを逐一記録する。一方、状態はイベントフローから導き出される視覚的表現であり、状態フィールドは人手による入力は許されない。
02 どう設計するか：役割・プロセス・データ・インターフェースの境界線を明確にする
設計段階で最も陥りやすい落とし穴は、「アプリを作って人に記入させること」であり、運用二年経ってもアプリにはログイン画面とパスワード欄しかなく、空白のままだった。原因は役割とインターフェースの整合性が取れていないことにある。
役割設計
作業場には四種類の人がおり、それぞれが異なるインターフェースを使用する。
- 作業者：大きなボタンの作業台端末やタブレットを使い、「自分の担当している作業指示書」のみを確認できる。ボタンは三つ：開始・一時停止・完了。画面には表は一切表示されない。
- 班長：スマートフォンや作業場の看板を使って、当該班の全作業台の状態を確認し、わずか2分で「どこで詰まっているか」を見つけることができる。
- 調整担当者または計画担当者：PC端末を使い、工場全体の作業台のガントチャートと異常リストを確認し、特にスケジュール調整や異常対応に注力する。
- 品質または工芸担当者：独立した入口を持ち、初回検査の合格率、再作業率、SPCトレンドグラフなどを確認する。作業指示書の状態を直接変更することはできず、出せるのは「ライン停止」か「放行」のみ。
データモデル
コアとなる四つのテーブルに加え、いくつかの補助テーブルがあれば十分である。
- work_order：作業指示書のメインテーブルで、販売注文、計画注文、製品と関連付けられる。
- work_order_route：工程ルートで、各工程のノードに何個の作業を配置するかを定める。
- route_event：工程イベントフロー（コアの逐次記録）で、誰がいつ、どの工作機械で、どの工程まで進めたかを記録する。
- exception_log：異常ログ（材料不足、設備故障、品質再作業など）。
状態フィールド（status、current_step、progress_pct）はすべてroute_eventからリアルタイムで算出され、保存されない。保存されるのはイベントのみである。これにより、誰が作業指示書を変更しても、状態は常にイベントフローに基づいて決定される。
インターフェースの境界線
三種類の端末の境界線を明確に描く必要がある。
- 作業台端末：バーコードスキャン→作業指示書呼び出し→工程表示→大きなボタンで開始・一時停止・完了；いかなる数字フィールドへの入力も禁止され、すべての数字はPLCまたはバーコードスキャナーによって自動的に記録される。
- 班長用看板：当該班の作業台をグリッド化した視覚的表示で、緑は正常、黄は超過ペース、赤は異常。赤をクリックすると異常ログの詳細へ直接ジャンプする。
- ディスパッチャーPC：ガントチャートに資源負荷と異常キューを追加し、異常は必ずキューで分類する必要があり、ガントチャート内に混在させて「異常を探させる」ようなことはしてはいけません。
03 開発方法：収集・インターフェース・検収の三重のゲートウェイ
開発段階の核心的な命題は「現場が使いたくなるようにすること」です。現場が使いたくなるためには、「ワンクリックで済む」ことが前提であり、「大量の入力が必要」なわけではありません。その背後には三つのゲートウェイがあります。
収集ゲートウェイ
収集は三層構造になっています：
- 設備の直接収集：CNC、射出成形機、SMTはOPC UAまたはModbusを使用し、起動・停止信号、現在のプログラム番号、カウント値をリアルタイムでイベントストリームに書き込みます。この部分は最も難易度が高いものの価値も最も高く、一度実装すれば以後は人手に依存しなくなります。
- バーコード読み取りとボタン操作：手作業の作業ステーションでは、バーコードリーダー（部品）と大型ボタン（開始／一時停止／完了）を使用します。バーコードリーダーはUSB HID経由で動作し、出力は文字列のみです。OCRや画像認識は行わず、現場のネットワーク環境が不安定だと画像処理はすぐに使えなくなります。
- 計量／計数／光電センサー：材料の重量測定、部品の個数カウント、安全光電センサーなどは、すべてPLC信号をOPCに変換して処理します。
三層は共通の収集ゲートウェイサービスを利用し、ゲートウェイが異なるプロトコルを統一されたイベント形式（JSON）に正規化して、メッセージキュー（KafkaまたはRabbitMQ）へ書き込みます。その後、サブスクリプションサービスが消費してデータベースへ反映します。このため、設備や加工ステーションを変更する際もゲートウェイのみを改修すればよく、メイン業務システムを再構築する必要はありません。
インターフェースゲート
外部インターフェースには二種類あります：
- 上流側：ERPまたはMESから作業指示書、販売注文、BOMが発行されます。これは主データソースであり、本システムは読み取り専用で書き込みを行わないため、二つのシステム間で作業指示書の状態が相互に変更されることを防ぎます。
- 下流側：財務システムには労働時間やコスト情報が必要であり、顧客システムには納期進捗情報、サプライヤーシステムには部品セット状況の確認が求められます。下流側は「イベントトリガー」または「定期的な取得」により情報を取得し、本システムの作業指示書状態への逆書き込みは許可されていません。
インターフェース設計原則：イベントフローは出るだけで入らないこと。本システムはイベントの発信元（source of truth）であり、外部システムは購読者です。このルールを守ることで、進捗状況は常に一つの真実だけとなります。
検証ゲート
検証とは「機能が使えること」ではなく、次の三つの事項を指します：
- データの真正性：ランダムに5枚の作業指示書を抽出し、ホワイトボードや現場の映像と照合して、システム記録と実際の開始・完了時刻の誤差が5分以内であることを確認します。
- 異常のクローズド・ループ：材料不足の異常を発生させ、班長による作成、調整担当者の処理、購買による補充、作業ステーションの復旧までの全工程を追跡し、5分以内に異常キュー内でその流れが確認できるかを検証します。
- サイクルタイムの比較：一週間にわたり各作業ステーションの実際のサイクルタイムを統計し、工芸定額と比較して、差異が30％を超える場合は自動的に警告票を発行します。
これら三つの項目をクリアして初めて、「工程の進捗が本当に見えるようになった」と言えます。
まとめ：導入の順序、リスク、指標
このようなプロジェクトの稼働は一度にすべてを行うのではなく、三段階に分けて進めます：
- 第一期（1～2ヶ月）：まず作業台端末と残業班長用の看板を導入し、対象は一つの生産ラインのみです。目標は「ホワイトボード上のメモの80％が自動的にシステムに同期される」ことです。
- 第二期（2～3ヶ月）：調整担当者のPC、異常キュー、設備直接調達を追加し、工場全体の主要生産ラインまで対象を拡大します。目標は「現場で進捗を電話で尋ねる必要がなくなること」です。
- 第三期（要望に応じて）：ERP、財務、顧客システムとの連携を行い、サイクルタイムの最適化やSPC分析を実施します。この段階は必ずしも必須ではなく、前二段階を終えた後、現場からのフィードバックを踏まえて判断します。
一般的なリスク：
- 現場での抵抗：監視や比較を恐れる心理です。解決策としては、画面には作業ステーションのみ表示し、個人は非表示にすること、指標は班単位で設定し、個人ランキングは作らないようにします。
- 収集漏れの問題：古い設備には通信ポートがなく、スキャナーによる代替しかできません。検証時には漏れ率が5％を超えないことを確認します。
- 労働時間の歪み：作業員が「数字を合わせる」ために何度も始動・停止を繰り返すケースがあります。システムは同一作業ステーションで5分以内に複数回の始動を検知すると、直ちに異常として記録します。
検証項目の成否を決める指標はたった三つだけです：
- 調整担当者の電話件数：導入後、50％以上減少します。
- 異常時の平均対応時間：時間単位から分単位へ短縮されます。
- 顧客が確認可能な進捗情報：納期遅延に関する苦情率が30％以上低下します。
これらの三つの指標を現場に持ち込めば、壁のホワイトボードは空になり、進捗管理という課題はようやく本当の意味で完了したことになります。