おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(4)

 最後は試験によって得られた成果と、最近の取り組みについての話でも。

TOEICに取り組んだ結果

 よく、『TOEICに意味はない』『TOEICなんてやっても無駄』とか言われたりもしますが、私にとっては結構意味がありました。

1. 一定のレベルに達すると、『英語に関わる』ことに対する抵抗感がなくなる

 一言で言うと、『英語アレルギーを克服できる』ってことです。

 私の場合大体700点台に到達したあたりから、

  • あれ? 何か英語勉強していてもあまり苦しくなくなったな

 という感覚が出てきたんですね。それどころか、

  • この英語圏の情報、取りに行ってみるか

 と、自分から英語の情報に手を伸ばせるようになります。

 昨年9月にこんな記事を書いたと思うのですが、

dimeiza.hatenablog.com

 このNUC、amazon.comで、つまり英語圏で買い物をしているんですが、実は昨年の7月に700点を達成していた後のことだったりします。

 その後、昨年11月のサイバーマンデーRyzenamazon.comで注文してみたり、先日はEssential Phoneを注文したりと、英語圏で買い物をすることができるようになったばかりか、先日はサポートを受けるために英語でチャットしたりと、自分の目的を達成するためのツールとして使い始めるようになりました。

2. 英語アレルギーを克服するまでの間は、スコアが補助輪的なインセンティブになる

 英語アレルギーを克服して、英語に自然に触れるようになると、学習と実力の間に障害なく正のフィードバックが回り始めますが、それまでの間はどうしても『分からない』『理解できない』苦痛が出てきてしまうんですね。

 自然な成長実感が得られないこうした時期においては、数値として見えるスコアが上がっていく、という『分かりやすいフィードバック』が、学習者を補助的に支えるという効果を持ちます。

 TOEICのスコアは優劣を競うものではなく、実力を序列化するものでもなく、単に『一私的団体が作成した問題をどれだけ解けたか』の指標でしかありません。どう使うかはすべて受験者に委ねられている、と言ってもいいでしょう。

 なので、受験者としては、『自分にとって最も価値のある解釈の仕方をする』のが合理的です1

 その一つとして、『成長を可視化して実感を作り出す』という使い方をしてもいいんじゃないかと思います。

3.英語で世界に働きかけられるようになる

 ご存知の方もいらっしゃるかと思いますが、昨年末からこんな取り組みをしていてですね。

qiita.com

qiita.com

qiita.com

qiita.com

qiita.com

 AlexaとGoogle Assistantを1台のRaspberry Piで同時に動かす、って話なんですが、両者の公式情報に当たるとすぐに分かる通り、いずれも英語の情報なんですね。

 読めるようになったので英語の情報を拾ってくる、ってだけじゃなくて、この成果をyoutube英語で公開したら、外国の人から質問が来たので、諸々やり取りしたりしています。

 さらに調子に乗って、githubに成果物を公開して、英語でREADMEを書くところまでやってしまいました。

github.com

 この辺、(特にRaspberry Pi zeroでのWakeword付き並行動作は)あまり先例のない試みなので、ほんのわずかですが世界にcontributeできたんじゃないかな、と。

 アウトプットはまだ始めたばかりで、google先生の力も借りていて、見る人が見ると下手なんじゃないかと自覚はしているのですが。

* 下手だろうが知ったことか! 全力で伝え、伝わればいいんだ!

 という開き直り感が最近出てきましてね。

 日本のAmazonで、片言の日本語で一生懸命商品を紹介しながら、それでも売り上げを稼いでいく中国の人たちの商魂を見ていると、

* 上手下手に拘らず、とにかくコミュニケーションに挑む

 ということが、今後英語を一層求められるようになるであろう、われわれ日本人が認識しておくべきスタンスなんじゃないかなぁ、と最近思い始めています。

ここから先、歩むべき道

 ぶっちゃけですね。

* 730取ろうが800取ろうが、読めない単語も多いし意味の取れない文章も多い

 のですよ。世間で憧れられているような、ペラペラスラスラの領域はまだまだ程遠いのです。

 ただ、800は一つの節目であり、私自身の今年の目標と合わせて、今後はReading, Listeningの取り組みと並行して、Speaking, Writingの2つの側面を新たに加え、4つの領域から英語を深耕していこうと思っています。

 今取り組んでいることを書いておくと、こんな感じです。

Reading

 通勤電車の中で、過去に読んだ邦訳文書の原典に当たっています。

 一つはこれ。

www.joelonsoftware.com

 私は若いころからJoel On Softwareの大ファンで、20代のころはmoreも含めて暗記する位読んだんですよ。

 これを英語で読んだらどんな感じだろうなぁと思って、邦訳があるエントリを中心に読み始めています。

 もう一つはこれ。

 これも邦訳を読んで瞠目させられた口なので読み始めていますが、まだちょっと難易度が高いかな、という印象。

Listening

 『1日1TED』と勝手に名付けたキャンペーンを絶賛実施中です。

www.ted.com

 実は枕元にiPadを据え付けていて、寝ながら動画を見れる環境があるんですが、平日は必ず寝る前に1つTEDを聞くことにしているんです。

 聞き方は、あえて日本語字幕を表示しつつ、英語を聞き取って、日本語字幕と対比する、という感じです。

 ヒアリングした単語から日本語の文章を組み立てられるか、という視点で聞くと、聞き取りの精度に自覚的になりつつ、聞き取れなくても興味深い内容を取りこぼさなくて済むので、楽しみながらヒアリングを鍛えられるかな、と思っています。

 寝る前の学習は記憶にもいいらしいですし、寝ながらで気楽に聞けるので、いい感じで続いています。

Speaking

 ここはまだ始めたばかりで、今のところは瞬間英作文に手を付け始めました。

 もう少し力を付けたら、TerraTalkとかにも手を付けつつ、慣れてきたら英会話教室かなと思っています。

www.terratalk.rocks

Writing

 この辺は先日のGitHub以来、まだあまり手がついてません。

 技術情報を英語で書ければなーと思っていますが、もう少し学習寄りの活動を視野に入れた方がいいのかも、と考え中です。

さいごに

 1年間にわたって挑んできたTOEICですが、スコアを徐々に上げながら、英語学習のループを作ることができ、いい感じで成果を収穫できたように思います。

 まだまだ会話も含めた実用には程遠いので、学習はずーっと続くのですが、とりあえず苦手を克服し、次の領域へのステップを踏むことができたかなと。

 『万人にとって有効な唯一の英語学習法はない』ので、ここに書いてあることがどれぐらいの人に役立つのか分かりませんが、私と同じように英語アレルギーに苦しみ、苦手を克服して世界を広げようとする人々(特にエンジニア)の役に、少しでも立つことができたら、筆者としては何よりの幸いでございます。


  1. そういう意識もあって、最初の回で述べたように、私はあえて非対称な解釈の仕方をしていた、というわけです。

おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(3)

 前回まででモチベーションについて書いたので、今回は具体的な学習サイクル、教材とか、戦術の話をします。

学習サイクル

 実は今回の英語学習のサイクル、一昨年までにやってきた高度情報処理技術者試験勉強のサイクルとほぼ同じなんです。

学習時間的な話

 学習時間で書くのが簡単かと思うのでリストアップしますが、実は以下2種類の時間しか使っていません。

  1. 通勤電車の中(往復合計で約30~50分)
  2. 週末午前中(土日、約120分づつ)

 これを大体1年間やりました。ってことは単純計算で1

