はじめに
こんにちは。株式会社High Link ロジスティクス開発のかんたろう(kantarow)です。
今回の記事では、弊社の物流業務を委託している倉庫の検品業務にハンディターミナルを導入して業務を効率化した話を紹介します。
ハンディターミナルで動作するアプリケーションはRuby on Railsを使って開発されています。こういった事例はなかなかないと思いますので、参考までに実際の開発についても紹介します。
ハンディターミナルとは
ハンディターミナルはコードの読み取りが可能な携帯端末です。モデルによっては文字認識が可能なものもあります。
この記事では倉庫内の検品業務に話を絞りますが、身近なところでは配達員やコンビニの店員が利用しているのを目にすることがあります。
携帯性に優れるので、PCなどの比較的大きめの機器が入り込めない環境でのリアルタイムなデータ収集・処理で活用されることが多いです。
ハンディターミナルを導入する理由
私たちが開発している物流業務システムは、受注から発送までの業務を支援することで効率化を図っています。
今までシステムを介入させることができなかった検品作業を効率化するために、ハンディターミナルの導入を決めました。
今まで検品作業にシステムを導入できなかった最大の理由は、操作のオーバーヘッドです。
例えばPCを使って検品を行う場合、伝票番号をバーコードリーダーで読み取ってシステムに入力し、画面上に表示される商材のリストと現物を目視で突合しながら登録作業を行う必要があります。この際に使うのはキーボードとマウス、バーコードリーダーになりますが、これらを扱うための手間の積み重ねが大幅な遅延に繋がると考えられます。
他にもPCを置くスペースの問題やバッテリーの問題、本体のコストの問題などがあり、この領域のシステム管理を見送る原因になっていました。
一方、ハンディターミナルを利用すると、機器を使う作業のほとんどをコード読み取りに置き換えることができます。
小型であるため取り回しがよく、モバイル前提なので駆動時間の問題もクリアできます。
また画面表示だけでなくバイブレーションで利用者に検品の成否を伝えるるなど、ハードウェアの特性を利用して業務体験の改善が可能です。
運用のための前準備
ハンディターミナルを利用するには、商材がハンディターミナルで識別可能である必要があります。現実的にはそれが不可能な商材もあるので、一部の商材については印刷されたバーコードのリストで対応しました。
しかし、メイン商材である香水のアトマイザーは、ハンディターミナルで識別する必要がありました。
弊社が運営する香りの定期便カラリアでは、4mlのアトマイザーに小分けされた香水をサブスクリプション形式で毎月購入することができます。
この香水には製造日と内容物から構成されるロット番号が付与されています。このロット番号は比較的視認性が悪く、人の目で確認し続ける限り間違いが起こるリスクがあります。
逆に言えばハンディ導入で最も改善を見込めそうなポイントです。
アトマイザーを識別するために、最初はOCRによるロット番号の読み取りを検討しましたが、最終的にラベルにmicroQRを印字する方法に決定しました。
microQRは非常に小さなスペースに印刷可能で、小さなアトマイザーの検品に用いるのに適しています。幸いアトマイザーに貼るラベルには余白があったため、そこにmicroQRを印刷することで、ハンディターミナルによる検品が可能になりました。
検品アプリケーションの開発
今回私たちが選定したのは、キーエンス製のハンディターミナル「BT-A500」です。
この製品にはAndroid OSが搭載されており、Androidアプリを開発するためのSDKも配布されています。
またハンディターミナルにプリインストールされたブラウザからハードウェアの機能を扱えるようにもなっており、JavaScriptを利用したWebアプリケーションとしての開発も可能になっています。
私たちの物流業務システムはRuby on Railsで開発されているため、今回はJavaScriptを利用する方法を選びました。
アプリケーションコードとハンディターミナルの関係は下図のようになっています。
ハンディの開発元からはkjs-modules.js というラッパライブラリのようなものが配布されているので、これをアプリケーションコードと一緒にRailsから配信します。
このようにすることで、アプリケーションコードがハンディターミナルに直接依存することを避けられます。
私たちにとってハンディターミナルのような専門的なハードウェアでの開発は初めてでしたが、Web技術を利用することで普段の開発と同じように進めることができました。
また既存のシステムに直接組み込めるため、つなぎ込み作業が必要なく、自由度が高い開発が可能になりました。
これは業務システムを自社で開発しているメリットだと思います。
通常のブラウザ環境での開発
開発開始当初はトライアル機を使って実際の動作を確認しながら開発することができましたが、運用に入ってからは全機を現場で利用していたため開発機が無い状況でした。
この問題は先述したkjs-modules.js から利用している機能群をモックすることで、最低限の動作確認を行えるようにすることで解決しました。
具体的には、図中にも記載がある_scanManager などの機能をページ内にインジェクションするChrome拡張機能を開発することで実現しています。
いくつか例を挙げると、拡張機能が提供するフォームに値を入力すると読み取りのコールバックが呼び出されたり、バイブレーションやブザーのAPIを呼び出すとそのパラメータが表示されたりします。
あまり作り込まれていない補助的な拡張機能ですが、最終的に実機で確認するまでの間の手段としてはよく機能しています。
ハンディを導入してできるようになったこと
ハンディを導入したことによって、検品作業者に伝票に記載されている以外の情報を知らせられるようになりました。その代表例が配送先別仕分けの情報です。
伝票は最終的に、関東、沖縄、その他の配送先地域に仕分けられて発送されます。この仕分けは伝票に記載されている住所から人力で行うこともできますが、ハンディを使えばシステム上で判別することが可能です。
実際の運用では、ハンディターミナル側では「期待する配送先地域」を設定しておきます。例えばそれを関東に設定した場合、関東以外の伝票が読み込まれると作業者に警告します。こうすることで作業者は伝票をわざわざ仕分ける必要がなく、警告されたときだけ個別で対応すればいいので、認知コストが低減されます。
また、伝票は配送先地域でソートされており、検品作業者はほとんど同じ配送先地域を連続で処理することなるので、警告の発生頻度を抑えることができます。仕分けのための警告はあくまで検品に便乗する形にすることで、作業の複雑性を下げています。
また、検品が行われた伝票をシステム上で特定できるようになったことで、集荷をお願いしている配送業者に伝票番号のリストを渡せるようになりました。配送業者はこのリストがあることで業務上のメリットを得られるとのことで、社内物流にとどまらないサプライチェーンの合理化にも役立っています。
おわりに
今回は倉庫にハンディターミナルを導入するに至った経緯と効果、Web技術による検品アプリケーションの開発について紹介しました。
ハンディを導入するにあたっては倉庫業務の物理的な制約を考慮することが多かったのですが、それらをハンディの特性を活かした工夫で乗り越えるのがとても楽しかったです。
また今回はWeb技術を活用した開発でしたが、組み込みあるいはネイティブアプリケーションのイメージが強い領域でも十分力を発揮することがわかり、Webエンジニアとしては大変興味深かったです。
High Linkでは物流システムを内製している強みを活かし、物流業務を積極的に改善しています。社内物流×ITの仕事に興味を持っていただけたら下記のリンクからご応募ください！
