パスワードを忘れた? アカウント作成
224084 story
インターネット

メールアドレスの命名規則にはどういうものがある? 110

ストーリー by soara
mr.smith@example.com 部門より

あるAnonymous Coward 曰く、

私の会社では「グループ会社すべてのメールアドレスのドメインを統一する」という方針になったようで、近々グループ会社数社のメールアドレス一斉変更が行われる予定。そのメールアドレスは

「名前イニシャル 1文字.名字.ランダム文字 2桁@example.com」

というルールで命名されるとのこと。

ランダム文字が入っているところにちょっと違和感がありますが、皆さんの会社ではメールアドレスの変な命名規則はありますか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by kousokubus (37099) on 2010年05月29日 9時10分 (#1771296)

    s.tanaka@とかが大量に発生して手に負えなくなるから

    知り合いのところは早いモノ順だったので、tanaka@、s.tanaka@、s.tanakaka@みたいな事になってて異様にめんどくさいとか
    # 偉い人と新人が1文字違いだと間違えて送りそうでほんとこまる:-(

    • マジで社内に n.sato@ と n-sato@ と n_sato@ があって、
      「メール送ったんですけど見てくれました?」「え?届かないんですけど」が
      頻発して参りました。配信エラーが出ないんですよね。
      メールアドレス変えてもいいって言うので、デスクの内線番号くっつけました。
      転勤したら番号だけ変えるかな?
      親コメント
    • ウチは[名前の頭文字 + 名字@~~~]です。
      山田太郎さんならTaroh Yamada=> tyamada@~~となる。

      ここで大きく二つの問題がでる。
      ①同姓同名や同姓で名前の頭文字がかぶる場合
       例えば、山田太郎と山田孝史だと、ルール通りならどちらもtyamada@となる。
       意外とかぶる人が多い。

      ②名前の読み間違いが出てくる。
       例えば、岡優子さんはyoka@~~となるので、
       メールアドレスから名前を想像すると[ヨカさん]かと思われる。
       大塚幸治ならkotsukaなので[コツカさん]とかね。
       大小入れ替わってるしwwとネタにされておいしい面もあるけど。

      ①の対策としては、後から入ってきてかぶる人は
      名前の部分を(ある程度)自由に調整できる。
      既に山田太郎がいて山田孝史が来た場合、孝史さんは
      tayamada@~~とかtakayamada@~~とする。
      それでもかぶったりややこしいので結局アドレスだけでは判別出来ないんですよね。

      ②の場合はどうしようも無いので
      上記の例では「ヨカさんいますか?」と電話がかかってきたら岡さんに転送し、
      「先方、メールアドレスから名前間違えてヨカさんと思っていますよ」と先に教えてあげる。
      口頭でアドレスを教える場合は
      「岡のアドレスはワイ、オー、ケー、エー、アットマーク~~で、[ヨカ]と読めるようになります。
       これは岡の[oka]の前に優子の[y]が入っているので[ワイ-オカ]と覚えて下さい」
      と長ったらしい説明になる。

      ちなみに名字の先頭が母音であったりYで始まっても面白い。
      安宅充さんならmatakaでマタカさん、山田直樹さんならnyamadaでニャマダさん・・・。

      もうね。面倒だわ。

      親コメント
    • シリアルな数字ならよくありそうな気がするけど、ランダムな文字ってのは珍しいかも。

      ここはひとつ
      s.tanakaZZ@ とか
      s.tanakaDX@ とか
      s.tanakaKY@ とか
      s.tanaka!?@ とか
      「どう見てもランダムじゃねえだろ」ってアドレスから割り当てていって欲しいものです。

      親コメント
      • by Anonymous Coward on 2010年05月29日 10時39分 (#1771333)
        s.tanaka@ とか
        s.tanakaZ@ とか
        s.tanakaZZ@ とか
        s.tanakaS@ とか
        s.tanakaSD@ とか

        >「どう見てもランダムじゃねえだろ」

        「どう見てもガ(以下略
        親コメント
      • ランダムじゃないと偉い人が怒るんじゃないかな。「なぜおれが23なのだ!」とか。
        あと、命名時にランダムだと割り当てを同時に進めてもかぶる可能性が低い。
        # でもZZは羨ましいな。

        そういや大抵降り直しって、転送メールアドレスでなんとかしませんか。
        うちはそうだった……そして古いアドレスでも届いたりしてめんどくささが倍増した……

        親コメント
        • by ogino (1668) on 2010年05月29日 19時18分 (#1771556) 日記

          そういや大抵降り直しって、転送メールアドレスでなんとかしませんか。
          うちはそうだった……そして古いアドレスでも届いたりしてめんどくささが倍増した……

          • 宛先としての古いアドレスは転送する
          • 差出人アドレスが古いアドレス(ドメイン)のものは全部拒否 "v=spf1 -all"

          としたら迷惑メールがごっそり減りました。自分宛を装った Return-Path: というのは結構な割り合いを占めるようです。

          親コメント
      • 母校の新メールアドレスは,(名前イニシャル1文字).(名字).(アルファベット2文字)@ドメインだったのだが,アルファベット2文字がaa,ab,ac,ad...と続くタイプだったなあ.この方式でZZにたどり着くのはいつの時代になることやら.

        しかし,AAに変な意味を読み取る文化だったので,メールアドレスに軒並みその文字がつく状況に苦笑してしまった

        親コメント
  • by NOBAX (21937) on 2010年05月29日 9時40分 (#1771303)
    >名前イニシャル 1文字.名字.ランダム文字 2桁

    これは整理するときに困るんだよね。
    苗字は知っていても、名前なんか知らないことが多い。
    鈴木課長、山田主任とか。
    だから

    苗字-名前イニシャル 2文字.数字2桁

    などでお願いしたい。

    実は、最近はメルアドを直接見ることは少ないんで
    どうでもいいのですが。
    • 今年の春の発行分から、フルでの「(姓).(名)」 に変わった。
      以前までは、「(イニシャル)(ランダム数字).(名字)」 だったので、
      サーバ管理してると、下の名前がわからなくで困った。

      ので、自分で提案してルールを変えさせた(^^;

      古参は、短いアドレスのままの人が多いねぇ。

      でも、すでにランダム数字が入っている人はそのままなので、
      探しにくさはあまり改善されていないともう一人の管理者にいわれた。

      親コメント
  • エラい順に (スコア:3, 興味深い)

    by elderwand (34630) on 2010年05月29日 9時33分 (#1771300) 日記

    割り当てる [srad.jp]だと、どうなるんだろう?

    #うちの事務方は j03 (人事) とか k02 (経理) とか使ってます。
    #個人じゃなくてグループアドレスですけどね。

  • by saratoga (23467) on 2010年05月30日 13時53分 (#1771751) 日記
    古くは、ユーザIDも、ドメイン名もアルファベット3文字が普通で、くそ長いのはカッコ悪いという風潮がありました。
    #rmsとか、今でもかっこいいと感じます。
    たぶん会社名、大学名が、3,4文字というといのが多かったからでしょうか。decとか、sunとか、mitとか、lvlとか。

    国内でも創世記は、短い名前が多かったです(例えば、村井純氏は、いまでも jun@wide.ad.jpみたいですね)。
    ところが、どんどん衝突が増えて、ファーストネーム頭文字1文字+ファミリーネームというのがほとんどになりました。
    このとき間に "."や"_"ははさまないので、この時代、ア行ではじまる人は、子音をくっつけて別の名前で呼ばれていました。
    名前の衝突は、@より後ろのドメイン名で(学科や研究室や部署略称とか)なんとかしのいでいたように思います。
    この時代は分散管理状態だったので管理規模も小さく、ドメインごとにちゃんとやっていれば特に問題もありませんでした。

    さらに時代は進んで、ちゃんとできないドメインがあるかぎり電子メールが基幹業務に使えない!、IT管理業務をアウトソースしてしまえ!
    という時代が来ると、全社一元管理ということになるのですが、なぜかドメイン名も全社一緒にしましょうということになって、
    衝突回避の役割を担っていたサブドメインが全廃されてしまいました。つまり、ユーザID部分だけで、全組織にわたってユニークにする
    必要が出てきました。結果として親からもらった名前に勝手に数字やアルファベットをつけられるという自体が起こったのです。

    どうせやるなら、人の名前をいじらずに、ドメイン部で吸収してあげた方が、「人を人として扱ってる」感じがしてよいと
    思うのですが、当時のSI'erには、そういう人間味もなければ、バーチャルなドメインを運用する技量もなかったのでしょうね。
  • 名残 (スコア:2, 興味深い)

    by Anonymous Coward on 2010年05月29日 9時39分 (#1771302)

    混在してます
    1.明らかに本名じゃない → 古参
    2.苗字そのまま → 比較的新参
    3.苗字+名前の一部 → 誰かとかぶった新参

    ルールなき時代の名残がおもしろい。

    • ローマ字変換表 (スコア:2, 参考になる)

      by Rodin (28411) on 2010年05月29日 15時12分 (#1771466)
      し → si、じ → zi、ち → ti、つ → tu、ふ → hu
      しゃ → sya、しゅ → syu、しょ → syo、・・・

      まっ間違えたんじゃないからねっ! 短い方が入力が楽なんだからねっ!
      [ち][し][つ]の人はそう言えます。

      のばす発音をどう表記するかも問題。
      先輩の大野さんがonoを使い、後輩の小野さんが困るケースも。
      --
      匠気だけでは商機なく、正気なだけでは勝機なし。
      親コメント
  • 他の人も指摘してますが、
    イニシャルのみで命名すると誤送や重複など様々な問題が発生しやすくなりますので、
    フルネーム+ランダムで3桁ぐらいの数字を追加するぐらいした方が良いと思います
    • フルネームだと、知人や親戚が会社宛にメールアドレスを推測して送りやすくなるというのはありますね。
      一見良さそうなルールですが、SPAMも受け取りやすくなり、個人情報保護法に厳密な会社だったりすると嫌がります。
      ランダムな文字を加えるというのは、折衷案としてはまあ妥当かもしれません。
      親コメント
    • by Anonymous Coward on 2010年05月29日 10時25分 (#1771323)
      前の会社はフルネーム+2文字ランダムだったんですが、自分と同姓同名の人がいて(結構えらい人)、
      たまに間違って僕のところに配信されてきてましたね。
      何かの依頼に対する催促のメールとか、予算の許可を求めるメールとか、年1,2回のペースでありました。
      フルネームの場合、アドレス検索するときに、名前部分が一致しちゃうとそれ以上確認しない人が結構いると思います。
      イニシャルなら・・・ってまぁ一緒か。

      個人的には、内部的なメールアドレスはフルネーム+ランダム文字列とかでいいですが、エイリアスで普段使いたいアドレスを
      別に登録できるようにしてくれるといいんですがね。
      親コメント
    • 前の会社では「姓.名@会社ドメイン」でした。というか、そういうルールを私が作りました。それまではメジャーな姓の方々のアドレスがカオスでした。名の後に社員番号も入れればベストだったかな。

      --
      May the music be with you.
      親コメント
  • by Anonymous Coward on 2010年05月29日 20時13分 (#1771572)

    いろいろ見て、つぎのルールなら便利で安全かなと思った

    1.本当のメールアドレスは社員IDベース
      Axxxxxx@example.comとか

    2.このアドレスへ転送できるID名を申請できる
      申請ルールは
        * 本名ベース
              同じ表記でぶつかる場合は追加文字を付けることで調整するなど
        * 会社が許すなら自由
      とか
      面倒なら社員IDのままでいい

    3.申請IDつくったら、実際に社外でのやりとりはそれのみ(社員IDは使わない)

    4.どちらのIDも退社後は管理部へ転送になる

    5.退社後x年たったら
        社員IDのメール:Reject
        申請ID:再申請可能になる

    とかどうだろう

    まー、そこまで会社寿命とメールというシステムの寿命が長くないかもしれないが
    どっかでリセットできないと、名前空間使いきりそうだしなぁ

  • 以前の職場ですが、 個人名を表す英字4文字会社コード5桁社員コード5桁@親会社ドメイン という、
    「もうちょっと何とかならんか」という物でした(abcd1234512345@example.co.jp)。
    しかも、導入初期は頭の4文字にルールが無く(本人に決めさせていた)、てんでバラバラでした。
    後になって、姓の子音に統一された様ですが。

    今の職場は 名.姓.所属@会社ドメイン なので、まぁ普通かと。

  • 私の所属する組織でも最近メールシステムの統合などということが行われていまして、
    その規則は「名.姓.ランダム2文字@組織全体で同じ」となってしまいました。
    例えば living.dead.pq@example.com のようなものです。
    最後の二文字がどのように決められるのかは知らされていません。

    最後の二文字、やっぱり気持ち悪いなぁ。
    アルファベットだと同姓同名も結構な確率で存在するので、
    悩ましいところです。

    --
    屍体メモ [windy.cx]
    • 姓+名+かぶったら数字つける@全社同じ
      だった。
      俺はよくある名前なのでyamada.tarou003@fuga.hoge.comだった。
      3人もいたのかよ。
      親コメント
      • グループ全体のディレクトリサーバをひいてみても同じ姓名(のアルファベット綴り)の人がいないのにもかかわらず
        はじめっからランダムな2文字っぽいものが付与されている作業場所があったなあ。某大手。
        名前協働者や参画プロジェクトメンバなど作業場をともにする者に一時的泡沫的に割り当てるメイルアドレスも
        同じ規則に則らせるという場合、同じ名前の人が参画退場を繰り返す場合もランダム2文字(あるいはそれ相当)が
        増えていくだろうから。名寄せの更新間隔は1年に一度とかだと使われていないアドレスが一時的に増える側に傾く。
        親コメント
  • first.last@example.com (スコア:1, 参考になる)

    by Anonymous Coward on 2010年05月29日 10時40分 (#1771335)
    first.lastが基本で、かぶった場合はfirst.m.lastかfirst.middle.lastにする。
    日本人はmiddleがないので、てきとーにイニシャルをでっちあげる。
    Ichiro.R.Tanakaみたいに。(違
    よその会社見てても外国の会社はたいていそうなってる。

    某邦銀と一緒になった某証券は、所属によってドメイン名が
    いくつにもわかれて、もう意味不明。

    10年位前は"."より"_"のほうが主流でしたがいつの間にか"_"は
    見なくなりましたね。"-"と紛らわしいからかな。
  • by mksr2005 (32864) on 2010年05月29日 11時35分 (#1771374)

    姓-名-数値@ドメイン です。

    同姓同名があると数値が増えていく模様。ほとんどの人は1です。
    ディレクトリで検索してみると同姓同名がいないのに3となっている人がいました。
    なんでだろう?

  • 不要 (スコア:1, 興味深い)

    by Anonymous Coward on 2010年05月30日 4時05分 (#1771674)
    命名規則なんて不要。うちは1万人規模の会社だけど、基本は名前ベースのIDを使ってる。
    私みたいにファーストネームそのままの人もいるし、ファースト一文字+ラストネームの人もいるし、まったく名前とは関係ないIDの人もいる。

    大事なのは、ドットやアンダースコアを使わないこと。あくまで文字列のみ。こうすることで、unixアカウントやwindowsアカウントのIDとして流用できる。
typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...