【サポーターズCoLab勉強会】エンジニアのためだけの英語入門に行ってきました

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門

https://supporterzcolab.com/event/533/

に行ってきたので、そのときのレポート

 

以下、講義を聴きながらのメモ

 

登壇者の方は、留学の経験があるが、

留学したからといって、すぐに英語ができるわけではない

それがきっかけになって勉強しようと思った。

 

その辺の本屋で、「2語で伝わる英会話!」とかいう本が多いが

そういう楽して学べる英語は本当の英語ではない。

 

この勉強会を通して、

みなさんが英語への一歩が踏み出せればよい。

エンジニアが英語できると何がよいか?

嬉しいことはすでに分かっている。

が、英語を勉強するのはとてもしんどい

なので、目標やモチベーションが大切。

嬉しいこと1: 入出力のスペック大幅アップ

入力

  • 最新のドキュメントが読めるようになる。
  • 疲れずに英語のドキュメントが読める。

出力

  • 例えば、技術ブログなどを英語で書くと、海外の人も見てくれる。
  •  OSS 活動がしやすくなる(PR  のコメントやコミットメッセージなど)

嬉しいこと2: 市場価値の高い人材になれる。

嬉しいこと3: もちろん、お給料が増える

いろいろなデータを見ていると、英語ができていると年収が上がる人が多い。

嬉しいこと4: 転職の際の選択肢が広がる

例えば、海外企業に勤めたいというのがまず浮かばない。

それは、英語ができないから。

それで選択肢が減っているのはとてももったいない。

嬉しいこと5:  かっこいい。

 

英語のジャンルを4象限に分けたとき

  • listening (リアルタイム・自分でコントロールできない)
  • speaking (リアルタイム・自分でコントロールできる)
  • writing (ノンリアルタイム・自分でコントロールできる)
  • reading (ノンリアルタイム・自分でコントロールできない)

どれが難しいか?

ノンリアルタイムの方が、翻訳ツールなど使えるので簡単

事前に準備できるspeaking, writingは、自分でコントロールできるので簡単

逆に準備できないのは、相手に依存しているので、むずかしい。

準備すれば誰だって英語でスピーチできる。

結論からいうと、

listening が一番難しい。

speaking ができれば、writing はそれを書くだけなので speaking のほうが難しい。

エンジニア向け、英語表現テンプレート

英語の人は、あいさつの始まりに「調子どう?」みたいなのをめちゃめちゃ言う。

ただ、how are you? はほとんど言わない。

what’s up の返答は i’m fineじゃだめ

最近なんかあった?とかそういうことを聞かれている。なので返答は難しい。

 

ずっとyesを使ってると、硬い人だと思われるので、いろんな表現を使えると良い。(yup など)

コミットメッセージとかは、日本語よりも英語のほうが簡単だったりもする。

主語とかいらないんで、動詞から始まっていい。

speaking 攻略

格好つけずに簡単に喋る

 

発音

日本人を知ってる海外の人は、日本人が英語の発音がひどいことは分かっているので

海外の人もそこは日本人に合わせて喋ってくれる。

逆に、自信なくして小さい声で喋ると、もっと伝わらないのでよくない。

 

喋りながら、発音が難しい単語は避けるようにする。

R と L の発音は本当に難しい。

が、R と L を入れ違えたときに存在しない単語だったら

相手が意味を汲み取ってくれるので、意外と大丈夫だったりもする。

Q & A

Q1.

英語をはじめたきっかけは?

A1.

学生の頃の先生が良かった。

 

Q2.

こういう勉強方で良かったというのはあるか?

A2.

実際に喋るのがよい。skypeとかで喋れるサービスもある。

DMM 英会話など。

 

Q3.

話をしていると、分からない単語があって、スペル自体も分からないから調べようがなさそうだがどうすればよいか?

A3.

スペルが分からなくても、それっぽい単語でぐぐったら、googleがもしかしてこの単語?とサジェストしてくれるので、それをつかっている。

 

Q4.

下手な英語を喋って相手を怒らせたときの対処方は?

A4.

そもそも怒らないと思う。そうとう変なこと言わなければ。

 

Q5.

日頃、ものを主語にしてしまうことがおおいが、人を主語にしたほうがよい?

A5.

いや、それでもよい。

 

Q6.

ゲームのチャットで英語を勉強するのはよいか?

A6.

何もしないよりは良いが、ゲーム特有のスラングとかもあるので、仕事で喋るほうがよい。

 

Q7.

どの程度英語ができたら市場価値として英語ができると言えるか?

A7.

どのくらいかはわからない。ただ、自分は英語できますと言える。

 

Q8.

実務として、エラーを検索するときは、どういう検索の仕方をしたほうがよいか?(効率の良いググり方は?)

A8.

普通に日本語で検索することもある。そのほうがわかりやすいので。

 

Q9.

