なぜブラウザベースにこだわるのか――工場のPC・タブレット・OS依存を減らす設計

当社では、商品情報、一括表示、規格書、ラベル印刷の操作を、できる限りブラウザへ集めたいと考えています。

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

理由は、技術的な流行ではなく、現場で使う端末の事情です。

工場ではPCを開いて座る操作が合わないことがある

製造現場では、商品や原料を確認しながら移動します。デスクトップPCの前へ戻るより、タブレットで商品情報や規格書を確認できる方が自然な場面があります。

Accessを中心にするとWindows PCが前提になります。ブラウザであれば、Windows、Mac、iPad、Androidなどから同じ入口へアクセスできます。

• 商品情報を確認する
• 原材料や包装資材を選ぶ
• 一括表示案を作成する
• 規格書を閲覧する
• ロットと印刷枚数を指定する
• 履歴を検索する

ブラウザ化の目的は「どの端末からでも同じデータを見ること」

端末へ個別のAccessファイルを配るのではなく、データの正本をサーバーへ置きます。サーバー側を更新すれば、各端末は次回アクセス時に同じ画面とルールを利用できます。

同時編集、権限、変更履歴も、ファイルを配布する方式より一元的に設計しやすくなります。

ラベル印刷の終端にはWindowsが残る

「全部ブラウザベース」と言っても、現在検討しているBrother b-PACを使う方式では、印刷を実行する端末にWindows、b-PAC、対応ブラウザ拡張機能、プリンタードライバーが必要です。

したがって、目標はすべての端末から直接プリンターを制御することではありません。

商品データ、表示作成、印刷指示はブラウザへ統一し、プリンター固有の処理を小さな印刷エージェントへ閉じ込める。

在庫管理ツールではブラウザからBrotherラベルプリンターへ出力する経路を検証済みです。この経路を一括表示へ転用し、タブレットから印刷ジョブを作り、Windows端末がジョブを受け取って印刷する形も検討できます。

関連情報：在庫管理で検証したBrotherブラウザ印刷を、一括表示ラベルへ転用できるか

ブラウザ化しても、自動的に安全にはならない

Webシステムには、認証、権限、通信の暗号化、バックアップ、監査ログ、入力検証、同時編集制御、脆弱性対応が必要です。

社外公開する必要がない機能は、社内ネットワークやVPNからのみ使える構成にすることも重要です。

OS依存を減らす代わりに、サーバーとWebアプリを保守する責任が生まれます。それでも、当社の端末構成と、情報を一か所へ集めたい目的にはブラウザベースが合うと判断しました。

この連載の記事

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