学習タイミング 学習時間[分] 回数[回] 合計[分] 合計[時間]
通勤時間帯 40 260 10,400 173
週末(土日) 240 52 12,480 208
合計 280 312 22,880 381

 400時間に満たないですね。

 ただまぁ、仕事の中で英語の文書を読んだりはしているので、その辺を加味するとずいぶん違ってくるとは思います。私は比較的読まされる量が多い方かもしれませんが、エンジニアであれば、最近のオフィシャルドキュメントはたいてい英語だったりしますから、そんなに大きな差はないかとは思います。

 学習時間、今計算してみて意外に短いなぁ、と自分でも思いましたが、この学習タイミング自体は意図的に計画したものです。

 前回も書いた通り、仕事をしたり家事をしたり、睡眠もしなきゃいけませんから、生活サイクルとコンフリクトする計画は立てられないですし、学習時間を延ばして苦痛になって辞めてしまったら意味がありません。

学習時間の『品質』

  そうは言っても限られた時間なので一つ工夫したのが、

* 『高品質な学習時間』と『低品質な学習時間』を分け、それぞれに最適な勉強をしよう

 ということでした。

 例えば通勤時間は電車の座席に座って(あるいは立って)、学習コンテンツを視聴するわけですが、電車の中って語学学習の邪魔が結構入るじゃないですか。

 ましてや紙と鉛筆を広げて問題を解く、なんてことはとてもできないわけです。

 一方で、週末自宅の机に向かっているときは、

  • 様々な娯楽コンテンツの誘惑はある

 のですが、

  • 電車に比べれば比較的静か
  • 机も広いので紙と鉛筆を使おうがパソコンを使おうが自由自在

 という環境の静謐と空間的余裕があります。

 なので私は、

* 自宅週末の『高品質な学習時間』では、新しい概念(新単語、文法、発音)の習得に注力する

* 電車の中の『低品質な学習時間』では、既存概念の復習、適用に注力する

 という立て分けをしました。

 両時間ごとに、使用したコンテンツを紹介していくのが、この際ちょうどよさそうですね。

『高品質な時間』に取り組んだ事柄

 大きく3つの取り組みをしています。

1. iKnowで『新規単語』のインプット

f:id:dimeiza:20180407162949p:plain

 まずはiKnowで単語学習。

 iKnowは『新規単語を学習』→『忘却タイミングに合わせて単語の問題を繰り返し出題して復習』→『一定数正解するとマスター』という流れで単語学習を進めるようにデザインされています。

 iKnowを開くとこんな画面が出てくるんですが、下の『アイテム』に『新規のみ』と書いてある場合、既出単語の復習を全く行わずに、新規単語だけが出てくるようになります。

 これを1回につき20から40単語回してました。

 iKnowでは問題に回答した際、単語を使った例文が出てくるので、その例文を有声でリピーティングしてます。

 最初に単語学習を持ってきているのは、簡単でとっつきやすく、気乗りがしないときでも、学習に手を付け、継続するための呼び水になるからです。

2. DSの英語アプリを動かす

 最初は1回目で説明したえいご漬けをやっていたのですが、文字の認識率が低くてイライラしてきたので、このイライラは危険だなと。

 今回は従来と違ってTOEIC照準で勉強しているので、途中から、比較的新しいこれに切り替えて勉強を進めていました。

 各パートごとに勉強できて、それほどストレスなく操作できているので、割と長く続いていますね。

 あえて自宅でDSによる学習方法を選択しているのは、

  • 回答を紙に書いた後で、自分で自己採点するのが面倒

 という心理があったからです。

 そもそもTOEICの本試験だってOMR(マークシート)で採点しているのに、人間様がわざわざ手書きで採点する技術的必要性なんぞなかろう、と。

 『公式問題集で勉強するといいよ』と周囲にも言われていて、やった方がいいんだろうなぁ、と思ってはいるのですが、結局手を付けずにここまで来ています。

 このソフト位の手間で自動的に採点、評価してくれて、かつ新形式に対応した電子上の高品質な学習コンテンツがあれば、是非それをやってみたいと思ってはいます2

 大体このDSによる学習を30分から40分ぐらいやって、次に入ります。

発音または文法の学習

 あとは発音の練習『か』文法の練習をやって、その日の学習を終えていました。

 両方同時にはやらないようにしていました。疲れるので。

 発音についてはこれで。

 後半のParrot's Lawとか英文読書はとりあえず置いといて、発音バイエルを最初から最後まで、付属のCDをシャドーイングする形で練習していました。

 TOEICに関しては、『正しい発音を知らないと、脳内でカタカナ変換を伴ってしまうので、英語をパッと理解できない』という点がListeningに効いてくるので、一見関係ない発音の練習は(今後会話に進むための下準備としても)しっかりやっておいた方がいいかと思います。

 あと、この本の『はじめに』に書いてある

結局、語学の学習の秘訣は『壮大な慣れ』です。

 という言葉はすごく私に刺さりました。

 これを読んだとき『特別なことをする必要はなく、慣れないことと分かったうえで何度も繰り返して、長い時間をかけて慣れていけばいいんだな』という理解と安心を得たのを覚えています。

 一方、文法についてはこれで。

 この本、『構造、フレームワークで英語の文章構造を論理的に分解する』という点において、非常によくできた本です。

 われわれ日本人は日本語の文章を理解するときに、わざわざ『単語を分解して、各単語の品詞を解釈して、構造を把握した後で意味を理解する』とか七面倒なことをやってないかに見えるんですが、それはやらないのではなくて、脳内で超高速に無意識的にやっているだけだったりします。

 実はこれは英語についても同じことが言えるのですが、我々は英語の文章を超高速かつ無意識的に品詞分解、構造把握できるわけではないので、まずは意識的にそれをやりましょうよ、という本ですね。

 個人的には、この本は論理的思考を求められるエンジニアに対しては結構親和性が高い本なのではないかと思いました。理詰めで、『なぜこの単語はそのように解釈しなければならないのか』といった問いに答えてくれる本です。

 この本は文法の基本要素から少しづつ読み進めつつ、読み進めるたびに練習用テキストが提示されます。そのテキストに対して、文法上のQuestionが提示されるので、Answerをよどみなく言えるようになることを求められます。

 このQuestionに対するAnswerを口頭で回答する練習をひたすらやっていました。

 実はAnswerは暗記しても良い、とこの本自身に書かれているのですが、実際に暗記していくだけでも、練習用テキストだけでなく初見の英文に対して、構造を自動的に解析する癖がついてくるんですよ。

 この効果はPart5以降のReadingにおいて絶大なものがあります。気づかない間に、

  • あぁ、この"arrived"は『準動詞』で、『分詞構文』ではなく『過去分詞形容詞用法』で使われているから、『大黒柱』になる動詞は別の動詞"went"の方だな
  • あれ? ここには現在形の『述語動詞』が2つある。両方とも『準動詞』にはならないから、後ろの方は『従属節』か

 みたいな構造把握のための脳内回路ができて、問題を解くときに自動的に作動するようになってきます。

 一方で、実はこの本についてはいろいろ批判があります。著者の薬袋先生もそのことを認識していて、『あとがきに代えて』で批判に対する回答をしていたりするんですが、その中にこんなことが書いてあります。

これは私の持論なんですが、英語の勉強法には、万人に妥当する唯一絶対の方法などというものはない。

大事なことは無作為に抽出した10人の中にいつも2人は私のやり方で劇的にできるようになる人がいるということなのです。また、この2人に入らなくても、私のやり方に触れて魅力を感じる人であれば、勉強を続けると必ず実力は向上します。

 私はこの本で文法に関する理解が一気に進んだので、『劇的にできるようになる人』に近い感覚を抱きました。ただ、人によるのではないかとも思っているので、一度見てみて、合うと思ったらやってみるといいんじゃないかと思います。

