【生産技術の視点】生産現場が本当に欲しいITってなんだろう－現場編【考察】

親会社の派遣(ここでは弊社と述べます)でやっていた鉄工所の生産技術の任が解かれることになりました。今までITエンジニアでありながら現場に密着していたので、現場が必要なITはなんだろうかと振り返ることにしました。私の経験をもとにしているため弊社鉄工所を基準としています。

各技術のレベルはこの記事のアップした段階のものをさします。

生産現場が求めるITのゴール

生産現場が求めるITのゴールとして、”ITのための作業がないIT”を求めています。一言でいえば製品品質や設備に関わるデータを全自動で取得・記録してくれるシステムです。

しかし鉄工所の現場はそんなITの実現はまだまだ先、人手によるITの運用が必要です。それならばせめて製造・検査工程のデータ入力の手間を最小限にする簡易化を行うこと、人のデータ入力作業をサポートすること、これが今の現場が望んでいるITであると考えます(ゴールに対するベンチマークの観点からも同様)。

分かりやすい例は検査工程かと思います。私がすぐに浮かぶのは電子回路の検査装置です。例えばカメラによるシルクの表示の欠陥や配線パターンの欠落の検出、目に見えない箇所は通電による回路動作の正当性の確認、最後は検査記録の保管を一貫して自動で行う、といった具合です。

電子回路は量産時、いわばデジタル的な検査が可能です。あるべき姿が明確であり、その判定基準も同じく明確に設定できるからです。先ほどのシルクやパターンの欠陥はパターンマッチングを元に精度を上げるアルゴリズムを実装すれば検出可能であり、通電による回路動作はねらった入出力のピンに電気が流れたか流れていないか、電圧・電流値の大小といった判断で検出可能です(実装における大変さは私も知っているところですので、あえて触れません)。

鉄の世界はデジタルに判別できないアナログの世界(検査工程の例)

”ITのための作業がないIT”が理想である一方、鉄の世界ではそんなうまい話はありませんでした。

検査工程を例にすると、鉄はアナログ的な検査が必要でした。鉄はあるべき姿が明確な一方で判定基準が明確に設定できないからです。圧延のような円柱または四角柱の長棒を検査するならまだしも、鍛造品のような複雑な形状のものにたいして異常となる状態をつかんだとしても100%の精度で異常を検出できません。せいぜい「異常の可能性がある」止まりです。最後は人間の判断が必要です。

例えば、鉄の凹へこみが規定値を満たしてるかをしらべるには針デプスを使用すればよいでしょう。しかし、鉄の凹みは発生個所がバラバラであり、すべての箇所を測るのは工数の制約上現実的ではありません。また凹みの状態によっては針デプスでは測定できない箇所もあります。最終的には人の目視による判断に委ねられます。

様相が異なる異常に対して人は最高のAIである

おいカワッター、昨今はAIによる画像検査が発達したじゃないか、ほぼ一瞬ですべての箇所の凹みを検出できるじゃないか、ともいわれるでしょう。残念ながらあらゆる場所で発生し、角度によって様相がことなる凹みに対して機械学習(教師ありorなし・強化学習)・ディープラーニングを用いて対応させることは今の段階ではまだまだ確実ではありません。人間が最も優秀なAIと言っても過言ではありません(私はこの様相が異なることをよく”バラツキが大きい”といっています)。

他にも目に見えない異常の例として、鉄の傷があります。磁化＋磁粉＋ブラックライトによる検出がありますが、鉄の凹みの場合と同様のため割愛します(ほかにも色々な異常があります)。

たかが鉄の凹み一つとっても”ITのための作業がないIT"にはほど遠いのが現状です。またAIは凹み以外の様々な様相をもった異常に対して検出できる人間に敵いません。

人によるデータ入力のデメリット(ググれば出るが生技の立場として)

様相が異なる異常に対しての判別は人が得意であるがために、異常の記録も人間によりデータ入力が必要であると言わざるを得ません。

人によるデータ入力による作業のデメリットはネットでもググれば沢山でてきますが、私は生産技術員の立場として、次の2つの具体的な情報を残せないことが手作業によるデメリットの大部分を占めていると考えています。

共通点は記録を図で残すことができない、図を元にした一元管理された情報として記録を蓄えられないことです。

