株式会社青柳総本家 × enebular 導入事例
「このシステム、自分たちで作れないか」と思ったことはないでしょうか。外注すれば費用がかかる、専任のエンジニアもいない、でも期日は迫っている。こうした状況に、名古屋の老舗菓子メーカー、青柳総本家が置かれました。そして、生産管理チームリーダーの馬場翔太氏が、プログラミング未経験のまま、1か月でシステムを立ち上げました。
なぜ食堂の利用記録システムだったのか
青柳総本家は現在を「第二創業期」と位置づけ、売上高10倍成長を目指しています。その戦略の柱の一つが、工場IoT化によるDXです。設備の稼働状況を可視化し、業務を効率化する。最終的な絵は大きいものです。
しかし、いきなり工場の基幹システムを内製しようとは考えませんでした。馬場氏の言葉が、この判断をよく表しています。
「IoTの自社開発体制の構築に向けた最初のステップとして、まずは難易度の低そうなこのシステムの内製に取り組み、ノウハウを蓄積したいと考えました」
食堂利用記録システムを選んだのは、機能的に小さく、失敗しても基幹業務に直接影響しない領域だからです。加えて、実務上の期限もありました。連携していた勤怠管理システムの解約が2025年4月末に迫っており、早急なリプレースが必要でした。
新しい設備を本ラインに入れる前に、小さな検証ラインで試す。製造現場ではおなじみの発想が、DXの進め方にも活きています。
なぜenebularを選んだのか
情報収集の中で、ウフルのWebサイトにあったenebularを使ったイベント参加者記録システムの事例記事に目が止まりました。「直感的なインターフェースとローコードで誰にでも簡単に、短期間でIoTのシステムを開発できる」という内容が、課題感と合致したのです。
決め手は、ツールの機能というよりも、スタート地点の設計でした。ウフルは食堂利用記録用のサンプルフローと手順書を提供しました。コードを大きく書き換えることなく、ほぼそのまま使えるものです。ゼロから作るのではなく、動く見本が手元にある状態からスタートできる。この差が、未経験者にとって決定的でした。
実際にどう進んだか
2025年3月末にプロジェクトを開始し、解約期日まで約1か月という状況でした。提供されたサンプルと手順書の通りに実装を進め、予定期間内に構築を完了しました。
トラブルがなかったわけではありません。自社で用意したデバイスがシステムと連携しない不具合が出ました。ただ、これはenebular側の問題ではなく、ハードウェアの連携の問題でした。ウフルに問い合わせると迅速かつ丁寧に対応してもらえ、すぐに解消できたと馬場氏は振り返ります。
完成したシステムの仕組みは以下の通りです。
- 社員が食堂入口で社員証を非接触ICカードリーダーにかざす
- Raspberry PiベースのIoTデバイスがプログラムを実行し、社員IDと利用時間をenebular（クラウド）へ送信
- データがGoogleスプレッドシートに自動で書き込まれ、いつでも参照できる状態になる
稼働後に変わったこと
新システムがもたらした変化は、大きく二つあります。
一つは、データ管理の手間が大幅に減ったことです。以前は食数の確認のたびにシステムにアクセスしてデータをダウンロードする必要がありましたが、今はGoogleスプレッドシートを開くだけです。残業が減った担当者もいるとのことです。
もう一つは、データへのアクセス権限の広がりです。馬場氏はこう語ります。
「今月の各社員の食堂利用回数や選んだメニューのリアルタイムなデータをもとに、翌月の食数を予測してフードロス削減につなげるなどの施策を、以前よりはるかに迅速に、的確に行えるようになりました。従来、データにアクセスできるのは総務部の特定の社員だけでしたが、今は私も必要なときに見られますし、経営陣も直接アクセスできるようになっています」
この事例が示すこと
青柳総本家が得たのは、稼働しているシステムだけではありません。「自分たちでコントロールできる」という感覚と、IoT内製化のノウハウです。
馬場氏はすでに次を見ています。工場のコンベアで流れる製品を光センサーで監視し、生産数や不良数をリアルタイムで記録する仕組み。設備故障時にIoTでアラートを各部署に自動通知する仕組み。これらはまだ構想段階ですが、食堂システムで積んだ経験が、その具体化の土台になりつつあります。
基幹から始めない、小さく始める、ノウハウを積んでから本丸に向かう。青柳総本家の取り組みは、製造現場のDXをどこから始めるかという問いへの、一つの実践的な答えを示しています。
本ブログ記事は事例記事を元に再構成して執筆したものです。
