AndroidにおけるJava API使用の何がフェアユースではなかったのか

Java

昨日の話の続きです。
nebuta.hatenablog.jp

Google翻訳に頼りながら判決文を眺めてみました。素人だし英語苦手なのでいろいろ誤解してるかもしれませんが、そのときはすみません。判決文の全文は以下に公開されています。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

前提

ソフトウェアのAPIが著作権法の保護対象になるということは、2015年6月に最高裁判決が出ているので、残念なことですがこれはもう確定していました（正確には、2014年5月に控訴審判決が出て、Googleが最高裁に上告。翌6月に上告が棄却されて確定した）。

今回の争点は、「GoogleがAndroidにおいてJava APIを無断流用したことがフェアユースにあたるか否か」です。米国の著作権法上は、フェアユースであれば著作権の侵害には当たりません。そこでフェアユースだとした地裁の判断に対して、Oracleが不服を申し立てたのがこの控訴審です。

4つの争点

フェアユースか否かの判断材料として、今回は以下の4つ要素がおもな争点として取り上げられています（各要素については後述）。

  • Factor 1: the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes
  • Factor 2: the nature of the copyrighted work
  • Factor 3: the amount and substantiality of the portion used in relation to the copyrighted work as a whole
  • Factor 4: the effect of the use upon the potential market for or value of the copyrighted work

この4つのうち、Factor 1と4については"フェアユースではない"方向に、Factor 2については"フェアユースである"方向にそれぞれ有利で、Factor 3については中立的であると判断されています。

On this record, factors one and four weigh heavily against a finding of fair use, while factor two weighs in favor of such a finding and factor three is, at best, neutral. Weighing these factors together, we conclude that Google’s use of the declaring code and SSO of the 37 API packages was not fair as a matter of law.

(p.54)

ただし、Factor 2については"フェアユースバランシング全体に対してそれほど重要ではない"とも記されています。

The Ninth Circuit has recognized, however, that this second factor “typically has not been terribly significant in the overall fair use balancing."

(p.44)

これらを総合的に判断して、AndroidのJava API使用については"フェアユースではない"という結論に至ったとのことです。

Factor 1: The Purpose and Character of the Use

簡単に言えば、AndroidでJava APIを使っていることが商業的な性質が強いか否か、ということです。Oracleは、GoogleはAndroidで莫大な利益を上げているから商業的だと主張していて、GoogleはAndroidはオープンソースだしGoogleの利益は検索エンジンによるものだからAndroid自体は非商業的だと反論しています。これに対して控訴裁では、商業的か否かはその利益が金銭的であるかどうかや、直接的に得られるものであるかどうかに依存しないので、Androidは商業的であると結論付けています。

それからもうひとつの大きな論点として、"transformative"であるか否かということも挙げられています。transformativeという用語をうまく解釈できなかったのですが、どうやら新しい価値を与えるような使用方法かどうかということのようです。Oracleは、Googleは単にAPIをコピーしただけだからtransformativeではないと主張していて、Googleはスマートフォンという新しいプラットフォームを作ることが目的だったと反論しています。

地裁ではGoogleの"transformativeである"という主張は認められて重く評価されたようですが、控訴審にあたっては逆にGoogleの主張が退けられました。根拠としては、スマートフォンといえども同じAPIを同じ目的で使っていることに変わりはないことなどが挙げられています。

この控訴審にあたってOracleは、数千行のOracleのJavaコードがAndroidでそのまま使われているという証拠を提出していて、これも地裁の判断を覆す大きな材料になったようです。

Factor 2: Nature of the Copyrighted Work

APIを設計という行為が創造的なものであるかどうか、という争点です。まず、コンピュータソフトウェア自体は、著作権法で保護されるべき対象という前提はすでに確立されています。そして、APIパッケージの宣言コードとSSO(Structure Sequence Organization)が著作権法の保護対象だということはすでに結論が出ています。

その一方で、APIの宣言とSSOの創造性というのは”最小限のもの”であり、APIというのは創造的な側面だけでなく機能的な側面も重要であることから、これを使用することはフェアユースであるというのがGoogle側の主張です。地裁ではこの主張が認められ、控訴審でも肯定的に判断されました。しかし前述のように、それ自体が全体に対してあまり重要ではないとされています。

