最初に増えるのは、削減量ではなく停止時間の数字
MESを入れてダウンタイムの記録を始めると、多くの工場で最初の3か月は停止時間の数字が増えます。設備が悪化したわけではなく、それまで記録されていなかった停止が見えるようになるためです。
この現象を事前に説明しておかないと、「MESを入れたら稼働が悪化した」という誤った結論になり、プロジェクトが止まります。導入前に、経営側と現場側の双方に対して「最初の数か月は数字が悪化するように見える。それが記録が機能している証拠である」と合意しておいてください。
減らす対象を決めるには、まず停止時間を分解します。
⑤の未記録時間は、必ず計算式で出せます。「計画稼働時間 −（生産時間＋記録済みの停止時間）」の残差です。この残差を毎日ダッシュボードに表示するだけで、記録の精度は数週間で目に見えて上がります。残差が計画稼働時間の5%を切るまでは、削減施策の議論に入らないことをお勧めします。分母となる計画稼働時間の定義はMESで見るべきKPIの記事で扱います。
停止理由コードは3階層・40個以内に収める
停止理由コードの設計は、ダウンタイム管理の成否をほぼ決めます。よくある失敗は両極です。
- 粗すぎる：「設備異常」「材料待ち」「その他」の3つしかない。集計はできるが打ち手に結びつかない
- 細かすぎる：120個ある。現場は探すのが面倒で、上から3番目のコードばかり選ぶ
実務で機能するのは3階層・末端40個以内です。
| 階層 | 内容 | 個数の目安 | 誰が使うか |
|---|---|---|---|
| 第1階層 | 大区分（段取り／故障／チョコ停／待ち／品質対応） | 5〜6 | 経営報告・KPI集計 |
| 第2階層 | 対象（機構部位、材料、人、前工程 など） | 各3〜5 | 改善テーマの選定 |
| 第3階層 | 現象（詰まり、警報コード、欠品 など） | 全体で40以内 | 保全・改善の実作業 |
設計上の原則は3つです。
- 現場が選ぶのは第2階層まで。 第3階層は、設備の警報コードや後からの分析で自動的に埋める設計にします。現場に3階層すべてを選ばせると、選択時間が停止時間より長くなる場面が出ます。
- 「その他」は第1階層に置かない。 「その他」は各第2階層の下にだけ置き、月次で件数を監視します。特定の「その他」が上位に来たら、それは新しいコードが必要というサインです。
- コードの追加は許容し、削除と再定義は原則しない。 既存コードの意味を変えると、その時点で過去データとの連続性が切れます。この考え方は不良コード体系の記事と共通です。
自動判定と手入力の境界を1つのルールで決める
停止の記録は、開始・終了・理由の3つに分かれます。実装で迷うのは「どこまで自動化するか」ですが、判断基準はシンプルです。
開始と終了は必ず自動、理由は原則として人。
開始・終了の時刻は、設備の運転信号、サイクル完了パルス、信号灯の状態、生産カウンタの停滞など、いずれかの方法でほぼ確実に自動取得できます。ここを人手にすると、記録漏れと時刻の丸め（「だいたい10分」）が発生し、集計が使い物になりません。古い設備からの信号取得は設備接続の記事で扱います。
一方、理由は自動化が難しい領域です。設備の警報コードから理由を推定できるのは非計画停止の一部で、材料待ちや人待ちは設備からは判別できません。ただし、理由の入力を後回しにできる設計にすると入力率が大きく上がります。停止の瞬間は復旧作業が最優先なので、理由は復旧後、あるいはシフト終了前にまとめて入力できるようにします。未入力の停止を一覧で表示し、シフト終了時に埋めさせる運用が現実的です。
チョコ停（1件が数十秒〜数分の微小停止）は、この原則の例外です。件数が多く、1件ずつ理由を入力させるのは不可能です。チョコ停は「発生回数と合計時間だけを自動で数え、理由は付けない」と割り切り、回数が閾値を超えた設備・品目の組み合わせだけを個別調査の対象にします。
打ち手はデータの粒度で決まる
集めたデータで何ができるかは、粒度で決まります。逆に言えば、狙う打ち手から必要な粒度が決まります。
| やりたいこと | 必要な粒度 | 追加で必要になるもの |
|---|---|---|
| 設備別の停止時間ランキング | 設備×日×理由（第1階層） | 設備マスタの整備のみ |
| 品目切替に起因する停止の把握 | 停止イベントに製造指図・品目を紐づける | 停止時刻と作業実績の時刻同期 |
| チョコ停の多発条件の特定 | 秒単位のイベント、品目・金型・材料ロットの紐づけ | イベント量に耐えるデータ設計 |
| 予兆にもとづく保全 | 停止イベント＋設備の連続値（温度・電流・振動） | ヒストリアン等の時系列データ基盤 |
上の2行はMES単体でほぼ実現できます。下の2行はデータ量とデータ基盤の設計が必要で、MESの中に抱え込むとデータベースが肥大化します。停止イベントはMES、連続値は時系列データ基盤という役割分担が基本です。記録機能そのものの実装はダウンタイムの記録と分析の記事、保全業務との接続は設備の保守・保全管理の記事で扱います。
記録が定着したあと、最初に取り組むべき順序
未記録時間が5%を切り、理由コードが機能し始めたら、削減の議論に入れます。着手順は、削減効果ではなく打ち手の確実性で決めてください。
- 待ち（④）から着手する。 材料待ち・指示待ち・前工程待ちは、設備に手を入れずに計画とルールの変更で減らせます。効果が出るまでの期間も短く、投資を伴いません。
- 段取り（①）を次に。 外段取り化と手順の標準化は方法論が確立しており、成果が読めます。
- 故障（②）は保全体制の話になる。 部品在庫、保全要員のスキル、点検周期の見直しが絡むため、時間がかかります。
- チョコ停（③）は最後。 原因が設備の設計や材料のばらつきに起因することが多く、恒久対策には設備改造や仕様変更が必要になる場合があります。
多くの工場が③から始めてしまうのは、チョコ停が現場でもっとも目につくためです。しかし合計時間で見ると④の待ちが最大であることが少なくありません。分解したデータがあれば、この順序は議論ではなく数字で決まります。
よくある質問
停止理由の入力率が上がりません。何から手をつけるべきですか？
入力率が低い原因の大半は、入力のタイミングと操作数です。まず「復旧直後に必ず入力させる」運用をやめ、未入力一覧からシフト終了前にまとめて入力できるようにしてください。次に、選択操作を2タップ以内にします。よく使うコードを上位に固定表示し、直近に選んだコードを既定値にするだけで入力率は大きく変わります。それでも上がらない場合は、コードの粒度が現場の認識と合っていない可能性が高いので、実際に選ばれているコードの分布を見て統廃合します。
チョコ停は何秒から数えればよいですか？
規格として決まった閾値はありません。実務では、設備のサイクルタイムを基準に決めます。1サイクル分の遅れは正常なばらつきの範囲、2〜3サイクル分以上停滞したら停止として数える、という置き方が扱いやすい方法です。重要なのは秒数そのものではなく、閾値を設備ごとに定義してマスタで管理し、変更履歴を残すことです。閾値を変えると過去との比較ができなくなるため、変更日を記録しておかないと分析時に混乱します。
停止時間の目標値は、他社と比較できますか？
分解の定義がそろっていない限り比較できません。同じ「稼働率95%」でも、計画休止や段取りを分母・分子のどちらに入れるかで数字は大きく変わります。他社比較を行うなら、まず時間の区切り方をISO 22400のような共通の枠組みにそろえる必要があります。実務上は、他社との比較より自社の同一設備の時系列比較と同一工程を持つ自社他拠点との比較のほうが、はるかに行動につながります。
