物流と在庫管理の
システムについて語りたい

about me

スライドのテーマ

別に誰も興味持たなくてもいいし、
誰もついてこなくていいから、
自分の得意分野について話したい。

という訳で物流の話をしたいと思います。

主旨としては、

「エンジニアの視点で、
物流とそのシステムについて語る」

という内容です。

その前に、自分の経歴について、もう少し。

がっつり物流やってました。

他社の物流業務を丸ごと一括して引き受け（3PLと言います）、 倉庫と開発現場が隣接しているケースも多々ありました。

現場や倉庫を走り回ってました。

現場や事務所と密な連携を取りながら、
システム開発を進めてきた経験を踏まえての話です。

免責事項

10 の現場があれば、10 の運用方法があります。

まず、物流の基本から。

物流６大機能

• 輸配送
• 保管
• 包装
• 荷役
• 流通加工
• 情報処理

物流６大機能

• 輸配送
• 保管
• 包装
• 荷役
• 流通加工
• 情報処理

よく話題に挙がるのは、ここ。

物流６大機能

• 輸配送
• 保管
• 包装
• 荷役
• 流通加工
• 情報処理

今日話すのは、ここ。

主に、在庫管理について話したいと思います。

超ざっくり分割すると、次の機能に分類されます。

在庫管理システム：機能概要

• 入荷
• 出荷
• 棚卸
• データ交換
• 請求・支払

入荷

複雑化する事は、あまり多くない。

また、いったん安定稼働に入ると、
システムが変わる事は、それほどない。

担当エンジニアのスキルレベルは、
初級～中級でも何とかなるケースが多い。

割くリソース：中

在庫管理システム：機能概要

• 入荷
• 出荷
• 棚卸
• データ交換
• 請求・支払

出荷

保有している商品を、
顧客や市場に向かって出す業務。

複雑化しやすい。

また、外的要因により、システムの改修が
必要となる事も多い。

稼働後も、頻繁に変える必要があるケースも多い。
エースを投入するなら、ここ。

割くリソース：大

在庫管理システム：機能概要

• 入荷
• 出荷
• 棚卸
• データ交換
• 請求・支払

棚卸

倉庫内に保有している商品の数量を
チェックする業務。

きっちりシステム化せずとも、
何とかなるケースも多い。

扱う商品によっては、ハンディターミナルで１つ１つ読み込ませる作業が現実的でないケースがある。
（その場合は、帳票を見ながら、目視で確認する。)

システム的な作業は、
事務所内で完結させる事も多い。

割くリソース：小

在庫管理システム：機能概要

• 入荷
• 出荷
• 棚卸
• データ交換
• 請求・支払

データ交換

入荷データ・出荷データ・棚卸データ
といった電子データを、ベンダーやサードパーティと
やり取りする業務。

重要なのは、交渉力と政治力。

状況次第で、現場やエンジニアに
大きな負担がかかる事があります。

自分たちが極端に不利（＝相手が一方的に楽）に
ならないようにしよう！

システム的に重要なのは、スピードよりも正確性。

「粗いが早い」エンジニアより、
「じっくり作ってバグが少ない」エンジニアの方が
この工程に向いてます。

割くリソース：中～大

在庫管理システム：機能概要

• 入荷
• 出荷
• 棚卸
• データ交換
• 請求・支払

単純化できないなら、
システムでカバーしない方がいい。

計算の仕組みが、超絶複雑となる事も多い。

会計知識が必要だったり、妙なローカルルールに
盛大に振り回されりする事も。

重症化すると、物流のシステム作ってるのか会計のシステム作ってるのか、分からなくなるレベルに達します。

加えて、計算ルールがベンダーごとに違っていたり、 ルールがコロコロ変わる事も珍しくありません。

また、
『割高になるけど
計算がシンプルで事務作業が軽減される』
という計算方法より、

『計算が複雑怪奇でも、
安くできる（可能性がある）』
計算の方が好まるケースもあります。

そういった場合、

「請求と支払の計算に必要な帳票は出せるように
　しているから、計算はそっちでやってね♪」

という方向に持っていくのが理想です。
（そう出来ないケースも多いでしょうけど・・・）

そんな感じで、発生した課題に対し、
技術のみで解決しない方法が、
ベターな選択となる事も多いです。

最後に、システム導入について

物流の現場は多種多様です。

自前で保有しているシステムが、
「現場の運用にマッチしない」
といった事は多々あります。

そんな時、

1. 業務に合わせてシステムを変える
2. システムに合わせて現場の運用を変えてもらう

といった選択肢があるかと思います。

１．業務に合わせてシステムを変える

導入がスムーズに行きやすい。
こっちで進めてほしいと言われる事が多い。

ただ、システムが１点ものになったり、
一部の機能が、完全に特定のユーザ向けに
なる事が多い。

結果、システムが煩雑になりやすい。

２．システムに合わせて現場の運用を変えてもらう

だいたい嫌がられる。
調整に時間を要する事も多い。

政治的に優位な立ち位置でなければ、
この方法が実践できないケースも多々。

ただ、ビジネス的に大きな成功を
おさめるなら、こっちだと思います。

どちらが正解というものはありません。

経営者もしくは責任者が、自身の判断で
舵を切って行くしかないと思います。

現場は生き物で、状況も刻々と変わって行ってます。

限られたリソースの中で、何ができるか（何が提案
できるか）といったスキルは重要だと思います。

色々な技術が出てきているとはいえ、
レガシーな仕組みで泥臭くやっている
現場が多いのが実情です。

未来を見据えた、華やかで革新的な
テクノロジーが世の中を変えていく、
という考えも大事ですが、

今現在、泥臭く動いている現場や、
日々の業務に追われている方々に目を向けて、
そこから改善のアプローチをしていく。

という考えも重要なんじゃないかと思います。

おわり