Factor 3: Amount and Substantiality of the Portion Used

元の著作物の量的および質的な価値はどれくらいのものか、という争点です。これについては、開発者の負担を軽減するために、既存のAPIを流用するという行為がAndroidプラットフォームを作るにあたって重要であったことはGoogleも認めています。

Factor 4: Effect Upon the Potential Market

AndroidがOracleが本来持っていたはずの潜在的な市場での価値をどの程度損ねたのか、という争点です。これは、フェアユースの「元の作品の市場性を著しく損なうことがないようなコピーに限定される」という考え方を反映したものだそうです。

Googleは、Oracleがデバイスメーカーではないことや、まだスマートフォン市場を開拓していなかったことなどを挙げて、AndroidがOracleの市場を奪ったことはないと主張しており、地裁もそれを認めていました。しかし控訴審では、スマートフォンがOracleの"潜在的な"市場であったことは疑いがなく、デバイスメーカーでないことも（自分で作らなくてもライセンス供与などの方法があるので）意味のない主張だという結論が出されました。

結局、APIはコピーしちゃダメなの？

これらの争点のうち、Factor 1/3/4については"Androidの場合"という前提での話であって、別のケースであれば違った判断がくだされる可能性もあるでしょう。要は、フェアユースと言い切るにはGoogleが儲けすぎていて、Oracleが進出して儲けられる可能性を奪ってるよね、という話です。Oracleの主張が認められた形ですね。

一方でFactor 2は、APIの宣言コードとSSOは（著作権法で保護されるべき）創造性を持っているけど、機能的側面も強いからフェアユース性もある、ということを認めています。ただし、それはフェアユースであるか否かを判断する他の要素に強い影響を与えるものではない、ということです。

もともとフェアユースかどうかは個別の事案で判断される性質のものなので、今回の判決だけですべてのケースが決まるというわけではありません。特に今回は、商業活動であるかや、潜在的な市場価値にどれだけ影響を与えたかということが決め手になっているので、この点が非常に大きな意味を持っていると思います。

AndroidによるJava APIの使用は著作権侵害に該当するという判決

Java

詳しくないので間違いがあったらすみません。

米控訴裁判所が、Java APIの使用に関するOracleとGoogleの争いに新しい決定を下したようです。Oracleによる「GoogleのAndroidによるJava APIの使用はフェアユースには当たらず、同社の著作権を侵害している」という主張を認め、地方裁判所に損害賠償の裁判を差し戻すという判決が出されました。
Oracle wins appeal against Google in copyright case – TechCrunch

今回の判決

判決文は以下にあります。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

最後のConclusionに次のように書かれています。

For the foregoing reasons, we conclude that Google’s use of the 37 Java API packages was not fair as a matter
of law. We therefore reverse the district court’s decisions denying Oracle’s motions for JMOL and remand for a trial on damages. The district court may determine the appropriate vehicle for consideration of infringement allegations regarding additional uses of Android. We dismiss Google’s cross-appeal.

私たちは、Googleの37のJava APIパッケージの使用は、法律上のフェアユースではないと結論づける。したがって、JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定を取り消し、損害賠償の裁判を差し戻す。（後略）

言葉通り、フェアユースではないということは著作権侵害にあたるということなので、最初の損害賠償請求の裁判に戻すよ、ということです。

これまでの経緯

OracleとGoogleの争いに関するこれまでの経緯は、2016年7月のJJUGナイトセミナーの様子をレポートした次の記事に詳しくまとめられています。
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える（その１）。JJUGナイトセミナー － Publickey

重要な部分のみ抜粋すると、

  1. GoogleによるJava使用は特許侵害ではないという判決がでる（2012年5月）
  2. APIは著作権法で保護されるという判決がでる（2015年6月）
  3. GoogleのAndroidにおけるJava API使用はフェアユースにあたるという評決がでる（2016年6月）

最初の2つは、すでに判決が出てしまっているので確定事項です。また、2のAPIが著作権法で保護されるというのはJava APIに限定されたものではないので、非常に広範囲に影響するということで大きな話題になりました。

