海外でエンジニアとしてキャリアアップするためにやったこと。ベルリンのスタートアップからトロントのShopifyに転職します。
最後に記事を書いてから（２０１６年１２月）なんと３年半の月日が流れてしまいました。
この度、カナダ・トロントにてShopifyという会社にSenior Software Developerとして転職することになりました。この機会に今までの仕事のふりかえり・棚卸しをしたいと思います。
現時点までで私は８年ほどエンジニアとして働いていますが、今年で「キャリアの半分以上を」海外で過ごしたことになります。なかなか感慨深いものがあります。
この数年何してたの？
最後にブログを更新した２０１６年１２月以降、驚くことに同じ会社で３年半働き続けていました。ウェブ系スタートアップでの平均勤続年数から言うと「３年半は長くいた方」な気がします。
今の会社に長くいすぎ!?世界の主要IT企業エンジニアの平均勤続年数は3年以下 ｜ Geekroid
ですので、まずはこの会社で過ごした３年半がどのようなものだったか記しました。
タイトルに「キャリアアップのためにやったこと」と書きましたが、結果としてキャリアアップにつながる経験値をたくさん積ませてもらえました。
実は勤務地も一回変わっており、去年の９月には現職を続けたまま、カナダ・トロントに引っ越しています。その顛末も別の機会に詳しく説明できたらと考えています。
目次
ハイライト
１．自分が在籍した３年半で、会社が３倍ほどの規模に成長した。
現職はChartMogulという、サブスクリプションビジネス向けに分析ツールを提供している会社です。 市場のニーズをタイミングよく捉えており、自分が働き始めたときには既に成長中でした（だから応募しました）。
そこから今までに、会社の人員も、ビジネス規模も約３倍くらいに成長しました（売上の方はどこまで出していいのか分からないので、人数でいうと１５人から５０人ほどになりました）。
３年半順風満帆だったわけではありません。けっこうしんどい時期が何回かありましたが、それを生き延びて、さらに（後述しますが）成長路線にもう一度乗せることに貢献するという、貴重な経験を積ませてもらいました。
２．成長とその間の紆余曲折で、自分の役割・責務が大きく変化した。
おおまかに分けて、３年半で下記の経験を積ませてもらいました。
１年目：Individual Contributor（部下を持たずに個人のタスク遂行で価値を出すことを求められている人。"IC"とかって略されたりします）としてやることをやる。コードを読んで、設計に対して意見を言えるように「刀を研いで」おく。
２年目：チームリードとして、チームの障害・構造的な問題を取り除いていく。１on１、技術面接、ロードマップへの提案など、やることが増える。
３年目：テックリードとして、データパイプラインの設計を行う。エンジニアリング部署全体の技術理解度、１０倍・１００倍スケールしたときのことを見据えて、要件の再定義を行う。チームリードを兼任しながらプロジェクトの成功に責任を負う。
詳しくは下記に別記事としてまとめたので、参考になれば。
３．３年目に入り、自分の成長速度の鈍化を感じた。
そのテックリードとして担当したデータパイプラインがリリースにいたったのが、今月３月のことです。 この時期の自分を分析すると、 「疲労がたまっている」 「バランスが崩れている」 という状態だったと思います。
会社を成長させること、自分が成長すること、価値を出し続けることなどについて「行き詰まっている」感覚がありました。
- 以前と同じ質で物事を提案しているはずなのに、なかなか賛同が得られない。
- チームとしてのスピード感が出ない。
- プロジェクトの完遂と会社の成長のあいだの「変数」が増え、フィードバックがうまく機能しない。
おそらく、会社の規模・構成が変化するにともない、会社の文化が変わったことに気づけなかったのだと思います。
機能を開発し、みんな志高く同じ目標に向かって突き進むことが当たり前だった入社１〜２年。 ビジネスが大きくなり、個人からチーム、チームから部署になりはじめ、また入社する人たちのマインドセットも徐々に変わってきた後半の１〜２年。
自分はどちらかというと「働いている姿を見せること」で他の人に影響を与えてきたと思います。 そのリーダーシップスタイルは、まだ会社が小さいうちにはいいのですが、より大きな組織になると影響力ががくっと落ちます。
また、テックリードとして「この設計はどこまでスケーラブルなのか」という質問に常に答え続けなければいけません。このときに自分の脳裏をよぎったのは、「今の会社で自分は技術選定をリードする立場だが、自分よりもすぐれた知識やプラクティスが業界には絶対にあるはず」という思いです。
自分が現職に留まりつつキャッチアップするのがいいのか。シニアやリードの新規採用で新陳代謝を起こしたほうがいいのか。「自分が居続けることに弊害もあるのかもしれない」と考え始めるようになりました。
こういう振り返りができたのは最近です。プロジェクト終了直後は、とにかくデータパイプラインの再設計、チームリード、テックリードを並行して進めて、かなり疲労困憊でした。
これからは？
ソフトスキルの目標： "Calm, centered leadership"
「自分が働くことで成果をあげる」という意識のままでリーダーシップポジションに入ると、「自分みたいなのが複数人いればいいのに」という危険極まりない思考に入っていきかねません。CEOにフィードバックをお願いする機会があったのですが、その中で自分に刺さったのは「Calm, centered Leadership」という表現です。
今すぐ成果が見えずとも、自分のやったことが長期的・持続的な変化・変革につながっていくという信念をもつ。そのために研鑽を積む。その結果として上述のリーダーシップスタイルが導き出せるのでは、と踏んでいます。
その際、技術スキルは、周囲を「Enable」する、その点で有用になってきます。 そのためには、自分の興味分野で深掘りできるポイントをしっかり掘っていき、その中から普遍性を見出すことが大切です。
一方、マネジメントという観点で「Enable」するためには、ビジネス・部署の複雑性を理解しながら技術が「本質的になにを阻害しているのか」「何を変革できるのか」それらを様々な立場の人が「納得するしかない」形でプロジェクトに落とし込んでいくことが重要です。
技術目標： "Deepen the portfolio"
ChartMogulに入社した当初は、「Rails/Full-stack」「Getting things done」「Consistent learner」あたりのコンビネーションで価値を出せていたと思うのですが、 経験年数が二桁になるころには、より体系化された知識と専門性がないとキャリアが続かないのではと感じています。
ここらへんのキャリアトラックで悩んでいたときに、下記二つの視点が大変参考になりました。これも解説し始めるときりがないので、また別の機会に。知りたい人はコメント・連絡いただければ幸いです。
Shopifyを選んだ理由
Shopifyでは、マーチャントの海外展開を支援するAPI基盤の開発、というチームに配属される予定です。
転職活動中は、TechLeadとしてやっていたデータパイプライン分野を深掘りすると言う意味で、データエンジニアリングにふったキャリア選択も候補にありました。
しかし、
- まだ一つの専門領域に舵を切っていくには経験値・サンプル数が足りない気がした。
- それよりも先に、大規模かつ既に馴染みがある技術スタックで運営されているシステムの内部を知りたい。そうすることで、幅と深さの両方を知った上で専門領域を考えられると思った。
- Shopifyで働いている人にリファレンスをとったところ、みな口を揃えて「良い会社」といっているので、マネジメントの部分でも学ぶことがありそう。
- 何よりも、最後のチームマネージャーとのマッチング面談で、話が一番弾んだ。
というあたりで、Shopifyからのオファーを受諾することに決めました。
また一からの出直しです。ワクワクしています。
海外でエンジニアとして働き続けるためのアドバイス
１．生活ががらっと変わるときは、職務・スタックは変えない方がいい。
初めて住む国で、職務内容も変えるとなると、相当のパワーが一度に要求されます。 一社目では日本でやったエンジニア職務で足がかりをつかむと、「文化・生活に慣れる時期」というバッファがとれるのではないでしょうか。
２．二社目からは、成長をとっていこう。
人は環境に影響されやすいものなので、成長中の会社に身を置くことは自分を成長させる上でよい方法だと思います。
こういう考え方を、Growth Mindsetと言うそうです。
３．「がんばって働く」という価値観はマイノリティになりうることを肝に銘じる。
これはニュアンスが難しいのですが、 「みんながんばって働くわけではない」ということをしっかり考えたことがありませんでした。
自分で会社をやったりスタートアップの初期メンバーだったことがあると、つい「まじめに働くのは当たり前でしょ（そうじゃなきゃ会社が潰れる）」と思ってしまいがちです。しかし、会社の成長路線・雇用体制によっては、それが長く続くわけではないですよね。会社のステージが変われば、社員の意識も変わります。
自分が期待する「勤勉さ」というのがなくても、会社に価値を与えられる人はいるのだろうな、それが多様性の意味だろうな、と考えるようになりました。勤勉さがマイノリティになりうることを意識していないと、めっちゃストレスになります。気をつけて。
４．フルリモートと、フルリモート＋フル時差は全然違う。
チームメンバーの時差の最大１０時間という、ハードな状況が何回かありました。 今でも、どうやったらその時差でいい感じのエンジニアチームがつくれるか分かっていません。
よりワークフローが非同期に特化した部署（最近のカスタマーサクセスなど）ならうまく回るのかもしれません。クリエイティブな技術設計の話など、私はホワイトボードを引っ張り出して、1時間集中して同僚とガチャガチャ議論したいタイプなので、これを非同期で置き換えるイメージがまったく湧きません。
成功事例があったらぜひ聞いてみたいです。
おわりに
こんな方とお話ししてみたいです。
- Ruby/Rails界隈でのデータパイプラインの知見、データ処理のライブラリに物足りなさを感じている人。Apache BeamやFlinkをそれ界隈の技術をやっている・やってみたい方。
- ベルリン、もしくはトロント進出済み・進出予定のエンジニアの方。もしくはそもそもエンジニアとして新規挑戦されたい方。
- Shopifyにご縁がある方。
９月頭までの１ヶ月半はわりと時間があります。はてなと同じハンドルネーム（kenzan100）で色々なソーシャルメディアにいますので、連絡いただければ幸いです。
それではまた次の機会に！
［補足］海外でエンジニアとしてキャリアアップをするためにやったこと。３年半を詳しく振り返る。
下記の補足記事です。
３年半ベルリンのスタートアップで働いた経験を、時系列で細かくふりかえります。働いた会社の詳細や前後の文脈などは、上記本記事を参照してください。
入社したて：与えられた仕事をやりきる。コードを読みまくる。
まずはIndividual Contributor（部下を持たずに個人のタスク遂行で価値を出すことを求められている人。"IC"とかって略されたりします）として認めてもらうまでに、１年くらいかかりました。
入りたての最初のミーティングで、「RustでInMemory DBつくるんだけど、どう設計したらいいと思う？」みたいなトピックを出されて、固まったことを覚えています。ビジネスドメインの理解も入社したてでふわふわ、関連技術の経験もない状態だったので「何が分からないのかも分からない」ような状況でした。
案の定、そのあとはかなりレイヤーの違う仕事に回されました。データ可視化ライブラリd3.jsとビジネスロジックの統合辺りをきれいにして、UIに新しいグラフ描画オプションを追加する仕事を一生懸命にやっていました。 とにかく、コードを読みまくることに必死でした。
その後フロントエンドでスピード感よく仕事が終わらせられるようになってきたので、バックエンドの実装が遅れていた部分に、チームメンバーとして参加することに。Golangでマイクロサービスを書くという、そのときの興味分野にマッチしたプロジェクトでした。
大体主要なコードを読み切り、コンポーネント間の構造で物事を捉えられるようになったのは一年くらい経ってからです。
Be the worst
組織で自分が一番できていない状態にあることを、プログラマー向けのパターン言語で「Be the worst」というそうです。
転職や社内での異動を考えている人は、ぜひ"Be the worst"になれる機会を積極的に取りにいくといいと思います。サバイバルモードで学習意欲が高まる人にはなおさらオススメです。
１年経った頃：チームリードをやらせてもらえないか打診
１年が経って周りに気を配る余裕が出てきたころです。「あれ、今の会社のボトルネックって、技術じゃなくてチームワークだな」と気づく場面がありました。
あるチームに、一人でバリバリとコードを書く、英語が苦手なフルリモート勤務のメンバーがいました。彼が仕事をするとぐっとプロジェクトが前に進むのですが、実はその陰で他のチームメンバーが置いてけぼりを食らってしまう。言語と時差の壁もあり、フィードバックがうまく機能していない状況でした。
そこで、CTOに１on１を申し込んで「今の自分ならチームリードの職務に適性があるはず。やらせてもらえないか」と打診しました。 CTOからすると想定外の申し入れだったらしく驚いていましたが、「You have drive and passion for Product development」と（おそらく）そこまでの仕事を進め方を評価してもらい、チームリードに昇格してもらうことができました。
"Is there any blockers?"
ここからはかなり考え方が変わります。 自分の仕事をやりきることは当たり前で、さらにメンバーの仕事の障壁を率先して取り除いていかなければいけません。５、６人のフロントエンド主体のチームで、１on１、新規採用の面接などもやらせてもらいました。
この頃参考になったのは、スタンドアップのときの"Is there any blockers?"という質問形式と、Enablement・Empowermentという考え方。 そして同じような問題が二度三度と起こったら、それを構造的に解決できないか考える姿勢です。
例えば、あるメンバーがフロントエンドの状態管理で苦言を呈していました。話を聞くとかなり深刻で、今のままで状態管理をアドホックで進めていくと、バグが頻出するだろうとのこと。
そこで、当時はBackbone/Marionetteで構築されたSPAだったのですが、SPAそのものをマイグレーションすることも含めて幅広く検討し、マイグレーションコストを議論し、徐々にライブラリを切り替えていくロードマップを立てました。
このときは下記の点に注力しました。
- 半分のチームメンバーがフルリモート（時差数時間の差含む）だったので、議論をいかに非同期で進めるか考える。
- 英語が不得意なメンバーが一定数いたので、「決まったこと」と「議論中のこと」を明確に分けて、メンバーの理解度に差がないか気を配る。
- 自分の意見の我を通さない。建設的な議論の風通しの良さが、チームの長期的な健全さ・生産性につながることを理解する。
- 計算されたリスクをとって、「決める」責任を負う。
入社２年半〜：テックリードとしてコアプロダクトの設計を担当
チームリードになって半年が経った頃、CTOが自身のスタートアップを起こすということで（円満）退社を迎えました。
新しいCTOの採用が難航する中で、他のチームのリードがHead of Engineeringにプロモートされました。
同じ頃、機能開発優先でつくられていたチームの分け方に弊害が生じていました。会社の成長で、処理するデータ量・データそのものの複雑さが増しており、MVP以降修繕を繰り返していた最初の設計そのものに「綻びがではじめていた」と理解しています。
Tech Debt Month
そこで「TechDebt Month」というものが社内で提案されました。「技術負債返済のための集中月間」とでも訳すのでしょうか。この月を境に、既存のチームをいったんリセットし、破綻し始めているサービス・コンポーネントの分析・（必要であれば）再設計をするというプロジェクトが始まりました。
技術負債の洗い出しで、緊急度・重要度がともに高く認識されたのが、マイクロサービスに切り出したデータモデルの見直し。 だからといって、マイクロサービスをそのままMonolithに戻すのは問題を先延ばしにしているだけ。
ちょうどこの頃下記のBraintree 元CTOの記事を読み、Modular Monolithを社内で啓蒙し始めていた頃でした。
この二つがうまい具合にはまり、データモデルの再設計のプロジェクトのテックリードをやらせてもらいました。そこから今まで、コアプロダクトであるデータパイプラインを主導するチームのテックリードとして、２年間過ごしています。
最後に渾身の力で仕上げたデータパイプラインは、タイトな締め切りとチームの知識という制限を考慮すれば、そこそこ良い感じで稼働していると思います。 （ここは、キチンと技術トークとして一本別記事として仕上げたい。）
おそらく数年後には「クソコード・クソ設計したなー、俺」と恥をかくことになると思いますが。。そんなもんだと腹をくくっています。
おわりに
上記のふりかえりの結果で、下記記事をまとめることができました。できるだけ海外っぽいと感じたところをアドバイスにしました。ご興味ある方はぜひ目を通してみてください。
ベルリンにて転職しました。
お久しぶりです、ドイツベルリンから書いております。 深山雄太です。
前回の記事
結論から申し上げますと、今月いっぱいで今働いている会社を辞め、来月からベルリンの別の会社で働き始めます。
海外で働きつつ、そのまま現地で転職活動をしたのは生まれて初めてのことです。ベルリンで働き始めてから一度も活動報告をしていなかったこともあり、この記事でまとめて書いてみます。
ベルリンどうよ？
とても良いです。ベルリンの住みやすさは最高です。 東京よりも圧倒的に人口密度が低く（２３区と比較して、人口は約三分の一、面積は約１．６倍だったかな）、通勤や週末の買い物にまったくストレスを感じません。
部屋も広い。東京やニューヨーク、ロンドンとかだと、家賃あたりの体積が極端に狭いと感じます。その点ベルリンは、たてよこ高さすべてにおいて「一人が快適に暮らすにはこれくらいのスペース必要っしょ」みたいな最低基準が高い気がします。
[オフィスです]
ベルリンも不動産価格は高騰しているみたいなのでいつまでもこの状況が続くかはわかりませんが、今の所はエンジニアが楽しく働けそうな都市の中ではゆとり（というか田舎感）を感じることができます。
お店の営業時間が短く、深夜営業ほとんどなし。日曜日は基本的にすべての店が閉まります（レストラン除く）。 日本のコンビニ、ドラッグストア、ドンキホーテみたいなものは皆無でして、物欲がなくなります。買い物がパターン化してくるので、買い出しのストレスが減りました。
大都市に慣れた人からすると、ベルリンは不便かも。でもエンジニアとしては一台のPCと電源とWi-Fiさえあれば、時間はいくらあっても足りないくらいの学習リソース（やコミュニティ）があります。 選択肢が少なくても、打ち込めるものがあればいい。そんなライフスタイルを望む人にとっては、ベルリンはとってもおすすめです。
ちなみに家から職場までは、こんな道のりです。
[家を出たあたり]
[地下鉄]
[そして職場の近く]
なんで転職するの？
ベルリンはそんなわけで自分にとってとても暮らしやすい環境ですが、会社は、働くうちに辛さを感じることが増えてきました。 理由は二つで、あまりにも人数が少なすぎたこと、ドイツ語でのコミュニケーションが思ったより多かったことです。
3月から今月末まで八ヶ月働いたことになるその会社ですが、ウェブアプリ開発を中心にした受託開発の会社です。 https://nerdgeschoss.de/
大学を出たてのドイツ人二人が創業者。長期のお仕事が増えてきたということで、フルタイムのエンジニアをhttp://berlinstartupjobs.com/で募集していたときに、偶然応募しました。 詳しくは前回の記事にまとめてあります。
柔和で人当たりのよいクリスと、技術オタクのイエンズ。この二人の組み合わせは絶妙で、二人が大きめの仕事を取ってくるさまを間近でみるにつけ、つくづくチームって大事だな、と思います。
[創業者二人の写真。数年前だからだいぶ若い。]
ドイツ人二人で、ドイツ国内のクライアント6社くらいを同時に回していた彼ら。その環境でなぜか東京から連絡した日本人の私を採用してくれました。真相は今でも謎ですが、数回のスカイプと技術課題で遠隔地にいながらオファーを決断してくれた彼らの懐の深さには、今でもいたく感謝しております。
彼らは採用当時「ベルリンは英語だけでやっていけるし、俺たちを英語メインで仕事してるから、ドイツ語いらないよ！」と言ってくれたのですが、しかしやはりここはドイツ。そういうわけにはいかなかったです。
ドイツ語辛い
同僚がいなく、創業者二人とクライアントがドイツ語で打ち合わせをしていたりするので、どうしても会話で後手後手にまわってしまう。
ステークホルダー全員、英語を話そうと思えばそれこそペラペラしゃべることができる人たちなのですが、込み入った話になってくるともちろんドイツ語の方が話しやすいわけで。そういうときに、毎回あとから「で、何が決まったんだい？」と聞き返すのは、ストレスでした。
日本でも英語を社内共通語にしようとする会社がいくつかあると思いますが、たとえば契約の話とか、納期がせまってきたときとか、ホットフィックス対応とか。そういうときにはやはり母語でのコミュニケーションの方がリスクが少ないわけです。
ましてや従業員とクライアントであれば、どちらを優先させたほうがよいかは明らか。クライアントが快適に話せる言葉を使ったほうが良いに決まっています。それを実感した八ヶ月でした。
「ドイツに移住しておいてドイツ語が辛いとか、こいつ何言ってるんだ」というツッコミが聞こえてきそうですが、ベルリンの良いところは、そのときに「英語オンリーの職場に転職する」という選択肢があるところです。
このとき自分には「ドイツでこの先もがんばりたいので、ドイツ語を学んで、今の職場でプレゼンスをあげていく」という選択肢と、「英語が通じる地域でエンジニアとして活躍したいので、英語だけで何とかなる職場に転職する」という二つの選択肢がありました。
自分にとっては明らかに後者の方が比重が大きかった。そのため、このタイミングでの転職活動に踏み切りました。
転職活動やってみてどうだった？
冒頭にも書きましたが、海外での就労生活ははじめてで、特にツテがあるわけでもありません。その状態で最初は自分が好きな会社（ドイツにはこだわらず）にぽろぽろとレジュメを送っていたのですが、あまり反応がよくありません。
今度は地域をベルリンに絞って探してみますと、募集自体はいくらでもあるものの、何を基準にしてどういう順番で応募しようか、迷ってしまいました。
- http://berlinstartupjobs.com/ （1社目を見つけるときに使った求人サイト）
- https://jobspotting.com/
ハニーポットというサービスがよかった
そんなときに同じく日本からベルリンに移住されたエンジニアの先輩から、ハニーポットなるサービスがあることを聞きました。
["Companies apply to you."]
ハニーポットはいまおそらく流行りのエンジニア限定のリクルーティングサービス。各地に似たようがものができつつあると思いますが、この会社はドイツベルリンにHQがあり、ヨーロッパで転職活動をしているエンジニアに嬉しいサービスです。
エンジニアとしてサービスに登録するだけで、複数の企業があなたにコンタクトしてくれます（オファー金額つき）。レジュメの公開期間が二週間限定と決まっており、その間に登録企業があなたに興味をもてば、連絡がきます。限られた時間の中で、あなたがどれだけ求められるか、だいたいの市場価値を判断することができます。
アメリカだと似たようなもので https://hired.com/ というのがあります（サービス開始時期としては、こっちが先だったと思う）。
インタビュープロセスにも不慣れな時期においては、こういったところで複数のインタビュープロセスをこなしてみることで、「採用までにだいたい何ステップあって、各ステップでどんなことを聞かれて、自分はどれだけペラペラしゃべることができるか」というものを確認できます。
やっているうちにだんだんと傾向と対策がわかってきます。その後の活動に向けて、大いに自信がつきました。
自分は三ヶ月くらいの期間で、合計10社くらいとお話をし（レジュメ送っただけで終わったところは除く）、うち5社くらいからオファーをいただいたのですが、そのうちの半分はこのサービス経由でした。
採用の大まかなプロセス
だいたいどの企業も、
- 書類でのスクリーニング
- スカイプとかで１、２回自己紹介と技術についてのオープンエンドセッション
- 技術課題（ホワイトボードか、持ち帰り課題、ときどき1日体験入社みたいなのもあった）
- 最終的な相性をみるお見合いセッション
- オファー
という流れをとっていたように思えます。
特に自分が面白いなと思ったプロセスをとりあげると、
最初の方で必ず聞かれる質問
"What is the biggest technical challenge you solved recently?" という感じの質問は、必ずと言っていいほど聞かれます。 https://www.quora.com/How-do-you-answer-the-technical-interview-question-What-is-your-biggest-challenge-and-how-did-you-solve-it
答えはその人自身の経験に依存しますので対策はないのですが、 「ある程度実践的な（チュートリアルやりましたとかではないやつ）技術課題に対して、情熱的にしゃべることができること」 というのが、この段階で大切なことだと感じています。
ただでさえ母語ではない英語で語らなければいけないですので、必ずサマリーを書き出したり、暗唱してから臨むことをおすすめします。 「あぁ、こいつは技術が好きで、自発的に問題に取り組んで成果を出せるんだな」と思ってもらえたら、このセッションはパスできると思います。
技術課題の傾向
局所的な感覚値ですが、グーグルとかマイクロソフトが採用しているコーディングチャレンジに対して、肯定的な企業と否定的な企業が両方いると思います。 https://www.quora.com/Which-is-the-best-book-to-prepare-for-coding-programming-interviews
いわく「コーディングパズルでは、その人が職場でどうパフォーマンス発揮するか全く測れない」 一方で「アルゴリズムやデータ構造について理解が乏しい人は、肝心なところで活躍できない」などなど。
ハイブリッド型の技術課題として、「一問一答形式のコーディング問題を足切りで出題、その後合格者にだけ数時間から数日かけて取り組む技術課題を出す」などもありました。
最近増えてきたなと思うのは、その会社のプロダクトの一部を簡素化して、お持ち帰り課題として切り出す、というパターン。 その中でも、SoundCloudの課題はとっても面白かった（落ちました）。技術課題が面白い会社は、良い会社だと勝手に思っています。
深掘りできるときにしておこう
会社が違えばその会社の技術に対する姿勢もそこそこ異なるわけで、一概にこれをやったらいい、というものはやっぱりありません。 でも、あなたが応募している職種に書かれている技術スタックで、それがどういう仕組みで動いているのか（インターナルの概論）というのは、このセッションをクリアするのに大事な所だと思います。
例えばRails。ウェブアプリ開発時に、Railsの恩恵が大きい部分（Railsが何を解決しているのか）についての理解がどの程度あるか。自分が楽できたなー、と感じた時などに深堀りしておくことが大事だと思います。ARがどうDBとやり取りするのかとか、AutoLoadingとか。
転職活動というのは「もしかしたら聞かれるかもしれないから勉強しておこう」という点において、普段よりも学習意欲が高まっている状態だと思います。転職活動をちょっと大きめにとらえて「自分のスキルアップ期間」と考えて勉強すると、なかなか有意義な時間が過ごせるのではないかと。
お見合いセッション〜実際に決断するまで
はれて技術課題も突破したら、あとはもうお見合いみたいなもんだと思います。 どんな企業にも良い顔をしたくなるのですが、待遇面と「毎日の業務フローで、今までの経験上、ここだけは譲れない」みたいなものを明確にしておきましょう。
これは日本にいたときのエンジニアの先輩のアドバイスの実践なのですが、 もしここまでに彼らのオフィスで1日とか半日時間を過ごしたことがないのであれば、頼み込んででも「1日だけ体験入社的なことさせてくれない？」と聞いてみましょう。 お互い入社してからミスマッチが判明するのは最悪ですので。
自分の場合は「英語だけで通用する職場に行きたい」というのがそもそもの転職理由でしたので、開発チームの日常の業務フローが英語だけで完結するか、というのは大きなポイントでした。
結果的には、カスタマーサポート以外全員外国人のチーム、顧客のほとんどが北米、だけどヘッドクォーターはベルリンという会社に巡り合うことができ、当初の目的を叶えることができそうです。
[ここで働きます]
決済APIと連携済みのSaaSを主な対象としたビジネスメトリクスを提供している会社です。そっち方面の会社で働いている方がいたら、ぜひ登録して使い心地を教えてください。 https://chartmogul.com/
転職活動で一番つらかったこと
いつの時代もつらいのは、最終的には一社に決めなければいけないのに、複数社並行してプロセスを進めなければいけないことですね。こればっかりは。。 体験入社で心が固まることは多いとは思います。
あと、すぐに決めるぞ！という気持ちで臨まずに、転職活動を課外活動みたいなものとしてとらえて「夢の仕事（ここからオファーもらえたら、百パーオーケー）に出会うまで長期的に頑張り続ける」という気持ちの方が成長できる気はします。メンタルも技術力も。
ただ、今いる会社の通常業務をこなしながらなので、心と体は疲弊していきます。ほどほどにしましょう（奥様、話を聞いてくれてありがとう）。
そういう意味では、選考が進んだ会社の中でSoundCloudとかN26（銀行スタートアップ）が自分にとっての「夢の仕事」でした。ただ、こういうところはおそらく応募件数が他のスタートアップとくらべて桁違いだと思います（いわんやグーグル、フェイスブック、Amazon、エトセトラ）。
[SoundCloud楽しかった。色々と噂はありますが。]
こういった所のプロセスは、よりアーリーなスタートアップ企業よりも時間がかかるということは覚えておくと良いと思います。私の場合、あるスタートアップが二週間で計５回くらいのプロセスを終えてオファーをくれたのに、今あげたような大手は二週間たってまだ技術課題の結果待ち、というのはざらでした。
この場合、既にオファーが出たところに待っていただいている状態で、（そもそも落ちているかもしれない）結果待ちをしなければいけないのはかなり辛いです。「そういった特殊な状況下になったら、どういう決め手でオファーをアクセプトするか」は事前に考えておくとよいかも。
がんばってね！
はい、がんばります。 えーと、この八ヶ月で自分に仕事環境に起こった変化でいうと、だいたいこんなところです。
そんなこんなで、自分は1日の体験入社も済ませ、来月から新しい会社で働きます。体験入社時点ですでにかなりディープなプロジェクトが待っていることもわかったので、不安と期待で胸がいっぱいです。
良いご報告ができるよう、がんばります。 それでは、また。
来月頭より、ベルリンでエンジニアとして働くことになりました。
https://www.flickr.com/photos/ntrinkhaus/14593212964
お久しぶりです。
突然のご報告ですが、来月頭よりベルリンでエンジニアとして働くことになりました。この場を使って、働くことになった経緯と今後の展望を書きます。
これから海外でウェブ系のエンジニアとして働く人の参考になれば幸いです。
まず私の属性ですが、31歳、文系出身、主にRuby（Rails）でウェブアプリを書いています。エンジニア歴五年くらいです。 プログラミングを始める前は、大学時代に友達と始めた会社でゲームをつくっていました（会社は存続していて、今年で8年目です）。
こんなゲームをつくっていました。
主に日本のスタートアップ企業で働いてきました。DB設計/インフラ構築含め、一からウェブサービスを開発することもあれば、既存サービスの登録者数を2ヶ月で倍増させる施策に携わることもありました。
昨年はひょんなことから、ニューヨークの選抜式のプログラミングキャンプに三ヶ月滞在しました。 ※そのときの詳細は下記にまとめています。
エンジニアとして働くようになってから思っていることで、また海外に数ヶ月滞在してより強く思うのは、 「英語はもはや標準語で、情報のインプット/アウトプットが英語でないことは、成長する上で不利である」ということです。
すこし偏った考え方かもしれませんが、現時点ではそう思います。
理由は単純です。より多くの人に自分の考えを伝えたい人は、母国語が何語であろうと、英語で発信します。情報の母数が圧倒的に大きいので、その中で浮かび上がってくる情報にはみんなが注目します。その結果、さらに英語での情報量が増える。このフィードバックループが働いていると思うからです。
Github、StackOverflow、HackerNews.. こういったサイトに全世界からエンジニアが集まり、英語で議論しています。
個人的にも、RailsCastsやThoughtbot社が提供するスクリーンキャスト、そして 英語が原著である数々の技術書にお世話になりました。
ThoughtbotのCTO Joe Ferrisさんは声がとても良い
ベルリンという選択肢
そんな経緯で海外でのエンジニアキャリアへの思いを強くしていた矢先に、複数の方から「ドイツ ベルリンのスタートアップシーンがアツいらしい」という噂を聞きました。
実際に日本人エンジニア二人が渡独し会社を立ち上げていたり、他にもグッドパッチさんが海外オフィス第一号としてベルリンにオフィスをつくっていたり。
以前の職場の同僚は、世界中のスタートアップを巡る中で、ベルリン発のスタートアップWunderlistの職場環境に強く感銘を受けたそうです。
そのときに、ベルリンのウェブ業界では英語さえ喋ることができれば不自由しない、ということも聞きました。
ワーキングホリデービザの使い道
そして最後に自分の背中を押したのは、ワーキングホリデービザの存在です。 今まで自分の中のワーキングホリデービザのイメージは「異文化理解のための留学の大人版」のようなもので、自分とはあまり関係がないと思っていました。
ただ、就労ビザを取ることの難しさを去年ニューヨークで肌で感じた昨年末、 「ワーキングホリデービザで就職先を見つけ、そこから就労ビザに移行する」というやり方があることを知りました。
さらに、私がこの方法を真剣に考え始めたときには、すでにワーキングホリデービザの取得期限が間近に迫っていました。 ドイツのワーキングホリデー申請資格は、「申請日に、30歳以下であること」。31歳の誕生日がタイムリミットです。
31歳の誕生日が一ヶ月後に迫っていた私にとって、この期限は「今決断しなければ、人生で選択できるチャレンジの一つが永久に失われる」という類のものでした。
妻には「見通しが甘すぎる」とこってりと絞られましたが、最終的には妻と私二人で、（移住覚悟で）ベルリンに生活の拠点を移す、という決断をするに至りました。
仕事のオファーをもらうまで
ビザが取れるからといって、雇ってくれる（それも自分が望むポジションで）組織がなければ、就労ビザの取得は望み薄です。 自分の現在のスキルセットがどう評価されるのかまったく分からない状態で、とりあえず現地のウェブエンジニア向け求人をあたってみました。
Berlin Startup Jobsというどんぴしゃのサイトがあり、情報は毎日のように更新されます
全部で5,6社にレジュメを送り、ベルリンに移住することになった経緯をそのメールの冒頭に書き添えました。 結論からいうと、無事そのうちの一社からオファーをいただき、ベルリン到着後すぐにその会社でエンジニアとして働き始めます。
その会社はここ。ドイツ人二人だけでやっている開発会社で、三人目として自分が参加します。 https://nerdgeschoss.de/
そのうち一人の Jensというエンジニアは、ベルリンで Swift.berlin というミートアップを主催しており、余暇でサーバーサイドSwiftのウェブフレームワークを自分で開発していたり、技術的に大変面白い方です。
他の会社からも総じて反応がよかった訳ではなく、この会社だけが今の自分のスキルセットを評価してくれました。 雇用はお見合いなのだなと、つくづく思います（もし今エンジニアとして就職活動、転職活動をしている人がいたら、決して一社一社からの評価に気を揉まないでください）。
この会社がなぜオファーをくれたのか自分なりに分析してみると、
- 英語に関しては苦労せずにコミュニケーションできること（ドイツ語が喋れなくてもまったく問題ない、とのことでした）
- スタートアップでウェブアプリを0から素早くつくる、という経験があったこと
- Swiftが出たばかりのときに作ったiOSゲームをGithub上で公開しており、それを気に入ってくれたこと（実は現在の開発環境だとビルドできません。。 ）
ざっくりとこんな所だと思っています。
この選択を正解にするために
自分はエンジニアとしてまだまだ未熟です。それでも自分となんのしがらみもない海外の開発会社からオファーをもらえたことで、チャレンジする道が拓けました。
ただ、この方法がオススメかというと正直迷います。場所が変わることは強烈な成長ファクターだと思いますが、結果成長するかどうかは、その人次第ですよね。
「日本でまず技術力を伸ばして、それから海外でもどこでも、自分が挑戦したい分野に挑めば良いのでは」という考えにも共感します。ウェブアプリ開発という文脈で、東京のレベルが低いとはまったく思いません。
ただ、自分の場合たまたま「英語で情報をインプットしているときのほうが、よりプログラミングにハマる感覚が強かった（成長実感が強かった）」というイメージがあるので、今回の道を選びました。
あとはこれを正解にしていけるよう、現地で精一杯、願わくば JensとChrisという二人のドイツ人と一緒に「代表作（サービス/プロダクトなのか、ライブラリなのか、はたまた組織そのものなのか分かりませんが）」をつくれるよう、粘り強く挑戦していきたいと思います。
自分が働く会社のチーム紹介ページ。この "YOU" が俺になります
似たような経験をすでにしていらっしゃる方、これからしようかどうか迷っている方、そんな方々にとっての一つの視座になれば幸いです。
とりあえず、今一番不安なのは、日本のおいしいお米が食べられなさそうなことと、集団でディスカッションするときに、会話においてけぼりになりそうなことです。。
「中級者エンジニア」ならではの悩み
皆さんは、今自分のエンジニアとしての学習サイクルに満足していますか？
自分は全く満足できていません。やってみたいこと、やらなきゃいけないと思うことがたくさんあって、その割に学習速度を保てていると感じられていないからです。
三ヶ月前までは、そんなことはありませんでした。それは、 リカースセンター(前まではHacker School) という、仕事/寝食を忘れてコーディングに没頭できる場所に渡米し通っていたからです。
そこで日本に帰国後、このコミュニティで感動したことを自分なりに解釈し、Dokugaku Dojoという名前でこの3ヶ月間実験してきました。
プログラミング独学道場 第一回ミートアップ「Hello World」を開きました。 - zakisan's blog
Dokugaku Dojo = 中級者エンジニアが、学習を加速させる場所
しかし最近「これは何のための、誰のための場所なのか」という、このコミュニティの位置づけについて色々と悩んでおりました。悩みに悩んだ結果、現在は 『初心者を過ぎたエンジニアが、さらに学習を加速させられる場づくり』 というビジョンを掲げております。
その理由として。。
ブーム化するプログラミング学習
アメリカではすでにプログラミング学習が一種の「ブーム化」しています。短期間で一気にウェブアプリ開発技術を詰め込む、「ブートキャンプ」と呼ばれるやつですね（私が参加したところの組織のファウンダーは、初心者を対象にしたこのブートキャンプ現象を毛嫌いしていましたが...）。
ブートキャンプの語源は、軍隊の新兵訓練施設です photo by MCRD Parris Island, SC
2015年5月時点で、北米地域で 70を超えるプログラミングブートキャンプが存在するようです。 日本でもこの流れは起きていて、最近だとテックキャンプ、テックアカデミー、（リモートだと）コードキャンプなどがあります。
プログラミング、その深遠な冒険の始まり...
では、そこでひとまず「なんとなく、ウェブアプリってこう作れば良いんだな」ってことが分かったとしましょう。実はそこからが、冒険の始まりなのです。 この右も左も分からない初心者を脱したあたりから、エンジニアは色々な方向に興味、目的意識が拡散していく傾向にあります。
ここで厄介なのは、まだ一つの技術分野を「極める覚悟」をもった段階ではないため、とりうる選択肢が色々ある、ということです。
現在の自分の頭の中をさらけ出してしまうと。。
Railsで何年か書いてきたけど、何年後かにRailsって陳腐化するよなぁ。。（現状への不安） そういえば、静的型付けの言語って業務でまだやってないなぁ。。でもC++やJavaを独りでやる気しないなぁ.. やっぱここはGoかな！ でももっと振り切ってRustも良いんじゃね？ あともちろん、関数型は絶対だよね。。Scala、Elixir!? Haskell。。 JavaScriptも、古くて常に新しい言語なので、理解の深さが試されるよなぁ、ECMAScript6 ...
この混沌とした思考が、プログラミング言語だけでなく、ライブラリ、フレームワーク、XaaS(SaaS, PaaS, BaaS...) においても繰り返されるとお考えください。
中級者からの思考のビッグバン です。Qiitaから毎週届く「先週ストックが多かった投稿ベスト20」が、これに拍車をかけます。
そうなってくると、一つの技術にじっくり取り組む集中力が減退してしまい、表層的な部分しかなぞっていないということにもなりかねません。 さらに、今までは「初心者にありがちなバグ・エラー」でお互いに助け合えていたエンジニア同士でも、細分化したときには助け合える共通の課題が減ってしまいます。結果、勉強仲間に出会いにくくなったり、ウェブ上の情報ボリュームが少なくなってしまいます。
ググってもなかなかシンプルな解決策が出てこないエラーで悩んだり、バズっている技術の何に手を出したら良いのか考えたり、、エンジニアは十把一絡げではなく、そこからさらにまた専門性があるんだ、ということにも気づいてくる頃です。
中級者エンジニアならではのメタなコミュニティをつくりたい
そんな雑多な状態で、どうやったら良いコミュニティがつくれるんでしょう。一つニューヨークでの体験から気づいたのは、この中級者にさしかかったときの悩み、課題は（その時手を出している技術は違えども）メタでは同じ。 ということです。彼らにも、他の人、先達、同じくらいのレベル感の仲間ががいて、救われる、勇気づけられる、助けられるポイントがあると思うんです。
その「迷いを抱えながら学び続けるエンジニアを助けられる（学習速度を上げられる）コミュニティとは何なのか」それをDokugaku Dojoが抱える命題とおいて、現在活動しております。
ぜひ、Dokugaku Dojoのミートアップにお越しください！
ということで、この想いに共感してくださる方は、ぜひ私たちが主催するミートアップにお越しください :)
- 日時： 11/28（土） 午前10時スタート （所要時間：二時間）
- 場所：渋谷駅徒歩五分、グッドパッチさんのオフィスお借りします。
- ご興味ある方は、下記Facebookイベントページより、参加ボタンを押してください。
Dokugaku Dojo 第三回ミートアップ STDIN/STDOUT | Facebook
フィードバックお待ちしております！！
プログラミング独学道場 第一回ミートアップ「Hello World」を開きました。
先週末の土曜日、「プログラミング独学道場」という私たちが主催している活動の第一回ミートアップを開きました。その活動内容をここでレポートします！
レベル感問わず、独学でプログラミングを学んでいる皆様に見ていただきたいレポートです。
独学道場ってなに？
プログラミングを独学で学ぶエンジニア（エンジニア目指して修行中の方含む）たち が、自分の独学の様子を安心できるコミュニティ内でさらけ出すことで、レベル感に関わらずお互いから刺激を請け合い、結果として エンジニアという人種の探求と、好奇心ドリブンであることの幸せを追求する 。。
まぁ、変な集団です。こう書いてみると、まだまだ固まっていないなぁ、と自分でも思います。が、その分これから何が起こるのか自分たちにもよくわかりません。それが楽しいです。やみつきになりそうです。
この独学道場の取り組みはつい一ヶ月ほど前に始まったばかりなのですが、今までで口コミを中心に50人ほどの人に活動に参加してもらうことができました。
普段どんなことをしているの？
普段の活動はオンラインのもくもく会。 ビデオチャットやテキストチャットをつかって、自宅やカフェで独学するときに自分の勉強内容をみんなに逐次共有します。
人から見られている程よい緊張感と、独学内容を言語化することでペースメーカーになることが、現在の価値になっています。 これ以外にもさまざまな独学道場限定の実験的な取り組みが、ときに主催者発信で、ときに横のつながりから起きはじめています。
ただし、オンラインだけでもくもくやっているよりも やっぱり実際にあった方がより面白いことが起こせるよね、という合意があって、 晴れて先週の土曜日、第一回独学道場ミートアップ「Hello World」を開催する運びとなりました。
告知時点で参加していた道場生のほとんどにご参加いただき、30名ほどが集まるイベントとなりました。
Goodpatchさんのオフィスをお借りしました！
会場は、最近お友達になったグッドパッチさんのオフィススペースをお借りしました。本当にありがとうございます。 マイクやアンプといった音響設備があったり（！？）、会場全体にBlueToothスピーカーで音楽が流せたり、至れり尽くせりの環境でした。。他のイベントスペースへのハードルが上がってしまいそうで怖いくらい、ものすごく恵まれた会場でした。重ねて、御礼申し上げます。
午前１０時からお昼前までの健康的な会で、みなさんあまり遅れることもなく、１０時少しすぎには会場全部がちょうどよく埋まるくらいの人が集まりました。
イベントレポート本編
さて、ここからは時系列でイベントの様子をお伝えします。 最初は、主催者の私 深山 雄太（みやま ゆうた）と北郷 裕太郎（ほんごう ゆうたろう）から、独学道場の趣旨説明。
また、実は独学道場は開始当初からインターナショナルなイベントです（理由は後述）。
この日も、アメリカのボストン、ハーバード大学から参加する学生がいて、 ビデオチャットから参加する彼を紹介する時間もとりました。
日本語がどの程度伝わったのかは不明ですが、会場がその瞬間盛り上がったのは確かです笑
本イベントのねらい
それがサクッっと終わったあとは、独学道場ミートアップ本編です。 今回意識したのは、「会に来た人たちが、安心して喋る機会をできるだけ増やす」こと。
その上で必要だと思ったのは、独学の先達からの「独学の楽しさ、秘訣」のプレゼンです。 今回は、深山が会の一ヶ月前くらいに知り合った松林さんという方にお越しいただき、「いま分からないことを分かるようにするにはどうしたら良いか」「分かっている人とまだ分かっていない人のあいだはどう埋められるのか」などのテーマについてお話しいただきました。
Linux Distributionの一つであるVine Linuxを開発している Project Vineの副代表をやられており、 プログラミング学習がここまで一般的になる前から、ずっと独学でやられてきた方です。
なんと一生続いている趣味が「音楽考古学」ということで、「好きこそものの上手なれ」を体現されている方でした（著名なハッカーの方には、音楽に造詣が深い方が多い気がします）。独学の真髄は楽しむことにあり、という、独学道場へ入門される方々にとってこれ以上ないイントロダクションでした。
グループワークの時間です
その後は、いよいよ開場の皆さんにお話ししてもらうワークの時間です。
実は皆さんの話す時間を最大化するために、あらかじめこちらで「興味・関心が似通っていそうな方々」5 ~ 6人の グループをつくっておきました。 彼らが同じテーブルを囲めるように席替えをしてもらって、自己紹介+アイスブレイクの時間を軽く設けます。
そしてその後に、メインの「自分の独学体験、不満、課題、困りポイント」の共有をしてもらったのですが、ここがハイライトとなりました。 ペアになって喋ってもらったのですが、会場のボルテージは最高潮。 皆さんの顔つきがより一段と好奇心に満ちイキイキとした状態になりました。
同時に相手の話を傾聴する姿勢が生まれ、互いのややもすると「他では尋ねられない」疑問点や不満をシェアすることが、 独学道場ならではの関係性が生まれる上で最も大事な活動だと認識しました。
最後に、独学道場のこれからの施策について軽く私たち主催者から説明。
このときどうしても伝えたかったのは、 「ここは安心感をもって、安心感をお互いに与える前提でつくられたコミュニティです」ということ。
人はただでさえ、何か新しいことを学ぶときは無防備です。ましては独学でやっていれば、躓くポイントは無数にあります。
そのときに、周りにいる人からバカにされる、判断される、評価される もしくは職場のように即成果につながることを求められていたら、 私たちは学ぶことに一生懸命になれるでしょうか？
私は、なれないと思います。人は、誰しも「学ぶことにワクワクする力」「自分が変わっていくと信じる力」を持っていると私は固く信じています。 これらの力は大人になるにつれて萎むもの。それが復活するためには、安心感をもって取り組めるコミュニティ、空間が不可欠です。
これが、私が独学道場にこめるもっとも大切な願いです。
独学道場って、これから何するの？
独学道場は、今後とも エンジニア（とエンジニアを目指す人）にとって ベストなライフスタイルはなんなのか、模索していきます。
そのときに、自分がニューヨークで体験してきたプログラミングラボ（キャンプ）が原体験にあります。 正直、そのときの感動体験をどうしても再現したい、と思い、日夜この独学道場に取り組んでいるといっても過言ではありません。
そのニューヨークのプログラミングラボの説明は、過去に書いたこの記事に詳しくのせました。 ニューヨークのエンジニアコミュニティについて。Hacker Schoolでプログラミング修行中｜Okazaki Yuta｜note ご興味ある方はぜひチェックしてみてください。
独学道場ミートアップ第二回「Do Loop」開催します！
そして、最後まで記事を読んでくださった皆さんに、 次回 独学道場ミートアップ 第二回 「Do Loop」に先行申し込みできるリンクをご用意しました。
日時： 10月10日（土）午前中
場所：渋谷（会場検討中）
独学道場ミートアップ 第二回 「Do Loop」先行申込リンク
こちらも、ぶっちゃけどんな人が集まるかわかりません。 ただ一つだけ約束できるのは、きっと、あなたが今まで出会ったことがない人々が、 「プログラミングを学ぶことに情熱を燃やしている」という一点だけで集まるだろう、ということです。
ワクワクしませんか？ ぜひ独学道場と一緒に、世界を変える練習をしましょう。 皆さんのご参加、お待ちしております。
独学道場で、アルゴリズムの勉強を再開しています。
僕らが主催するプログラミング独学道場で、帰国後遠ざかっていた アルゴリズムの勉強を再開。 Manberという人が書いた「Introduction to Algorithms」の第1章の末尾、エクササイズの1.3をやった。
独学道場とは www.dokugaku.io
エクササイズ 1.3 は、訳すとこんな感じ。
「9, 44, 32, 12, 7, 42」のような順番で並ぶ数字のリストを考えてください。 このリストから、できるだけ少ない回数 数字を取り除いて、数字が大きくなる順で並ぶようなリストにしてください。
自分が唸って書いたRubyスクリプトは下記。もっと良いやり方あるよ！ って方は、ぜひぜひ！コメントください。
require 'pp'
def make_ol(list)
possible_arr = []
list.each do |n|
possible_arr.each do |arr|
i = (arr.length - 1)
while i >= 0
if arr[i] < n
arr.delete_if{ |m| m > n }
arr << n
break
end
i -= 1
end
end
possible_arr << [n]
pp possible_arr
end
possible_arr.max{ |a,b| a.length <=> b.length }
end
pp make_ol([9, 44, 32, 12, 7, 42])
