データバックアップメモ - extended -

bk1リニューアルのゴタゴタについて、bk1の河野氏が自身のブログで記述している。以下はその一部を抜粋。

現場の声としては、延期につぐ延期でお客様からメール拒否の声が多く寄せられ、リニューアル本番時にメールを送れなかったことが反省点です。これは「それでも大事な内容だからメールを送ろう」とぼくが言うべきでした。お客様から届くお怒りのメールを恐れて、より悪い結果になってしまったことを深く反省しています。

お客様の怒りの声を恐れ後手後手の対応に回ってしまう、というのはテクニカルサポートなどでよく見られる光景なのだけれど、実は一番やってはいけないことではないかと思う。後手後手になればなるほどお客の怒りを増幅してしまう、という点だけではなくて、怒りのメールが期待の裏返しである事を忘れてしまっているからだ。

本当に怒って呆れてしまったら、自分の意思など伝えずに去っていくものである。そして彼らはあちこちで不平不満を広める。企業にとって一番怖いのはそういったサイレントマジョリティである。

今回のリニューアルの前にアマゾンの秘密という本を読んでいたのだが、その中に今回のリニューアルを思わず意識してしまう部分があった。

それは「アマゾンでは新サービスの告知というのを出来るだけしないようにしている」という点。ギリギリまで告知をほとんどしないということで、万が一本稼動でトラブルが起きたとしても、お客が余計な期待を抱く事も無い。

お客に余計な期待を抱かせないようにする、いわば秘密主義とも言える対応だが、裏を返すと実際に新サービスを開始しても問題無いといえるレベルになるまでサービスを開始しない、ということであるようだ。本サービスになっても問題無いといえるレベルにするためにテストを何段階にも用意しておき、実稼動システムとテストシステムを同じレベルで動作させて、かなりの人数をテスターとして用意して検証するというのだから、かなり徹底しているといえる。決して提供サービスのレベルを下げるわけではないところがアマゾンらしい。

と同時に、トラブルが発生して何度かサービスのリリースを延期しなければならなくなったとしても、無理やり期日にリリースするような事はしないらしい。日本企業によく見られる「大々的に新サービスを告知→新サービス提供前にトラブル発生→サービス提供を延期→トラブル対応の中、再度サービス開始日を告知→システムは完全ではないが再度の期日延期を避けるために見切り発車→トラブル大発生→顧客の怒り大爆発」というスパンに陥る事を恐れる為だ。

告知をする場合の弱点を際立たせてしまったという意味において、今回のbk1とはとても対照的に感じた。もっとも、書籍というのは自分に都合のいいところだけを載せがちなので、その点は差し引いてみる必要があるのだけれど。

もうひとつのキーワードとして記憶に残ったのは「アマゾンは一つのソフトウェア」という言葉だろうか。Amazon APIのような外部にその機能を提供するのもそういった感覚があればこそだと思う。と同時に、お客は一つのソフトウェアを見るような目でサービスを見るということでもあろう。一箇所がだめだと全てをダメだと思う顧客心理を良く現している言葉だと思う。

あとは「社員に何も教えてくれないが何でも学べる」ほどの情報共有がイントラネットで出来るようになっていることなど、大きな企業ではよく見られるものも散見されたが、基本的には会社のポリシー（もしくは企業文化）がそれを有効なものにしているように思う。他にもいくつかポイントがあったかと思うが、それは実際に本を読んでもらったほうがよいと思う。

河野氏は

焦りはなかったかと言えば嘘になるし、不安はなかったかと言うのも嘘になるほど、決して万全ではないスタートでした。これは執行部の責任として、重く受け止めています。

といわれているが、それよりもむしろ会社全体のサービスリリースに対する基本ポリシーが上記のような見切り発車を生み出し、今回の失敗を生み出してしまったように感じた。全体責任などではなく、ポリシーの不徹底が生み出してしまったというか。

外野席から見ているだけの何も出来ない身で無責任な発言ではあるけれど、「倒れない程度に」「マイナス思考にならないように」「体の血の巡りを良く保つようにして」がんばってほしいと思う。