APIに著作権があるとしても、Androidにおける使用はフェアユースだから著作権法の保護の対象にはならないよ、としたのが3つ目の評決です。判決文のJMOL（Judgment as a Matter Of Law）というのがこの判断のことを指しています。

その後、Oracleは地方裁判所に対して新たな審理を求めましたが、2016年9月に棄却されています。これが「JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定」というやつです。そのあたりの経緯やOracleの主張については、下記の記事で解説されています。

オラクル、グーグルによるJava APIの使用めぐり上訴 - ZDNet Japan

今回の控訴裁判所の判決では、"フェアユースに当たる"とした判断そのものが覆されたわけです。なぜ覆されたのかは判決文に書いてあるようですが、難しそうなので読んでいません。誰か読んで教えてください。

追記：
判決文をもう少しちゃんと眺めてみたので、こちらも参考にしてください。
AndroidにおけるJava API使用の何がフェアユースではなかったのか - 我らねぶた馬鹿

今回の判決はあくまでもOracle対Googleの個別事案

勘違いしやすいので注意しなければいけないのは、「APIが著作権法で保護される」というのは、今回の判決に関係なく2015年にすでに確定してしまっています。

そしてその後にOracleとGoogleが争っていたのは、「AndroidにおけるJava APIがフェアユースにあたるか否か」という個別の事案であって、この裁判の判決が、世の中にあるそれ以外のすべてのAPIに適用されるというわけではありません。

今後どうなるか

気になるのは今後Androidがどうなるかということですが、これからまた損害賠償請求裁判をやり直すわけなので、すぐにどうこうなってしまうということはないかと思います。ただ、次にGoogleがどう出るかには注目しておいた方がよさそうです。長期的には、GoogleがJavaを見限るという極端な展開も含めて、いろんな可能性がまた復活しちゃったなあという感じですね。

JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に参加した話

Java Java10

3月26日（月）に開催されたJJUGナイトセミナー「Java SE 10 / JDK10リリース特集」に参加してきました。タイトル通り、先日リリースされたJava 10の新機能などについて特集する会で、参加者240人枠の予約がすぐに埋まり、さらにキャンセル待ち200人以上という盛況ぶりでした。やはりみんな関心があるんですね。
【東京】JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」 3/26（月）開催 - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

どうでもいい話だけど、Java 10と書けばいいのか、JDK 10と書けばいいのか、はたまたJava SE 10と書けばいいのか未だに戸惑いますね。

新しいリリースモデルのおさらい

まずはオラクルの伊藤敬さん（@itakash）から、新しくなったJDKのリリースモデルに関するおさらいから。

もういろんなところで言及されているように、OSS版であるOpenJDKについては、年2回6ヶ月毎（3月と9月）のメジャーリリース、3ヶ月毎（1、4、7、10月）のパッチリリースというサイクルになります。原則として各バージョンでリリース期間は重複しないので、次のバージョンが出たらそれまでのバージョンは非サポートになりますが、3年毎にLTS（Long Term Support）版が出ます。直近のLTSは次のJDK 11です。

Oracle JDKは、次のJDK 11以降で新しいリリースモデルが適用されて、以降は有償版のみの提供となります。リリース間隔は3年ごとで、サポート期間はそれぞれ8年間。OpenJDKと同様に3ヶ月毎に（1、4、7、10月）パッチリリースが行われます。なお従来Oracle JDKの有償版にのみ提供されていた機能については、段階を踏んでOpenJDKに移行されるので、Oracle JDKとOpenJDKは同等の内容になります。

これまで無償版のOracle JDKを使っていたユーザは、Oracle JDKを有償サポートで使うか、OpenJDKに移行するかという選択を迫られています。非LTSなOracle JDK 8のサポート期限が2019年1月（個人利用の場合は2020年12月）なので、猶予はそれほどありません。
Oracle Java SE サポート･ロードマップ

