投稿者: sasaki

前編では、BCGデジタルベンチャーズ(以下BCGDV)がグローバルの大企業と共に取り組んだ新規事業の話を伺いました。後編ではデータの活用方法を中心に伺いました。

モビリティデータの活用方法とは？

元垣内：「次にお伺いしたいテーマはデータの活用についてです。」

山家：「MaaSもそうですが、業界に限らずデータの活用は一般的になっていくと思います。一方で、新規事業を立ち上げる際は、利用者の課題を解決できるか、そもそもフィジビリティがあるのか、どのようにしてビジネスとして勝つのかなど、ポイントをいくつか挙げてそれに対するクライアントの強みを優先に考えなくてはなりません。

たとえば、クライアントが、大量のデータを収集、活用できる可能性があっても、その効率的な蓄積や分析は得意ではないかも知れない。そういった場合に、データ分析基盤のような仕組みを自前でゼロから用意することは、必ずしも競争優位にはつながらないことがあります。」

元垣内：「スマートドライブでも、地図データやドライブレコーダーの動画を集めながら分析をするために、さまざまな画像処理の技術を必要としています。ただし、すべて自社で賄おうとせず、一部で外部のサービスを利用することもあります。」

山家：「開発からリリースまでのスピード感を考えると、必ずしもデータ周りをスクラッチ開発で作ることがベストであるとは限りません。サービスの強みとなる部分は、じっくり時間と労力をかけて作りますが、それ以外の部分に関しては、外部と連携して開発スピードをあげたほうがいいと思っています。大量のデータを蓄積するだけでも、莫大なコストがかかりますし、大量のデータを分析するのも、かなりの手間とデータを扱える人材が必要です。すでにソリューションを持っている企業と手を組むなど、注力すべきところとそうでないところを切り分けて考えた方が、早くサービスをリリースできます。

たとえば、MaaS関連のサービスを開発する場合、サービス全体のデザインやユーザーインターフェイスをBCGDVが担当して、データ周りをスマートドライブが担当するとか。そうすることで上手く連携できそうですよね。」

元垣内：「それができると嬉しいですね！ 最近、各方面から『MaaS関連の新しいサービスを展開したい』と相談を受けることが増えてきました。MaaSはバズワードにもなっていますし、新規サービスに挑むのは非常に素晴らしいことだと思っています。しかし、実際にそのサービスがどんな価値になるのか、クライアント企業様にとってどのような課題が解決できるのかについては、私たちもまだ手探りで探している状態といいますか…。」

山家：「データを貯めれば何かに使えると思われがちですが、議論すべきは『このデータをどう活用すべきか』です。データを活用してどの課題を解決していくのかについては、私たちも常に頭を悩ませています。難易度の高いテーマですよね。」

元垣内：「本質的なところに時間を割かず、足回りだけに時間を使うのは、本当にもったいないことです。ですので、スマートドライブとしては、モビリティデータの価値をいち早く多くの方々が見つけられるような仕組みづくりをしていきたいと思っています。そして、その先にあるのが『データを活用してどのようなビジネスを作ることができるか』です。

BCGDVとしては、新規事業を成功に導くためのフレームワークを持っていたりするのでしょうか。」

山家：「前編で紹介した『FarePilot』の場合、本格的な開発に入る前に、データを集めてホットスポットを分析し、ビジネスとして成立するか否かを見分けました。開発前の段階で予測モデルをいくつか作って検証するということを何度も繰り返す感じです。フレームワークというよりは、迅速にPDCAを回すことを心がけています。インターネット企業がサービスを改善するのと同じように、ある程度行けそうだとわかったら、サービスの開発に着手しています。」

元垣内：「まずはプロトタイプを作って、試して、改善してという方法で回していくと。」

山家：「BCGDVだけで足りない場合は、BCG内の別の組織にデータサイエンティストのチームがあるのでフォローをしてもらいます。そうやって、自分たちがやるべきこと・できることに集中するのも大事なことです。」

元垣内：「近年、デジタルトランスフォーメーションを推進する流れが多くの企業で見られます。そういう側面からクライアントにご相談を受けることはございますか？」

山家：「デジタルトランスフォーメーションは、仕事の仕方や評価体系を変えるといった話から、デジタルツールを導入して情報を一気通貫させるところまで、各企業、いろんな側面から取り組んでいらっしゃいます。

BCGDVとしては、各社におけるデジタルトランスフォーメーション全体の取り組みの中で、その推進力向上に貢献できればと思っています。今まで経験した仕事の仕方や事業とは少し違うけれども、働き方を変えたり、積極的に新規事業を立ち上げたりすることで、先進的な企業へと変わっていきますよ、というように。」

元垣内：「つまり、先進的なパイロットプロジェクトというイメージでしょうか。実際に、そういった取り組みは事例としてありましたか。」

山家：「そういう位置づけでご相談される企業様は多いですね。全社的にデジタルトランスフォーメーションを掲げつつ、具体的な取り組みの中で、パイロット的なものとしてBCGDVのプロジェクトが位置づけられているケースが多いかもしれません。

BCGDVの働き方は、典型的な大企業とは異なりますので、まずはこの働き方を体験していただき、サービスが形になっていく過程や働き方を経験する中で新たな刺激を感じて欲しいですね。

デジタルトランスフォーメーションの全体像を作って推進していくのは、BCGが得意な分野だと思います」

新規事業が成功するパターンとは？

元垣内：「ご経験の中で、新規事業が成功するパターン、たとえば『こうするとうまくいく』というパターンはあったりするのでしょうか。」

山家：「今までの経験から言うと、実際にサービスを作って、ユーザーに利用してもらってから、ビジネスにするかしないかを判断する流れだとスムーズに進む印象です。逆に、非常に精緻な計画を立てようとすると、進行スピードが鈍化し、前進しづらくなります。とくにデジタルサービスは実際にユーザーに触ってもらわないと、うまくいく・いかないの判断が難しい事が多いです。ですので、大量に紙の事業計画を作るのではなく、素早くサービスを作って、修正点を改善するというアプローチ取るようにしています。」

元垣内：「その通りですね。私たちスマートドライブでもモビリティデータを活用したAI開発に着手していますが、AI解析やデータ解析は実際にやってみないとわからないこともたくさんあります。

ビッグデータを活用したサービスの開発を進めるには、しっかりと計画を練りこんだウォーターフォール型では間に合いません。2018年に経済産業省が策定した『AI・データの利用に関する契約ガイドライン』でも、スピード感を重視した探索的段階型の開発計画が提唱されていますし、ご一緒するクライアント企業様には段階的に、少しずつ形にしていくという提案をしています。」

山家：「サービスを検証するために必ずしもモノを作る必要はないんです。既存の何かをうまく活用してユーザーに触ってもらうだけでも、十分に感触が掴めたりしますので。お互いに合意してサクサクと進めることができれば、成功する可能性はぐんと上がるはずです。」

元垣内：「BCGDVの持つスピード感や具体的なアウトプットと、BCGのコンサルティングならではの強みの両方を持ち合わせているので、クライアント企業にとっても納得感が高いということでしょうか。」

山家：「BCGDVの進行に納得していただけるケースは多いですね。どのクライアントにも共通するのは、たくさんの資料よりプロトタイプを見たいと言うところです。私たちがいかにうまく短期間で持っていくかを常に考えて行動していることもあります。

基本的に、私たちが考えるプロジェクトはイノベーション、インキューベーション、コマーシャライゼーションという三段階で構成されています。それぞれ、イノベーションはアイデアを出して企画すること、インキューベーションは制作すること、コマーシャライゼーションはグロースさせることで、一気通貫で関わるようにしているのです。中には、企画だけ携わるプロジェクトもありますが、私たちとしては最初から最後まで責任を持って担いたいですね。もちろん、その体勢は整っていますし。」

元垣内：「すべてを一社でお任せできるところはそんなに多くありませんし、いま一番、求められていることだと思います。」

山家：「段階ごとに人や企業が変わると、関係性を0から構築しなくてはなりませんし、コミュニケーションが多く発生することになりますので、どこかで行き違いが発生してしまう。だから、なるべく同じ人が担当した方がスムーズなんです。」

元垣内：「責任も負いますので、本当に良いものを素早く作ることができますよね。」

元垣内：「最後に、スマートドライブへのご意見やご要望を頂戴できますか？」

山家：「BtoC向けのSmartDrive FamiliesもBtoB向けのSmartDrive Fleetも、非常に洗練されたユーザーエクスペリエンス（UX）が素晴らしいですよね。一般的なBtoB向けのサービスは、開発コストの低減や不具合を出さないことの優先度が高くなりすぎて、UXが劣ってしまうケースが少なくありません。だからこそ、より一層良さが際立っているんじゃないかと思っています。

その理由の一つには、BtoC向けのサービスを提供していることもあるんじゃないでしょうか。そこから得た気づきやポイントをBtoB向けのサービスにも反映させることもできますしね。今後も洗練されたUXを維持し続けてほしいです。

管理画面を最初に見たときに思ったのが、『すごくカッコいい』。シンプルで使いやすいのにデザインはスマート。そこにはスマートドライブの信念や強いこだわりを感じます。」

元垣内：「UXに関してはスマートドライブが全社的に注力をしているところです。そもそも、一人目の社員はアメリカ出身のデザイナーですし、最初からデザインとUXを中心にサービスを形にしてきたところが起点にもなっています。

そして、山家さんがおっしゃった通り、to C向けとto B向けのサービス両方を提供しているのは、それぞれで培ったUIやUXの使い心地を当てはめて、どちらにも良いサイクルを生み出していきたいという考えからです。

また、車両管理サービスは、パソコンに慣れてない方も使いますし、経営層や管理者、ドライバーなど、幅広いユーザーに合わせたデザインにしないと定着していきません。」

山家：「運行管理システムは使う人のリテラシーもかなり開きがあると思いますので、難易度が高いですよね。」

元垣内：「管理ツール自体がそもそも面倒くさいものだと思われがちなので、まずはその考えを拭い去るために、簡単に管理できるということをデザインや使いやすさで伝えていかなくてはなりません。そうして、利用する人たちが本来の仕事に集中できる環境を作りたいと考えています。

デジタルトランスフォーメーションの枠組みでのご活用始め、モビリティデータの活用価値の創出を後押ししていくためにも、私たちも提供するサービスや開発により一層、磨きをかけていきたいと思います。ありがとうございました！！」

元垣内：「まずは山家さんのご経歴とBCGデジタルベンチャーズ（以下BCGDV）についてご説明いただけますか。」

山家：「BCGDVで、東京センターのエンジニアチームを統括している山家 匠（やんべ・たくみ）です。BCGDVの東京拠点は2016年4月に立ち上がりましたが、私は同年に入社しましたので、初期の頃のメンバーでもあります。

現職につくまでの過去の経歴についても少し触れておきます。1社目は、証券会社のシステムをつくるシステムインテグレーターで、おもに基幹系システムの設計・開発やシステムアーキテクチャの設計をしていました。それから2008年後半、社員数がまだ80人程度だった上場前のGREEに転職。そこではSNSの基盤やプラットフォームに関する業務に従事していました。2011年にサンフランシスコに渡り、GREE Internationalの立ち上げに参画、帰国後はゲーム部門と基盤開発部を見てきました。

2014年にAppirioへ移り、Topcoderというソフトウェア開発のクラウドソーシングを行うビジネスを担当。その後、BCGDVへ転職、今に至ります。

BCGDVは、一言でいうと、新規事業を大企業と創造する組織です。ボストンコンサルティンググループ（以下BCG）という言葉上、どうしてもコンサルティングのイメージが強くなりますし、そこへさらにデジタルという言葉がつくので、BCGの戦略を実装する組織だと思われがちです。実際は、大企業と一緒に新規事業を立ち上げ、それを成長させるまでが私たちの仕事であり、BCGとは大きく異なります。

典型的なパターンの一つは、大企業と新規事業を一緒に立ち上げて、その新規事業を運営する会社も作ってしまうこと。運営会社を立ち上げたら、お金と人員をお互いに出し合い、独立した会社として運営していきます。」

元垣内：「ありがとうございます。これまでに大企業と組んで新しく立ち上げた事業はどのくらいあるのでしょうか。」

山家：「グローバルでの実績をお伝えしますね。ロサンゼルス、ニューヨーク、シアトル、ロンドン、ベルリン、シドニー、上海、東京、全拠点を合わせて今まで作ってきた新規事業は80後半ぐらいですね。」

元垣内：「ほとんどがグローバルリーディングカンパニーとのソリューション事業というイメージでしょうか。」

山家：「そうですね。BCGDVが得意とするところは新規事業の立ち上げですので、そこに大企業が持っているアセットを掛け合わせるイメージです。

アセットとひとくくりにしていますが、技術的なものだったり、ある国やあるエリアでビジネスを展開した経験だったり、企業によって本当に幅広いものです。それらを持ち寄っていただき、新規事業を作っていきます。ですので、スタートアップがゼロから事業を立ち上げるのとは少し基準が違うかもしれませんね。」

元垣内：「グローバルで、尚且つビジネス誌・FORTUNEに定常的に載るような大企業と新規事業の立ち上げができるのは、BCGならではですよね。」

山家：「たしかに、関係性も何もない状態からいきなり、『一緒にやりましょうよ』と声をかけるのは、なかなかハードルが高いことです。おっしゃる通り、BCGとしてのリレーションがあるからこそできる、というのはあるかもしれません。」

大企業ならではの新規事業を立ち上げる際の困難とは

元垣内：「大企業が新規事業を立ち上げる際に困難に思っていることはなんでしょうか。」

山家：「いくつかあると思いますが、一つは、デジタルの新規事業立ち上げの経験がなく、まずは何をどうすべきか、手順や手段がわからないことです。また、社内の制度や仕事の進め方が既存の事業向けになっているので、新規事業開発ではでミスマッチを起こしてしまうケースも考えられます。

実際に、BCGDVでプロジェクトを行うときには、今までの仕事の仕方や既存の考え方に縛られないように、ご担当者様に弊社のオフィスに来て常駐してもらうようにしているんです。それほど、既存の強い主力事業がある中で新規事業を起こすのは、非常に難しいということです。」

元垣内：「なるほど。大手企業には大手企業の、ベンチャーにはない課題があるのですね。」

山家：「立ち上げから運営までのスピード感は、スタートアップやベンチャー、そして大企業、それぞれで違いますが、新規事業の立ち上げはスピード感が大事です。

私たちならではの強みは、スタートアップやベンチャーを実際に経験してきた人、実際に自分で会社を運営していた人、大企業と一緒に仕事をしたことがある人が弊社内にバランスよく揃っていて、どちらのコンテクストも分かるところです。つまり、大企業のコンテクストを理解しつつも、スタートアップで成功するためにはこういう進め方で、こんなスピード感で進めていくべきだという、掛け合わせた時の全体感を把握できるメンバーがたくさんいる。それが一番の強みですね。」

元垣内：「今まで80以上のプロダクトやサービスを立ち上げられたという実績がそれを証明していますよね。グローバルでさまざまな成果やノウハウが蓄積されていると思いますが、グループ内で成果の共有はされているのでしょうか。」

山家：「守秘義務もありますので、個別プロジェクトの詳細については知ることができませんが、成功事例から得たフィードバックやそこで適用したメソドロジー（能力を伝授するために体系づけた方法論）を反映して、今後のプロジェクトの進め方を改善していくことはあります。」

元垣内：「それは、BCGならではのメソドロジーでしょうか。」

山家：「BCGDV独自のメソドロジーとして集積しています。BCGは戦略コンサルティングが専門ですのでカバーする範囲が非常に広いのですが、私たちは新規事業に特化しているので、視点や進め方が異なります。」

MaaSの取り組み事例

元垣内：「ここからは事例の中でもMaaSに関するものをいくつかお伺いできればと思います。」

山家：「事例を2つ、紹介させてください。まずは、Boschと組んだプロジェクトで、『COUP』という電動スクーターのシェアリングサービスです。ベルリンから始まり、今はパリとマドリードまで広がっています。BoschはB to B向けに自動車部品や電動工具を提供しているメーカーですが、カスタマーと直接コンタクトできるサービスを提供したい、そしてシェアリングという新しいビジネスにも参入したいという希望があり、このプロジェクトが始動しました。

Boschが持っていたアイデアをもとに、BCGDVが実際のビジネスコンセプトを作り、検証を重ねたうえでリリースしました。」