TEDを聞く

 これは余裕があれば。

 ノルマをこなし終えて時間と精神に余裕があれば、TEDで興味のあるネタを見つけて聞いていました。

www.ted.com

 TEDについては最近取り扱い方を変えているので、最後にちょっと話をします。

『低品質な時間』に取り組んだ事柄

 通勤電車内で何をやったか、って話ですね。

1. iKnowで既出単語の『復習』

 週末に勉強した既出単語の『復習』に絞って取り組みます。

 iKnowの学習サイクルの中で新規単語を学習しようとすると、そのサイクルはボリュームが増えてしまう、という特徴があるのと、落ち着かない電車内でやるなら、新規学習という高コストの学習作業ではなく、もう少しハードルの低い復習をやろう、という発想です。

 この時もリピーティングしていますが、流石に声を出すわけにはいかないので無声で。

2. 英語リーディング教本の読解

 文法書を読むだけならパッシブな作業なので、それほど苦も無くできます。ここで文法の内容を先に読んでおいて、週末に暗唱する、という流れです。

3. 英語ニュースを読んでみる

 これは比較的最近の取り組み。POLYGLOTSを使っています。

play.google.com

 テクノロジーのジャンルからニュースを取ってくると、TechCrunchのニュースとかを表示してくれるので、エンジニアも興味を持って読み進めることができます。

 WPM(Words Per Minute)とか、読解速度を表示してくれたりするんですが、読むのが遅い私は大抵比較されると凹むので、あまり気にせずに読んでいます。

ここまでのまとめ

  • 学習は通勤電車の中と週末に集中的に。苦痛にならないような時間配分を意識した。
  • 週末の高品質学習時間では単語学習から入り、手や口を動かす高コストな学習を実施。
  • 通勤電車の低品質学習時間では既出単語の復習や文法読解など低コストな学習に絞って実施。

 こんな感じですね。

 ただ、これで十分だとは思っていなくて、より良い勉強法を今もなお模索中です。

 最後は試験によって得られた成果と、最近の取り組みについて話をしようかと思います。


  1. 1週間52週、毎週5日通勤。祝日や休暇を考えるともう少し少ないかも。

  2. PC、DS、スマホ等でよさげなのがあれば教えてください。

おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(2)

 前回までで英語学習のための背景を話しましたが、次は学習の骨格となる、モチベーションの話を。

モチベーション

 『英語を勉強する』って言うと、この現代社会、右にも左にも勉強法が溢れていて、頼まなくてもノウハウを教えてくれるような世界だったりするじゃないですか。

 ところが、あちこちで聞きまわったノウハウを手にして実際に英語学習に取り組もうとしても、長続きしなかったり効果が出なかったりするというケース、割と多かったりしません?

 少なくとも私はそうでした。

  • えいご漬けでゲーム感覚で勉強しているはずなのに、いつしか苦痛まみれになり、勉強を止めてしまう
  • iKnowをLifetimeプランで買って自腹を切っているのに、やっぱり苦痛で単語が身につかない
  • そもそも12年間も学校英語やってきて、しかも好成績で卒業しているのに、一向に英語が楽しくない

 最後の奴、実はそうなんですよ。学校英語の成績は決して悪くなかったのに、社会人になってから英語に苦しんでたりするんです。

『自分にだけ意味のある、英語に取り組むメリット』に腹落ちする

 この理由はいたって簡単で、

* 英語を習得する/使いこなすことに対するメリットを腹落ちしていない

 ことに尽きます。

 口でも頭でも『英語を理解できたらいいなー』と漠然と思っている状態だと、英語学習を作業以上の何者かにすることができないんです。

 前の記事で長々と、個人的な背景を語ってきたのには明確な理由があって。あそこで書いたことが、『私にだけ意味のある、英語に取り組むメリット』なんです。

 客観的に見れば、英語を習得した程度で、一個人が世界に何等か影響を与えることなんてできないのかもしれません。

 しかしそれは他人にとっての意味付けであって、私にとっては関係のない話です1

 自分の中に、自分のためだけの、英語を取得するメリットが内発的に存在し、燃え続けている限り、英語学習の歩みを止めない原動力になりますし、空回りを防ぐこともできます。

 まずはこれを灯し、薪をくべ続け、消さないことを意識しましょう。

長期戦であることを覚悟する

 よく、『2か月で』『3か月で』800点取るぞ的なキャッチーな広告なり、成果報告なりを目にすることがあります。

 短期間でがむしゃらに、というのは確かに一見効率よく見えますし、実際に成果を得られるのであれば、それはそれでよいことだと思います。

 一方で、学業にすべての時間を使える学生と違って、現実世界で日々の仕事や生活に追われながら生きる我々としては、1日10時間の勉強なんて空想の中だけの話ですし、5時間確保するのだって極めて難しいわけです。

 また、後述しますが、TOEIC800点取ったからと言って、一部で喧伝されるような英語全能者になれるわけではないですし、これから先も絶え間なく学習の道は続くわけです。

 この辺の状況を考えると、

* 会話も含めた実践的な英語習得はロングスパンで計画し、行動する

 ということは大事です。

 私の弟は大学時代から英語に秀でていて、今は世界を飛び回りながら英語で研究者と議論するような堪能な奴なんですが、その弟にして、

『英語の勉強ってコスパ悪いからね』

 って言ってましてね。短兵急に結果を求めて落胆しないようにするためにも、長期戦であることは覚悟しておきましょう。

苦痛にするほど追い込まない

 長期戦である、ということは、『一瞬だけ苦しい思いをして突き抜ければあとは楽』みたいな戦術が使えないってことです。

 もし日々の戦いが苦痛で、その戦いが長期戦なら、ずーっと苦痛が続くことになりますが、それは誰だって嫌ですし、脱落者を生む道ですよね。

 であるならば、

* 日々の取り組みを苦痛にしない。苦痛だと思ったらいったん止めるなり、やり方を変えて苦痛でないようにする

 という意識もまた必要になってきます。

 ずいぶん昔にこういうツイートが流れてきたんですが、

 私はこれとは逆の立場を取っていて。

 例えば今は昔と違って、新技術を広く展開しようと思ったら、ペインレスなチュートリアルって必須じゃないですか。

 最近だとAVS Device SDK/Google Assistant SDKAmazon FreeRTOSのチュートリアルなどは、指定された機材(Raspberry Pi等)をそろえて指定された手順通りにやれば、サクッと動く成果物を作ることができます。

 学習曲線を急峻にせず、一段階づつ着実に、転ばないよう無理なく知識を与え、最終的に何等か動く成果物をインセンティブとして与えるように設計されているわけです。

 適切に設計された学習計画を公式が与えることで、新来者を増やしてユーザの水かさを増し、市場を取っていくのが今どきのイケてる技術普及戦略ではないかな、と。

 我々が英語のチュートリアルを自分たちのために作るとしたら、同じように学習曲線を急峻にせず、転ばないように整備し、(自分という)ドロップアウトを出さないデザインにしたいと思いませんか?

 私はそう思いました。

 となると、

  • 1回の学習時間を長時間にしない。
  • 生活や仕事とコンフリクトするサイクルで学習しない。
  • 学習時間の中に、学習の本質と関係ない不要な手間を含めない。
  • 学習にリズム、サイクル、イテレーションを与え、成果にインセンティブを与える。

 といった円滑化を考えていくことも、一つ無視できない要素になってきます。

