メソッド屋の日記 このページをアンテナに追加 RSSフィード

2014-11-24

技術イケメンをつくってみる。

22:15 | 技術イケメンをつくってみる。を含むブックマーク

イケメンへの憧れ


実は私はずっとイケメンなプログラマに憧れている。


 NEC時代も、最初は営業から初めて、若い頃は役立たず。アジャイルとかやるようになったり、オブジェクト指向だったりから、活躍できるようになった。これは、何を意味するか?というと、抽象的なことや、リーダーシップとか、チームビルディングが得意ということだ。


 でも、本当になりたいのはイケメンプログラマになりたいのだ。自分の周りのイケメンの皆さんをみては、ああぁかっこいいなぁ。でも自分にセンスないのわかってるしなぁ、、、。ただ、新技術系でも教育とか、記事書いたりはいいのだ。作業がぜんぜんできないタイプなのだ。あー、神様私に数学センスを!!!


 イギリスにいって振り返って、その後もいろいろあって、やっぱり自分は技術が好きやなぁと思うようになってきた。英語勉強に関しても一区切りした。(ちなみに、完璧になったということではなく、これ以上は実践して慣れるしかない、少なくともそれをしないと上達しなさそうなフェーズと感じたから)


 自分はほんまはプログラマになりたいけど、プログラマとしては三流。これはずっと自分の憧れで、コンプレックスNECに入った時は、OSのコマンドを担当したいといって入社したんだ。(でもほぼ営業的な部門に配属されましたw)その後も、大手SIerなので、無理やりプログラミングしたけど、とても十分とは言えず、センスもなく。


イケメンコンプレックス克服への道


 今回ふとおもったけど、何を自分のやりたいことを躊躇しているんだろう。センスとか言ってるけど、もともとすべてのことにセンスなどないやん。わしはメソッドと努力だけでいろんなことをなんとかしてきた。自分の人生で望んでいたことはがんばってなんとか叶えてきた。


 英語バリバリになりたいとか(途中だけど)、歌うまなりたいとか(これも途中だけど、イギリスでヒントゲット)、コンサルタントになりたいとか(これはOK)アジャイルやりたいとか(これは死ぬほどやった)要求開発したいとか、コンパニオンの美人お姉さんとお付き合いしたいとか(一応結婚はした。終了したけど orz


なーに、今回もできるさ。技術イケメンの道。というわけで、趣味ベースかもしれませんが、私の友達にたくさんいるガチで技術イケメンになってみるプロジェクトをやってみようかと思っています。今の時代みんな技術イケメンが求められているので、わしぐらいコテコテに向いてない人が技術イケメンになったら、そのメソッドいけてない?的な。


リンクが見つからないけど、プログラミングの学び方 - Web/DB プログラミング徹底解説このお方の言ってることとか参考になりそう。とりあえず、なぜ自分がイケメンプログラマじゃないと思うのかとか、イケメンプログラマが共通で持っているポイントとか、何を達成したら自分でイケメンと思えるのかなんてことを整理した。


自分がイケメンじゃないと思うところ


他の人が書いたロジックを読むのが遅い

自分の書いたコードがクールじゃないと思うときがある。

オープンソースのコードをすらすら読めない

テストスキルがしょぼい

オペレーションの経験が弱い

基本能力に抜けがある気がする


イケメンの性質


おしゃれなコードを書く

問題解決が早くて、生産性が高い(これは、無駄なものを大量に作るわけではなく)

変化を抱擁する

新しいことを素早く、正確に学ぶ

内部構造を奥の奥まで理解している


分析

これから、せっかく一生懸命やった、英語学習に当てはめて考えてみた。英語だったらどういうのが重要だろう?

リーディング :自分のレベルにあったちょっと簡単めの本をたくさん読む。

        グラマー(言語の文法/動作原理理解、ネットワークやハード、OSなどなどの動作原理/仕組み)を鍛える

ボキャブラリ ;技術系だと、クラスライブラリイディオムに相当?

ライティング ;コードを書くこと。多分グラマーとか、イディオムとか、パターン重要?

リスニング  ;なし

スピーキング ;なし


何をすべきか?

自分の場合きっと、最初のステップは、コードリーディングが自由自在に読みまくれることが重要だろう。そして、実践としてのコードを書くことをすればいいだろう。運用付きの。

最初の一歩は、コードリーディングテクの強化だから、この本を読み始めた。


しかし、この本を読み始めるには、C言語をおさらいする必要がありそう。長年触ってないが、せっかくだから英語で勉強しよう。Learn C - Free Interactive C Tutorial あー、懐かしい。英語ではこんな風に見えるのか。なんだか感じが違うなぁ。

それが終わったらデータ構造とアルゴリズム→コードリーディングLinuxとかCoreOSとか)をやってみよう。

