システム屋の視点でAmazonFlexのサービスを考えてみる

システム屋の視点でAmazonFlexのサービスを考えてみる

Amazon Flexと言うサービスが2019年4月から正式にリリースされています。
これは、登録したユーザーがAmazonから配達業務の委託契約を受けるという、UberEatsのAmazon版です。
米国では2015年に開始されていて、様々な問題が発生しているそうです。

先行して導入した国で露見しているAmazonFlexの問題点

とまぁ、色々あるようです。
もちろん大部分の配達員の方は真面目にしっかり配達してくれているのだと思います、どこの国でも。

問題の傾向を見るとサービスとして異常系の潰し込みが弱い

99％成功しても1％の致命的なエラーで評価が変わることがあるシステム屋の世界です。
致命的エラーは「異常系を洗い出し、分類して準正常系まで落とし込む」工程が不足していた事を物語ります。
原因は色々あるでしょう。

しかし、どんな理由であれ、致命的なエラーを起こしたシステムが非難を受ける事は間違いありません。
悪い奴は必ずいます。これを【準正常系】として落とし込むところまで【AmazonFlexのサービスが設計されているか】が問題となります。

個人情報ってどこまでを指すのか

今入っている現場でそんな話題が出たことがあります。

ざっとですが、こんな内容がテーブルに上がりました。
今の現場では、この全てのパターンに対して「個人情報として取り扱うべきだ」との結論に至りました。
実際には「個人を特定できる情報、個人と関連づいた情報が個人情報である」という認識をすることが多いように思います。
つまりは「氏名のみ」と「氏名+ハッシュ化された何かのパスワード」は現時点ではギリギリ個人情報に当たらなそうです。

個人情報保護を考えた場合、Amazon Flexというシステムのリスク

あくまでもシステム屋としてみた場合の視点で書き連ねていきます。

今のAmazon Flexでは流石に改善されているでしょうけど、米国では購入した商品がわかる状態だったようです。
多分配送伝票か何かに記載があったのでしょうね。日本でも書籍買ったときに書籍名まで伝票に記載されてる時ありましたし。
この場合【個人名 + 住所 + 購入商品名】という情報が配達人に渡ってしまいます。

職業＝配送会社の配達員であれば、何かしでかすと即クビですから、その情報が渡っても問題ないのかもしれません。
大体配達エリアを個人が選べるわけではないですし。

しかし、Amazon Flexでは配達エリアを自分で選べるようです。
エリアがどの程度の広さなのかは判らないですが、効率を考えるAmazonさんですから『ある程度狭めた範囲』になっているでしょう。

以前「横浜流星がUber Eatsで豚バラ頼んだ」という情報が流れたことあります。※真実は知りません。（それほど興味ありません）
が、そんなことを言い出す馬鹿が存在するという事実をこの事例は物語ってます。
そしてシステム屋的に言えば、このエラーは十分に考えられる異常系であり、準正常系までフローを落とし込まないとイケナイ奴です。

AmazonFlexの準正常系対応

AmazonFlexの答えは「変な奴は垢BANして次の依頼は出さない」という対応です。
このやり方は言ってみれば下のような対応です。

ありがちな対応かもしれないですけど、私だったらそんな改善を行うエンジニアに次のオーダーは出さないですね。

まずは異常系の発生を抑える仕組みの改善が必要です。
でも、参画の敷居を低くしている手前「選考で篩い落とす」は難しいのも事実です。
そのため、対処療法になるのも判らないではないです。

業務全体の見直しをするとパッと思いつくだけでこれだけの案は出てきます。

Amazonは個人事業主であるAmazonFlex登録者と業務委託契約をしっかり結んでいます。

この記載内容がどうなっているか、私は理解していませんが、登録者の不満を拝見すると『やめたくなくなる環境』の用意は無さそうですし、垢BAN以上の罰則も（記載はあるかもしれないですが）実施はされていないように感じます。
というか、垢BAN砲を撃ちすぎなイメージを持ちますね。

ソース①：Amazonフレックスの評判はどう？稼ぎづらいの？配達員の声を調査
ソース②：アマゾンフレックスの口コミ・評価
ソース③：アマゾンの自社物流「Amazon Flex」は誤解されている–ジェフ・ハヤシダ社長インタビュー

業務委託契約を結んでいれば情報漏洩はない？

これは詭弁で、情報が漏洩しないなんて事はあり得ません。

いえ、性善説的には「あり得ない」のですが「悪意を持った人なんていない」なんて想定が甘々なのは社会生活をしている人ならわかっていると思います。もちろんAmazonだってそんな事は十分理解しています。が、それでも対応は【垢BAN】なんです。

企業間の情報漏洩は漏れた機密情報から特定も容易でしょうけど、個人情報はむずかしいです。
情報の漏洩ルートを追わないとそもそも違約を問えないですよね。
知り得るルートが沢山ありますから「漏洩源はあなたです」という特定はとても難易度が高いと言えます。

じゃぁどうするか。

Amazonの対応は【疑わしき者は罰する】の実行のようです。

システム屋は業務フローのどこまで踏み込むべきか

時と場合にはよるでしょう。でも、システムが絡まないところでも極力口を出すべきだと考えています。

エンジニアが作成するシステムで業務の全てを賄えるというのは幻想です。
システムは業務の一部を担うモノであって、業務全体のフローをコントロールしているわけではありません。
異常系の発見にはエンジニアの作成するシステム外の「何か」が影響を与えていることも多く、 プログラマもシステムが絡むフロー全体を理解し把握しておく必要があります。
というか、それが出来ないと異常系の見落としが生まれます。

まとめ

エンジニアもプログラムだけではなく全体の業務をしっかりと理解しよう

というお話をAmazonFlexを題材にまとめてみました。
今参画している現場で、複数の会社が集まった合同案件になっているものが複数あります。
その中の企業さん（担当者さん）には「上が決めた自分の作業範囲だけやります」というスタンスの方が一部見受けられます。
こういった方は、アイディアを求められると【全体の流れを見ると変な仕様】に持っていこうとする事があります。

例えば、データとして広く収集したい（ビックデータにしていきたい）希望があり、その為に参入障壁を下げようという前提があるのに「情報は個人と紐づけてこそ意味がある」と氏名/住所/携帯番号の入力を必須にする仕様を話し出したりとか。

要注意ですね。