この記事の前提
ここで紹介するのは、少人数・多品種小ロットの食品製造業である当社の経験と判断です。各製品やサービスの優劣を断定するものではありません。機能、料金、契約条件、法令は変更されるため、導入・表示作成時は必ず最新の公式情報と自社の運用条件を確認してください。
食品製造業へ入って驚いたことの一つが、書類とフォーマットの多さでした。
同じ商品でも、取引先が変われば別のExcelへ転記します。自社の商品情報、食品表示ラベル、製品規格書、見積書、提案書、取引先独自の商品登録表が、それぞれ別ファイルとして存在します。
関連情報:商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方

商品は同じなのに、情報の置き場所が違う
例えば原材料を変更した場合、影響は原材料名欄だけではありません。

- 一括表示の原材料名
- 添加物の表示
- アレルゲン
- 栄養成分
- 製品規格書
- 取引先へ提出した個別フォーマット
- ラベルテンプレート
一つの変更を複数ファイルへ反映しなければならず、どこか一つが古いまま残る危険があります。
Excelは柔軟で、取引先から届いた様式へそのまま入力できます。しかし、その柔軟さが「同じ情報を各ファイルへ持たせる」運用につながりやすい面もあります。
Accessで一元化しようとした
そこで、商品情報をMicrosoft Accessへ集め、一括表示ラベルへつなげる仕組みを作りました。
Accessは、表、クエリ、フォーム、レポートを短期間で組み合わせられます。私にとっては、Excelからデータベースへ移る現実的な入口でした。
しかし、Accessで商品情報を管理できても、取引先から渡された別形式のExcelがなくなるわけではありません。規格書提出のたびに、Accessの情報を相手先書式へ移す作業が残りました。
小規模事業者ほど、転記の負担が重い
大企業なら、商品情報管理の担当者、品質保証、営業、システム担当を分けられるかもしれません。
小規模事業者では、製造や営業を行う人が、そのまま規格書や表示も作ることがあります。繁忙期に書類の更新が集中すれば、製造時間を削ることになります。
人が少ないからシステムを入れにくい。しかし、人が少ないからこそ転記を減らす必要がある。
必要なのはファイルの保管ではなく、共通データ
根本的に必要なのは、Excelを別のソフトへ置き換えるだけではありません。
関連情報:一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計
商品名、原材料、アレルゲン、栄養成分、期限、保存方法などを共通データとして持ち、必要な出力へ展開することです。

食品表示に関するルールは更新されます。システムが自動生成したから正しいのではなく、根拠資料と最新の制度を確認できる状態が必要です。消費者庁は事業者向けガイドやアレルギー表示情報を公開しているため、最終確認は公式情報と実際の配合・検査結果に基づいて行います。
参考資料
この連載の記事
- 第1回:ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由
- 第2回:食品表示と規格書をExcel・Accessで管理する限界――転記が増え続ける理由
- 第3回:kintone・FileMaker・Exment・規格書サービスを検討して分かった――構想から逆算するツール選び
- 第4回:なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計
- 第5回:Accessの商品マスタをPHP・MySQLへ移した――まだ「引っ越し段階」の食品表示DB
- 第6回:在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか
- 第7回:何枚印刷したかを残す――ラベル履歴・ロット・商品情報を結ぶ設計
- 第8回:一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計
- 第9回:商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方
- 第10回:AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX

