メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

ネイティブに伝える為のロジカルさとは?

イギリス人のプレゼンテーション/ヴォイスコーチのChristianeから指導を受けているが、彼女とのディスカッションの過程でネイティブに対してわかりやすくしゃべる為には、ロジカルさが必須だと実感した。その顛末と気づきを共有したい。



1. イントロダクション




Christianeとの出会い


 私は昔から音楽が好きで昔はヴォイストレーニングに行っていた。また音楽をしたいなと思ってまたヴォイストレーニングをやってみようと思っていた。そんな時に、PechaKucha 20x20 - Tokyoという六本木で毎月やっているプレゼンテーションのイベントに参加していた。英語をガチで使う機会を求めて、英語のプレゼンが聞けるし、外国人の人が沢山来ているこのイベントはとても自分にとって楽しいイベントなのだ。自分は結構人見知りなので、「今日は自分から話しかけてみる!」というノルマを課していたが、自分が1人出来ていて、他に1人の人が見つからなかったこともあり、イベントが終わるまでそのノルマが達成出来ずにいた。

 イベントが終わった後に、1人でぽつんと座っている女性を見つけて話しかけてみた。それがChristianeだった。話を聞いてみると、イギリス人で、ヴォイスコーチをしているという。プレゼンテーションの指導もしていると話していた。自分にとっては、ボイスコーチで、しかもそれをブリティッシュイングリッシュを操る英語ネイティブが教えてくれるなんて夢のようだったので、彼女に連絡先を渡してレッスンをお願いする事にした。発声が良くなり、英語の発音イントネーションはもちろん、プレゼンの指導まで。これは楽しみだ! まずは、彼女とお話をして、進め方を話そうという話になった。


ほんのちょっとした違い


 彼女のサービスを利用するにあたって、彼女と話をした。彼女は、どういう事をしてほしいか聞いてきた。私は「発声を良くしたいこと、英語の発音/イントネーション、自分が発言している内容が適切かどうかの確認、プレゼンの指導をしてほしい」といったような事を言った。多分日本人の人が相手だと、「私のサービスで、きっとあなたを満足させる事ができると思うわ。料金はXXです。それでよければ、初回は何日にしましょうか?」という話になる流れのところだが、彼女の行動はそうじゃなかった。


まるで要件定義


 彼女は「要件を定義」し始めたのだ。「プレゼンの原稿のレビューはしてほしい?」「発音とイントネーションは入れてほしいのね?」そんなやり取りをして、彼女は、私の「要件」をリストアップして定義しだした。そのサービスがInでどのサービスがoutなのか。その後彼女はこういった。


「じゃあ、6月までの提案を作って送るわね。」


 数日後彼女がメールを送ってきた。こんな内容が入っていた。私の要求を全て満たしていて完璧だ。そして、曖昧さが全然ない。この時はこのちょっとした違いに気がついていなかったのだ。この内容でお願いします。という返信をして彼女にサービスをお願いする事にした。

28/4 Week 1
Meet to view your draft presentation and workshop format.
To check format, structure and any obvious amendment requirements.
Room optional, cafe OK.
2hrs

5/5 Week 2
Proof read presentation and workshop content. I would appreciate a copy to be posted to me as I prefer to work on actual documents.
Feedback any amendments and discussion. Face to face meeting. Room optional, cafe OK.
2hrs


12/5 Week 3
19/5 Week 4
Pronunciation, word stress, sentence stress, sentence flow. Room required.
1.5hrs

26/5 Week 5
Pronunciation, word stress, sentence stress, sentence flow. Room required.
1.5hrs

2/6 Week 6
Voice projection techniques, delivery style, coping with pressure. Room required.
2hrs
Handling questions. Room optional, cafe OK.
1hrs

9/6 Week 7
Presentation delivery coaching. Face to face meeting. Room required.
2hrs

16/6 Week 8
Presentation delivery coaching. Face to face meeting. Room required.
2hrs

23/6 - 29/6 Week 9
Travel to US / Conference


日本の現場だと、プロのエンジニアと話をするときも、こんなに明確にスパッとしたものが仕事の最初から出てくる事はまれだろう。ちょっとびっくりしてしまった。日本はすりあわせ文化なのだなと思った。


2. とんでもない課題



あなたの言っている事が全然理解できなかったのよ


私は6月にUSのAgile Roots » Amplify Learningというイベントでプレゼンをするのだが、その時に私が考えて、原田さんと一緒にお話する、Build Less Patternというお話をする予定だ。ソフトウェアパターンは、思いっきり技術的な専門用語だ。私は、彼女はソフトウェアの専門家じゃないので、英語的な文法とか、こんな言い方をしない。という事を指摘してくれるのだと思っていたが、全く違っていた。まず彼女が言ったのはコレだった。


「Build Less Patternとは何?」


私は一瞬?と思った。実は、彼女は、私の英語LTを見ている。1000 Speakers Conference in English 7 - 1000 Speakers Conference in English | Doorkeeperという吉岡さんがやっているイベントで私はカンタンにBuild Less Patternsのイントロだけ話してきたのだ。当日、話をしたら吉岡さんも「それは、いい考えだね!」と言ってくれいていたのだ。自分ではアドリブでトークしたんだけど、まぁ、それなりに出来たと思っていた。私が前にLTでやった無いようだよ。という話をしたら彼女はこういった。


「ごめん、当日あなたの言ってる事が全然理解できなかったのよ」


えええええーーー。全部英語で話したけど、少なくとも日本人には伝わっていたはず。Agile2011でもWorkshopのセッションを担当しているオーガナイザーのネイティブの人から一番いいセッションだったと言ってもらえた。一体どういうことだろう。


具体例よりも定義を明確に話す事


彼女が専門用語がわからないかな。とも一瞬思ったけど、そこまでさっぱりわからん内容でもないはずやのにという想いもあった。ただ、今回は結構概念的なお話だ。そこで、私は説明することにした。



「Build Less Patternって何?」



「そうだね、僕たちはソフトウェアを作っているだけど、ソフトウェアって余計な機能が沢山ついているのが多いじゃない。人間って、機能追加するのは得意なんだけど、減らすのってすっごく苦手なんだ。だから、機能を減らしやすくするための方法を纏めた物だよ。」



「うーん。理解できないわ。」



「そうだね、他の例でいうと、例えば、このWebサイトって、最悪じゃない、凄く機能が沢山あるよね。でもコレって機能たっぷりあるけど、ほとんどの機能ってほとんど使わないよね。」



「そうね。iPhoneとかもそうだわ」



「でも、このWebサイトはどう?凄くシンプルで、自分が欲しい機能だけあるじゃない?」



「そうね。」



「だから、本当は機能は多ければいいのではなくて、必要な物があればいい。でもなかなかこの取捨選択が出来ないから、取捨選択をしやすくするようなガイドがBuild Less Patternなんだ」



「?、で、Build Less Patternって何?


正直言って、自分は相当愕然とした。「俺ってこんなに英語ダメだったっけ、、、 orz」こんな体験は、アメリカでも、ベトナムでも、イギリスでもなかったので、そうとう絶望的な気分になった。そんな様子を見ていたのか、彼女は日本に来て3年だから、日本人に慣れているのだろう。こんな絵を書いてくれた。


 日本人のプレゼンテーション(左の絵)は、いつも、だらだらしていて、全然結論がわからないのよ。西洋のプレゼンテーションは、このハンバーガーの様に構成が決まっていてロジカルなの。イントロダクションがあって、ボディがあって、コンクルージョンがある。凄くロジカルなのよ。


3. 解決の糸口


 これを聞いて自分的に「あぁ!」と思う事があって、しゃべり方を100%変えてみた。


「ちょっと、まって、考えさせて!」
「Build Less patternは、ソフトウェアパターンの一種だよ」
ソフトウェアパターンというのは?」
「ソフトウェアの開発で繰り返し使われている、課題に対するソリューションのカタログだよ」
「なるほどね」
「例えば、、、、、」


その時点で、彼女も嬉しかったのか「やっと通じた!」見たいな感じでハイタッチをした。良く我慢してくれたものだ。ここまでに私は時間を45分は使っていたと思う。


ロジカルさと明確さ




その後もディスカッションで、自分が思ってもいなかったような定義の説明を求められたりした。そしてその後も


「このit is said のitって何を表しているの?」
「このweって、誰の事?あなたとKiroのこと?」


文脈でわかるやろー。みたいな事もことごとく彼女は明確にしていった。その後プレゼンの構造もレビューしてもらってるがその時のも


「ここで、この話が出てくるのはおかしい。だって、この見出しからすると、この節の内容があわないわ」


とか、日本人だったら誰も気にしないような構成の曖昧さを指摘してきた。



具体例と定義と


 我々日本人は「具体例」の方がわかりやすいと感じる傾向にあると思う。無意識的に。だから、いつも「具体例」で説明してしまいがちだ。逆に定義なんて普段の生活でそんなに重要視していない。でも少なくとも彼女は、具体例の前に「明確な定義」が必要なようだ。そういえば、海外の技術書籍は概念があると、必ず「定義」が明確に書いてあり、「具体例」はあまり重視されない。たまに「ソースコード全部載せてよ」と思うけど、一部しか載ってなかったりする。一方日本の書籍は、具体的な定義は曖昧だが、具体例が沢山載っている事が一般的だ。


 その次の日にたまたま出版社の人とお話をしたら同じような事を言っていた。「日本では、とにかく、定義はいいから、どうやったらいいか教えろって本しか売れないんですよ。向こうは逆で、「それは何だ?」と定義が重要視されるんですよね〜。」と。向こうの本の方が本質的な事が書いてあるから好きとは感じていたけど、本質的な考えの違いがあるようだ。

 どうやら、以前プレゼンしたときは、ある程度、概念のコンセンサスがある中での説明だったので、対応できたのだろう。共通のコンセンサスが無い環境が来たらもう終わりだと実感したのだった。