1. 製品品質の観点
   工数の問題上、製造や製品検査工程で出た製品の形状(寸法)、不良の状態・数や場所を正確に残すことができない
2. 設備保全の観点
   設備の異常内容と場所が過去データと紐づかずすぐにたどれない

弊社の場合、”1.”や”2.”に関わらずデータの入力作業はラインのオペレータ(作業者)の作業です。監督者(班長以上)は有事以外はあくまでも管理側の立場です。そのためオペレータは実際の製品の生産中、色々な異常の第一人者となります。

以下、具体例です。

製品品質の観点

これは簡単そうにみえて非常に厄介な問題です。監督者や私のような生産技術員の立場からみると「なんでこんな簡単なこともできないのか」になりがちになるため。

しかし、実際にやってみると次のことが分かります。実際に生産技術員として自身の試作製品の品質を自分でみたことでわかりました(理屈だけでなく体に染み込ませた、という意味で)。

• 製品を測る行為そのものが辛い(その場で記録さえ取れれば何とかなるレベル)
  鍛造品を例に。物を測ることは誰もが簡単にできそうに見える作業です。500gの比較的軽いものなら良いでしょう。しかし、重くて5kg、酷いときは20kgを超えるものはどうでしょうか。一箇所測るだけで骨が折れます。
  1200℃を超える真っ赤な鉄をリフトで釣り上げる作業(玉かけ・吊り上げ)、決して明るくない場所で・曇ったゴーグルで見る1mm単位のメモリ。測定具を素手のように扱えない2重の軍手状態。ひたすらにしんどいです。
  ただ、ここら辺は製品の根幹をなす作業であり(何だかんだ言って)現場の教育・測定ノウハウが必然的に継承されるため、記録さえ取ればなんとかなるところでもあります。
• そもそも製品に不具合がないかをチェックすることが大変
  一日に合計数千個と製造・検査している中、不良を1個でも流出すれば即客先クレームに直結する可能性大。どれだけ注意深く検査しても人手の作業、必ず見落としは発生。また、基本的にカウンタはログ機能はないため、不良の数も手書きになり書き間違えが発生。
• その後で図を使って記録することはもっと大変(絶対無理)
  実際は大きなパレット毎に検査した記録(製品番号・不良の種類・数など)を残すが、それでも数百個とあり不良の場所や状態を全て思い出しながら記録することは不可能。
  製造・検査工程に関わらず製品は数秒～長くて数十秒に1個流れているため、できて不良の傾向のみの把握である。
  そのため図示日報を書いてくれと頼むが、大抵は現場の負担が大幅に増大となるためよほど余裕がない限り断られる。

検査記録は我々が不良の原因を調査・対策するための細かさににはなっていません。どんな不良が・何個あったかはデータを入力・蓄積した社内イントラで追えるでしょうが、製品のN数が膨大であることによる「どこに・不良の程度は」を記録をとれないため分かりません。またようやく図示日報の記録を現場の協力を得てやってもらえたとしても”ある時点(スポット)”の記録のみで終わり、蓄えていくことができません。

結局、検査記録はISO的な審査向けの資料で役目をおえてしまうでしょう。

設備保全の観点

生産・検査に関わらず、設備の異常が発生した場合、オペレータは設備の軽度・重度の異常に関わらず監督者を呼び出します(設備を止めた後で)。

前提として、オペレータは勝手な判断をしないことを徹底します。設備の異常はオペレータが独断をして処置をしてしまった場合、処置時のエアシリンダ内の残圧によるケガ(で済めば良い方)、回転物の突然の動作による巻き込まれなどを誘発させやすくします。基本、えぐいものばかりです。最悪、人命をなくすことだって普通にあります。

設備修理を終えた後、記録作業をするのですが、その時にできることと言えば次のような例でしょう。材料をラインに供給するロボット搬送の例とします。

一見して問題ない報告内容です。しかし、これも前節「製品品質の観点」と同じ問題をはらんでいます。設備以上を一元管理された情報として蓄えることができないことです。

製品とくらべ記録のN数が少ないため写真などで不良が「どこに・不良の程度は」を説明することは可能ですが、情報が報告書どまりになってしまいます。もし同様の異常を調べたければ、社内ネットワーク内の報告書が保存されている年度フォルダから一つ一つExcel(Word)を開く作業をせざるを得ないでしょう。

