河村化工株式会社 滋賀工場 御中 ／ 工場内DX推進担当 面接資料
CHIKAMORI ICHIRO ／ DANIEL ITIRO TIKAMORI
製造現場で働いている人間が、そのままIT側もやっています。
現在も滋賀の工場で、塗装ラインの下塗り後・乾燥炉の手前の工程を担当しながら、 個人事業のシステム基盤を設計・構築・運用しています。 説明会で伺ったことから考えたことは03に、 できないことは06にそのまま書いています。 下のリンクは全て、いま動いている実物です。
御社が Python・Raspberry Pi を使われていると伺い、同じ構成で稼働モニタを用意しました。
以下は今週、御社のために形にし、実際に動かしているものです。要件の設計と検証は私、実装はAIコーディング支援という分担です（06に記載）。Java / Spring Boot は自分で書いた学習成果で、ここには含めていません。
センサー Python SQLite ダッシュボード
(GPIO / 疑似) → OK/NG判定 → events表 → スマホで確認
サイクル計測
GPIO 17 ← 部品検知（立ち上がり = 1ショット）
GPIO 27 ← 検査結果（HIGH = NG。画像検査装置 / PLC から）
画面に出すのは数字ではなく次に確認すべきことです。不良率がシフト平均の2倍を
超えた時間帯に印をつけ、「同じ時間帯のサイクルタイムを確認してください」と書きます。
成形機の異常は不良より先にサイクルタイムの伸びに出るためです。
止まったラインと、まだデータが無いラインは別の表示にしています。
表示は日本語・ポルトガル語・英語を切り替えられます。
読めない画面は使われません。正しく動いていても、そこで止まります。
ベトナム語は選択肢に出したうえで、あえて無効にしてあります。私には正しさを確認できず、
不良名の訳が一語ずれる方が、英語のままより現場に害があると考えるためです。
現場の方に確認してから入れる、と画面上に書いています。
温湿度も同じ画面に入れています。金属加工では湿度は錆の問題ですが、
成形では品質そのものだと考えました。樹脂が吸湿するとシルバーストリーク・寸法不良の
原因になり、しかも不良が出るまで目に見えません。材料倉庫の湿度が基準を超えたときは、
数値だけでなく「乾燥条件と保管状態をご確認ください」と書くようにしています。
こちらは実際に稼働中のシステムです。タップで開きます。
稼働監視ボード（16項目） サーバー・アプリ・定期処理を常時自動チェックし、止まればその場で赤くなります。工場の行灯と同じ考え方で、対象がソフトウェアになったものです。 status.zaiketz.com LeveBase — 自作アプリ 企画から公開・運用まで一人で。スマートフォンアプリとして動きます。 levebase.com8月31日に滋賀工場を見学させていただき、伺った内容に合わせてこの章を書き直しました。 成形 → 塗装 → 組付けという流れ、組付けをカメラで確認し、 NGであれば作業者に知らせて出荷前に直せるようにしておられること、 その判定を記録として残し、それが客先へOK品のみをお出ししている保証になっていること、 部品箱の有無をセンサーで検知して作業者の端末に不足部品を知らせておられること、 そして「間違えても安全な仕組みにしたい」というお考えを伺いました。 以下は一般論ではなく、私が入ったら、どの工程から、何をするかです。 まだ伺えていない点は08に残しました。
1ヶ月目 ― 触らずに、いま何が取れているかを洗い出す。 成形機・検査装置・PLC・紙の帳票を回り、既に出ている信号と、出ていない信号を分けます。 この段階では何も変更しません。現場の手順を勝手に変えないことが先です。
2ヶ月目 ― 一番小さい所で、記録を1本だけ通す。 1ラインのOK/NGとサイクルタイムを、時刻つきで残すところまで。既存の装置は変更しません。 止まっても生産が止まらない形から始めます。
3ヶ月目 ― 現場が読める画面にして、実際に使われるか確かめる。 使われなければ、現場ではなく画面の方を作り直します。 DXが失敗するのは技術ではなく、現場で使われないときだからです。
DXで求められていることは、突き詰めると ムダ・コスト・時間・手間・ミス・あいまいさを減らし、意思疎通・効率・利益率・ 事業の継続性を上げることだと理解しています。 道具を入れることが目的ではなく、この結果が出なければ意味がないと考えています。 以下、左が現場でよく起きること、右が私が実際に作って運用しているもの、 上の札がそれで何が良くなるかです。
うまくいった話ではなく、自分で見つけて直した不具合を書きます。
毎日動くはずの書き出し処理が15日間まったく成功していませんでした。テストは全て「合格」。 原因は、テスト用のダミー部品が何を渡されても受け付けていたことです。 検査治具が不良品を通していた状態でした。
ダミーを実物と同じ厳しさに直し、欠けていた18日分・623件を欠損ゼロで復旧しました。
教訓：「テストが緑」は「動いている」ではない。実物が出たかを確認する。
アクセス数が631件と出ていましたが、実際の利用者は11件。残り620件は監視のために 自分が送っていた自動アクセスでした。測定器が測定対象に影響していた形です。
監視からのアクセスに識別印をつけて集計から除外し、過去の数値も実態に合わせて訂正しました。
教訓：数字が良く見えるときほど、測り方を疑う。
禁止事項を検出するはずのチェックが、条件の書き間違いで何にも一致せず、毎回「異常なし」を 返していました。合格は出るが、検査はしていない状態です。
以後、チェックを作ったら必ず一度わざと不良を流し、 赤くなることを確認してから本番に入れる手順にしました。 今日この資料を作る前にも同じ手順で自分の設定を試し、実際に1件、 見逃す欠陥が見つかって直しています。
教訓：止まることを確認していない安全装置は、無いのと同じ。
できないことを隠すと、入社後に御社が困ります。先に書きます。
分からない技術に当たったときの進め方は決まっています。 調べる → 小さく試す → 任せる／作る → 動くまで確かめる → 記録する → 本番に入れる。 AWS認定ソリューションアーキテクトも、上の監視基盤も、その順番で身につけました。
履歴書をご覧になって気になる点があると思いますので、伺われる前に申し上げます。
ご懸念は当然のものだと思います。隠して入社しても、困るのは御社です。 そのうえで、製造現場を12年知っていて、システムを実際に作って動かしている人間が 必要でしたら、私はその形に近いと思っています。