まともなコードが書けるエンジニアならどこでも海外移住できるという単純な理由
ベルリンでもシンガポールでもITスタートアップのエンジニアチームで一緒に働いたチームメンバーの中に現地人はひとりも居なかった。そういう現状からITエンジニアならほぼどこでも移住できますよ、という理屈になる。
現地人とはその国で生まれ育った人のこと。例えば現在働いているベルリンのスタートアップのエンジニアチームにはイタリア人、インド人、ロシア人、ルーマニア人、ポーランド人、スペイン人、日本人（私）が居る。つまり地元ドイツのドイツ人は居ない。シンガポールに居た時もそう。エンジニアチームにシンガポール人はひとりも居なかった。他の会社も探しまくればどこかには居るだろうが、全体的に数が少ないのは確かな話。
その理由はコンピュータ・サイエンスの基礎知識があって、かつまともにコードが書ける人なんてそうそう居る訳ではないからだ。国内人材の方が現地の言葉はもちろん習慣なんかも把握しているので、国内でエンジニアを採用できるんなら採用したいのが本音だろう。しかしとにかくエンジニア人材が慢性的に不足している。で、結局は世界中からコード書ける人を集めて来ることになる。たまたまコード書ける人がルーマニアやスペインに居たから呼び寄せた、というのが実情だ。
IT人材が不足しているのは日本だって同じ。それでもほとんどの日本のIT部門で働く人は日本人で構成されている。外国人を入れずにチームが満たされているのは、専門知識の無いITサラリーマンが多いため。
これはSEと呼ばれる人に多い（英語圏にSEにあたる職種は無い）。大学で経営学などを専攻していたが、たまたま入った企業で所属がIT部門になっちゃった。会社でSEの勉強して今は立派にSEやってます！みたいな人だ。いわゆる企業が「ポテンシャル採用」とか言って、現在はITスキルは無いかもしれないが入社の後しっかり学んでもらってSEとしてご活躍いただきたい、という仕組み。
こんな悠長なことやってる会社は海外には無い。
文系理系という区別に意味は無いと思うし、大学の出身学部によってその人の専門知識の全てが決まる、なんて思ってもいない。そんな偏った話ではなく、ここで指摘したいのは現状でスキルが無くても「ポテンシャル採用」って無理やり向いてないかもしれない人に社内教育っておかしくね？ということだ。そういう無駄な教育コストのしわよせは全てエンジニアの低い給与に跳ね返ってきてる。面倒くさいことしてないで国籍関係なくデキる人を呼んでくればいいだろ、と。
現在の勤め先に入社した初日のことだった。ヨーロッパで働くのは初めてだし「みなさんと仲良くできたらええな」とか思ってオフィスに入った。すると同僚のロシア人エンジニアNがよってきて「おー来たな。これ君のマックブックね。で、stagingサーバーにアクセスしたら404のエラーが返ってきて使えないんだよ。後１時間でリリースしたい機能があるんだけどstagingで確認できなきゃ本当に困るんだ。アクセス権はもう渡してるから至急にサーバーに入って治してくれ！俺は機能リリースの方で大忙しだし。あー自己紹介とかもういいから。ハヨしてハヨして！後１時間だー」これが初日に言われたセリフだった。
結局nginx設定にあったバグを見つけて治した。その間に「サーバーと言うものはだねー」とか「障害時の問題の切り分け方とはー」とか社内教育してくれる人なんて居ない。
入社＝即戦力、が分かりやすく常識化している。
「毎日がこんなキリキリ舞いみたいなテンションで仕事するのはイヤだな」と思ったが、それはたまたま私の初出社とメディアのプレスリリースが重なっただけだった訳で、普段は普通のテンションで仕事している。
誰もがそうだが自分の能力を客観視して正確に把握することは難しい。そして日本でITエンジニアをやっているとその能力を世界標準で把握することはとてもとても難しい。日本のITエンジニアの虐げられ方が凄まじいからだ。日々サービス残業をして、なおかつ月末にもらう給料も「？」という金額だと、どうしても自分の能力を過小評価してしまう。「アタシがコードを書くことの価値はこの程度なのね（涙）」となってしまって当然だ。
こと海外移住に関しては技術を持ったエンジニア達が「いやー僕なんて海外でやっていけないと思います。」と過小評価して、その一方で何かの分野の専門知識の無さそうな自称ブロガーが「海外でも暮らせるぜ！なぜなら俺ってブログ書けるしよ」となりがち。現状はまったく逆。それが何の分野であれ専門知識こそが重要なのだ。
また「先進国だとビザや在住資格、労働許可が出ない、移民は制限してる」なんてどっかのブログやらの噂話を引っ張ってきて言う人が居る。しかし実情はハッキリしていて、ほとんどの国で専門技術があってしっかり稼げる人ならビザは出る。
今の時代のITエンジニアならば「技術＋英語＝ほぼどこでも移住できるチケット」の公式が成り立つのだ。
とっても単純で明らかなことなのになぜか日本の優秀なエンジニアに伝わっていないのが歯がゆい。あなたのその技術の価値はドルやユーロに変換すれば軽く年収１０００万円なんか超えてるし行こうと思えば比較的カンタンに移住できますよ、と。
億万長者を目指すならスポーツ選手よりもエンジニア | BUSINESS INSIDER JAPANなんて記事もあることだし。
ツイッター芸人のメイロマさん曰く。
夢のないことを言いますが、Twitterで移民したいとか質問してくる人の殆どは移民無理です。語学がダメだし専門性が何もないから、まずビザが下りない。日本でフツーのサラリーマンやってる人も殆どの人は無理です。詳しいことは来月ぐらいに始まる某連載に書くけど。
— めいろま (@May_Roma) July 11, 2012
彼女のツイートの真意はともかくとして、「日本でフツーのサラリーマンやってる人」の範疇に「まともなコードが書けるエンジニア」というのは含まれていないと思われる。ちゃんとコードを書いてシステムを設計するということは まーまー価値のある仕事なんだし。
ポイントはその持ち前の技術に英語をプラスすること。ただそれだけ。
Web系エンジニア必須の環境設定 ＜その２＞ssh接続 は全てsshrc
前回の続き。
週に１度でもサーバーにssh接続して作業するなら生のsshを使わずにsshrcにしましょう、と。普通にsshをするとvimの設定なんかの全ての設定がサーバーの設定に依存する。vimでサーバーファイルを編集していて、いつものキーバインドを使っても「アレ？効かない！」なんてことが少なからずイラっとさせる。
これを解消するのがsshrc。sshした際に手元の管理ファイルをサーバー側で一旦読み込んでくれる。抜ければ元に戻る。サーバー側の設定を一切汚さずに自分好みの設定ができるという優れもの。
いちいちサーバー側にGitHubに入れたdotfilesをcloneして使う、とやる例を見たことあるけど、面倒臭過ぎるだろそれ。
設定環境：MacOS
公式ページ
github.com
インストール方法
$ brew install sshrc
終わり。
設定ファイルを作る。
vimrc以外にもいろいろ読み込む場合に備えてsshrc用のフォルダを作ってそこに全てのsshrc設定を入れ込む。ただし64kb以上を入れ込むとブロックされるのでご注意を。
$ cd $ mkdir ~/.sshrc.d $ cp .vimrc ~/.sshrc.d/.vimrc $ vim ~/.sshrc.d/.vimrc いろいろ編集する
コピーしたファイル.sshrc.d/.vimrcの中身を編集してサーバーに持って行きたい設定だけにする。例えばキーバインドの設定だけを残してNeoBundleとかは全て削除する、とか。いちいちサーバーに接続した先のカラースキームまで気にしないわ、とお考えならその設定を削った方がいい。
これでsshrcをした際にsshrc.d配下のvimrc が読み込まれる。
.sshrcファイルを作る。
$ cd $ vim .sshrc
.sshrcの中身に以下を貼り付けて保存する。
export VIMINIT="let \$MYVIMRC='$SSHHOME/.sshrc.d/.vimrc' | source \$MYVIMRC"
これで設定は終わり。
サーバーに接続して設定が読み込まれるか確かめる。コマンドはsshrc
$ sshrc my_name@myserver.com
しょうもないストレス無し！快適！であればaliasに設定してsshすればいつでもsshrcとなるようにする。
alias ssh='sshrc'
以上です。
Web系エンジニア必須の環境設定 ＜その１＞dotfilesをGitHubで管理
シンガポールからヨーロッパに来てもソフトウェアエンジニアとしての職種が同じで言語も英語なので「やってることほぼ同じだな」と感じることがほとんど。そして開発の環境設定もほぼ同じ。人種国籍問わずエンジニアなら「これはやってるだろー」というような設定をまとめた。と、言うのもたまーになぜかやってない人が居たりして「こういう方法があるよ」と教えてあげると喜んでいただけるからだ。
誰もがやってること ＝ とても需要があってかつその設定が支持されている
のだと思う。
あくまで必須項目に絞ったので、エディタはVimかEmacsかとかの宗教に踏み込むつもりはない。永遠に結論の出ることが無い話ではなく「それぐらいのことやってるだろーフツー」という内容だけ。なので熟練のエンジニアの方は当然過ぎる話で面白くもなんともないと思われる。主に学生さんとか若い方向けとしてください。
全てのdotfilesをGitHubで管理する
.vimrc,.bash_profileなどファイル名の先頭にドットが付いた管理ファイルを全てまとめてGitHubで管理すること。こうしておけばMacBookが変わっても、転職を機に会社のコンピュータを返却しても、国境を超えて引っ越ししても、いつでもどこでもGitHubからクローンするだけでいつもの親しんだ環境がすぐに実現できる。
コンピュータが変わるたびにゴリゴリ設定を書く必要が無くなる。
動作環境：MacOS
自分のディレクトリにdotfilesという名のフォルダを作る。
$ cd $ mkdir dotfiles
現行のファイルをdotfiles配下に移す。（私は好みで先頭にドットを付けると隠れファイルになるのがイヤでドットを付けないファイル名としている。ここはお好み次第）
$ mv .vimrc dotfiles/vimrc $ mv .bash_profile dotfiles/bash_profile $ mv .agignore dotfiles/agignore $ mv .tmux.conf dotfiles/tmux.conf 管理したいファイル分を繰り返す
シンボリックリンクを作成する。以下の内容のシェルスクリプトを作成し、dotfiles_links.shという名で保存する。
ln -sf ~/dotfiles/vimrc ~/.vimrc ln -sf ~/dotfiles/bash_profile ~/.bash_profile ln -sf ~/dotfiles/agignore ~/.agignore ln -sf ~/dotfiles/tmux.conf ~/.tmux.conf
実行権を与えて、実行する。
$ chmod +x dotfiles_link.sh $ ./dotfiles_link.sh
GitHubにログインして左上の＋ボタンを押す。新しいリポジトリを作る。リポジトリ名はdotfilesとしておく。
$ git init $ git add . $ git commit -m "first commit" $ git remote add origin git@github.com:<Your Account Name>/dotfiles.git $ git push -u origin master
他のコンピュータにこの設定を持ってくる時
$ cd $ git clone https://github.com/<Your Account Name>/dotfiles.git $ cd dotfiles $ chmod +x dotfiles_link.sh $ ./dotfiles_link.sh
これだけ。
このちょっとしたことで貴重な時間をしょうもない設定作業に費やすことが一切無くなる。
