ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

日本→シンガポール→ベルリンへと流れ着いたソフトウェアエンジニアのブログ

海外移住を「カッコいい」なんて思ってたら勘違いかもしれませんよ、と言っておく

ある意味では海外移住なんてカッコ悪いことの連続でしかないな、という話。

以前は質問箱なるものを設置して海外移住をお考えの方から質問を受け付けたり、今でもメールなんかで同様の質問をよくいただく。ご質問者さんは海外移住を考えていて、そのこと自体はいい事だと思うのだが、たまに「?」と思う時がある。それは「海外移住=カッコいい」みたいな意識が見えた時だ。

私からすれば海外移住なんて根っからカッコ悪い事が好きな奴でもないと続かないと思っている。

初めて日本からシンガポールに渡り、日本人のまったくいない会社で英語だけ使って働き始めた時のこと。まだまだ全てが英語で運営される職場に慣れない私は人事担当のA嬢に呼ばれて、政府に提出する就労書類についての説明を受けていた。聞きなれない書類用語の英単語をがんばって聞きながら理解しようとしているのに、よく分からない言葉が何度か出てくるので会話を止めてこう聞いた。

「ちょっと待って。その『ラッフルズプレイス』ってなに?」

シンガポールをご存知ない方のために説明するとラッフルズプレイスとはシンガポールのシティエリアにある主要駅とその周辺の名前。東京で言えば「新宿」のような存在。

前述の私の素朴すぎる質問を受けた時のA嬢のキョトンとした表情が忘れられない。
いい年したオッサンが東京で働く際に真顔で「おい、君。その『新宿』というのはなんだね?」と聞いているところを想像して欲しい。

きっとA嬢は「こんな何も知らない奴に複雑なサーバーインフラやデータベース設計を任せて大丈夫かいな?」と思ったに違いない。

これが海外移住の現実だ。地元の小学生でも知っているようなことすら知らないオッサンが七転八倒しながら働き、生活を送ることになる。ラッフルズプレイスの例は何百とある私のカッコ悪い事例のひとつでしかない。

そんな私も5年も英語ばっかりの環境で暮せば慣れるし、英語もそれなりに達者になる。最初は失敗続きだった海外生活も違ってくる。
最初の頃とは異なり、オシャレな海外のITオフィスで多国籍なメンバー達とまーまー流暢な英語を使って仕事をしている姿はカッコよく映るのかもしれない。またITエンジニアの場合、英語がそれなりに使えるようになると情報量が格段に上がる。元々が英語が標準のITの世界で日本語で検索したり、情報を仕入れている時点でちょっと不利だったのが標準になっただけなのだが、本人にしてみればやはり情報量の差を感じずにはいられない。

さらにシンガポールというのはすごい都市でその地の利を活かしてあらゆる情報が集積されている。英語と中国語が標準であることから北米、ヨーロッパ、中国からの情報がいっきに集まる都市なのだ。
そんな都市でITエンジニアとして暮らしていると「オレはなんでも知っている気分」になってしまう。

実はそういう自分が気に入らなかった、というのがシンガポールからヨーロッパに移住した理由でもある。

だいたい現代の世の中では「オレはなんでも知っている」なんて思ってる奴が一番危ない。

ブラックスワンで有名なナシーム・タレブ氏の書籍にもあるように、情報革命で変化のスピードが未だかつてないほどに速くなった際に全ての出来事は「予想外の出来事」となった。政治情勢の変化も、天災も、金融危機も、創業数年でしかない会社が世界を変える影響力を持つのも、全て予想通りに予想外の出来事だ。そこで生き抜く方法は常に変化に備え、変化し続けること。

シンガポール勤務初日にA嬢に「こいつ大丈夫か?」という目線で見られている私はかっこ悪いが、そんな状況下で心に抱く「ちきしょー!」という反骨精神が変化への適応をドライブさせる。私はどんなに人からカッコ悪く見えたとしても、あの状況が妙に好きなのかもしれない。

つい先日はドイツの住所登録で役所の職員の人とかなりモメた。解決した今だから分かるが、ドイツ生まれのドイツ人だったら絶対にモメない内容だった。カッコ悪いことこの上ないが、これこそが私が求めていたことだ。慣れてなくて不器用にしかできないが、なにか新しいことに挑戦しているというドキドキ感がある。

そんな状況を切り抜けたからこそ「オレだったらアジアでもヨーロッパでもそれなりに暮らせるかな」といった根拠の無い自信が付いたのだと思う。

おそらく数年後、誰の目からも「カッコ悪いなアイツ」と思われないぐらいにヨーロッパ生活に順応したら、私はまた次の場所へ移住するような気がする。カッコ悪さとセットになった新しいことへの挑戦が好きなのだ。きっとこれは自ら選んで海外に出た人に共通してある感覚ではないだろうか。

という訳で海外移住を「カッコいい」と思ってたら大いなる勘違いかもしれませんよ、と。

タレブ氏の本はこれ。

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方


tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

ReactをGoogle Cloud Platformにデプロイする

静的なReactをGoogle Cloud Platformにデプロイする方法。

いろいろググって出てきた方法で試したのに、これという解説が見つからなかった。Reactのデプロイに関してはGoogleの公式ドキュメントもStack Overflowのポストも全部イマイチという印象。

決してGoogle Cloud PlatformにReactが適さない訳ではない。GCPは無料でいろいろできるし、Reactとも相性がいいはず。なんでこの系統のドキュメントが充実していないのか、いまだに謎。
なのでここに書いた。

create-react-appを入れてサンプルのReactコードを作る。

$ npm install -g create-react-app

以下のコマンドでサンプルプロジェクトがスグにできあがる。

$ create-react-app my_test_app
  :
  :
 We suggest that you begin by typing:

   cd my_test_app
   yarn start

 Happy hacking!

$ cd my_test_app

$ npm start

npm startをした時点でhttp://localhost:3000/にアクセスすると以下のReactサンプル画面が見える。
f:id:tango_ruby:20171009052737p:plain:w300

buildをしてbuildフォルダを作る。

$ npm run build

GCPにログイン。Google Cloud Strageで新規バケットを作成する。Create Bucketボタンを押す。
f:id:tango_ruby:20171009053153p:plain

お好きな名前を付ける。
f:id:tango_ruby:20171009053352p:plain

上部のUpload Folderボタンを押して、先ほど作成したbuildフォルダを選択し、アップロードする。
f:id:tango_ruby:20171009053459p:plain


以下のapp.yamlを作成する。

runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /
  static_files: build/index.html
  upload: build/index.html
- url: /
  static_dir: build

作ったapp.yamlファイルをバケットにアップロードする。結果として以下の状態になる。
f:id:tango_ruby:20171009053800p:plain

上部のActive Google Cloud Shellボタンを押すと、シェル・コマンドの入力画面がChromeの下に出てくる。
f:id:tango_ruby:20171009053842p:plain

以下のコマンドをGoogle Cloud Shellで実行し、フォルダを作成、シンクロさせる。

 $ mkdir my-test-app123
 $ gsutil rsync -r gs://my-test-app123 ./my-test-app123

全てが正常に行われていると作成したフォルダ内にapp.yamlとbuildが転送される。

$ cd my-test-app123/
$ ls
app.yaml  build

Google Cloud Shellのプロジェクトフォルダ内で以下のコマンドを実行してデプロイする。

$ gcloud app deploy

 [1] europe-west2  (supports standard and flexible)
 [2] us-east1      (supports standard and flexible)
 [3] us-east4      (supports standard and flexible)
 [4] asia-northeast1 (supports standard and flexible)
 [5] australia-southeast1 (supports standard and flexible)
 [6] southamerica-east1 (supports standard and flexible)
 [7] us-central    (supports standard and flexible)
 [8] europe-west3  (supports standard and flexible)
 [9] europe-west   (supports standard and flexible)
 [10] cancel

Please enter your numeric choice:  7