きっと自分がイマイチだったのは、一足飛びにやろうとしたから。下の方から積み上げてみる。すでに学んでいることも多いんだけど、きっと、そこに抜けている箇所があると思うんだ。これは、実は英語学習から学んだこと。できることならすぐ終わるはず。

アジャイルの流儀で英語に挑戦! - [挫折と挑戦編1]日本人が英語を話せない本当の理由:ITpro


これは、自分にのこった最後のコンプレックス。果たして、40超えたおっさんは、イケメンになれるのか?わからんけど、手探りでやってみます。

2014-05-24

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

| 21:19 | ネイティブに伝える為のロジカルさとは?を含むブックマーク

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



1. イントロダクション


f:id:simplearchitect:20140220221320j:image:w640



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. とんでもない課題


f:id:simplearchitect:20130328194443j:image:w640


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


私は6月にUSのAgile Roots » Working Togetherというイベントでプレゼンをするのだが、その時に私が考えて、原田さんと一緒にお話する、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年だから、日本人に慣れているのだろう。こんな絵を書いてくれた。

f:id:simplearchitect:20140502225559j:image:w360


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


3. 解決の糸口


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


「ちょっと、まって、考えさせて!」

「Build Less patternは、ソフトウェアパターンの一種だよ」

ソフトウェアパターンというのは?」

ソフトウェアの開発で繰り返し使われている、課題に対するソリューションのカタログだよ」

「なるほどね」

「例えば、、、、、」


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


ロジカルさと明確さ


f:id:simplearchitect:20140416103413j:image:w640



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


「この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なのか?」というのを個人的に聞いたら、にっこり微笑んで非常にロジカルに説明してくれた。こんな事をきいたら、日本人だったら、若干嫌な顔をされるかもしれないが、快く教えてくれた。

 もしかすると、彼女はプロの英会話教師なので、日本人にあわせて説明してくれていたのかもしれないが、そういうレベルまで向こうの人は明確に説明できるのかもしれない。

f:id:simplearchitect:20130221121834j:image:w360


まとめ


・日本と西洋文化の「わかりやすさ」は全然違う

・英語で話をするときは、定義、明確さ、ロジカルさを意識して話をする

・自分が思っているより、相当自分たちはロジカルではない。文化的な背景があるから


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


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


Being Logical: A Guide to Good Thinking

Being Logical: A Guide to Good Thinking

2014-03-09

何かを始める時に20時間がんばってみる

| 14:26 | 何かを始める時に20時間がんばってみるを含むブックマーク

凄く面白いプレゼンテーションの事を知ったのでカンタンにシェアして、自分のコメントを忘れないように書いておきたい。

D

この動画でも、紹介されているが、何かをマスターする為に10,000時間ルールというのがある。何かのエキスパートになるためには、10,000時間が必要だとのことだ。ビートルズがデビューするのに要した時間とかもそんな位だったとか(適当w)


さて、この10,000時間はむっちゃ長い。フルタイムの仕事で5年位。まぁエキスパートになる為にはコレ位かかるよねという感じだ。このプレゼンでは、エキスパートではなく、何かを始めるには20時間あれば良いという話をしている。自分が特に印象的だったのは次の場面


パフォーマンスにかかる時間

f:id:simplearchitect:20140309141510p:image:w360



上達度と時間

f:id:simplearchitect:20140309141508p:image:w360



