ユーザー名に同姓同名をつける？つけない？

グループウェア調達のRFPを拝見させていただいていると、たまに、「同姓同名に対応していること」という項目に出会うことがある。それも、現在Notes/Dominoをご利用のお客様からのRFPに多い気がする。現状の同姓同名の運用がうまくいっていないというわけではないのだけれども、他のグループウェアを見ると、同性同名がつけられるので、もっと楽に同姓同名への対応が出来るのではないか、という思いからRFPに反映されているように見受けられる。

Notes/Dominoでは、ユーザー名に同姓同名をつけることができない。それは、ユーザー名は、メールアドレスとして使われるだけでなく、文書の作成者として見えたり、データベースや文書のアクセス制御に設定されたりするので、ユーザー名の重複を許可していない。「ユーザー名 = ユニークID」という考え方だ。

それに対して、同姓同名に対応しているという他のグループウェアは、システムの内部的にユニークIDを持ちつつ、それに紐付けてユーザー名を設定する方法を取っている。文字通り、ユニークIDでユニーク性を担保しているので、同姓同名がつけられる。

実は最近、社内で同姓同名対応の話が話に上がって、このブログにたまに出てくるノーツの守護神の意見がなるほどと思ったので、このエントリを書いてみた。守護神のお声と僕の意見を交え、同姓同名の実装を検討する際の検討点を以下に挙げてみる。

1.見て誰だか分かるか
同姓同名があると、メールアドレスの選択時に宛先間違いが起こる可能性が大きくなる。基本的には、ユニークIDを見なければ、ユーザーをユニークに特定することが出来ないが、ユニークIDとユーザー名が別々の場合は、エンドユーザーにはそれは不可能だ。宛先間違いは、情報漏洩につながることがあるので、非常にクリティカルな問題である。また、システム管理者やアプリ開発者としても、ACLに埋め込まれたIDを見て、ユーザーを判別できるほうが運用・開発の効率は良い。つまり、可読性の問題ということだ。Notes/Dominoは、可読性を重視したシステムということが言える。

2.ユーザーを誤って削除した場合の対応
ユーザーのパスワード忘れなどで、ユーザーを再作成するしかない状況に追い込まれた場合の対応をどうするかという問題。「ユーザー名 not ユニークID」なシステムは、同じ名前で再作成しても、ユニークIDが違うのでそれは別人。今までアクセスできていたものはアクセスできなくなる。一旦削除してから新たに作成する対応が必要だ。Notes/Dominoの場合、基本的に再作成で対応できるが、ユーザーIDで暗号化されたコンテンツは復旧不可能になる。まぁ、どちらのタイプのシステムも、誤削除への対応はそれなりにリスクがある。セキュリティにかかわる部分だけに、これは致し方のないところだろう。問題は、ID誤削除を想定した対応が出来ているかというところにあると思う。Notes/Dominoの場合は、R5のころからユーザーIDリカバリー機能が提供されており、最新バージョンの8.5では、IDボールとという機能で、使いやすさ、セキュリティ面の両方のバランスを取った方法が提供されている。

3.結婚などで名前を変更する場合の対応
これは、「ユーザー名 not ユニークID」なシステムに軍配が上がりそうだ。「ユーザー名 = ユニークID」なシステムの場合は、システム内に存在するユーザーIDを変更する仕組みが提供されているかどうかがポイントとなる。Notes/Dominoの場合は、システム管理プロセスという機能が大昔から提供されており、変更作業は自動化されている。

こう見ていくと、一番重要なのは1番の可読性の問題ではないだろうか。他人の芝が青く見えることは良く分かる。しかし、同姓同名をRFPに挙げるなら、むしろ、「同姓同名を禁じられること」という項目にすべきだと思う。