自分にとって最適な勉強法は自分でしか発見できない

 最後はこれです。

 Qiitaですげー数のいいねがついているこの勉強法、私も見たのですけど。

qiita.com

qiita.com

 2つ目は私が英語学習に取り組む前に見ていました。両方とも、私もいいねしましたし、成果を出していて立派だと思いましたし、一部は参考にしています。

 ただ、『これが私にとって最適な勉強法か?』と言われると、答えは明確にNoなんです。

 例えば前者で言うと、

1000時間やることにします。1日3時間くらいやればよさそうです。

 この時点でエー、と思うほど、私は根性なしですし、

まず最初に発音、基礎文法、瞬間英作文をやりました。

 発音と文法は私も取り組んだんですが、瞬間英作文は800取るまでに全く手を付けていません(今ちょうどやり始めています)。

 後者については、

2010年10月(大学2年生/学習開始時)

 先方は学生、一方でこっちは社会人(しかもいい歳の)で、置かれている環境、コンテキストからして全く違うわけです。

 自分にとっての勉強法を考えるときに、(このBlogも含めて、)他者の成功体験を参考にすることはできます。

 が、自分という人間のコンテキスト(境遇、仕事、性格、傾向)を知っているのは自分だけなので、そのコンテキストに最適な学習法を編み出せるのは自分だけだ、ということは認識しておくといいと思います。

 誰かが成果を出した勉強法であっても、自分がやりたくなかったり、成果が出なかったりするのであれば、自分にとっては無価値。逆に誰かにとって意味がなかったとしても、自分が成果を出せるなら、そのやり方には自分にとっての価値がある、ということです。

 平たく言うと、『英語の勉強法は(自分も含めて)学習者の数だけ存在する』のです。

 自分の学習法は他人からコピーするのではなく、これまで述べた3点を意識しつつ、いいと思ったものをまずは取り込んでみて、実際に回しながら評価し、組み立てていくと、しっくりくるものができるんじゃないかと思います。

ここまでのまとめ

  • 誰よりも自分にとって、英語を学ぶメリットを意識し消さないようにしよう。学習という作業をする価値はそこからしか生まれない。
  • 長期戦であることを覚悟する。たとえ800取っても英語への学びはずっと続くのだから。
  • 学習を苦痛にしないようにしよう。自分にとっての英語チュートリアルをペインレスに、ドロップアウトを出さないように設計する。
  • 自分に最適な学習法は自分で組み立てる。他人の成功例をうのみにする代わりに使える所を盗み、回しながら評価しよう。

 一見ポエム的に見えるんですが、自分の感触としては学習計画や方法よりも、この辺りのモチベーションが学習の骨格であり、成否を分けると思ったので力いっぱい書きました。

 では、そろそろ戦術的な話に入っていくことにしましょう。以下次号。


  1. 最後に成果をちらっと話しますが、英語でアウトプットをし始めたりしているので、ほんのわずかではありますが影響を与え始めたりしています。

おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(1)

はじめに

 先日、表題の事項が発生しまして。

f:id:dimeiza:20180405203947p:plain

 今回に関しては、まぁなんというか、率直に言ってまぐれだとは思ったのですが、

  • もう若くもなく、学力も全盛期(20台)には到底及ばない、いいお年頃のエンジニアが、
  • 英語好きではなく、むしろ英語アレルギーを抱えた状態から、
  • バリバリがむしゃらにではなく、仕事と両立しつつ、無理せず、ゆっくり着実に
  • 予定より半年前倒しで、多くの人の目標点に到達した

 という状況になってしまったので、これは自分のやってきたことをシェアしておかないと罰が当たるんじゃないかと思い、筆を執ることにしました。

背景

 TOEICへの挑戦を始めたのはちょうど1年前ぐらいの頃でした。

仕事からの要求

 これまでも仕事の中で参照技術仕様やら何やらで、英語の読解を求められることは多かったのですが、そのたびに『なんとなく理解』『勘』『他力本願』で何とかやり過ごしてきました(と言うと関係者にすっごく怒られそうですが)。

 ただ、ここ最近は以前にもまして、対峙する技術仕様に英語の割合が増えてきたのです。

 しかもソロで動くことが増えてきていて、他人の力を借りることも難しくなってきました。

情報獲得の速度

 一方で、Twitterとかで諸外国やら、識者から流れてくる情報を眺めていると、大抵英語が最初の情報源じゃないですか。

 そして、英語で発信されたものが日本語に変換されて国内で周知されるまでに、どうしてもタイムラグが発生してしまう、と。

 技術の情報源が母国語頼みだと、タイムラグの長さによって、われわれ日本人は2種類の不利益をこうむってしまう、と思ったのです。

1.情報の鮮度が失われ、価値を失い陳腐化する。

 せっかく収集の努力をしても費用対効果が悪くなってしまいます。

2.母国語では決して発信されない情報が存在する。

  海外の技術書だと、ずーっと翻訳されない名著があったりしますよね。

 どの本だか忘れましたが、2000年代に英語で著された本が、10年以上後になって邦訳された、なんて話を聞いた辺りで、

  • 英語の情報源の取り扱いを他人には任せておけないな

 と思いました。

自分は世界を変えられるかもしれない

 もう一つ、あまり社外にアウトプットしてないので張り子の虎なんですが、IT関連のセンスは(周りの人と比べると)自分では結構あるなと思っているのです。

 小手先の技術だけではなく、取り扱う技術の広さや、設計やマネジメントの考え方、知的財産等異分野の知識など、若手にはない地力もついてきています。

 そういった(ある程度肥えた目で)、英語圏から発信されてくる情報とか、海外を渡り歩くような一流の有識者の言動行動を見ながら、不遜にも

  • こんなの、単に英語だってだけで、言っていることや考え方は(我々と)それほど大きな差はないんだな

 と思い始めてしまったのです。それどころか、

  • ひょっとして、自分は英語ができるようになったら無敵なんじゃないか?

 傍から見ると噴飯物な、根拠のない自信を持つようになってしまったのです。

 まぁ実際そんなことはないでしょうし、大抵の人は鼻で笑うと思うのですが、この、

  • 英語を学ぶことで、自分は世界を変えることができるかもしれない

 という、アウトプット、アクティブ志向のモチベーションは、実は情報を取りに行くというパッシブ志向のモチベーションよりも、自分にとってずいぶん魅力的で、大きな原動力になっていました(今でもなっています)。

そういうわけで

 2016年までに高度情報処理技術者試験に3連勝して勢いをつけ、継続的な自己学習も習慣化できたことだし、

  • ここらで一度本気になって、英語、ぶっ潰しますか

 と、昨年の初頭から取り組みを始めた、という次第でした。

スタート地点

 そもそも最初はどうだったのか、という話です。

最初のスコア

 表題の通り、265点上げて800点なわけですから、最初の結果は当然こうだったわけです。

f:id:dimeiza:20180405201727p:plain

 600点行かないにしても、そこそこできてた方じゃん、という方もいらっしゃるかもしれません。Qiitaに掲載されていた記事の300点台よりはよほど恵まれていますね。

 この辺は、

仕事の中で参照技術仕様やら何やらで、英語の読解を求められることは多かった

 という点が多少効いてはいます。ただ、いきなり無勉強でTOEICを受けるわけはなく、年明けから多少勉強してこの数字だったりします。

これまでやってきた取り組み

 割と前からこれをやってきてはいました。

 一応最後まで走ったんですが、後半の方は惰性というか、あまりやる気がない状態で進めていて結構苦痛でした。

 あと、実はずーっと昔からこれをやってまして。

