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

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

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

• 未登録
• 仮登録メールの送信済み
• 本登録URLの確認待ち
• 本登録済み
• ログイン済み
• 追加情報の登録待ち
• 確認・承認待ち
• 利用停止または退会済み

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

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

役割と権限を、画面名だけで決めない

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

• 利用者本人が自分の情報を閲覧・変更する
• 担当者が支援に必要な情報を閲覧し、メモや進捗を追加する
• 管理者が利用状態や担当者を変更する
• 公開担当者が全体へ表示する情報を承認する
• システム管理者が権限や連携設定を管理する

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

外部サービスとは、成功した後だけでなく途中状態を合わせる

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

• 外部サービスへ送信する前
• 送信したが応答を待っている
• 外部処理は成功し、自社側への反映を待っている
• 外部処理は失敗し、再実行できる
• 一部だけ完了し、確認が必要
• 双方で処理が完了した

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

機能を使わないことと、未完成であることを分ける

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

• 一般利用者から見えるログイン導線
• 会員限定情報の公開範囲
• 保持する会員データ
• 管理画面の操作
• 再開時に戻すURLと表示条件
• 休止中も必要な保守と安全対策

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

テストは、状態の移動として行う

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

• 仮登録から本登録を完了できるか
• 期限切れや使用済みURLで次の操作が分かるか
• 登録途中で離脱した利用者が再開できるか
• 役割ごとの閲覧・変更範囲が正しいか
• 権限のないURLへの直接アクセスを拒否できるか
• 外部処理の失敗で二重登録が起きないか
• 停止・退会後にログイン、通知、表示が正しく変わるか

この進め方が有効な場合

• 仮登録や承認を含む会員登録がある
• 利用者、担当者、管理者など複数の役割がある
• 会員種別や契約状態によって表示内容が変わる
• 決済、予約、顧客管理など外部サービスと連携する
• 会員機能を段階的に公開・拡張する
• 既存会員データを移行または同期する

別の進め方が適する場合

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

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

会員サイト設計チェックリスト

• 利用者の状態と遷移条件を整理したか
• 状態ごとに見せる画面と次の操作が明確か
• 役割と操作権限を分けたか
• データの所有者と正本を決めたか
• 外部サービスとの途中・失敗状態を確認できるか
• 機密情報を必要以上に保持・表示していないか
• 未公開、休止、未完成を区別したか
• 期限切れ、離脱、重複、権限外操作を確認したか