元垣内：「最近でこそ、MaaSやシェアリングという言葉が浸透してきましたが、『COUP』のローンチは3、4年前ほど前のことですよね。」

山家：「取り組み始めたのは2015年ごろで、サービスが始まったのは2016年8月からです。当時としては先進的なサービスという印象でしたね。」

山家：「スクーターの用意はBoschがパートナーシップを組んでいる台湾のGogoro（ゴゴロ）と進め、私たちはサービスのアプリや電動スクーターからデータを取得してサービスに反映させるところ（例：スクーターの現在地把握など）を開発しました。」

元垣内：「ゴゴロって、バッテリーも取り外せるバイクですよね。」

山家：「それが重要なポイントです。サービスとして長く続けていくためには、バッテリーの交換は避けられません。」

元垣内：「ユーザー側はバイクの現在地やバッテリー残量がわかることで、使いたい時に行きたいところまで行けるかどうかの情報が可視化される。オペレーション側もバイクの稼働状況などがわかることでサービス全体の効率化を考えることができる。どちらにとっても使い勝手が良く、利便性の高いサービスですね。」

山家：「もう一つが、Shellと組んで立ち上げた『FarePilot』というプロフェッショナルドライバー向けのサービスです。これはUberやLyft、一般のタクシードライバーにとってホットスポット、つまりお客さんが拾いやすいスポットが分かるアプリ。どのドライバーも、ただフラフラしているだけだとガソリンを消費するだけですので、無駄なくお客さんが近くにいるところへ行けた方が有利ですよね。このアプリは、時系列のデータとライブデータを分析して、ホットスポットをドライバーに教えたり、近くで行われているイベント終了時刻を知らせたりすることができるのです。モニターは非常にシンプルなデザインで直感的に使えるようにしました。」

元垣内：「このサービスに対するShellの狙いはなんだったのでしょうか。」

山家：「プロフェッショナルドライバーへの直接的なアクセスと、lower carbon technologyというコンテキストでサービスを展開することです。後者について簡単に説明すると、移動距離が少ないほうが二酸化炭素の排出量が減るという発想からです。」

元垣内：「なるほど。同じ距離を走るのであれば、お客さんを効率的に乗せて生産性を上げましょうということですね。こちらのサービスはローンチまでにどれほど時間がかかりましたか。」

山家：「私たちは基本的にサービスのローンチまでは、年単位でなく、3カ月〜6カ月ぐらいのスピード感でリリースすることを心がけています。一般的な業務系システムの開発だと1年や2年はかかるかもしれませんが、私たちの提供するサービスの場合、そんなに時間をかけるよりもユーザーに早くあてたほうが良いのです。」

元垣内：「スマートドライブのように完全なるスタートアップでさえも、3カ月や半年でリリースというのはかなり刺激的なスピード感です。」

山家：「ただ、この期間内でリリースするのは完全版ではなく、機能を絞った状態のもの。そこから徐々に改善を重ね、理想形に近づけていくようにしています。」

—

 

グローバルな大企業が取り組む新規事業の取り組みをしっかりとサポートするBCGDV、後編ではさらに踏み込んで「データの活用」にフォーカスして紹介していきます。

>>>>後編はこちらから

【会社概要】
会社名：有限会社One up（http://sts-taxi.net/）
事業内容：民間救急・介護タクシー事業,総合保険代理店の運営
従業員数：45名

「SmartDrive Fleet」の導入前に抱えていた課題

 

 まずは、「SmartDrive Fleet」を導入しようと思ったきっかけについて、お聞かせ願えますか。

有限会社One upでは、損害保険や生命保険などの保険業とともに民間救急・介護タクシーの運営も行っています。

保険の営業マンはほとんどがそうだと思いますが、営業先への移動は小回りがきく車を利用します。営業マン１人につき車両が１台という企業様も少なくないでしょう。最近は以前と比べて人手不足の影響で営業マンの人数が減ってしまったこともあり、普段から車両を使って営業マンがどのように営業活動をしているかを把握したうえで、車両管理を徹底し、業務の効率化が行えないかと考えていました。そこで車両管理が行えるツールを探すことにしたのです。

また、車両管理と営業マンの位置情報を把握しなくてはならない理由には、保険業法も関係していました。保険の契約を取る際には、契約者に対面で説明し、利用規約に同意していただくことが保険業法で定められていますが、これが遵守できなければ業務停止命令が出てしまいます。たとえお客様のご要望であっても、営業マンが契約書を代筆するのは絶対にあってはならないことです。そうした事業リスクを排除するために、契約を取った場所が契約者の家であるかが確実にわかるよう、GPSで証跡を残すことを目的に利用していたのがiPadでした。Apple IDを共通化すればリアルタイムの位置情報を確認できるので、営業マン一人ひとりにiPadを貸与し、そこから位置情報を確認していたのです。これは車両管理ツールにはなりませんので、あくまでも位置情報の取得という観点で利用していました。

そんな中、保険の営業マンが利用する車両に加え、介護タクシー事業の開業により利用する車両が一気に増加します。介護タクシー事業は、保険業の契約者に介護老人保険施設が多く、高齢者の送り迎えや交通手段に困っている利用者が多いと知って、少しでもスムーズな移動を手助けできるようにと始めたものです。初めは3台だったものが、徐々に需要が膨らみ、現在ではおよそ20台が稼働するようになりました。保険の営業マンと同じように、ドライバー全員にiPadを貸与しようかと思いましたが、落として壊してしまったり、紛失してしまったり、さまざまなリスクがあるので難しいと判断。iPadを１台購入するにも、それなりに金額がかかりますしね。

10年ほど前からiPadのGPS情報を活用して、リアルタイムで車両位置情報を管理していましたが、本当はiPadを使わず別の手段によって、安く・簡単に管理する方法を探していたのです。たしかに便利ではありますが、iPadもiPhoneも設定に手間がかかりますし、設定ができる人に頼らなくてはなりません。しかし、「SmartDrive Fleet」はシガーソケットに挿すだけで簡単に利用を開始できるので、初めて話を伺った時に「これだ！」と。

なるほど、まずは保険業の方で車両管理をしっかりと行う意義を見出されたわけですね。では、なぜ介護タクシー事業でも車両管理を行おうと思われたのでしょうか？

介護タクシーは、保険で利用する車両とは異なる課題を持っていました。それは、ドライバーの労働時間管理です。労働基準法の改正によって、始業から終業までの拘束時間と労働時間、休息時間を管理者が把握し、定められた時間を越えないように管理者側が責任をもって調整を行う必要がありました。所定の拘束時間を越えれば翌日の労働時間を調整しなくてはなりませんし、給与計算も変わってきます。今までは自己申告制でしたが、万が一、基準を越えてしまうと労働基準法違反になりますし、ドライバーも過労で体調を崩すかもしれない。そこで労基法を遵守するために管理が徹底できるツールはないかと。

今後、業務拡大に向けてスタッフや車両を増やしていくとなると、自己申告では正確な労働時間と休憩時間が把握できませんし、適切な管理も行えません。そして何よりも記録がないと何かあった時に会社としての責任を問われてしまいます。また、介護タクシーを運営する中で、給与体系を運賃の50%をドライバーに還元する歩合制へと変更しましたので、実働時間に対する給与支払いを行うために実働時間と休憩時間を正確に計上する必要がありました。これらの理由を含め、労働状況を把握し、労務管理をしっかりと行ったうえで給与支払いを適正に行うにはどうすればいいのかという課題にぶつかっていました。

確実に記録を残すことができるうえ、誰もが簡単に設置と管理ができるという点で、「SmartDrive Fleet」を試してみたいと思ったのです。さらに調べていくと、配車効率の向上にもつながることがわかり、今後の期待も込めて導入を決めました。

『SmartDrive Fleet』とともに、他社のツールも比較検討されていたのでしょうか。

インターネットで何社か確認しましたが、操作画面を見て直感的に使いやすいなと思ったのが「SmartDrive Fleet」でした。また、今までGoogle Mapを活用して車両管理や営業、ドライバーへの指示を出していましたので、Google Mapをベースにリアルタイムでの車両管理ができるというもの大きなポイントでしたね。

導入する直前までは連絡手段としてLINEを活用されていたそうですね。たとえば、お客様からここに来て欲しいと依頼があった場合、どのようなオペレーションで連携を取っていたのでしょうか？

