要求の出し方

昨日の日記のコメントで、masakaさんより

とはいえ、国際化やローカライズ、あるいはある国でのみ重要な機器（たとえばAirH”）での不具合は、上記の方法だけでは開発者に理解してもらいづらい場合があるのも事実。そのあたりについても、答はないとしても、実体験にもとづいた話が聞けるとうれしい。前の日記では「自分で考えよう」でしたが。

というのをいただく。

ローカライズというか非常にスペシフィックなお願いというのはやっぱりなんだかんだ言っても個別なケースバイケースな話にならざるおえない。今でこそ、日本語化だ、ローカライズだ、国際化だということが海の向こうの人にも、一応、教養レベルの話としては伝わるのだけれど、10年前、20年前は、それこそ日本語には漢字というのがあって、平仮名がどーだとか、１バイトで文字は表現できなくて、最低２バイトは必要なんだ、あーだこーだというレベルの話からしなければいけない時代があった。そーゆー時代からの積み重ねでいけばある国特殊な事情についても一般的な解を必死になって見付けるというプロセスを経て、もちろんいろいろな試行錯誤を経て今にいたるつーことになる。

コミュニケーションなんだから、相手に、自分を理解してもらうことから始めないといけない。信頼にたる人間だということを認めてもらわないといけない。最初のボタンをかけ違うと後々大変になるので、最初が肝心だ。会社内でのコミュニケーションの場合は、会社の組織力学というか、各社の御作法にのっとって話を通しておくとか根回しをしておくとかが重要っちゃあ重要。外資系で日本法人から本社へ話を通すのも、その手のプロトコルが非常に重要。まあ、ここらへんは、大人の世界なので、日々勉強してほしい。

問題はオープンソースコミュニティの場合だ。自分は新参者である。どこの馬の骨だか分からないので、それを分かってもらう事からはじめないといけない。その道のプロの方とやりとるするのだから、それを尊重しつつ、自分の専門性(素人ではないということ)の証明をメールとかのやり取りでしないといけない。いや別に素人でもいいんだけど、素人は素人なりに等身大で自分を理解してもらう必要がある。

最初からすごいデカイ山を登るのではなく、今ここにある小さな山から登って行くという作戦をわれわれはSamba国際化プロジェクトでとった。余談になるけど、わたしが今ここで言っている事は、どこのプロジェクトにも適用可能だとか、もっとも有効な方法であるとか、そーゆー保証は一切なくて、たまたまわたしのやった経験によれば、こーゆーことをやったらこーゆー結果になった、という事例を述べているにすぎない。わたしのやった方法でやれば常に成功するとか失敗するとか言う事を言いたいのではなく、たまたま、ある条件である方法をとったらある結果になったというだけにしかすぎないので、読む人はそこらへんを十分咀嚼して自分のプロジェクトに当てはめるなり参考にするなり、しないなりしてほしい。

自分達の存在をアピールするために、まあ、いわば自己紹介がてらに、国際化にまつわるバグをせっせと報告しまくった。 id:hyoshiok:20041022
と同時にメーリングリストに、われわれが今やろうとしている事を宣言した。つまり、どーゆー問題があるかということを詳細に報告し、それを解決したいと言う事を宣言した。どんな問題を解きたいかという宣言で、それをどう解くかと言う事ではない事に注意してほしい。

われわれは多分問題をよく知っている。しかし解き方を一番良く知っているとは限らない。

DEC時代の尊敬するエンジニアのGayn Wintersは常に「問題を正しく理解しろ」と言っていた。問題を正しく理解することは難しい。本当に難しい。われわれはともすると、問題を理解する前に回答に飛びついてしまう。何が本当に問題なのか？徹底的に考えろとよく言っていた。

われわれは本当に問題を知っていたのであろうか？わたしの最初の問はそれであった。何をいまさら、Sambaの国際化には問題があるんでしょう、それを直すに決まっているじゃないですか？と返って来た。国際化ってなんなのよ？何が一体問題なのよ。そーゆーことを明示的に宣言したドキュメントってどこかにあるの？実に素朴な疑問である。少なくともわたしの満足するようなドキュメントは無かった。われわれは何を解こうとしているのか、それを定義する事からはじまった。そしてその問題をコミュニティに理解してもらうというチャレンジに挑戦した。

最初の一歩である。