インドネシアの業務にスマホを使ったQRコード管理の仕組みを導入

業務システムの開発導入でもバーコードやQRの読み込みによるデータ収集はこれまでも行われておりますが、弊社ではここ数年製造現場や倉庫での現場端末の導入を検討されるお客様に対してスマホによるQRコード管理をお勧めしています。

ロット管理の概要

ロット管理システムの機能は「現物のロットの動きをシステムで記録する」ことであり、そのためにはシステムから発行する現品票をロットに貼り、現物が動くたびにをロット番号をキーにシステムに実績入力する必要があります。システムと現品をロット番号で結びつけるのが現品票です。

ロット管理システムでは、製造指図を発行する際に投入ロットを「引き当てる」、または生産実績を上げる際に投入ロットを「在庫選択する」、という人間の意識が介在します。BOM（部品構成表）に基づいて投入品目をFIFO（先入先出法）で自動引き落としすることは可能ですが、現品がシステムの動きどおりに投入される可能性は極めて低いでしょう。

究極のロット管理が製番管理であり、材料購入依頼時から製番をつけてしまえば、入荷時に製番付きで在庫として入庫し、製造指図に製番を指定することで正しい材料を引当て、製品になるまで製番はついて回ります。個別受注生産に合う方法であり、原価の把握も個別原価計算により製番単位に行われます。

ロット管理の目的

そもそもロット管理の目的とは何でしょうか？苦労してシステム上でロット管理を行っても、その情報が工場経営に有効活用されなければ無意味です。

ロットトレース

客先で不良品が発覚した場合の原因究明のため、システム上でトレースを行い、問題のロットとその影響範囲を特定することで、リコール対象ロットを限定し全品回収のリスクを低減します。また履歴が追跡できるというお客側や取引先への「安心」を提供することも大きいでしょう。

但しこれが可能なのは、現物の動きどおりにシステムに実績入力が行わており、現物とシステムが一致していることが大前提です。

在庫管理の正確性の維持

生産管理システムの実績入力の際に発生する計量誤差、紛失等によるシステム数量と実数量の乖離の管理が、ロット単位に可能になります。

ロット単位ではなく場所（工程）単位に実績を上げる場合は「どこに何が何個あるか」が把握できますが、在庫数量の最小のまとまり単位は「場所」である以上、気軽に「現物を数えて理論値が正しいかどうか確認」するのは困難です。場所にある在庫数を数えるのは棚卸という一大イベント？であり、通常は半日または終日仕事になります。

一方でロットという現品の流動単位で実績を上げる場合は「このロットに何個あるか」は流動先ごとにチェック可能です。つまり流動先ごとにロット数量をチェックすることは、流動先ごとに役割分担して在庫全体の理論値を常時チェックしていることと同じになります。

実績入力がリアルタイムに行われればベストですが、現実的には実績がシステムに反映されるタイミングが翌日になる工程（夜勤や土日出勤）と、安定的にリアルタイムに反映される工程（出荷工程）が混在します。システム上でロット管理が行われている場合は、ロット数量は後工程の実績数量で上書きされるので、後工程にいくほど正確な数量に収斂していきます。

バーコードフォーマットとロット番号

バーコードは通常Boxラベルや現品票に載るもので、バーコード管理を行なう場合に何をバーコードフォーマットに含めるかは悩ましいところです。ロット番号は必須として、それ以外にシステムに実績として登録されるために必要な情報がバーコード自体から、もしくはロット番号をキーに取得できるかを考慮する必要があります。

場所単位の在庫管理システムでは品目コードがキーになりますが、FIFOなどロット管理が必要になる場合は、在庫管理上バーコードには最低でもロット番号と品目コードが必要になります。場所情報は流動先で変わるため現品票のバーコードに含めることはしません。

ロット番号は「日付＋通し番号」で構成され、荷姿レベルまで管理したければ荷姿番号が必要になり、バーコードスキャン時の数量入力の手間を省きたければ入数も必要になります。

バーコードによるロット管理

現場オペレーションの基本は、倉庫であれ製造であれ出荷エリアであれFIFO（先入先出）ですが、これをシステム上で管理するかしないかというのは別次元の話です。もちろん在庫管理システムにFIFOの実装をすることは可能ですが、それを運用するには入力担当者が入出庫時に間違えずに正しいロットを選択する必要があり、運用負荷が格段に高くなります。

入荷（材料 IN）

入荷時に荷姿（またはパレット）の数だけ現品票を発行しスキャンして入庫処理を行ないます。同一ロットの現品票が全て同じであれば在庫は「品目コード－ロット番号」で管理され、荷姿ごとに管理が必要なら「品目コード－ロット番号－荷姿番号」になります。

棚番管理を行う場合は、入庫時に棚番を入力またはスキャンする必要がある。入荷時に荷姿の現品票をスキャンした後で、バーコード化された棚番リストからスキャンするか、棚番の物理的な場所に貼ってあるバーコードをスキャンし入庫とします。この場合在庫数量は「品目コード－ロット番号－荷姿－棚番」で管理されます。

材料出庫（材料 TRANSFER）

材料ロットの現品票をスキャンし材料を材料倉庫から現場材料置き場へ移動します。バーコードスキャン時に出庫数がキーインされなければデフォルトで荷姿の入数が現場材料置き場に移動します。

材料投入（材料 OUT）

製造指図に対して投入材料が間違っている場合は、アラートを表示させ誤投入を防止する。荷姿1パック使い切れなかった残りを材料倉庫に戻す場合はバーコードスキャン時に残数をキーインする。

初工程の製造実績入力（仕掛品 IN）

現品票のバーコードをスキャンし仕掛品在庫数量のプラスし、入庫数がキーインされなければデフォルトで荷姿の入数の入庫とします。

仕掛品在庫振替（仕掛品 OUT 製品 IN）

現品票をスキャンし仕掛品を引き落とし製品倉庫へ移動し、出庫数がキーインされなければデフォルトで荷姿の入数の出庫とします。

出荷指示書を発行

出荷予定数量分の在庫ステータスを引当数に変更します。

出荷（製品 OUT）

現品票をスキャンし製品の引き落とし、出荷指示と一致しない現品票をスキャンした場合はアラートを表示させます。

バーコードリーダー（スキャナー）

基本はPCにUSBケーブル（昔はRS232C）で接続しますが、BluetoothでPCとペアリングするタイプのものは、BluetoothスキャナーとかWirelessスキャナーとか呼ばれます。

ちなみにUSBケーブルでPCに1対1接続することをケーブル接続といいますが（そのまんま）、Bluetoothで通信を行う機器同士を接続することはそのまんまBluetooth接続と呼ぶよりも、「ペアリング」という特別な言葉で呼ばれます。

その理由として、例えばスマートウォッチとスマホを接続した状態でBluetoothスキャナーを使って出荷作業を行なう場合、3つのBluetoothの電波の中から、ちゃんとPCの電波を選択して通信できるような手順を踏むからであり、単なる接続を超えた意味を持っています。

バーコードリーダーはスキャナーとも呼ばれるとおり、単純にバーコードをスキャンしてデータを取り込むまでが役割であり、キーボードからの手入力による手間の省力化と、誤入力防止という2つの目的が果たせれば十分です。

例えば指図書の「指図NO」を読み込む場合の役割は、すばやく正確に指図NOを検索フィールドに入力することであり、引き続き業務システムが指図情報（指図NO・製造品目・出荷品目・入荷品目・移送品目・予定数量・場所 etc.）を画面に表示し、オペレーターが画面から実績情報（開始時間・終了時間・実績数量）を入力し更新します。

また例えば現品票の「品目コード＋ロットNO」を読み込む場合の役割は、在庫情報（品目・ロットNO・場所・数量 etc.）を画面に表示するまでであり、引き続きオペレーターが画面から実績情報（場所・実績数量 etc.）を入力して更新します。

バーコードリーダーを使ったオペレーションの中では、動作主体は以下のように変わります。

バーコードを認識できたかどうかはピッという音で判りますが、そのデータがPCに正しく取り込まれたかどうか、データが正しいかどうか、などの判断はPC側のアプリでやる仕事なので、基本PCのモニターが見える距離内で使用する前提です。