ドライバーにLINEで現在地を送ってもらい、その位置情報を元にお客様から一番近いドライバーをアサインするという方法で指示していました。お客様には、ドライバーの現在地からお迎えにあがるまでのルートと場所、そしてGoogle Mapの所要時間を目安にしつつ、少し余裕を持たせた時間をお伝えしていました。バスやトラックのルート配送と違って常に目的地と住所が異なりますし、ドライバーにLINEで位置情報を送ってもらっても、その後実は移動していたというケースも多々あり、結局また電話で最新の位置情報を確認する等して意外と手間がかかっていたんです。

今、どの車両がどこにいるのか。そうした情報を確実に把握してスムーズオペレーションを行いたい。そうした思いから、LINEはあくまでも一時的な連絡ツールとして利用していただけで、車両管理システムは必要だと前から検討していました。

「SmartDrive Fleet」の導入を決めた理由

 

「SmartDrive Fleet」を導入する決め手となったのはどの機能でしょうか？

導入以前は、連絡をスムーズにするために、ドライバー全員に社用携帯電話を所持させていました。しかし、経営・管理側と現場側との間で、なかなか埋めることのできないギャップがあったのです。

管理側からすれば、業務時間中に電話がかかってきたら、素早く停車してなるべく早く電話に出てもらいたい。しかし、それを伝えると、ドライバーからは「休憩時間も拘束されないといけないのか」と反発が出てしまうのです。先述したように、拘束時間の中には労働時間と休憩時間が含まれますが、業務上、稼働時間に多少の前後が出てしまうので休憩時間はドライバーによってバラバラです。こちらもそこまでは把握しきれません。

そこで改善策として、会社の携帯電話ではなく、ドライバー個人の携帯電話を使うことになりました。最近のスマホならば、電話でコミュニケーションを取る必要はあまりなく、LINEのやりとりだけで完結させることができるからです。ただ、プライベートの携帯電話なので、お客様への電話連絡を強制できない。そうなると、その部分のオペレーションは管理者側で対応せざるを得ません。結果、電話でのオペレーションは管理者側が、ドライバーにはLINEで業務連絡を送り、随時対応してもらうというフローで一旦は着地しました。

しかし、このままでは非効率です。そこで、本腰を入れてさまざまな車両管理システムを調べることにしました。デバイスと携帯電話を連携させるシステムを提供している会社はいくつかありましたが、利用しているのがドライバーの個人携帯なので、つながっている間の通信料はドライバーにかかってしまうため、このタイプは導入が難しい。ところが、「SmartDrive Fleet」は通信機能内蔵型ですので、個人の携帯電話と連携させなくても利用することができますよね。さらには、シガーソケットに挿すだけでデータが取得できるといったシンプルさが決め手になりました。

毎回業務の前に細かい設定が必要になると、ドライバーの負担が増えるだけです。年配のドライバーやITリテラシーが低い人も少なくありませんので、そういった容易性は私たちにとって非常に重要なポイントだったのです。使い方が難しいと社内への問合せも増えますし、運用する上でのサポートコストもかかってしまう。それを最小限にできるというのも決め手になりましたね。

 

「SmartDrive Fleet」の導入後に得られた効果

 

「SmartDrive Fleet」を導入してから、どのような効果や変化がありましたか？

もっとも大きな効果は、走行履歴や安全運転診断を活用して指導を行うことができるので、ドライバーの意識が変わったことです。

走行履歴には、ドライバー一人ひとりの特徴や性格が明確に出ます。たとえば、午前10時に5km先にいるお客様をお迎えに行く場合、ドライバーが出発時間と経路を考えなくてはなりませんが、通常、5kmなら20分ほどで到着と分かっていても、1時間前に車庫を出る人と20分前に車庫を出る人ではその後の対応が大きく変わります。1時間前に出る人は、しっかりと段取りを組んで向かうため、予期せぬことが起きても慌てることなく冷静に対処できます。一方、20分前に出る人は道路が渋滞していたり、事故があったりすると、約束の時間に遅れてしまいますし、その後の業務も後手後手の対応になってしまいます。走行履歴からはそうした情報を読み解くことができるので、後者のタイプのドライバーにはもう少し早く出るようにアドバイスをして、トラブルを回避するようにしています。

1時間前に出る人は同じようなトラブルに直面しても事前に調べた経路の複案を持っているので問題なく対処ができるのです。時間に余裕があると、何かあった場合でも、次の業務に支障がでないように早急に本部へ連絡を入れて会社の影響が少なくなるような配慮ができますし、余裕を持った行動ができるので、お客さんの希望も柔軟に聞き入れることができるんです。たとえば、普段は自宅から病院までの送迎でも、希望を聞いて途中にある薬局へ寄ってあげることもできる。このように、走行データから一人ひとりが成果を出せるよう、個別のアドバイスと適切な教育が行えるようになりました。

そういう良い循環ができれば会社としても信頼と売り上げが向上しますし、お客さまのリピートにもつながります。

 

2つめは安全運転への意識です。余裕のないドライバーは、少しでも時間に遅れるとすぐにスピードを上げて間に合わせようとします。スピードの出し過ぎや、急操作が3回以上あった場合は運転診断アラートメールを飛ばすよう設定し、ドライバーが事務所へ戻ってきた時や翌日など、タイムリーに指導をして安全運転を徹底しました。それを続けてきた結果、効果が出てきたのです。

安全運転診断の結果は集計後、週次で全ドライバーが目を向けやすい場所に貼り出していますが、可視化された自分の運転をしっかりと見て振り返ることができるので、急操作が激減し、急加速についてはほとんどなくなりました。以前は匿名の電話で「運転が心配だ」というご意見を頂くこともありましたが、現在ではそうした電話がありません。私たちのお客さまは個人だけではなく、半分が病院です。ご依頼をいただくのは総合病院が多いので、信用関係がなければ依頼にも繋がりません。安全運転は会社の信用に直接つながる重要な要素ですし、会社の経営にも直結しますので、安全運転への意識が改善できたことは全社的にも大きなインパクトでした。

 

振り返りでは、具体的にどのようなことをされているのでしょうか。

「SmartDrive Fleet」の走行履歴で毎日、欠かさず安全運転の振り返りを行っています。最初の頃は、なぜ急ブレーキや急発進、急ハンドルが発生したのか分かりませんでしたが、ドライバーに問いかけることで管理側も原因と要因をはっきり認識できるようになりました。

ドライバー自身も自ら「なぜ急操作が発生したのか」を考えるようになっています。あの時間、あのルートで急ブレーキを踏んだ。そこで、なぜ、急ブレーキを踏まなければならなかったのか。すると、「あの曲がり角近辺で、車が急に飛び出してきたからだ。あそこは少し見通しが悪いから危険だな」だと思い出す。そうすれば、次に同じルートを利用するときに、注意を払うようになりますよね。継続して振り返りを行っていると、危険な運転が発生したら、その理由を事前に覚えておこうという意識を持つようになるのです。

 

「SmartDrive Fleet」は安全運転の度合いが点数化されますので、次のアクション（改善策）に結びけることができるんです。

ある日、点数が低いドライバーに、「なぜ、いつもと違うルートを通ったの？」と問いかけると、「急いでいたので裏道を使いました」という回答されたことがあるんですね。さらに、急いでいた理由を問うと、「xx様のお迎えで少し時間がかかってしまい、結果として次の訪問先に遅れました」と。ここからさらに質問をして問題の核に迫っていきます。「どのような理由で、xxさんは遅れてしまったの？」と聞くと、ベッドから起き上がれなくなったためだとわかりました。

管理者側には患者様の情報までは伝わりません。しかしこのように、ドライバーとコミュニケーションをとって原因が明らかになれば、ケアマネージャーにxxさんの情報を共有し、利用者の容体に合わせたサービスを提供できるようになります。そうなると、ケアマネージャーからも、介護者の容体確認や情報共有までしてくれる介護タクシー会社として、信用・信頼が生まれていくということです。

なるほど、今までは運転の振り返りはしても、根本原因までは分からなかった。それが、今は走行履歴や安全運転診断のデータを活用し、「なぜ急ブレーキがあったのか」「なぜ急いだのか」「なぜxxさんのところで遅れたのか」と深掘りしていくことで、利用者様の状態が詳細にわかるようになったと。それが会社の信頼を底上げすることにつながっているのですね。

