コラム・物流百景
トラックドライバーの個人所有スマホに業務用アプリケーションを導入？
ソリューションベンダー側の課題と責任を考える
公開日：2025年1月23日

昨今、社員が持ち歩くスマートフォンでの利用を前提とした業務用アプリケーションがどんどん増えています。

代表的なアプリケーションを挙げましょう。

• メール・チャットツール
  GmailやSlack、LINE WORKSなど
• Officeツール
  モバイル版のExcelやGoogle Wokspaceなど
• 出退勤管理ツール

その他にも、スケジュール管理とメールなどを統合したグループウェア各社は、皆モバイル版アプリケーションを提供しています。
そして、この潮流は、トラックドライバーにも押し寄せています。

• 運行管理（TMS）系ツール
  動態管理、配車計画、配送管理、カーナビゲーションなど
• 伝票管理系ツール
  伝票受発行および受領サイン確認、EDIなど
• トラック予約管理・入退場受付
• 点呼・アルコールチェッカー

その他にも、ドライブレコーダーの代わりにスマートフォンのカメラ機能を使うアプリケーションや、スマートフォンの加速度センサーを利用して運転状況を記録するアプリケーション、あるいは体活動計などと連動し、ドライバーの健康状態をモニタリングするアプリケーションなどもあります。

ここで課題になってくるのが、これら業務用アプリケーションを、誰のスマートフォンにインストールさせるかという点です。

結論から言えば、会社から業務用スマートフォンを支給し、業務用アプリケーションを利用させるのが筋ではあります。しかし、特に中小企業では、懐事情などから、従業員の個人所有スマートフォンに業務用アプリケーションをインストールさせ、利用させてしまうケースもあるでしょう。

本稿前半では、トラックドライバーの事情にフォーカスし、業務用アプリケーションのあり方と、後半ではソリューションベンダーがアプリケーション開発を行う際に注意すべきことを考えていきましょう。

個人所有のスマホで業務用アプリケーションを利用させることがNGな理由

会社が従業員に対し、業務利用のための携帯電話・スマートフォンを支給せず、個人所有のスマートフォンなどを業務利用させることのリスクをまとめました。

ただし、従業員に対し、携帯電話・スマートフォンを貸与することで生じる、会社側のリスクもあります。

• 従業員が、業務用スマートフォンを私用で使ってしまうというリスク。
• 私用で使った通信費やアプリケーション内課金が会社に請求されてしまうというリスク。
• スマートフォンを紛失、あるいは盗難されるリスク。

こういった会社側が被るリスクを回避するため、MDM（Mobile Device Management）やMAM（Mobile Application Management）といったツールをあらかじめスマートフォンにインストールすることで、会社側は、「従業員がどのようにスマートフォンを利用しているのか？」、あるいは「業務用スマートフォンを、私用で利用していないか？」といったことを監視し、また不必要なアプリケーションの利用を制御・管理する必要があります。

実は筆者、あるクライアントから依頼を受け、従業員（トラックドライバー）が利用する業務用スマートフォンのMDM運用を受託しています。その経験から言うと、MDM・MAMといったツールの管理と運用には、それなりに手間が掛かりますが、「仕事用のスマホで、そんな使い方するの!?」という従業員が実際に見つかったこともあります。したがって、やはりMDM・MAMといった管理ツールを用意することは、もはや業務用スマートフォンを従業員に貸与するうえでは必須であると考えています。

トラックドライバーが、業務用アプリケーションの利用を嫌がる理由

とは言え、トラックドライバーに対し、業務用アプリケーションの利用を指示すると、さまざまな理由により、嫌がられることがあります。

ドライバーの中には、ITリテラシーが低く、スマートフォンの利用についても不慣れな人がいます。
そのため、いずれのケースにおいても、業務用アプリケーションの利用目的を懇切丁寧に説明し、かつ利用開始レクチャーや、利用開始後のサポートについても手厚く行う必要があります。

一方で、厄介なのは、トラック予約受付システムのような、発荷主・着荷主といったクライアントから要請されて使用する業務用アプリケーションです。こういったアプリケーションに対するサポートは、クライアント側が行うのが筋なのですが、中には「この間も同じこと、説明しましたよね！」というふうに、つっけんどんな対応をするクライアントがいることも事実です。

クライアントから使用要請を受けたアプリケーションについても、運送会社側がその使い方をよく学んで、クライアントに代わってフォローを行うことも、場合によっては必要になるでしょう。

ソリューションベンダー側、つまりアプリケーションにおける仕様上の課題

とは言え、「文字が小さすぎて読めない」といったユーザビリティ上の課題は、業務用アプリケーションを開発するソリューションベンダーの責任であり論外です。

しかし、デザインを優先するなど「制作者のエゴイズム」をゴリ押しし、例えば「ボタンを画像で作ってしまう」「画面を拡大縮小するピンチ操作を無効にする」といったアプリケーションを開発してしまうベンダー、実際にいるんですよね...

これ以外にも、ソリューションベンダーに責任がある、不適切なアプリケーション開発・仕様の例を挙げましょう。

