生産性を向上させるためには、日本人エンジニアに英語での会話力は必須だと思った
私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は同僚からの何気ない一言からの気づきをシェアしたいと思います。
David からの何気ない一言
私は無宗教で葬式の時は曹洞宗なのですが、以前から聖書には興味がありました。私の叔父はドイツ、アメリカに長年住んで仕事 をしていました。そんなガチに海外で生活していた彼が言っていました。
彼らの文化を理解したかったら聖書を読むのがいいよ
確かにイギリスにいた時もあらゆる場面で、日本に帰っても海外の映画を見ても様々な場面で、聖書の影響を感じます。 私は自分の仲間をより理解したいし、明るさ、生産性の高さ、芸術性などを本当に尊敬しているので、是非ともその考えを学んでみたいと思っていました。
私の尊敬する同僚の David もクリスチャンなので、彼にどの聖書を読んだらいいか教えてもらいました。スノボに行った時も会話しましたが、昨日改めて私に一番あった聖書を選んでくれて、一言こう言ったのです。
君がこの本を読んで、一緒にディスカッションをするのを楽しみにしているよ。
たぶん、日本人だったら、自分がよく知っている分野の本をお勧めした場合、こうは言いません。きっと「読んだら感想聞かせてな」だと思います。
初めてその分野の本を読もうとしている人に「ディスカッションをしよう」という発想自体がありません。
マイクロソフトではやたらディスカッションが多い
そういえば、自分のチームもやたらディスカッションが多いことが頭によぎりました。一方的な情報伝達の会議みたいなものはほぼなく、 定例会議も例外なく、ディスカッション形式のものです。もしかすると、日本でイメージするディスカッションとUSでのディスカッションは意味が 違うのでしょうか？英英辞典で調べてみました。
If people discuss something, they talk about it, often in order to reach a decision。
talk about something with a person or people
違う辞書で調べてみましたが、1. の場合はほぼ同じイメージ。ただ、2. の場合は、日本人の持っている「議論」よりは「お話し」 というノリに近い感じです。しかしどちらの定義も日本人が持っているイメージよりずっと気軽に話をする感じです。
ディスカッションはバトルではなく、楽しいもの
自分が持った違和感の正体を考えてみると、「ディスカッションはその対象をよく知っている人同士がやるものである」というイメージがあることに気が付きました。では、「ディスカッション」は何のためにやるのでしょう？
私が持っていた「ディスカッション」のイメージを掘り下げると、意見を交わして「どちらの意見が正しい」みたいなことを決定する勝ち負けがあるものでした。確かにそのイメージだと、初めてその本を読んだ人が、ベテランと話をしても意味がなさげです。
これは先の 1. の方の意味合いに近いです。だから「ディスカッション」はバトルみたいなイメージがありました。でも実際に、自分のチームで活動をしてきた経験を思い起こしてみると、どうも 2. のほうがよっぽど機会が多く感じます。
その目的は
「お互いが持っている意見を交換して、知識や考えを深めること」
で、ディスカッションは「楽しいもの」というイメージがあります。ディスカッションをすることで、自分のわかってなかったこととか、気づいていなかったことを知ることができます。これは楽しいことです。
本や資料を見ることは一方通行のコミュニケーションですが、フィードバックがあるので相当短い間に高い位置に近づくことが できます。そういえば今のチームのコミュニケーションでは、一方的に伝達があるコミュニケーションの形態はほぼありません。
よくよく考えると、考えを「深める」というと、「その分野をよく知っている人だからできる」というイメージがありますが、 知識「０」の人だって「０」から考えを「深める」ことは可能です。
何かを一から学ぶにしても、一方方向で本当に理解できているかわからないことより、双方向のほうがフィードバックを得られるので、明確にわかってないことがわかりますし、一緒にいる人もわかっていない部分を「ちがうんとちゃう？」って言ってあげることができます。これはすごく生産的だしうれしいことですね！
「間違えてたら恥ずかしい」感覚はもったいない
自分の心に聞いてみると、自分が持っている「初心者のうちはまず自分で学んで、成熟したらディスカッション」という考えの裏には「自分がいうことが間違えてたら恥ずかしい」という感覚があったように思います。
以前このブログでも書きましたが、自分がどんなレベルになっても、「知らないものは知らない」し、「理解を間違えているものは間違えてる」だけであって、だれでもあるし、恥ずかしくもなんともないと思います。それを知っているふりするほうがよっぽどかっこ悪いし、他人のそれを許容しないのもチームの生産性を考えるともったいない気がします。そして、それを後でこっそり調べるのも本当に生産性的には無駄な作業だと思います。理解できるまで聞いちゃえばその場でバリューが出ます。
自分にとってわからないことを聞くだけでも十分
そう考えると、ディスカッションをは「どっちが正しい」とかまったくもってどうでもいいことで、「自分の考えが自分なりに深めるための行為」と考えると、初心者時代からそれをやったほうがよっぽど効率がよさそうです。
ちなみにディスカッションといっても、素晴らしい意見をいうとかじゃなくても全然かまいません。「教えてもらったけど、俺全然理解できてないわ」とか、「この用語ってどういう意味？」とか、ある意味理解できてなくてかなり的外れなことを言ったり、質問したりしてもそれで充分なディスカッションです。素直な気持ちを隠さず表現すればいいだけです。誰も「的外れだから勉強して来い」とか言いません。
だから全然自分にとって知りたいことをお話しするだけで十分です。
合意できないことに合意できる
日本のマイクロソフトのエバンジェリズムのトップを務める伊藤かつらさんに教えてもらった言葉で「Agree to disagree」というのがあります。
「合意できないことに合意する」という意味です。別に合意なんかしなくても、どっちが正しいとか強引に決めなくても、相手のことを理解する助けになりますし、それでいいのではないでしょうか？ そう考えると、自分の考え、知識を深めることができるなんて、なんてディスカッションって効率的だしなんて楽しいんでしょう！これが、「正しくないといけない」とか「議論に勝たないといけない」とか思うとめんどくさいし、楽しくなさそうです。そしてどうでもいいですね。
思い起こしてみると、同僚がディスカッションをして意見が違うことがあっても、感情的になったり、揉めるとかそういう場面を仕事では見たことがありません。自分の意見を「こう思う！」というのはいいますし、「合意」に達しないことはありますが、「自分の理解を助けてくれてありがとう」といったノリであることが大半だと思います。
だから彼らはディスカッションしたがるんじゃないかなと思いました。
技術者には英語での会話力が必要
我々エンジニア系の英語に対する意見はいろいろあって、コンピュータ系の場合は英語はできたほうがいいという意見が多いですが、「読み書きさえできればいい」「話す機会はほぼないから、せいぜい講演が聞けたらいい」とか、そういう意見が多くて、「会話」はあまり重視されていません。正直言うと、私も英語の勉強が趣味だから会話は練習しましたが、正直「エンジニアとして必要だから」勉強したという感覚ではありませんでした。
しかし、今、初心者の頃から「ディスカッション」をさせてもらえることの楽さと効率の良さが理解できてくると、今の自分のしょぼい英語力が本当にはがゆくなります。
私の同僚はUSの人はすくなくて、私と同じように2nd Language learnerがほとんどです。ヨーロピアンとか、南米とか、インドの人とか中国の人とか皆、ガンガンにディスカッションをします。よく聞くと彼らの英語力が素晴らしいかといえば微妙かもしれませんが、それでも自分の思ってることをガンガン伝わるまで話して、ほかの人の意見も理解できるまで聞いてディスカッションをしまくっています。
むしろ「わかってない」からディスカッションする
私は、彼らがそのことをよく知っているからだと思い込んでいましたがよくよく思い起こしてみるとそうじゃないのかもしれません。むしろ「わかってない」からディスカッションをするのではないでしょうか？
今の実力とか、あってるか否かは関係なくて、自分がそう思っていることを話してそれでフィードバックを受けて、お互い影響しあって、考えや知識を深めて、そして話終わったら、お互い「助けてくれてありがとう」という感じの気がします。
今はスカイプや、音声チャットなど普通にできます。チャットでもできますが、音声のほうが１００倍以上情報量がありインタラクティブ性があり、フィードバックが早いです。日本人でも、すごくイケてる技術者の人は、知らないことを知らないと素直に言うし、自分の意見が合ってるとか間違っているとかを恐れず、自分の意見をシェアします。
こういう楽しい「ディスカッション」ができる体質に多少なりともなることで、いろんなことが楽になるし、効率的になっている気がします。
日本だけに閉じているのはもったいない
そうなると、こういうすごく効率的なことを「日本国内」だけでやるのはパイが少なすぎるので、すごくもったいないと思います。例えば私は、DevOps のことが分からなければ、DevOps のことに超絶詳しい David やチームメートとディスカッションすることができます。海外カンファレンスに行けば、著名な本を書いている経験ある著者と直接ディスカッションができます。これは本当に効率的なことです。
こんな楽ちんになることが、英語の会話力がないばっかりに、この恩恵を受けられないとなると相当効率が落ちてもったいないです。逆にもっと会話力があれば、もっと楽に知識を深めれるのに！！！と思うわけです。私も歯がゆいのでもっと高めたい！
最近はディスカッション重視のカンファレンスが増えているように思います。DevOps Daysなども、著名な人のプレゼンオンリーより、参加者同士のディスカッションが重要であるようです。それも今ならそちらのほうが価値があると十分うなづけます。
いわゆる「英語力」ではない「会話力」が重要
ただし、ここでいう「会話力」は英語のTOEICのスコアが高くなってから、、、とかじゃなくて、たとえそれが300点台であっても、自分の言ってることを伝え、相手の言っていることを理解する「気合い」もしくは「慣れ」の要素での「会話力」だと思います。
私も昔イギリスに行っていたときに、英語力が下から２番目の「Elementary」のクラスの奴が、イギリス人のネイティブの女の子をナンパしようとしていました。（そして会話が成立していましたｗ）別に高度な表現を使う必要はなくて、しょぼかろうが、単語だろうが、伝える、理解しようとする意志の問題だと思います。正直私もここはまだうまくできていませんが、技術ではなく意識の問題じゃないかと思っています。今までは「会話力」のメリットをそこまで感じませんでしたが、「ディスカッション」の楽さと効率性を知ってしまった今となっては是非身に着けたい能力です。
まとめ
そういえば、昔、スクラムの第一人者の江端さんがこんなことを言っていました。
僕は本を読まないんですよ。直接作者に会いに行きます。
当時は単に「スゲーな！」と思いましたが、今考えると、最も効率的に新しい技術を学べる素晴らしいTipsと思います！ 是非皆さんも「ディスカッション」の楽しさを実現するために、まず自分から一歩を踏み出してみませんか！海外の話だけではなく、自分から、自分の職場で「楽しくディスカッション」することから始めてみませんか？
というか、私がまずやってみたいです！ 日米の環境問わず、こんなことから始めてみようと思っています。
- 素直に自分の思ったことを言い、理解できるまで相手の話を聞くようにする （日、英関係なく。自分のレベルや、あってるかは気にしない）
- ディスカッションは、お互いの知識を深め合うための助け合い行為だと思って話をする
- ディスカッションを楽しむ。意見が違う人がいても、フィードバックが得れたとか、違う意見が聞けたと喜ぶ
- 知らないこと、よく理解できてないことほど正直にそういう。たとえ相手がだれであっても。結局そっちのほうがフィードバックを得られ、誤解もなく、得ができる。
そして
- 自分や、相手が、「知ってる」か否かどうでもいいこと。今の瞬間から、お互いの位置から、お互いが知識をシェアして高めあうことを助け合い、楽しむことに集中する。今、その瞬間の楽しみと、生産性の向上に注力する。
ということを心がけて、明日から実践してみたいと思います。実験なので、何かまた気づきがあればシェアしたいと思います。
とりとめがありませんが、自分のメモとして。
私は Infrastructure as Code をわかっていなかった
私はここ１週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。
それは次の一言です。
Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。
もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか？そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭によぎります。
Chef (software) - Wikipedia, the free encyclopedia
ここ数日様々な記事やビデオを見て Infrastructure as Code について再考してみたのでここに共有したいと思います。
Infrastructure as Code 再考
まず定義から行きましょう。David 本人が定義している Infrastructure as Code は次の通り
Infrastructure as Code とはソフトウェア開発で実施されてきたテクニック、プロセス、そしてツールセットをシステムやアプリケーションやミドルウェアのデプロイやコンフィグレーションの管理に役立てるための戦略のことである
itproguy.com – DevOps practices
DevOps Practices | IT Pro Guy & Tesar.info
他も見てみましょう Thoughtworks の人の定義
Infrastructure as Code とは、インフラの構成を管理したり、プロビジョニングを自動化するためにハイレベル、もしくは宣言的な言語でコードを書くことである。これは単にスクリプトを書くのではなく、ソフトウェア開発で実証されているプラクティスを使う。例えば、バージョン管理、テスト、小さなデプロイメント、デザインパターンの使用などだ。
どちらの定義にも書いてあることは、Infrastructure as Code は、インフラやプロビジョニングを自動化するための、ハイレベル / 宣言的なコードを書くプラクティスであり、それらがコード化されることで、単に自動化できるとかではなく、ソフトウェア開発で培われてきたプラクティスがインフラ構築にも使えるようになることが大きなイノベーションです。具体的には、バージョン管理ツールを使うことだったり、テスト駆動開発やCIだったり、リファクタリングだったり、今までソフトウェア開発でしか使われてこなかったことが、インフラの構築にも使えるようになるわけです。
ここまでは私が理解していたことです。この「ソフトウェア開発のプラクティスをインフラ構築に使える」というイメージはChef のチュートリアルを実施するととても分かりやすいです。このチュートリアルでは、Test Kitchen や、Serverspec というツールを使って、インフラストラクチャをテスト駆動開発で実施します。
Learn to develop your Ubuntu infrastructure code locally - | Learn Chef
３種類の Infrastructure as Code の領域
実際に私のイメージするインフラをコード化したものとしては３種類の対象があります。１つは「VMや、PaaS、Network」などの 生成の自動化、そして、もう一つは起動したVMに対して、各種のツールやライブラリをインストールして設定していくことを自動化するものです。前者は、ARM（Azure Resource Manager), Azure / AWS SDK, Chef-Provision などでできる領域であり、後者は、Chef や Puppet や Ansible、Windows 系なら PowerShell DSC が実施してくれる領域です。様々なインターネットの定義を確認しましたが、前者と後者がまとめて Infrastructure as Code と呼ばれることが大半のようです。ちなみに３つめはコンテナですが、今回の記事では割愛します。
私も頭が混乱して、David 本人に聞いてみましたすると、彼は、「このビデオを見てみてよ。それでまだ質問があったらいつでも聞いてくれよ」とのことでした。
Configuration as Code
そのビデオでは、私は知らなかったのですが、先ほど述べた前者と後者を Infrastructure as Code と、Configuration as Codeとして明確に使い分けていました。David 本人もこのビデオでちらと言っていますが、Configuration as Code とみんながみんなそう呼んでいるわけではないけど、自分はこの考えがメリットがあり好きだから使っていると言っています。
実際にインターネットで検索すると、いくつかの Configuration as Code のアーティクルが見つかりました。
www.slideshare.net
www.slideshare.net
Wikipedia の Infrastructure as Code もよく見たら、Configuration as Code の部分は「extension」と書いてあります。
Infrastructure as Code - Wikipedia, the free encyclopedia
本当の歴史はわかりませんが、きっと 一般的な用語の Infrastrucure as Code は、きっと AWS SDKぐらいから始まっているのでしょう。それが、だんだん拡張されて、Configration の領域もそういわれるようになったという感じでしょうか？
Infrastructure as Code と Configuration as Code
このビデオやアーティクルで Configuration as Code を明確に分けるメリットについて述べられています。
Dev と Ops の役割が明確に分かれること
混乱がなくなること (Infrastructure as Code と Configuration Management)
ライフサイクルの違い
最初のポイントに関しては、「DevOps と逆方向じゃね？」とお思いになる方もおられるかもしれません。ただ、私の意見としては、DevとOps はフィーチャーチームとして同じチームになるほうがいいと思いますが、フルスタックエンジニア的なものになる必要はないと思っています。これは意見がわかれるところでどちらでもいいと思います。個人的には、Dev と Ops というのは萌えポイントが違うことが多いと思うのです。
例えば、私と一緒に働いている小塚さんという非常に優秀なITProのクールガイがいるのですが、彼はたまに私のやっていることが「全然興味ない」と言っています。一方、Dev出身の私は、彼がたまに、OSのパラメータをいじってパフォーマンスがちょっと向上したとかいってほくそ笑んでいる姿をみて「まったく興味ないわ」と思っていますw。やっぱり人は自分が楽しいことをやって、それで周りと協力するほうがずっと仕事も楽しいと思うので Dev と Ops はあったほうがいいと思うのです。お互いのキャリアは一瞬で簡単に身につくものでもありません。 そういう全然違う人が同じチームで助け合う姿のほうが私は DevOps として楽しいんじゃないかと思っています。
自分的な結論
また、ビデオでも、David が多くの人が、Infrastructure as Code と Configuration Management の混乱を感じていると 言っています。私も思いっきりそうでした。Chef は Configuration Management Tool であるが、Infrastructure as Code でもあるという風にすると、確かにどこに「インフラ」はいっちゃったのかな？という感じになります。
きっとこのInfrastructure as Code のムーヴメントは、元Develper の人に主導されてきたのではないか？と仮説を立てています。 私のようなDevの人からすると、コードを書くのに集中したいので、デプロイする先のは、まるっと「インフラ」という感じなので、その 細かい違いに無頓着です。 一方 David は ITPro guy と名乗るぐらいなので、ITPro の人です。彼にとっては、インフラ構築と、コンフィグレーションは まったく別物で、使うタイミングも違うものという考えをしていました。例えば、「コンフィグレーション」は何回か実施します。
というわけで、私も David の考えに大変共感しましたので、今後は Infrastructure as Code と Configuration as Code という２つの用語を使って明確に分ける派になろうと思っています。
おまけ: Donovan Brown の姿勢
このビデオのDonovan Brown の姿勢がとても好きです。彼は、Visual Studio Team Services の Product Manager で、DevOps を広める立場にあります。その人が「私は Infrastructure as Codeがわかってないんだ」と言って、David にビデオという人前できいてそれをなおかつ共有するとか、日本人ではありえない展開です。でも彼は演技ではなくて素直にそれを人前で聞いています。そしてそれをシェアして、同じように思っている人と学びを共有しました。私もそうありたいと思います。
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。
前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。
見えてきた「物量」の違い
私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
海外イベントに行った時の報告の違い
一つの例を具体的に考えてみます。インターナショナルチームで、以前高額のDevOps Enterprise 2015というイベントに参加した時のことです。インターナショナルチームでも当然レポートとかはあるのですが、一般的に大変シンプルです。E-Mailで、Wordでいうと1-2ページ程度、大まかにポイントがまとまり、写真で雰囲気がわかればオッケー的な感じです。ですので、これを作るのはそんなに時間がかかりません。２－３時間ぐらいでしょうか？
一方日本側として、海外のイベントに参加した時の報告は、プレゼンを作って、そのプレゼンをみんなで見れるように報告会があり、それが録画されます。これはとてもいいことなのですが、報告する人からすると、最低１日はがっつり準備が必要になってくるでしょう。見るほうも１日のイベントになります。
ちなみに、私が初めてインターナショナルチーム向けにレポートを書いたときに、がっつりとした日本式のものを書いて提出した事がありました。それは没になりました。というのも、彼らによると「読むのに時間がかかるからシンプルなのを」とのことでした。
会議に対する姿勢の違い
１つの会議に参加する工数もずいぶん違います。この辺りはMSの日本チームも米国チームと近いので、過去に日本の企業で務めていた時のことと比較してみます。インターナショナルチームの会議は、会議を実施している時間はとにかく集中していて、議事もOne Noteという共有サービスを使いその場でシェアしてシンプルなものを書いていきます。だから、会議の前も、後も何もする必要がありません。必要な時間は会議の時間だけです。
ところが、日本で過去に実施していた典型的な会議の場合、実施前に準備し、実施後に、数時間かけて議事録を作成します。その議事録も、会議の内容がすべて収まったような詳細なものです。また、会議では次の会議までにこれを済ませてほしいという重厚な宿題がだされるケースも多くあります。
ワークショップを開催する例はどうでしょう？
例えば米国でValue Stream Mappingというワークショップを同僚のDavidと実施した時のことです。会場に行ってワークショップを実施して、他チームのプロセスや課題を見える化してディスカッションします。ワークショップをしながら、テンプレートに簡単なテキストベースで記録をとります。手書きでダイヤグラムを作成、写真をその場で撮影して共有にアップロードします。他チームのメンバのほうも、「後日資料をまとめて提案しててください」みたいなことは言われず、「いやー助かったわ。次はこういうことお願いします」という感じでその場が濃厚に終わります。
私はゲスト参加だったので、何もしなくてもいいのですが、折角なのでバリューを出そうと、写真を撮りまくって ほかの仲間と共有するために、ワークショップの進め方の資料をその場でさっとつくりました。さすがにそれはワークショップ中に終えるのは無理だったので、終わった後１時間ぐらい作業していました。Davidがやってきましたが私がワークショップの 続きのことをやってるのを見て「何をしているんだろう」という感じの若干微妙な顔をしていました。彼らにとっては、ワークショップの作業の続きがワークショップの後にも行われているのが、不思議なのかもしれません。
そして、Davidのもう一つの会議が終わった後、４時ぐらいですが、さっさと切り上げて一緒にスノーボードに行きました。なぜなら、会議の後に必要な残作業などないからです。
万事がこんな感じで、必ず「会議をしている時間」の中で基本的にすべてが無理なく完結するようにできています。会議の間は集中していますが、その前後にかけてる時間が全然違う感じです。でも成果はどの程度かわるのでしょうか？
お客様との会議でもかわらない
驚くことに、これは、お客様が相手でも変わりません。先日も欧州のお客様とIoT x DevOpsのディスカッションをしたときのことです。たまたま参加させてもらいましたが、500人ものデベロッパーを抱えるお客様のところで、ハッカソンを開催して業務プロセスを変えるというイベントの相談でした。お客様は手ぶらで来ていますが、こちらに対してやってほしいことがとても明確です。こちらも手ぶらです。ディスカッションは濃厚に行いますが、終わった後にやはり議事録をだしてくれとか、提案してくれとかそういう話は一切ありません。びっくりしたのですが、「500人ものハッカソンを開催して、業務プロセスを変える」というイベントを行うという決定が、その場で「じゃあ、やりましょう。」と決定されたことです。
日本だったら、上の人にお伺いを立てて、稟議を通して、承認されて、、、、とかあるところなのに、全然違います。これはスピードで勝てるはずがありません。
考え方の違いに対する考察
万事がこのような感じで、結局のところ、彼らの生産性が良い大きな理由は、彼らがものすごい量のことをものすごい速さで効率的にやっているのではなく、物理的に「量」が少ないからということが大きいと思います。アジャイルのコンサル時代 に学びましたが、改善の最大のポイントは「やらないことを増やす」ことです。日本の文化だと、どうしても、仕事というのは「献上」モデルになっていると思います。仕事の成果を「献上」する相手の生産性や成果を最大化しようとします。だから「献上する側」が楽かどうか、時間がかかるか？はあまり考慮されません。 一方インターナショナルチームだと、「チーム全体の生産性」をあげるように工夫されているように感じます。日本だと「献上」する相手を敬い、そこに最大限のパワーを使う感じでじゃぶじゃぶ時間が過ぎていきますが、インターナショナルチームだと、後述しますが、「助け合い」という感じで上下関係もないので、仕事をやる側の人にとっても「大変」なことは要求されません。
よく外資系に務めていると「本社から、とてもやれないようなことを要求された」とかよく聞きますが、本当のところは、１つの仕事に対する、仕事量イメージの違いが生み出している不幸のような気がします。私はBOSSにとてもできないような仕事を要求されたことは１回もありません。彼のイメージする仕事をこなしているのは本当に楽に定時内で楽々できるものです。 きっと、仕事をお願いするほうがそういうイメージなのだと思います。ところが、日本側からすると、先ほどの会議の例でもそうですが、「日本式」に同じ仕事をするイメージをすると、ものすごい物量になってしまうということではないでしょうか？ だから、本国側も「なんで、あんなに簡単な仕事を頼んでるのに、日本側は大変だとかいうんだろう？」みたいな感じになっているのではないでしょうか？
上下関係がない
ほかに気づいたことは、日本では「偉い」人がいるのですが、インターナショナルチームでは「偉い」人がいないということです。インターナショナルのチームでは、「BOSS」や「マネージャ」はいるのですが、彼らが「偉い」という感覚がありません。単なる同僚で違う役割の仕事をしてくれているという仲間という感じです。彼らも私に命令をしてくるなんてことはなく、私に意見を求めたり、チームで一緒に仕事をするのがうまくまわるのに、協力してくれている感じです。 一方日本では「偉い人」が存在するので、「偉い人」にお伺いを立てないと万事何事も進まなかったりします。チーム内でも「偉い人」の順番があって、「偉い人」が若い人に指導をするみたいな雰囲気があります。インターナショナルチームでは、誰も年齢とかを気にしません。自分で考えて、お互いが助け、助けられ、お互い感謝する感じです。だから、基本的に自分で意思決定をして物事を楽に進めることができます。もちろん時にはBOSSに相談したほうがいいことはありますが、頻度が圧倒的に少ないイメージです。 基本仕事は、自分の意志で「俺これやるわー」というノリでやるもので、KPIのみがあり、強制的にやらされることはない感じです。だから圧倒的にストレスがありません。
日本で生産性を上げるために
外国人上司にしょっちゅう言われることは「最も少ない工数で、最大のインパクトを」ということです。彼らは私がたくさん工数を使うこと、休日も働くことを全くいいと思っていません。例えピカピカな成果を休出して出したところで、微妙な顔をされるのが関の山です。
大量の物量を速い速度でこなそうとしても結局無理がかかって、結局時間外労働することになります。それよりも、物量を減らして、本当の「実」をとる方法を考えます。 「偉い人に献上する成果」だけを最大化するのではなく、「チーム全体の生産性」を最大化させるために、「チーム全員が大量の仕事をしなくてもいい仕組みづくり」をするほうがよっぽど簡単でしょう。
仕事をする側も楽になる仕組みづくり。余った時間でさらに新しいことも取り組みやすくなりそうです。
でも、こう書くと「いやー君が言う通り、文化が違うから日本では無理だよ～」という声が聞こえそうですが、日本でこのレベルのことをやっている会社さんを私は知っています。ソニックガーデンさんです。倉貫代表のブログがあるので、これを読めばその考えの一端に触れることができるでしょう。
私が一度彼らとお仕事させてもらった時です。彼らは私のクライアントでした。ある仕事をするために会議をするという段取りになったときです。代表の倉貫さんがその時に私に言ったことが衝撃的でした。
「牛尾さん。会議をやるときに準備はしてこなくていいです。無駄ですので。その代わりに会議のその場で良い成果を出しましょう。」
普通でいうと、人を雇うときに、その人にいっぱい仕事をしてもらいたいと思うのが普通だと思います。だから新しい仕事を始める前、クライアントは私がいっぱい準備して、提案書とか作ってくれることを期待するのが普通だと思っていました。ところが、倉貫さんは全く逆でした。雇っている方が、無駄な作業をしてこなくていいというのです。雇われているほうも、こっちのほうが楽に仕事ができますが、その「場」で成果を出すためには普段から実力をつけておくしかないので、空いた時間で本当の「実力」をつけることに注力できます。
日本の全体を今すぐ変えることは難しいですが、こういう人が一人でも増えてくると日本の生産性は上がってくると思うのです。お客様相手の箇所が難しいなら、自分の会社内、いやグループ内だけならできるかもしれません。少なくとも自分がそうなることもできます。米国の人ができることも日本人ができることも大して違いはありません。しかし、「成果」につがならないこういう無駄の積み重ねで、日本がソフトウェア産業で負けているのだとしたら、相当もったいない気がします。以前にも書きましたが個々の日本人の能力は高いと思います。
こういう環境で働ける人が増えたら、もっとみんなが楽しく働けて、グローバルから見ても成果が楽に上げれるようになると思います。少しづつでも始めてみませんか？日本だから仕方がないとあきらめるのではなくて、私も自分の幸せのためにも実践してみたいと思います。
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。
それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。
私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。
気軽に「聞けないこと」が生産性を阻害しているのでは？
以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それどころか個々の人だと、日本人の人のほうが優秀な人が多いんじゃないだろうか？と思うぐらいです。
これにはいくつの要因があると仮説を立てているのですが、その大きな要素の一つである「気軽に聞けない文化」について考察してみたいと思います。
私を含めた日本人は気軽に何かを聞けません。聞いたところで、「ググれカス！」と言われたり、「よく調べてから質問しなさい」という風に言われることもよくあります。 米国で仕事をしているときは、誰でも気軽に質問していることに気づきます。それもとってもしょ～もない質問でも気軽にするのです。そして誰も「ググれカス」とかいいません。
私が気づいた衝撃的な例をお話しすると、どれだったかは失念したのですが、確かAppleの製品発表の時に、故Steve Jobs氏が、iPadかiPhoneか何かの新機能の特徴を説明していました。その直後の質問コーナーで、質問した人がいたのですが、その内容が「新機能の特徴を教えてください」というもので、私は「なにいっとんねんこのおっさん！今Jobsが話していたばっかりやん！」と思いました。 ところが、Jobsは「Good question」といって先ほどした説明をまったく同じように繰り返していました。そして、その質問者は満足したようでした。
私の職場でも、とっても優秀な人でも、日本だったら「えっ？そんなこと聞く？」ということでも自分が知らなかったらカンタンに隣の人に聞きます。例えばマイクロソフトに入社した人が「Azureって何？」というレベルのことを質問しているぐらいの勢いでも誰も問題と思いません。知らないことは知らないのです。
実際に気軽に質問することを実践すると、相当効率がよく感じます。聞けばその場で自分よりよっぽどわかっている人から教えてもらうことができます。もし、その前に自分でググるとすると、自分で調べる力はつくかもしれませんが、結局のところ自分がよく知らないことなので凄く時間がかかってしまいます。だから、気軽に教え、教えられしていると、本当に効率よく仕事が進みます。
気軽に聞くためには、「簡単に断れる」ことが必要
さらに気が付いたことは、この「気軽に聞ける仕組み」を作るためには、「気軽に断れる空気」を作ることが重要だということです。これは、スポーツカーが速く走れるのは、良いブレーキがついていて、いつでも止まれるからということに似ています。
例えばハッカソンをしていて、ハッカソンのサポートをしてくれる同僚がいます。彼らに助けを求めたら、気楽にきてくれますが、自分がわからないと簡単に「わからないから、あいつに聞いたらいいと思うよ」とか、「うーん。わからないないなー、サポートに聞いたら？」とか言います。これは、社内だからとかではなく、お客様を相手にしていても同じなのです。そして、サポートを受けたほうも「助けてくれてありがとう」って笑顔で返します。
もし、これが日本だったら、自分がサポートをしている以上、一旦お客様から質問を受けたらサポートに連絡するとか、自分も一緒になって意地でも最後まで付き合うとか、 「後日回答します」と最後まで責任を持ったりするところです。 よくよく考えたら、やくざ映画や、寅さんとかを見ていても、「頼まれちゃぁ断れねぇなぁ」といって、一旦助けを受けたらとことんやっちゃうのが日本人の性質だと思い出しました。だから、気軽に助けを受けず、ググれカスとか、調べてから来なさいということを言いますが、一旦受けたからにはとことん助けてくれます。
また、助けを受けて、途中で投げ出すと、相当いい加減に見られたり、頼りにならないと思われたりもします。
それは、素晴らしい美徳ですし、顧客対応に対してもいいことかもしれませんが、事ソフトウェア開発の効果や効率を考えるとこれは相当な無駄を生んでいるかもしれません。簡単に聞けて、助けになれなかった場合は、すぐに「ごめん」とできる。
これだけ、でも聞く方、聞かれる方、双方相当に楽が出来ると思うのです。
日本の文化は素晴らしいですが、ソフトウェア開発に関してはそれがマイナスに働いている場面が多く、大変もったいなく感じます。インターナショナル環境で彼らを観察して、何か改善できそうなヒントを見つけたら共有して、自分でも実施して試してみたいと思います。
ご意見、ご感想など歓迎です！
技術イケメンをつくってみる。
イケメンへの憧れ
実は私はずっとイケメンなプログラマに憧れている。
NEC時代も、最初は営業から初めて、若い頃は役立たず。アジャイルとかやるようになったり、オブジェクト指向だったりから、活躍できるようになった。これは、何を意味するか？というと、抽象的なことや、リーダーシップとか、チームビルディングが得意ということだ。
でも、本当になりたいのはイケメンプログラマになりたいのだ。自分の周りのイケメンの皆さんをみては、ああぁかっこいいなぁ。でも自分にセンスないのわかってるしなぁ、、、。ただ、新技術系でも教育とか、記事書いたりはいいのだ。作業がぜんぜんできないタイプなのだ。あー、神様私に数学センスを！！！
イギリスにいって振り返って、その後もいろいろあって、やっぱり自分は技術が好きやなぁと思うようになってきた。英語勉強に関しても一区切りした。（ちなみに、完璧になったということではなく、これ以上は実践して慣れるしかない、少なくともそれをしないと上達しなさそうなフェーズと感じたから）
自分はほんまはプログラマになりたいけど、プログラマとしては三流。これはずっと自分の憧れで、コンプレックス。NECに入った時は、OSのコマンドを担当したいといって入社したんだ。（でもほぼ営業的な部門に配属されましたw）その後も、大手SIerなので、無理やりプログラミングしたけど、とても十分とは言えず、センスもなく。
イケメンコンプレックス克服への道
今回ふとおもったけど、何を自分のやりたいことを躊躇しているんだろう。センスとか言ってるけど、もともとすべてのことにセンスなどないやん。わしはメソッドと努力だけでいろんなことをなんとかしてきた。自分の人生で望んでいたことはがんばってなんとか叶えてきた。
英語バリバリになりたいとか（途中だけど）、歌うまなりたいとか（これも途中だけど、イギリスでヒントゲット）、コンサルタントになりたいとか（これはOK）アジャイルやりたいとか（これは死ぬほどやった）要求開発したいとか、コンパニオンの美人お姉さんとお付き合いしたいとか（一応結婚はした。終了したけど orz）
なーに、今回もできるさ。技術イケメンの道。というわけで、趣味ベースかもしれませんが、私の友達にたくさんいるガチで技術イケメンになってみるプロジェクトをやってみようかと思っています。今の時代みんな技術イケメンが求められているので、わしぐらいコテコテに向いてない人が技術イケメンになったら、そのメソッドいけてない？的な。
リンクが見つからないけど、プログラミングの学び方 - Web/DB プログラミング徹底解説このお方の言ってることとか参考になりそう。とりあえず、なぜ自分がイケメンプログラマじゃないと思うのかとか、イケメンプログラマが共通で持っているポイントとか、何を達成したら自分でイケメンと思えるのかなんてことを整理した。
自分がイケメンじゃないと思うところ
他の人が書いたロジックを読むのが遅い
自分の書いたコードがクールじゃないと思うときがある。
オープンソースのコードをすらすら読めない
テストスキルがしょぼい
オペレーションの経験が弱い
基本能力に抜けがある気がする
イケメンの性質
おしゃれなコードを書く
問題解決が早くて、生産性が高い（これは、無駄なものを大量に作るわけではなく）
変化を抱擁する
新しいことを素早く、正確に学ぶ
内部構造を奥の奥まで理解している
分析
これから、せっかく一生懸命やった、英語学習に当てはめて考えてみた。英語だったらどういうのが重要だろう？
リーディング ：自分のレベルにあったちょっと簡単めの本をたくさん読む。
グラマー（言語の文法／動作原理理解、ネットワークやハード、OSなどなどの動作原理／仕組み）を鍛える
ボキャブラリ ；技術系だと、クラスライブラリやイディオムに相当？
ライティング ；コードを書くこと。多分グラマーとか、イディオムとか、パターン重要？
リスニング ；なし
スピーキング ；なし
何をすべきか？
自分の場合きっと、最初のステップは、コードリーディングが自由自在に読みまくれることが重要だろう。そして、実践としてのコードを書くことをすればいいだろう。運用付きの。
最初の一歩は、コードリーディングテクの強化だから、この本を読み始めた。
Code Reading―オープンソースから学ぶソフトウェア開発技法
- 作者: トップスタジオ,まつもとゆきひろ,平林俊一,鵜飼文敏
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2004/06/01
- メディア: 単行本
- 購入: 18人 クリック: 550回
- この商品を含むブログ (214件) を見る
しかし、この本を読み始めるには、C言語をおさらいする必要がありそう。長年触ってないが、せっかくだから英語で勉強しよう。Learn C - Free Interactive C Tutorial あー、懐かしい。英語ではこんな風に見えるのか。なんだか感じが違うなぁ。
それが終わったらデータ構造とアルゴリズム→コードリーディング（LinuxとかCoreOSとか)をやってみよう。
きっと自分がイマイチだったのは、一足飛びにやろうとしたから。下の方から積み上げてみる。すでに学んでいることも多いんだけど、きっと、そこに抜けている箇所があると思うんだ。これは、実は英語学習から学んだこと。できることならすぐ終わるはず。
アジャイルの流儀で英語に挑戦！ - ［挫折と挑戦編1］日本人が英語を話せない本当の理由：ITpro
これは、自分にのこった最後のコンプレックス。果たして、４０超えたおっさんは、イケメンになれるのか？わからんけど、手探りでやってみます。
ネイティブに伝える為のロジカルさとは？
イギリス人のプレゼンテーション／ヴォイスコーチのChristianeから指導を受けているが、彼女とのディスカッションの過程でネイティブに対してわかりやすくしゃべる為には、ロジカルさが必須だと実感した。その顛末と気づきを共有したい。
1. イントロダクション
Christianeとの出会い
私は昔から音楽が好きで昔はヴォイストレーニングに行っていた。また音楽をしたいなと思ってまたヴォイストレーニングをやってみようと思っていた。そんな時に、PechaKucha 20x20 - Tokyoという六本木で毎月やっているプレゼンテーションのイベントに参加していた。英語をガチで使う機会を求めて、英語のプレゼンが聞けるし、外国人の人が沢山来ているこのイベントはとても自分にとって楽しいイベントなのだ。自分は結構人見知りなので、「今日は自分から話しかけてみる！」というノルマを課していたが、自分が１人出来ていて、他に１人の人が見つからなかったこともあり、イベントが終わるまでそのノルマが達成出来ずにいた。
イベントが終わった後に、１人でぽつんと座っている女性を見つけて話しかけてみた。それがChristianeだった。話を聞いてみると、イギリス人で、ヴォイスコーチをしているという。プレゼンテーションの指導もしていると話していた。自分にとっては、ボイスコーチで、しかもそれをブリティッシュイングリッシュを操る英語ネイティブが教えてくれるなんて夢のようだったので、彼女に連絡先を渡してレッスンをお願いする事にした。発声が良くなり、英語の発音イントネーションはもちろん、プレゼンの指導まで。これは楽しみだ！ まずは、彼女とお話をして、進め方を話そうという話になった。
ほんのちょっとした違い
彼女のサービスを利用するにあたって、彼女と話をした。彼女は、どういう事をしてほしいか聞いてきた。私は「発声を良くしたいこと、英語の発音／イントネーション、自分が発言している内容が適切かどうかの確認、プレゼンの指導をしてほしい」といったような事を言った。多分日本人の人が相手だと、「私のサービスで、きっとあなたを満足させる事ができると思うわ。料金はXXです。それでよければ、初回は何日にしましょうか？」という話になる流れのところだが、彼女の行動はそうじゃなかった。
まるで要件定義
彼女は「要件を定義」し始めたのだ。「プレゼンの原稿のレビューはしてほしい？」「発音とイントネーションは入れてほしいのね？」そんなやり取りをして、彼女は、私の「要件」をリストアップして定義しだした。そのサービスがInでどのサービスがoutなのか。その後彼女はこういった。
「じゃあ、６月までの提案を作って送るわね。」
数日後彼女がメールを送ってきた。こんな内容が入っていた。私の要求を全て満たしていて完璧だ。そして、曖昧さが全然ない。この時はこのちょっとした違いに気がついていなかったのだ。この内容でお願いします。という返信をして彼女にサービスをお願いする事にした。
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.
2hrs5/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.5hrs26/5 Week 5
Pronunciation, word stress, sentence stress, sentence flow. Room required.
1.5hrs2/6 Week 6
Voice projection techniques, delivery style, coping with pressure. Room required.
2hrs
Handling questions. Room optional, cafe OK.
1hrs9/6 Week 7
Presentation delivery coaching. Face to face meeting. Room required.
2hrs16/6 Week 8
Presentation delivery coaching. Face to face meeting. Room required.
2hrs23/6 - 29/6 Week 9
Travel to US / Conference
—
日本の現場だと、プロのエンジニアと話をするときも、こんなに明確にスパッとしたものが仕事の最初から出てくる事はまれだろう。ちょっとびっくりしてしまった。日本はすりあわせ文化なのだなと思った。
2. とんでもない課題
あなたの言っている事が全然理解できなかったのよ
私は６月に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. 解決の糸口
これを聞いて自分的に「あぁ！」と思う事があって、しゃべり方を１００％変えてみた。
「ちょっと、まって、考えさせて！」
「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
- 作者: D.Q. McInerny
- 出版社/メーカー: Random House Trade Paperbacks
- 発売日: 2005/05/10
- メディア: ペーパーバック
- 購入: 1人 クリック: 6回
- この商品を含むブログを見る
何かを始める時に20時間がんばってみる
凄く面白いプレゼンテーションの事を知ったのでカンタンにシェアして、自分のコメントを忘れないように書いておきたい。
この動画でも、紹介されているが、何かをマスターする為に10,000時間ルールというのがある。何かのエキスパートになるためには、10,000時間が必要だとのことだ。ビートルズがデビューするのに要した時間とかもそんな位だったとか（適当w）
さて、この10,000時間はむっちゃ長い。フルタイムの仕事で５年位。まぁエキスパートになる為にはコレ位かかるよねという感じだ。このプレゼンでは、エキスパートではなく、何かを始めるには20時間あれば良いという話をしている。自分が特に印象的だったのは次の場面
パフォーマンスにかかる時間
上達度と時間
これを見たらわかるように、20:80の法則と同じように、確かにそうだ。何かの１つのパフォーマンスをするためには、最初はすっごく時間がかかる。やっていると、だんだん少ない時間でできるようになる。この人は、重要な事は、それはあなたの才能（知性）の問題ではなく、感情の問題だといっている。つまり、最初の２０時間は、むっちゃ１つの事に時間がかかるのが当然ということだ。私も良く経験があるが、新しい技術に接するときに「あ〜わしはやっぱ全く才能ないよなぁ、、、」といつも思っていた。でもそれは当たり前で、それを２０時間位しないとある程度のスピードでパフォーマンスできないのだ。歌の練習だと最初の１曲にはむっちゃ時間がかかるということだろう。つまり20時間やってないのに、出来ないとかなんとか判断するのは、そもそももったいない話なのだ。
つまり、この人がこの考えに至ったのは子供が生まれて時間が全くなくなったことがきっかけだが、自分には「２０時間諦めなければ、そこそこ出来るようになる。だけど、最初は誰でもむっちゃ時間がかかるのが当然」ということが響いた。自分は本当に才能あるものは、最初からすっと出来てしまうと思っていたけど、多分そうではないのだ。逆にすっと出来たと思っていた事もよく考えたら子供の頃からやっていた事だったりする。
私はコンサルタントだから新しい事を学ぶ場面は多いし、好きだ。一方自分がガチのプログラマと比べるとどうしても偽物感が拭えなかった。最近は、倉貫さんが「同じ事を続けているから、その道で他の人に負けないエキスパートになれる」と言ってくれたことで、自分も「技術コンサルタント道」を極めようと思っている。特に開発をうまくやる為のコンサルタントを極めていこうと思う。これは、先の10,000時間ルールの方に該当する。自分の差別化要素で、ライフラークな事。これの軸はぶれない方がいい。
一方、そのために必要な学びもこの20時間ルールを使って、エキスパートじゃないけど、そこそこ使えるレベルという所程度にまでは技術を上げていくような事をしていけばいいのではと思っている。上手く行くかは今後のお楽しみかなぁ。
自分が才能が無いからあかんよな。と諦めていたけど本当はやりたい事に上手く使ってみよう。才能が以外とある分野もあるといいなぁ。20時間後にわかるかな。
