ツール先行でハマらないために：Access→ブラウザDBへ進めた実務記録

この記事の前提

ここで紹介するのは、少人数・多品種小ロットの食品製造業である当社の経験と判断です。各製品やサービスの優劣を断定するものではありません。機能、料金、契約条件、法令は変更されるため、導入・表示作成時は必ず最新の公式情報と自社の運用条件を確認してください。

食品製造業では、一つの商品について多くの情報を扱います。

商品名、原材料、添加物、アレルゲン、内容量、賞味期限、保存方法、栄養成分、製造者、JANコード、包装資材。さらに、取引先ごとの製品規格書や商品登録表があり、同じ情報を別の様式へ何度も転記する場面があります。

最初にツールを選ぶと、後から苦しくなる

私はExcelを使い、次にMicrosoft Accessで商品情報と一括表示ラベルを管理する仕組みを作りました。その後、FileMaker、kintone、Exment、eBASE、インフォマートなども検討しました。

振り返ると、最初に考えるべきだったのは「どのツールならすぐ始められるか」ではありませんでした。

完成したとき、どの情報が、どこからどこまで一つにつながっていてほしいのか。

当社がつなげたかったのは、単なる商品台帳ではありません。

一部分だけを先に作ると、そのツールの得意な範囲に業務を合わせることになります。後から連携範囲を広げようとしたときに、データ構造、ライセンス、画面、出力方式などの制約が見えてきます。私自身、この順序で何度も立ち止まりました。

Accessは、表、フォーム、クエリ、帳票を短期間で組み合わせられます。商品情報をデータベース化し、一括表示ラベルへつなぐ最初の実装には非常に役立ちました。

一方、当社では複数人で利用する中でファイル破損を経験しました。また、工場ではデスクトップPCを置いて操作するより、タブレットを持って確認する方が合う場面が多くあります。WindowsとAccessを前提にすると、端末の選択肢が狭くなりました。

そこで、まずAccessの機能をPHPとMySQLへ移し、ブラウザから利用できる状態にしました。現在のWeb版にはAccess時代の一枚表に近い構造が残っており、完成形ではありません。

kintoneは短期間で業務アプリを作り、通知やプロセスを組むことに強みがあります。ExmentはOSSのWebデータベースとして高機能で、帳票へ書き出す機能も魅力です。eBASEやインフォマートの規格書サービスは、商品情報を取引先と受け渡す用途に強みがあります。

ただし、当社では一括表示、独自の規格書、取引先別様式、ラベル印刷、履歴までを一つのデータから動かしたいという構想がありました。各サービスの得意領域と、当社が一体化したい範囲が完全には一致しませんでした。

そのため、既製サービスを否定して自作を選んだのではありません。得意な部分は活用し、自社固有の生成処理や連携はブラウザベースで作る、という役割分担へ近づいています。

当社では、在庫管理ツールからBrotherのラベルプリンターへブラウザ経由で印刷する仕組みをすでに検証しています。

少量多品種で必要枚数が変わる当社では、QL-800のような小型ラベルプリンターとの相性が良いと感じています。この既存の印刷経路を、一括表示ラベルへ転用できないか検討しています。

現在できているのは、商品情報の一覧・検索・編集・複製、CSV出力、JAN管理、Brotherテンプレートとの紐付け、印刷履歴の土台などです。

現在進めているのは、次の段階です。

完成した万能システムを紹介する記事ではありません。業務を続けながら、Accessから引っ越し、段階的に作り直している記録です。

ツールを触り始める前に、最終的にどこまで連携させたいかを描く。その構想と、会社の人数、端末、費用、保守できる範囲を照らし合わせて選ぶ。

「まずはここから」と始めること自体は必要ですが、完成形を持たずに始めると、後からデータをつなぐ段階で沼にはまりやすい。これは私自身が経験したことです。

この方法がすべての会社の正解ではありません。同じように人手と開発時間が限られた小規模事業者にとって、何を先に考えるべきかの参考になればと思います。