プロフィール

このブログを運営しているユージです。

長崎県諫早市で、小規模な食品製造会社を経営しています。製造現場に立ちながら、業務システム、Linuxサーバー、データベース、ネットワーク、ESP32、電子工作、AIなどを組み合わせ、現場の課題を解決する仕組みを作っています。

私が重視しているのは、コードを書くこと自体でも、特定の技術を深く追究することだけでもありません。

現場で何が問題になっているのかを見極め、必要な仕組みを考え、使える技術や外部のリソースを組み合わせ、実際に動き、業務で使い続けられる状態まで持っていくことです。

業務課題の発見から、要件定義、技術選定、AIを活用した開発、インフラ構築、導入、運用改善までを一つにつなぐ。

その立ち位置を、私は「現場実装型エンジニア」と表現しています。

「フルスタック」ではなく、「現場実装型」

扱っている技術領域だけを見れば、フロントエンド、バックエンド、データベース、サーバー、ネットワーク、IoT、機器制御などを横断しているため、フルスタックエンジニアに近い部分もあります。

しかし、私の立ち位置は、一般的なフルスタックエンジニアとは少し異なります。

どの技術を使うかから考えるのではなく、まず現場を見ます。

• 現場で何が問題になっているのか
• なぜ、その作業に時間がかかっているのか
• どこで同じ入力や確認を繰り返しているのか
• 少ない人員と費用で解決する方法はないか
• 導入した後、現場の人が無理なく使い続けられるか

そのうえで、課題に応じて技術を選び、組み合わせます。

• 業務課題の整理と要件定義
• 既製サービス、自前開発、クラウド、オンプレミスの比較
• AIを活用したシステム開発
• サーバー、データベース、ネットワークの構築
• センサーや機械との接続
• 実際の現場への導入
• 障害対応、改善、運用の見直し

一つの技術分野を深く掘り下げることよりも、現実の問題を、実際に動く仕組みへ変換することが私の専門です。

コードを書くことより、実装を成立させること

現在の開発では、コードを最初から一行ずつ手で書くことを中心にはしていません。

AIへ目的、要件、制約、既存の構成を伝えて実装案を作らせ、内容を確認し、既存システムへ組み込み、実機で検証する進め方が中心です。

必要に応じて、公式資料、オープンソースソフトウェア、既存サービス、技術コミュニティ、専門家など、さまざまなリソースも使います。

重要なのは、すべてを自分一人の知識だけで作ることではありません。

何を作るべきかを判断し、どの技術を使い、どこを自分で持ち、どこを外部へ任せるかを決め、最終的に現場で使える状態へまとめることです。

AIが生成したコードが一見動いても、それだけで実用的なシステムになるとは限りません。

• データが壊れないか
• 権限設定に問題がないか
• 例外や異常時にどう動くか
• ログから原因を切り分けられるか
• バックアップと復旧ができるか
• 現場の操作で事故や誤処理が起きないか
• 継続的に保守できる構成になっているか

こうした点を確認し、問題があれば設計や実装を戻して修正し、運用できる状態まで持っていきます。

すべての技術領域を、専門家と同じ深さで扱えるわけではありません。深い問題が出たときには、資料を調べ、AIを使い、必要に応じて外部の知見も借ります。

それでも、問題がどの層にあるのかを考え、ログ、設定、ネットワーク、データベース、プログラム、機器などを順に切り分け、解決へ進めるための実装経験は積み重ねてきました。

私にとってAIは、経験や判断を置き換えるものではなく、調査と実装の速度を上げる開発リソースです。

最初からエンジニアを目指していたわけではありません

大学時代には、本格的ではないものの、BASIC、C言語、Perlなどに触れていました。

卒業後に勤めた会社では、営業などの業務を経験した後、社内の基幹システムからデータを取り出し、Microsoft Accessを使った集計システムや業務ツールの作成、予算に関する業務などに携わりました。

その頃から、次のようなことを考えるのが好きだったように思います。

• この作業をもっと楽にできないか
• 見えていないものを、数字やデータで見えるようにできないか
• 人が繰り返している作業を、仕組みに置き換えられないか

システム開発を専門として歩んできたわけではありませんが、必要なものを調べ、作り、実際に使いながら、データベースや業務システムの扱いを身につけてきました。

食品製造業に入って驚いた、情報と書類の多さ

食品製造業へ入って特に驚いたのが、取引先ごとに異なる書類やフォーマットの多さでした。

同じ商品を提案する場合でも、提出先が変われば、同じ情報を別の様式へ転記し直さなければならないことがあります。

• 商品規格書
• 原材料・アレルゲン情報
• 栄養成分や食品表示に関する資料
• 見積書・商品提案書
• 取引先独自の商品登録表
• 製造記録・品質管理記録

製造現場でも、温度、数量、設備の状態などを記録し、確認し、別の書類へ転記する作業が数多くあります。

現場へ入るほど、「これは本当に、人が何度も入力しなければならない仕事なのだろうか」と感じる場面が増えていきました。

ないものは、自分で作ってみる

最初から大きなシステムを作ろうとしたわけではありません。

目の前の不便を一つずつ減らすために、必要なものを作ってきました。

• 食品表示ラベルの作成を支援するツール
• データベースへ作業ログや記録を残す仕組み
• 社内パソコンへ安全にリモートアクセスする環境
• 外出先からFAXを確認、検索、返信できるシステム
• 温度、ドア開閉、設備稼働などを記録・通知する仕組み
• 製造数や作業状況をブラウザーから確認するWebツール
• OCRやAIを使って書類を分類・検索する仕組み

不便を解決しようとするたびに、必要になる技術が少しずつ増えていきました。

電子工作とWebシステムがつながっていった

製造現場の問題は、パソコンの中だけでは完結しません。

温度、扉の開閉、機械の動作、製造数量、異常の発生など、現実の設備から情報を取得する必要があります。

そこでRaspberry PiやESP32を使い始め、徐々に次の要素をつなげるようになりました。

• センサーやスイッチから情報を取得する
• ネットワークを通じてサーバーへ送る
• データベースへ記録する
• ブラウザーから状態を確認する
• 異常時に通知する
• 必要に応じてブラウザーから機器を制御する

電子工作 × ネットワーク × サーバー × データベース × Webを組み合わせることで、小規模な現場でも使える仕組みにできます。

業務以外の制作も、技術の検証になる

このブログでは、業務システムだけでなく、電子工作、DIY、修理の記事も扱っています。

例えば、壊れたラジコンを、専用プロポではなくスマートフォンやタブレットのブラウザーから操作できないか試したことがあります。

一見すると仕事とは関係ありませんが、実際に作るには、マイコン、モーター制御、電子回路、Wi-Fi、Web画面、安全に停止させる仕組みなどが必要です。

遊びや修理の中で試した技術が製造現場の改善に生きることもあれば、仕事で身につけた技術が別のものづくりに生きることもあります。

分野の境界よりも、使える技術を、必要な場所でどう組み合わせるかを重視しています。

クラウドと自前運用を使い分ける

クラウドサービスを否定しているわけではありません。便利で、外部へ任せた方が合理的なサービスは利用します。

一方、業務の中心になるシステムをサブスクリプションへ深く依存させることには慎重です。

• 料金が将来も同じとは限らない
• 利用人数や保存容量が増えると費用も増える
• 仕様変更やサービス終了があり得る
• 業務へ定着した後は、簡単に他のシステムへ移れない
• 蓄積したデータを完全に移行できるとは限らない

そのため、外部へ任せる価値が高い部分は利用しつつ、自社で持ち続ける意味が大きいデータや業務の核は、自前サーバーで動かすことがあります。

クラウドかオンプレミスかを最初から決めるのではなく、費用、保守性、データ、将来性を考えて選ぶ方針です。

私が横断的に扱っている分野

現在は、次のような分野を、現場の課題に応じて組み合わせています。

• 食品製造、食品表示、品質管理、作業改善
• 業務整理、要件定義、運用設計
• Linuxサーバーとオンプレミス運用
• Proxmox、Docker、WordPress、n8n
• PHP、Python、FastAPIなどを使ったWebツール
• MariaDBなどのデータベース
• ネットワーク、VPN、リモートアクセス
• ESP32、Raspberry Pi、センサー、電子工作
• ブラウザーからの機器監視・制御
• AIを使ったOCR、分類、調査、システム開発支援
• バックアップ、障害対応、ログ確認、運用改善

どれか一つの技術を使うことが目的ではありません。

現場の課題を解決するために、必要な分野を横断し、短期間で実装し、使いながら改善していくことが、現在の私の特徴です。

このブログで発信する理由

中小・零細企業では、効率化や自動化が必要だと分かっていても、導入費用、月額料金、保守、人員などの問題で実現できないことがあります。

私自身も、現場の仕事をしながら、どうすれば少し楽になるか、同じ入力や確認を減らせないかを考えてきました。

そして実際に作り、設定を間違え、通信できず、機械が思ったように動かず、プログラムの不具合に悩み、何日も原因が分からない経験を重ねてきました。

インターネットには完成した手順はあっても、「なぜうまくいかなかったのか」「どのように原因を切り分けたのか」という情報が少ないことがあります。

このブログでは、成功した方法だけでなく、失敗、調査、判断、修正、運用までの過程もできるだけ残します。

同じようなことで悩む小規模事業者や、現場の問題を自分で解決しようとしている方にとって、何か一つでもヒントになればと思っています。

このブログで扱う主な内容

サーバー・業務システム

Linux、Proxmox、Docker、WordPress、n8n、MariaDB、FastAPI、HylaFAXなど、実際に構築・運用しているシステムについて書いています。

ESP32・電子工作・IoT

温度記録、ドア開閉アラーム、設備カウンター、センサーとサーバーの連携、ブラウザーからの機器制御などを扱います。

食品製造現場の改善

食品表示、製造記録、品質管理、設備改善、画像検査、在庫・製造管理など、小規模な食品製造現場で発生する課題を扱います。

DIY・修理・実験

家電、車、電子機器、おもちゃなどの修理や改造についても、失敗や安全上の注意を含めて記録します。

記事を書くときに大切にしていること

• 実際に試したことを中心に書く
• 成功例だけでなく、失敗と切り分けも残す
• 自前構築を無条件に勧めない
• 費用、保守、安全性、セキュリティも考える
• 事実、推測、個人的な意見をできるだけ分ける
• AIを使った場合も、可能な範囲で実機や公式資料と照合する
• 古くなった記事は、可能な範囲で追記・修正する

運営者情報

最後に

このブログは、一つの技術を教科書的に解説するだけの場所ではありません。

地方の小規模な食品製造会社で、限られた人員、設備、費用の中、現場の問題を見つけ、必要な仕組みを考え、実際に作り、止まり、直し、運用へ乗せてきた記録です。

私は、技術そのものよりも、技術を使って現実の問題をどう解決するかということに興味があります。

既製品が自社に合わない。外注するほどの予算はない。人手も足りない。しかし、このままでは困る。

そんなときに、今あるもの、使える技術、AIや外部の知見を組み合わせ、現場で動く形にできないだろうかと考える。

それが、私のものづくりの原点です。

このブログのどこかに、同じような問題で悩んでいる方の役に立つ情報があれば幸いです。