• 直感的に操作可能なアプリケーション設計を考慮していないケース。
  例えば、初見の人でも利用できるような適正なガイダンスを設けていなかったり、「アプリケーションで処理されるプロセス」を、事前にきちんと理解・把握していないと使えない（迷子になってしまう）ような仕様になっているケースが該当します。
• アプリケーションで処理される業務プロセスが、標準規格に準拠していないケース。
  「該当する業務における標準的なプロセス」ではなく、「一般的ではないプロセス」を採用し、利用者（ドライバー）を惑わせてしまうアプリケーションも存在します。
  このような設計ミスを避けるためには、該当する業務を広く学ぶことも必要ですが、まずは物流情報標準ガイドラインを紐解くことが大切です。
  物流情報標準ガイドラインでは、物流業務における主要なプロセスが標準化されています。まずは物流情報標準ガイドラインを参照し、該当する業務プロセスが掲載されている場合には、そのとおりに設計を行うべきです。
• データフィールド設計が、物流情報標準ガイドラインに準拠していないケース。
  同様に、物流情報標準ガイドラインでは、主要なデータフィールドについて、項目名や書式、文字数などの仕様が定められています。
  例えば、ガイドライン中に、「伝票番号」は存在しますが、「帳票番号」は存在しません。さらに言えば、「伝票番号」が納品書に記載されると、「指定納品書番号」と呼称が変わります。しっかりと、物流情報標準ガイドラインを読み解き、準拠することが必要です。

特に中小運送会社においては、（アプリケーション仕様ではなく）サービス設計が、業務用スマートフォンの支給を躊躇（ちゅうちょ）させてしまうケースもあります。例えば、料金体系の設計です。

• ソリューションそのものの月額基本料金は0円
• アプリケーションを利用するアカウント数（＝スマホの台数）に対し、1ユーザーあたり月額1万円の利用料金が発生

このようなアプリケーションだと、中小運送会社の経営者の中には、「ユーザー単位の利用料金がこんなに高額なのか...。そうなると、スマートフォンの月額基本料や通信費などを会社が負担するのは難しいよな」と考え、ドライバー個人所有のスマホで業務用アプリケーションを使用させようと考える人も出てくるでしょうね。

これは筆者の私見でもあり、願望でもありますが、特に中小運送会社が顧客となるケースが多い、トラック運送業向けのアプリケーションにおいては、「中小企業でも導入しやすい料金体系」を目指してほしいものです。

ベンダーの方々と話していると、「基本料金を高くして、アカウント単位課金額を減額すると、かえって導入への敷居が高くなってしまうんですよ」と懸念する方がいるのですが、だったら、基本料金にもアカウント数に応じたラダーを設ければ良いだけです。

どのみち、ユーザー数が多くなる大手事業者に対しては、大口割引を設けることが一般的なので、大口顧客に対しては基本料金を高くする代わりに、アカウント単位課金額を安くする料金設計を行うことで、この懸念には対処できるはずです。

ただし、それでもドライバー個人所有のスマートフォンへのアプリケーション導入を促したいソリューションベンダーがいるのであれば、せめてブラウザアプリケーションを用意するべきです。インストール型アプリケーションに比べれば、ブラウザアプリケーションの方がドライバーへの負担は小さいですし、もしガラケーを利用しているドライバーがいたとしても、対応できる可能性が高まりますから。

業務用アプリケーションの着地点

先日、ある大手物流システム開発会社を取材する機会に恵まれました。
このとき、こんな発言がありました。

「今どき、すべての機能を自社開発しようという発想が時代遅れなんですよ。むしろ、自社で開発するよりも、より優れた機能・性能を提供しているソリューションがあるのであれば、協業し、システム連携を図ったほうがソリューションの価値も上がるはずです」

「素晴らしいですね」と称賛した筆者に、この担当者はこのように言葉を続けました。

「ソリューションベンダーは、ユーザー価値の向上に努力すべきです。ベンダー側のエゴイズムをユーザーに強いることは論外で、その意味では『自社開発にこだわりたい』というのも、ベンダー側のエゴイズムなんですよ」

ただし、そのためには、他社のシステムと連携できる仕様となっていることが必須となります。当然、物流情報標準ガイドラインに準拠することが前提となります。

ドライバー向けアプリケーションに限らず、あらゆるアプリケーションやソリューションは、手段であって目的ではありません。
したがって、ソリューションやアプリケーションの最適化は、導入企業にとっては部分最適でしかないのですが、この理解が不足していているソリューションベンダーは少なくありません。

例えば、トラック予約受付システムは、WMS、WES、WCS、受発注管理システムなどとの連携がなければ、本来目指すべき物流センター業務の全体最適は実現できないはずです。
ソリューションベンダーは、自社ソリューションだけの最適化を目指すような狭い視野ではなく、関連する業務プロセス全体を意識し、全体最適化に貢献できるようなソリューション開発、あるいはビジネス設計を行うべきでしょう。

本来、ソリューション（solution）とは、解決や解答を意味する言葉です。
本稿のように、今やシステムやアプリケーションと同義として使われることが多いソリューションという言葉ですが、ユーザーが抱える、あるいは業界が抱える課題解決に貢献するという本来の目的を、ベンダー側は見失わないようにしたいものです。