ある時、自分でも見落としていたことに気づいた。始め方ばかり作って、終わり方を作っていなかった。
診断して、買って、契約して、使い始める。その流れは、ずいぶん丁寧に作っていた。けれど、やめたいと言われたとき、どうするか。データを返してほしいと言われたとき、どうするか。そこが、すっぽり抜けていた。始まりだけの設計は、片手落ちだった。
終わり方を、作っていなかった
人は、サービスを始めるときより、やめるときに、その本性を見る。
やめにくい、消しにくい、問い合わせないと止まらない。そういうサービスを、自分はずっと不快に思ってきた。なのに、自分が作る側になると、つい始め方ばかりに気を取られる。やめる導線は、作らなければ、ないままになる。意識して、終わり方を設計に入れた。
止めるのは、段階を踏んで
支払いが止まったときの扱いも、いきなり全部消す、にはしなかった。
まず知らせる。次に機能を絞る。それでも続けば、止める。最後に解約。段階を踏む。そして、止めたからといって、データをすぐには消さない。手違いや、行き違いのこともある。取り返しのつくうちは、戻れる余地を残す。止めることと、消すことを、分けて考えた。
消すことも、自分でできるように
データを持ち出すことも、消すことも、相手が自分でできるようにした。
書き出し。接続の解除。利用の停止。削除の予約。これを、こちらに頼まないと進まない作りにすると、その問い合わせが、また私の時間に乗る。それに、自分のデータを自分で扱えないのは、相手にとっても気持ちが悪い。だから、終わりの操作も、製品の機能として持たせた。
最小限しか、預からない
終わり方を整えるうちに、そもそも預かるものを減らす、という発想にもなった。
外部とつなぐときは、必要な範囲の権限だけをもらう。全部を見せてもらうのではなく、その業務に要るところだけ。預かるデータも、保つ期間を決めて、過ぎたら消す。最初から多くを抱え込まないほうが、止めるときも、消すときも、軽い。終わりの軽さは、始まりの慎みから来ていた。
きれいに、立ち去れるように
解約のときには、後始末を一通り自動で流す。
外部との接続を切る。データを書き出して渡す。処理を止める。消す予定を立てる。最後の請求を確定する。来た人が、きれいに立ち去れるようにする。引き止めるための面倒くささを、わざと残さない。
止められる。消せる。立ち去れる。これがあって初めて、安心して始めてもらえる。終わり方を整えることは、実は、始めてもらうための設計だった。
次の回で、この第5部を締める。守りの最後、人が見る一つのキューについて書く。