2013/05/26

プロ通訳じゃないソフトウェアエンジニアが #agilejapan 2013 のTDDワークショップで通訳した時に気をつけたこと

5/24(金)に開催されたAgile Japaan 2013の『Test-Driven Development for [Embedded] C』というワークショップ(講師:James Grenning 氏)で通訳をやりました。以前、Agile Samurai Dojo GatherningでJonathanさんと参加者の通訳をやったことはありますが、ちゃんとしたワークショップで通訳をやったのは初めてです。


今回、個人的に非常に勉強になったので、自分の勉強の整理のため今回の体験をまとめておきました。もし同じようなことをやるどなたかの役に立てば幸いです。

※なお、このエントリは講師が外国人、受講者が日本人、日本語と英語の逐次通訳(通訳元の人が話し終わってから通訳をやるスタイル)を想定しています。

なぜ通訳をやることになったの?

最初にそもそも通訳をやることになった経緯を先に説明しておきます。

私は講師であるJames Grenningさんの著書「Test Driven Development for Embedded C」の読書会を東京で開催しており、その翻訳書である「テスト駆動開発による組み込みプログラミング ― C言語とオブジェクト指向で学ぶアジャイルな設計」の翻訳レビューにも参加していました。ちょうど翻訳が落ち着き始めた去年の年末、監修者の蛸島さんに、レビュアーの私が「本の販促でJamesさんを日本に呼べませんかね?出版後だとAgile Japanですかね」と提案しました。Agile Japanでは海外スピーカーをゲストに呼んでいることは知っていたので、もしかしたら実現できるかなと思ってい方からですね。そこから、2人でAgile Japan運営委員の方にJamesさんをキーノートスピーカーとして呼べないか交渉しにいきました。

当初は、何か難しい交渉になるのかと想定していましたが、運営委員の平鍋さんも「いいですね!Jamesさんは前から呼びたかったですよ!」といきなり快諾。意外と話が早く進みました。実際の来日の交渉はAgile Japan運営委員の方が担当され、私は蛸島さんとTDDのワークショップの通訳および補助として準備をやらせていただくことになりました。

技術的な通訳の基本

通訳と言えば、日本語を英語に、あるいはその逆に置き換えたらいいんでしょう?と連想されるかもしれませんが、実際の通訳は少し奥が深いと思います。私が頭に思い描いている通訳の作業は以下の通りです。

※実際には以下の作業は日常の英会話で常に意識していることですが・・・
  1. 通訳元となる言語を聞いて理解する。
  2. 1で話している内容の意図を把握する。通訳する内容を整理する。
    • 元の直訳すると伝わりづらい場合、頭の中でもっとシンプルな表現に置き換えます。また、意図が分からない場合質問して確認したりします。
  3. 通訳先となる言語に単純に置き換える。
  4. 3の内容をより自然な表現にして発話する。
    • 実際には3→4は一瞬で行われます。

この時、純粋に通訳と言われて想い描くのは3(機械的な言語の置き換え)だと思われますが、実際には通訳の元の意図を損なわず、かつ通訳の先に意図が伝わるようにするために工夫が必要になるのです。これは通訳する両言語の言語能力が必要になる他、通訳対象の専門知識が必要になります。なぜかというと対象分野によって適切な語彙が違うため、対象分野の専門知識がないと適切な語彙が選べないからです。聴講者は何を言っているのか分からない状態になってしまいます。

例えば、翻訳の例になりますが、Amazonで「翻訳がひどい」というレビューを付けられている翻訳書は前述の作業が適切にできなかった例だと考えられます。これは2の原文の意図を把握する作業ができていなかったり、対象分野の知識がないため3の狭義の通訳ができていなかったり、4として翻訳先の日本語が推敲されていなかったりして起きているのだと思います。

ワークショップの通訳って何をやるのか?

では、技術通訳が分かったとして、ワークショップでの通訳は何をやるのでしょうか?それはワークショップによって内容が違うと思いますが、基本的には2つだと思います。

  • 講師の説明を受講者に通訳する
  • 受講者と講師の質疑応答を通訳する

前者については講師がキリがいいところまで話をして、そろそろいいかなと頃合いを見計らって、通訳した内容を受講者に伝えます。明確に講師から通訳してくれと指示がある場合もあるでしょう。ただし、今回は講師が説明内容や受講者の様子に集中している雰囲気で、通訳側が通訳を差し込んでいいタイミングを見計らって通訳する感じでした。