以前MM2100の工場にCipher Lab（サイファーラブ）という台湾メーカーの100mのレンジを持つBluetoothスキャナーを導入したことがあるのですが、せっかく遠距離通信できるのに、現品のある場所からPCの画面が遠すぎると、データが正しく読み込まれたかどうかの確認ができない、というジレンマに陥ったことがあります。

ハンディターミナル

ハンディターミナルと言った場合には、一般的には取り込んだデータをバッチでPCの業務システムに戻すタイプのものを指すようで、事前に作成した指図に対してハンディターミナルで実績を収集します。

ハンディターミナルの場合、現品ラベルのバーコード情報がハンディに溜められた情報とマッチするかどうかのチェックが目的であり、ハンディターミナルの中に以下の機能が実装される必要があります。

また指図情報をハンディターミナルに取り込む際のフォーマット変換や、実績情報を業務システムに取り込む際のフォーマット変換や実績計上の仕組みがインターフェイスとして必要になります。

無線ハンディーターミナル

別に通常のバーコードリーダとしてもバッチ式ハンディとしても使えるにもかかわらず、バッチ式のハンディターミナルと区別してWindows CEなどのOS搭載モデルを「無線ハンディ」と呼ぶ理由は、スキャンしたバーコード情報を無線で飛ばしてリアルタイムに処理することを目的として購入する場合がほとんどだからです。

通常のWindowsアプリの開発と同じ感覚で無線ハンディターミナル用のアプリの開発ができます。

スキャナー・ハンディターミナル・無線ハンディターミナルのどれを選べばよいか？

日本の倉庫の現場では当たり前のように行われているバーコードによる在庫管理も、インドネシアの日系企業ではまだこれから検討といったところも多いと思いますが、バーコードを読む機器はPCにケーブル接続またはBluetoothでペアリングするスキャナー式か、バッチでデータ転送するハンディターミナル式か、Windows CEなどOSを搭載した無線ハンディターミナル式かの3択になります。

どれを選択したらよいかの判断するために必要な基準をざっと挙げると以下のようになります。

「PCに接続して使うスキャナーでは現場で自由な作業が出来ない、かといって無線ハンディは高すぎる」という消去法でバッチ式のハンディターミナルが選択されるケースが多いのですが、ハンディ端末側で入出庫や棚卸作業をするためのメニュー形式のアプリと、それを受けて基幹システムにデータを繋ぐPC側のアプリの2つの開発が必要になり、市販されるハンディターミナルには独自のアプリ開発ツールが付随しているのが一般的です。

ハンディターミナルには日本のDenso・Casio、米国のDatalogic・Honeywell・Zebra、中華系のCipherLABなど有象無象ありますが、Keyence製は使用性、認識率、耐久性、照射角度の広さなどの面でレベチです。Android搭載が主流なので、アプリ開発も通常のWEB開発環境で行えるようになりました。

基幹システムへの実績計上方法

バッチ式のハンディターミナルを使う場合、基幹システムから発行した指図に基づいて実績を取得し、現品が指図どおりにスキャンされるかチェックしてから基幹システムの実績として連携するケースと、指図なしで現品をスキャンして取得した実績を基幹システムに計上する2通りの方法があります。

ハンディターミナル側でのアプリ開発

ハンディターミナル側ではメーカーが提供する独自のスクリプト（BasicまたはVBScriptライクの言語）を使って、基本はメニューとボタンとテキストボックスの3つで倉庫での入出庫作業を行うためのアプリを開発しますが、基幹システム側の指図情報やマスタデータをハンディ側に格納するデータベースは、無償で軽量（コアはわずか225KB）、基本的なSQL文はすべて使えるし、CSVファイルとの相性も抜群のSQLLiteを使うのが一般的で、PC上のエミュレーターで動作確認しながらの開発になります。

左図は製造指図に記載される投入予定情報に基づき、材料倉庫から製造現場に正しく材料が払出しするためにハンディを利用するフローですが、基幹システムで発行した指図のヘッダーに印刷された指図NOをスキャンし、該当する倉庫との棚から該当するロットの品目を出庫しているかどうかのチェックをかけ、実績数量との差異に許容範囲を持たせてエラー、もしくはアラートを表示させるなどの機能を実装させています。

