Ａｍａｚｏｎがいろいろとやらかしているようです。
先週の初めですが、Ａｍａｚｏｎで買物をしようとカートに入れるボタンを押すと、カートに下になにかウィンドウが開いたままウェイト状態になってしまいました。いままではそのようなウィンドウは開かなかったため、Ａｍａｚｏｎがインターフェースを修正してきたようです。
その後数十分放置しましたが改善せず、もう一度トライ。しかしそれでも、ウェイト状態は続きカートに商品を入れられません。私はブラウザーにＦｉｒｅｆｏｘを使っているため、今回のＡｍａｚｏｎのインターフェース変更で対応しなかったんだな、と思い、ＧｏｏｇｌｅのＣｈｒｏｍｅを使ってトライ。しかし見事にＣｈｒｏｍｅも同じ状態になってしまいました。仕方が無いのでＭｉｃｒｏｓｏｆｔのＥｄｇｅを使ってみると、またもや同じ現象が。これは私の使っているＰＣの問題かと思い、今度はｉＰａｄでトライ。しかし見事にｉＰａｄでも同じ現象が再発してしまいました。ここまでくるとさすがに気づきますが、どうもＡｍａｚｏｎ側がインターフェースのプログラム変更を失敗し、カートに上手く商品が入らなくなっているようでした。
これでは買物ができないためもう一度Ｆｉｒｅｆｏｘに戻り、何度かトライしてみました。どうやら商品の画面を開いてその商品をカートに入れると今回のバグが発生するようであり、レコメンデーション等にでたものをカートに入れたり、過去の購入履歴からもう一度購入というボタンだと上手くいくことがわかり、その方法でどうにか操作を終えることができました。
そのような不具合が数日続きましたが、金曜日夕刻にはどうにか通常の操作でカートに入れることができるようになり、操作上の問題はなくなりました。この記事を作成している日曜日の時点では、今回追加されたカートに商品を入れた際に他のレコメンデーション商品を表示するウィンドウが昔と同じく表示されないようになっていました。おそらくバージョンを元に戻し、問題の発見・解決を行っているように思います。
さらに先週末には、一部のユーザの間で注文履歴に他人のものが表示されるようになってしまったようです。私自身のＩＤでは問題ありませんでしたが、私の注文内容が誰かのＩＤに表示されて可能性はあり、複雑な気分ではあります。先日もくだらないＯＲＥＯのおもちゃを買ったばかりであり、私が如何にくだらないものにお金を使っているかを他人にバレていると思うといい気分はしません。とはいえ今回の問題について私の推測では、誤って表示されたのは他人のアカウントではなくテストデータだと思っています。インターフェース変更のテストの際に実際の客ではなくテストデータを参照するようにし、その仕組みが残ったまま本番環境に一部のプログラムを移行したため、該当するユーザにはテストデータの履歴が表示されてしまったように思っています。
しかしこのような大規模なミスを、過去にもＡｍａｚｏｎは行っています。数年前のインターフェース変更時には、過去の購入履歴をもとに二重発注を防ぐ表示がでなくなり、ネットが大炎上したことがあります。Ａｍａｚｏｎは誤った二度買いを誘発しようとしているとか、憶測で結構な批判を浴びました。しかし数ヶ月後には何もなかったようにこの表示が復活し、炎上は治まっています。
こう考えてみると、Ａｍａｚｏｎのやり方は世界のデファクトなのかもしれません。Ａｍａｚｏｎは昔からシステム変更に関するローンチ（公開）日時をあきらかにしていませんし、何の前触れもなくインターフェースを変更してきます。一時慣れによる問題が起きてユーザが離れても、よりよいシステムを提供する方が多くのユーザを確保できるという考えなのでしょうし、ネットビジネスでは重要な考え方かもしれません。完全なシステムを提供するために十二分のテストをする余りリリースまで二時間がかかる日本と、問題が起きてから考えることにして、1日も早くよりよいシステムを提供する海外企業の差といえる気がします。
世界は完全なシステムを提供するのではなく、誤りがあっても新しいシステムを１日でも早く提供する事が競争の源泉といわれています。逆に日本のように完全なテストをしても、実際その機能が使われる可能性は解りませんし、全体に対して無駄なテスト工数と金額がかかることになります。決済関係など一切の間違いがあってはいけない部分はもちろんありますが、広告の表示や例外的な処理など、通常余り使われない機能に十分なテストを行わないという考えも我々は取り入れていく必要があるのかもしれません。
逆に完全完璧なシステムを作ることは不可能ですし、そのために工数の大半を割くという考え方も日本独特のように思います。となれば、完全はない前提で間違いが起きてはいけない部分をきちんと明確にし、そこを中心に精度を高めることを考えるべきのように思います。その上でその他の部分はある程度の品質でリリースを行い、問題が起きた時点で対応を行ったほうがずっと効率の良いシステムを作れる可能性があることを、我々は再検討する必要があるように感じさせられた今回の事件でした。
