Subscribed unsubscribe Subscribe Subscribe

ジャバ・ザ・ハットリの日記

日本→シンガポール→ベルリンへと家族と共に流れ着き、ベルリンのスタートアップで働くソフトウェアエンジニアの日記

書評『年収は「住むところ」で決まる 』はこれからの住まい選びに参考にするべき1冊

『年収は「住むところ」で決まる 』(著:エンリコ モレッティ)を読んだ。これは特に海外転職において「住むところ」選びをする際に、ぜひとも参考にすべき1冊だった。

年収は「住むところ」で決まる ─ 雇用とイノベーションの都市経済学

年収は「住むところ」で決まる ─ 雇用とイノベーションの都市経済学

タイトルにある「年収」について本書ではそこまで言及されていない。単にキャッチーなタイトルを付けただけで、本書の内容を端的に言い表しているのは副題の方。その副題が「雇用とイノベーションの都市経済学」。多くの資料とデータを使って都市経済の移り変わりを説明している。それらは「誰もが知っているけど、その理由がいまいちうまく説明できないこと」だ。

例えば「シリコンバレーはIT産業のメッカのひとつであり、数多くのIT企業がそこに集積していること」これは誰もが知っている事実ではあるが、なぜ特定の地域に同種の業態の会社や人材が集まっているのか、を論理的に説明するのは難しい。

IT産業といえば最もリモートワークに適して産業であり、ソフトウェアエンジニアにいたってはネットさえ繋がればどんな田舎でも働くことが可能だ。実際にそうした働き方を実践している人もいるが、都市単位で見た時にはそれとまったく逆のことが起きている。シリコンバレーやベルリンなどのIT都市に多くのITエンジニアたちが惹きつけられ、人がさらに人を呼びその集積化がより一層高まっている。
これと逆に今までアメリカ国内にあったが国外に流出しているのは工場など。誰もが知るようにiPhoneはDesigned by Apple in Californiaであって、それを作っている工場は中国だからMade in China だ。アメリカやシリコンバレーでは工場で働いていた人の雇用は失われ、その代わりにソフトウェアエンジニアリングやデザインなどの高度人材に対する需要がずっと高まっている。

興味深いのは工場などの生産部門は比較的容易に場所の移転が可能だがイノベーションに関わる部門はほぼ移転が不可能ということ。孤立した環境では革新的なアイデアの実装が不可能であり、そのためにはその企業だけでなく都市単位でのエコシステムが重要になってくる。

都市で働く人材は同じような人材とのつながりを持ち互いの所得を高めてしまう。つまりクリエティブな人達に囲まれていると、自分自身もよりクリエティブになり、生産性が上がる。ハーバード大学は同医学部の研究者たちが発表した医学論文をすべて洗い出し、共同執筆者たちの研究室の間の距離を調べたところ、それが1キロ未満だと、質の高い論文が書かれている傾向にあることが分かった。

またある都市でイノベーション産業の新たな雇用が1つ生まれると、それ以外の業種の雇用が5つ作り出されている。科学者やソフトウェアエンジニアの雇用が増えれば、タクシー運転手、家政婦、ベビーシッター、美容師、医師、弁護士、犬の散歩人、心理療法士など地域のサービス業に対するニーズが高まるからだ、と。

こうして発展する都市はどんどん加速度を高めて発展し、衰退する所はどんどん人材が流出して衰退してしまう。統計上アメリカの都市間の格差はずっと広がっており、格差が収まる気配は一切無い。

住む場所と職場を変えることがどれほど人生に影響するか、に関して私も身をもって実感している。日本→シンガポール→ベルリンへと家族と共に移住を繰り返し、周りの影響を受けて生活が激変し続けている。住む場所や住む国は惰性で決めてしまいがちだが、それはもろに生活に直撃する。

シンガポールから次の移住先を探す際に資料をよく読んで都市ごとの統計を比較した。その時は本書を読む前だったのでベルリンがIT都市として抜き出てきていることと、IT投資額がやけに高いな、と思っただけだった。
ただこうして本書を読んだ後、ITエンジニアとしてのキャリアを考えた際に住むところ選びはとてもとても重要だっだのだな、と思った。

人間は傲慢なので自分の給料が上がった時に「給料が上がった理由?そりゃあ俺様が仕事をがんばったからに決まってるだろ」と思いたい。しかし実際には都市単位で考えて「あなたのがんばりよりも都市の機能として、あんたの住んでいる都市全体の給料が上がる仕組みがあって、そこにたまたま乗ってただけなんですよ」となっている可能性が高い。