これを見たらわかるように、20:80の法則と同じように、確かにそうだ。何かの1つのパフォーマンスをするためには、最初はすっごく時間がかかる。やっていると、だんだん少ない時間でできるようになる。この人は、重要な事は、それはあなたの才能(知性)の問題ではなく、感情の問題だといっている。つまり、最初の20時間は、むっちゃ1つの事に時間がかかるのが当然ということだ。私も良く経験があるが、新しい技術に接するときに「あ〜わしはやっぱ全く才能ないよなぁ、、、」といつも思っていた。でもそれは当たり前で、それを20時間位しないとある程度のスピードでパフォーマンスできないのだ。歌の練習だと最初の1曲にはむっちゃ時間がかかるということだろう。つまり20時間やってないのに、出来ないとかなんとか判断するのは、そもそももったいない話なのだ。


 つまり、この人がこの考えに至ったのは子供が生まれて時間が全くなくなったことがきっかけだが、自分には「20時間諦めなければ、そこそこ出来るようになる。だけど、最初は誰でもむっちゃ時間がかかるのが当然」ということが響いた。自分は本当に才能あるものは、最初からすっと出来てしまうと思っていたけど、多分そうではないのだ。逆にすっと出来たと思っていた事もよく考えたら子供の頃からやっていた事だったりする。

 

 私はコンサルタントだから新しい事を学ぶ場面は多いし、好きだ。一方自分がガチのプログラマと比べるとどうしても偽物感が拭えなかった。最近は、倉貫さんが「同じ事を続けているから、その道で他の人に負けないエキスパートになれる」と言ってくれたことで、自分も「技術コンサルタント道」を極めようと思っている。特に開発をうまくやる為のコンサルタントを極めていこうと思う。これは、先の10,000時間ルールの方に該当する。自分の差別化要素で、ライフラークな事。これの軸はぶれない方がいい。


 一方、そのために必要な学びもこの20時間ルールを使って、エキスパートじゃないけど、そこそこ使えるレベルという所程度にまでは技術を上げていくような事をしていけばいいのではと思っている。上手く行くかは今後のお楽しみかなぁ。


自分が才能が無いからあかんよな。と諦めていたけど本当はやりたい事に上手く使ってみよう。才能が以外とある分野もあるといいなぁ。20時間後にわかるかな。

2014-01-05

英語技術ブログのちょっとしたテクニック

| 21:22 | 英語技術ブログのちょっとしたテクニックを含むブックマーク

tumblrアカウントを作って、世界に知ってもらいたい日本の開発シーンの情報をたまにブログしてみようと思い立ちました。


ブログの第一号は、顧客、経営者、開発者の3者のWin-WIn-Winを達成して、私が興味津々の、ソニックガーデンさんのビジネスモデルについて書いてみました。もし良かったらご覧ください。(そして、よかったら拡散してくださいw)


Keep it simple ? No Delivery, No Due Date, No Fixed Scope


さて、この過程で下手でもいいので、英語で技術情報発信してみよう!と思ったのですが実際にやってみると、本当に難しかったです。多分喋りの1000倍ぐらい難しいと感じました。しかもブログなので、残ってしまいます。私の英語の師匠のお力を借りてなんとか仕上げましたが、彼が私の文をレビューしてくれて、いろいろテクニックを伝授してくれましたので、私の駄文のbefore/afterを使って、そのノウハウをシェアしたいと思います。


1. 事前準備として文法チェックする


文法的に正しいかどうかのチェックは最近様々なサービスが出ています。例えばこのGingerなんかなかなかいい感じですので、こういったサービスで事前に文法チェックをすませましょう。


Gingerとかいい感じです。Gingerがどんなものかは下記のリンクの記事がとてもわかりやすいです!


恥ずかしい英語におさらばできる無料の本格英文チェッカー「Ginger」が日本で正式ローンチ - THE BRIDGE(ザ・ブリッジ)


こういったツールで文法チェックしたところで、文法として間違っていないだけなので、それが読みやすいかとか、わかってもらえやすいか?とかはわかりません。ですので、最初のうちはレビューをしてもらうのが無難でしょう。私は師匠にレビューしてもらいました。師匠からは、記事の構成からダメだしをいただきました。例えば私の最初の文章は、「SIer」という文化がある事が前提の文章で、米国では「SIer」がほぼほぼ存在しないため、その説明をしないとわかってもらえないということでした。こういうことは知識では知っていましたが、指摘されるまで思いもしませんでした。やはり師匠は偉大です。


2. 事実と自分の意見を混ぜない


