ホワイトボードからダッシュボードへ ― 車両積載計画とGPS車両追跡をひとつにつなぐ

課題:積載判断が今もホワイトボードで行われている

プレキャストパネルやパネル部材、大型部材を扱う製造業の多くの工場ヤードに足を運ぶと、決まって同じ光景に出会います。ディスパッチャーがマーカーを手に、どの注文をどのトラックに載せるかを頭の中で組み立てている光景です。これは普段はうまく機能します ― 納期がずれたり、トラックがダブルブッキングされたり、「14番現場向けの積み荷はどこですか」と聞かれて「おそらく高速道路のどこかです」としか答えられなくなるまでは。

もどかしいのは、この問題を避けるためのデータはすでに社内に存在しているという点です。施工チームはどのパネルが、どこに、いつ必要かを把握しています。工場は何が生産済みで出荷可能かを把握しています。そして多くの車両には、保険や燃費管理の目的ですでにGPS端末が搭載されています。実際に不足しているのはデータそのものではなく、「納期と現場」→「どのトラックに何を積むか」→「そのトラックが実際どこにいるか」を、分断された3つの記録ではなく、ひとつの連続した記録としてつなぐ仕組みです。

この隙間を埋めるために設計するのが、リアルタイムGPS車両追跡と連携する車両積載計画モジュールです。

なぜ一般的な配車計画より難しいのか

市販のフリート管理・配車計画ソフトの多くは、均一で箱詰めしやすい貨物を前提にしています。しかしプレキャストパネルや中空床版など、長く扱いにくい部材を出荷する製造業は、一般的なツールがうまく想定していない制約に直面します。それは積載可能量を決めるのが重量ではなく、荷台の長さであることが多いという点です。トラックは重量にまだ余裕があっても、置き場所がなくパネルをこれ以上積めないということが起こります。この種の製品に対応する積載計画ロジックは、重量と長さの両方を扱う必要があり、どちらか一方だけでは不十分です。

一般的なツールがもうひとつ見落としがちな制約は、現場には常にシステムが把握できない例外が存在するということです。すでに別の現場に割り当て済みのトラック、時間帯指定のある納品先。人が持つ現場知識で上書きできない積載計画ツールは、結局ディスパッチャーに避けて通られるようになります。

私たちの設計アプローチ

このモジュールは、データ入力を二重にする別ツールとしてではなく、既存のProduction Execution & Traceability System(simpliMES / ERPNext基盤上に構築)の拡張として設計します。全体のフローは次の通りです。

flowchart TD
    A["配送オーダーキュー"] --> B["ディスパッチャー計画ボード"]
    B --> C["積載案の自動提案"]
    C --> D["ディスパッチャーによる調整"]
    D --> E["積載計画の確定"]
    E --> F["配送トリップ作成"]
    F --> G["リアルタイムGPS追跡"]
    G --> H["ダッシュボードとETA"]

配送オーダーキュー ― 必要な納期、現場、製品/パネルコードを施工チームのスケジュールから直接取得します。すでに存在するデータを二重入力する必要はありません。

ディスパッチャー計画ボード ― 車両×日単位のカレンダービューで、一週間分の空き状況を一覧できます。担当者の頭の中だけにある状態から解放されます。

積載案の自動提案 ― 重量と荷台の長さの両方をもとに、トラックごとの積載案をシステムが提案します。長く扱いにくい貨物では、長さが実質的な制約になることがほとんどです。

手動での調整 ― システムが把握できない例外(すでに別の現場に割り当て済みのトラック、時間帯指定のある納品先など)に対応するため、ディスパッチャーは注文をトラックや日付間でドラッグ&ドロップで調整できます。システムは提案するだけで、判断するのは人です。

積載計画の確定 ― 確定と同時に配送記録が作成され、特定の製品コードと直接ひも付き、そのままリアルタイム追跡へと連携します。後から突き合わせが必要な別のスプレッドシートを作る必要はありません。

GPS追跡がどこで連携するか

追跡側は、フリートが既に保有しているGPS機器をそのまま活用できるように意図的に設計しています。目標は既存の車両追跡インフラの上に乗るソフトウェアであって、新たなハードウェア導入ではありません。積載計画が確定し配送トリップが作成されると、そのトリップは自動的に追跡されます。