「広がってしまった都市と地方の経済格差を埋めなければならない」という、地域格差是正論がある。しかしなぜ地域格差是正しなければならないのか、という疑問に対して誰もが納得できる答えを持っている人は居ない。本書ではただ淡々と事実をもとにその格差の原因を突き止めている。地域格差は歴然とあってそれは今後さらに広がり続ける。

個人的には国境をまたいで様々な国への移住を繰り返すスタイルが好きだが、そんなことを誰かに強要しようなんて思う訳がないし、生まれ故郷を離れずにずっとそこで暮らし続ける人生を否定することもない。どこに住むかはその人次第だが、その「住むとこ」選びにとても参考になる1冊となった。

ということで自身としてはこれからも最先端のIT都市に住み続けたいなー、と思った次第。

年収は「住むところ」で決まる ─ 雇用とイノベーションの都市経済学

年収は「住むところ」で決まる ─ 雇用とイノベーションの都市経済学

格差の壁をぶっ壊す! (宝島社新書 311)

格差の壁をぶっ壊す! (宝島社新書 311)

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

Rails 5.1のwebpack (gem無し)を使ってReact, Redux, Material-UIの環境構築

RailsのViewをReactにする場合のお手軽な環境構築としては少し前ならreact-railsやreact_on_railsといったGemを使って統合していた。それもRail 5.1になってGem無しでもカンタンに環境構築が可能になった。もちろんGemを使えばそれらに付随する機能が使えて便利な面もあるが、「無しでもカンタンにできる」というのはありがたい。またRail標準としては「これからJavaScriptフォルダ配下のpackにReact関連コードを置きます」とかやられると、一応Rails標準というものを知っておいた方がよさそう。
ということでRails 5.1のwebpack (gem無し)を使ってReact, Redux, Material-UIの環境構築を書いた。

$ ruby -v
ruby 2.3.3
$ rails -v
Rails 5.1.1
$ npm -v
4.0.5

railsのバージョンが5.1であることを確認した後、rails newを--webpack=react指定で実行する。
実行後の出力結果を見るとwebpacktやらyarnがあることが分かる。

rails new myapp --webpack=react
 :
 :
Using rails 5.1.1
Using sass-rails 5.0.6
Bundle complete! 17 Gemfile dependencies, 71 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
       rails  webpacker:install
Copying webpack core config and loaders
      create  config/webpack
      create  config/webpack/configuration.js
 :
 :
$ brew upgrade yarn
success Saved 562 new dependencies.
├─ abbrev@1.1.0
├─ acorn-dynamic-import@2.0.2
├─ acorn@5.0.3
├─ ajv-keywords@1.5.1
 :
 :
yarn add v0.23.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...

フォルダ構成が以下のようになっている。これからはapp/javascript/packs配下に入れるのが標準とのこと。

app/javascript
└── packs
    ├── application.js
    └── hello_react.js

packsに入っているhello_react.jsはこのように単純なReact component。
単にHello Reactと出力しているだけ。早速これを使って動作を確認してみる。

import React from 'react'
import ReactDOM from 'react-dom'
class Hello extends React.Component {
  render() {
    return <div>Hello {this.props.name}!</div>
  }
}
document.addEventListener("DOMContentLoaded", e => {
  ReactDOM.render(<Hello name="React" />, document.body.appendChild(document.createElement('div')))
})

サンプルの動作を見るために以下のコマンドでpages controllerを作る。

bundle exec rails g controller pages index

pagesのindex.html.erbに javascript_pack_tag を追記する。

# app/views/pages/index.html.erb

<h1>Pages#index</h1>
<%= javascript_pack_tag 'hello_react' %>

javascript_pack_tag のロードを有効にするため webpack-dev-serverの設定をdevelopment.rbに記載。

# config/environments/development.rb

Rails.application.configure do
 :
 :
  config.x.webpacker[:dev_server_host] = "http://127.0.0.1:8080"
end

サンプルの動作を確認するためrails サーバーを立ち上げる。

bundle exec rails server

別のターミナルから以下のコマンドを実行しwebpack-dev-serverを立ち上げる。つまりrails sserverだけではサンプルを見ることができない。

./bin/webpack-dev-server --host 127.0.0.1
  :
  :
  [164] ./app/javascript/packs/application.js 515 bytes {1} [built]
  [266] multi (webpack)-dev-server/client?http://127.0.0.1:8080 ./app/javascript/packs/application.js 40 bytes {1} [built]
     + 70 hidden modules