まず師匠が最初に指摘してくれた事がこれです。私も思い入れがあるだけにどうしても自分の意見とかで熱くなってしまいますが、事実と意見が入り交じるととても読みにくくなります。基本的に英語の技術文章の場合は自分の意見は排除して、事実中心に書いた方が良いようです。私の文章はほぼ自分の意見ですが、師匠はこのパートを書き換えてくれました。明らかに下の方が英語文章っぽくかつ、客観的で自分が見ても興味をそそられます。(このブログでは達成できていませんが、日本語でもそういう風に気をつけてみようかなと思っています)


before

In terms of stakeholder’s happiness, Sonic Garden’s business model is really impressive.They succeed in making win-win-win relationship between employee, employer and customer.

I’d like to write about a piece of the secrets of their business model as a software consultant.

after

This is a slogan, the Sonicgarden company uses to describe their business model. The Sonicgarden is a custom software development company in Japan.

How can a custom-software development company survive without delivery?

Here's what I found during interviews with CEO, their workers and their customers.


私はこの指摘をいただいて、記事の構成を全体的に見直しました。その上で師匠がいろいろ直してくれました。彼が直してくれたポイントを整理してみたいと思います。


3. 繰り返しを避ける


最初に私が気づいたのは繰り返しになっている部分が修正されていました。例えば次のような感じです。


具体的な表現をOne等の表現に変える


この例では、the customer という部分がoneに変わっているところが印象的です。そして、if文をつかったごちゃごちゃした表現がすっきりした表現になっています。

before

When a customer order custom-made software to a developer, the customer has the ownership over the software. but if you use their business model, the developer has the ownership over the software.

after

When a customer orders custom-made software, one will usually own the software after the software is done. But at Sonicgarden, the developer keeps the ownership.


if文を避ける


次の例では、これまただらだらしたif文が質問とif notに入れ替わっています。プログラムコードと同じで英語でもif文のごちゃごちゃしたのは嫌われるようです。

before

Is ownership over software important? If you give up the ownership, you can reduce the cost of these.

after

Is software ownership important to a customer? Is it valueable? If not, you can reduce the cost of these.


neitherを使って繰り返しを避ける


これは、neitherを使って繰り返しを避けたり、if文をwithinで置き換えています。英語でもif文は怪しいサインかもw

before

The Sonic Garden never promises the due date of the production. It causes overwork and low-quality software. They also never promise the fixed scope even if they are in a sprint.

after

The Sonicgarden never promises the due date. It causes overwork and lowers quality of software. They neither promise the fixed scope even within a sprint.



4. シンプルな表現を心がける


他にも師匠が置き換えてくていた部分があります。それは、表現のシンプルさです。以前師匠は、be + PPの表現を多用するのは日本人っぽいと指摘してくれました。今回はそれは避けたのですが、やはり、どうも回りくどく書いてしまうようです。いくつかのパターンを見てみましょう。


余計な説明を削除する


ここはどうしても意見を入れたいところなので、明確に意見として書いたつもりでしたが、あっさり直されましたw Build Lessとかの概念は元々向こうの概念だからいいのかもしれません。確かに直していただいた文の方が1000倍カッコいい。やっぱりポイントはif分かもしれません。多分日本語の文法に影響を受けているのでしょう。

余談ですが私は全ての文を作る時は英語で考えて英語で作りました。それでも日本語の影響を受けるみたいですね。修行が足りません。

before

In my opinion, if you want to create valuable software, ‘Build Less’ concept is really important.

after

'Build Less' is the key cocept to create valuable software.


文を一旦サマリして書き直す


この例でも日本語の影響が顕著です。だらだらした文章を一旦サマライズして、スッキリと構成されています。単一のテクニックではないですが、言い換えてわかりやすく、シンプルになっています。こういうサンプルをみて、ごちゃごちゃしている時はシンプルに書くように考え直す方がよさそうです。

before

Most of them can’t afford to hire a full-time programmer. It is very hard to find skilful programmer for someone who has no experience of programming. Using this service, Customers can use a skilful programer’s resource with low cost.

after

It is almost impossible for people without programming experience to find and hire good programmers. Sonicgarden is a good resource for them like skillfull programmers on demand.


主語を置き換える


