「事故が起きてからでは遅い」――Uber Eatsはなぜ走行中の配達員に次々とリクエストを送るのか?

Uber Eatsの原付配達員が走行中に次々と届く配達リクエストと短い受付時間に直面する様子を描いた、交通安全問題を訴えるアニメ風イラスト。 デリバリー副業

まだ配達は終わっていない。

バイクで道路を走り、注文者のもとへ向かっている。

そんなとき、スマートフォンに次の配達リクエストが届く。

一件だけではない。次々と届くこともある。

配達員としては、次の仕事が入ること自体はありがたい。待機時間が短くなれば、それだけ効率よく稼働できるからだ。

しかし、問題はタイミングである。

「今、運転中なんだけど。これをいつ確認しろというのか?」

Uber Eatsは、配達員に安全運転を求めている。

それなら、走行中に届く新しいリクエストは、安全に判断できる仕組みになっているのだろうか。

今回は、現役の原付配達員として経験している問題を、Uberの公式説明と道路交通法から考えたい。

配達が終わる前から次の仕事が届く

Uber Eatsで配達をしていると、現在の注文を届け終わる前に、新たな配達リクエストが表示されることがある。

これには、配達と配達の間に生じる待機時間を短くするという利点がある。

仕事を途切れさせずに進められることは、配達員にとってもメリットだ。

だが、原付バイクの配達員は、スマートフォンの前に座って仕事をしているわけではない。

道路を走っている。

前方の車、歩行者、自転車、交差点、信号、道路標識などを確認しながら運転している。

そこへ突然、次の配達依頼が届く。

画面には報酬、距離、予定時間、店舗や配達先の情報が表示される。

これらを見て引き受けるか判断するには、情報を読む必要がある。

運転中の配達員にとって、これは単なる通知ではない。判断を求める通知なのだ。

Uber公式ヘルプには「通常15秒以内」と書かれている

Uberの公式ヘルプ「配達リクエストの受け付け」には、リクエストを受信した場合、通常15秒以内に受付操作を行うと説明されている。

別の公式ヘルプでは、ほとんどの場合、他の配達パートナーへ転送するまで15〜30秒待機すると記載されている。

この秒数は、配達員にとって非常に重要だ。

例えば、幹線道路を走行中だったとしよう。

すぐに安全な場所へ停車できるとは限らない。

交差点の手前かもしれない。

後続車が続いているかもしれない。

停車できない区間を走っているかもしれない。

ようやく安全な場所へ停車したころには、リクエストの受付時間が終わっている可能性もある。

15秒という時間は、スマートフォンを操作するには十分でも、安全に停車するには十分とは限らない。

ここでUber Eatsに聞きたい。

この制限時間は、走行中の配達員が安全に停車するまでの時間を考慮して設定されているのだろうか。

警察庁は「安全な場所に停車してから使用」と呼びかけている

警察庁は、運転中のスマートフォン使用について、重大な交通事故につながる危険な行為だと注意を呼びかけている。

道路交通法では、原付バイクを含む車両の運転中、一定の携帯電話使用や画面の注視が禁止されている。

スマートフォンをホルダーに固定していれば、何をしてもよいわけではない。

警察庁は、運転中にスマートフォンを使用する必要がある場合、必ず安全な場所に停車してから使用するよう求めている。

当然のことだ。

配達員は、報酬が表示されたからといって、走行中に画面を読み込んではいけない。

だが、ここで問題になるのが、リクエストの受付時間である。

安全な場所へ停車してから確認する。

その間に受付時間が終わる。

それでは、配達員は仕事の機会を失うことになる。

法律を守って安全に判断した配達員が、不利になる仕組みであってはならない。

安全運転と売上を天秤にかけさせていないか

配達員にとって、新しいリクエストは次の売上につながる機会だ。

報酬がよい案件なら、なおさら受けたいと思うだろう。

しかし、走行中に届いた依頼をその場で確認するのは危険である。

だから安全な場所に停車する。

ところが、停車している間にリクエストが消えてしまうかもしれない。

こうした状況が繰り返されれば、配達員が「少しだけ画面を見よう」と考えてしまう危険性はないだろうか。

もちろん、走行中に画面を注視することを正当化するつもりはない。

運転者には交通ルールを守る責任がある。

しかし、運営側にも、危険な操作を誘発しにくいシステムを設計する責任があるはずだ。

安全運転を呼びかけるだけでなく、安全運転をしても不利益を感じさせない設計が必要なのではないか。

無応答は応答率にどう影響するのか

