30代半ばフロントエンドエンジニア、テクニカルディレクターの転職活動について

転職をした訳だが、想像以上に苦労したのでその旨、誰かの役に立つかもしれないと思って Web 上に記録しておきたい。

当方、Web 制作会社に9年間勤めたフロントエンドエンジニア兼テクニカルディレクターである。年齢は30代半ば。受託案件ではなく、自社サービスやプロダクトの開発がやりたくて転職を決意する。

2017年4月、退職を上司に宣言した上で転職活動を始めた。 6月に現職業務終了、7〜8月に有休消化して退職、8月中旬に新環境で就業、という予定を建てていた。

まずはエージェントなどに頼らず、自分自身の力で転職活動を経験してみたいと思ったので、求人サービスにプロフィール登録してみた。 結果的に Wantedlypaizapasonatechgreen を利用。

  • 実働の割合的にはほぼ Wantedly 経由でのスカウトや応募だった。実働は会社訪問6件、面接2件
  • paiza はサーバーサイドの仕事が多くほぼ自分とマッチしなかったが、実働は面接4件
  • green は最低限のプロフィールだけ登録して一晩置いたら、匿名スカウトが何通も届いていたのでうんざりして使うのをやめた。よって実働なし。ロクにプロフィールを書いてもいないのに、スカウトをよこす人事って一体…。下手な鉄砲も数打ちゃ当たるという感じ?
  • pasonatech は10年前くらいに派遣社員をやっていたときにお世話になっていた派遣会社。サービス内の検索でヒットした求人に条件に合うものがほぼなかったので、応募はしなかった。よって実働なし

転職先の希望条件について

転職先について、以下のような希望があった。

事業面

  • 自社サービスやプロダクトを活発に運営している
  • 会社が目指すべき明瞭なビジョンがある
  • 新規事業に対して積極的
  • 娯楽事業(ゲーム、映画、音楽、ギャンブルなど)とマッチング事業は、やりがいを感じられそうにないので避けたい
  • デザイナーが社内にいる
  • 極力制作を外注に出さない
  • 正社員が30人以上いる

文化・生活面

  • スーツで出勤しなくていい
  • できれば朝早く出勤しなくていい
  • できればオフィスがダサくない
  • できればパーティーとか社員旅行とか煩わしいイベントが多くない

待遇面

  • 年収が現在より下がらない
  • 一般的な福利厚生がある

活動概況

Wantedly、paiza、green ではプロフィール登録すると、すぐに何件かスカウトメッセージをもらった。まずまずの手応えを感じつつ会社訪問に行く。

正直、転職先のイメージなんて曖昧なものでしかなかった。何せ9年間、同じ会社に勤めていたのだから。軽く浦島太郎のような感覚であった。 実際にそのような会社に訪れ、担当の方と何人もお話をすることによって、どんどんと外界の様子が分かってきて、自分のしたいこと、したくないこと、企業の求めることが明確になっていくのを感じた。履歴書や職務経歴書などのレジュメも、そのフィードバックにより徐々に改善した…はずだと思う。

マッチングの難しさ

スカウトされたので面接に行くがマッチングしない、もしくは落選となる、ということはよくあった。(期待外れの人材でどうもすいません…)

マッチングしない原因としては以下のようなことが考えられた。

  • 活動初期は自分の求める転職先のイメージが不明瞭であったが故、希望する事業内容と異なった企業にも話を聞きに行ってしまっていた
  • 期待されるポジションが自分の希望する内容ではなかったので、違うポジションを希望したが聞き入れられなかった
  • 担当者と明らかにウマが合わなかった(高圧的な担当者だった)
  • 企業側が期待するスキルと、僕のスキルセットが違っていた。なのになぜかスカウトされているという状況
  • 企業側の想定年収と、こちらの希望年収が合わない。

面接落選となるケースの原因はというと。

  • 登録プロフィールが不十分だった?(実際にお会いすると魅力を感じてもらえなかった様子)
  • 活動初期は面接の要領が悪く、自己 PR が上手くできていなかった。スカウトされているが故、「選考されている立場」を自分がよく理解していなかった
  • 技術試験に落選した(スキルセットのミスマッチ)