算数の教え方を比較してみた


 ロジカルさがないと、コミュニケーションが上手く行かないと感じた私は英語で難しい概念をカンタンに説明している例をみて、ロジカルな説明が出来るようになろうと思い立って実際やってみた。「算数」の学び方なんてどうだろう。海外サイトをサーフして、Math is Fun - Maths Resourcesというページを見つけて説明を読んでみて愕然とした。


「あー、全然違う」


最初に明確な定義があり、その後にロジカルな分類、そして例と言ったような構成だ。皆さんも自分の目で見てほしい。そして、更にびっくりしたことに、自分が気にしてもいないような事が定義されている。例えばデータの定義なども明確にある。


What is Data?

Data is a collection of facts, such as values or measurements.
It can be numbers, words, measurements, observations or even just descriptions of things.

Qualitative vs Quantitive

Data can be qualitative or quantitive.
- Qualitative data is descriptive information (it describes something)
- Quantitive data, is numerical information (numbers).
    :


これを見て私は思った「うぉー。子供の頃からこれかよ、、、そらわしらとは細胞レベルで違うわ」そして、わかりやすいとも思った。こんな厳密なレベルで言葉を意識したのは、オブジェクト指向とか、データモデリングをアカデミックに学んだ時位しかない。普段の生活では全く意識すらしないだろう。

 そして、「わしらは、子供の頃ってどうやったっけ」とおもって、同じようなサイトを探してみた。しかし、探しても、探しても、明確な定義が載っているページはなかった。例えばこんな感じ。



算数の教科書の見開き例
学校図書株式会社 小学校 算数



 つまり、例とかで、「解き方」を教えて、その後は「とにかく問題を沢山やってみよう!」「こう解くんだよ」というノリだった。確かにそんな感じだった。


わかりやすさの違いを意識して話をする


 きっと、我々と、西洋文化の人たちは、「わかりやすい」というのは共通の概念じゃなくて「わかりやすい」というのは根本的に違うというのを実感した。これは、日本ダメよね。という話ではなくて、日本の人は「やり方」で学んで、西洋の人は「定義」から学び感じ。なので、全然発想からして違うのだと思う。それを考えると「守破離」というのもきわめて日本的なやり方だと思う。メリットとデメリットがあるだろう。
 しかし、数学とか、コンピューターの分野の場合は、ロジカルに発想している方が、今の自分にはずっと明確で、カンタンで、わかりやすく感じた。
 そして、英語を勉強している身としては、単に英語の文法とか、表現を学ぶだけでは、通用しないこと、英語を話しているときは、もっともっと、ロジカルに考えて話さないと、先方にとってわかりにくいという事を身にしみて実感をしたので、その後は、出来るだけ定義を意識し、明確に、ロジカルに話すように練習をしているところだ。



 後日、自分が通っているBritish Councilという英会話教室で、Third conditionという用語が出てきた。彼女は日本人に具体例で説明して、定義を話さなかった。教室がおわったあとで、彼女に「Third conditionの定義は?」「ThirdはなぜThirdなのか?」というのを個人的に聞いたら、にっこり微笑んで非常にロジカルに説明してくれた。こんな事をきいたら、日本人だったら、若干嫌な顔をされるかもしれないが、快く教えてくれた。
 もしかすると、彼女はプロの英会話教師なので、日本人にあわせて説明してくれていたのかもしれないが、そういうレベルまで向こうの人は明確に説明できるのかもしれない。


まとめ


・日本と西洋文化の「わかりやすさ」は全然違う
・英語で話をするときは、定義、明確さ、ロジカルさを意識して話をする
・自分が思っているより、相当自分たちはロジカルではない。文化的な背景があるから


これは、自分の個人的な体験で、Christianeだけもしかするとイギリスとアメリカは違うかもしれないので、他にいいご経験をされておられる人は是非コメントをお願いしたい。


PS. 後日この本読み始めましたw


Being Logical: A Guide to Good Thinking

Being Logical: A Guide to Good Thinking

  • 作者: D.Q. McInerny
  • 出版社/メーカー: Random House Trade Paperbacks
  • 発売日: 2005/05/10
  • メディア: ペーパーバック
  • 購入: 1人 クリック: 6回
  • この商品を含むブログを見る