同じ姓と名を持つ人々に最適な電子メールアドレス形式は何ですか？
組織（会社や教育機関など）が大きいほど、同じ名前の人が2人いる可能性が高くなります。
通常、メールアドレスは[email protected]
同じ名前の2人のユーザーがいる場合に、間違った人にメールを送信するリスクを最小限に抑えるために、電子メールアドレスの形式はどのようにすべきですか？
私は見た：
firstname.middleinitial(s)[email protected]
[email protected]
[email protected]
[email protected]
編集：もう1つの考慮事項は、この形式が社内外の人々のために機能することです。
同じ会社で働いている人は電子メールディレクトリにアクセスでき、その人の場所や部署は知っているかもしれませんが、社外の人は知りません。
編集2：これは、定期的にユーザーを循環するドメインの一般的な問題でもあります。たとえば、一般的なユーザーが3年間または4年間だけメールを使用し、その後卒業する場合は、大学や大学などです。去る。電子メールをリサイクルしないことを選択した場合、毎年参加/脱退する同様の名前を持つ人々が無制限に集まる可能性があります。
あなたの質問は、電子メールの送信者が目的の受信者の電子メールアドレスを覚えている必要があるか、または目的の受信者の電子メールアドレスを正確にリバースエンジニアリングする必要があると想定しているようです。また、メールアドレスは会社全体で単一の形式である必要があると想定しているようです。
回答は、意図した受信者と電子メールアドレスの形式の両方についての情報を知っている送信者に依存しているため、解決策を作りすぎると思います。ある時点で名前の衝突が発生することは事実上保証されていますが、最終的な名前の衝突を回避するために単一のソリューションを設計することは多大な労力であり、非常に少ない見返りと多くの潜在的な欠点があります。他の場所で指摘されているように、代替手段のほとんどは、ユーザーがメールを送信している人についてかなり多くを知っている必要があります。
代わりに、電子メールアドレスをより実用的にすることができます。 firstname.lastnameのような基本的な形式を使用し、電子メールアドレスに数字を追加するだけで問題を解決できます。この場合、ユーザーに自分の記憶に依存するよう依頼する代わりに、ソリューションを設計して、ユーザーがメールを送信する正しい受信者を認識できるようにすることができます。同じ会社で働いている送信者は、社内ディレクトリを使用して適切なメールアドレスを検索できます。社内ディレクトリを使用すると、電子メールの送信者となる人が意図した受信者について覚えている内容に間違いが生じるだけでなく、あいまいさが増します。たとえば、人々は私の名前を覚えていることが多いですが、スペルが間違っていることがよくあります。私の社内ディレクトリには、私の正しいスペルと、頻繁に使用されますが、ナディーンのスペルの両方が私の名前に関連付けられています。企業ディレクトリの私のエントリにより、他のメタデータを使用して他のメタデータを使用しているユーザーを見つけることができます。会社にいないユーザーの場合は、個人の名刺を見るか、個人が送信した電子メールの返信を押します。もちろん、リバースエンジニアリングを試みることもできますが、企業ディレクトリの代わりに優れた検索エンジンを探すこともできます。
どちらの場合も、送信者の実際の目標を満たすソリューションを設計しています。送信者はメールアドレスの形式を気にしません。送信者は、目的の受信者にのみ連絡したい。コミュニケーションが目標です。電子メールアドレスの形式など、通信の仕組みは目標ではありません。
Firstname.lastname（または同様の）形式を使用しても、名前の衝突の可能性を最小限に抑えるいくつかの方法があります。たとえば、代替名をサポートすると役立ちます。サミュエルまたはサマンサがサムのそばにいる場合、代わりにサム。姓を割り当てることができます。
また、指定された名前付けスキーマは最終的に失敗することにも注意してください。たとえば、私はファーストネームだけで生まれた人と仕事をしました。彼らは姓を持っていなかったし、私たちの雇用主が彼らを強制したので、彼らは確かに姓を引き受けたくなかった。
つまり、ユーザーの実際の目標に対してほとんどの時間機能するソリューションを設計し、必然的に発生するEdgeのケースに備えることができます。
ミドルネームは解決策を見つけるには不適切な方法である可能性があります
わかりました。地域固有のソリューションではなく、グローバルなソリューションを探しています。したがって、誰もがミドルネームを持っているわけではないことを理解しましょう。私はしません。そして、私は最後の会社で、組織内で同じ名前のこの問題に直面しました。 Amit Jainという名前の1人の人がすでに開発者として働いていて、emailId amit.jain @を持っていたので、私が参加したとき、私はamit.j @を獲得しました。とにかく、私はそれにいくつかの考えを与えました、そしてここにいくつかの意見があります。
1）Department suffixesは、一部の組織で機能するソリューションである可能性があります。したがって、たとえば、amitjain_ux @とamitjain_dev @を使用でき、その形式は2つの方法で役立ちます。 1つは、その人の役割をすばやく洞察することです。次に、（ほとんどの場合）競合を回避するのに役立ちます。
2）正当な理由により、部署/チームの接尾辞を提案しました。電子メールを送信し、「to」フィールドに電子メールIDを追加し始めたいとします。名前で開始し（通常のユーザーの動作）、オートコンプリートは2つのオプション（2つのサフィックス付き）を提供します。これにより、目的のものを簡単に選択できます。
3）極端なケースでは、同じチームに同じ名前の2人がいる場合-amitjain01_ux @とamitjain02_ux @を使用できます。
これが重複した姓と名を分離する「最良の」方法であるかどうかはわかりません。しかし、私たちは自分自身と私たちのユーザーに、名+姓が何を表すかを推論する必要があります。これらは個人の識別子です。つまり、メールアドレスに別の識別子を追加する必要があります。この識別子は、到達しようとする人に接続できるものである必要があります。
あなたのこぶしの提案は、ミドルネームのイニシャルでそれを扱います。問題は、最も近い同僚のミドルネームを知らないことが多いことです。特に会ったことのない人は特にそうではありません。したがって、これはうまく機能しません。
2番目の提案（乱数）も識別子として使用できません。
イニシャル+姓を使用する3番目の提案も、私たちには何の役にも立ちません。ポイント1を参照してください。
ランダムな文字列を使用します。これについてはコメントしません;）
したがって、これらすべてが失敗します。ただし、ユーザーについては、あまり変更されないことがわかっていることがあります。場所は通常、時間の試練に耐える固定パラメータです。大企業は2〜3年ごとに再編成する悪名高いサイクルを持っているため、最終的には変更される肩書きよりもはるかに優れています。つまり、肩書きも変更され、電子メールアドレス識別子が再び失敗します。しかし、場所はしばしば同じものです。それはすべての永続的なものではありませんが、私たちが持っている中で最高です。
したがって、これが[email protected]の使用の結論につながります。
これは特定の場所にあるため、意図的に場所を指定しませんでした。同じ都市の異なるサイト、同じサイトの異なる建物、または会社の場所に応じて異なる都市を使用できます。
tl; dr
[email protected]はユーザーに最適です。[email protected]はより多くのバリエーションを提供し、覚えやすいです。[email protected]覚えやすさのトレードのために、より多くのバリエーションを購入します。任意の意味のある名前のバリエーションを追加できます：
jimmyまたはjjの代わりにjames=。
また、可能な場合は複雑さを徐々に追加して、不要な混乱を回避できます。このシステムの最も重要な機能：
メールIDは、システムコードではなく個人情報に基づいています。一意性は常に覚えやすいとは限りません。
名前を学ぶことは良いことです。
考えられるすべての解決策の中で、私は本名が個人間の組織識別の最良の形式だと思います（これは本質的に私たちにとって電子メールアドレスが行うことです）。人について最初に学ぶのはその人の名前であり、知らない場合は連絡を取るべきではありません。ですから、本当の名前が良いことに同意することができますね？
一方、GUIDなどの数値は、プログラムではるかにスケーラブルです。 IDが不足することはなく、個人に関する一時的な可能性のある事実とは関係ありません。しかし、他の人のことを覚えておくのは無意味です。
名前に追加されたシステム生成の短い番号はどうですか？それでも、ユーザーが別のユーザーについて知る必要はありません。多分彼らのオフィスの電話内線または携帯電話番号？最近、電話番号の電話番号はありません！
では、選択肢を使い果たすことなく、お互いの名前を使用できるようにするにはどうすればよいでしょうか。
満たすべき条件を見てみましょう。
1.かなりユニーク
あなたが大企業なら、これは挑戦です。名前だけでは十分な一意のバリエーションが提供されない場合があります。
企業がf.m.lastを回避しようとしているのを見てきましたが、実際には人間のメモリ負荷を節約できず、固有のオプションが不足する可能性が高くなります。
平均的な組織では、first.m.lastはかなりしっかりしています。これらの3つのデータには、可能性のある多くのバリエーションがあります。ただし、そのようなIDが不足する可能性があります。他の要件を検討した後で、そのことに戻りましょう。
2.確実に一定
名前は堅実ではありませんが、比較的一定しています。そして、彼らが変わるとき、組織のメンバーはおそらくそれを知って、それを学ぶべきです。
システムで生成された数値は非常に一定ですが、なぜそれが学習する価値がないのかについてはすでに説明しました。
（ベニーが述べたように）場所は検討に値しますが、組織はオフィスを移動、拡張、または統合し、リモートの従業員を支持するか、少なくとも手を出してしまう可能性があります。これらの要因を考慮すると、場所を信頼するのは難しい場合があります。
これらの目的のために、名前は定数で十分のようです。
3.人間が学習可能
名前は誰にとっても覚えるのが最も簡単なものではありませんが、他の人とコミュニケーションをとるのであれば、知っておくべきデータです 。そして、発生する可能性が高い一連の名前の中には、他の多くの固有のデータよりも学習しやすくする、よく知られたパターンがたくさんあります。
一意性の保護
全体として、私はfirst.m.lastについてかなり良い気分です...しかし、フォールバックがあっても害はありません。
企業がfirst.m.last.2のようなインデックスを追加するのを見てきましたが、それは一種の侮辱ですよね。また、ユーザーがその名前の2番目のユーザーであることは特に意味がありません。
オプションが不足する状況を考えます。
組織ですでに働いている誰かが自分のIDを要求しています。
初心者が同じfirst.m.lastを搭載しています。
初心者は会社のために名前を変更する準備ができていません。
同僚の間でシステムとを区別する可能性が高いハードデータは何ですか？
私が検討した（ただし実装されていない）オプションは、採用年：first.m.last.2015です。同じ名前の人が2人いるかもしれませんが、同じ年に彼らが採用された可能性はほとんどありません。そして、それは覚えやすい数字であり、同僚について学ぶことは悪いことではありません。 「ええ、あなたは去年始めたばかりです...」または「私はあなたがここにどれくらい長くいるのか忘れてしまいました...」。
そのロジックを購入した場合、今度は全員のメールに年を追加する必要があるかどうかを尋ねる必要があります。このオプションは不愉快ですが、より一貫性があり公平です。個人的に、私はリスクを冒して、必要になるまでそれを止めます。
この返信は手に負えなくなりました。
（新しい）ユーザーが決定できるようにします。
新しいメンバーが組織または会社に参加します。人事部門はすでに通常の事務処理を行っています。つまり、ITには、すべての名前、生年月日などを含む個人のレコード（任意の一意の静的識別子キーの下）があることを意味します。半自動プロセスは、予備のユーザーアカウントと権限をセットアップします。彼らが初めてログインするとき、おそらくスーパーバイザーまたは管理者の前で、彼らは（おそらくとりわけ）名前に基づいて電子メールアドレスを選択するように求められます。後で簡単に変更できます。利用可能なデータに基づいて、いくつかのプリセットが表示されます。ローカルパートとして任意の文字列を取得する方法はありません。ニックネームはHRデータベース内に登録する必要があり、ディレクトリに表示されます。
例
ジョンジェイ博士が「ジョー」ドウIIIのとき。参加すると、彼はこれらのオプション（の一部）を提示されました：
john.doe@–これは、類似した名前を持つ誰かがすでに使用しているものである可能性が高いです。それ以外の場合は、あらかじめ選択されているデフォルトです。doe.john@–彼はハンガリー人の祖先を持っている可能性がありますが、この命令はおそらくネイティブのマーキンとして彼にとって異質であると感じています。john.doe.3@=john.doe3@–彼の最愛の祖父が亡くなって以来、この名前は家族の伝統であり、そのため一見恣意的な数字は彼にとって異質ではありません。j.doe@–彼の場合、イニシャルがファーストネームとミドルネームのどちらから始まっているのかは明らかではありません。姓があまり一般的でない限り、他の誰かと衝突する可能性は非常に高いです。j.j.doe@=jj.doe@–イニシャルはニックネームになることがあります。jay.doe@–ジョンは父親であり、家族の誰もがとにかく彼をミドルネームで呼んでいました。john.jay@–ミドルネームは、実際には他の親または配偶者の別の姓です。john.j.doe@–ミドルネームを使用してもかまいませんが、秘密を守りましょう。john.jay.doe@–彼のミドルネームは彼にとって重要であり、まったく恥ずかしくない。john-jay.doe@–彼のミドルネームは実際には2番目の名であるため、彼はすでに「John Jay」として知られています。john.jay-doe@–彼の両親は彼に彼らの両方の姓を彼に与えました、または彼は結婚時に彼の配偶者ジェーンの1つを追加しました。
joe.doe@–大学時代以来、彼はジョーと呼ばれていました。すでにジョンが多すぎたためです。実は空手教室で「ドジョエ」として始まりました。john."joe".doe@–はい、これは正当なローカルパーツですが、遅かれ早かれ問題が発生します。"joe"@–これも有効であり、（必ずしも）joe@と同等ではありません。
John Doeは1991年12月21日にテキサス州スモールビルで生まれたことがシステムで認識されていますが、プライバシー上の理由から、電子メールアドレスの作成にこれらのデータを使用することはできません。とアドレス（G-Mail、Yahoo、Hotmail、Facebookなどで）。
従業員が合法的に名前を変更したとき。彼らが結婚したり、離婚したり、性別を再割り当てしたり、養子になったとき、彼らは別のデフォルトの住所を選択するかもしれません。古いものは明示的なエイリアスになり、他の誰かに再割り当てされることはありません。
テクニカルノート
ローカル部分（アットマークの左側）は、次のようなほとんどの電子メールシステムで処理する必要があります。
- 明示的および暗黙的なエイリアスを持つ可能性がある正規の単一ケースのASCIIのみのバリアントがあります。いくつかの暗黙のエイリアスは次のとおりです。
- すべての単一ピリオド文字
.が両方から削除された後、同じローカル部分になる別の文字列。 （連続するドットはメールアドレスを無効にします。） - 有効な大文字小文字の折りたたみ後に同じローカル部分になる別の文字列。つまり、ローカル部分では大文字と小文字が区別されません。
- 文字変換スキームの後で同じローカル部分となる非ASCII文字の文字列。
- 通常のグリフバリアントと同じローカル部分のように見える可能性がある非ASCII文字の文字列。
- すべての単一ピリオド文字
- ローカル部分のすべての文字は、単一のスクリプトからのものでなければなりません。これには句読点文字は含まれません。
私は前の雇用主のために働いているときにこの問題を目撃しました。私が働いていた部署に同じ名前の人が2人いて、別の部署の人と同じ名前の人が2人いたため、部署のサフィックスについてここで人々が言ったことは、そこでは機能しなかったでしょう。
彼らはこれを回避しました：最も長くそこにいた人の[email protected]、次にfirstperson.surnameNUMBER @ company.com、NUMBERは2から始まり、誰かが同じ名前で新しい人が始まるたびに増加しました。
理想的ではないかもしれませんが、人々（ユーザーと顧客）は気にしていないようでした。
大企業で約30年間働いていて、別の会社に買収されて、クライアントのネットワークで私に電子メールアドレスが必要で、姓と名が共通していて、私はこれの犠牲になりました。
[email protected]、[email protected]、同僚は[email protected]、クライアント用のメールアカウントは[email protected]-その30年間、年に数回、社内のマークスチュワートのいずれか（通常はいつでも2つか3つのマーク）のメールを受け取ります。 -他の2つまたは3つのマークをコピーして、「マークスチュワートが間違っていると思います。私はxxxで働いています。」
私のキャリアのほとんどの場合、[email protected]不要な場合はミドルネームを省略し、同じ姓名を持つ2人目の人物が[email protected]。これは実際の答えではなく、むしろ私の経験の報告です。そして、国際組織に関して言えば、ファーストネームまたはミドルネーム、ラストネーム、または特定のラストネームを持たない従業員もいます（Ngが頭に浮かびます）。地域の人口。私の唯一の本当の答えは、外部ユーザーと内部ユーザーの両方を容易にするために、乱数サフィックスを避け、姓と名の部分的な組み合わせを避けることだと思います。また、「学部」は通常、一般的すぎるか、または主観的すぎて、あまり役に立たないという個人的な意見もあります。