会員登録・マイページ・権限管理が必要になるのはどんなときか

01

「ログインできる場所」より先に、誰に何を見せるかを決めます

会員の仕組みを考えるとき、登録画面やログイン画面から思い浮かべがちです。けれど、利用する人が知りたいのは、ログインした先で何が見られ、何ができるかです。運営する側にとっても、誰が登録し、誰に何を公開しているかを把握できなければ、仕組みはかえって手間を増やします。

まずは、利用する人の種類を書き出し、それぞれに見せる情報と見せない情報、本人にしてもらいたい操作を並べてみます。会員は1種類だけなのか、受講者と講師、取引先と社内のスタッフのように、立場によって見せる内容が変わるのかで、必要な仕組みは大きく変わります。

あわせて、登録した人にとって何が良いのかも確かめます。登録やログインの手間に見合う利点がなければ、会員は増えず、仕組みも使われません。

02

既存のサービスで足りる場合もあります

限定公開の動画やファイルの共有、オンライン講座や会員制のサービス、会員へのメール配信など、会員向けの情報提供を支えるサービスは数多くあります。決まった人に、決まった情報を届けることが中心なら、こうしたサービスを使うほうが、費用も期間も抑えられます。

予約システムを選ぶときと同じく、確認したいのは「今のやり方をそのまま再現できるか」だけではありません。サービスに用意されている登録・公開・配信の流れを理解し、事業の運用をそちらに寄せられないかも考えます。サイトには、会員になる前に知っておきたいことと、登録や利用の案内を分かりやすく置くことが大切です。

• 会員の種類が少なく、全員に同じ情報を見せればよい
• 会員の登録や管理を、サービスの画面と手順で無理なく行える
• 会員の情報を、ほかの業務の情報と結び付ける必要がない

03

個別に設計することを検討するサイン

サービスの標準的な流れに運用を寄せることを検討しても、手作業や例外対応が繰り返し残ることがあります。次のような状態が続くなら、会員の仕組みを業務に合わせて設計する価値があります。

個別の設計は、機能を増やすことが目的ではありません。利用する人が迷わず必要な情報にたどり着き、運営する側が会員と関連する情報を一つの流れで扱えるようにするための方法です。既存サービスで足りる部分と、個別に整える部分を分けて考えます。

• 利用する人の種類によって、見せる情報やできる操作が変わる
• 登録の承認や会員情報の更新を、運営する側が手作業で繰り返している
• 会員の情報が、申し込み・支払い・書類など、別の情報と結び付いている
• 条件に合う情報を、該当する会員にだけ知らせたい

04

権限は「役割」と「範囲」で考えます

権限の管理というと難しく聞こえますが、考え方は単純です。管理者、スタッフ、会員、取引先といった役割ごとに、何を見られるか、何を追加・変更・削除できるかを表にします。役割ごとの違いが表で説明できれば、仕組みとして設計できます。

このとき大切なのは、必要以上の権限を渡さないことです。スタッフが会員情報を閲覧できても、削除まではできないようにする。会員は自分の情報だけを変更できるようにする。権限を絞ることは、誤操作や情報の漏れを防ぎ、運営する側の安心にもつながります。

• 役割ごとに、見られる情報と見られない情報
• 役割ごとに、追加・変更・削除できる情報
• 役割を誰が、どのような手順で変更するか

05

運営する側の画面と仕事も、設計の対象です

会員の仕組みは、利用する人の画面だけで完結しません。登録の承認、会員情報の更新、問い合わせへの対応、退会の処理、利用状況の確認など、運営する側には日々の仕事が生まれます。この仕事をどの画面で、誰が、どのくらいの手間で行うのかも、最初に考えておきます。

利用者が自分でできることを増やすと、運営する側の問い合わせ対応が減ることもあります。たとえば、領収書や書類を利用者が自分で取得できる、予定や状況を自分で確認できるといった工夫です。どこまでを利用者に任せ、どこからを運営する側が確認するかを分けることが、続けやすい仕組みにつながります。

仕組みのコストは、導入にも運用にもかかります。それはお金だけの話ではありません。機能を足したのに管理の手間が増えたり、利用する人に「難しい」と感じさせてしまったりする仕組みは、成功とは言えません。運営する側と利用する側の双方にとって、心地よく使えることを目指します。

06

個人情報を預かることも含めて考えます

会員の仕組みを持つことは、利用する人の個人情報を預かることでもあります。取得する項目は、本当に必要なものに絞ります。項目が少ないほど、登録の手間も、管理の負担も、万一のときの影響も小さくなります。

あわせて、ログイン情報の扱い、不正な登録への対策、公開後に不具合や問い合わせが起きたときに誰が対応するかも決めておきます。仕組みを作ることと同じくらい、公開後に安全に運用し続けられる体制が大切です。

07

予約と組み合わせる場合

同じ人が繰り返し予約する、会員かどうかで予約できる内容が変わる、支払いや領収書を本人が確認できるようにしたい。このような場合は、会員の仕組みと予約の仕組みを一緒に考えます。予約の流れから選び方を整理する方法は、「予約システムは、既存サービスか個別開発か」でご紹介しています。

08

相談では、決まっていないことも含めて整理します

Harmony Webが開発したレンタルスタジオの予約サイトでは、空き状況はログインせずに誰でも確認でき、予約の申請は会員登録をした人だけができるようにしました。運営者が支払いを確認したあとに領収書を発行し、利用者はマイページからダウンロードできます。誰に何を見せ、誰が何を確認するかを分けた設計です。

公開後も、スパム登録への対策や、利用者が調律の予定を自分で確認できる表示の追加、登録のトラブルへの対応を続けています。最初からすべてが決まっていたわけではありません。今の会員の管理方法、見せたい情報、困っている場面が分かれば、どこまでを既存サービスで進め、どこを個別に設計するかを一緒に考えられます。