iknow.jp

 5,6年ぐらい前に友人が続けて取り組んでいるという話を聞いていて、Lifetimeプランを契約して、出勤前の時間帯とかにちまちまやっていたのですが…。

 しばらく続けていると面白い技術や技術書が出てきて、そっちに飛びついて英語の方は忘れてしまう、なんてことを何度も繰り返していました。この辺はエンジニア特有の落とし穴かではないかと思います。

 そういうわけで、世間標準からすれば英語に触れる機会は多めだったのですが、英語自体には強烈な苦手意識が伴っていました。通りの良い言葉で言うと『英語アレルギー』という奴です。

  • ググる→英語のページしか出ない→必死で日本語のページを探す→そこから読み始める

 とか、

  • 英語のページしかない→読み始める前にエキサイト先生にご登場願う 1

 みたいな行動パターンを紹介すると共感していただけるでしょうか(今までよくやってこれたな…)。

推移

 こんな感じでした。

受験日 Listening Reading Total
2017/3/12 265 270 535
2017/5/21 350 295 645
2017/6/25 380 285 665
2017/7/23 415 290 705
2017/10/22 370 340 710
2017/11/19 390 340 730
2017/12/10 355 315 670
2018/3/11 445 355 800

f:id:dimeiza:20180405204142p:plain

 まぐれ、って言った理由が分かったでしょ? 前回の試験が予想外に悪く、今回が予想外に良かった、というのが正直なところです。

 Listeningのスコアがガッと上がっているので、最後こんな値になっているんですが、紆余曲折ありながらもじわじわ上がっている格好になっています。

 『TOEICは受け続けているとスコアは上がっていくよね』と、英語堪能な知り合いには言われたのですが、このグラフやら上述の事項やらを見て言えることは、

勉強し続けても、必ずしも順調に上がっていくわけではない。 スコアは試験の内容やらコンディションに依存して上下にブレる。

 ということです。

 TOEICのスコアに一喜一憂してはならない、とよく言われますが、一歩推し進めて私は、

* 上がったら『ハードルを越えられた』と全力で喜び、落ちたらなかったことにしてスルー

 という風に、非対象に取り扱うように心がけていました。

 ちょっと先走ってしまいましたが、ここから先、(ある意味で勉強法より大事なメンタル面について)話をした後で、実際の戦術を書いていこうかと思っています。

 以下、次号。


  1. 岡部「英語か! エキサイト先生にご登場願え!」ダル「そんなめんどいことしてられねっつの! 訳すると…ハ~イ、ポールゥ!」 …改めてこのシーン見直したんですが、ダルが使った翻訳ソフト、2010年だというのにGoogle先生真っ青の翻訳精度ですよね…。

Developers Summit 2018【16-C-6】The Amazon Way~Amazonのソフトウェア開発~ 聴講メモ

講演資料

 資料公開予定なし。

概要

 外部から伺い知ることが少ない、Amazonのソフトウェア開発の姿について、特にAmazonのバックボーンであるカルチャーを中心に紹介する。

スピーカー

 Amazonの西谷さん。

詳細

  • 今日は、ソフトウェア開発の手前のところ、カルチャーの話をしたい。

The culture of Innovation

  • イノベーション、インベンションがクリエイティビティを開放する、という言葉がAmazonにはある。

  • ミッション

    • 地球上で最もお客様を大切にすること
      • ここでお客様とは、ものを買う消費者だけではなく、販売者、企業、コンテンツクリエイターも含む。
    • 安心感をもたらす
      • お客様の生活を楽にする、というコミットメントに根ざしている。
    • 常にお客様を起点に行動する
      • ミッション、コミットメントのスタート地点として。
  • Customer Obsessionという考え方。

    • Obsessionという言葉の訳は難しいが、お客様への執心、執着というニュアンス。
  • 顧客重視と長期的視点

    • 創業時から一貫して変わっていない。
    • 1997年の株主向けレターにおいて既に明言されている。
      • お客様への徹底的なフォーカス。
      • 長期的視点での投資を継続。
    • 売上は成長し続けているが、純利益自体はフラットに推移している。
      • 得た利益を次の投資として回し続けているということ。

イノベーションの例

  • こうした投資の結果、いろんな領域でイノベーションを起こし続けている。

    • Amazon Dash Button

      • 汎用的なボタンだけではなく機器に組み込まれたボタンなどもある。
    • Amazon倉庫内の流通システム。

      • 商品を搭載した、たくさんの棚が自律的に可動している。
      • 各棚の軌道計算、衝突回避はAWSで行っている。
    • 配送システムも刷新し続けている。

      • ドローンによる配達の実証実験とか。
    • 最近だとAmazon go。

      • シアトルにある実店舗。
      • レジで会計せずに品物を買える。
    • ただ、国ごとに差があって全てのイノベーションを同時に実現することは難しい。

創業時のコンセプト

  • 紙ナプキンのスケッチ。以下の要素が配置された図。

    • Selection(品揃え)
    • Customer Experience(顧客満足)
    • Traffic(トラフィック)
    • Sellers(売り手)
    • Lower Cost Structure(低コスト構造)
    • Lower Price(低価格)
  • 以下の循環の中で成長する。

    1. Selection(品揃え)の実現でCustomer Experience(顧客満足)が向上する。
    2. Customer Experienceが向上するとTraffic(トラフィック)が増える。
    3. Trafficが増えるとSellers(売り手)が増える
    4. Sellerが増えるとSelectionが増える
  • また、以下の構造も含まれている。

    1. Lower Cost Structure(低コストのオペレーションの実現)がLower Price(低価格化)をもたらし、
    2. Lower PriceがCustomer Experienceにつながる
  • AmazonAWSの社員も普段から親しんでいて、AWSも同様の考え方になっている。

イノベーションのための組織づくり

メカニズム

  • PRFAQ(PR+FAQ)

    • 新しいプロダクトの開発時にプレスリリースから書き始める。
      • 主題、副題、サマリ、課題、解決、引用など。
    • 製品の具体的なアイデアとデータを提供する。
    • FAQも事前に準備する。  
    • こうしたプレスリリースを書くための研修が社内にある。
    • もちろん初版をそのまま使うことはない。

      • 書いて、見てもらって、リバイスして、プロダクトにつなげる。
    • どういったものを作って誰に売るかというDecisionの後押しをすることが目的。

      • 誰に何を売るかわかりやすくする効果がある。
  • プレゼン文化はない。

    • アマゾンにはプレゼンを使った会議はほとんどない。
      • プレゼン形式だとプレゼンターの喋りが上手ければ、内容も良く聞こえてしまう。
    • Amazonで複数名で検討を行う際には、6pagerと呼ばれるレポートを使う。
      • ファクトベースの数ページのレポートを先に配布し、
      • 数分間読んでもらい、
      • その後ディスカッションする。

アーキテクチャ

  • いわゆるマイクロサービスとセルフサービスプラットフォーム。

    • セルフサービスプラットフォームがAWSの元になった。
  • 2001年頃、Amazonが大きくなる中で、アプリのモノシリック構造が問題になった。

    • 大量のディベロッパーが1個のアプリを構築し、1本のラインでデプロイするプロセス。

      • ちょっとした修正も重厚長大なパイプラインを通さないといけない。
      • アプリ一つ(機能一つ)デプロイするのに全体更新が必要だった。
    • 解決策としてはいわゆるマイクロサービス。

      • そしてDevOps。
      • この辺りは組織とも切り離せない。

組織