ハンディターミナルでCSVファイルを使うということは、以下の4回のデータ変換が発生します。

棚に張ってあるラックラベルの棚番バーコードをスキャンするのは、材料出庫や出荷などの出庫処理の場合は、最初に出庫元棚番を読み込むタイミングで行い、入荷や製品入庫などの入庫処理の場合は、最後に入庫先棚番を読み込むタイミングになります。

業務システムにスマホによるQRコード管理を導入するメリット

ここ最近のインドネシアのスマホ決済市場では、GrabとTokopediaと連携するOVO、Gojekアプリの標準eウォレットであるGOPAY、そしてOVOとGOPAYの2強市場に積極的な割引戦略で商機を賭けるDANAの3つ巴でのシェア獲得競争が行われています。

レストランのレジ台に置いてあるQRコード、またはレシートに印刷されているQRコードを読み取り、スマホ内のアプリでチャージしてあるお金から引き落とす方式で、3社ともお得な割引やポイント還元を提供しているので、インドネシアでもあっという間にスマホ決済が浸透しました。

業務システムの開発導入の現場でもバーコードやQRコードの読み込みによるデータ収集はこれまでも行われておりますが、弊社ではここ数年製造現場や倉庫での現場端末の導入を検討されるお客様に対してスマホによるQRコード管理をお勧めしており、その理由は以下のとおりです。

手軽にローコストで導入可能

誰でもスマホは持っているので高額なスキャナーやハンディーターミナルを購入する必要はなく、QRコードを読み取り業務システムに反映させる機能さえ実装させれば短期間で手軽に導入することができます。

RFIDへの過渡期である今、レガシー技術に大きな投資はしたくない

将来的にはインドネシアの製造現場では、既存のバーコードやQRコードから、電波を用いてRFタグのデータを非接触で読み書きするRFID方式（Radio Frequency IDentifier）に置き換わることが予想されます。

レガシー技術であるバーコードやQRのスキャンのために別途読み取り端末を買うよりも、誰もが所有しているAndroidスマホを現場端末として利用するほうが費用を最小限に抑えることができます。

QRコードはスマホとの相性が良い

スマホのカメラは一次元バーコードよりもQRコードのほうが認識しやすい上、ラベルサイズも小さく収まります。

長い桁数の一次元バーコードを読み取るにはそれなりの品質のスキャナーを使う必要がありますが、QRコードであれば膨大な桁数の情報を安価なAndroidスマホで十分読み取ることができます。

日常生活でのスマホ決済に慣れている現場のインドネシア人作業者にとっても、スマホを使ったQRコード読み取り作業は負荷にならないはずです。

スマホ用アプリの開発が楽

ハンディーターミナルで棚卸や入出庫用のアプリを開発する場合、C言語や端末に依存する専用スクリプトでの開発になりますが、スマホのAndroidアプリ開発ならPhoneGap + HTML + jQueryで短期間に業務に特化したUI/UXのアプリ開発が可能です。

または業務システムのUIがレスポンシブなWEB画面であれば、スマホ専用アプリの開発すら不要になります。

QRコードをスマホで読み業務システムにデータ登録するイメージ

左の動画は、入庫処理画面から「QRコード読み取りボタン」を押すことでカメラが起動し、物品に貼られているQRコードをスキャンすることで、入庫処理が完了する簡単なデモです。

最初2件のレコード登録済の入庫処理画面から、新たにQRコードをスキャンすることによって、レコード件数が3件に増えていますが、スキャンしたタイミングで自動登録することも、連続スキャンで複数レコードをまとめて登録することも可能です。

弊社の業務システム開発テンプレートHana Firstの画面UIはレスポンシブなWEB画面であるため、別途スマホ用アプリを開発する必要はありませんが、PhoneGap + HTML + jQueryを使えば、短期間で入出庫処理、棚卸処理などのAndroidアプリを開発することもできます。

QRコードのスキャンにより業務システムへの実績登録を行う場面として想定されるのは、材料の入荷処理、材料の出庫処理、製品の入庫処理、廃棄処理、出荷（ピッキング）処理などです。