パスワードを忘れた? アカウント作成
288518 story
ソフトウェア

国際プロジェクト初体験を聞かせて! 101

ストーリー by soara

あるAnonymous Coward 曰く、

オープンソースソフトウェア開発プロジェクトのなかには、いろんな国の人々が協力しあう国際的なプロジェクトがたくさんあります。むしろ、世界の主要なプロジェクトは国際的なものがほとんどかもしれません。これら国際的なプロジェクトでは英語が公用語として用いられるため、英語で説明・論戦・説得・理解・合意などを行うスキルが要求されます。

しかし、ネット環境や活動の場が急速にグローバル化しても、一方で日本人は英語が下手だ(と思っている)し、それが簡単に解消するわけではありません。国際的なプロジェクトへの参加は、多くの日本人にとってかなり抵抗感が大きいのではないかと思います。

先日のRubyやNucleus CMSプロジェクトの例にもあるように、プロジェクトを国際化することはさらなる飛躍の可能性を意味するものの、現実には「言葉の壁」を越えることは難しいということも起こっています。また、オープンソースに興味はあるけど英語はちょっと...と思っている人もいらっしゃるのではないかと思います。英語のせいでオープンソースに参加できないでいる人がいるとしたら、それはオープンソースにとって損失です。

/.Jには、国際的なオープンソースプロジェクトで活躍されている(いた)人もいらっしゃるのではないかと思います。英語での議論は予想通りあるいは予想以上に大変でしょうか? 困難をどう克服したのでしょうか? 日本人にとって英語は永遠の課題なのでしょうか? それとも「案ずるより産むが易し」なのでしょうか? 皆様の国際プロジェクト参加初体験をお聞かせいただければ、オープンソースの将来を担うアレゲ予備軍の人々の役に立つのではないかと思います。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • TOMOYO Linuxの場合 (スコア:3, 参考になる)

    by haradats (29198) on 2011年01月09日 9時15分 (#1885451) ホームページ 日記

    /.Jには、国際的なオープンソースプロジェクトで活躍されている(いた)人もいらっしゃるのではないかと思います。英語での議論は予想通りあるいは予想以上に大変でしょうか? 困難をどう克服したのでしょうか? 日本人にとって英語は永遠の課題なのでしょうか? それとも「案ずるより産むが易し」なのでしょうか? 皆様の国際プロジェクト参加初体験をお聞かせいただければ、オープンソースの将来を担うアレゲ予備軍の人々の役に立つのではないかと思います。

    TOMOYOは、SF.jpのプロジェクトとして発足して、今もSF.jpで活動しています。プロジェクトの発足から、メインライン(Linux標準への提案活動)までの歩みについて、下記の資料で参照できます。

    • http://www.slideshare.net/haradats/tomoyo-linux
    • http://www.slideshare.net/haradats/realities-of-mainlining-case-of-the-tomoyo-linux-project

    TOMOYOは、もともとは「日本で開発したものだから、日本で使ってもらえば良い」と思っており、「国際化」は全く考えてなかったのですが、CELinux ForumやYLUGなどで「Linuxの開発成果はメインラインにすべき(しろ、ごるぁ)」というご意見をいただき、そこから急遽「国際化」である「メインライン化」を目指したという経緯です。

    もともと国際化を意識していたわけではないので、「メインライン」という言葉も知らなければ、当時のLinuxの主要な会議である「Ottawa Linux Symposium」について名前すら知らないし、開発メーリングリストであるLKML (Linux Kernel Mailing List)も購読していないというかなりオワタ的な状態からスタートしました。語学(英語)的な課題について振り返るとき、個人的には「最初に何をどう発言(提案)すれば良いのかわからない」が一番悩んだところです。他の方のコメントで「半年ROMれ」というのがありますが、開発にかかわらず新しい世界と交流をしようとするとき、「どんな人たちがいるか」「どんなふうに話をすれば良いか」「どんな(暗黙の)ルール、あるいは文化があるか」がわからないと、発言はできません。まず、その世界を知る、知ろうとする努力が欠かせないと思います。始めてしまえば(交流が始まれば)なんとかなるのですが、最初の合流、最初の提案が、難しい、そう思います。

    ということがあったので、TOMOYOの最初の提案からメインラインにマージされるまでの全提案とそのスレッドを他の人があとから読んで参考にできるようにしています(実際、読む人がいるかはわかりませんが)。それを含め、LKMLにおけるやりとりからの教訓を読みやすい形で、Japan Linux Symposium 2009で発表しています。

    • http://www.slideshare.net/haradats/kernel-development-drawing-lessons-from-mistakes

    Linux開発における語学(英語)の重要性についてですが、自分の経験からは、「発音や文法が多少おかしくても通じる」ので、「とにかく伝えたいことを伝える」ことが大切だと思います。日本人には「英語が弱い」という人種的?コンプレックスがありますが、英語が弱いのは日本人だけではありません(笑)。Linux界隈のネイティブの人は細かいことはいいから、主張を説明して欲しいという視点で待っているので、「これ正しいかな?」とか「伝わるかな?」とかはあまり気にしないほうが良いです。

    「国際化」についてですが、実は世界はもともと国際化しているわけで、要は視点や活動範囲を自分が制限するかどうかだと思います。知らない世界や英語がメインのコミュニティと交流することは大変といえば大変ですし、疲れるといえば疲れますが、視野が広がり経験が増えます。物理的には日本という国にいても、気持ちや活動内容では、自由に世界と交流ができます。すべてがうまくいくわけはなく、時には挫折や失敗もありますし、行き詰まることもあるでしょう(TOMOYOも実際そうでした)。でも、そこには確かにそこにしかない喜びがあります。多くの人に勇気をもって踏み出して欲しい、そう思います。

    --
    tsh
  • by Anonymous Coward on 2011年01月08日 12時43分 (#1885187)
    一度、とんでもなく失礼な言い回しのメールを送りつけてしまったことがあります。
    送った時は全く気付かず、相手が怒り出して周りからも激しく批判されてから、自分のメールを辞書片手に読み直してようやく気付いたんですけどね。
    慌てて誤解だと弁解したものの、もう何を言っても聞き入れてもらえませんでした。

    最近よくある「下手な英語でいいから堂々と発信しろ」みたいな主張は全くの嘘っぱちだと思ってます。下手な英語は時に議論の流れも、和やかな雰囲気も、自分の立場すらも破壊することを身に染みてますから。
    正しい英語を完璧に使えない人間は、安易に英語で発信すべきではないですよ。相手にとっても失礼や迷惑になりかねないので。
    • by tt (2867) on 2011年01月08日 18時54分 (#1885298) 日記
      まあ私も英語は苦労してますけど、どうせブラジル・スペインとか、中国・韓国・インドとかの人々の英語の方がもっとひどかったりするので、 あんまり気にしてもしょうがないかなあと思ってます。

      私が最初に参加した、比較的有名な世界的といえるプロジェクトはsnes9xだと思っていますが、当時は本当になーんもわかってなかったんで、 こんな結果 [twitter.com]になっちゃったりして、 結構散々でした。まあおかげで吹っ切れたんですが。

      その後色々なプロジェクトに様々な細かいパッチとか送りつつ、lame [sourceforge.net]では一時期「リーダー」と (少なくともIRC上では)呼んでもらえるぐらいの状態まで頑張りましたが、とはいえ、そちらもそれまでの間に takehiro.c [srad.jp]なんていうのをやっちゃったり。 ほかにも余りにうざい奴がいたので「もう少し基礎を学んだほうがよいぞ。落ち着いたら?」 と書いたつもりがかなりきつい&独特の英語になってしまったのか一部できめぜりふっぽくコピペされて使われてしまったりとか。

      他にも忘れてしまってるのもかなりあると思われますし、英語については色々恥ずかしいことがたくさんありますね。 コミュニケーション能力のなさに悲しくなったことはもう何度も。 まあ昔書いた作文を見てイタイと感じるのと同じようなモノで、今は全部笑うことにしてます。でなきゃやってられません。

      15年ぶりに会った高校時代の英語教師にかけられた最初の言葉が「おお冨永やんか。お前の英語はひどかったなー」だった私ですが、 様々な試練と努力のおかげで英語はだいぶマシになったと思っています。また、TOEICとかの点数も順調に高くなってます。

      が、結局あの手のテストは極端に言えば「ファストフード店でどういうメニューを頼むか」とかいうことのための英語であって、 残念ながら実際のオープンソース的な活動には"余り"役に立たないです(もちろんTOEIC的な英語が全くできないのではそれ以前の問題でしょうが…)。 抽象的な概念や思想、ポリシーといったものを説明し、相手を理解し、議論し、より良いものを作り出すための手段としての英語の実力はああいうのでは 測れないかと思います。というか、そもそもそういった能力を発揮するのは母国語(日本語)でも難しかったりするわけですが。

      結局そういうのを学ぶには同じようなことをやるしかなくて、じゃあそれを模擬的な形で教えてくれる学校みたいなものがあるかというとあんまりないわけでして。 ビジネス英会話ともまた違うと思っています。

      なので、やっぱりここは「習うよりなれろ」じゃないでしょうか。 若いみなさんは是非ばりばりとチャレンジしてみてほしいです。私が参加した当時と違って周りに国際プロジェクトに参加したことのある経験者も多いでしょうから、 色々聞ける相手も多いでしょうし。ググれば各種メーリングリストのアーカイブとかも簡単に見つかるし、 つらつら読んでたら似たようなシチュエーションの人が出したメールとかも見けられるでしょうし。

      ちゅーことで以上、おっさんの自分語りでした。自慢ぽく聞こえたらすまん。

      --
      -- Takehiro TOMINAGA // may the source be with you!
      親コメント
    • by Anonymous Coward on 2011年01月08日 13時07分 (#1885197)

      次を頑張ってください。
      一発絶交とか、自分の不徳で相手に迷惑をかける状況って日本人間でも起こりうるので、たった一回でへこたれてはダメですよ。やりたいことやチャレンジできることを自分であきらめても、詰まらなくなるだけです。

      英語の間違いはすぐに直せます。人間関係は時間の助けを借りればなんとかなることもあります。
      取引先から出入り禁止食らったことがありましたけど、7年間地味に回ってまた取引してもらえるようになりましたから。英語も国語もソーシャルスキルも、使えば使うほど成長しますよ。自信つけましょうよ。

      親コメント
    • by undefined (8004) on 2011年01月08日 13時56分 (#1885206)

      そんな気はないのに失礼な文面になってしまって非難囂々、というのは辛い体験だったと思いますが、
      「正しい英語を完璧に使えない人間は、安易に英語で発信すべきではない」までいくと
      羹に懲りて膾を吹く、ではないかと。

      どういう間違いだったのか、差し障りのない範囲で公開していただけると、英語でコミュニケーション
      を取ろうとしている人達の参考になると思います。

      親コメント
    • 英語の敬語なんて簡単 (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2011年01月08日 16時11分 (#1885237)

      あまりにも目に余る言い回しはまずいけど、敬語にそれほど神経質になる必要は
      ないと思います。日本人の感覚から言うと、英語には敬語は皆無といっていいでしょうし。
      それよりも、内容を丁寧かつ簡潔に、読む側の立場に立って説明することに、
      十分に気を配ることのほうが大切です。

      英語で敬語といえば、
      ・ものを頼むときは、命令形ではなく「Would you please...?」
      ・自分がやりたいことを伝えるときには、「I want to...」ではなく「I would like to...」
      くらいしか、気にしたことがありません。

      むしろ、
      ・意見を事実であるかのように言ってはいけない
      ・相手の意見を頭ごなしに否定してはいけない
      ・ひとに命令してはいけない
      ・ひとのことをばかにしてはいけない
      ・自分の抱えている課題が、理由もなく他の課題より優先順位が高いように言ってはいけない
      ・相手にも社会生活があり割ける時間やリソースは限られていることを忘れてはいけない
      など、英語・日本語にかかわらず、ひとと議論するうえで常識的なことを忘れないことのほうが
      重要だと思います。

      親コメント
    • どちらも下手の内だけど、不自然>>無礼ってことだと思います。
      経験はバグレポート・パッチ程度ですが、ネット上だと大抵周りの人の投稿が読めるので、似た話題、発展してる議論で表現をまるっとコピペさせてもらうのが楽。書けなくても読める人はこの界隈に非常に多いはず。判断や依頼など敏感な表現だけなんとかすれば、細かい事実の記述は機械的に直訳で。

      長く個人的なつきあいが出来る現実と違って一言のミスが命取りになりかねないですし、自分も可能な限り日本語英語にかかわらず言葉で問題が起こるのは避けたいです。
      あとはオープンでも個人発のプロジェクトには可能な限り関わらないとか(日本でも同じ)

      親コメント
    • by Anonymous Coward on 2011年01月09日 10時26分 (#1885461)

      こういう人、英語MLに参加した日本人に、たまに見ます。
      よくあるパターンとしては、正しい英語を書くのに必死で、内容がおかしいことに
      気づいていなくて、案の定「わけわからん」という反応が返ってきたときには、英語表現が
      悪いせいだと思い込んでしまって、内容がおかしいことに思いが至らないというものです。

      > 正しい英語を完璧に使えない人間は、安易に英語で発信すべきではないですよ。

      こんな極端なことを言っていることからも、英語表現が悪いせいだと
      思い込んで凝り固まってしまっている様子がうかがえます。
      正しい英語を完璧に使えるって、どんな文学者ですか?
      私は日本で生まれ育った日本人ですが、正しい日本語を完璧に使える
      自信なんてないですし。

      親コメント
    • 開き直ってあえてミスを入れています。適切な過去・未来形とか三単元のsとか。
      自分の気づかない別のところで変な言い回しがあっても失礼なヤツじゃなくて下手なヤツだと思われるんじゃないかと。
      効果のほどはわかりませんが。

      日本の掲示板にたどたどしい日本語で書き込みがあっても(お礼やバグ報告など)
      あたたかく見られてるっぽいので

      #1885262 [srad.jp]でも言われているように

      明らかなバグを修正するパッチであるとか、明らかに高速化するコードとベンチ結果であるとかであれば、英語部分はどうでもコードで伝わってるっぽい

      親コメント
    • by Anonymous Coward
      部長の山本は間もなく戻りますので、そこで座って待ってろカス
      • それあるね。
        敬語の使い方が、あまり教えられていない学んでいないというか。

        初心者さんだと、下手をしたら英語には敬語表現がないと思っている人もいたりする。
        いきなり、tell me why... じゃなくてさ、whould you please let me know why....
        とかいった風にするとかね。

        >そこで座って待ってろカス

        十年程前に、インドの方々が来日されて一緒に仕事したことあるんだけど、
        どうも身分的に違う人がいたらしくて、メールやら会話から「結構きっつい
        言い方するんだな」とか、「怒るべきなんだけど、やたらへりくだりまくり」
        とかあって、じゃ、俺はカースト上の××さんには丁寧に、下の人にはフランク
        に?とか考えこんでしまったことがある。

        親コメント
  • by elderwand (34630) on 2011年01月08日 17時13分 (#1885262) 日記

    コード書く。

    君たちが難しそうに議論してる事って、こういうことかい?てな感じでヘタな英語付けときますけど、その瞬間、議論がピタと止むのが快感ですね。

    #いや、そう何回もあるわけじゃないけど。

  • by kcg (26566) on 2011年01月10日 15時10分 (#1885829) ホームページ 日記

    OSS開発で異なる言語話者同士が同じ仕事をすることで接触言語が生まれたりしたら面白いですね。
    グロービッシュやらSimple Englishがそんな感じなのかもしれませんが。

  • by Anonymous Coward on 2011年01月08日 16時08分 (#1885234)

    国際的プロジェクトというと、CMSの XOOPS の開発とコミュニティの流れが面白いというか参考になるところが多いです。

    まず PHP-Nuke というCMSがあって、それを元に日本人のリーダーが中心になって多国籍開発陣でXOOPS1/XOOPS2を作成しました。XOOPS2はヒット作でした。2002年ごろの話です。
    XOOPS2の開発から日本人リーダーが一時的に抜けたあとに、日本からのパッチが本体に取り込まれなくなりました(セキュリティー上の問題が無視されたりなども)。そんな経緯や拡張性の問題から日本人が中心になって XOOPS Cube が作られます。XOOPS Cubeは日本人XOOPSコミュニティーではたいへん大きな支持を受けます。
    XOOPS(本家)はその後も分離を繰り返します。

    次期バージョンのXOOPS Cude はディレクターが日本人以外の人、メインプログラマーは日本人、デザイナーは日本人以外と多国籍になっています。

      XOOPS(本家)は今は、中国の人がリーダーをやっているとちょっと前に聞きましたが、また変わっているかもしれないです。

    ※聞きかじりが多いので間違いがあったらすまそ

  • 英語メールの例 (スコア:1, 参考になる)

    by Anonymous Coward on 2011年01月08日 19時21分 (#1885306)

    英語メールの例を見つけてきました。

    おそらく、日本人が最初に書く英語メールは最初はバグ報告(日本語が使えません)とか
    パッチ(マルチバイト文字を使えるように改良しました)といったものでしょうから、
    そういうのを探してきました。

    たとえば、このバグ報告の例 [debian.org]では、本文はたった4行です。

    > 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」がついているのに注目するくらい?

  • 日本の英語教育にはキャッチボールが少ないと思うんで
    こういうのが練習になるといいなとは思いますが
    なかなか踏み出せないですね。
    私も何回かバグ報告みたいなのを頑張って書いたけど
    かなり思い切りが要る・・

    日本人は、野球でいうなら
    変化球の投げ方については詳しいけど実際にはキャッチボールすらしたことない
    って感じがするので、キャッチボールの練習もすれば伸びるんじゃないかという気がします。

  • by Anonymous Coward on 2011年01月09日 1時39分 (#1885398)
    一応僕は外国生まれで中学校までは外国[主にアメリカ]に住んでたけど16才から日本に住んでいるプログラマーです。海外で開発の勉強は少々やりましたけど最終的にほとんどの技術を日本の専門学校で学んだ。会社に入ってから英語が話せる僕はもちろん海外と日本の開発者の間に立ちコードやその他のやりとりを合わせる存在になった。しばらくやってから分かったことがいくつかあるが、纏めて言うと:
    *日本の開発術には匠があり、日本の開発者は真面目で責任を持ってしっかりしたコードを組む。
    *外人の開発者は気まぐれで、コードを見る限り丸で効率を一切考えずに何かの新開発概念に凝りすぎているコードばっかり組む。遅れて問題となる時に攻めると逆ギレして一切仕事をしなくなる。また、どれだけ下っ端のプログラマでも一々自分の馬鹿馬鹿しい考えを押し、それを一々何でダメだと説明しても「この企画はダメだな、成功すると思えない」などの文句が来る。。。

    今は海外の開発部門がない会社で働いているが、出来る限りこれからは日本人としか開発したくない。ウオータフオールモデルが海外で成功しないには理由がある。
    • >ウオータフオールモデルが海外で成功しないには理由がある。
      嘘を書くな。

      これだと、まるで日本ではウォーターフォールが成功しているみたいに見えるじゃないか。

      >外人の開発者は気まぐれで、
      あと、ここがちょっと嘘くさい。
      USのシリコンバレーもあればインドもあれば中国もロシアもフランスもドイツも
      あるのに、「外人の開発者は」とひとまとめにするのは無理すぎ。

      多少の経験があったところで、どうせインドかロシアあたりの1~2カ国の
      経験があるくらいでしょ?

      親コメント
  • だから君が最初の一人になるのでなければ、英語はある程度、すでにいる日本人にフォローしてもらえると思って大丈夫だ。逆に言うと、その場ですかさずフォローが入れてもらえるような環境からスタートしたほうが良い。その意味ではMLとかはリアルタイムではないのでフォローしづらい。国際会議とか、とにかく「人が直接会う」場からスタートしたほうが良い。
    # そうすれば「あいつは英語が下手」というのも含めて解ってもらえる。

    逆の言い方をすると、「最初の一人」はものすごくきつい。「最初の一人」に対する感謝を忘れないようにしたほうが良い。

    .

    一方で。言語問題はたいしたことはない。一番むつかしいのは「文化の差」と言うやつ。
    物の考え方、優先順位のつけ方が、日本とアメリカはまるで違う。世界地図でイギリスが中心の(要するに普通の)世界地図があるが、まさに「東の端」対「西の端」ぐらい違う。

    で、文化の差を埋めるには、「普段の説明より、1段手前から説明する」気持ちを忘れないこと。「How」は別にその必要はないが「Why need it」周りは特に丁寧に。特にアメリカ人は移民の国なこともあって、「全員共通認識だよね」という所から一段づつ説明するのが説明の仕方の基本パターン。
    日本人は「全員の共通認識はいちいち説明しないよ?!そのつぎから行くからね」とやるので『あいつは何を言ってるんだ』と思われる。実際には「2ステップ」ぐらいジャンプしていて、前提が合っていないので議論がかみ合わなくなることが多分にある。

    で、説明の文章は「1筋の流れ」のように説明するのがよい。枝分かれして行ったり来たりしてはいけない。聞いている側が迷子になりやすいし、迷子になったときのフォローが入れられるほどこちらも言語能力がないんだから。この点に関しては大前研一の文章は参考になる(書いてある内容ではなく、話の筋道の立て方が、参考になる)。

    .

    最初から難しいことを言わない。

    たとえ目的はややこしい内容の採用であっても、最初は別の、もっと簡単なテーマから入る。
    manpageの内容をもうちょっと分かりやすくして、とか。そうやって「傍流」側でちょっとだけ貢献して、味方を作っておく。これは別に国際プロジェクトじゃなくてもそうだけど、言語不如意状態な所ではこの戦略は特に有効。

    .

    最後に「あいつは日本の文化圏の人なんだ」という事を理解してもらうためのマーカー表現がいくつかある。例としてはこんな感じ:

    - 人の名前は xxx-san と「さん」を付ける。判っている人はこれが「日本語の prefix である」事を理解する。
     一方で「xxxさん」は相手が男女どちらでも使えるので、名前から男女の区別がつかないときにはとても便利。

    - 一番最初に何かしてもらう場合は、文章の最後に「Thank you in advance for taking your time.」なんてのを
        書くが、その後に「Arigato!!」と書いておく。

    これだけでも結構軋轢は減る。

    --
    fjの教祖様
    • そうですね。説明の足りない人は、日本人には特に多いように感じます。 説明をすっ飛ばして絵を描きだす人も。(「絵に説明つけなきゃわかんねーんだよ」って言いたくなること多数。)

      あとは枝葉ですが…。

      manpageの内容をもうちょっと分かりやすくして

      これも言い方がありまして…。ただ「わからない」といわれただけじゃ、なにがわからないのかわからないんだ。具体的に、「ここの部分は、Aという解釈とBという解釈がありうるが、どちらの意味ですか?」のように訊いてみるとか、あるいは、具体的な修正案を提示するとか、していただけると嬉しい。下手に抽象的なことを言おうとすると、たいてい失敗して、しかも具体性がないので何が言いたいかわからない、という落とし穴にはまります。

      - 人の名前は xxx-san と「さん」を付ける。判っている人はこれが「日本語の prefix である」事を理解する。

      "-san" は prefix じゃなくて postfix ね。

      Thank you in advance for taking your time.

      "in advance" はないほうがいいかも。なんか、"Thanks in advance" が「よろしくお願いします」の英訳だと書いてあるサイトもありますが、「前もってお礼申し上げます」っていうのは、ひねくれた読み方をすれば「あとから礼をいう気はないからね」という意味になるので。"Thanks for taking your time" で十分ですよ。

      親コメント
      • "-san" は prefix じゃなくて postfix ね。

        それはこの業界で使うギャグだ。
        # prefix には「敬称」という意味がある。敬称という意味の場合は、
        # 前に着こうが後に付こうが「prefix」という。
        ## とネタを1つ潰された腹いせに、マジレスする (^w^)。

        Thank you in advance for taking your time.

        "in advance" はないほうがいいかも。なんか、"Thanks in advance" が「よろしくお願いします」の英訳だと書いてあるサイトもありますが、「前もってお礼申し上げます」っていうのは、ひねくれた読み方をすれば「あとから礼をいう気はないからね」という意味になるので。"Thanks for taking your time" で十分ですよ。

        うーむ。どちらかというと "Thanks for taking your time" は「時間掛けろや、仕事しろや、ゴラァ」という意味に取られかねないので、そちらの方が危険ですよ。

        .

        Thank you in advance は「あなたが時間を費やしてくれたその場で感謝のメッセージを伝えることができないので」先にお礼を言っておくね、と言う意味。つまり、「あなたが返事をくれようがくれまいが、作業を使用が姉妹が、私は感謝していますよ」という事。

        相手によっては、メールを受け取ったら返事を書かないで、いきなり man page に update をかけてしまう人もいるよね。で、こちらはこちらでメールをチェックしていても man page の最新版をチェックしてはいないので、更新されたことに気が付かなくて御礼が遅れたりする。

        なので、謝辞プロトコルが一般常識どおりに進むとは限らない相手の場合は、"Thank you in advance" を必ず書くことを薦めています。これが営業職とか相手だったら、心配しないんですけどね。

        --
        fjの教祖様
        親コメント
  • by Anonymous Coward on 2011年01月08日 11時21分 (#1885165)

    >これら国際的なプロジェクトでは英語が公用語として用いられるため、
    >英語で説明・論戦・説得・理解・合意などを行うスキルが要求されます。

    とりあえずバグレポートとか、改善提案とか、そんなのでも英語で説明したりは
    するんだけど。某拡張の日本語化(多国語化)もそんな感じで始まった。
    (これは開発者側が乗り気だったこともある。)

    最初はそんなレベルから始まったけれど、でもそれは「プロジェクト」とは呼ばないよね。

    • by Anonymous Coward on 2011年01月08日 11時52分 (#1885171)

      そうですね。私もまずはバグレポート程度からでした。
      それでも、英文メールを何回も読み直して、送信するときはどきどきものでした。
      返事が返ってきた(言いたいことがきちんと伝わっていた)ときには
      めちゃくちゃうれしかったものです。

      もう20年近く前のことですが。

      親コメント
      • by Anonymous Coward on 2011年01月08日 12時04分 (#1885176)

        そうですね。私もまずはバグレポート程度からでした。
        それでも、英文メールを何回も読み直して、送信するときはどきどきものでした。
        返事が返ってきた(言いたいことがきちんと伝わっていた)ときには
        めちゃくちゃうれしかったものです。

        バグレポートを詳細に記述(「このコマンドに不具合があった」「LinuxとSunOSで再現した」「このCのソースがおかしい」)して
        「このパッチで直る」とdiffの修正パッチも添付した長文のメールを1通、OSSのMLに投稿したら無視されました。

         

        その半年後に英語ネイティブの間だけで「こんな不具合があった」「あ、こっちでも再現した」ってやり取り始まって
        開発者から「勧告:このコマンドをしばらく使用しないように」なんてメールが
        MLに流れていたのを見たときには悲しくなりました。

        #出張中で気づいていなかった私が、帰ってきた直後に
        #「それ僕が半年前にパッチ送りました・・・」って涙目になりながらMLに投稿しました。
        ##その後に開発者から「Thanks!パッチ取り込んだよ!」のメール来ました

        ##教訓:長文の詳細なレポートより、まずコミュニケートしたほうが話は進むくん。

        親コメント
      • FreeBSD に patch 送って採用(?)されたことが私の一生の自慢です。

        キーリピートの修正 [freebsd.org]・・・これは自慢できる、かな。
        ATAレイヤーのタイムアウトに関して [freebsd.org]・・・タイムアウトの記述を見直せや、のプレッシャーにはなってるのかな。
        atacontrolの自己拡張 [freebsd.org]・・・これはどうでもいい、むしろ保存の場として逆利用している。

        いや内容的には些細なことなんですけどね。 でもシステムはこうした些細な前進の集大成であると。
        で今家庭内サーバー [so-net.ne.jp]を 6.2R から 8.x にあげようとしていて、自分だけのローカルパッチで逃げていた部分がはじめから修正されていたり、記述が見直されたりしていると 「情けは人の為ならずやな~」と感慨ひとしきりです。

        # ただし時間かかってます、2年がかりです、当時のメールアドレスはもう失効しました。
        親コメント
  • by Anonymous Coward on 2011年01月08日 12時04分 (#1885177)

    痛いのは最初だけだよ・・・

    • by Anonymous Coward

      そだね。最初は怖いけどすぐに慣れる。

      仕事で準備時間1週間でマレーシアに吹っ飛ばされたときに英語と中国語とマレー語っぽいのちゃんぽんで相手の言ってる言葉わからなくて身振り手振りだったけど、最終的にはなんとかなったもの。

      ただ絶対に必要なのは目的。
      参加させられるっていう状況が一番自分を落ち着かせやすいけど、自発的に参加するプロジェクトだと目的を見失うと簡単に自分も見失うのでタレこみAC氏には頑張ってほしいと思う。

typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...