あるソフトウェア開発者の転職経験記

オランダ在住かつマーケット以上の給料をもらっているという前提条件があるので、あまり参考にならないかもしれないが、こんな感じでやったら成功したというのを一応記録しておく。

【条件設定】

転職する際にはなぜ転職したいのかを明確にしておくとゴールが設定しやすい。僕の場合は以下が大きな理由。

• 今の会社での給料が頭打ちになった
• 明確に開発者以外の方向にも行くようにと言われた
• 会社の先行きに不安があった
• 会社の変革する方向に不満があった
• 言動不一致というかこれじゃない感が漂っていた（る）
• 割とゆるい感じだったのが、締め付けられていく感もあった（る）

ここから以下の条件を設定した。

• 手取りの給料が一緒かそれ以上
• 今の会社はペンションプランがないので、それがある会社に行くと下がる可能性があった
• ある程度アジャイルな環境
• 今更フォーターフォールは嫌
• せっかく開発者なのだから、なにか目に見えるもの開発したいよね
• ある程度自由な社風
• 俺に従え的な雰囲気があると辛い（経験済）

個人的に給料の下がる転職は不可能なので、一番上が一番重要だった。下2つは正直何を言われても入ってみないと分からないというのがあるので、最低でも一つは条件を満たさないとがっかりする転職になりかねないというのもあった。

【応募】

応募するのは基本以下の3つの経路があると思っている。

• エージェント経由
• コーポレートリクルーター経由（会社お抱えのリクルータ−）
• 自前

エージェント経由は便利だが正直あまり良いイメージがない。理由は概ね以下

• 興味があると言ったものと別のものを出してくる
• 広告用の募集要項なんだそうだ
• 必ず電話で話したいと言い出す
• そんな時間ない（業務時間外でもOKという融通の効くところもある）
• 希望する給料をいうと第一声が「下げられないか？」である
• 高いのはわかっているが無理なものは無理だ
• 転職後一年もするとまた電話してくる

上記が問題にならないのであれば、便利だと思う。履歴書のスクリーニングで落ちる可能性が格段に低くなるのもよい。

コーポレートリクルーターはコンタクトを取ってきたエージェントが希望する会社の人であれば一番よい。LinkedInやIndeed経由でメールが飛んでくるので気になる会社であれば返事をするのがいいだろう。

自前は茨の道であることは否めない。かなりの確率で履歴書のスクリーニングを通過できない。頑張ってカバーレターを書いたのに涙を飲むというのもままある。っが、希望する職にダイレクトに応募できるというメリットもあるので、鉄の心臓を持っている、時間的に余裕がある等頑張れる要因があるのであればこの道を取ってみてもいいかもしれない（ちなみに今回の転職はこれだった）。

【面接】

履歴書のスクリーニングを通過すると面接がある。会社によっては電話だったりスカイプだったりするが、そこまでの大差はない。いきなり課題を出す会社もあるが、プロセスの一環なので気にしない。昔から面接では苦労した記憶がないので、ここまで来るとオファーがもらえる確率が50％くらいという気持ちになる。面接では大抵以下のことが聞かれるので、適当に納得できそうなものを用意しておくといい：

• 自己紹介（経歴等）
• なぜ転職するのか
• 自慢したい直近の成果

相手の会社について事前に調べる必要があったことはない。ほぼ100％面接の場で事業内容等を説明してくれる。質問があれば都度すればよいし、多分した方がよいと思われる。テクニカルな面接でない場合はコミュニケーション能力を計っている場合が主なので、無言の方が印象が悪いと思われる。（知らない単語が出てきたら、「なにそれ？」くらいの質問でいい気がする）

プロセスは前後することがあるが、面接の後は大抵課題が与えられる。課題は経験上以下の2種類がある：

• 面接官付きの短期決戦型
• お題が与えられる長期戦型

これらは見られているものが違うので注意しないと行けない。短期決戦型の課題はアルゴリズムに対する知識が問われるのが主なので、以下のトピックを習熟しておけば怖くない：

• グラフ操作（BFS、DFS等）
• ソート
• 探索
• ビッグ・オー記法

大抵の場合は上記の組み合わせまたは変形でなんとかなる。普段からHackerRank辺りで遊んでいるといいかもしれない。面接者は（おそらく）実際のコーディングの様子、問題解決のプロセス等を見ているので、思考を口に出すと割と喜ばれる。

長期戦型はあるトピックに対してのフルアプリを作成することが多い。短期決戦型と違って何が出てくるのか予測がつかないが、大抵4時間から1日くらい費やせば完了する程度の規模なので、週末を使ってじっくり取り組めば問題ない。短期決戦型と違い、デザイン、データ等実践的な解決を見られるので妥協しないで頑張った方がよい。（テストカバレッジ100％とか含む）

