<< URI でリクエストされた時に送るデータの設計 | main | 「自然キー」で識別するのが、もっとも「自然」 【パターン】 >>

個人の識別キーの設計 : 名前? 番号? メールアドレス? 別名?

顧客や申込者の「個人」を識別するキーの設計は、なかなか興味深いテーマ。

分かりやすさでは「名前」。一意識別性なら「番号」。
ドメイン名や、メールアドレスは、「名前」の分かりやすさと、一意識別性を兼ね備えている。

宅配ピザ


宅配ビザに注文すると、電話番号を質問される。
顧客データベース上で、私(の自宅)を電話番号で特定しているわけだ。

データベースに登録されている住所(と名前も?)を、確認されて、顧客の確認を終了。
これで、どこに配達するか、特定できたわけだ。

簡易な識別方法として、電話番号が有効なことは多い。

宅配ピザであれば、国番号とか、市外局番も不要。東京だと、4桁-4桁の番号が、リピート顧客の識別キーになる。

利用する側も、受付側も、負担が少ない、良い設計だと思う。

クレジットカードの問合せ


クレジットカードについて、突然、使えなくなったので、コールセンターに電話。

カード番号を聞かれた後、登録済みの「住所」「電話番号」「生年月日」を質問されて、本人確認。
結構面倒。まあ、宅配ピザというわけにはいかない。

限度額オーバーだった。

ちゃんと、限度内でやっているつもりだったけど、海外で使った金額が、前月引き落とし済みと思っていたら、遅れて、今月の請求になっていたので、限度額オーバーになっちゃった。

でも、この情報が、さきほどの本人確認で聞き出せるのは、ちょっと、不安。

カード番号、住所、電話番号、生年月日、悪意があれば、他人が私に成りすますのは、それほど、むずかしくはなさそう。

もっとも、金額とかのナマのデータは、オペレータは、一切、しゃべらない。
(たぶん、画面でも、この段階では、そこまで見れない)

「限度額オーバー」という状態だけ教えてくれる。
セキュリティレベルと、問合せの利便性を考えると、ここらへんもバランスがとれた仕組みになっているのかもしれない。

何のときだったか、忘れたけど、「登録してある銀行口座番号」まで、聞かれたことがあった。
クレジットカード会社からの請求書とかには、口座番号は、マスキングしてあるので、この情報まで、私がちゃんと提示できれば、より確かな本人確認になるわけだ。

リフレクソロジー


時間があいたので、足裏マッサージでもしようかと、リフレクソロジーのチェーン店に飛び込んだ。

会員かどうか聞かれたので、会員と申告。でも会員カードをもっていなかった。

誕生日(月と日)を聞かれて、苗字を聞かれて、本人確認終了。
同じ誕生日で、同姓の人はいないみたい。

あとは、支払い時に、ポイント加算してくれたことを告げられる。

誕生日(月と日)で、ハッシングして、そのグループ内で、姓で特定にいく。
同姓同名の場合、どうやっているのか、ちょっと興味があるなあ。
(お店の人とか、この記事読んでいたら、教えてくれないかしら)

応募者の重複チェック


私のメインの活動領域、人材の募集と応募のドメインでの「個人の識別」のテーマ。

同じ人が、繰り返し応募してきたり、別の職種に同時に応募する、というのはよくある話。

で、応募情報から「同一人物」を特定するのが、結構やっかい。

メールアドレスとか、電話番号は、わりと、変わるんですよね。

いちおう、「生年月日」と「ヨミガナ」をキーにして、「もしかして同一人物」リストを出すようにしている。

漢字の姓名は、表記の揺らぎが意外とあるんですよね。(大沢さんと大澤さんとか)

最後は人間が判断


どのケースも、「本人確認」とか「同一人物」判断は、人がやっている。

クレジットカード会社とかは、情報の一致だけじゃなく、相手の応答がつまったり、へんだったりしたら、マニュアルが、しっかりしていて、質問レベルが難しくなるようになっているらしい。

そうそう、何か、住所か何かを言い間違えた時に、えらいめにあった気がする。

管理番号


システム化の王道(?)は、やはり、管理番号をつけて、一意に識別すること。

これは、電子化以前から、業務の仕組みとして、確立しているやり方。

顧客番号、注文番号、契約番号、請求番号、...

紙伝票に手書きの時代から工夫されている。

手書き時代の番号は、「年」とか、「月」を先頭につけて、それ以下を連番にする、というのが多かったような気がする。

これ、システム的にはちょっと厄介なんですよね。月ごとに、連番をリセットするというのは。

あと、最近は、分散処理というか、ネットワーク上で、複数のサービス(異なるアプリケーション)から、顧客登録が可能、というケースもでてきた。

この場合は、一意に識別する顧客番号を、発行するのは、結構たいへん。

まあ、先頭に、サービスごとの識別番号をつけるとか、いうやり方もあるにはある。

年、月、登録サービスなどの情報を、識別キーに埋め込むことは、あまり良い方向ではなさそう。

この程度のレベルであればいいけど、会員種別とか、居住地域とかの情報が、識別番号の一部にまぎれこんでくるのは、明らかに、汚染。

登録制


ドメイン名とか、ISBN は、登録制だから、グローバルに、一意識別が保証されている。
電話番号も、国番号まで使うと、いちおう、そうなっている。

通信インフェースカードの識別番号である、 MAC アドレスも、世の中のすべての通信カードで、一意に識別するようになっている。 (ろくでもない製造業者が、偽造番号で作っていることが、昔はあった。今でもあるのなか?)

JAN コード(商品のバーコードでおなじみ)も、登録制で一意の番号。ワールドワイドの商品識別体系の一部として互換性があり、世界中で一意になる仕組み。

もっとも、JAN コード自体は、一意だけど、同じコードを複数の商品に使ったりしているメーカーがあるので、商品のコードとしては一意ではない。

サイズ、色違い、バージョン違いなどは、 JAN コードでは、特定できないのが普通。

こういう共通の識別体系じゃなくても、アプリケーションで独自に「発番」の仕組みを作って、登録制にするのは、常套手段。

ネットワーク上で、他のサービス(他の識別体系)との連係が、ますます重要になってきているの。アプリケーションの独自の発番の仕組みを考えるときは、外部の識別体系との関係性や、整合性には、気を配るべき。

まあ、URI のように、ドメイン名(サービス名)以下に独自の体系であれば、一意識別は保証できる。
でも、利用者からみたら、同種のサービスは、同じ識別体系であるほうが、使いやすい。

妥当性検証


クレジットカード番号や、ISBN (本の国際識別番号体系)は、単純な連番ではない。
チェックデジットと言って、本体の番号を、一定のロジックで計算した、結果の数字を付加している。
登録データベースに問い合わせなくても、番号だけで、妥当性検証ができるようになっている。
---

とりとめなくなってきちゃったなあ。
とりあえず、識別キーネタ、ということで書いておきましょう。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM