国際プロジェクト初体験を聞かせて! 101
ストーリー by soara
あるAnonymous Coward 曰く、
オープンソースソフトウェア開発プロジェクトのなかには、いろんな国の人々が協力しあう国際的なプロジェクトがたくさんあります。むしろ、世界の主要なプロジェクトは国際的なものがほとんどかもしれません。これら国際的なプロジェクトでは英語が公用語として用いられるため、英語で説明・論戦・説得・理解・合意などを行うスキルが要求されます。
しかし、ネット環境や活動の場が急速にグローバル化しても、一方で日本人は英語が下手だ(と思っている)し、それが簡単に解消するわけではありません。国際的なプロジェクトへの参加は、多くの日本人にとってかなり抵抗感が大きいのではないかと思います。
先日のRubyやNucleus CMSプロジェクトの例にもあるように、プロジェクトを国際化することはさらなる飛躍の可能性を意味するものの、現実には「言葉の壁」を越えることは難しいということも起こっています。また、オープンソースに興味はあるけど英語はちょっと...と思っている人もいらっしゃるのではないかと思います。英語のせいでオープンソースに参加できないでいる人がいるとしたら、それはオープンソースにとって損失です。
/.Jには、国際的なオープンソースプロジェクトで活躍されている(いた)人もいらっしゃるのではないかと思います。英語での議論は予想通りあるいは予想以上に大変でしょうか? 困難をどう克服したのでしょうか? 日本人にとって英語は永遠の課題なのでしょうか? それとも「案ずるより産むが易し」なのでしょうか? 皆様の国際プロジェクト参加初体験をお聞かせいただければ、オープンソースの将来を担うアレゲ予備軍の人々の役に立つのではないかと思います。
TOMOYO Linuxの場合 (スコア:3, 参考になる)
/.Jには、国際的なオープンソースプロジェクトで活躍されている(いた)人もいらっしゃるのではないかと思います。英語での議論は予想通りあるいは予想以上に大変でしょうか? 困難をどう克服したのでしょうか? 日本人にとって英語は永遠の課題なのでしょうか? それとも「案ずるより産むが易し」なのでしょうか? 皆様の国際プロジェクト参加初体験をお聞かせいただければ、オープンソースの将来を担うアレゲ予備軍の人々の役に立つのではないかと思います。
TOMOYOは、SF.jpのプロジェクトとして発足して、今もSF.jpで活動しています。プロジェクトの発足から、メインライン（Linux標準への提案活動）までの歩みについて、下記の資料で参照できます。
TOMOYOは、もともとは「日本で開発したものだから、日本で使ってもらえば良い」と思っており、「国際化」は全く考えてなかったのですが、CELinux ForumやYLUGなどで「Linuxの開発成果はメインラインにすべき（しろ、ごるぁ）」というご意見をいただき、そこから急遽「国際化」である「メインライン化」を目指したという経緯です。
もともと国際化を意識していたわけではないので、「メインライン」という言葉も知らなければ、当時のLinuxの主要な会議である「Ottawa Linux Symposium」について名前すら知らないし、開発メーリングリストであるLKML (Linux Kernel Mailing List)も購読していないというかなりオワタ的な状態からスタートしました。語学（英語）的な課題について振り返るとき、個人的には「最初に何をどう発言（提案）すれば良いのかわからない」が一番悩んだところです。他の方のコメントで「半年ROMれ」というのがありますが、開発にかかわらず新しい世界と交流をしようとするとき、「どんな人たちがいるか」「どんなふうに話をすれば良いか」「どんな（暗黙の）ルール、あるいは文化があるか」がわからないと、発言はできません。まず、その世界を知る、知ろうとする努力が欠かせないと思います。始めてしまえば（交流が始まれば）なんとかなるのですが、最初の合流、最初の提案が、難しい、そう思います。
ということがあったので、TOMOYOの最初の提案からメインラインにマージされるまでの全提案とそのスレッドを他の人があとから読んで参考にできるようにしています（実際、読む人がいるかはわかりませんが）。それを含め、LKMLにおけるやりとりからの教訓を読みやすい形で、Japan Linux Symposium 2009で発表しています。
Linux開発における語学（英語）の重要性についてですが、自分の経験からは、「発音や文法が多少おかしくても通じる」ので、「とにかく伝えたいことを伝える」ことが大切だと思います。日本人には「英語が弱い」という人種的？コンプレックスがありますが、英語が弱いのは日本人だけではありません（笑）。Linux界隈のネイティブの人は細かいことはいいから、主張を説明して欲しいという視点で待っているので、「これ正しいかな？」とか「伝わるかな？」とかはあまり気にしないほうが良いです。
「国際化」についてですが、実は世界はもともと国際化しているわけで、要は視点や活動範囲を自分が制限するかどうかだと思います。知らない世界や英語がメインのコミュニティと交流することは大変といえば大変ですし、疲れるといえば疲れますが、視野が広がり経験が増えます。物理的には日本という国にいても、気持ちや活動内容では、自由に世界と交流ができます。すべてがうまくいくわけはなく、時には挫折や失敗もありますし、行き詰まることもあるでしょう（TOMOYOも実際そうでした）。でも、そこには確かにそこにしかない喜びがあります。多くの人に勇気をもって踏み出して欲しい、そう思います。
tsh
Re:TOMOYO Linuxの場合 (スコア:3, 興味深い)
Linuxカーネルの話ですから、そんじょそこらのプロジェクトとは異なり、流れるメールの量も半端じゃないと 想像します。それを読みこなした上で、さらに自分から情報発信するのですから、英語だけでも大変だと思います。
LKMLのトラフィックは相当なものですが、通常は、関連する話題や投稿者の発言をフィルタして追いかけたり（私はGmailアカウントでTOMOYOを含むようなメッセージ以外はアーカイブにしています）、あるいは自分が投稿したメッセージの反響をモニターする（スレッド表示が不可欠でThunderbirdを使っています）などしていることが多いのではないかと思います。そのようにすると、「数」としてはそんなに多くありません。
「情報発信」のほうは、メーリングリストへの投稿や会議での発表などがありますが、元メッセージに書いたように経験がないと、何をどう書いたら良いか悩みます。メーリングリストごとの雰囲気をつかみ、「どんな人がいるのか」などをつかむには、メッセージアーカイブを読めば良いのですが、よく知っている内容や興味あるものでなければ「言うは易く」、で結構つらいと思います。とりあえず購読して、日々のメッセージを眺めながら必要に応じてアーカイブを参照するのが現実的です。会議の発表のほうは、「郷に入れば郷に従え」ではないですが、発表しようとする会議の過去の資料を参考にしながら考えるしかありません。ある程度目を通すと、おおよそのイメージがわいてきますが、「日本語で書いた資料を英訳する」というよりは、「最初から英語で考える」ほうが良いと思います。とか偉そうに書いていますが、最初にオタワで発表をしたときには、どうしても何をどう書けば良いか考えがまとまらず、手ぶらで現地入りするという恐ろしい経験をしてしまいました。今思い出しても冷や汗ものです。
「英語だけでも大変」は、否定しません。読むのも書くのも、日本語よりはるかに時間がかかりますし、英語での発表と質疑対応の難易度は高いです。ただ、「やりたいこと」あるいは「伝えたいこと」があれば、時間がかかったり思うように伝えられなくても道は開けると思います。よく「語学で上達するには、外国人の恋人を作ること」と言われますが、それと同じように自分が書いたコードや考えを知って欲しいという思い、自分のプロジェクトを知って欲しいという思いがあれば、進んでいけます。最後は情熱であり意地です。昔、聞いた話ですが、ある女性が海外に出かけてトラブルに巻き込まれたそうです。その女性は語学は強くなかったのですが、非常に頭にきて日本語でどなって文句を言っていたら、それが「なんとなく」通じて対応してもらえたという話です。その話が実話かどうかわかりませんが、そうしたことは本当にあってもおかしくないと思います。外国の人が話す片言の日本語を私たちが理解しようとするように、外国の人も私たちの話すことを理解しようとしてくれます。うまく話せるに超したことはありませんが、「伝えよう」という気持ちさえ忘れなければ伝わります。
tsh
下手な英語の生兵法は命取り (スコア:2, 興味深い)
送った時は全く気付かず、相手が怒り出して周りからも激しく批判されてから、自分のメールを辞書片手に読み直してようやく気付いたんですけどね。
慌てて誤解だと弁解したものの、もう何を言っても聞き入れてもらえませんでした。
最近よくある「下手な英語でいいから堂々と発信しろ」みたいな主張は全くの嘘っぱちだと思ってます。下手な英語は時に議論の流れも、和やかな雰囲気も、自分の立場すらも破壊することを身に染みてますから。
正しい英語を完璧に使えない人間は、安易に英語で発信すべきではないですよ。相手にとっても失礼や迷惑になりかねないので。
Re:下手な英語の生兵法は命取り (スコア:5, 参考になる)
私が最初に参加した、比較的有名な世界的といえるプロジェクトはsnes9xだと思っていますが、当時は本当になーんもわかってなかったんで、 こんな結果 [twitter.com]になっちゃったりして、 結構散々でした。まあおかげで吹っ切れたんですが。
その後色々なプロジェクトに様々な細かいパッチとか送りつつ、lame [sourceforge.net]では一時期「リーダー」と (少なくともIRC上では)呼んでもらえるぐらいの状態まで頑張りましたが、とはいえ、そちらもそれまでの間に takehiro.c [srad.jp]なんていうのをやっちゃったり。 ほかにも余りにうざい奴がいたので「もう少し基礎を学んだほうがよいぞ。落ち着いたら？」 と書いたつもりがかなりきつい＆独特の英語になってしまったのか一部できめぜりふっぽくコピペされて使われてしまったりとか。
他にも忘れてしまってるのもかなりあると思われますし、英語については色々恥ずかしいことがたくさんありますね。 コミュニケーション能力のなさに悲しくなったことはもう何度も。 まあ昔書いた作文を見てイタイと感じるのと同じようなモノで、今は全部笑うことにしてます。でなきゃやってられません。
15年ぶりに会った高校時代の英語教師にかけられた最初の言葉が「おお冨永やんか。お前の英語はひどかったなー」だった私ですが、 様々な試練と努力のおかげで英語はだいぶマシになったと思っています。また、TOEICとかの点数も順調に高くなってます。
が、結局あの手のテストは極端に言えば「ファストフード店でどういうメニューを頼むか」とかいうことのための英語であって、 残念ながら実際のオープンソース的な活動には"余り"役に立たないです(もちろんTOEIC的な英語が全くできないのではそれ以前の問題でしょうが…)。 抽象的な概念や思想、ポリシーといったものを説明し、相手を理解し、議論し、より良いものを作り出すための手段としての英語の実力はああいうのでは 測れないかと思います。というか、そもそもそういった能力を発揮するのは母国語(日本語)でも難しかったりするわけですが。
結局そういうのを学ぶには同じようなことをやるしかなくて、じゃあそれを模擬的な形で教えてくれる学校みたいなものがあるかというとあんまりないわけでして。 ビジネス英会話ともまた違うと思っています。
なので、やっぱりここは「習うよりなれろ」じゃないでしょうか。 若いみなさんは是非ばりばりとチャレンジしてみてほしいです。私が参加した当時と違って周りに国際プロジェクトに参加したことのある経験者も多いでしょうから、 色々聞ける相手も多いでしょうし。ググれば各種メーリングリストのアーカイブとかも簡単に見つかるし、 つらつら読んでたら似たようなシチュエーションの人が出したメールとかも見けられるでしょうし。
ちゅーことで以上、おっさんの自分語りでした。自慢ぽく聞こえたらすまん。
-- Takehiro TOMINAGA // may the source be with you!
Re:下手な英語の生兵法は命取り (スコア:2, すばらしい洞察)
次を頑張ってください。
一発絶交とか、自分の不徳で相手に迷惑をかける状況って日本人間でも起こりうるので、たった一回でへこたれてはダメですよ。やりたいことやチャレンジできることを自分であきらめても、詰まらなくなるだけです。
英語の間違いはすぐに直せます。人間関係は時間の助けを借りればなんとかなることもあります。
取引先から出入り禁止食らったことがありましたけど、7年間地味に回ってまた取引してもらえるようになりましたから。英語も国語もソーシャルスキルも、使えば使うほど成長しますよ。自信つけましょうよ。
Re:下手な英語の生兵法は命取り (スコア:2, すばらしい洞察)
そんな気はないのに失礼な文面になってしまって非難囂々、というのは辛い体験だったと思いますが、
「正しい英語を完璧に使えない人間は、安易に英語で発信すべきではない」までいくと
羹に懲りて膾を吹く、ではないかと。
どういう間違いだったのか、差し障りのない範囲で公開していただけると、英語でコミュニケーション
を取ろうとしている人達の参考になると思います。
Re:下手な英語の生兵法は命取り (スコア:1)
あくまで自分が経験したコミュニティの例ですが、人種のるつぼの米国や文化背景の異なる国が隣接しているヨーロッパの人たちは、意見や考え方が異なる人が集まるところでの議論には慣れていて、多くの場合、日本人などよりよっぽど許容力があります。英語の表現の間違いや多少のニュアンスの差についても同じで、それほど目くじらを立てることもない。
もちろんビジネスの場で、ある特定の人の機嫌を損ねるとおしまい、という場合は異なると思いますが、オープンソースのような場では、発言せずに閉じこもっても何も進展しませんから、失敗覚悟で発信していく方が実があると思います。
英語の上手下手よりも、まず、「仲間」として認めてもらうのが大事でしょう。
そのためには、プログラムであれ議論であれ、コントリビュートした数がものをいうはず。
特にプログラム開発であれば、英語が拙くても、プログラムという実体に語らせることが
できるのではないでしょうか？
Re:下手な英語の生兵法は命取り (スコア:1)
toilet paperというと、確かに手紙という言葉があるんだけど。
中国語の手紙：toilet paper
日本語の手紙：letter
paperだったら両方とも紙になっている。
だからそれ、間違えたじゃないかと。
英語の敬語なんて簡単 (スコア:2, すばらしい洞察)
あまりにも目に余る言い回しはまずいけど、敬語にそれほど神経質になる必要は
ないと思います。日本人の感覚から言うと、英語には敬語は皆無といっていいでしょうし。
それよりも、内容を丁寧かつ簡潔に、読む側の立場に立って説明することに、
十分に気を配ることのほうが大切です。
英語で敬語といえば、
・ものを頼むときは、命令形ではなく「Would you please...?」
・自分がやりたいことを伝えるときには、「I want to...」ではなく「I would like to...」
くらいしか、気にしたことがありません。
むしろ、
・意見を事実であるかのように言ってはいけない
・相手の意見を頭ごなしに否定してはいけない
・ひとに命令してはいけない
・ひとのことをばかにしてはいけない
・自分の抱えている課題が、理由もなく他の課題より優先順位が高いように言ってはいけない
・相手にも社会生活があり割ける時間やリソースは限られていることを忘れてはいけない
など、英語・日本語にかかわらず、ひとと議論するうえで常識的なことを忘れないことのほうが
重要だと思います。
何か考えてると対人不安→自閉症→ひきこもりになりそうですね・・・・ (スコア:2)
Re:何か考えてると対人不安→自閉症→ひきこもりになりそうですね・・・・ (スコア:1)
Re:下手な英語の生兵法は命取り (スコア:1)
どちらも下手の内だけど、不自然＞＞無礼ってことだと思います。
経験はバグレポート・パッチ程度ですが、ネット上だと大抵周りの人の投稿が読めるので、似た話題、発展してる議論で表現をまるっとコピペさせてもらうのが楽。書けなくても読める人はこの界隈に非常に多いはず。判断や依頼など敏感な表現だけなんとかすれば、細かい事実の記述は機械的に直訳で。
長く個人的なつきあいが出来る現実と違って一言のミスが命取りになりかねないですし、自分も可能な限り日本語英語にかかわらず言葉で問題が起こるのは避けたいです。
あとはオープンでも個人発のプロジェクトには可能な限り関わらないとか（日本でも同じ）
Re:下手な英語の生兵法は命取り (スコア:1, すばらしい洞察)
こういう人、英語MLに参加した日本人に、たまに見ます。
よくあるパターンとしては、正しい英語を書くのに必死で、内容がおかしいことに
気づいていなくて、案の定「わけわからん」という反応が返ってきたときには、英語表現が
悪いせいだと思い込んでしまって、内容がおかしいことに思いが至らないというものです。
> 正しい英語を完璧に使えない人間は、安易に英語で発信すべきではないですよ。
こんな極端なことを言っていることからも、英語表現が悪いせいだと
思い込んで凝り固まってしまっている様子がうかがえます。
正しい英語を完璧に使えるって、どんな文学者ですか？
私は日本で生まれ育った日本人ですが、正しい日本語を完璧に使える
自信なんてないですし。
Re:下手な英語の生兵法は命取り (スコア:1)
開き直ってあえてミスを入れています。適切な過去・未来形とか三単元のsとか。
自分の気づかない別のところで変な言い回しがあっても失礼なヤツじゃなくて下手なヤツだと思われるんじゃないかと。
効果のほどはわかりませんが。
日本の掲示板にたどたどしい日本語で書き込みがあっても（お礼やバグ報告など）
あたたかく見られてるっぽいので
#1885262 [srad.jp]でも言われているように
明らかなバグを修正するパッチであるとか、明らかに高速化するコードとベンチ結果であるとかであれば、英語部分はどうでもコードで伝わってるっぽい
Re: (スコア:0)
Re:下手な英語の生兵法は命取り (スコア:1)
それあるね。
敬語の使い方が、あまり教えられていない学んでいないというか。
初心者さんだと、下手をしたら英語には敬語表現がないと思っている人もいたりする。
いきなり、tell me why... じゃなくてさ、whould you please let me know why....
とかいった風にするとかね。
>そこで座って待ってろカス
十年程前に、インドの方々が来日されて一緒に仕事したことあるんだけど、
どうも身分的に違う人がいたらしくて、メールやら会話から「結構きっつい
言い方するんだな」とか、「怒るべきなんだけど、やたらへりくだりまくり」
とかあって、じゃ、俺はカースト上の××さんには丁寧に、下の人にはフランク
に？とか考えこんでしまったことがある。
Re:「半年ROMれ」 (スコア:1)
>このへんのことは、「みんなが書いてるのを真似して書けばいい」のだと思います。
その余裕があるか？というのが、問題だったりする。
英語に自信がないお方があちらに行って、いきなり英語のドキュメントだけという状態で、それを理解するという仕事があり、さらに普通の仕事をして、英語の書き方／使い方にそれほど注意が払えるか？というのが問題だと思います。
>みんながどんなふうに書いているか、どんな書き方をすれば議論がうまく流れるか、
その何通かの狭い見聞だけで得た表現だけでメールを全部出せたらよいのですが、オリジナルなところで馬脚が現れます。
しかも、オリジナルってことは、結構、その発信メールで言いたい事／肝な事だったりして、そこらへんで混乱を招いたりね。
>MLアーカイブという生きた英語のテキストがあるのだから、活用しましょう。
で、これがそのメールを出している人の地位や職務によって微妙な差があったりして、仕事のメールだとそこらへんを読み込まないと難しい。
これは、英語に関係なくて、新しい業務についた時に「えっと、この人は部長で、こっちは課長だし」とか「部署のよりこっち側だから...」といったのをわからないと、ちょっとズレた表現になったりしますね。
傷口を軽くするためには、そういったこれまでのメール等を読んでいるのはよいことですが、無傷になるわけでもないので、慎重に...というかね。
わたしはちょっと狡くて近くに英語が出来てその職場に長くいる日本人がいたら査読してもらったり、メール内容の確認をしてもらうふりをしつつ「こんなんでよいかな？」と職場の近しい人に聞いたりして最初はやっていました。
最初の英語環境での仕事は、むっちゃ疲れたという記憶があります。
Re:「半年ROMれ」 (スコア:2, 参考になる)
英語ではオリジナルなことは書くな,
他の人の使っているところをみたことの無い語を使うな,
特に、辞書と教科書に載っていない例や「この人」(チーム
ティーチングの相方の白人のおじいさん)の言ったことのない言い方を使うなと
教わってきました。
だから,他の人が「自分の英語に自信が無い」とか行ってるのを聞くと,
それは英語の量を読んでいないからだと感じるんですよね.
同じ理由で、「オリジナルなところで馬脚」ってのは,
そのオリジナルな事と似た内容を扱うコンテキストの英文を
「読んで覚え」ていないってことだと感じます.
タダ単純にパクリ元をMLの外側の文章に求めればいいじゃないかと.
そもそもよく考えると,オリジナルな英語なんて存在しなくて,
絶対にその母国語話者のパクリをするしかないわけですから,
だったら単純に,パクればいいわけです.
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:「半年ROMれ」 (スコア:1)
> その余裕があるか？というのが、問題だったりする。
いやまったく。職場に英語で電話かかってくるといつもパニック。
content-type: voice/interactive; language=en-us
とか電話機に出るようにしてほしい。
Re:「半年ROMれ」 (スコア:1)
>結局、どうしたいんですか？
難しい場合は、(あまりやっちゃいけないんだが)両部署の上の共通の人に教えてもらっていた。メールの返事が遅いとかいう文句もあったので、そこらへんはがんばってお勉強。
# 英検２級がぜんぜん役に立ってないというか、ブランクありすぎ。
# 昔はちょっと独学やっていたので、カンを取り戻せたというのもありそう。
英語メールに慣れるまでの数ヶ月、残業のあらし。半分火をふくのが見えていたので、それに隠れてやっていたな。
趣味のMLで知りあった外人さんに教えてもらったりとかもあったな。
>仕事で公開のMLアーカイブってあったりするんでしょうか？
用件というか会議体ごとにアーカイブというかファイルに落としていたのをCD-Rに焼いていてくれたのがあったので、それをせっせと読んでいた。
先任者が残していてくれたもので、これは大変ありがたかったけど、量も大変で、確かCD-Rに５枚程度あったかな？(重複多数)
それを見習って、離任前に同じ様に残しておいた(当時のセキュリティだから、今は無理かもね)。
# 着任当時に書いていた自分のメールが恥ずかしいったらありゃしない。
>英語環境での仕事は珍しくないでしょうから、学生のうちから
>国際的なオープンソースプロジェクトとかに携わって、英語に慣れておくのは
重要かもしれません。
わたしが最初に英語環境の職場に入った時はそんなプロジェクトとかなかったけど、今の方々にはぜひ読むだけでもよいから携わっておくとよいと思う。
Re:「半年ROMれ」 (スコア:1)
>それは英語の量を読んでいないからだと感じるんですよね.
そうなんですよね。乱読できるレベルまでサクサクと分かる様にならないと、十分には読み慣れていない＝それまでに結構時間がかかる＝急な英語環境への配置に対応できない...ということになっちゃう。
>タダ単純にパクリ元をMLの外側の文章に求めればいいじゃないかと.
さらに膨大な量からの検出という作業が待っていて、これをやっちゃうと仕事にならない。
仕事についてから準備でどこまで彌縫策としてとれるか？ということを話題にしている面もあるよね。
>だったら単純に,パクればいいわけです.
パクる先の膨大さも考慮しないとね。
Re:「半年ROMれ」 (スコア:1)
そ、それは、学生のうちに終わらせておくべきというか、
すでにやってある前提でなくては、英語を使うのは難しいですよね、みたいなつもりで言いました。
社会人になると時間ないですからね。
普段から英字新聞読むとか英語のニュースサイト読むとかなんとかして英語に触れる時間を増やさないと。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:「半年ROMれ」 (スコア:1)
>現実的ではないということですか?
現実的な量と時間の問題。
いきなりプロジェクトに入ったら、量も時間も限定されているだろ？という流れを読みましょうね。
Re:「半年ROMれ」 (スコア:1)
>そ、それは、学生のうちに終わらせておくべきというか、
そうなんだよね。
でも、英語は学生時代にそれほどやられているわけでもない。なので、英語として独立してやるよりは、自分の興味をもてる分野でやっておくといいってことね。
>社会人になると時間ないですからね。
そうなんだよね。
時間かけたらなんとかなるんだから後回しでやっちゃうと、そこに社会人になってぶちあたると結構、痛い。
>英語に触れる時間を増やさないと。
英語にふれていても、環境依存なフランクさ慇懃さといったことや上下関係とかってあまり身に付かない面があるんだよね＞会社での英語でのやりとり
英語での技術的な言い回しのやりとりはいくつか技術系の英語主体MLで学べるけど、限界はあるってことなんだけどね。
付け焼き刃をどれだけ焼き込むか？みたいな話になっちゃうのだが、それでも焼いていないよりはずっとましだというお話。
実際に、英語だろうが日本語だろうが、ネイティブレベルに本を読めても、実際の会社現場では役に立たない／不足しているって、あるじゃない？
それのネイティブレベルに本を読めても以前で、やりとりする羽目になった場合に、多少は役に立つといったレベルなんだってことね。
元投稿の「下手な英語の生兵法は命取り」にしても、そういったレベルだということ。
で、一般的な日本語でのメールやりとりしていて、会社にはいって「え？そうなの？」ということって、結構あるだろ？
それが、日本語がおぼつかないと、それがその会社／現場のものなのか、日本語レベルの問題？それとも常識？という三段階のかすみがかかって問題がわかんねぇってなことになるってことを言っているのがこのスレだと思うよ。
Re:You'd better～ (スコア:1)
> そういえば「お座りください」は「sit down, please」と教えられるけど、これも
> そんなに丁寧な言葉でないそうな。
「sit down」はペットなんかには言うけど、人には言わないんでしたっけ?
Re:You'd better～ (スコア:1, おもしろおかしい)
使います。
sitが直接表現なので、丁寧というか湾曲表現としては
have a seetを使う事が多いみたいですが、サービス業でもなけりゃ
正直どうでもいい話でもあります。
湾曲表現は判りにくくてイヤ。
typo? (スコア:2)
わんきょくひょうげん？（なぜか変換できないとか）
Re:You'd better～ (スコア:1)
それはほどの馬鹿くらいという位置づけなんでわ。
「わ」と「は」の使い分けができないのも…
＃「ず」と「づ」は正しく使い分けできてるのにね。
Re:You'd better～ (スコア:1)
>部長の山本は間もなく戻りますので、そこで座って待ってろカス
頭の中で,そういう状況になったとき英語で何を言うか考えてみました.
出た結論.
直訳で「座って」って言う必要がないっていうだけですかね.
とにかく,なんでかしりませんが人にsitって言う気にはなりません.
犬にお座りって言ってるみたいな,子供をしつけているみたいな.
I DO sit down, but YOU can't make me sit down! って怒られるのかな?
追記:
下にhave a seatってあって,確かにそうだなと思いました.
ただ,これが婉曲表現というほどのものかというと微妙な気がしますが.
言語はよく分からん.
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
英語書けなきゃ (スコア:2)
コード書く。
君たちが難しそうに議論してる事って、こういうことかい？てな感じでヘタな英語付けときますけど、その瞬間、議論がピタと止むのが快感ですね。
＃いや、そう何回もあるわけじゃないけど。
ピジン言語 (スコア:2)
OSS開発で異なる言語話者同士が同じ仕事をすることで接触言語が生まれたりしたら面白いですね。
グロービッシュやらSimple Englishがそんな感じなのかもしれませんが。
XOOPS→フォークして XOOPS Cube （開発者の多くが日本人）の流れ (スコア:1, 興味深い)
国際的プロジェクトというと、CMSの XOOPS の開発とコミュニティの流れが面白いというか参考になるところが多いです。
まず PHP-Nuke というCMSがあって、それを元に日本人のリーダーが中心になって多国籍開発陣でXOOPS1/XOOPS2を作成しました。XOOPS2はヒット作でした。2002年ごろの話です。
XOOPS2の開発から日本人リーダーが一時的に抜けたあとに、日本からのパッチが本体に取り込まれなくなりました（セキュリティー上の問題が無視されたりなども）。そんな経緯や拡張性の問題から日本人が中心になって XOOPS Cube が作られます。XOOPS Cubeは日本人XOOPSコミュニティーではたいへん大きな支持を受けます。
XOOPS（本家）はその後も分離を繰り返します。
次期バージョンのXOOPS Cude はディレクターが日本人以外の人、メインプログラマーは日本人、デザイナーは日本人以外と多国籍になっています。
XOOPS（本家）は今は、中国の人がリーダーをやっているとちょっと前に聞きましたが、また変わっているかもしれないです。
※聞きかじりが多いので間違いがあったらすまそ
英語メールの例 (スコア:1, 参考になる)
英語メールの例を見つけてきました。
おそらく、日本人が最初に書く英語メールは最初はバグ報告（日本語が使えません）とか
パッチ（マルチバイト文字を使えるように改良しました）といったものでしょうから、
そういうのを探してきました。
たとえば、このバグ報告の例 [debian.org]では、本文はたった４行です。
> In graphical installer, if I choose "Chinese (Simplified)", "Chinese
> (Traditional)", "Japanese" or "Korean" as the language, there will be
> some missing characters in the next page ("Selection your location").
> Please see the attached screenshots and notice the "unicode squares".
（和訳）
（Debianの）GUIインストーラで、中国語・日本語・韓国語を選んだ時、その次の（場所を選ぶ）
ページで正しく表示されない文字があります。添付するスクリーンショットを見てください。
「Unicode番号の正方形」に注意してください。
といったぐあいです。必要かつ十分な情報を盛り込んだ報告の例だと思います。
この程度の英語を書ければ十分だと思います。あえて言えば最後の行の先頭に
「Please」がついているのに注目するくらい？
もっとキャッチボールを (スコア:1)
日本の英語教育にはキャッチボールが少ないと思うんで
こういうのが練習になるといいなとは思いますが
なかなか踏み出せないですね。
私も何回かバグ報告みたいなのを頑張って書いたけど
かなり思い切りが要る・・
日本人は、野球でいうなら
変化球の投げ方については詳しいけど実際にはキャッチボールすらしたことない
って感じがするので、キャッチボールの練習もすれば伸びるんじゃないかという気がします。
言語だけでなく。。。 (スコア:1, 興味深い)
*日本の開発術には匠があり、日本の開発者は真面目で責任を持ってしっかりしたコードを組む。
*外人の開発者は気まぐれで、コードを見る限り丸で効率を一切考えずに何かの新開発概念に凝りすぎているコードばっかり組む。遅れて問題となる時に攻めると逆ギレして一切仕事をしなくなる。また、どれだけ下っ端のプログラマでも一々自分の馬鹿馬鹿しい考えを押し、それを一々何でダメだと説明しても「この企画はダメだな、成功すると思えない」などの文句が来る。。。
今は海外の開発部門がない会社で働いているが、出来る限りこれからは日本人としか開発したくない。ウオータフオールモデルが海外で成功しないには理由がある。
Re:言語だけでなく。。。 (スコア:2)
＞ウオータフオールモデルが海外で成功しないには理由がある。
嘘を書くな。
これだと、まるで日本ではウォーターフォールが成功しているみたいに見えるじゃないか。
＞外人の開発者は気まぐれで、
あと、ここがちょっと嘘くさい。
USのシリコンバレーもあればインドもあれば中国もロシアもフランスもドイツも
あるのに、「外人の開発者は」とひとまとめにするのは無理すぎ。
多少の経験があったところで、どうせインドかロシアあたりの1～2カ国の
経験があるくらいでしょ？
大抵のOSSプロジェクトには、すでに日本人がいる (スコア:1)
だから君が最初の一人になるのでなければ、英語はある程度、すでにいる日本人にフォローしてもらえると思って大丈夫だ。逆に言うと、その場ですかさずフォローが入れてもらえるような環境からスタートしたほうが良い。その意味ではMLとかはリアルタイムではないのでフォローしづらい。国際会議とか、とにかく「人が直接会う」場からスタートしたほうが良い。
# そうすれば「あいつは英語が下手」というのも含めて解ってもらえる。
逆の言い方をすると、「最初の一人」はものすごくきつい。「最初の一人」に対する感謝を忘れないようにしたほうが良い。
.
一方で。言語問題はたいしたことはない。一番むつかしいのは「文化の差」と言うやつ。
物の考え方、優先順位のつけ方が、日本とアメリカはまるで違う。世界地図でイギリスが中心の(要するに普通の)世界地図があるが、まさに「東の端」対「西の端」ぐらい違う。
で、文化の差を埋めるには、「普段の説明より、1段手前から説明する」気持ちを忘れないこと。「How」は別にその必要はないが「Why need it」周りは特に丁寧に。特にアメリカ人は移民の国なこともあって、「全員共通認識だよね」という所から一段づつ説明するのが説明の仕方の基本パターン。
日本人は「全員の共通認識はいちいち説明しないよ？！そのつぎから行くからね」とやるので『あいつは何を言ってるんだ』と思われる。実際には「2ステップ」ぐらいジャンプしていて、前提が合っていないので議論がかみ合わなくなることが多分にある。
で、説明の文章は「1筋の流れ」のように説明するのがよい。枝分かれして行ったり来たりしてはいけない。聞いている側が迷子になりやすいし、迷子になったときのフォローが入れられるほどこちらも言語能力がないんだから。この点に関しては大前研一の文章は参考になる(書いてある内容ではなく、話の筋道の立て方が、参考になる)。
.
最初から難しいことを言わない。
たとえ目的はややこしい内容の採用であっても、最初は別の、もっと簡単なテーマから入る。
manpageの内容をもうちょっと分かりやすくして、とか。そうやって「傍流」側でちょっとだけ貢献して、味方を作っておく。これは別に国際プロジェクトじゃなくてもそうだけど、言語不如意状態な所ではこの戦略は特に有効。
.
最後に「あいつは日本の文化圏の人なんだ」という事を理解してもらうためのマーカー表現がいくつかある。例としてはこんな感じ:
- 人の名前は xxx-san と「さん」を付ける。判っている人はこれが「日本語の prefix である」事を理解する。
一方で「xxxさん」は相手が男女どちらでも使えるので、名前から男女の区別がつかないときにはとても便利。
- 一番最初に何かしてもらう場合は、文章の最後に「Thank you in advance for taking your time.」なんてのを
書くが、その後に「Arigato!!」と書いておく。
これだけでも結構軋轢は減る。
fjの教祖様
Re:大抵のOSSプロジェクトには、すでに日本人がいる (スコア:1)
そうですね。説明の足りない人は、日本人には特に多いように感じます。 説明をすっ飛ばして絵を描きだす人も。（「絵に説明つけなきゃわかんねーんだよ」って言いたくなること多数。）
あとは枝葉ですが…。
これも言い方がありまして…。ただ「わからない」といわれただけじゃ、なにがわからないのかわからないんだ。具体的に、「ここの部分は、Aという解釈とBという解釈がありうるが、どちらの意味ですか？」のように訊いてみるとか、あるいは、具体的な修正案を提示するとか、していただけると嬉しい。下手に抽象的なことを言おうとすると、たいてい失敗して、しかも具体性がないので何が言いたいかわからない、という落とし穴にはまります。
"-san" は prefix じゃなくて postfix ね。
"in advance" はないほうがいいかも。なんか、"Thanks in advance" が「よろしくお願いします」の英訳だと書いてあるサイトもありますが、「前もってお礼申し上げます」っていうのは、ひねくれた読み方をすれば「あとから礼をいう気はないからね」という意味になるので。"Thanks for taking your time" で十分ですよ。
Re:大抵のOSSプロジェクトには、すでに日本人がいる (スコア:1)
それはこの業界で使うギャグだ。
# prefix には「敬称」という意味がある。敬称という意味の場合は、
# 前に着こうが後に付こうが「prefix」という。
## とネタを1つ潰された腹いせに、マジレスする (^w^)。
うーむ。どちらかというと "Thanks for taking your time" は「時間掛けろや、仕事しろや、ゴラァ」という意味に取られかねないので、そちらの方が危険ですよ。
.
Thank you in advance は「あなたが時間を費やしてくれたその場で感謝のメッセージを伝えることができないので」先にお礼を言っておくね、と言う意味。つまり、「あなたが返事をくれようがくれまいが、作業を使用が姉妹が、私は感謝していますよ」という事。
相手によっては、メールを受け取ったら返事を書かないで、いきなり man page に update をかけてしまう人もいるよね。で、こちらはこちらでメールをチェックしていても man page の最新版をチェックしてはいないので、更新されたことに気が付かなくて御礼が遅れたりする。
なので、謝辞プロトコルが一般常識どおりに進むとは限らない相手の場合は、"Thank you in advance" を必ず書くことを薦めています。これが営業職とか相手だったら、心配しないんですけどね。
fjの教祖様
Re:大抵のOSSプロジェクトには、すでに日本人がいる (スコア:1)
どうも、勉強になります。
そういえば、自分はどういう表現をしていたかな…と思ったら、Thank you for your patience をよく使っていました。
Re:まずは相手が検証可能な貢献から (スコア:1)
あぁ、ごめん。これは「交通費をケチるな」という意味でもあるんだ。
アメリカにとぼうとすると、エコノミーでも20万、ビジネスクラスだと50万ぐらいするけれど、その程度の予算をけちるぐらいなら最初から国際プロジェクトに参加しようと考えないほうが良い、と言う意味。
# 特に予算を握っている偉い人。
大抵の場合、1年に3,4回ぐらい飛んでいく必要があり、それが3年以上続くものだ。移動でへとへとになった状態では使いものにならないから、ビジネスクラスぐらいは使ったほうが良い。すると移動コストだけで 600万円近くかかる。これに比べたら宿泊費なんて誤差。
それだけの出費を理由付けられるぐらい、得られるものがあると言うのでなければやめとけ
と言う意味でもあるし
それぐらいの出費、他のプロジェクトと比べても特に高いわけでもあるまい?!
という意味でもある。
fjの教祖様
Re:まずは相手が検証可能な貢献から (スコア:1)
偉さは関係有りません。
「明日海外出張決定な～！！」
と言われるような立場になれば、もうエコノミークラスの席は残っていませんから。否応なしにビジネスクラスです。
たとえば新製品でトラブル発生、開発に直させなくちゃいけない。お客様は怒髪天を衝いている
「日本から誰も監視に行っていないとは何事だっ」
こんな場合は、
1) そこそこ英語ができて
2) 外国でも萎縮せず
3) 押しが強い奴で、技術的説明が理解できる
の3条件が揃えば、「明日行け」攻撃を食らいます、平社員でも。
逆に「参加することに意義がある」程度であれば、「行かなくてもどうにかならない？」と言われます。たとえ副社長であっても。
.
なので「ビジネスクラスを使えるかどうか」は偉さで決定するのではなく、「それだけのコストを掛けてでもしなくてはいけない」という何かがあって、その「何か」を実行出来る実力があるかどうか、ですね。
もちろん、それらを Justify するのは予算を握っている人なので、そういう人は自分の出張は大抵ビジネスクラス以上です(^w^)。本部長とかね。
.
判ると想いますが、上記の状態、実は「お客様に頭を下げて、撤退させてもらう」という手があるわけです。ビジネスクラスだろうがファーストクラスだろうが、社員を送り込んでも何ともならない(何とかできる奴が一人もいない上に、自分自身にもどうにか出来る実力がなく、さらに言えば社内十どこにもそんな奴がいない)なら、出張予算を使うよりもお客様を1セット失うほうが安い。
また、トラブルにそれだけのコストを掛けても、そもそも商品が「240円」で起こっているお客様が一人しかいないなら、絶対ペイしません。
お客様を逃さないほうが往復50万円のコストよりも利益が大きいからこそ、往復50万円掛けるわけです。
OSS だってそれと一緒です。金銭的な収入だけじゃなく、実績とか、他のメンバーからの信頼とか、有名になるとか、そもそも楽しいとか、いろいろ成果はあるでしょうが、それらをトータルで見て 赤字になるならやっぱりやらないほうがいいんですよ。一旦始めたら途中でやめるとむしろ信頼を失ったりしてマイナスになりかねませんから、トータルが怪しいなら一番最初の段階で手をつけない。できないことをやると言わない。
そこら辺が甘い経営者が多いですね、日本には。
fjの教祖様
国際的「プロジェクト」？ (スコア:0)
＞これら国際的なプロジェクトでは英語が公用語として用いられるため、
＞英語で説明・論戦・説得・理解・合意などを行うスキルが要求されます。
とりあえずバグレポートとか、改善提案とか、そんなのでも英語で説明したりは
するんだけど。某拡張の日本語化（多国語化）もそんな感じで始まった。
（これは開発者側が乗り気だったこともある。）
最初はそんなレベルから始まったけれど、でもそれは「プロジェクト」とは呼ばないよね。
まずはバグレポート程度から (スコア:1, 参考になる)
そうですね。私もまずはバグレポート程度からでした。
それでも、英文メールを何回も読み直して、送信するときはどきどきものでした。
返事が返ってきた（言いたいことがきちんと伝わっていた）ときには
めちゃくちゃうれしかったものです。
もう20年近く前のことですが。
Re:まずはバグレポート程度から (スコア:3, 参考になる)
そうですね。私もまずはバグレポート程度からでした。
それでも、英文メールを何回も読み直して、送信するときはどきどきものでした。
返事が返ってきた（言いたいことがきちんと伝わっていた）ときには
めちゃくちゃうれしかったものです。
バグレポートを詳細に記述（「このコマンドに不具合があった」「LinuxとSunOSで再現した」「このCのソースがおかしい」）して
「このパッチで直る」とdiffの修正パッチも添付した長文のメールを1通、OSSのMLに投稿したら無視されました。
その半年後に英語ネイティブの間だけで「こんな不具合があった」「あ、こっちでも再現した」ってやり取り始まって
開発者から「勧告：このコマンドをしばらく使用しないように」なんてメールが
MLに流れていたのを見たときには悲しくなりました。
#出張中で気づいていなかった私が、帰ってきた直後に
#「それ僕が半年前にパッチ送りました・・・」って涙目になりながらMLに投稿しました。
##その後に開発者から「Thanks!パッチ取り込んだよ！」のメール来ました
##教訓：長文の詳細なレポートより、まずコミュニケートしたほうが話は進むくん。
Re:まずはバグレポート程度から (スコア:1)
キーリピートの修正 [freebsd.org]・・・これは自慢できる、かな。
ATAレイヤーのタイムアウトに関して [freebsd.org]・・・タイムアウトの記述を見直せや、のプレッシャーにはなってるのかな。
atacontrolの自己拡張 [freebsd.org]・・・これはどうでもいい、むしろ保存の場として逆利用している。
いや内容的には些細なことなんですけどね。 でもシステムはこうした些細な前進の集大成であると。
で今家庭内サーバー [so-net.ne.jp]を 6.2R から 8.x にあげようとしていて、自分だけのローカルパッチで逃げていた部分がはじめから修正されていたり、記述が見直されたりしていると 「情けは人の為ならずやな～」と感慨ひとしきりです。
# ただし時間かかってます、2年がかりです、当時のメールアドレスはもう失効しました。
初体験の感想 (スコア:0)
痛いのは最初だけだよ・・・
そう、だんだん怒りへと変わっていくんだ！ (スコア:0)
Re: (スコア:0)
そだね。最初は怖いけどすぐに慣れる。
仕事で準備時間1週間でマレーシアに吹っ飛ばされたときに英語と中国語とマレー語っぽいのちゃんぽんで相手の言ってる言葉わからなくて身振り手振りだったけど、最終的にはなんとかなったもの。
ただ絶対に必要なのは目的。
参加させられるっていう状況が一番自分を落ち着かせやすいけど、自発的に参加するプロジェクトだと目的を見失うと簡単に自分も見失うのでタレこみAC氏には頑張ってほしいと思う。
Re:へたっぴ英語 (スコア:3, 興味深い)
個人的な経験ですが、中学レベルの英文法にしくじっても何とかなります。かなりブロークンでも筋が通っていればコミュニケーションが取れる感じです。
あと、和文英訳ソフトが吐き出す英文が、以外と通じます。
何よりも、英語を母国語としない人がかなりいるので、一種のコミュニケーションツールとして割り切った方がいいのかもしれません。