概要

電話番号の入力項目は、もともと台湾の実店舗で必要となった要件から始まりました。しかし、他の地域チームからも同様の機能を求められたことで、より大きな課題が見えてきました。RHINOSHIELDが展開する10地域のWebサイトでは、それぞれ異なる個人情報の入力項目、ルール、インターフェースが独自に発展していたのです。

そこで、新たな地域別仕様を追加するのではなく、マーケティングチームや開発チームと連携し、個人情報を管理するための共通構造を設計しました。地域ごとの違いには柔軟に対応しながら、全体として一貫性があり、保守・拡張しやすい仕組みを目指しました。

この新しい基盤はその後、電話番号認証、より柔軟な性別選択、プロフィール入力を促すインセンティブ、誕生日特典など、グローバルEC全体におけるさまざまな機能の展開を支える仕組みへと発展しました。

01—最初の依頼

すべては、ひとつの電話番号入力欄から始まった

2021年、RHINOSHIELDは台湾で実店舗での販売を拡大していました。店舗のレジでは、顧客にメールアドレスを尋ねるよりも、電話番号を入力してもらうほうが現実的でした。しかし、当時の会員システムは電話番号にまったく対応していませんでした。

そのため、当初のプロジェクト範囲は非常にシンプルなものでした。

• 台湾の会員システムに、電話番号の入力項目と認証フローを追加する

それだけであれば、比較的小規模な機能追加でした。しかし、実現可能であることが確認されると、プロジェクトの範囲はすぐに広がっていきました。他の地域チームからも、SMSでのコミュニケーションやプロモーション施策のために、電話番号を利用したいという要望が寄せられました。

こうして、台湾だけのための変更が、グローバルな会員システム全体の要件へと変わっていきました。

02—本当の課題

ひとつの会員システムが、10通りの異なるルールへと分岐していた

既存の個人情報に関するユーザー体験を見直したところ、10地域のWebサイトがすでにそれぞれ異なる仕様で運用されていることが分かりました。

性別や生年月日の入力が必須の地域もあれば、そうでない地域もありました。氏名とメールアドレスはすべての地域で共通して必須でしたが、それ以外のプロフィール項目は、各地域のビジネスルールによって異なっていました。その結果、インターフェースも時間とともに地域ごとに独自の形へと発展していました。

この状態で、それぞれの地域に個別で電話番号を追加しても、根本的な問題は解決できません。むしろ、システムの不整合をさらに増やすことになります。

課題は、単に新しい入力項目を追加することではありませんでした。分断されたシステムの中で、新しい項目を各地域でどう機能させるかを設計することでした。

03—組織上の制約

不整合はUIだけの問題ではなかった

当時、開発チームには専任のプロジェクトマネージャーがおらず、Webサイトの仕様の多くが正式にドキュメント化されていませんでした。また、以下の内容をまとめた共通のPRDや一元管理された資料もありませんでした。

• 各市場にどの入力項目が存在するのか

• どの項目が必須なのか

• バリデーションがどのように機能するのか

• 地域ごとの違いをどのように扱うべきか

• 今後の変更をどのように一貫して実装するのか

さらに、私自身も他のプロジェクトを並行して担当していたため、10地域それぞれに異なるデザインを作成・維持し続けることは現実的ではありませんでした。

そこで、既存の分断された状態をそのまま拡張するのではなく、このプロジェクトをきっかけに、より管理しやすい共通の仕組みを構築することを提案しました。

変更を行うたびに、その地域のWebサイトの仕様を知っている人に大きく依存している状態でした。

04—プロジェクトの再定義

目の前のビジネス要件に対応することはもちろん重要でした。しかし、その要件だけを解決しても、既存の運用・保守上の問題はそのまま残ってしまいます。

そこで、デザイン課題そのものを次のように再定義しました。

• 10地域それぞれの体験に不要な違いを増やすことなく、新しい会員要件をどのように導入できるか？

そのためには、システムが次の3つを同時に満たす必要がありました。

• 地域ごとの柔軟性： 各市場には、ビジネス要件やデータ要件において正当な違いがある

• 体験の一貫性： 共通する入力項目やインタラクションパターンは、可能な限りすべての地域で同じように機能する

• 将来的な保守性： 今後変更が発生しても、同じ体験を10回個別にデザインし、ドキュメント化する必要がない仕組みにする

05—システムモデル

各地域のWebサイトをそれぞれ独立したものとして扱うのではなく、個人情報を、地域ごとのルールを設定できる共通コンポーネント群として扱うことを提案しました。

同じ入力項目をグローバルで共通して使用しながら、市場ごとに異なる動作を設定できる仕組みです。これにより、インターフェースの構造には一貫性を持たせつつ、地域ごとにルールを変更できるようになりました。

地域ごとの差異を、個別のデザインではなく「設定」で対応できる仕組みにしました。

06—電話番号と認証機能の追加

当初の要望が、新しいシステムを検証する最初のケースになった

電話番号は、この共通構造を使って導入した最初の主要な項目でした。

台湾では、実店舗での顧客識別やSMS認証に利用できます。一方、他の地域では、それぞれのマーケティングニーズに応じて、個別のインターフェースを新たに設計することなく、同じ電話番号項目を有効にできるようにしました。