基本的にケアマネージャーがケアプランを作りますが、介護タクシーは法律上、ケアプラン以外のサービスを提供できません。もし、ケアプラン以外のサービスを提供してしまうと、介護保険をもらえなくなってしまいます。ただ、そこで何もしないという訳でなく、気づいた点をもとにケアマネージャーにプランの変更を提案することで、お客様へのサービスを最適化するようにしています。1番大事なことは、みんなで振り返りをすることで、お客様の体調がしっかりと把握できるように意識づけすることです。

「SmartDrive Fleet」の導入で、今までと振り返り方は変わりましたか？

そうですね。今までは時間に遅れた、クレームが来たなど、何か問題が発生したら振り返りをしていましたが、今は振り返りが習慣化しましたので、問題を未然に防げるようになりました。

私は配車を組んできた経験が長いので、「あの通りは普段なら30分で行けるけど、この時間帯は混雑するから40分はかかる」といったデータが頭の中で蓄積されていますが、過去の走行履歴のデータを見ることで、所用時間の平均がわかることに気づきました。そこから今は自分の持つ経験値と実際のデータを照らし合わせて、配車を組むロジックを磨きあげています。今後は私だけなく、「SmartDrive Fleet」のデータを見て、誰もが道路の混み具合や特性を加味したルートでの配車を組めるようになってほしいと思っています。

ご存知かとは思いますが、タクシーは距離と時間によって金額が変わるものです。最短距離で行けば安くなりますが、渋滞に巻き込まれてしまうと前に進まないのに金額だけが高くなってしまいます。理想は混雑しない最短ルートで到着すること。そこで、「SmartDrive Fleet」のデータはお客様にとって最適なルートをドライバーに教えるためにも一役買っています。

ドライバー個人の走行データから、毎日向かっている目的地にどのルートを利用しているのかを把握できれば、管理者は無駄のない正しいルートを教えることができます。安全運転しながらも次の仕事に間に合わせるには、5分〜10分程度、時間に余裕をもたせなくてはなりません。余裕を持つことができれば次の仕事に、そしてドライバー自身の給与アップにもつながります。

道路はその時々の状況によって常に変化します。なので、同じルートでも明日は状況が変わっているかもしれない。そのことが伝わるようにアドバイスするには、各ドライバーがいつもどの道を走行するかを理解しつつ、運転の癖を見抜いて指導することが重要です。走行履歴はそうした癖を見抜くためにも、非常に役立っています。

ここ5年〜10年以内にドライバーになった若手はカーナビ世代ですが、何十年も運転しているベテランドライバーは地図世代が多く、頭の中に地図がある程度入っているので、同じ目的地へ向かうにも迂回ルートをいくつか理解しています。だからこそ、若手の教育に「SmartDrive Fleet」やそこから取得したデータが活用できるのです。ナビ世代の若手ドライバーは新しいテクノロジーやツールに対して抵抗がないので、安全運転教育ではデータを活用した方が吸収が早い。地図と自分の走った実際のルート見比べながら、レクチャーできるのはとても良いですよね。

「SmartDrive Fleet」の活用で目指していきたいこと

 

「SmartDrive Fleet」に搭載されているスマートフォンアプリのリアルタイム機能もご活用いただいているそうですね。

はい、リアルタイム機能によって予想外の効果が出ています。先述したように社用携帯から個人携帯へと運用が変わったので、業務連絡はすべて事務所を経由していました。案件によっては、同じ場所へ2名のドライバーを向かわせるケースもありますが、待ち合わせの際にそれぞれが今・どこにいるかという情報を管理者が個別に連絡しなくてはならなかったのです。それが今では、ドライバーのスマホから他のドライバーの現在位置が確認できるようになったため、わざわざ管理者に確認の電話をする手間がなくなりました。

また、全ドライバーの現在地が可視化されるようになると、他のドライバーと同じ場所にいてはアサインされる可能性が低くなるということがわかりますので、各ドライバーがどこにいれば自分に仕事がアサインされる可能性が高いかを意識しながら自発的に動くようになりました。

SmartDrive Fleetを活用して今後目指していきたいこと

現在は、民間患者搬送用の車両12台で『SmartDrive Fleet』を導入しています。民間患者搬送とは、病院に行く際に救急車を呼ぶほどではないけれど自身では運転して行けない場合に利用される移動手段のことです。とはいえ緊急性が高いことも多く、今から何分後に到着できるのか、正確な情報を伝えることが何よりも重要となります。他の車両よりも、リアルタイム機能の必要性が高かったため、まずはこの車両に導入しましたが、今後は他の車両にも導入して実働時間や休憩時間を把握し、労務管理をしっかり行っていきたいと思っています。

スマートドライブに今後期待することや希望することはございますか。

手書きの日報を1年内には廃止したいと思っていますので、乗務記録（休憩や実車走行等のステータスをスマートフォンアプリで登録して記録に残せる機能）で記録を残せるよう、現在、テスト運用を行っています。そこへさらに、お客さまごとの利用運賃が記入でき、簡単に計算できるようになるとより便利になるのではと思っています。今は「メモ」欄に運賃を記入していますが、集計はできませんので…。ですので、今ドライバーが日報をもとに自分で集計しているものを自動化することができれば、さらなる効率化につながるのではないかと考えています。

また、車両の停止時間から走行開始するまでの時間を「休憩時間」と自動で判定できれば、労務管理も効率化できるのではと思っています。車両を停止してから15分経過したら休憩を開始したと判断するとか。ただし、利用者都合での待機時間は労働時間に含まれますので、この区分けをできるようにしなければなりません。

ドライバーに負荷がかからないように、労務管理を行えるようになること。これが今、私たちが目指すところです。

前編・中編では、モノフルの武田様にインタビューをいたしました。トラック簿の機能でSmartDrive PlatformのAPIを利用しているとのことでしたので、今度はSmartDriveの担当者に詳細を伺ってきました。

まず自己紹介をお願いします。

風間 進一（かざま しんいち）です。株式会社スマートドライブでSmartDrive Platformの開発ディレクターをしています。エンジニアではないので直接プログラムを書いたりはしておらず、プロジェクトの進行管理や調整を社内外の様々な関係者と共にやっています。

前職はトランスコスモスという会社に４年ほど所属しておりまして、ECのアウトソーシングをやっている事業部にて今と同じようにシステム開発の調整や進行管理をしておりました。さらにその前の職場は６年半ほどミクシィにいまして、mixi Platformの立ち上げから外部公開のところまを経験させていただきました。

 

ミクシィ時代にもプラットフォームに関わっていたのですね。SmartDrive Platfromというのはどういうものなのでしょうか？

SmartDrive Platformは３つの要素に分解できます。まずは「Data In」という、IoTデバイスから上がってくるローデータを取り込む部分があります。２つめは「Add Value」という言い方をしているのですが、貯めたデータをクレンジングしたり、加工して解析をかけることで、もともとローデータだったものをハイコンテクストなデータに置き換えることをやっています。３つめは「Data Out」でして、蓄積されたローデータやハイコンテクストなデータを様々なサービスに供給するという３つの要素を持っています。

SmartDrive Platformの特徴はどういったところでしょうか？

移動体にフォーカスをしているところが特徴です。今は車がメインになっていますが車に限ったものではなく移動するもの全てがPlatformの対象になります。他にもバイクや、コンテナ、動物など様々な移動体で利用いただけるように最初から設計されているので、多種多様なニーズに対応できるようになっています。

 

トラック簿では、どういったAPIが使われてているのですか？

まず弊社のSmartDrive APIは※RESTful APIで構築されておりまして、弊社のデバイスを車両に搭載することで、その車両がどこにいる、どこにいた、というロケーション情報をDevice last locationというAPIを介して提供しています。また、事前に登録しておいたトラックバース（倉庫の荷下ろしする場所）に「入ったのか？」「出たのか？」といった情報をWebhookで通知しています。トラック簿の場合は、Webhookを受け取るサーバーを用意していただいたので、そこのエンドポイントに対して通知を飛ばしています。

※ RESTful API
Webシステムを外部から利用するためのプログラムの呼び出し規約(API)の種類の一つで、RESTと呼ばれる設計原則に従って策定されたもの。

 

APIリクエストを投げると、どのようなレスポンスが返ってくるのですか？

