1. FAQを書こうとして、止まった
チーム向けのアプリにFAQを追加しようとした。「解約・返金はできますか？」という質問項目は既にあった。そこに「利用をやめるときの手順」を書き足そうと思って、キーボードに手を置いた。
しばらく、止まった。
書くことが、なかった。
結局、書いた内容はこうだ。ブラウザのキャッシュを消すか、ブックマークから削除する。管理者は設定ファイルを空にするか削除する。連絡不要。サーバー側にデータはない。
それだけだった。
2. 普通の解約がどれだけ重いか
一般的なSaaSの解約フローを思い浮かべてほしい。アカウントにログインして、設定画面を探して、解約ボタンを見つけて、理由を選んで、確認メールを受け取って、場合によっては引き止めのオファーを断って、やっと完了する。
データの取り扱いについても説明が必要だ。退会後〇日間はデータを保持します、完全削除をご希望の場合は別途申請を、といった文章が続く。
これはサービス提供者にとってもコストだ。解約フローの設計、メールの自動送信、データ削除のバッチ処理、問い合わせ対応。すべてに開発工数と運用コストがかかる。
3. なぜ書くことがなかったのか
このアプリがなぜ解約手順を必要としないかというと、そもそもサーバーに何も預けていないからだ。
音声の録音も、日々のメモも、閲覧履歴も、すべて各自のスマートフォンの中にしかない。外部サーバーに送信される個人情報がない。アカウントが存在しない。したがって、削除すべきアカウントデータもない。
管理者が配信する設定ファイルは確かに存在するが、それは会社の言葉を定義したものであって、個人を特定する情報ではない。そのファイルを消せば、アプリとしての機能も自然に終わる。
4. 設計の純度がFAQの長さに出る
プロダクトのFAQは、そのサービスの複雑さの鏡だと思う。解約フローが長ければ、それだけ多くのデータを持ち、多くの手続きが絡み合っているということだ。
逆に、FAQが短いプロダクトは、設計がシンプルだということを意味している。シンプルな設計は、意図して削ぎ落とした結果である場合と、最初から余計なものを持たなかった場合とがある。
このアプリの場合は後者だ。個人情報を取らないという原則を最初から持っていた。その結果として、解約という概念が設計の外側に落ちた。意図して解約をシンプルにしたのではなく、解約が不要な構造になっていた。
5. 「取らない」ことの複利
個人情報を取らない設計の利点として、よく挙げられるのはプライバシーへの配慮だ。ユーザーが安心して使える、情報漏洩のリスクがない、GDPRやその他の規制への対応コストが減る。
だがそれだけではなかった。解約フローが消える。カスタマーサポートの一角が消える。データ保持ポリシーのドキュメントが不要になる。退会後のデータ削除バッチが要らない。FAQの一項目が、三行で書ける。
取らないという選択は、取らないことそのものの価値だけでなく、取った後に発生するはずだったすべてのコストを消す。これは複利に似ている。最初の選択が、下流のコストを連鎖的に削っていく。
6. ユーザーにとっての解放
解約手順が存在しないということは、ユーザー側から見ても解放だ。
使わなくなったサービスのアカウントが、どこかのサーバーに残り続けるという感覚は、現代人に特有の小さな不安として積み重なっている。メールアドレスが残っている、パスワードがどこかに保存されている、自分の行動履歴がデータとして存在し続けている。
ブラウザのキャッシュを消せば終わる、というのはその不安を持たせないということだ。始めるときと終わるときの非対称性がない。入口と出口が同じ重さしかない。
7. 書けなかったことが、設計の証明だった
FAQを書こうとして止まった瞬間は、設計思想が可視化された瞬間だった。
思想は普段、コードの中に、構造の中に、見えない形で存在している。それが「書くことがない」という形で表面に出てきたとき、設計の純度を確認できた気がした。
余計なものを持たなかった結果、余計な説明が不要になった。それだけのことだ。だが、そのシンプルさに辿り着くまでには、最初から取らないという選択が必要だった。後から削ることは、最初から持たないことより、ずっと難しい。
個人情報を取らない設計は、プライバシー保護だけでなく、解約という概念ごと消す。FAQの短さが、設計の純度を証明する。