- share :
設備が何分止まったかは日報やExcelで把握できているのに、なぜ止まったのかを集計しても、どこを改善すればよいのかが見えてきません。製造現場には、そんな悩みを抱えている工場が少なくないのではないでしょうか。
その原因は、「センサーやIoTが足りないからだ」と考えたくなるかもしれません。しかし、集計が進まない原因は、機器の不足より先に、停止理由を記録するルールが現場でそろっていないことにある場合があります。
この記事では、IoT導入の前に決めておきたい少数の「停止コード」の作り方、1ラインで行う3カ月の手作業試行で確認する指標、そして自動化する範囲の考え方がわかります。
【本記事の要点】
- 6分類程度の「停止コード」を設計し、1ラインで3カ月の手作業試行を行う。
- 未入力率など4つの指標で、記録の質と改善の焦点を確認する。
- 信号で取れるデータと人の判断が必要なデータを分け、自動化の範囲を絞る。
稼働監視ツールを入れても停止理由が集計できない原因:記録ルールの不統一
古い設備を含む中小工場では、設備の稼働状況をExcelや日報で管理していることが多く、停止時間そのものはおおむね把握できています。問題は、その先です。「停止時間は分かるが、なぜ止まったのかを集計しても改善点が見えない」という悩みがあります。
本記事が想定する、同じ停止を人によって異なる名称で記録している現場では、原因は設備監視ツールの機能不足や、IoT・センサーの導入量そのものではありません。停止理由を記録するルール、すなわち「停止コード」が現場で統一されていないために起きています。
ある作業者は「材料待ち」と書き、別の作業者は同じ状況を「段取り」と書くこともあれば、忙しい時間帯に理由欄が空欄のまま次の工程へ進んでしまうこともあるでしょう。停止理由の表記が人ごとに違う現場では、どれだけ稼働率をグラフ化しても、改善すべきポイントは浮かび上がってこないのです。
中小企業基盤整備機構の生産工程診断資料は、設備投資に踏み切る前に、まず生産工程の現状分析と課題整理を行い、そのうえでIoT等の活用可能性を検討するという進め方を案内しています。停止理由の記録ルールを先に整えることは、この「現状分析を先に行う」という考え方に沿うものです。
稼働率の見える化ツールを先に入れても、入力される理由データの質が低ければ、集計結果は改善の判断材料になりません。順番を誤らないことが、最初の分かれ目になります。
出典・参照:
IoT導入前に決める「停止コード」の作り方
停止理由の記録を統一するには、現場の誰が書いても同じように分類できる、少数の「停止コード」をあらかじめ用意しておく必要があります。細かく分けすぎると入力の手間が増えて「その他」が乱発し、粗すぎると原因の特定に使えません。目安は6分類程度です。
停止理由を6つの大分類に分ける
代表的な大分類の例は次のとおりです。
- 故障:設備そのものの不具合による停止
- 段取り:品種切り替え・治具交換などの準備作業
- 材料待ち:部材・資材の供給遅れによる停止
- 品質確認:不良検出・検査対応による停止
- 人待ち:作業者の配置・応援待ちによる停止
- 計画停止:定期メンテナンス・清掃など計画済みの停止
この6分類は出発点であり、固定の正解ではありません。自社の現場で頻発する停止理由を洗い出し、必要なら大分類を追加・統合してよいでしょう。
重要なのは、誰が記録しても同じ分類に落ち着く、迷わない粒度にそろえることです。あわせて、どの大分類にも当てはまらない停止のために、暫定的な「その他」も選択肢に含めておきます。「その他」がどれだけ選ばれたかは、後で分類そのものの見直しに使う材料になります。
大分類を自社の現場に合わせて調整する
大分類を決める際は、次の2点を確認すると、記録が長続きしやすくなります。
- 現場の作業者が数秒で選べる数に絞る(目安は6〜8分類。多くても10分類程度まで)
- 「その他」を選ばざるを得ない停止が続くようなら、頻出する理由を新しい大分類として独立させる
分類名は、この記事の6分類をそのまま使う必要はありません。現場で日常的に使われている呼び方に近づけたほうが、記録の定着は早くなります。
1ライン・3カ月の手作業試行の進め方と確認する指標
停止コードを決めたら、いきなり全ラインへ展開したり、センサーで自動収集する仕組みを構築したりする前に、1つのラインで手作業による試行を行います。中部経済産業局の「ものづくりデータ活用サポートブック」は、中小製造業向けの支援資料として、簡易なIoTツール等で3カ月分の稼働データを集め、その実績平均を暫定標準稼働率として活用する進め方を紹介しています。
この記事が提案する「1ライン・3カ月の手作業試行」は、原典に書かれた手法そのものではなく、その考え方を停止理由の記録ルールづくりへ応用したものです。
紙かタブレットで、1ラインから始める
対象は1ラインに絞り、紙の記録用紙かタブレットの簡易フォームで十分です。作業者には、停止のたびに用意した停止コードから1つを選んでもらうだけにします。この段階でシステム投資をする必要はありません。目的は、コードの分類が実際に機能するかどうかを、現場で確かめることです。
見るべき4つの評価指標
3カ月の試行が終わったら、次の4つの指標を確認します。
| 指標 | 測るもの | 結果の見方 |
|---|---|---|
| 未入力率 | 把握できた全停止件数のうち、理由欄が空欄だった件数の割合 | 高ければ、コードの粒度や運用に無理がある |
| 「その他」率 | どの大分類にも当てはまらず、暫定の「その他」が選ばれた割合 | 高ければ、大分類の見直しが必要 |
| 停止時間上位3件 | 合計停止時間が長い停止理由の上位3件 | 改善に着手する優先順位の目安になる |
| 改善後再発率 | 上位3件に対策を行った後、同じ理由の停止が再発した件数・停止時間の推移 | 減っていなければ、対策の見直しが必要になる |
停止そのものの記録漏れまで確かめたい場合は、未入力率とは別に、設備カウンターや既存ログ、巡回記録などとの突き合わせが必要です。
上位3件に注目する考え方は、少数の原因が全体の停止時間の大半を占めるという、パレート的な見方に近いものです。全部の停止理由を一律に改善しようとせず、まず上位3件に絞って対策を検討し、対策後は改善後再発率で効果を確かめます。目標値は固定せず、自社の3カ月間の実績を基準に、そこからの改善幅で判断するのが基本です。
なお、OEE(設備総合効率)には業界一律の目標値を置かないことをおすすめします。設備の年式や生産品目、稼働条件は工場ごとに異なるため、他社の数値をそのまま目標にする意味は薄く、自社の3カ月間の実績平均を暫定基準として、そこからの改善幅を見るほうが現実的です。
出典・参照:
自動化する範囲の決め方:信号で取得するデータと人の判断に残すデータ
3カ月の試行結果がそろったら、ようやくIoT・センサー投資の検討に入ります。ここで大切なのは、停止の「理由」までを一律に自動化しようとしないことです。信号で取得できる観測事実と、人の判断が必要な情報を切り分けて考えます。
信号(PLC・センサー)で自動取得できるもの
設備のPLC信号やセンサーで比較的容易に取得できるのは、次のような観測事実です。
- 停止・再稼働の時刻
- 停止時間の長さ
- 設備の状態
- 取得可能なアラームコード
停止時間上位3件の理由が、こうした信号と相性のよい形で発生していれば、時刻や時間の自動記録から着手すると投資の効果が見えやすくなります。
人の判断が必要なもの
一方、段取り・材料待ち・品質確認・人待ち・計画停止といった「なぜ止まったか」という理由そのものは、停止信号だけでは通常確定できません。作業者による入力、または生産計画・操作情報との突き合わせが必要です。
あわせて、試行の段階では「暫定原因」と「行った処置」も人が記録する項目に加えておくと、後から原因がはっきりした時点で内容を更新でき、改善後再発率の確認にも使えます。
自動化するかどうかは、「停止時間上位3件だから自動化する」と単純に決めるのではなく、次の4点を見て決めます。
- 頻度と停止時間の大きさ
- 取得できる信号の有無
- 入力の手間
- 原因判定にどれだけ文脈判断が必要か
時刻・時間の自動取得と、理由の記録は分けて検討すると、投資判断を誤りにくくなるでしょう。
まとめ:停止コード設計、3カ月試行、自動化判断の順で進める
停止理由を集計しても改善点が見えてこない原因は、センサーやIoTの不足ではなく、停止理由の記録ルールが現場でそろっていないことです。IoT導入の前に決めておきたい「停止コード」の作り方から自動化の範囲まで、進める手順は次の3つに整理できます。
- 停止コードを設計する:停止理由を6分類程度の大分類に分け、自社の現場に合わせて調整して、記録の基準をそろえる。
- 1ラインで3カ月の手作業試行を行う:未入力率、「その他」率、停止時間上位3件、改善後再発率の4つの指標で、記録の質と改善の効果を確認する。
- 自動化の範囲を決める:時刻や停止時間のように信号で取得できるものは自動化し、理由や処置のように人の判断が必要なものは人が記録する。
停止コードで記録がそろえば、停止理由を集計できるようになり、改善点も見えてきます。この順で進めれば、IoT投資は範囲を絞って進められるでしょう。
高額な設備連携を検討する前に、紙かタブレットで、1つのラインから始めてみてください。
執筆者
株式会社MU 代表取締役社長
山田 元樹
社名である「MU」の由来は、「Minority(少数)」+「United(団結)」という意味。企業のDX推進・支援を過去のエンジニア経験を活かし、エンジニア + 経営視点で行う。DX推進の観点も含め上場企業をはじめ多数実績を持つ。



