ひとつの失敗、ひとつの成功
· Matt Senter
あるユーザーからPremailについてのフィードバックが届きました。決済に進もうとすると404エラーが出るというのです。これはすぐに恥ずかしくなりました。本来動くページがあるべき場所で404を返すものなど、そもそも公開すべきではありません。ましてや、誰かがまさにお金を払おうとしている瞬間には。
テストはあります。アラートもあります。インフラの警報もあります。そのどれも、この問題を捕まえられませんでした。捕まえたのは、壊れた決済画面の向こう側に立っていた人でした。
この出来事が興味深かったのは、発見したときの悔しさとは別に、私が実際にどうやってそれを知ったかという点です。ほんの数日前にPremailに追加した機能が、ほかのすべてが私の目に届けられなかったフィードバックを浮かび上がらせてくれたのです。私のプロダクトが失敗し、そして私のプロダクトがその対処を助けてくれました。
顧客が警報になるべきではなかった
決済の失敗には、とりわけ痛いところがあります。相手はすでに、あなたのプロダクトを見つけ、何をするものかを理解し、お金を払う価値があると判断するところまで済ませています。その相手の前に、行き止まりを置いてしまうのです。
この人がタブを閉じて立ち去ったとしても、まったく無理はありませんでした。バグ報告も、スクリーンショットも、なぜ私が売上を得られなかったのかの説明も、私に対して負うものではありません。何かを買おうとしていたのであって、品質保証のボランティアに志願したわけではないのです。
それでも、この人は時間を割いてフィードバックを送ってくれました。本当にありがたく、お礼として50%オフを差し上げました。そうでなければ知らないままだったかもしれない問題を直す機会を、与えてもらったのです。
そこが同時に、居心地の悪い部分でもあります。教えてくれた人のことは分かっています。しかし、同じ問題に遭遇して何も言わずに去った人がほかにいたかどうかは分かりません。失敗を実際に捕捉していない限り、決済の失敗は、ただ買わないことにした人の姿とほとんど区別がつきません。
私の失敗は捕捉されていませんでした。テストや監視にどれだけ自信を持っていたにせよ、これは何か重要なものを見逃していたことのかなり明白な証明でした。
気づく必要のあったメール
私のフィードバックフォームは、確認すべきフィードバックがあることを知らせる短い通知メールを送ってきます。フィードバックの全文ではなく、ほんの短い一言です。誰が何を書いたのかを知るには、そのメールに気づいて、確認しに行く必要があります。
私はそれを見落としていました。しかしその通知がPremailの朝のブリーフィングに現れ、対応すべきフィードバックがあることにすぐ気づきました。読みに行き、決済の問題を知り、作業に取りかかりました。
ここははっきり区別しておく価値があります。Premailが404を検知したわけではありません。私の決済フローを調べたわけでも、バグを診断したわけでも、本来それを捕まえるべきだった監視を何らかの形で肩代わりしたわけでもありません。問題を見つけたのは顧客です。Premailがしたのは、顧客の報告を読みに行くきっかけとなる通知を浮かび上がらせることでした。
それはまさに私がブリーフィングにやってほしかったことであり、しかも私自身がまだ使い慣れようとしている最中に起きたのです。
作ったばかりのものを使う
Premailにブリーフィングを追加したのは、ほんの数日前のことです。反射的にメールクライアントを開くのをやめ、代わりにブリーフィングを、注意を向けるべきことの要約として使うよう自分を訓練しようとしています。これは私にとって習慣の変化であって、単なる機能のリリースではありません。
受信トレイを開くことと、何が重要かを見極めることは、別々の行為です。次に何をすべきかを変えるはずの特定のメッセージに気づかないまま、メールを眺めることはできてしまいます。今回の場合、フィードバックに関する小さな通知が、実際のタスクにならなければなりませんでした。これを読みに行って、返事をする、というタスクに。
朝のブリーフィングが、その結びつけを代わりにやってくれました。見落としていたものを見て、行動が必要だと理解し、すぐに行動しました。役に立ったかどうかに、曖昧なところはほとんどありませんでした。
人の役に立つと信じて機能を作るのと、その機能が自分自身のメールから重要なものを引き出し、その日の午前中の流れを変えるのを目の当たりにするのとは、別のことです。もっと恥ずかしくない例のほうがよかったのですが、これはかなり説得力のある例でした。
決済以上のものを直す
決済の問題は今では直っています。それを捕まえられなかったアラート、インフラの警報、テストも直しました。ページを動くようにするのは必要なことでしたが、そこで止まっていたら、何かがおかしくなったときに教えてくれる次の親切な顧客に頼り続けることになっていたでしょう。
こういうことは二度と起きない、と宣言するつもりはありません。最初のときも防ぐために努力していて、それでも起きたのですから。これらの変更の目的は、再発を防ぐこと、そしてもし起きてしまった場合には、顧客が報告する前や、見込み客が黙って諦める前に、私がそれに気づけるようにすることです。
教訓は、朝のブリーフィングがテストや監視の代わりとして許容できる、ということでは決してありません。「誰かが苦情を言うのを待ってから、その通知を要約する」というのは、信頼性の戦略としてはひどいものでしょう。そもそも問題が顧客に届いてしまった仕組みを直す必要がありました。
しかし同時に、それらの仕組みが失敗した後で、Premailが本当に役に立つことをするのも見ることができました。見落としていたメッセージを私の目の前に持ってきて、そのメッセージが修正に直結したのです。
自分のアプリが発見を助けてくれたからといって、決済の失敗が恥ずかしくなくなるわけではありません。二つのことが同時に真実です。私は顧客を壊れた決済画面に突き当たらせてしまい、そして作ったばかりの機能が対応を助けてくれました。わざわざ知らせてくれた顧客に感謝していますし、朝のブリーフィングが確実に気づかせてくれたことを嬉しく思っています。