ここでは、主語がサブスクリプションモデルから、彼らに変わっています。多分これも日本語の影響でしょう。ごちゃごちゃしたら主語を変えた表現を考えてみるのもいいのかもしれません。修正後の方がスッキリしています。また、if文を使わない書き方にしています。

before

The subscription model is monthly payment. The customer can resign every time you want if they don’t like the service.

after

They use a subscription model with monthly payments. Every customer can stop using the service anytime.


これも主語の置き換えテクニックでスッキリと生まれ変わっています。

before

And they also succeed in making a stable profile because of the monthly subscription model.

after

Profit is stable because of the monthly subscription model.



5. ナチュラルな表現を採用する


文法的にあっているのではなく、ネイティブが普段つかっている文を借文しましょう。難しいことですが、普段英語を呼んでいる時からどういう表現をしているか気を配ってそれをパクるのがいいと思います。例えばこんな感じです。


目的語の対象を変えてみる


customer satisfactionではなくcustomerを対象にするように書き換えています。

before

How to make customer satisfaction using this business model?

after

How can you satisfy your customer with this business model?

修飾語をどちらにつけるか工夫する


customerが大抵スタートアップと表現するのか、大抵のcustomerがスタートアップと表現するのか、確かに下の方が英語っぽいです。

before

Their customers are mainly startup company.

after

Most of their customers are startups.


一般的な言い回しに修正する


many clientsよりも、multiple clients の方が文の意味に沿っています。 そしてcan /will はイマイチですね。if文なので、could / would の方が絶対的にいいと思います。これは習ったはずなのにw

before

If they can handle many clients, the company will pay a lot.

after

If a programmer could handle multiple clients, the company would pay more.



ドモルガンの法則っぽく集合の概念の整理の仕方を変える


これは、役割はA, Bです。Cはありません。と説明しているのを、AをのぞいてBという役割しかありません。Cはありません。と書き換えています。日本語で読むと前者の方がよさげですが、英語で見るとどう考えても下の方がカッコいい。ドモルガンの法則のようですw

before

In addition, Sonicgarden have CEO and programmers. There is no such role like manager.

after

In addition, Sonicgarden has only one role except for CEO---Programmers. There is no manager.


表現自体を変える


日本語でもそうですが、知っているとスッキリ書ける表現があるようです。この場合はbest-in-classという表現です。

before

Their payment is as high as the employee’s of listed company.

after

Their salay is best-in-class in Japan



6. 英語で世界発信してみよう


私も英語の作文はへたくそですが、これからはいろいろ英語で発信していこうと思います。最初から上手く出来るはずもないので、まず始めるのが重要なのかなとか思っています。

2013-11-24

音読パッケージと音読にむっちゃイケてるソフトウェア

21:29 | 音読パッケージと音読にむっちゃイケてるソフトウェアを含むブックマーク

最近は英語の基礎力を0から叩き直そうと、何週目かの音読系トレーニングを毎日やっています。今日はちょっとした気づきがあったので、メモがてら久々のブログを書いてみます。



短期記憶の無さを克服するつもりが、、、


 私はADHDで、物理的に短期記憶がむちゃくちゃ無いので、一番の苦手が「短期記憶」です。例えば英語の音声を聞いた時にその時は聞き取れていても、しばらくたつとスグ忘れてしまいます。そこで、それを鍛える為にいくつかの施策をやっています。その一つがリピーティングという練習です。英語の音声を聞いたら、音を止めてすぐにその文を口で繰り返すという練習です。

 こいつをしたくて私は次の本をちょっと前に買ったのですが、読み返してみるとマジでいい本でしかもこの本の提唱している音読パッケージという方法論は英語脳を鍛えるのに最強メソッドとちゃうかと思う感じです。



音読パッケージ凄い!


みるみる英語力がアップする音読パッケージトレーニング(CD BOOK)

みるみる英語力がアップする音読パッケージトレーニング(CD BOOK)


この本は本書と中級、上級があり、私はこれと上級を買ってみました。音声を聞くとむっちゃ遅いし、上級での内容が簡単なので、はっはー、楽勝よ!と思っていたのですが、ふとこの本を読み直してみると、ある事に気がつきました。そこにはこうあります。