2 Pizza Team
  • Amazonのチームは2 Pizza team。

    • ピザ2枚でまかなえる人数がちょうどいい、という発想。
    • アイディアを早く形にしてフィードバックにすばやく対応するには、大規模な組織ではなく少数精鋭でやったほうが効率的。
    • AWS含め様々なプロジェクトで適用されている。
  • こうして作られた2 Pizza teamは、作るものに対するすべてのオーナーシップを負う。

    • プロダクトの計画策定 ロードマップ
    • 開発
    • 運用、カスタマーサポート
  • "You build it, You run it."

    • AWSのCTO(Werner Vogels)が言った。
    • 『Devが作ったものをOpsに投げつけて忘れてしまう』のはやめようという話。
    • なので、DevとOpsを隔てる壁がAmazonにはない。
    • 自分で作ったものは自分たちで動かし、面倒を見る。
      • 小さなチームで独立して全てを見る。
  • という観点で見ていくと、こんな問答になる。

    • QAは誰がやる?
      • 2 Pizza team。
    • オンコール対応は?
      • 2 Pizza team。
        • 順番に持ち合って24時間対応もするし、障害対応もする。
    • Opsは何をするのか?
      • Ops単体、という存在はいない。
チームの動き方
  • 全ての機能はサービスチームに存在するが、自身の役割に集中している。

    • 開発、ディレクション、支援など、個々がそれぞれの担当業務を専任している。
    • (自分たちでお守りをすることになるので)夜遅く起きないようにするために必死に作る。
  • 開発方法についてもチームに権限が与えられている。

    • 会社として統一した手法を指定するのではなく、各チームでアジャイル、ウォータフォールを選んで良い。
    • 採用も各チームでやっている。
    • 言語、開発ツールも自由。
    • ただ、そうは言っても効率化のために、共通で使えるリソースをまとめて用意したりもしている。
  • こうした動きを実現するためには、チームとして高い水準を維持する必要がある。

    • オンボーディングと呼んでいるトレーニング。
    • 定義されたパターン、プラクティス。
    • レビュー。
    • 内部的な技術共有。
    • Our Leadership Priniciple
      • これについては後程述べる。
    • といった原則を徹底的にやっている。
  • パイプラインについては、上述のカルチャー(独立かつ自由選択的な多数のチーム)から、

    • セルフサービス。
    • テクノロジ非依存。
    • ベストプラクティス。
    • 単一目的のサービス群。
    • を提供するためのツール群を社内で共有している。
      • 利用するかも裁量だが、90%以上のチームが使っている。
  • こんな感じで、各チームが開発からデリバリまで並列に動くことになる。

    • 年間5000万回ぐらいのデプロイが行われている。
  • AWSは昨年1年間だけで1400ぐらいの機能、サービスをリリースしている。

    • ただ、これは対外的にアナウンスしたものだけ。細かいリリースはもっと多い。

カルチャー

  • 文化の根底にはOur Leadership Principleがある

    • 14個の行動規範。
    • Amazonでは、マネージャであるかどうかに関係なく、全員がリーダとして動くことを求められる。
  • Web上で公開されている。

    • ちなみに中身は何年かに一回変わったりする。
      • ただし、一番最初の原則と最後の原則は不変。
  • 人事評価にも組み込まれている。

  • 以前からもこのOur Leadership Principleは知っていたが、入社して驚いたのは、普段の会話でこのキーワードが出てくること。

    • コミュニケーションにおける共通言語として使われている。
    • 社外の人が言われても、何のことか分からないが、社内だとニュアンスが伝わる。
  • Amazonの社員を捕まえて『どのOLPが好きか?』と聞くと、それぞれ異なる答えを返してくれるだろう。

Our Leadership Principle
  1. Customer Obsession

    • 全てはお客様から、という発想。
    • Empty chairという慣習がある。
      • 会議を行うとき、あえて椅子の一つを空けておき、そこにお客様が座っているかのように意識して会議を行う。
  2. OwnerShip

    • 長期的な視野に経って役割分担をすること。
    • テストで重要なこととして、すべてを自動化しようとしている。
    • 運用も全て自動化しようとしている
    • 自動化が非常に重要、という考え方が根付いていて、実現している。
    • テストをしやすいようにアーキテクト、デザインし、
    • テストや運用を自動化するためのアプリのアーキテクチャを考えている。
  3. Dive Deep

  4. Learn and be curious

    • 深堀していく。
    • Rootcause analysys
    • 5Whys
      • いわゆる『なぜなぜ』と同じようなことをやっている。
    • Brownbag sessions
      • 社内勉強会。ランチボックスを持って集まって取り組みをシェアしたりしている。
  5. Frugality

    • お客様にとって重要でないことにお金を使わない
    • Door Desk
      • 社員の机はドア用の板に木の足をつけた簡素なものを使っている。
      • 創業時の気持ちを忘れないようにするため。
    • この影響で、目黒のオフィスではドアが天井に並んでいたりする。
  6. Think big

    • お客様に貢献するために大きな視点を持つ。
    • 常識にとらわれない。
  7. Bias for action

    • スピード重視。
    • 取り組みにはやり直しがきくことも多い
      • プロトタイピングとフィードバック。
  8. Hire and develop the best

    • 採用時に高いバーを維持する
      • 各チームが採用活動をしていると話したが、人が足りないから採用する関係上、本来求めるべきレベルを下回っていても採りたくなる心理がある。
      • そこで、そのチームに直接関係ない人が採用に入ってバーを上げるという取り組みをしている。
    • カルチャーにフィットするかを非常に重視する。
      • カルチャーに合わない人だと、会社の成長を妨げてしまうので。
  9. Have backbone;Disagree and commit

    • 敬意をもって異議を唱える。
      • 偉い人に対する反論があっても空気を読んで言わない、とかいうのはやめよう、という話。
    • ただし、決定には全面的にコミットする。
  10. Invent and simplify

    • イノベーションとインベンションを求めてシンプルに。
      • コード、プロセス等全てにおいて。
  11. Are right, A lot

  12. Earn Trust.

    • 話をよく聞く。
  13. Insist on the Hightest Standard

    • 常に高い水準。
    • 同じ失敗、問題を繰り返さない。
    • コードレビューを非常に重視している。
  14. Deliver Results

    • 決して諦めない。
重視している点
  • こういうことを求めていくと『寝ずに働く』しかない。

    • のではなく、重要なことにフォーカスするようにしている。
  • イテレーションを重視している。

    • 必ずしも開発に限らない。
    • 溜め込みすぎずに、小さくしてなるだけ繰り返す。
    • 貯め込むと頻度も下がってしまうのでよろしくない。
  • MVP(Minimum Viable Product)

    • としてモノを作っている。
    • 最小限の仕様でモノを作って、お客様のフィードバックをもとにプロダクトを成長させていく。
    • マーケットに届ける時間と機能セットのどちらを優先するかは悩ましいが、トレードオフして必要最小限の仕様で届けていく。
    • いろいろ考えて、でかいモノを作っても、お客様にマッチしなかったら嬉しいものにはならない。

さいごに

  • Every day is still Day Oneという言葉がある。
    • 常に毎日が最初の一日である。
    • 現状に満足せずに新しい挑戦をし続けよう。

GB-BKi7HT2-7500を買ってみた

きっかけ

 最近、Intelが出しているNUCという製品を知って、小型ベアボーンに物欲を刺激されまして。

 よさそうなのを見つけたのですが、日本のAmazonはじめ、Webで売っているところを見かけなかったので、amazon.comで購入してみることにしました。

 現時点で情報があまりないように思ったので、軽くレビューでもしてみようかなと。