課題を無事通過すると、第2面接か、次の交渉のステージになる。第2面接は大抵課題の解決方法の理由を聞かれたりする。真面目に取り組んでいれば問題なく答えられるはず。

【交渉】

ここまでを無事通過するとサラリーの交渉になる。エージェントを経由する場合はこのステップはエージェント経由になるので、直には経験しないかもしれない。

人によっては現在の年収等を聞かれるのは好きではないかもしれないが、馬鹿正直に答える必要はない、自分が望む額を適当に言えばよいのである（今回ペイスリップを求められたが断った）。そうは言ってもあまり高すぎると向こうの予算オーバーになるので、適当に調節する必要はある。今回は現在の月収＋€200くらいで答えたりした（前々回が＋€400で前回は＋€700だったかな、今回は今の会社を早く去りたかったというのもある）。基本的にここは交渉の場なので、向こうがそれでは高すぎると判断すれば下げられないか聞いてくる。もちろん、下げる必要はないし、ダメならオファーが来ないだけである。交渉の余地がない場合もあるので、その場合は金額と仕事内容で判断すればよい。僕は気長にやれば希望金額より上を出す会社もあるということを知っているので、大抵断ったけど。

交渉がまとまれば晴れて契約。ちなみに、ここまでは現在の会社に内緒で行う必要がる。契約書にサインしたら辞意を伝えればよい。

【その他】

ここからはオランダのソフトウェア開発者市場のみに当てはまるものの可能性があるので、あまり参考にならないかもしれない。

【職種】
今回の転職活動でSI/コンサル系の大手からもオファーをもらったのだが、えらくしょぼかった。もし次があった場合はSI/コンサル系は外した方がいいだろう。元々好きでもないし。そう言えば、あの会社は課題的なのなかったな。あんまり技術を売っていないのかもしれない…

【大手ホテル予約会社】
向こうから連絡してきて、アポ取れと言われたので取ったのだがシカト食らった。なんだったんだろう？（単なる愚痴）

【向こうの予算】
オランダはよくソフトウェア開発者不足と聞くが、給料はあまり高くない気がする。リクルーターに現在の年収を伝えると次から大抵連絡が来なくなるという現象が多発した（コーポレートリクルーターなら予算外と言われたり）。

まとまらなくなってきたので終わり。

ライブラリの依存性

Scheme でライブラリを書いていると巨大なファイルになることがままある。最近だとこのファイル。まだ未完成なのだが既に1000行近くある(まだ1000行とも言えるが、個人的にファイル内の移動が既に辛い)。辛いなら分ければいいじゃない？という話なのだが、怠け者根性と分け方で迷っているというのの2つがあって今のところ放置している。

ライブラリを複数のサブライブラリに分ける際に大抵以下の2種類のパターンで迷う：

1. 機能ごとに分ける(例：型、手続き、etc.)
2. オブジェクト指向的に分ける

個人的にどちらが優れているという気はないし、ケースバイケース(その時の気分ともいう)で違う分け方をしている。今回は2の方向で分けたいと思っているのだが、これだと不都合がでる。ライブラリの循環だ。

今作っているライブラリはXMLのDOMを扱うものなのだが(最終的にどこまでサポートするかは不明)、DOMにはquerySelectorなる手続きがある。これはParentNodeで定義されているが、このインターフェースはDocument、DocumentFragment及びElementで実装されている。CLOSを使っていないので、これらは別々に実装される必要があって、どう実装するかは考えてないんだけど、3つの似たりよったりな手続きが実装されることになると思われる。そうすると、この手続きはどこか別の場所に分けたいのだが、ライブラリをオブジェクト指向的に分けるとこんな感じになって、循環する：

• Elementライブラリ： Selectorライブラリが必要
• Documentライブラリ： Selectorライブラリが必要
• DocumentFragmentライブラリ： Selectorライブラリが必要
• Selectorライブラリ： Elementライブラリが最低必要

 （Selectorライブラリに分けたいのはこいつが別仕様だからだったりする。）

こういう時は機能毎に分ければうまく行くんだけど、なんだかなぁという気がしていて、う〜ん。ライブラリの遅延ロードみたいなのを導入して循環参照を許してもいいんだけど、それもなぁ的な。Schemeのライブラリは生まれて日が浅い（と言っても既に数年経っているが）ので、こういう場合のベストプラクティス的なものはないし(Scheme的にはこういうケースでベストプラクティスが必要なのって言語仕様的にどうよってなる気もしないでもないがどうなの？)、さてどうしようかね…