ただし、これまでのOracle JDKも無償版に関してはOpen JDKと同等のものだったので、この機会にOpenJDKに移行してしまってもそれほど大きな問題にはならないと思っています。その場合、常に最新機能に追随して6ヶ月毎にアップデートを頑張るか、LTSで3年毎にアップデートするかという選択になりますね。
それよりも問題は、Java 8からJava 9にかけては多くの非互換性が含まれているので、Oracle JDK 8のサポート期限である2019年1月までに移行を完了させられるかということに尽きますね。これから始めるプロジェクトに関しては、Java 9以降（現実的にはJava 11）をターゲットにする想定した方がいいと思います。

JDK 10の追加機能の解説

続いて、David Buckさん（@DavidBuckJP‏）によるJDK 10に追加された新機能の解説。あとから資料が公開されるので細かい話は両略しまし（公開されたらリンクを追加します）。あと、Qiitaのきしださんの記事もよくまとまっていて分かりやすいです。

Java 10新機能まとめ - Qiita

Buckさんの話の大部分は、JEP 286のローカル変数型推論についての話でした。いわゆる、Java版の「var」です。JDK 10以降では、変数の宣言時にvarを指定することで明示的に型を指定しなくてもよくなりました。これはあくまでもイニシャライザの型から自動的に静的型が推測されるだけなので、動的型とは全く違います。型を書かなくてもいいというだけで、内部的には型があります。

varが導入されたことで、Javaのコーディングスタイルは大きく変わる可能性があります。ということで、OpenJDKプロジェクトからvarを使う場合のスタイルガイドが公開されています。Buckさんの解説もこのスタイルガイドを元にしたものです。「Oracle Blogs 日本語のまとめ」に日本語訳があります。

Oracle Blogs 日本語のまとめ: [Java] Style Guidelines for Local Variable Type Inference in Java

ここでもっとも重要なのは、"varはコードの可読性を上げるために使う"ということだと思います。タイプ量を減らすといった目的ではなく、あくまでもコードをシンプルにして読みやすくするために使うということです。明示的な型宣言が無いとコードが読みにくくなりそうですが、実際にはコードを読めば何の型かはすぐに理解できるので問題なく、逆に可読性が上がるという結論が多くの言語で出ているそうです。面白いですね。

Java 10でぼくたちの生活はどうかわるのか

最後に、久保田祐史さん（@sugarlife）ときしだなおきさん（@kis）によるセッション。おもに、新機能や互換性などの情報をどう追っていったらいいかという話や、Java 10に移行する上ので注意点などに関する話。これも資料が公開されるそうなので、細かい話は省略します。

Java 10以降におけるアップデートの手順は

  1. （既存プログラムを）再コンパイルせずに新しいJava環境で動かしてみる
  2. 非対応ライブラリや非推奨APIを洗い出す
  3. 非対応/非推奨部分を代替手段に置き換える

という感じにするのがいいそうです。非対応ライブラリの洗い出しには、jdepsやjdeprscanなどのツールを使います。jdepsはライブラリの依存関係を調べるツールで、deprscanは非推奨なAPIが使われている場合に、それを検出するツールです。

個人的に気になって質問したのは、新バージョンの検証をどれくらいのタイミングで初めていくのがいいかということです。これまではリリースサイクルがゆっくりだったので、JCPが固まって参照実装が出たくらいから検証を始めて、リリース後ある程度こなれてから対応というスパンでも十分でした。新しいリリースサイクルだとあまりのんびりしている時間はなさそうなので、これがどう変わるかということです。

LTSを移行ターゲットにしつつ、その間にリリースされたバージョンを順番に検証していくという形が現実的でしょうか。OpenJDKのリポジトリを追えばリリース前にも検証を進めることは可能だけど、そのサイクルを追うのはさすがにしんどいので、LTS以外は正式リリースを追う形でもいいんじゃないか、というのがきしださんの見解。私も同意です。

また久保田さんは、「まずは Java8 → Java9 を乗り越えること。それさえ乗り越えられれば、その後のバージョン間の差分（新機能とか非互換性とか）はそれほど大きくないので、あまり怖くないはず」とおっしゃっていました。

あと「創るJavaはいつ出るか？」という質問の意図について書こうと思ったけど、長くなったので別の機会にします。