現場作業員の入力の簡易化へ(実装もスモールに)

人手のデータ入力は製品品質・設備保全の観点からみて記録を図で残すことができない、図を元にした情報として記録を蓄えられないことを述べました。結果、異常の様相まで把握しないといけない場面で現場の改善・新製品の量産時の過去トラブルの把握までつながらないことになります。

ではここでITエンジニアの出番だ、自動化だ、と発想が出てくるのですが、重要な事があります。それは現場は完全自動を望んではいない、ということです。つまり、入力が簡易的であることが重要と考えます。

私は様相が異なる事象に対応するITは全自動の処理(特に異常の判別)は逆に不向きであると考えています。なぜなら「同じ内容でありながら様相が異なる事象」の扱いは人間が一番得意としていることだからです。初めの段階は精度が悪いですが、訓練されれば先ほど例にとった熱い鉄の寸法は早く・正確に、鉄の凹みの深さは相当な精度で目視判別できるまでに達します。すくなくともAIなど比にならないレベルです(疲労・悩みなど外乱要因があれば精度は落ちますが)。
※補足として、限度見本などで都度”異常の基準”を確認できることは必要になります

上記のことから、製造・検査に関わらず、人間は訓練を経ることで事象の判断と程度の重みづけに高い精度を持っていることが分かります。全自動化はこの判断と重みづけも担当することになりますが、今のところAIであっても「同じ内容でありながら様相が異なる事象」で人間を超えることはできません。

つまり、製造業でも「同じ内容でありながら様相が異なる事象」を扱う場合は、人間がやることとITがやることを役割分担することがまず第一に考えるべきです。すると、自然と現場が求めるITの形が分かってきます。冒頭述べた”簡易化(データ入力補助)＝人間のサポート役に徹すること”になります。

私の考える"入力の簡易化"は、今では古臭い言い方になるでしょうが、オペレータにとって使いやすいGUIの提供です。検査工程の場合、次の例となります。

1. 環境としてタブレット端末を扱いやすい箇所に設置、製品番号ごとの3Dモデルを表示
2. 不良が発生したら3Dモデルをクルクル回転させて不良箇所を指定(タップ)
3. そこから不良モードを選択、必要あればそのまま写真を撮影(ここで1.～3.の紐づけ完了)
4. 不良が出るたびに1~3を繰り返し、データを蓄積していく

以上のような方法なら図をもとにした記録を蓄えることが可能です。なお、3Dモデルがない場合は2Dの形状図を使用すると良いでしょう。図を起点にできればよいと考えます。
GUIの入力項目および階層は最小限にとどめます。GUIとなるとあれもこれも突っ込みがちですが、そうなると操作者の使い勝手がおちるため、製品の検査作業のサイクルタイムの延長をまねきます。そのため使用目的は限定すべきです。

設備故障の場合なら1.の3Dモデルが設備全体の表示にすればよいでしょう。

ITエンジニアは以上の仕様をもとにシステム構成・ER図・機器選定などを進めていきます。

運用はネットワークの連携(既存イントラの更新も含む)も計画の中に入れがちですが、まずはスタンドアロンの方が良いでしょう。ネットワークの連携は社内SE部門との協議が必須で実装時もデータの同期の問題がついて回りプロジェクトがシームレスに進行しなくなる可能性があり、さらに大抵は会社のお偉いさんの進捗報告があることから、ネットワークの話をさせないためです(報告の場では要点のみの説明では話が混乱しやすい)。
なんにせよ、ネットワークによる実装は今後の拡張仕様として定義する方がよいでしょう。面倒ですがログについては社内セキュリティ認可がおりたSDカードで運用です。

※補足として、目に見えない1サイクルずつの値が品質を決定する物性値は着目をしていません。もちろんあるべき姿は全自動で全ての物性値のログを取るべきと考えます。
物性値：モータの電流値、材料の長さ・温度・射出時の冷却水の流量(こちらも温度)、プレスの荷重など

生産技術部隊にスムーズに情報フィードバックできるIT

これは前章で述べたネットワークの連携の実装のことを指します。現場が蓄えた図を元にした一元管理された情報を社内イントラでいつでも閲覧できるようにします。今回の記事の趣旨から外れてしまうため実装の苦労については割愛します。