ターゲット

 これです。

https://www.gigabyte.com/Mini-PcBarebone/GB-BKi7HT2-7500-rev-10#ov

 選定で意識したのはこの辺。

  • 接続ポート、コネクタ種別
    • USB-TypeC,USB 3.0がそれぞれ2つ
    • HDMI,mini DisplayPortの複数画面出力
    • ThunderBolt 3
  • 2.5インチSATA HDD接続可否
    • 家にSSDが一つ余っているので流用したかった
    • M.2 SSD(システム用)とSATA HDD(データ用)という手も使える
  • 大きさも程よい
    • IntelのNUCは結構大きく見えた

 ほんの少しだけゲームもやっているので、グラフィックをどうフォローしようかとも思ったのですが、最近はSteamホームストリーミングとか、ESXiによる仮想マシンサーバからのパススルーとか、いろいろ手があります。

 ここは仮想化やリモート化の勉強も兼ねて、遠隔でやってみようかと思っていました。

注文

 amazon.comで注文しました。

https://www.amazon.com/gp/product/B071KJF4BX/

 本体+AmazonGlobal Priority Shipping+Import Fees Depositで、大体¥65Kぐらいでした。

 9/9にオーダー、9/11に出荷、9/15に受領、という流れでした。

 はじめてAmazon.comを使ったのですが、Amazon Global様々ですね。これで日本市場未流通の製品も比較的楽に手に入れられそうです。

開封の儀

 こんな感じの箱に入ってきました。

上面

f:id:dimeiza:20170919200456j:plain

底面

f:id:dimeiza:20170919200449j:plain

前面

f:id:dimeiza:20170919200452j:plain

後面

f:id:dimeiza:20170919200441j:plain

本体

上面

 電源スイッチは上面についています。

f:id:dimeiza:20170919200504j:plain

前面

f:id:dimeiza:20170919215507j:plain

左側面

f:id:dimeiza:20170919200520j:plain

背面

  • HDMI
  • MiniDisplayPort
  • ThunderBolt 3
  • USB 2.0(ここだけ残念、3.0だとベストだった)
  • Ethernet

 という構成です。

f:id:dimeiza:20170919200533j:plain

右側面

 MicroSDリーダがあります。これまで外付けのを使っていましたが、もういらないかな…。

f:id:dimeiza:20170919200517j:plain

底面

 各脚にねじがついていて、このねじを外して内部にアクセスします。

f:id:dimeiza:20170919200529j:plain

付属品

 1点、アダプタの電源プラグの形状が三叉プラグになっています。この点だけ注意ですね。

 私の環境では二つ又プラグだったので、たまたま持っていた旅行用の変換コネクタをかませて動かしました。

f:id:dimeiza:20170919200523j:plain

内部

 ねじを開けるとこんな感じです。

 ふた部分にSATA SSDをマウントしてケーブル接続し、SO-DIMMのDDR4 RAMをセットすれば使えるようになります。

 M.2スロットは2つあって、一つはSSD接続用、もう一つはWifi/BlueToothボードで占有されています(これ、外して別のボード刺したりできるのかしら…)。

f:id:dimeiza:20170919200525j:plain

動作

 BIOSは従来型でした。

f:id:dimeiza:20170919200532j:plain

f:id:dimeiza:20170919200513p:plain

 この構成でFF14ベンチを動かしてみましたが、720Pでこの程度の能力です。

 HD Graphics 620ですから、まぁそんな大したことはありません。

f:id:dimeiza:20170919200551p:plain

 で、このベンチを取った時の音を記録してみました。


GB-BKi7HT2-7500 fan noise

 なんか動画で見るとあまり騒々しくないように聞こえますね。実際は机の上に置いておくと、もう少し騒がしい印象でした。

 どうやらTurbo modeをEnableにしているとファンが回りやすいようなので、私はBIOSからTurbo modeをoffにして動かしています。

Voice wakeup

 という機能がついている、と製品ホームページにこっそり書いてあって。

f:id:dimeiza:20170919200459p:plain

 説明書いわく、

Voice Wake Up Feature: Allows the Device to Wake Up from Sleep/Shutdown Mode,

 とあって、スリープやシャットダウンモードから発声で起動させられる、と。

 ドライバインストール後、タスクトレイからRealtec HDオーディオマネージャを開くと、Voice wakeupの設定を行うことができます。

 "Hello Gigabyte"でも動かせるみたいですが(未確認)、"私のキーワードを聞く"で学習をさせようとすると、"お気に入りのキーワード"を6回録音して覚えてくれるらしいので、有名なあのフレーズを使って動かしてみました 1


GB-BKI7HT2-7500 Voice Wake up Feature

 まだ数回しか使っていませんが、現状認識率がちょっと微妙。録音の仕方に依存するのかもしれません。いろいろ試してみたいところです。

 ちなみにマイクは本体に内蔵されているので、マイクを追加することなくこの機能を使うことができます 2 。ボイスアシスタントとの親和性が高い作りです。

感想

 まだ使い始めたばかりなので、評価は固まってはいませんが、

良かった点

  • ライトユーザの作業(Webブラウジング、音楽、動画視聴)程度は余裕でこなす
    • Turboを切ってこの範囲で動かしている限り、音も静か。
  • 2.5インチベイ搭載モデルなのに小さくていいね。
  • フロントUSBポートでスマホ系の充電回りも賄えるので、充電コンセントであふれなくていい。

苦手な点

  • 3Dゲームはそんなに得意ではなく、ノーパソ程度。単体でゲームさせるなら他所をあたったほうがいいかも。
  • Core i7とはいえ2コアなので、開発用途にも力不足かも。

 って感じですかね。

 ほかに気づいた点があれば加筆するかもしれません。


  1. ずーっとAndroidユーザなので、本物を使ったことは一度もないです。

  2. それと気づかずマイクを注文してしまったのは内緒。

Developers Summit 2017 Summer【A-7】こっそり教える有名コミュニティの裏話 ~Tensorflow、Java、PyData~ 聴講メモ

講演資料

 資料公開予定なし。

概要

 エンジニアコミュニティの現状、課題、裏話等について、老舗や新鋭コミュニティの中の人(運営側の人)がパネルディスカッションする。

スピーカー

  • ウルシステムズの漆原さん(司会)
  • ブレインパッドの下田さん(パネリスト)
    • TFUG運営。Google Developer Expert。
  • Microsoftの寺田さん(パネリスト)
  • Slideshipの池内さん(パネリスト)
    • PyData.Tokyo運営。

詳細

各コミュニティについて

TFUG(Tensor Flow User Group)

  • 2016/11立ち上げ。
  • 約2800名のユーザ。

JJUG(Japan Java User Group)

  • 2007/4設立。
  • 一時期(2012年頃)は登録者数が少なかったが、現在は6000名ぐらい。
    • ちょうどOracleがSunを買収完了した時期。政治的な理由に加えて、他の言語の盛り上がりもあった。

PyData.Tokyo

  • PyDataは、Pythonをデータ分析(画像解析、自然言語処理、強化学習)に使うこと。
  • 登録者2500名弱。

設立、参加のきっかけ

下田氏

  • 昨今の人工知能ブームで、開発案件が来た。
  • Googleに見つかって声をかけられた。
    • ブレインパッドがGCPをやっていたというビジネス上の関係があった。