デバイスコードという、車両に搭載されているデバイス１台毎に割り当てられているIDがありまして、そのデバイスコードを指定してリクエストを投げることで、現在の位置情報を取得できます。過去の履歴情報を取得したいときは、開始と終了をタイムスタンプで指定してあげることで、その期間の情報をリストで取得します。弊社のデバイスは１秒間隔で緯度経度のデータを取ってますので、１秒毎のデータを取得できます。ただ、一気に取得してしまいますと負荷が掛かってしまうので、最大で100件ごとのデータをページングしながら取得できます。

ちなみにWebhookは、データの登録系はPOSTで、データの取得はGETですね。いわゆるRESTful APIの標準的な仕様に則っていますので、どちらもございます。

 

SmartDrvie APIは自社サービスでも使われていると伺いました。

そうです、もともとは自社サービスで使っていたAPIを拡張して、外部に対しても提供を開始しました。現在でもこれらのAPIはSmartDriveの各サービスでも使われています。

そういえば、「SmartDrive Families」という高齢者ドライバーの見守りサービスは、SmartDrive APIを活用した社内ハッカソンを行いまして一気に作り上げたもの。1週間ほどでコア機能を作り上げ、デザイン作成やAppStore申請などの作業を含め３ヶ月ほどで製品ローンチができました。

 

このSmartDrive APIは既にサービスメニューとして展開しているのでしょうか？

すでにお客様には提供できる状態ですが、まずは個別に連絡をいただければトライアルで試していただく形になります。今後、広く沢山のお客様に使っていただきたいと思っていまして、トライアルの申し込みページや、APIの仕様にを分かりやすくまとめたドキュメントを整備中でして、価格についてもまだ調整中の段階です。

そして、私たちが提供しているAPIが全て十分な状態かというと、まだまだ足りないと思っています。「どのようなAPIが必要なのか？」「どうすれば使いやすくなるか？」など、一緒にトライアルをしていただけるユーザー様の声を聴きながらSmartDrive APIをブラッシュアップしていきたいと思います。

 

すでにSmartDrive APIを使いたいという声はありますか？

そうですね、そういった声はどんどん増えています。例えば法人向けの車両管理サービスを利用している企業様がデータをCSVではなくAPIで直接取得し、自社のシステムに取り込みたい。APIを使ってBIツールに直接繋いでデータをビジュアライズしたい。このようご要望を沢山いただいております。とはいえ、APIというのは情報提供の１つの手段でしかないので、お客様が情報を取り出しやすいよう、APIだけでなく様々な形で提供していきたいとも思います。

 

トラック簿のように、SmartDrive APIを自社サービスの機能の一部として使うということも可能ですよね？

もちろんです。SmartDrive PlatformはIoTデータのプラッフォームに位置付けられますので、すでにIoTデバイスからデータを取得して、加工・クレンジング・解析することで情報精度を高くした状態で提供できます。そういった部分を自社でゼロから開発することなく、弊社のAPIを使っていただければデータの提供は可能でありますので、短期間でサービスの立ち上げができると思います。実際にトラック簿は３、４ヶ月でデータのつなぎ込みからサービスローンチまで持って行けたました。

 

自分だったらこんなサービス連携できたらいいなというのはありますか？

勤怠システムとの連携ができるといいなと思います。例えば、ドライバーさんが車両の走行を開始したら、自動で勤怠システム側のステータスが出勤になったり、どこでどう走ってきたという情報を勤怠のエビデンスにしたりできたらいいなと。あとは、人事系のシステムで安全運転スコアをドライバーさんの評価に組み込んだりするのも面白いかもしれません。

SmartDrive APIはRESTful APIのお作法に則っていて使いやすいので、私が想像もしてない使い方をしていただけるユーザー様が出てきてくれたら嬉しいです。

 

それは確かに面白いですね！今後のSmartDrive Platformの展開について教えてさい。

先ほどお伝えした３つの要素でいうとまずは、「Data In」の部分。ここはよりつなぎやすくしていきたいです。具体的には様々な移動体のデータをアップロードできるようになっているので、多様なセンサーデータを取り込んでいけるようにしたいと思っています。次に「 Add Value」ですが、ここはまさに付加価値を生み出すポイントですので時系列データやストリミーング処理をキーワードに柔軟かつ効率的にデータを捌いていきたいと思います。最後に「Data Out」ですが、よりデータを取り出しやすくするために、APIを種類を増やしていくこともそうですし、JSONだけでなく他のフォーマットでもデータを出力できるようにして、お客様のシステムとの連携をしやすいものにしていきたいと考えています。

 

最後に一言お願いします。

APIを使ったデータ提供している企業はたくさんありますが、IoTデータとくに移動体のデータに特化したデータの提供してい企業は少ないと思いますし、今後広がりを見せていくと思います。なのでチャレンジしていく余地は多分にあります。今後のSmartDrive Platformの展開にご期待ください。

トラック簿には3つのプランがありますが、中には月額基本料が0円のフリープランもあります。

まずは、今まで手作業で行われていた受付をアナログからデジタルへシフトしてもらわなくてはなりません。しかし、現場の方はデジタルに慣れていない方が多くいらっしゃる。そこで、お客様にデジタルやデータに馴染んでいただくためにも、「まずは使ってみようかな」というお客様に向けたフリープランを用意しました。

前編でもこの画像をお見せしましたが、倉庫側と運送側の接点になっているのが、バース管理の部分です。だからこそ、この部分の円滑化をはかるために、接点であるバースにおいて、どの運送会社が来ているか、作業時間がどれくらいかという情報を理解すべきだと考えています。それができれば、バースの回転率が向上すると次は荷揃えスピードの改善したり、将来的には「帰りの荷物はありますか？」という提案もしたりと、大きな視野で物流の効率化ができるようになるからです。

 

物流の現場を理解されているからこそ、正しい機能や提案ができるのですね。

私たちは、必ずお客様の現場を見せていただくようにしています。ドライバーが来てからどのような動線を辿って受付に着き、どこで待ち、呼び出しの手段は何か。誰がどう判断して、バースの呼び込みをしているか。全体の流れを書き留めるためにオリジナルのカルテを作成し、一つひとつ項目を埋めていくと、「トラック簿をこのように活用すると、ここのポイントが改善できます」と適切な提案ができるようになるんです。

単純に導入しましょう！予約しましょう！ではなく、お客様のオペレーションの中で、「ここは、この機能を使って効率化していきましょう」というアプローチを取って信頼関係を築くようにしています。今後、配車業務やマッチングといった、様々なサービスに繋げていくきっかけとしてトラック簿を提供していますので、同じバース予約サービスでも他の企業とは違う見せ方や提案ができているのではないでしょうか。

 

提案というのは、コンサルティングサービスではなく、新しいソフトウェアで解決していくための提案ということでしょうか。

現時点ではとくに線引きをしていませんが、一拠点ではなくて、工場から倉庫、配送先まで、トレーサビリティを高めていく中で、トラック簿の活用で何が実現できるかをご提案したり、機能を追加したりするなどして、総合的にフォローしていければと思っています。

 

提案段階でお客様の現場を見せていただくというのも、コンサルティング領域に近いですよね。

おっしゃる通りです。的確な解決策を提案するには、まずは現場を知り、具体的な悩みを理解することが重要です。今後、倉庫内の自動化や人材サービスなど、さまざまな軸で、ソリューションを作ろうと動いているのも、バースだけ円滑になっても倉庫内がスムーズに回らなければ意味がないと考えているからです。

 

GLPという盤石があるからこそ、ベンチャーのような動きもできるし、事業開発も行えるし、思いきりアクセルを踏むことができると。

GLPの本業として土地を仕込み、開発し、これだけの多くの物件を提供してきたこともあり、土台がしっかりとしているため、次の種として新たなサービスを植えることができたのだと思います。また、非常にありがたいことに、お客様もトラック簿から次のいろんなサービスへの展開を期待してくださっています。その辺りも、物流施設の最先端を知るGLPが基盤の会社であることが大きいのではないでしょうか。

トラック簿を皮切りに、モノフルとして今後どのようなサービスを展開していくのでしょうか。

