i18n と l10n の狭間 [文化の違いを説明すること]

昔話のひとりごとです。
ソフトウェアの開発で、グローバルに、つまり世界中の言語で使えるように設計することを国際化 (internationalization = i18n)、それぞれの言語や文化に合わせてUIや仕様を変えることを地域化 (localization = l10n) なんて呼びます。このふたつ、並行して行われる作業だけど本質的には相反するもので、双方の利害がぶつかると経験的にはたいてい i18n が勝ちますね。
商用ソフトウェアでローカルの市場を担当していると、その市場向けの仕様をなんとかしてねじ込もうとして開発者に要求を出すと、i18n の錦の御旗の元に簡単に却下されちゃうことがよくありました。
実は却下される本当の理由は国際化とはあまり関係なくて、アメリカ人の開発者に日本の文化的背景に基づく日本固有の仕様を説明しても、なんでそんなものが必要なのか理解されないので優先度が低いんです。
そんなわけで、外資系ソフト会社の日本支社で日本市場向けのプロダクトマネージャーとかリエゾンみたいなことをやっていると、わりと日常的に日本の文化を予備知識のないガイジンに説明してなにかを説得することになります。
例えば、グループウェアで使うディレクトリ（ユーザー一覧の社内アドレス帳みたいなものと思ってください）を典型的な日本の大企業向けにカリカリにローカライズしたいときの説明。

アメリカの会社、特にソフトウェア会社みたいなフラットな組織の人たちにとっては、社内アドレス帳なんて名前とメールアドレスと電話番号ぐらいがアルファベット順に並んでいれば事足りるもので、せいぜい First Name でソートするか Last Name でソートするかのオプションぐらいあれば十分です。実際、グループウェアのディレクトリとか国際的なメールソフトのアドレス帳はそんな UI ですね。
ところが、日本の大きな会社の紙の社内電話帳を見るとまず組織ごとに分かれていて（組織ごとにグルーピングしなければ）、ナントカ本部の中に部が分かれていて、部の中が課に分かれていて（組織構造の階層は柔軟に）、課の中は課長さんを筆頭に課長補佐さんとか役付きの人の名前が先に来て（役職のフィールドを作ってそれでソートしなくては）、その他の課員は入社年次の順番にソートされていて（入社年次のフィールドもいるぞ）、女性社員には下線が引いて区別されていたり（性別も入力できるようにしなくちゃ）します。
アメリカの会社だと、社員の誰かを特定するとき、例えば

A: Did you talk to John?
B: John who?
A: John Doe. International Marketing.

てな具合に、下の名前、上の名前、そのあとせいぜい所属部署名とか勤務地あたりという風に絞っていくけど、日本の会社だと

ほら、国内営業本部のオオカワ部長のところにいる、ウチのサトウ君と同期の女性、誰だっけ？彼女に話しといてよ。

みたいに組織からドリルダウンするケースがわりと普通で、日本の内線表はそういう思考パターンに適したレイアウトになっているんですけど、これが「普通」だというのは、アメリカの人にはまず理解できない。
で、これをいちいち説明しようと思ったら、日本ではGiven NameではなくてFamily Nameで呼ぶこと、名前は漢字とかなで表記するが、文字コード順でソートしたら辞書の順番にならないので、読みのデータを別に入れてそれでソートしないといけないこと、というあたりから始まって、日本の会社組織の典型的な構造がどうなっているかを説明して、社員はどこの部署に所属している誰々という風に組織に紐付いて認識されることが多いことを理解してもらい、日本のカイシャでは新卒社員はみんな同じ日に入社するしきたりがあって、同じ年に入社した人たちは「ドウキ」と呼ばれて横にひとからげにされることや、果ては雇用機会均等法以前の一般職と総合職について説明した上で、男女を識別して表示しても必ずしも性差別としてダイバシティプログラムとかの問題にハッテンするわけではないことなどを教えて、ようやく理屈の上では納得されるという手順を踏むことになります（もちろん、こんな仕様を「国際化」したコアのプログラムに入れるのはナンセンスなので、ローカルで独自のソリューションを作れるように必要最低限の部分をコアに入れてもらうわけだけど）。
ことほど左様に、文化の違いを本質的にどこが違うのかを識別したうえでロジックに落として、異文化の相手に分かるように説明するのは、けっこう面倒な作業なのだけど、ソフトウェアとかWebのサービスが国際化されればされるほど、丁寧なローカライズが大切になってきていると思うのですよ。誰とはなく。