ちなみに、こちらからお断りしたケースは以下のようなものがある。

  • 求人サービスの説明に書いてあることと、実態が異なっていた
  • 担当者が不誠実だった(当日約束の時間に現れなかった)
  • 実際に話を聞いてみると、事業内容がとても不安定に感じられた

年収については年齢や人生のフェーズとも関連している。例えば今の僕が新卒社員並みの年収で働けるかというと、答えはもちろんNOだ。これは期待されるスキルや職務内容とももちろん絡み合っていて「その年収を希望するなら(その年齢なら)これくらいはスキルがないと」ということになる。

こういったミスマッチが生まれる原因の根本にはもちろん自分の至らなさがあるが、それを前提として別の原因の一つとして、採用担当者がプロフィールをよく見てくれていない、と感じることが多数あった。

求人サービス側で気軽にスカウトができるシステムになっているので仕方がない面もあるが、スカウトするからにはそれなりに責任を持ってしてほしいと思った次第。また paiza では、スカウトを辞退しても、また同じ会社からスカウトが届くことが何回かあった。辞退された人に再び送れるようになっているシステムも問題かと思った。

paiza ではサービス上でスキルチェック問題を解くことによって自分のランクが決定し、そのランクに合わせて企業からスカウトしてもらえる、という仕組み。僕はフロントエンドエンジニアなので Node.js で全ての問題を解いていた。だが、スカウトされる案件がほぼ PHP でのスカウトだった。確かに PHP の経験年数は登録しているけど…。それがウリじゃない、というところで勝負しなければならなかったという、なんというか不幸。

今時のWebサービスでは Node.js って需要なさそう、と思ってしまった。ちなみに求人の件数は Ruby on Rails エンジニアが一番という印象。猫も杓子も Ruby on Raild。ウーム…。

マッチングの話とはあまり関係ないが、スカウト後の面接で結果が出るまで1ヶ月くらい待たされて、結果は落選、というケースがあった。自分勝手で失礼な企業だと思った。すいません、これは愚痴だな。

技術試験について

数社では技術試験が課されたが、その内容の難しさに心を折られそうになる。 本当に優秀な人しか取りたくないのだ。企業側も真剣である。

ある1社のものは特定の日時にメールで課題が送られてきて、3時間後までに回答を返信せよ、というものだった。 論述問題を3問と、プログラミング問題2〜3問。ほぼサーバーサイドエンジニア向けの問題で、自分に馴染みのないものだったが…、技術問題は Node.js でどうにか回答。 案の定、力不足でこれは落選となった。

別のある1社のものはフレームワークごとプロジェクトファイルと SQL データが送られてきて、これこれこういうビジネスロジックを構築せよ、というものだった。 回答期限は一週間後くらいだったので、週末を使って問題を解く。自分がある程度知っている PHP フレームワークだったので、回答することはできたが…。SQL に明るくないという自分の弱点が浮き彫りになり、これも落選。 こちらの会社では落選の通知の際に、ダメなポイントを全てコメントして教えてくれた。なんと誠実な採点担当者だろうか。ありがとうございました。

それにしても「試験に落ちる」のはやっぱり凹むのである。

とはいえ自分の弱点が端的に理解できるし、企業が求めている人材は「こういうことができる人」ということもダイレクトに理解できた。なんとも学びの多い経験であった。


あとがき