つまり、考えるべき課題は、

• 「台湾の電話番号入力をどう設計するか？」

ではなく、

• 「グローバルな会員システムの一部として、電話番号項目をどのように機能させるか？」

へと変わりました。

07—センシティブな情報を、よりユーザー自身が選べる設計へ

システムを標準化することで、センシティブなプロフィール情報についても改めて見直す機会が生まれました。その一例が性別です。

「男性／女性」という二択だけに限定するのではなく、以下の選択肢を用意しました。

• 男性

• 女性

• 自由入力

• 回答しない

目的は単に選択肢を増やすことではありません。ビジネス上の要件を維持しながら、センシティブな情報をどのように、あるいは提供するかどうかを、ユーザー自身がより自由に選べるようにすることでした。

標準化するのは仕組みであって、それを使う人ではない。

08—基盤の拡張

仕組みが安定したことで、単なるフォーム以上の機能へ発展させることができた

個人情報システムを標準化したことで、プロフィールの入力状況や条件に応じた機能を、より簡単に構築できるようになりました。

新たに独立した機能を作るのではなく、特典の仕組みにも、同じプロフィールデータと共通ルールをそのまま活用できるようになりました。

09—価値交換を明確にする

この考え方の中心にあるのは、「より多くの情報を求めるのであれば、その理由をユーザーが理解できるようにする」ということです。

ユーザーは、情報を入力することで得られる価値が明確であれば、プロフィールを完成させることへの抵抗が少なくなります。そこで、プロフィールの入力と誕生日特典を結びつけた、状況に応じたリマインダーを導入しました。

たとえば、単に「個人情報を入力してください」と伝えるのではなく、「プロフィールを完成させて、限定特典を受け取りましょう」と、その先にあるメリットまで伝えるようにしました。

これにより、プロフィール入力を単なる事務的な作業ではなく、ユーザーにとって価値のある明確な交換関係へと変えることができました。

10—特典の獲得条件を可視化する

個人情報ページを更新し、特典の獲得条件をユーザーが確認できるようにしました。 これにより、よくある次のような疑問を解消しました。

• 「必要な情報はすべて入力できている？」

ユーザー自身に「どの情報をすでに入力したか」を覚えてもらうのではなく、アカウント画面上で現在の入力状況と、特典獲得まであとどれくらいなのかを明確に伝えるようにしました。

ユーザー自身が「もう完了したのか」を把握できるようにする。

11—実際のユーザーの疑問を起点にワークフローを設計する

1. なぜこの情報が必要なの？

   • 価値と目的を明確に伝える

2. 選択肢はある？

   • センシティブな情報には適切な選択肢を用意する

3. 何がまだ足りない？

   • 未入力の項目を分かりやすく可視化する

4. 完了したらどうなる？

   •  達成条件と得られる特典を明確に示す

12—プロダクトを超えて

このプロジェクトを通じて、チームの働き方にも課題があることが見えてきました

会員システムに取り組む中で、デザインと開発の連携を支える基本的な仕組みが十分に整っていないことにも気づきました。既存の仕様や挙動の多くが一元的にドキュメント化されておらず、実装やQA、将来的なメンテナンスを必要以上に難しくしていました。

そこで、以下のような改善にも取り組みました。

• 入力項目とデザインの対応関係を明確にしたドキュメントの整備

• 画像素材や翻訳コンテンツを管理する共有ドライブの導入

• バグや開発上の課題を関係者が確認できる、一元化されたチケット管理ボードの導入

これらの改善を通じて、同じ質問や確認作業の繰り返しを減らし、特定の個人に依存しない形でチームの知識を共有・蓄積できる環境を目指しました。

13—成果

システムの一貫性を高めながら、コンバージョンを犠牲にすることなく改善

リリース後1か月以内に：

再設計したシステムにより、より多くのプロフィール情報を収集しながら、会員登録途中での離脱を減らすことができました。 また、各地域サイトのユーザーが、より一貫したアカウントフローを通じてリワードを利用できるようになりました。

再設計したインターフェースでは、ユーザーの負担を増やすことなく、より多くのプロフィール情報を取得できるようになりました。また、プロフィール入力完了時に特典を提供することで、ユーザーに入力を完了する明確な理由を提示しました。

その特典として提供した10％OFFクーポンは、最終的に71,000件の注文で利用され、リワード施策に対する高いエンゲージメントにつながりました。

13—最終的な振り返り

このプロジェクトに参加した当初、依頼内容はシンプルなものでした。台湾の会員システムに電話番号の入力項目を追加することです。しかし、10地域のWebサイト全体を確認してみると、それぞれに個別の項目を追加するだけでは、すでに分散していたシステムをさらに複雑にし、メンテナンスを難しくしてしまうことが分かりました。

このプロジェクトを通じて学んだのは、目の前のUI要件だけを見るのではなく、次の機能が追加されたとき、次の地域へ展開するとき、そして次の担当者がこのシステムを引き継いだときにどうなるのかまで考えることの重要性です。

地域ごとに異なるデザインを作るのではなく、将来の違いを設定によって吸収できる共通の仕組みを構築しました。そして、このプロジェクトから得た最も大きな学びは次のことです。

良いシステムは、すべての違いをなくすものではない。

その違いを、意図的で管理可能なものにする。