target url:      [https://my-test-app-182318.appspot.com]
 :
 :
Deployed service [default] to [https://my-test-app-182318.appspot.com]
You can stream logs from the command line by running:

最後に出てきたhttps://<アプリの名前>.appspot.comにアクセスするとデプロイした内容が見える。

もっといい方法をご存知でしたらコメントください。

プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで

プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

「多様な意見」はなぜ正しいのか(著:スコット・ペイジ)書評と英語圏の労働環境に関する考察

「英語圏のエンジニア達は日本人のように長時間労働をしていない。彼らは日本のエンジニアの2倍かそれ以上の給料をもらっている。それでなんで会社が成り立ってるんだ!?」という疑問は英語圏で働き出してからずっとあったが、これという答えは見いだせずにいた。が、ついに本書によってその回答を得たようだ。

「多様な意見」はなぜ正しいのか 衆愚が集合知に変わるとき

「多様な意見」はなぜ正しいのか 衆愚が集合知に変わるとき

結論から言えばそのカギは多様性にある。

多様性という概念を本書では学者が書いた本らしく仮説を立て、その検証、測定方法、結果までが丁寧かつ論理的に記述されている。単なる感覚で「多様性って大事だと思うんだよねー」みたいな記述は一切無く、そこが本書の最大の価値となっている。

本書にもあった実験は実に興味深い。まず最初は最高のチーム作りの研究だった。とびきり優秀なトップ数パーセントの人達だけで作ったチームAと、その他大勢からテキトーに集めてきたチームBを構成する。両チームに同じプロジェクトを遂行してもらっていかにチームAが勝つかを測る実験だった。
しかし結果は何度も何度もチームBが勝ってしまうのだ。チームBの勝利データを無視する訳にはいかず、ずっと溜めていくとひとつの結論が出る。「ひとりひとりの能力は劣っていたとしても、それぞれのメンバーが持つ多様性がチームを勝利に導くになにかをもたらしているのだ」と。

もちろんプロジェクトの内容によっても違いが出るし、「多様性は能力に勝る」が常に起きるとは限らない。心臓手術をしてもらう際に、最高の心臓外科医を集めたチームAとパン屋、セールスマン、レースクイーンという多様性あるチームBとどちらに手術して欲しいか、となったらAであることは明らかだ。

本書ではどの様なケースが最も多様性が活かせるか、また活かせないのか、について細かく言及されている。

今の勤め先であるベルリンのITスタートアップのエンジニアチームは全員で6人。それぞれイタリア人、ロシア人、ポーランド人、インド人、スペイン人、日本人(私)という構成だ。これは私の勤め先だけが特別なのではなく、ベルリンにあるほぼ全てのITスタートアップがこの様な多国籍状態だ。シンガポールでも同じ。それを好むと好まざるとに関わらず、国際都市においては多様性が空気や水のようにそこにある。

かつて日本で働いていた頃のエンジニアチームは全員が日本人でその同僚エンジニア達と今ベルリンのITスタートアップで働いている多国籍チームの同僚を比較して、そこまで個々の能力が違うようには思えない。しかしチーム単位で比較した際にその生産性は多国籍チームの方に軍配が上がる。

会社運営において英語圏と日本の労働環境を比較すると英語圏では日本の数倍の生産性が無ければ成り立たない。単純に言ってしまうと、英語圏のITエンジニアに2倍の給料を払って、そいつらが夕方6時に帰宅して半分の時間しか働かない場合、その生産性は日本の4倍以上を確保してもらう必要がある。で、それが現に達成されているようだ。英語圏であることからマーケットがグローバルになり、利幅が大きく取れるとかなんとでも言いようはあるが、それでも釈然としない感覚があった。個々のエンジニアの能力については4倍も違う訳ねーだろ、と。

その答えのひとつとして本書が解説する「多様性」がある。だいたいITスタートアップにおけるプロジェクト自体が多様性を大いに活かせる場だったのだ。英語圏のITスタートアップはその多様性あふれるチーム構成から高い生産性を叩き出しているのだった。

また私自身の人材価値としてもコード書いてシステムを設計する技術と同じかそれ以上にヨーロッパ人には無い視点で、東洋文化をルーツに持つ人間から意見することに価値があったようだ。日本では特別でもない普通の人材でも遠くへ移動してしまえば希少価値のある人材になり、それが価値を生み出せる。

本書を通して私が考えた結論は以下の3つ。(本の結論ではない)

  • できるだけ自分と異なる人を尊重することで価値が出せる
  • できるだけ遠くへ行くことで価値が出せる
  • できるだけ人と違ったことをすることで価値が出せる

この本は読んだ後「あーそうですか」だけでは終わらない。読後に「では私はこれからどうするべきか」を考えさせる本だ。上記の私の結論とはまた違った結論が他の方が読めば出てくる気がする。久々に読後もあれこれと思考を巡らせることができる本に出会った。

「多様な意見」はなぜ正しいのか 衆愚が集合知に変わるとき

「多様な意見」はなぜ正しいのか 衆愚が集合知に変わるとき

The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies

The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com