Java Day Tokyo 2018に関するアナウンス

伊藤さんから、Java Day Tokyo 2018関するアナウンスがありました。Java Day Tokyo 2018は5月17日（木）開催。基調講演に、なんとMark Rainhold氏の来日が決まったそうです。これが昨日の一番の驚き。参加登録サイトは近日中に公開予定とのこと。

JJUG CCC 2018 Springに関するアナウンス

JJUGより、 JJUG CCC 2018 Springに関するアナウンスがありました。JJUG CCC 2018は5月26日（土）開催。今月末までCall for Paperを募集中なので、ネタを持っている人は怖がらずに応募して欲しいとのことです。
JJUG CCC 2018 Spring

Eclipse FoundationがJakarta EEプロジェクトに関するサーベイを実施中

Java JavaEE Eclipse JakartaEE

去る2017年9月、Oracleはこれまで同社が主導していたJava EEの仕様策定および開発をEclipse Foundationに移行することを発表しました。
それに伴ってEclipse Foundationが新名称を決める投票を実施し、その結果をもって、今後は「Jakarta EE」の名称で開発が行われることが正式に決定しています。
https://mmilinkov.wordpress.com/2018/02/26/and-the-name-is/

現在Eclipse Foundationでは、今後プロジェクトを進めるにあたっての開発者向けのサーベイを実施中です。
Jakarta EE Developer Survey 2018

ごく簡単なアンケートです。期限は2018年3月30日11時59分（太平洋夏時間、日本時間では4月1日3時59分）まで。今後注力していくターゲットを考える上での重要な手掛かりになると思われるので、積極的に参加することをおすすめします。

自転車用スマートロック「LINKA」でセキュリティ向上なるか

自転車

実は年明け早々に愛車のMTBを盗まれてしまい、新しいMTBを買う羽目になりました。
もう盗まれるのはイヤじゃ、ということで2重ロックを徹底するべく、自転車用のスマートロック「LINKA Lock」というやつを導入しました。

f:id:zinbe:20180124120850j:plain

LINKA Smart Bike Lock - Lock Smarter, Not Harder – LINKA Smart Locks
簡単に言うと、ペアリングしたスマホとBluetooth接続が確立しているときだけ、ボタン一個でロック・アンロックできるという代物です。

その他に、以下のような機能もついています。

  • スマホアプリからアンロックできる
  • 1m以内に近いたときに自動アンロックされるモードがある
  • スマホが無いときはパスコードでもアンロックできる
    • でもパスコードの入力はちょっと面倒
  • 振動を検知してブザーを鳴らせる
  • 自転車を停めた場所（最後にロックが作動した場所）をスマホに表示できる
  • スマホに未接続の状態で一定時間経つと、バッテリー節約のためにスリープモードになる
    • 時間は設定で変更できる

YouTubeの解説動画を見ると、なんとなく様子が分かる。
www.youtube.com

ロックの途中でスポークに当たったりすると、安全装置が働いてロックが中止され、スマホに通知が来ます。
また、近づいたときに自動アンロックする機能があるものの、離れたときの自動ロックしてくれるような機能は無い模様。

もともとKickstarterで資金募集してたもので、今は市販されてるものの、169ドルとちょっと高い（ただし、日本にも無料で届けてくれるみたい）。私はメルカリで中古のものを買いました。

実物はこんな感じ。結構ゴツくて重いです。
f:id:zinbe:20180124120945j:plain

私のMTBにはダボ穴が付いておらず、ブレーキ用ブラケットも無いので、タイラップで無理やり固定しました（一応、公式にもタイラップでOKと説明されています）。
こんな感じで、ちょっと不恰好。
f:id:zinbe:20180201090022j:plain

上の動画の最後にあるようにタイラップを裏側に回した方が見た目が綺麗なんですが、私のはシートステーの幅が広めなためうまくフィットせず、写真のようになりました。
内側の横幅は2.1インチのブロックタイヤでもほんの少し若干余裕がある程度。縦幅は、フェンダーが無ければ余裕でした。