モノフルは現在、3つの戦略を軸に動いています。一つがトラック簿のようなプロダクトの開発、二つ目はスタートアップ企業への出資。三つ目が業務提携をするパートナー。この三つをうまく掛け合わせながら、「バース管理・配車計画・求貨求車マッチング・運行計画・動態管理」の輸配送プラットフォームをスピード感をもって強大にしていく。そのようにして、輸配送の領域を攻めたいと考えています。

中でも配車に関するソリューションは一番注力しているところ。世間では配車と求貨求車のマッチングは似たものだと思われているようですが、まったく異なるものです。配車計画はそもそも、この荷物をどのように運べばいいのかを考えなくてはならない、少し上流の概念。ですので、順番としては①この荷物をここに運ぶために②トラックをマッチングさせて向かわせる、となります。

 

つまり、配車計画が作成されたうえで、トラックの不足分を求荷求車マッチングで補うということですね。

そうです。配車と求荷求車を混同せずに、まずはこの流れを作らなくてはなりませんので、配車業務に注力してプロダクトの開発を進めようとしています。理想としては、私たちが提供するサービスを活用するお客様からデータをいただいたり、さまざまなデータを繋いだりすることで、より良いサービスへと進化させていくことです。

 

配車計画と少し似ていますが、介護の現場でも送迎計画の作成が大きな負担になっています。単純にルート作成をすれば良いというものではなく、「●●さんのおばあちゃんは車椅子を利用している」とか「▲▲さんはお子さんが乗降をお手伝いしてくれる」とか、さまざまな条件や状況を加味したうえで、送迎計画を作成しなくてはならないからです。そのため、経験者に頼ることが多いですし、時間もかかってしまう。ただでさえ人手不足が叫ばれている今、時間がかかるアナログな作業はどんどんデジタルで変えていくべきではないでしょうか。

ツールを導入したと言っても、デバイスを装着されている台数が一部であったり、動態管理ツールを利用していても活用しきれていなかったり…。そうした点も変えていかなくてはなりません。何を運んでいるのか、どのように運んでいるか、輸送モードによって改善点も異なりますので、スマートドライブと連携して誰がどこにいるか、リアルタイムの情報を取得・蓄積していきたいですね。

たとえば、東京－大阪間の長距離車が運行中だとしましょう。運転時間や走行距離は長くなればなるほど疲労は蓄積しますし、運転も乱れてくるので、全体的に事故の確率が上がると予想できます。しかし、管理者も荷受け主も、今ドライバーがどのあたりを走行しているのか知らないことがほとんどです。無事に拠点を通過しているのか、何らかの原因で遅延しているのか、効率も大事ですが、万が一を想定していつでもリアルタイムの情報を知っておくべきじゃないかなと。それが動態管理の本来の活用の仕方でもありますし。

たとえば、バース管理の仕組みを使って、ある拠点への到着時に「Aに到着しました」とフラグが立つようにすれば、ドライバーも報告しなくて良いし、管理者も安心できますよね。店舗配送のトラックは多くの拠点を回ることが多く、店舗側からすると「品出しがあるので何時には来てほしい」という強いニーズがある。少しの遅延が業務に響く細かな配送では、誰がどこにいるかという情報が非常に重要。ですので、各々の輸送モードに対して、どういうトレースをしていくべきかを考え、最適な機能や利用方法を考えるべきです。

 

おっしゃる通りですね。ちなみに、トラック簿の中でSmartDriveの機能が使われているとか。

はい、トラック簿にスマートドライブが提供しているデバイスから走行データを取得・活用できるSmartDrive Platform APIを活用させていただきました。トラック簿で利用できるのは次の2つの機能です。

まずは、車両が登録した地点に出入りした際に通知がとぶ、自動受付機能。通常、ドライバーは倉庫に到着すると、駐車場にトラックをつけて降車し、事務所に行って名前と携帯番号を書いて再びトラックに戻りますが、これが巨大な物流施設だと往復だけで10分以上もかかってしまうんです。ドライバーの負荷を軽減させることに加え、庫内を円滑に回すにはどのトラックが到着したのかという情報が大事ですので、ジオフェンスを張って半径100m以内に入ったらステータスを「受付完了」に変更できるようにしました。

もう1つは自動遅延通知です。バースの予約時間が14時なのに13時の時点でまだ50kmも離れた地点にいる場合、予約時間に間に合わないと予測できますよね。今まで、遅延の連絡はドライバー本人がセンターや自分が所属する運送会社に電話で連絡をしていましたが、いちいちトラックを止めて連絡しなくてはならないので結構な手間です。自動的に倉庫へ遅延の通知ができれば、先に到着したトラックを先に呼び出すことができますし、待機問題が解決できる。この二つの機能は、運送会社がもつ動態情報と、倉庫が持つバース情報をかけ合わせたものであり、まさしくモノフルが目指す企業の枠を超えた情報の共有化です。

 

スマートドライブとは今後どのように連携を深めていきたいとお考えでしょうか。

物流業界の課題を解決するためには、物流を深く理解する必要があり、非常に時間がかかるため、スマートドライブが物流業界に歩み寄るのが必ずしも正解とは思ってはいません。モノフルが間に立つことによって、ニーズを汲み取ったり、足りない部分を補填したり、うまく橋渡ししができればと考えています。

スマートドライブは自社が持っている強みを深堀りしつつ、テレマティクスの領域で存分に強みを発揮してもらいたい。スマートドライブとしてどの領域に特化すべきか、競合他社と比べたときに足りない部分を自社で開発するのか、それとも他社の力を借りるのか、もっともっと思いっ切ってアクセルを踏み込んで行って欲しいですね。

 

モノフルは業界の特性をすべて捉えたうえでプロダクトも開発できる、物流業界にとっては非常に頼もしい存在です。悩みを持ち込めば、何か良いソリューションを開発して提供してくれるんじゃないか、そういう期待の声が聞こえてきます。

各企業でも、それぞれ課題解決や業務効率の向上に向けて自社開発が進められています。その中で、企業が実現したいことに対して、実行スピードを上げるための支援を私たちができればと思っていて。

トラック簿のようなサービスを一企業が0から開発を始める場合、数千万円の投資だけでなく、利用が開始できるまで早くても一年程度の期間を要します。トラック簿のような汎用性の高い機能に関しては、SaaS型のサービスを組み合わせて利用し、その浮いたリソースを庫内作業や輸配送といったコア業務にさいてもらえるとありがたいです。

この機能欲しいな、と思ったときに気軽に相談でき、手軽に好きなサービスを組み合わせてご利用いただける御用聞きのような存在。痒いところに手が届く、誰にとっても使いやすい、それがモノフルの目指す理想像です。

 

既存のアセットを最大限に活用しつつ、スピード感と柔軟性のある事業で物流業界の最適化を推し進めるモノフル。今後も新たなサービス展開に目が離せません。

 

後編へ続く>>

物流倉庫（トラックバース）の混雑が社会問題となっています。今回はトラックバースの状況をデータ化し、作業の効率をあげ、トラックの待ち時間も削減できるサービスを提供するモノフル社にインタビューしてきました。また、トラック簿の一部サービスで利用されているSmartDrive APIとは何か？こちらについても伺いました。前編・中編・後編でお届けします。

はじめに、モノフルと武田さまについてご紹介いただけますか。

現在、株式会社モノフルでセールス&マーケティング シニアマネージャーをしています、武田優人（たけだ・ゆうと）です。モノフルは、世界的物流施設大手のGLPの日本法人である日本GLPが、2017年に設立した物流のデジタルトランスフォーメーションに特化した会社です。

私自身は2015年4月、日本GLPに入社し、はじめはプロパティーマネジメント部に所属して物件の施設や運営管理を行っていました。具体的な業務はテナントや物流会社の入退去対応、工事の調整、トラブル対応、アメニティ管理などです。そして2017年の4月1日、不動産というハードサービスだけでなく、物流に関するソフト面のサービスも提供することを目的に、GLP内で新規事業を立ち上げる事業企画部が発足しそこへ参画。呼び出しを待つトラックの長蛇の列や、荷主毎に異なる多種の伝票、数時間にわたる手積みの状況など、私が運営管理をしている際にも現場の苦労を感じていましたが、それをGLPという土台を生かしつつ、スピード感を持って高精度なサービスを提供したい−−そうした思いから、物流に関するさまざまな課題を包括的に捉え、解決へと導くサービスの提供に特化した、モノフルという子会社を立ち上げました。