この問題には、もう一つ気になる点がある。

応答率である。

Uber Eatsの配達員アプリには、直近の配達リクエストについて、受け付けた件数や拒否した件数、応答率が表示される。

では、走行中に届いた通常の限定配達リクエストを、安全のために操作せず見送った場合、どのように集計されるのだろうか。

Uberには、複数の配達員に案件を提示する「配達依頼レーダー」という仕組みもある。

レーダーの見送りと、通常の限定配達リクエストの見送りは、応答率上の扱いが同じとは限らない。

配達員に必要なのは、こうした違いについての明確な説明だ。

安全のために確認できなかった依頼まで、単純に「拒否」として扱われるのであれば、問題はさらに大きくなる。

Uberには、走行中の無応答がどのように記録されるのか、具体的に説明してほしい。

Uber Eats自身も安全を最優先と説明している

Uber Eatsの公式サイトには、安全に関する案内ページがある。

そこでは、安全に配達して収入を得られるようサポートすることを最優先事項としている。

安全ツールや位置情報共有機能なども紹介されている。

こうした取り組みは重要だ。

しかし、事故やトラブルが起きた後に役立つ機能だけでなく、事故につながる危険な状況を生み出さない設計も重要ではないだろうか。

例えば、走行中の配達員に対して、判断を必要とする通知をどのように表示するか。

安全な場所に停車するまで、受付時間を確保できるか。

走行中に応答できなかったことが、配達員の不利益にならないか。

これらも、立派な安全対策のはずだ。

Uberは走行速度を把握しているのではないか

Uberの配達アプリは、配達員の位置情報を利用している。

また、Uberの配車レーダーに関する公式ヘルプには、車両の走行速度によって表示内容を制限する仕組みが説明されている。

ただし、この説明は主に乗客を運ぶ配車サービスの機能についてのものであり、日本のUber Eatsの通常配達リクエストにも同じ制御が適用されていると確認できたわけではない。

それでも、技術的な疑問は残る。

アプリが走行状態を判定できるのであれば、走行中の配達員に対するリクエスト表示を、もっと安全に設計できないのだろうか。

例えば、走行中は詳細確認を求めず、安全に停車してから判断できる仕組み。

あるいは、停車までの時間を考慮した受付方法。

これは実装済みの機能を説明しているのではなく、安全設計として検討してほしい提案である。

「事故を起こすな」と言うだけで済む問題ではない

交通事故が起きれば、運転者の責任が問われる。

だからこそ、配達員は道路交通法を守らなければならない。

しかし、プラットフォームを運営する企業が、配達員の注意を引く通知をどのようなタイミングで送るかも、安全に関わる問題だ。

事故が起きた後に「運転者が画面を見たのが悪い」と説明するだけでは、同じ危険が繰り返されるかもしれない。

重要なのは、事故が起きる前に仕組みを見直すことである。

Uber Eatsの通知が特定の事故を引き起こしたと、この記事で断定することはできない。

しかし、走行中に判断を求めるリクエストが届くという現場の問題を、運営側が軽く扱ってよい理由にもならない。

Uber Eatsに公開質問――配達員の安全をどう守るのか

最後に、Uber Eatsへ具体的に質問したい。

  1. 配達中、特に車両が走行している間にも新しいリクエストを送る理由は何か。
  2. リクエストの受付時間は、安全な場所へ停車するまでの時間を考慮して設定されているのか。
  3. 走行中に安全のため応答できなかった限定配達リクエストは、応答率にどう反映されるのか。
  4. 位置情報や走行速度を利用し、走行中のリクエスト表示を制限する安全機能はあるのか。
  5. 配達員が運転中に画面を注視しなくても仕事の機会を失わない仕組みを検討しているのか。
  6. 配達リクエストの通知設計について、交通安全の観点からどのような検証を行っているのか。

事故が起きてからでは遅い

Uber Eatsは、配達員に自由な働き方を提供すると説明している。

そして、安全を重視するとも説明している。

その二つを両立させるために必要なのは、配達員の注意力だけではない。

運営する側のシステム設計も問われるべきだ。

配達員は、スマートフォンを操作するために道路を走っているのではない。

注文者へ商品を安全に届けるために走っている。

「安全運転してください」と言うのなら、安全に停車してから仕事を選べる仕組みを用意してほしい。

事故が起きてからでは遅い。

これは配達員だけでなく、同じ道路を使う歩行者、自転車、自動車の運転者、そして注文者にも関わる問題なのである。

参考資料

コメント

タイトルとURLをコピーしました