webpack: Compiled successfully.

ここでローカルホストの以下のページにアクセスする。Hello Reactが見えたら無事に動いていることになる。
http://localhost:3000/pages/index

f:id:tango_ruby:20170515051616p:plain


この時点ではReactが入っているだけでRedux, Material-UIがまだ入っていない。
以下のコマンドで入れる。

npm install --save redux
npm install --save react-redux
npm install --save-dev redux-devtools
npm install --save material-ui
npm install --save react-tap-event-plugin

コマンド実行後にpackage.jsonを確認すると以下のようにインストールされていることが分かる。

{
  "name": "myapp",
  "private": true,
  "dependencies": {
    "autoprefixer": "^7.0.1",
    "babel-core": "^6.24.1",
    "babel-loader": "7.x",
    "babel-preset-env": "^1.4.0",
    "babel-preset-react": "^6.24.1",
    "coffee-loader": "^0.7.3",
    "coffee-script": "^1.12.5",
    "compression-webpack-plugin": "^0.4.0",
    "css-loader": "^0.28.1",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.11.1",
    "glob": "^7.1.1",
    "js-yaml": "^3.8.4",
    "material-ui": "^0.18.1",
    "node-sass": "^4.5.2",
    "path-complete-extname": "^0.1.0",
    "postcss-loader": "^2.0.5",
    "postcss-smart-import": "^0.7.0",
    "precss": "^1.4.0",
    "prop-types": "^15.5.10",
    "rails-erb-loader": "^5.0.0",
    "react": "^15.5.4",
    "react-dom": "^15.5.4",
    "react-redux": "^5.0.4",
    "react-tap-event-plugin": "^2.0.1",
    "redux": "^3.6.0",
    "sass-loader": "^6.0.5",
    "style-loader": "^0.17.0",
    "webpack": "^2.5.1",
    "webpack-manifest-plugin": "^1.1.0",
    "webpack-merge": "^4.1.0"
  },
  "devDependencies": {
    "redux-devtools": "^3.4.0",
    "webpack-dev-server": "^2.4.5"
  }
}

以降はReduxやらMaterial-UIを使ってコードを書く。そこは長くなりそうなので書くとしても別記事にする予定。

結果としてはこんな感じでよくあるMaterial-UI風のページができあがる。個人的にはBootstrapは飽きたのでMaterial-UIがいいと思っている。フォーム押したときの下線がヒューっと出る動作とかが気持ちいい。

f:id:tango_ruby:20170516005313p:plain

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

転職回数は多い方がいい。「転職は3回まで」なんて言ってくる奴は放っとけばいい

転職回数は多い方がいい。別に転職回数を獲得ポイントのように考えて、ポイント数をたくさん稼ぐほどいいと言っているのではない。転職に伴って得られるスキルが重要でそれは経験がないと手に入りにくい。しかしそのスキルが手に入ったら、まーまー仕事も住む場所も自分で選べるようになりますよ、という話。

ちょっと前なら「転職回数は3回まで。それ以上になると履歴書に傷が付く」って野球のストライク数みたいに転職を3回でカウントしていた。今でもそんな習慣が残っているのだろうか。

日本での社畜エンジニアに嫌気がさして、シンガポールのITスタートアップへ転職し、その後もシンガポールのIT界隈で4回ほど転職を繰り返し、5回目の転職でベルリンのITスタートアップに移った。日本に居た頃から数えれば3回なんてとっくに使い切っている。英語圏のITスタートアップという転職市場についてしか言えないが、転職回数の多さが不利に響いたことは1度も無い。むしろこうして転職を繰り返していなければ国境をまたいで職場と生活の場を移すスタイルは手に入らなかったことは断言できる。

こちらの記事にも書いたが私は日本からシンガポールのIT企業へ転職する際になかなか英語での転職活動がうまくいかずに苦労した。苦労の末に入った最初のシンガポールのIT企業はそれなりに給料もよくて同僚とも親しく仕事をしていたし、なんの不満も無かった。あのままひとつ目のIT企業で満足し、そこにずっと勤め続けることも可能だった。
でももしそうしていたらある日に「そろそろヨーロッパに住まいを移して向こうの会社に転職しようかな」と考えた際にかなりうろたえただろう。日本からシンガポールへの転職であれだけ苦労してまたヨーロッパへの転職で苦労しなればならんのか、と。ひょっとしたらヨーロッパ移住自体を断念していたかもしれない。