内容が設備寄り＆データの紐づけは言及されていないですが、ググってパッと出た結果ではこれが近いイメージです。

3Dモデルを用いた橋梁維持管理システムの開発

J-STAGE

doi.org

ネットワークの連携のねらいは生産技術部隊へ現場が蓄えたデータを使ってもらい、現場で対応できない(生産技術部隊じゃないと対応できない)現場の改善に取り組みやすくさせることです。現場はデータを蓄えるだけでダイレクトに生産技術舞台に情報を送ることができます。そのため製品品質の不具合であれば「どこに・不良の程度は」まで盛り込むことができていますし、設備不具合であれば過去の類似の異常をたどることが可能です。

これは現場と生産技術部隊のコミュニケーションコストの削減を意味します。

現場は製品品質の不具合であれば「この不具合って製品のどこについてた？」「どれだけ酷い不具合だった？」といったことを聞かれなくても済みますし、設備の不具合であれば「以前も同じことおこってた？」を聞かれなくて済みます。

生産技術部隊も片道10～20分かけて工場に足を運び、さらに関係者に話を聞く必要はなくなります。また関係するオペレータが反対番(大抵夜勤)であればせっかく工場に行ったとしても無駄足になってしまいます。実際に生産技術をやっていましたが工数面・効率面で地味にきつかったので、意義は十分にあります。

上記より、改善だけに焦点をあてても現場－生産技術部隊、双方にWin-Winとなります。

さらに、生産技術部隊にとってもうまみがあると考えます。生産技術部隊が行う新規品(他部門の開発品やお客からの依頼品など)の量産を実施する場合です。生産技術部隊は必ず似たような性能や形状をもつ類似品の不具合を確認します。このとき過去の製品品質の検査実績から図と紐づいた不良の詳細を確認する事で量産体制構築のためのスケジューリング・調査・不具合対策がやりやすくなります。

費用対効果の闘いへ

今回のような話は弊社以外でも日常的に言われてきていると思いますが、結局最後は次の金の話が大きな壁となって立ちふさがります。

• 新規システム投入時の正確な金勘定が困難
  システム投入時、どれぐらいのコスト節減になるのか、ペイできる正確な時期はあるのか、運用は永続的にされる保証はあるのか。いつも悩まされます。それを会社のお偉いさんに説明することも。大抵は工数計算から正確な金勘定ができないため、投資額をペイできるコスト・期間も不明瞭になりがちです。
• 今回のようなシステムは無形固定資産の扱いになる
  税金の話です。前職の経験とあわせて書いているため正確でなかったら申し訳ありません。参考程度にみてください。
  いったん研究開発を終了(リリース)すれば無形固定資産として計上することになります。1年以上は運用、さらに将来の収益改善(工数改善：コミュニケーションコスト減や不良低減が目的)であることは確実であるためです。
  この”固定資産”が厄介で、年単位の減価償却となります。システムを新規に製作している段階で研究開発費(販管費)として一括で経費として勘定できますが、それ以降の扱いは固定資産です。
  
  詳しくは金融庁のHP(表現難解・分かりずらいが1次情報)や株式会社TOKIUM様のHPを見てみてください。

生産技術員の経験はITエンジニアのキャリアとしても無駄でないと思っている

約4年間、思わぬ形で鉄工所の生産技術員をしてきました。最初は転職したキャリアが生かされない人事配置に不本意であり嫌で仕方がなかったのですが、幸い前職より職場の人間関係に恵まれていたため(スポット的にはクラッシャー上司とかにやられかけましたが)、何とかやってこれたため次第にこの仕事もやりがいを見つけるまでに至りました(相当に愚痴りまくってたけど)。

この経験は私にとってこれからのITエンジニア人生として関連がない無駄なものに見えます。しかし私はそうは思いません。かといって無駄でない証明もできないのですが、それでもどこかで生産技術員としての経験がITエンジニアとしてのキャリアにプラスに働くと思っています。自分で言えることは3K職場で精神面の忍耐力と体力面の忍体力がついたかなと。

これからは本格的にITエンジニアとして動くことになります。その視点からみて感じたことがあればまた記事にしたいです。

では改めて再スタート。頑張りすぎない程度に頑張っていこうと思います。とりあえずいつも当日になるともぅﾏﾁﾞ無理。。会社やすも。。。になるのでその次の日から本気出します。

変更履歴