寺田氏

  • JJUGは丸山氏によって立ち上げられた。
    • 日本にコミュニティがないということから。
  • 6年前に幹事に。
    • 所属していた企業で、コミュニティの幹事になってはならないというルールがあって、事務局長になっていた。
  • なぜJava Championになったのか?
    • 海外の友人が多い。
    • JavaOneに行ったら日本人と交わらないようにしている。時間があったら外部の人と会っている。
    • 自分の活動を知ってくれている海外の人が多かったことが要因では。

池内氏

  • 前の会社にいたときにPyData面白いよ、と登壇時に話をし、PyDataの人集めたら面白いと思うよ、と言ったのが発端。
  • ニーズとして多そうだ、多かった、という実情もあった。
  • 情報格差(海外と比して2年ぐらい遅れている)をなんとか縮めたいと考えた。

漆原氏

  • 皆、情報を発信している中で見出されたという印象がある。

コミュニティ活動の醍醐味

寺田氏

  • 多くの人と出会える。
    • 地方のイベントに行くほうが交流が深くなる。
  • 良い人に会える。
    • パッションを持っている人はすぐに分かる。

池内氏

  • いろんな価値観に触れられた。
  • 運営を通してグローバルな発想に触れられる。

下田氏

  • 自分が行きたいコミュニティを作りたいと思っていた(そして作れた)。
    • データサイエンティストのコミュニティは技術者が少なかった。
    • アカデミック寄り過ぎても、ビジネス寄り過ぎてもダメ。
      • 価値を届けられるようなコミュニティにしたい。
  • 参加者は、企画、エンジニア、アカデミックとさまざま。
    • エンジニアもモバイル系、組み込み系など多種多様。

苦労していること

池内氏

  • 識者に話をしてもらうのだが、誰に話をしてもらうか。
    • 内容的にもディープな話をしてもらいたいが、難しすぎると誰もついてこれない。
    • 講演者はイベント来場者の伝手や、スライド・ブログ等から。会社経由ということもある。

下田氏

  • 内輪になりすぎず、それでいて行きたいと思う環境の塩梅が難しい。
  • 最初は入門者しかいないのだが、時間が経ってくると入門者と専門家等、層が広がってくる。
    • すべての参加者の需要を満たせないので、分科会を作る等の工夫をしている。
    • 提供しつつ自分も楽しむ、ということの両立に苦しむ。

寺田氏

  • 300人ぐらいだった頃はもっと大きくしたいと思っていた。
  • 大規模化した後は、それまでやってきたやり方では回らなくなる。

参加できない人やクレームへの対応

池内氏

  • connpassの抽選機能で行っている。
  • ヘイトコントロールが難しい。
  • 当日キャンセルとの戦い。
    • ドタキャンは仕方ない。皆忙しいし都合がある。
    • が、サイレント不参加は問題。本当に行きたい人が来れなくなる。

下田氏

  • スルー力が大事。運営は透明にやっているので。
  • (登壇枠は別なので)どうしても参加したければ登壇してください、と言っている。

寺田氏

  • 事務方は10名ぐらいいて、毎月幹事会を開いている。クレームに対してもKPTをやって対応。

イベント費用の工面

池内氏

  • 会場を借りつつスポンサーセッションを作っている。

下田氏

  • GoogleのDevelopers Committeeから支援を受けている。

寺田氏

  • 大規模化すると会場のキャパが問題になってくる。お金がかかる。
  • ボランティアでやっているのでお金を儲けることはできない。
  • JJUGのTシャツを作ったら、売ってくれと言われたが、売ったら商売になっちゃうので難しい。

コミュニティ活動で失ったもの

寺田氏

  • イベントは週末になりがちなので、家族との時間。

池内氏

  • コミュニティの色がつきすぎた。
    • 他にも言語を使っているが、PyDataの人という見方をされてしまう。

下田氏

  • TensorFlowの人、Googleの人という雰囲気が出てしまっている。
    • 意図せずしてGoogle陣営と見られがち。

コミュニティへの参加と会社の理解

寺田氏

  • コミュニティに参加すること自体は上司とか関係ない。
    • 自分自身を高めるために、アンテナを広げるために行くものではないか。
  • また、昨今はSNS等、外のつながりが転職にすごく有利になっているという側面がある。
    • よって、旧来の会社は、エンジニアをコミュニティに出したくないと考えるかもしれない。

池内氏

  • 自分は(トップなので)自由に動ける。
    • その上で(勤め人に対して言うならば)自由に動けばいい。
  • コミュニティ参加の効果を説明する際、前の会社ではコミュニティ経由で仕事に繋がった経緯があったので、数値ベースで話をしたことがあった。
    • このコミュニティとつながることで○○万円の仕事が得られたんだよ、的な。

下田氏

  • コンサルに近いような会社なので、間接的な効果を理解してもらうのが難しい。
  • 半分は仕事とは関係ないが、半分は無理やり仕事とつなげるようにしている。
  • 戦略的に動かないといけない。

健全なコミュニティ運営

池内氏

  • 自分は、コミュニティがムラ社会化した瞬間に興味がなくなる。
  • いかにムラ社会化を防ぐか。
  • フラット組織がいいと皆は言うが、実際はリーダを決めたほうがいい。

下田氏

  • 幹事を一人でやっているので、意見が割れることはない。

寺田氏

  • 幹事は20名ぐらい。毎回出てくるのは10名。
    • 幹事自体の入れ替えをやっている。長らくアクティブでない人は卒業してもらったりとか。
    • 女性を幹事に入れることで、託児所やコーヒースペースを設けるなど、視点の多様化が図られている。
    • 参加者自身も変化している。
      • これは幹事自身が若返りをしているからと考えている。
    • 新たに幹事を任命する際は、幹事メンバーの過半数承認が必要。
      • パッションを持っている人に(幹事にならないかと)声をかける。何よりも重要なのはパッション。
  • JJUGでは会長1名、副会長2,3名を置いて、その下に幹事。

コミュニティへの貢献方法

池内氏

  • 質問をする。
    • 興味深く聞いてくれたことを登壇者に伝えられるし、盛り上がった、という印象を与えられる。

下田氏

  • 会場で得られたことをブログやSNSで配信して欲しい。
  • 主催者側に大きなカンファレンスを主催するための後押しをしてほしい。

寺田氏

  • 会場のボランティア。
  • いいドキュメントを見つけたら、翻訳、共有する。
    • 今後、英語のドキュメントの邦訳はますます減っていくだろうから。
  • JavaのEarly Versionを試してバグを見つけたら報告とか、できることはたくさんある。

運営に向いている人

池内氏

  • ホスピタリティがある人が向いている。
    • 登壇者や参加者への配慮という観点で。

下田氏

  • 前には出ないが、作戦を立てて盛り上げていく軍師タイプの人。
  • 仕掛け人をやるのが面白いのでは。

運営側に回ることによるメリット

池内氏

  • (普段の仕事ではなかなか得られない)マネジメント視点、組織運営視点を得られる。

下田氏

  • 自分が行きたいコミュニティを作ることができる。

最後に一言

池内氏

  • サイレント不参加の風潮をなくしていきたい。
    • 抑止策を考えざるを得なくなってしまうので。

下田氏

  • 気軽に来てほしい。
    • (人数的に参加できない人がいるというツッコミに対して)パッションを持って運営側に来て欲しい。

寺田氏

  • ソフトウェア開発で世界との対等性を得ていくためには、コミュニティの力が不可欠と考えている。
    • 世界と日本の標準がかけ離れているという実情がある。
      • 海外では『Strutsなんて使うかよ』だが、国内だと『そうは言っても…』。
    • どのコミュニティでもいいので参加してアンテナを張り、情報を入手し、広めていってほしい。
    • 会社の先輩、後輩に声がけしていって欲しい。