英単語を覚えるためにどっかに保存している?

A9.

頭の中に保存している。話すときに何か見たりはできないので。

補足:

alcというサイトが良い。

辞書のようなサイトだが、辞書ではなくて、その単語を使った例文が表示される。

 

Q10.

日常で使うテンプレートとかある?

A10.

それが難しい。エンジニアに限定すると用途に特化して作れるが、日常会話は難しい。ので、テンプレートは持っていない。

 

Q11.

英語のpod cast など使っているか?

A11.

聞いていない。ただ、聞くとしたら自分の英語レベルにあったものを聞いたほうがいい。

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得に行ってきました

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得

https://supporterzcolab.com/event/410/

に行ってきたので、そのときのレポート

対象者

  • 現在新規事業の立ち上げに携わっている方
  • これから新規事業にたずさわるかもしれない方
  • (もしくはたずさわりたいと思っている方)
  • ライブラリを書くより、プロダクト開発が好きな方

話すこと

  • 作りすぎて失敗したことの事例紹介
  • つくりすぎないために
  • コアバリュー大事

登壇者の方が作ったサービス

pook

https://s.pook.life/lp/

ランサーズは、オンラインクラウドソーシングの会社だが

pookはオフラインでやることに特化したサービス

 → オフィスで肩を揉んでくれたり

 → 栄養士の方が手作りご飯を届けてくれたり

本題

エンジニアの新規事業への関わり方

そもそも新規事業って?

新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。

対して、起業というのは0から始めること。

どうやって関わって行くの?

求められること

サービスを作ることが求められる。

実際には、プログラムを書くというよりは、問題を解決すること。

失敗1:作りすぎた。

リリース時に作ったのは、

  • APIの数150本
  • ページは80

ガチガチの仕様をその通りに作ってリリースした。

多いと何が悪いか。

多いとリリースが遅くなる

 → 多すぎたということは、無駄なことを作ってしまった。

  → 使われないコードはただのゴミ。

本当にあった怖い話

 nヶ月書けて作った仕組みをすぐに消した。

 顧客が本当に求めていたものと違った。

どうすれば良かったか?

作らなければよかった

 → しかし作って見ないと分からないこともある。

  → 作る前にそもそも考えることがあるはず。

  • 同じような体験ができるサービスを作って模擬する。
  • ユーザーにもっとヒヤリングする
  • プロトタイプで実験してみる。

反省

  • 作らないで実験できないか考えてみる。
  • 試したい仮説をすぐに実装できないか考える

失敗2:技術選定

エンジニアあるある。

最近イケてる○○という技術を使おうぜ!

 → 既存に縛られないので、使いがち

結果

情報が少なくて死ぬ。

社内で知識が多い人の助けも受けられない。

サービスがあたるか当たらないかという問題の前に

サービスが作れるか作れないかという問題が発生する。

反省

  • 枯れた技術を使うべきだった
  • もっと協力しやすい技術を選定すべきだった。
  • できるかどうか分からないは早めに潰す。

失敗3:仕様が変わる。

どうしてそうなった?

  • 作るべきものがあやふやだった
  • 目的を達成するための機能がもりもり
  • 全部マスト

どうすればよかった?

コアバリューを定めて、やらないことを決める。

コアバリューとは?

ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。

これを選定することで、作らないものを決めることができる。

 → コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。

  → そうすることで、議論の着地点も見つかる。

反省

コアバリューを決めて、作らないを決める。


まとめ

新規事業開発に置けるエンジニアの心得

  • 一番大事なことは作らないこと
  • また、そのために、コアバリューを決める。
  • エンジニアとして問題を解決することにコミット

とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。


Q & A

Q1.

コアバリューを決めることでいらないものが見えてくるということだったが

APIの数など具体的にはどの程度減ったりするか?

A1.

Apiの数は80本になったりした。大体全部合わせて半分くらいになった。

Q2.

やっていくなかで一番コストがかかることは?

A2.

新規事業でいうと、人件費が一番コストになる。

技術でいうと、どこにコストがかかるか?

 → 作って捨てればいいので、キレイに作らないことを考えればよかった。

  → 無駄にキレイにつくることを考えてしまった。

   → 結果、使われないキレイな部分ができてしまった。

なので、キレイに作るっていうところにコストがかかる。

Q3.

新規事業をやる上で、予算をどのくらいに抑えろとかあったか?

A3.

最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。

最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。

新規事業は黒転するまでに時間がかかる。

 → なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。

Q4.

開発するに置いて、「これ使ったよ」みたいなツールとかあるか?

A4.

プロトタイプを作るツールでいうと、InVisionというツールを作っていた。

https://www.invisionapp.com/

InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。

逆にコンフルエンスを使ったのは失敗だったと思った。

コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール

別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。

それよりも、ガンガンアウトプットできるようなツールのほうが良かった。