GLPとしては、今後も物流と不動産の開発を行っていきますが、ハード面だけで解決できないソフト面についてはモノフルがサービスを開発し、両面で最適化を図ります。

 

2019年4月、モノフルの新たなサービスとしてトラック簿の提供が開始されましたが、開発へのきっかけについてお伺いできますか。

モノフルが輸配送の領域で目指しているのは、次の5つの情報を組み合わせて物流を最適化することです。

1. バース管理
2. 配車計画
3. 求貨求車マッチング
4. 運行計画
5. 動態管理

上記5つの機能や情報が連携し、なおかつ活用できてこそ、輸配送の最適化が実現するんです。

現状把握と車両の状態や輸配送に関する課題を洗い出すために、パートナー企業のスマートドライブと何度も話を重ねて気づいたのが、会社ごとに配車計画や動態管理を取り入れていても、「情報の共有化」ができていないために、業務改善が進んでいないということでした。開発に莫大な予算をかけて作り込まれた配車システムも、運送会社に情報を伝える手段がFAXだったり、電話だったり、最終的には人の手を介している。さらには返信もFAXで送られてくるため、やり取りで発生する紙を人の手で管理しなくてはなりませんし、情報が一部の人にしか伝わっていないなんてことも。

動態管理もまったく同じ状況でした。運送会社の多くはデジタルタコグラフ（以下、デジタコ）から取得したデータによってドライバーが「今、どこにいるか」を把握できますが、倉庫側はリアルタイムの情報が見えないため、ドライバーが遅れているのか、順調なのかがまったくわからない。さらには、配送の完了報告も、ドライバーが電話で伝えていることが多いというのです。せっかくお金をかけて便利なツールを取り入れているというのに、自社だけに情報が閉ざされてしまうと「活用できている」とは言い難いですよね。

そこでまず、「各社それぞれ異なるツールを利用していても、情報を共有化できるようにするにはどうすべきか」という点に目を向けました。−― 倉庫とトラックの状況を誰がどの環境でも見える状態にできないだろうか…。昨今、社会問題として度々取り上げられているドライバー不足をカバーし、業務の効率化や生産性の向上を図るには何から解決すべきか。

人口減少やドライバーの高齢化、若手人材の不足など、ドライバーの人手不足には多くの原因が積み重なっていますが、「2027年にはドライバーが24万人不足する」というレポートも上がっていて、物流、とくに配送に関する課題解決は急務です。今すぐ人材確保ができないなら、不足分をどのように補っていくかを考えていかなくてはなりません。そこで、人手不足の本質的な理由を探るために実際の現場に足を運びました。そこで見た光景は、私たちの想像をはるかに超えるものだったのです。

労働生産性＝ドライバー数 ×労働時間 × 稼働率

国土交通省の統計資料をみると、実際にドライバーの労働時間のなかで運転しているのは約半分ということがわかります。荷役と呼ばれているトラックから荷卸し、荷積み、棚入れや、順番待ちによる長時間の待機時間が発生し、実際に運転している時間＝生産性が落ちてしまっている。荷物の積卸しをするために施設内でトラックを接車するスペースをバースと呼びますが、特定の時間に荷物の積み卸しが集中すると、ドライバーには長い待機時間が発生します。2017年から荷待ち時間の記録が義務化されましたし、この問題への深刻さについてはある程度ご想像いただけるかもしれません。

さらに、フォークマンは基本的にフォークリフトに乗って荷積みや荷卸しがメイン業務であるのに関わらず、トラックを呼び出すために構内を探し回ったり、事務員の方々もトラックの呼び出しのための電話や、「あと何分かかるのか」といった問い合わせ対応に追われていたりとバース周りの対応に多くの時間を割いていました。

ドライバーの待機時間や、倉庫側の呼出しや問い合わせ対応によって本来やるべき業務に集中できずにいるため、全体の流れや仕組みを変えていくところから着手していかなくてはならないなと気づきました。誰もが自分の業務に集中してもらうために、システム化できるところは、システム化していこう。それがトラック簿の開発へ繋がっていったのです。

物流施設という現場を所有しているので、目先の課題をすぐに拾い上げることができるのがGLPの強みですよね。

直接的に物流の業務を行っているわけではありませんが、先進的な物流施設だけでなく築年数が経過した古い物件も含めを保有していますので、サービスの開発にあたって、実際の現場を見せていただいたり、現場の方からどんな課題感を持っているのか伺ったりすることができます。それはGLPならではの強みでもありますし、サービス開発に生きる部分でもあります。リアルな現場や声を見て、聞いて開発ができるということは、お客様にとって本当の使いやすさ・欲しい機能を適切に提供できることにもなりますしね。

 

エンジニアの方も、実際の現場を見て気づいたことや意見をサービスの開発に活かしていると伺いました。

そうですね、なるべく開発を担当しているエンジニアにも現場に来てもらっています。そこで実際にどんな人がどのように活用しているのかを見てもらうんです。トラック簿のタブレット端末を入力するスピード感や目線をエンジニアが自分の目で観察することで、年齢層が高い方が多いからローマ字入力では打ちづらいだろう、10桁の数字にはハイフンを入れた方がわかりやすいだろうなど、細かな改修点を見つけることができるからです。それは非常に有意義なことですし、サービスの開発に重要な視点であると思っています。

 

なるほど。ここまでは開発のきっかけやどのように開発されているかについて教えていただきました。ここからは改めて、トラック簿のサービス内容について教えていただけますか。

まず、一つめとしてはバースの予約機能でトラックの到着時間を分散させたり、長時間の待機時間を削減したりできること。また、バースの状況を可視化できるので、紙やFAX、電話による非効率な作業も限りなく0にできます。そして、トラック簿の中でもっとも重要なのがデータの蓄積と分析ができる機能です。紙で保管をしていると、過去のものはそのままバインダーの中で放置されっぱなしになりやすいんです。経験則で何曜日・何時に混雑するのか、感覚値では理解しているかもしれませんが、データ化していないと新しい人が入った時に対応できませんし、いつまでも問題を改善することができません。全体の傾向がある程度わかれば、効率化のために何をすべきか、どうすべきかを考えることができますし、待機時間料が一斉請求された場合、どれほどのリスクがあるのかを想定できるようになります。だからこそ、データを取ることが重要ですし、データを活用していただきたいのです。

バースの大混雑時には、8時間も待つトラックが発生するそうです。そうすると次に何が起きるか。時間が無駄になるし、仕事も進まないのでドライバーからは「あそこの現場はお金をもらっても行きたくない」と言われるようになってしまう。つまり、効率の悪さから業務に支障が出て、最終的には企業の業績に響いてしまう、悪循環ができるのです。さらに、順番がズレたり、トラックが来る順番が分からなかったりすると、荷揃えや荷積みの準備ができず、倉庫内の作業効率が鈍化します。過去のデータがないと、スタッフとフォークマンの人員が適切かどうかもわかりませんし、最適化もできません。

国土交通省が推進している物流効率化法でも、トラックの予約受付システムの導入が勧められています。そのため、最近ではバースの予約システムがメインのサービスが数多く提供されるようになりましたが、トラック簿に関して言うと、バースの予約はあくまでも問題を解決する手段の一つだと思っています。本当に効率化を目指すなら、本来、トラックドライバーの拘束時間の内訳を把握することから始めるべきなんです。拘束時間と内訳がわかれば、手がかりが見つかります。バースの予約で解決できるかもしれないし、受け入れ時間自体を変更すべきかもしれない。なので、まずは倉庫に到着後、待機時間を経て荷物を積んで出ていくまでのデータを指標として取得し、現状を知る。そこからです。

私たちはオーバーフロー型と言っていますが、朝8時から一日中混雑している倉庫もあります。この場合、バース予約ではなく、バース数を増やすか、作業時間を削減するためにパレット化を推進するか、問題解決の手段は別軸になってきます。ただし、混雑が朝だけ、夕方だけの場合、バース予約により分散化すれば解決できます。必ずしもバースの予約が解決するのではなく、幅広い視点で問題を受け止め、解決の手段を考えていくべきなのです。

私たちはGLPが所有する物件で実際の課題を肌で理解していますし、これまでに多くの現場に訪問してきたため、さまざまなケースやノウハウが蓄積されています。ですので、より現場の視点で必要な機能を提供できる自信があります。

 

中編へ続く>>