結果的に求人サービスとは違った繋がりでご縁があり、転職先は決まった。(前のエントリーでご報告した通り

なぜここまで苦労する必要があったのか、とも思う。エージェントに相談に乗ってもらったり、知人のツテを頼るなど、他にいくらでもやり方はあったはず。

おそらく自分は転職という人生の転機を他人に委ねるのではなく、「自分にできること十分にやる、やった」という納得感が欲しかったのだろうと思う。また、転職活動を進めていくうちに、どんどん慣れて上手になっていくというか、自分が上達していくことが楽しさを感じていたということもある。面接にしても、レジュメ制作にしても、やればやるほど上手くできるようになる。

ただ、結果が出るかどうかはまた別の話であった。どんなに面接が上手くできても技術試験で落ちたり、事業内容が自分の希望と違ったり…、と色々あった。

転職とは最終的にはその企業や担当者とのご縁であると、そう締めくくりたい。

転職しました

2017年8月10日付けで株式会社ラナデザインアソシエイツを退職し、株式会社FIXERに入社します。


実際には最終出社日が6月末で、一ヶ月余りは有休消化期間を過ごしたことになる。
社会人になってこの方、これだけの長期休暇を過ごすのは初めて。

のんびり…というわけでもなく、ちまちまとやりたいことをやっていたら一ヶ月なんてアッという間に過ぎていった。同居人がいつも通り仕事をしていたこともあって、生活リズムが乱れることもなかった。

普段なら後回しにしてしまうようなこと、例えば大きい買い物をしたり。パソコンとか家具とか沖縄への旅行とか…ここ一ヶ月、散財したなあ。

MacBook Pro 2017

7月初頭には石垣島へ旅行に行ってきた。(冒頭の写真も石垣島にて撮影)
沖縄を訪れるのは初体験!
離島巡りをして、竹富島、西表島も訪れることができた。

Taketomi Island

天気は大変良かったし、まだ学生の夏休み期間でもなかったので混んでいるわけでもなく、快適な旅行だった。 しかしともかくも暑くてバテたし、日焼けもした。観光ガイドさん曰く、紫外線は本土の何倍もあるのだとか。果たして本当(ほんど)かな?なんつって…


閑話休題。

転職の背景

サービスやプロダクトのチーム開発をやりたい、というのが端的な理由。特に受託案件ではなく、自社サービスの開発がやりたくなったから。

前職の在職期間は約9年。そのうち5年は RANAGRAM というチームに在籍していた。意思さえあればいくらでも挑戦ができる環境であったが、その想いをうまく形にすることはできなかった。自分の力不足であったと思う。

足りなかったのはアイディアなのか、技術力なのか、情熱なのか、行動力なのか、何だかわからないが、「自分はそこまでクリエイティブな人間ではない」と理解しておくことにしたい。ただ、自分の力を過大評価していたことは間違いない。今思えば、もがかずに早めに見切りをつけて、うまく泳げる環境に移ってもよかったのかも。

前職の最後の一年程はWebディレクターとしても活動しており、「社内一人制作会社」を目指して仕事をしていた。グラフィックデザインこそ専門外だが、お客さんに会って要件定義するところから実装して成果物を納めるところまで一貫して関わっていたので、ピンでやっている感覚が強かったかもしれない。本当は独立してフリーになることを考えていたのだが、「この状態はフリーとあまり変わらないのでは?」と思ってもいた。

そんな中、ピンで仕事をすることがふと寂しくなった、ということもあってフリーにはならずに会社を移ることにした。「チームで働きたい」という想いがあった。

株式会社FIXERに入社を決めたのは、もともとの知人である関係者にタイミングよく、直接声をかけていただいたため。

転職活動がうまくいかず、行き詰まりかけていたとき、たまたま「こういう案件があるので仕事を頼みたい」とお声かけいただいたのだが、「実は退職することになっているのでお受けできそうにありません」とお返事したら、「だったらウチで仕事しないか」ということになりトントン拍子に入社が決まった。

主にクラウドプラットフォームのベンダーをしている会社で(例えばこんなことをしている)、自社サービスの開発も精力的に行っている。フロントエンドにはあまり強くないとのことで、しばらく孤軍奮闘することになる予感…、ではあるが裏を返せばそれだけやりがいのある職場となるだろう。

そんなことがあって、「求めるより求められる」方が人間幸せだよなあ…としみじみ感じる今日この頃である。

P.S.
転職活動については、他人の参考になればこれ幸い…と思って別のエントリーとしてまとめる予定。 → 書きました。(2017年8月12日追記)

MacBook Pro (13-inch) を購入

自宅では長らく MacBook Air (13-inch, Mid 2011) を使用してきたのだけれど、かなりくたびれていて作業するに耐えない状態なので新しい Mac を買うことにした。 購入したのは以下のスペックの MacBook Pro (13-inch)

  • Touch Bar なし
  • 第7世代の2.3GHzデュアルコアIntel Core i5プロセッサ(Turbo Boost使用時最大3.6GHz)
  • Intel Iris Plus Graphics 640
  • 16GB 2,133MHz LPDDR3メモリ
  • 512GB SSDストレージ
  • バックライトキーボード – 英語(US)

本当は旧世代の整備済み製品を買おうとしていたのだけど、US キーボードの製品をほとんど見かけなかったので、諦めて新品を買うことにしたのだ。会社で使っていたマシンが US キーボードだったので、もう US 配列しか手が受け付けなくなってしまったので…。

スペックをカスタマイズすると受注生産になるらしく、配送予定日が遅くなるようだ。(出荷まで2〜3営業日、配送に2〜3日はかかった)なお、今回は上海からの配送になっていた。

早速設定していく。 電源を入れてウィザードに従って設定を進める。以下は一部抜粋。

  • FileVault は ON
  • iCloud アカウントを利用したログインパスワードの変更は可。同じく FileVault のロック解除に iCloud アカウントを使用

OSが起動したらば、まず「設定 > キーボード」でキーボード周りの設定を自分好みにする。

  • 「キーボード > キーのリピート」 → 最速に
  • 「キーボード > リピート入力認識までの時間」→ 一番短く
  • 「キーボード 」 → 「F1、F2などのキーを標準のファンクションキーとして使用」にチェック
  • 「キーボード > 修飾キー」→ Caps Lock と Control を入れ替え
  • 「ショートカット > フルキーボードアクセス」 → 「すべてのコントロール」にチェック
  • 「ショートカット > Mission Control > 通知センターを表示」 → 「Shift + Control + →」に設定
  • 「ショートカット > 入力ソース > 前の入力ソースを選択」 → 「Command + Space」に設定
  • 「ショートカット > 入力ソース > 次の入力ソースを選択」 → チェックを外す
  • 「ショートカット > Spotlight > Spotlight検索を表示」 → 「Option + Command + Space」に設定
  • 「ショートカット > Spotlight > Finderの検索ウィンドウを表示」 → チェックを外す
  • 「入力ソース > 日本語」 → 「ひらがな」と「英字」だけ残してチェックを外す
  • 「入力ソース > “/“で入力する文字」 → 「/(スラッシュ)」
  • 「入力ソース > “¥”で入力する文字」 → 「\(バックスラッシュ)」

「設定 > セキュリティーとプライバシー > ファイアウォール」 → 「ファイアウォールを入にする」

「設定 > Dock」では「Dockを自動的に隠す/表示」にチェックを入れる。

「設定 > 共有」では「コンピューター名」を見られても恥ずかしくない名前にしておく。

「設定 > ユーザーとグループ」では「変更するにはカギをクリック」した後、左サイドバーに表示されているユーザーを副ボタンクリックし「詳細オプション」を選択すると、アカウント名などを変更することができる。初回起動時のウィザードで設定したものをやっぱり修正したくなったらここで直す。

ソフトウェアのインストール

以下は App Store からインストール

  • Keynote
  • Pages
  • Xcode
  • Byword
  • Transmit
  • Popclip
  • Pixelmator
  • Logic Pro
  • WinArchiver Lite

Xcode 設定

  • 起動すると License Agreement が表示されるので「Agree」をクリックするとコンポーネント(Command Line Tools など?)がインストールされる

Alfred 設定

  • 「General」 → Launch After at Login」にチェック
  • 「General > Alfred Hotkey」 → 「Control + Shift + Space」
  • 「Features > Dictionary > Define a word」 → 「d」

以下は要 Powerpack

  • 「Features > Clipboard > Clipboard History 」 → 「Keep Plain Text」にチェック
  • 「Features > Clipboard > Viewer Hotkey 」 → 「Control + Shift + Command + Space」

iTerm2 設定

  • 「Profiles > Default > Window > Columns」 → 100
  • 「Profiles > Default > Window > Rows」 → 50
  • 「Profiles > Default > Window > Transparency」 → Transparent 側に10%くらい動かす

Git 設定

$ git config --global user.name "Naoki Sekiguchi"
$ git config --global user.email web@likealunatic.jp
$ git config --global alias.st status
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global core.excludesfile ~/.gitignore

GitHub と SSH 通信できるようにする。

$ ssh-keygen -t rsa -b 4096 -C “web@likealunatic.jp”
Enter file in which to save the key (/Users/naokis/.ssh/id_rsa): [空のまま Enter]
Enter passphrase (empty for no passphrase): [空のまま Enter]
Enter same passphrase again: [空のまま Enter]
$ pbcopy < ~/.ssh/id_rsa.pub

クリップボードに公開鍵の中身がコピーされた状態になるので、GitHub にアクセスして「Settings > SSH and GPG keys > New SSH key」と進んで内容をペーストし「Add SSH key」をクリック。

接続をチェック。

$ ssh -T git@github.com

Vim, Bash 設定

自分用の dotfiles レポジトリからごっそり設定を落とす。

$ git clone git@github.com:seckie/dotfiles.git ~/dotfiles
$ ln -s ~/dotfiles/.vim ~/.vim
$ ln -s ~/dotfiles/.vimrc ~/.vimrc
$ ln -s ~/dotfiles/.gvimrc ~/.gvimrc
$ ln -s ~/dotfiles/.gitignore ~/.gitignore
$ ln -s ~/dotfiles/.bash_profile ~/.bash_profile

Vim プラグインを入れる

$ curl https://raw.githubusercontent.com/Shougo/dein.vim/master/bin/installer.sh > installer.sh
$ sh ./installer.sh ~/dotfiles/.vim/dein

Vim を起動して以下を実行

:call dein#install()

フォントに VL ゴシック を利用したいので、それもインストールしておく。

その他 CLI でインストールするもの

Node.js は Nodebrew からインストールする。 とりあえず最新版を入れておく。

$ nodebrew ls-remote
$ nodebrew install-binary v8.1.4
$ nodebrew use v8.1.4

初期設定は以上。あとは随時必要に応じて運用していく。

SketchLogic Pro X を購入したいところだが、タイミングを失っている状態。さてどうしようか。

Let’s Encrypt でサイトの SSL 化

Let’s Entrypt という素晴らしいサービスが無料のSSL証明書が提供していると同僚に教えてもらったので、試しにこのサイトに導入することにしました。
このエントリーは導入過程のメモです。

Let’s Encrypt は Certbot というコマンドラインインターフェースを持っていて、証明書の取得とインストール、更新までコマンドでできるようになっているとのこと。なんとまあ便利ですね。

証明書の有効期限は90日間しかないので、crontab などで有効期限前に自動で更新していく運用が望ましいみたいです。ではそうしていきましょう。

事前に以下の準備をしておきます。

  • Really Simple SSL プラグインを WordPress にインストールしておく
  • ファイヤーウォールがあるならインバウンド 443 ポートを開けておく

また、環境としてはさくらのVPS(CentOS 6)で Nginx + WordPress を動かしている状態です。

証明書のインストールとWebサーバーの設定

サーバーに SSH でログインして、作業開始。
certbot-auto スクリプトをダウンロードして、 /usr/bin に移動、実行権限をつけて、実行。ウェブサーバーは Nginx なので、--nginx オプションをつける。

$ wget https://dl.eff.org/certbot-auto
$ sudo mv ./certbot-auto /usr/bin/certbot-auto
$ sudo chmod a+x /usr/bin/certbot-auto
$ sudo certbot-auto --nginx

これでインストールウィザードが始まる。 以下のくだりでは「2」と答えておくと、Nginx 設定ファイルにリダイレクトの設定を勝手に書き込んでくれる。

Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------

設定を反映させる。

$ sudo service nginx reload

この状態でもうすでにSSL化はできていた。https でサイトにアクセスしてみると以下のような状況。

SSL証明書を表示確認しているところ

http 接続を https 接続に強制リダイレクトをかける。
certbot-auto が /etc/nginx/conf.d/default.conf に設定を書き込んでいるが、コメントアウトされているのでそれを外して有効にする。

     # Redirect non-https traffic to https
-    # if ($scheme != "https") {
-    #     return 301 https://$host$request_uri;
-    # } # managed by Certbot
+    if ($scheme != "https") {
+        return 301 https://$host$request_uri;
+    } # managed by Certbot

設定を反映させる。

$ sudo service nginx reload

最後に自動更新の設定。
毎週日曜日の5時に更新処理が走るように設定した例。

$ sudo crontab -e

0 5 * * 0 certbot-auto renew --post-hook "service nginx reload" >/dev/null 2>&1

Really Simple SSL プラグインを使う

インストールしてアクティベートすると以下のようなメッセージが表示される。

Relly Simple SSL Plugin

「Go ahead, activate SSL!」ボタンを押す。すると以下のようなメッセージが表示される。

SSL activated!  Don't forget to change your settings in Google Analytics en Webmaster tools.  More info.

えっと…、本当に簡単だな…。
Google Analytics と Webmaster tools の面倒も見ろとな。あとでね。

以上です。


P.S.

URLが変わるので、はてブ数などはリセットされてしまいます。まぁそれはそうだわな。
本文「likealunatic.jp」を検索 - はてなブックマーク


References

webpack にまつわるぐだぐだ。キャッシュ対策と CommonsChunkPlugin

webpack (version 2) の公式ドキュメントではバンドルファイルのブラウザキャッシュ対策として、ファイル名にハッシュ値を埋め込む方法が提案されている

こうするとアプリのコードを変更する度に、バンドルファイル名に埋め込まれたハッシュ値も更新され、ブラウザキャッシュ対策ができる、という寸法だが…。
当然ファイル名が変わるわけだから、<sript> タグも更新しなくてはならない。それを解決するには、HTML ファイルも動的に扱わなければならない。chunk-manifest-webpack-pluginhtml-webpack-plugin を導入し、HTML のテンプレーティングを行い…、となると今使っている Pug はどうなる…、となってさらにさらに掘り下げないといけなくなり、はっきり言ってソリューションとして無理がある。

閑話休題。

webpack をヘビーに使っていると、サードパーティーフレームワークやライブラリのコード(npm install でインストールしたようなモジュール)を出力ファイル(バンドルファイル)から切り離したくなる。 バンドルファイルにライブラリが直接含まれるが故に、以下のような事象に直面したことがある開発者は多いのではないだろうか。

  • 複数人で開発していて各自のライブラリのバージョンが微妙に異なり、Git経由でやり取りされるバンドルファイルに環境の差分までが含まれてしまう
  • 使っているライブラリが増えて、コンパイルがとても遅くなる

解決策として、フレームワークやライブラリはまとめて別のバンドルファイルにする、もしくは単独で配布されたものを <script> タグを読み込む、という解決方法を取ることもできる。 これを可能にするのが externals オプションで、ここで宣言された名前については、依存関係がグローバルスコープから参照されるようになる。

externals: {
  jquery: 'jQuery'
}

webpack.config.js に設定しておくと、 import jQuery from 'jquery'; というコードはグローバルスコープの jQuery を参照するようになり、バンドルファイルに jQuery のコードは含まれないようになる。 もちろんこの場合には jQuery は新たに別の <script> タグで読み込む必要ある。

よりスマートな解決策としての CommonsChunkPlugin

CommonsChunkPlugin を使うと、複数のバンドルファイルから共通の依存モジュールを切り出してくれる。 サードパーティーライブラリをアプリのコードと分割する、という使い方ももちろんできる。 公式で示されている設定は以下のようなものだ。

plugins: [
  new webpack.optimize.CommonsChunkPlugin({
    name: "vendor",
    minChunks: function(module){
      // node_modules のディレクトリ下に含まれるものだけに絞る
      return module.context && module.context.indexOf("node_modules") !== -1;
    }
  }),
  new webpack.optimize.CommonsChunkPlugin({
    name: "manifest", // 名前は "manifest" でないとダメ
    minChunks: Infinity // entryがいくつあろうと生成。省略可
  }),
]

サードパーティーコードを別にしたいだけなら vendor だけでも目的は果たせるが、manifest を入れると、webpack バンドル共通部分(ソースには webpackBootstrap とコメントが書かれている部分)が manifest.js として別ファイルに書き出される。こうするとビルドするたびに vendor のハッシュ値が変更されることを防げるとのこと。
でもこれ、先述のハッシュ値をファイル名に含めるキャッシュ対策をやっていないと、意味はなさそう。なぜならハッシュ値はバンドルファイルのコード内には現れないから。

manifest を定義した場合、以下のように manifest.js も読み込まないとコードは動かないので注意。

<script src="/js/manifest.js"></script>
<script src="/js/vendor.js"></script>
<script src="/js/bundle.js"></script>

References