リピーティングをしても、さまざまな間違いを犯したりしてしまうものです。トランスクリプトをを使わない、聴くだけのリスニングでは、推測による理解にとどまってしまう部分が多いので、リスニングをすませた後この聴き解きをおこなってください


この文を見て、何となくもしかして、、、と思う部分があって、やってみる事にしました。


この音読パッケージ法は、CDに1文(もしくは途中)にpauseの入った音が入っています。このpauseのタイミングで、前に流れた文をテキストを見ず繰り返します。


  1. テキストを見ないリピーティング
  2. テキストを見ながらリピーティング
  3. 音読
  4. テキストを見ないリピーティング
  5. シャドーイング

というステップで進みます。最初にテキストを見ないリピーティングをやってみました。文が遅くて簡単なので、結構いきなりまぁまぁ出来る感じです。長い文がすぐにリピート出来ない感じですがちょっと練習したら出来る感じです。意味もはっきり言ってこのレベルなら100%わかります。


リスニングの適当さが判明


 さて、意気揚々と、テキストを見ながらリピーティングに進んだのですが、リピーティングをするとこんな遅い音声なのに以外とミスをしている事に気がつきました。the/aが抜けていたり、sを忘れたり、kind of を飛ばしてリピーティングしていたり、といった具合です。自分では出来てると思っていたのに、こんなに遅い音声なのに、自分がいい加減に聴いていた事に気づく事が出来ました。そして、この本でも書いてあるのですが、文字というのはあくまでおまけであり、音がメインだから、音で英語の構文や文章の意味を理解出来る必要があります。そう思ってた私でもその「理解」が甘かったと感じられました。

 本を読むと、そもそも、文字と、音があったら、文字の方が理解しやすいという事自体おかしいのです。よくよく考えたら日本語ではそうですし、英会話の学校に居る時も、日本人以外の人は、音で余裕で理解できている感じがあります。日本人はかなり文字に頼ってしまう傾向にあるとのことです。私も音派のつもりでしたら、全然甘かったというわけです。

 そこで、音読も出来るだけテキストを見ず、音を思い出して、音で意味や文法の構造を理解出来るスピードで音読して、徐々にスピードアップするようにしたら、ずいぶんマシな感じになってきました。音で文法を理解できないとおかしいので、サンプルを聴く時もtheとかがあるか無いかとか、ちゃんとした文法で自分が話をしているかを、文をイメージせず、音で理解して喋るようにすると、その後はtheとか文法構造に敏感に聴けるようになってきました。うーむ。コレは進歩かも!こんな遅い音源だからこそ、気づけたのかもしれません。本当は簡単すぎるから「上級編」でいいかなぁと思っていたけど、この遅い音声がいいとおもったので、この音声で徹底的に英語の基礎力をあげる事にしました。(ちなみに上級編は普通の速度なので)



イギリス英語で、音読パッケージを決める



さて、私は今年のイギリス留学以来すっかりイギリス好きになってしまったので、British Councilという英会話学校に行っています。テキストやCDも当然イギリス英語です。英会話学校に行った後は、その内容を音読したり、文法を確認したり、新しい表現を自分の口で言えるようにしたりという復習をしています。この復習でも音読パッケージ作戦を使うとかなり効果的かなと思うようになりました。しかし、ポーズ付きの音声はありませんので作る方法がありません。いいの無いかなと思っていたらありました!


Best Dictation


Connecting to the iTunes Store.


このアプリ試したら最高!!!ポーズ付きの音源が簡単に作れるし、繰り返し練習もむっちゃ簡単。これはディクテーションやポージングに最高っす。!(ついでに言うと、歌の練習にもw)


 こいつで、多分15分程度で、ポーズ的な音源を作れました!そして、実際にやってみると、まぁ、激ムズでした。もう脳しびれるぐらい。スクリプトを見て意味をしらべて、意味がわかっているつもりでも、自分はなんとまぁ、いい加減にきいていたのか、いかに、theとかaとか適当に聴いているか、、、ほんま大意だけでなんとかしてた感じやなぁと反省。


 いや、本当、ディクテーションもいいけど、リピーティングはもっといい。音読パッケージ方は更に凄い!コレからも続けて、英語の文章で読んだらわかるというのと、音で聴いたらわかるという壁をまずはとっぱらいたいと思います。