そんな風に移動できない人にはなりたくなかったのでどんなに気に入った職場でも重い腰を上げて、転職を繰り返すようにした。そうして転職を繰り返すうちにスーパーエンジニアではなくとも「英語圏ならどこの国に行っても仕事を取ってくることはできるかな」といった経験に伴う自信とスキルは身についた。
それらもあってヨーロッパへの転職は予想に反してすんなりといった。エンジニアとしての技術レベルだけを見ればそんなに劇的な変化はない。変化したのは転職によって得られる「仕事を得るノウハウ」の方だ。具体的には会社の選び方からはじまって、英語の応募書類の送り方、英語での面談方法、入社後のこなし方、英語で同僚と仲良くなる方法などになる。

いろんな会社に出たり入ったりとやってると「会社を見る目」が肥えてくる。特にITスタートアップは玉石混交なのでクソなスタートアップに捕まったらロクなことが無い。「会社を見る目」は本やネット記事を読んだだけで身に付くのではない。本当に自分に合った会社を見つけることはすごく高度で難しいのに、それが軽んじられている気がしてならない。
新卒で1発目に入った会社で転職もせずに「ここが自分に合った素晴らしい会社である」なんてどんな価値基準で言ってんのかまったく不明だ。まず他と比べるだけの経験値が無いし、自分には経験値が無いという自覚もない。

今まで一度もラーメンを食ったことが無いヤツが生まれて初めてのラーメンを食って「このラーメン世界一だわ」って言ったら「え?」となるだろう。「このラーメンが世界一だ」と言うためには旨いラーメン以外にも不味いラーメンや多彩な味のラーメンをいろいろ食った後でなければ分からないはずだ。最初に食った時点で分かるのは「ラーメン」という概念ぐらいで、それがたくさんあるラーメンの中でどのぐらいの位置にあるのかは決して把握できない。ラーメンを例にしたがこれを仕事や職場、住む場所に当てはめて考えて欲しい。

人生の貴重な時間を使ってやる仕事に対して「これ違うかも」とか思いながら続けることなんてまったく非効率だ。住む場所や国についても同じで「ここはアタシに合ってないのかも」となったらスパッと辞めて次に行くべきだろう。それで「やっぱここも合わないな」となったらまたその次に行けばいい。クソまじめに仕事を神格化してしまって「イヤなんだけどがんばらないと」と歯を食いしばってイヤイヤ働くような人にいい物が作れるとは思えない。いい物って作ってる人が楽しんで、集中して、情熱を持って取り組んでこそできる物だ。

転職を繰り返したところでエンジニアとしての技術力が向上する訳ではない。ただそこで向上するのは仕事や国を「自分で選んで移るノウハウ」の方だ。エンジニアという人種は技術編重でこうしたスキルを軽視しがちだが、これは技術力を支えるもう片側の車輪みたいなもので、これらの両輪がしっかり動いていないとダメなのだ。

転職数が増えれば当然ながら就職面談の際に「なんで転職したの?」「その会社でどんなことしてたの?」と聞かれることになる。そこはそれぞれの会社でエンジニアとして何を得て、何をその会社にもたらしたのか、が自分の言葉で説明できればOk。ちょっとした転職面談の際に「Aという会社で**して***をもたらしましたわー」という話をするために何十年も勤め上がる必要は無い。エンジニアなら5ヶ月もあれば話のネタの1つや2つはできるし、それで十分だ。(このあたりを深刻にクソまじめに考えると話がややこしくなる。もっと軽く考えていいし、本当に考えなければならないのは他の分野になる。)

そしてこれらは誰もが知る素晴らしい企業にお勤めの日本のエリート様には少々苦手なようで、そこが個人的にはチャンスだと感じている。日本の大手自動車会社や大手銀行にお勤めでシンガポールに転勤で来られていた日本人を数人知っている。彼らが会社の命令ではなく自分の意思で転職したり、国を選んで移住したという話を聞いたことはない。エリートはこんな風によー分からんITスタートアップをまわって生き延びる戦略を持ち合わせていない。このチャンスは非エリートな場所で泥臭くても楽しく生きようとする人にこそあるのだ。

そしてそのノウハウは言語化が難しいし、経験によって蓄積したノウハウが全て他者にも応用できる訳でもない。ノウハウを得るにはご本人に経験いただく他はない。「ビビってないでやってまえー!」としか言いようがないのだ。
面白そうな会社や住みたい国を見つけたら気にせず突っ込んでいきましょう。多少失敗してもそのうちに経験値が積まれてどこでも生き延びれるようになりますから、という話でした。

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com