チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
あるリモートチーム向けのコラボレーションツールには、タイムゾーンを入力するプロフィール欄がありましたが、正しく入力している人はほとんどいませんでした。オンボーディング中に長いドロップダウンリストから自分のタイムゾーンを手動で選ぶ必要があり、特にアカウント作成時に引っ越したばかりだったり旅行中だったりした人にとっては、飛ばしたり間違えたりしやすい手順だったからです。その結果、チームのディレクトリには古いか欠けたタイムゾーンのデータがあふれ、同僚にメッセージを送るかどうかを決める際に実際に使えるほど信頼する人はいませんでした。
この会社は、手動の入力欄を自動のものに置き換えました。ユーザーにタイムゾーンを選ばせる代わりに、アプリはリクエストを送る接続から直接タイムゾーンを解決しました。/v1/ipがログイン時にユーザーのIPアドレスを受け取って国と座標を返し、その座標を/v1/timezoneに渡すと、その場所のIANAタイムゾーン名が返ります。ユーザーがフォームに一度入力したときの所在地に固定するのではなく、定期的に再解決することで最新の状態を保ちました。
製品上で目に見える結果は、すべてのチームメンバーのプロフィールへの小さな追加でした。チームのディレクトリやダイレクトメッセージの会話で、名前の横に国の表示と自動で更新される現在の現地時刻が表示されるようになりました。メッセージを送るか朝まで待つかを決める同僚は、相手がどの国を拠点にしているかを覚えていたり、自分でタイムゾーンの計算をしたりしなくても、相手の場所で今が常識的な時間帯かどうかをひと目で確認できるようになりました。
この会社は、この設定を完全に自動で変更できないものにするのではなく、調整できるようにしました。検出された所在地をユーザーが上書きしたい場合がときどきあるからです。たとえば、普段とは別の国から一時的に仕事をしている人が、今接続している場所ではなく普段のタイムゾーンをプロフィールに反映させたい場合などです。自動検出は一般的なケースでは自動で更新される妥当な初期値を設定し、例外のために手動での上書きも引き続き利用できるようにしました。
エンジニアリングの労力という点では本当に小さな機能で、基本的にはログイン時に2つの検索をつなげ、チームのディレクトリの表示を少し変えただけでした。しかし、何年もの間チームに少しずつ調整の手間をかけさせていた摩擦を取り除きました。今が誰かに連絡してよいタイミングなのかを、事前に尋ねるか推測するしかないという、目立たないコストです。
位置とタイムゾーンのデータはリクエストのたびではなく定期的に更新されるため、リクエスト量はメッセージやページ表示の1件ごとではなくログインのセッション数に連動していました。そのため、1日を通して相当な数のユーザーがログインするチームコラボレーションツールでも、処理量は1日の無料の割り当ての範囲内に十分収まりました。
このような小さく目立たない初期設定は、積み重なると、どんな派手な機能よりも重要になりがちです。たまにしか起きない問題を解決するのではなく、絶えず起きていることから小さな摩擦を取り除くからです。両方のエンドポイントのドキュメントは/docs/ipv4-lookup/と/docs/timezone-lookup/にあります。