会員サイトで、登録状態・役割・権限・外部連携をどう設計するか｜実務知識

会員サイトは、会員登録、ログイン、マイページ、管理画面を用意すれば運用できるわけではありません。

同じ利用者でも、メールアドレスを入力した直後、本登録を完了した後、ログイン中、追加情報の確認待ちでは、利用できる画面と次に行う操作が異なります。利用者、担当者、管理者が同じ情報を扱っていても、閲覧・変更・承認できる範囲は同じではありません。

私たちが会員機能を整理するとき、最初から画面一覧を作ることはしません。外部の会員管理、決済、予約などと連携すると、自社サイト側の表示だけでは処理が完了したか判断できないからです。まず利用者の状態、役割、権限、データの正本、失敗時の戻り先を並べます。

画面ではなく、利用者の状態から整理する

最初に、サービス内で起こり得る状態を並べます。例えば会員登録には、次のような状態があります。

重要なのは状態を増やすことではなく、各状態について、見せる画面、許可する操作、次へ進む条件、途中で失敗した場合の戻り先を決めることです。

「登録に失敗しました」という一つの表示へまとめると、再入力すべきか、メールを確認すべきか、ログインし直すべきか判断できません。現在の状態と次の操作を対応させることで、途中から再開できる導線を作れます。

同じ画面へ到達できても、役割によって許可する操作は異なります。実際の作業から権限を決めます。

「管理者」という一種類へ操作を集めず、閲覧、作成、変更、削除、承認、出力、設定を分けます。利用者本人の情報、担当者だけが記録する内部メモ、全体へ公開する情報では、同じ会員IDに紐づいていても扱いが異なります。

外部の会員管理、決済、予約、顧客管理と連携する場合、自社サイトと外部サービスのどちらを正本にするかを先に決めます。処理は「APIを呼び出せたか」だけでは確認できません。

利用者には「処理中」「完了」「再操作が必要」「問い合わせが必要」など、次の行動が分かる状態として表示します。運用者には、どこまで完了したかを確認できる情報を残します。外部側で管理すべき機密情報と、自社管理画面へ表示する状態情報も分けます。

運用方針の変更により、完成している会員機能を初回公開では利用しない場合があります。このときは機能を削除するか残すかだけで判断しません。

「未公開」と「未完成」を区別し、休止する機能の関連URL、ボタン、権限、データ、通知を一組で確認します。

画面を一枚ずつ開くだけでなく、利用者が状態を移動する一連の流れとして確認します。

ログイン後に同じ静的資料を見せるだけで、会員種別、承認、外部連携、個別データを扱わない場合は、細かな状態・権限設計は不要です。汎用の会員サービスやCMSの閲覧制限で要件を満たせる場合もあります。

個人情報、決済、契約、支援記録などを扱う場合は、画面制作だけでなく、データの所有者、保持範囲、操作履歴、削除方針、外部サービスの責任範囲を含めて設計します。