取り付けて1週間ほど経ちましたが、今のところ快適に使えています。
特に、コンビニに寄ったときなどにいちいち鍵を取り出す必要が無いのがいい感じです。
バッテリーは1週間で6%減。この分なら2〜3ヶ月に1回充電すれば足りそうです。充電はmicroUSBでできるので、モバイルバッテリーを繋げば良さそう。
f:id:zinbe:20180201134404p:plain

なお、長時間停めるときには、これとは別にワイヤー錠も併用して2重ロックにしています。

現状の不満点を挙げるとすると、次のような感じです。

  • ロック・アンロックが遅い
    • 開始から完了まで3秒くらいかかる。途中で揺らしたりすると安全センサーが働いちゃうので、動かさずに待つ必要がある。
  • ボタンが固い
    • 指が痛いくらい思いっきり押さないと反応しない
  • スリープからの復帰したときに、Bluetooth接続の反応が悪いことがある
    • スマホのアプリを立ち上げ直すと接続されるので、たぶんスマホ側の問題。仕組み上仕方ないのか

私が買ったのは「ORIGINAL LINKA」の方ですが、春にはGPSトラッキング機能も付いた新製品が出るみたいです。
GPS付いてても、通信はどうするんだろうってちょっと疑問ではありますが。

ちなみに、同様のスマートロックで「I LOCK IT」という製品もあります。
Bike Lock - I LOCK IT - The Smart Bike Lock
実は最初はこっちの方が気になっていたんですが、公式サイトからは日本には発送していないということで断念しました。
自動ロック機能があったり、オプションでKye fob（スマホいらずの電子キー）があったりして、こっちの方がちょっと高機能な気がします。

「#12 Creators Learning English Meetup」 #clem_jp

英語 CLEM

先月に引き続き、「#12 Creators Learning English Meetup」に参加してきました。

clem.connpass.com

Creators Learning English Meetup 略して「CLEM」は、英語を勉強中のエンジニアやデザイナーを対象としたMeetupで、ほぼ毎月開催されています。
英語の勉強法やTipsを発表し合ったり、英語で挨拶や会話をするなど、とにかく英語に触れる機会を増やそうという会で、Meetup以外に朝活などもやっているそうです。

今回は開催1周年記念ということで、2017年のCLEMで登場した英語学習Tipsのおさらい、LT大会、として
簡易版"他人に目標を立ててもらう会"（タニモク会）の3本立てでした。

まず https://twitter.com/kayoko_coco:@kayoko_coco さんより2017年の英語Tipsまとめ。去年のCLEMでは、次のようなTipsが挙げられたそうです。

  • 英語の学習はスポーツと同じ
  • 諦めから始めることで挑戦のハードルを下げる
  • 英語で自分が何をしたいのか具体的にイメージしよう
  • 根拠のない自信を持とう！
  • まずは3000語程度の語彙力をつけよう。日常会話は3000語くらいで理解できる！
  • あらゆる隙を見つけて、英語でできることが英語でやる！
  • 独り言を英語で
  • 発音はカタカナで覚えてはダメ。耳コピ、発音記号で
  • オンライン英会話ではお気に入りの先生をまず見つける
  • 英語は英語で勉強しよう！

また、英語学習にオススメの参考書として次のようなものが紹介されました。

補足で、htj_fusionさんからおすすめアプリとしてHelloTalkの名前が挙がりました。

続いて新年LT大会。
まずレアジョブの山田さんから、「オンライン英会話のコツ」。これは、リアルタイムで講師につないでオンライン英会話を実演するという珍しいスタイルの発表で、どんな感じでレッスンが行われるのかがよくわかる、非常に素晴らしい発表でした。


こんな感じ。さすがレアジョブさん。

続いて@d_dateさんより、去年1年間の英語活動報告。海外カンファレンスに参加したり、OSSにコントリビュートしたり、try! Swift Conference の運営に携わったりと、積極的に実践的な活動をされていて、刺激になりました。やはりエンジニアたるもの、単に勉強するというだけに止まらず、こうありたいものだと思わされました。

3番目は私（@zinbe）より、仕事でポルトガルなどの海外に行くことになった経緯と、そのためにやった英語の勉強方法、実際に行ってみてどうだったのかなどを話させていただきました。