後者の質疑応答に関しては、質問内容を聞いて、質問者に「質問は○○ですね?」と意図を確認して、講師に通訳します。講師が解答をしたら、その逆をやります。

通訳の準備として何をしたらいいのか?

(1) 専門知識の習得

前述のとおり、通訳する上では対象領域の専門知識が必要です。対象領域の知識を習得する他、ワークショップの資料を必ず隅々まで読んでおくのは必須です。そして、可能な限り、講師の著書、ブログ記事、インタビュー記事を読み、インタビュー動画も見ておきます。これでワークショップの内容を理解し、さらに講師の話し方、発音の仕方、よく使う語彙、説明のパターンなどを把握します。コレをやっておくと当日、「あ、あの話かな?」と推測がつくようになります。

(2) 通訳の練習(英会話カフェ、Skype英会話、シャドーイング)

次に通訳自身の練習は専門の書籍がたくさんあるのでそっちを読んでください^^; 私がやってたのは英会話カフェやSkype英会話での英会話の練習、そしてPodcastを聞きながらシャドーイングしたり、見聞きしたものを英語に置き換えたりする練習をしていました。といっても、これは普段やっていることなので特別このためにやったわけではありませんが^^;

今回の通訳の振り返り(Keep、Problem、Try)

では、最後に今回の通訳の振り返りをしておきます。

Keep(良かった点、続けて行きたい点)

(1) 対象領域の知識を習得する時間を豊富に持てた

結果的にではありますが、今回通訳する前に原著の読書会をやり、インタビュー記事を書き、翻訳書のレビュー、今回のワークショップの資料翻訳をやっていました。ワークショップの内容は頭に入っている状態だったので、この点はほとんど心配はありませんでした。

(2) 講師と密に打ち合わせでき、講師の不安を解消できた

ワークショップ1週間前、そしてワークショップの2時間前に講師と打ち合わせをしました。ワークショップの流れ、どこで質問を入れるか?、デモはどのPCでやるか?などを講師と確認してお互いに疑問点を解消できました。おそらく講師の心理的な不安を事前に解消できた点は大きいと思います。

(3) ワークショップ中、アイコンタクトなしに自然と通訳できた

最初は講師に通訳するタイミングを指示してもらう予定でしたが、それでは気が散りすぎるので、本題に集中してもらうため、通訳を入れるタイミングはこちらで図ることになりました。講師はただ自然にワークショップを進行出来るように努めました。ときおり、間違えたり、講師の説明が分からなくて聞きなおす場面もありましたが全般的には上手く言ったと思います。

Problem(問題のあった点)

(1) 資料を完全に翻訳してしまい、講師自身が資料を読めなくなってしまった

今回、通訳がアマチュアである点を考慮して、翻訳した資料を投影した方が受講者にとっては良いだろうと判断して、講師の許可をもらって日本語版を投影しました。しかし、実際には(当たり前ですが)講師が資料を読めなくなって進行状況が分からなくなる事態がたびたび起こりました。手元に原文を用意していたので、手元の原文を確認しながらの説明になったので、講師に認知的負荷を与えてしまったことを申し訳なく思いました。

(2) ジョークが通訳できなかった^^;

講師は気さくなアメリカ人であり、ちょいちょいジョークを挟んで場を和ませようとしました。ところが、通訳がジョークを理解できなくて、講師に確認しようとして、講師に「もういいよ、次いこう」と言われてしまうことがあり、受講者にも逆に笑われてしまうことがありました^^;

Try(次回改善したい点)

(1) 資料は原文に日本語字幕を付ける

講師と受講者双方が理解できる落とし所として、キーノートの資料(平鍋さん翻訳)のように原文に日本語字幕をつけるやり方が良いのかなと思います。

(2) ジョークも通訳できるようにする

これは経験と sense of humor が必要ですかね?^^;

おわりに(初の通訳を終えてみて)

まず、今回の機会を与えていただいたアジャイルジャパン事務局の皆様ありがとうございました。TDDと通訳の両方において非常に良い勉強の機会となりました。今回の体験を今後の私の人生においても飛躍のきっかけにしたいと思います(おおげさではなく)。

そして、翻訳書監修者の蛸島さん、翻訳から始まりワークショップの実施まで一緒に作業し、いろいろ提案やアドバイスを頂いて助かりました。今回は2人でないと負荷が高くてこなせなかったと思います。ありがとうございます。

