kintone・FileMaker・Exment・規格書サービスを検討して分かった――構想から逆算するツール選び

商品情報をデータベース化しようとすると、さまざまな選択肢があります。

当社でも、Microsoft Accessから次へ進む候補として、FileMaker、kintone、Exment、eBASE、インフォマートなどを考えました。

関連情報：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由

どれも得意な領域があります。問題は、機能一覧の多さだけで選ぶと、自社が最終的につなげたい業務とのずれに後から気付くことです。

先に決めるべきなのは「どこまでつなぐか」

当社が構想していたのは、次のような流れです。

商品マスタ
  ├─ 原材料・複合原材料・添加物
  ├─ アレルゲン・栄養成分
  ├─ 包装資材・JAN
  ├─ 一括表示
  ├─ 自社製品規格書
  ├─ 取引先別の提出様式
  └─ Brotherラベル印刷
         └─ ロット・枚数・再印刷履歴

ここまでを一つのデータから動かすのか、規格書だけなのか、単純な台帳と検索だけなのかで、向くツールは変わります。

kintone：業務アプリを早く作れるが、UIと長期運用は自社との相性を見る

kintoneは、フォーム、一覧、通知、プロセス管理などを組み合わせ、クラウド上で業務アプリを早く立ち上げやすいサービスです。外部連携やプラグインを利用できるコースもあり、多くの業務を組み立てられます。

一方で、私自身は標準UIの操作感や情報の見せ方が、作りたい現場画面と完全には合わないと感じました。これは機能の不足というより、私の好みと現場の使い方との相性です。

また、当社のような少人数企業では、利用人数に応じた継続費用、最低契約数、追加機能、将来のデータ移行も判断材料になります。業務の中心を置いた後で価格体系や運用方針が変わっても、簡単に移行できない可能性があります。

そのため「すぐ作れるか」だけでなく、5年後にどこまで依存しているか、データをどう持ち出せるかまで考えました。

FileMaker：画面と業務アプリを作りやすいが、当社では費用との均衡を検討した

FileMakerは、データベースと業務画面を一体で作りやすく、モバイルを含む運用も考えられる点が魅力でした。Accessからの移行先として自然に思える部分もあります。

当社では、使用人数や端末が時期によって変わること、長期運用することを踏まえ、ライセンスとサーバーを含む継続費用との均衡を慎重に考えました。

FileMakerが不得意ということではなく、当社が自前サーバーとWeb技術を扱えることも含めると、別の選択肢を取りやすかったという判断です。

Exment：帳票出力は魅力的。私はリレーションの組み合わせで詰まった

ExmentはOSSのWebデータベースとして非常に高機能です。ブラウザで利用でき、権限、履歴、検索、ワークフローに加え、データを帳票へ書き出せる点は大きな魅力でした。

商品情報を保存し、検索・閲覧し、定型の帳票へ出力する用途では有力な選択肢だと感じています。最終的に、記録の保存先や閲覧先としてExmentを利用する形も考えました。

私が詰まったのは、複数段のリレーションを組み合わせて独自の生成処理へつなげようとした部分です。

例えば、商品から原材料を参照し、その原材料が複合原材料を持ち、さらに構成原料、添加物、アレルゲンを展開し、表示順序を整え、規格書と一括表示の異なる出力へ使う、といった構造です。

私の設計やExmentへの理解が十分でなかった可能性もあります。ただ、少なくとも私は「思った組み合わせにならない」「どこでどう関連付けるのがよいか分からない」という場面にはまりました。

Exmentに帳票出力機能がないのではありません。帳票出力はむしろ良い機能です。私が難しく感じたのは、帳票へ渡す前段の複雑なリレーションと、当社固有の組み立て処理でした。

関連情報：AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX

この経験から、汎用Webデータベースへすべてを押し込まず、保存・検索・閲覧はExment、表示生成などの固有ロジックは別のWebアプリ、という分離も現実的だと考えるようになりました。

eBASE・インフォマート：食品規格書の共有に強いが、社内の全工程とは役割が異なる

eBASEやインフォマートの規格書サービスは、食品の商品情報を収集し、規格書として取引先へ提出・共有する領域に強みがあります。

当社が困っていたのは、それに加えて次の作業が別々になっていたことです。

• 取引先独自のExcelやテンプレートへの転記
• 一括表示の作成と更新
• Brotherラベルプリンターへの出力
• JANや包装資材との紐付け
• ロットと印刷履歴の管理

規格書サービスが不得意というより、取引先との情報共有を中心とするサービスと、社内の商品マスタを起点に製造周辺業務まで動かすシステムでは、中心となる目的が異なります。

外部提出には既存サービスを使い、社内では共通商品データを管理し、必要に応じて転記・出力を補助する形も考えられます。

Access：早く作れるが、当社では端末と複数利用が課題になった

Accessは、当社の最初の商品データベースとラベル出力を作るうえで非常に役立ちました。既存のOffice環境で開発でき、帳票も作れます。

ただ、当社では複数人利用中にファイル破損を経験しました。Access全般が必ず破損するという意味ではなく、当時の構成や運用を含む当社の経験です。

工場でタブレットを使いたいこと、端末のOSを限定したくないこともあり、ブラウザベースへ移行しました。

自作Web：自由度は高いが、最も楽な選択ではない

自作Webシステムでは、画面、データ構造、ラベル印刷、規格書変換を当社の要件に合わせられます。

一方で、認証、権限、バックアップ、監査ログ、脆弱性対応、障害対応、法改正への追従を自社で担います。担当者が自分だけになれば、別の意味で属人化します。

自作は無料の代替品ではありません。ライセンス費用を開発・保守の時間へ置き換える選択でもあります。

当社で感じた得意領域と注意点

「まず使ってみる」前に出口まで描く

試してみなければ分からないことはあります。ただ、業務データをため始める前に、少なくとも次を確認した方がよいと感じています。

• 最終的に何と何を連携させるか
• データの正本をどこに置くか
• 独自帳票やラベル出力が必要か
• 利用人数と端末はどう変化するか
• 料金が変わった場合に移行できるか
• CSV等でデータを取り出して再利用できるか
• 自社で保守する範囲と外部へ任せる範囲

ツールを起点に業務を広げるのではなく、完成形を描き、それぞれの得意領域を組み合わせる。この順序が、私のように途中ではまる可能性を減らすと思います。

参考にする公式情報

• kintone公式料金
• Claris FileMaker公式料金
• Exment公式サイト
• eBASE公式サイト
• BtoBプラットフォーム 規格書

この連載の記事

1. 第1回：ツールから選ぶと沼にはまる――小規模食品メーカーがAccessからブラウザDBへ進んだ理由
2. 第2回：食品表示と規格書をExcel・Accessで管理する限界――転記が増え続ける理由
3. 第3回：kintone・FileMaker・Exment・規格書サービスを検討して分かった――構想から逆算するツール選び
4. 第4回：なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計
5. 第5回：Accessの商品マスタをPHP・MySQLへ移した――まだ「引っ越し段階」の食品表示DB
6. 第6回：在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか
7. 第7回：何枚印刷したかを残す――ラベル履歴・ロット・商品情報を結ぶ設計
8. 第8回：一括表示を「私しか作れない」から「誰でも作れる」へ――食品表示DBの再設計
9. 第9回：商品マスタ・一括表示・製品規格書を一つのデータへ――取引先別書式との向き合い方
10. 第10回：AIで長年の構想が動き出した――食品現場と技術を横断して組み立てる小規模DX