• ジオフェンスによる自動ステータス更新 ― 配送記録は、車両が設定した境界を通過するたびにDispatched → In Transit → Arrivedと自動的に更新されます。ドライバーやディスパッチャーが電話でステータスを報告する必要はありません。
• 施工チーム向けETAの可視化 ― 現場チームがトラックを待って手待ちになったり、逆に予定より早く到着して慌てたりすることを防ぎます。
• 配送ごとの完全なトリップ履歴 ― 同じ積載計画と製品コードにひも付いており、「この部材はいつ、どこに届いたか」という問いに、実際に追跡可能な形で答えられます。

積載計画とGPS追跡は、設計上同じ配送記録に書き込みます。積載計画を行う仕組みと、トラックを追跡する仕組みを別々に構築すると、形を変えた突き合わせ問題を再び生み出すだけになります。

位置情報とコンプライアンスについて

このモジュールは車両およびドライバーの位置情報を取得・処理するため、日本国内で展開する場合は個人情報保護法(APPI)の観点から、利用目的の明確化(業務上の配送管理であり、従業員評価目的ではないこと)、保存期間の適切な設定、位置情報へのアクセス権限の限定といった設計上の配慮が必要になります。また、確定した積載計画・配送記録・トリップ履歴が製品コード単位で追跡可能な形で残ることは、J-SOX(内部統制報告制度)が求める業務プロセスの証跡としても活用しやすく、監査対応の負荷を下げる副次的な効果があります。サプライチェーン全体の可視化・トレーサビリティ強化は、経済安全保障の観点からも国内外で重視が進んでいる領域であり、こうした基盤づくりは単なる業務効率化にとどまらない位置づけになりつつあります。

このモジュールが置き換えるもの、置き換えないもの

範囲を明確にしておくと、このモジュールが置き換えるのは「ホワイトボードでの場当たり的な積載判断」と「電話による手動のステータス報告」です。構造化され、製品コードごとに追跡可能な計画に置き換わります。一方で、ディスパッチャーをプロセスから排除するものではありません ― 自動提案はあくまで人が確認・修正する出発点であり、自律的に配車を決定するシステムではありません。また、フリートが既に利用しているGPSプラットフォームが有効なAPIまたはWebhookを提供していることが前提となり、この点は開発前の検証事項であって、前提として決め打ちするものではありません。

よくある質問

新しいGPS機器の導入は必要ですか?
不要です。フリートが既に導入しているGPS機器と連携できるように設計されています。ただし、そのプラットフォームが位置情報とジオフェンスイベントを取得できるAPIまたはWebhookを提供していることが条件です。

トラックの割り当てを決めるのはシステムですか、ディスパッチャーですか?
システムは重量と荷台の長さをもとに割り当て案を提案します。ディスパッチャーはいつでも内容を確認し、トラックや日付間で注文をドラッグ&ドロップして調整できます。最終的な積載判断はディスパッチャーに残ります。

スタンドアロンでの導入は可能ですか、それともMESのフル導入が前提ですか?
どちらの形でも導入できるように設計しています。既存のERPNext/simpliMES基盤の上に追加するスタンドアロン型、または Production Execution & Traceability のフル構築に組み込む形のいずれも可能です。スタンドアロン導入の範囲とスケジュールは、フリートのGPSプラットフォームが検証済みの連携アクセスを提供できるかどうかに左右されます。

トリップ履歴は個々の製品コードにひも付いていますか?
はい、これがトレーサビリティの核心です。各配送トリップは、積載計画とその際に実際に積載した製品/パネルコードにひも付いており、単なる「どのトラックがどのルートを走ったか」という一般的なログではありません。

全体像における位置づけ

このモジュールは、私たちの Production Execution & Traceability の取り組み全体を支える同じ考え方の延長線上にあります ― 生産されたすべての製品は、工場の出荷口までではなく、納品先まで一貫して追跡可能であるべきだという考え方です。もし貴社のチームが今もホワイトボードでトラックの積載を計画し、配送状況を電話で追いかけているなら、次に埋めるべき隙間はここにあります。

貴社のフリートと生産体制への適用についてのご相談は、hello@simplico.net までお気軽にお問い合わせください。