そして、講師のJamesさん、つたない通訳でしたが逆にフォローしてくださってありがとうございました。気さくな人柄で、なんでも提案を受け入れてくれる懐の広さに感激です。

以上。また通訳する機会あれば今回の振り返りの結果を生かしたいと思います。

2013/05/25

#agilejapan 2013 キーノート1「Demand Technical Excellence」 by James Grenning の感想

5/24(金)に開催されたAgile Japan 2013に参加してきました。このエントリーでは参加できなかった人向けにキーノート1つ目 James Grenningさんの"Demand Technical Excellence(邦題:アジャイルにおける品質と技術の重要性)"について講演の概要と私の感想を残しておきます。



最初に所感を述べておきます

Agile Japanの帰り道、もやもやとキーノートの内容について考えていました。最初にアジャイル言い始めたおっちゃん達の一人であるJamesさんのメッセージは何だったのか?

今回のJamesさんの講演のメッセージはアジャイルマニフェストで言っていることと同じだと思います。こうじゃないでしょうか?
「未熟な個人をプロセスやら何やらでがんじがらみにするという考え方はやめよう。個人が自立したプロフェッショナルとなり、顧客も自分も満足できるような仕事を自分の力でやろう。そのために必要な学習はやろう。自分が自分の組織を変える旗手になろう。」
安っぽい自己啓発みたいですんません。

がんじがらめにされるのは楽なんですよ、何も考えなくていいから。自分で考えて、自分で行動するのは怖いですよね。失敗するかもしれないし、おかしなこと言っていると他人に笑われたるするかもしれないし。でも、自立していない状況で仕事しても楽しくないし、成果もついてこないですよね。何でもいいから、1つコレだといのを見つけて、実践して、他人と協調して何かをやりとげていく。そういうことを継続したいなと思う次第でした。

そして、Jamesさんの「dogma follower(宗教信者)になるな」という言葉はちょっとドキッとしました、手段が目的化しやすい自分への戒めとして手帳に書いておきました。周りが見えてへん状態にならないよう、自分を客観視したり、人の意見は素直に聞ける謙虚さ、冷静さも持っていたいです。

スピーカーのJames Grenningさんについて

プログラムに書かれているとおり、最初にアジャイルを推進した人の一人であり、現在も世界中の組み込みソフトウェア開発の現場でコーチングやトレーニングを行なっている方です。

James Grenningさんの発表について

大きく分けて3つあったのかなと思います。

  • アジャイルマニフェストが書かれた背景
  • アジャイルマニフェスト10周年で挙がった課題
  • 今、現場が取り組むべきこと(開発者、スクラムマスター、マネジャー)

なぜアジャイルマニフェストが書かれたのか?


アジャイルマニフェストが出される前に主流だったのは「プロセスさえちゃんとしていればいい。モジュールも開発者さえも交換可能な存在だ。」というもの考え方だったそうです。理論的土台となっているのがWatts S. Humphrey氏の「Managing the Software Process」。CMMIの元ネタだそうです。

JamesさんはWatts S. Humphrey氏自身がそう言ったわけではないけどと断りを入れながら、産業界のメッセージは「プロセスがすべてで、人は取り替え可能」だったといっていました。それに対して、そうじゃないよね、人が一番重要だよねと言ったのがアジャイルマニフェスト著者達で、彼らの考え方がまとめられたのがアジャイルマニフェストのようです。

これは以前公開したJames Grenningさんのインタビューで同じことを語っている事に気づきました。

驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。
それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。

日本の多くの現場ではどうでしょうか?人の協調を重要視することが日本の製造業の強みだったように思えますが、今の現場で同じことができているでしょうか?ただ、アジャイルコミュニティの活動の成果か、今変化の途上にある気がしますね。

アジャイルマニフェスト10周年で挙がった課題


アジャイルマニフェストが書かれたのが2001年。2011年は10周年ということで、アジャイルマニフェストの著者が10周年を祝うパーティーが開かれたそうです。そこで、今アジャイルコミュニティが抱えている問題について話し合ったのだそうです。

そこで挙がった今後アジャイルコミュニティがやるべきことは以下の2つだそうです。
InfoQを見ると実際には4つありますが、この講演で強調したかったのはこの2つのようです。

  1. Demand Technical Excellence(卓越した技術を求める)
  2. Promote Individual Change and Lead Organizational Change(個人の変化を促し、組織の変化を導く)

なぜ卓越した技術を求めるのか?