www.slideshare.net

できるだけ英語で頑張ろうと思ったのですが、無理でした（というかスライド作りも途中で諦めてる）。でもこのレベルでも海外で仕事できちゃうんだ、という勇気付けにはなったのではないかと思います。
そう、このレベルでも意外と何とかなっちゃうんです。だから恐るるに足らず！
今年は、"何とかなっちゃう"のレベルを脱却できるように頑張ります。

後半はワークショップの時間で、他人に目標を立ててもらう会 （通称タニモク会）の英語特化簡易版。自分が現在置かれている状況をパートナーに説明した上で、今年の目標を立ててもらう、というものです。
私の状況はLTでほぼ話した通りだったのですが、それにねぶたが趣味だということも加えて、次のような感じの目標をいただきました。

  • 一通りのストーリーを持った英語でのプレゼンを、しっかり準備をした上でやってみる
  • 英語で行われる、IT関連のオンライントレーニングコース（Courseraにみたいな）を履修する
  • 外国人旅行者向けの観光案内ボランティアなどに参加する

日常で英語を使う機会を増やさなといけないというのは常に感じていて、観光案内はちょっと気になっていたところでした。TELPみたいなサービスも出てきたしね。ねぶたのことなら案内できる自信があるんだけど。

そんな感じで、このところ下がりかけていたモチベーションがちょっと持ち直しました。頑張ろう。

#11 Creators Learning English Meetup に参加してきた話 #clem_jp

CLEM 英語

12月4日に開催された「#11 Creators Learning English Meetup」に参加してきました。
clem.connpass.com

Creators Learning English Meetup 略して「CLEM」は、英語を勉強中のエンジニアやデザイナーを対象としたMeetupで、ほぼ毎月開催されています。英語の勉強法やTipsを発表し合ったり、
英語で挨拶や会話をするなど、とにかく英語に触れる機会を増やそうという会で、Meetup以外に朝活などもやっているそうです。

今回は2つのワークショップとLT大会の、大きく分けて2部構成でした。
ワークショップで得られたポイントは以下のような感じ。

  • 相手の目をちゃんと見て話をする
  • 初対面の挨拶は、握手→簡単な自己紹介→質問や世間話など
    • Closed Qustion（Yes/Noで答えられる質問）よりも、Open Qustion（5W1Hを使うような質問）をした方が会話が続くのでおすすめ
  • 名刺交換は会話のあとに。相手の名刺の名前を読む。両手を添える必要はなし！

ちゃんと相手の目を見るということのトレーニングとして、相手の顔を見たままで（紙を見ずに）、相手の顔半分を描くというワークショップをやりました。
Open Qestionはいつも実践しようと頑張っているつもりですが、いざやろうとするとなかなか難しいよね。

LT大会は、偶然にも海外カンファレンス参加特集になりました。海外のカンファレンスに参加するにあたって、どうやって英語を勉強したか、というような話。ここでの知見をまとめると、

  • いろんな英語の勉強法
    • オンライン英会話
      • 習慣化することが大事（毎日の時間を決める、先生を固定する、など）
      • テンションが高い先生を選ぶとやりやすい
    • 英語オンリー飲み会
    • ネイティブスピーカーが一緒に参加しているとすごくいい
    • 日本語を使ったら罰ゲーム
    • YouTubeやPodcastで技術関連の英語コンテンツを視聴する
    • 単語集はDUOが最強
    • 単語帳アプリはAnkiがおすすめ
  • ちょっとした手土産を持っていくと、会話のきっかけになるのでおすすめ
  • 海外カンファレンスはパーティー。英語が不安とか言わず、どんどん行ってみた方がいい

こんな感じでしょうか。

私自身、英語はできないながら、海外カンファレンスへの参加回数だけはそこそこあるので、今回の話はあるあるネタが多くて楽しかったです。一方で、英語の勉強法については自分のやり方との違いなど、勉強になる部分がありました。とりあえずDUOやろうかな。

次回は1周年記念ということで、今年1年に出てきたTipsの総ざらいのようなことを計画しているそうです。