ここでScrumの父Jeff Sutherlandの言葉を引用しています。「The biggest problem worldwide for Scrum teams is getting shippable code at the end of every sprint. 」多くのスクラムチームで各スプリントの最後にリリース可能なコードを実装することに大きな問題があるようです。

Jamesさんによると、これは未だに1970年代の開発手法を続けている開発者が多くいるからだということです。それはdebug later programming。実装した後にprint文やデバッガのステップ実行でバグつぶしをやる方法です。この開発手法は、「後でバグを見つけて取り除く」手法であり、バグの混入は許容してしまっているわけです。さらに開発規模の増大に伴い、テストの規模が増大すれば、テストできない範囲にバグが混入され、一番最悪なタイミングにこそバグが見つかって、プロジェクトは大炎上してしまうのです。

debug later programmingの問題に対してJamesさんが提案しているのは「ScrumとXPの結婚」。XPで定義されていた進化的設計に必要な技術プラクティスを見つめなおすことです。

XPの技術プラクティスの中でもJamesさんが一番取り組んでいるがTDDです。開発とテストを連続させ、バグを未然に防止する方法ですね。Jamesさんによるとコンピュータサイエンス分野で有名なエドガー・ダイクストラの言葉「デバッグに時間を浪費するのではなく、バグの混入を最初から防ぐ」を実現する取り組みだと話していました。

今、現場が取り組むべきこと(開発者、スクラムマスター、マネジャー)


現場に対してJamesさんが推奨しているのが「2. Promote Individual Change and Lead Organizational Change(個人の変化を促し、組織の変化を導く)」だったと思います。個人が自立したプロフェッショナルとして成長し、自分が起点となって自分の組織を成長させていこうというアドバイスです。Twitter界隈でもここの言葉に同意している人は多くいたように思えます。

開発者がやるべきこと

  • ものづくりのエキスパートになれ
    • (TDDをやる時間がないって本当?バグを追いかけている時間があるんならテストを書いてデバッグ時間を減らしたらいいんじゃないの?)
  • 新しいことを学習し、挑戰しよう
    • (今21世紀だよ?未だに70年代のdebug later programmingやってるってどういうこと?良い本がいっぱい出てるからまず読め!)
  • 信頼を築き、自分の仕事を包み隠さずチームに見せよう
    • (自分の弱みを見せることを恐れるな、他人に失敗を知られることを恐れるな、包み隠さず明らかにしないと人は成長しない)
  • 自分の組織のアドバイザーになれ
    • (ボスがTDDをやらせてくれないって?じゃ、君がTDDのプロになって上司に教えればいいだろ?)

スクラムマスターがやるべきこと

  • 同僚が問題解決者になるよう勇気づけよう
  • 宗教信者になるな、君はスクラム”マスター(主人)”であって、スクラム”スレーブ(奴隷)”じゃない
    • Scrum研修で教えられていることを絶対視するな、手段を目的化するな

マネジャーがやるべきこと

  • 優れたチームを育てよう
  • チームのモチベーションを上げようとするな
    • 人のモチベーションを上げることは難しい、無理にやろうとしないこと
    • 無茶苦茶な納期を指示したり、生産性の低い作業をやらせなければ、本来プログラミングは楽しいはず!
  • モチベーションを下げるのをやめよう
    • モチベーションを上げるのは難しいのに、下げるのは簡単。余計なことをしないでいい。

最後に小ネタ

キーノートの感想などはおしまいですが、裏話を1つ。「テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」の翻訳が落ち着き始めた去年の年末、監修者の蛸島さんに、レビュアーの私が「本の販促でJamesさんを日本に呼べませんかね?出版後だとAgile Japanですかね」と提案しました。そこから、2人でAgile Japan運営委員の方にJamesさんをキーノートスピーカーとして呼べないか交渉しにいきました。

何か難しい交渉になるのかと想定していましたが、運営委員の平鍋さんも「いいですね!Jamesさんは前から呼びたかったですよ!」といきなり快諾。まじですか!!実際の来日の交渉はAgile Japan運営委員の皆様が担当され、私は蛸島さんとTDDのワークショップの通訳および補助として準備をやらせていただくことになりました。

ワークショップについて別途エントリを書きますが、なかなか楽しいものでした。Jamesさんを日本に招聘する活動に携われ、日本の開発者が奮い立つようなキーノートを聞けて、大満足でした。コミュニティの可能性を感じる日々でした。関係者の皆様、ありがとうございました。また、よろしくお願いします!