読者です 読者をやめる 読者になる 読者になる

職業選択の自由

職業を選択するまでの過程。

就職活動と転職活動のココが違う3つのポイント

「面接なんて来なければいいのに」

と、何度思ったことか。

「月曜日なんて来なければいいのに」

と、どちらが多いか。

このブログでは「転職活動」をテーマに今までの行動や具体的な質問を振り返ってきたが、この時点でどうしても自分の心理について吐露しておきたい。そもそもこのブログは、140文字では収まらない転職活動へ思うところを吐き出して精神の安定を保つ目的で始めた。いつかテーマにしようとは思っていたことだが、大きな転機になるであろう面接を控えたこのタイミングで一旦整理をつけておきたくなった。

転職活動は今まで経験したことのない戦いだと、体験してみて改めて感じた。就職先を探すという意味では学生の就職活動と共通する要素もあるが、基本となる軸が大きく違う。そこが転職活動の最も辛い部分である。今回は自分自身への反省と今後の誰かに向けて、新卒の就職活動と社会人の転職活動の違いをポイントを絞って述べていく。

基本的に「隠し事」である

就職活動中の学生には同級生という仲間がいる。「土曜日なのに合同説明会か〜」「今度◯◯の面接なんだ!」「エントリーシート適当に書いたら通ったwwww」など他愛もない会話ができる仲間がいる。

しかし転職活動はその時の勤務先には秘密にしておかなければならない。「こいつは辞めようとしている」とでも思われたら仕事に支障をきたすどころではない悪影響がある。面接に向かう際も、本当の理由を伏せて定時退社したり有給休暇を取ったりしなければならない。ちなみに俺は独身であることを利用して、仲のいい女性との約束がある風を装うことがたまにある(当然ながらそんな人はいない)。

時間換算で半分以上を過ごす職場において、致命的な隠し事がある。この状況は少なからずストレスである。これに耐えられるかがまず第一の関門である。

開始時期を決めるところから戦略である

経団連が発表する採用活動開始時期が度々話題になるが、これはある意味で「いつ就職活動を始めればよいか」を考えなくて済むようになる優秀な仕組みである。学生側は定期テストや受験と同じ感覚で就職活動を始められる(※)し、採用側もある程度どんな学生がくるか予測できるので、就職先マッチングという意味では一定の成功を収めていると考える。

しかし、転職活動には当然ながらそれがない。会社に長くいた経験がかえって不利に働くこともある。かといって若くして準備期間が長ければ通りやすくはならない。要するに正解などない。重要となるのが、今の自分の条件を冷静に判断する分析力、それを考慮して転職先を見極める洞察力、そしてそれに役立つ情報を持ち自分の味方となる人を見つけるコミュニケーション能力である。いつ、何をして、何を以って、どのように、どこを志望するか。すべてが戦略である。

※こう書くと「仕事と進学は全然別だ」とお叱りを受けるかもしれない。しかし、「いつ」「何を」すべきか固定しているという点で、就活は転職活動より受験に近い存在だと今の自分なら判断する。

即戦力しか求められていない

「即戦力」なんて就活業界でも聞き飽きた単語だが、なんだかんだいって新卒を取る会社は教育を施す余裕がある。自分の会社は入社から3ヶ月は新人研修期間だった。これで最低限のJavaだったりSQLだったりプロマネだったりの知識を叩き込んでから現場に送り出すわけである。そして現場に送られてからも先輩や上司のフォロー制度が基本的にある。

それに対して、特に自分が志望しているITベンチャーは、面接からして「いかに技術を持っているか」が最優先で問われる。入社してからの教育制度は知る由もないが、面接で話を聞く限りは「現場のソースコードを触れさせる」もしくは「退勤後に自習する」が大部分だ。研修というのは大企業用語なのかもしれない。

ただ、その会社で主に使っている技術の経験が浅くても、それまでの活動を評価してくれる会社も中にはある。根本的に違うのは、「教えてもらう」か「学びにいく」か。自分が今までしたこと、持っている知識を主張することで、いかに「素早く役に立てるか」アピールするのが面接における最大の戦略かもしれない。

おわりに

仕事が忙しく気分が落ち込んでいた頃は、「なんでこんな会社入ったんだろう」と後悔しかしなかったもんだ。しかし、面接を通じてある程度アピールできる鉄板ネタを持っていることに気づき、案外遅すぎなかったのかもと思えるようになってきた。いろんな意味で、自分の今までを反省する機会になったはずだ。

ま、何を言っても朝が来れば仕事に行くし、明後日は有給取って面接に行く。転職活動もまた、気持ちの切り替えが大事である。

個人用メモ: 面接対策

2次面接の日程が決まった。泣いても笑ってもこれで最後だという。しかも2時間を予定されている。面接まではまだ数日あるが、今から緊張で体の不調を感じるほどだ。この俺がこんな緊張することがあるとは。会社で先輩と話す時もLTで大勢の前で話す時も図太かった俺が。

少しでも安心するため、エージェントの方から教えて貰った想定質問集の回答を箇条書きで用意してみる。多分コピペだろうが、中には実際に用意しておいたほうがいいと感じたものも多かったので回答した。技術的な知識を確認する質問や相手のサービスそのものに関する質問は調べながら書いたため、結構時間がかかった。勉強会のネタとしては意外にふさわしかったのではないか。(土曜のもくもく会を利用して記事を書いた)

一部、内容が重複していたり、相手の企業名が直接書いてあったりしたので、そこは編集した。また、「退職してから何をしていたか」など明らかに条件に該当しない質問も削除した。

  • 志望動機
    • エンジニアとしてプログラムに触れる機会を増やす
    • Rails, JavaScriptなどの最新技術を勉強できそう
    • 自分のエンジニアとしての価値を試したい
  • 転職理由
    • 今の会社での業務が書類作成や打ち合わせの実施に時間を取られコーディングをあまりせず、また今後人員や費用の調整が多くなってくるためエンジニアとしてのキャリアに不安を感じた
    • プログラムを変更するのに顧客の承認が必要であったり、付随するドキュメントが数多く必要であったり、またテスト作業を人手で行うべきというプロジェクトの方針に不自由さを感じた
  • やりたいこと
    • プログラマとして機能の開発や改善に携わりたい
    • 最新技術を勉強したい
    • タスク管理や雰囲気作りなど、マネジメントの方向でも貢献したい
  • 周りから自分のここが認めらなかったと思うこと
    • プログラムの改善提案をしても、テストが大変になるだったり承認が必須だったり機能に不足はないだったりで却下されることが多々あった
    • そもそもプログラムを作る機会が少なく、今まで勉強してきたコンピュータサイエンスの知識を全体的に活かせていない
  • 周りから自分のここが認められたと思うこと ※3:7 位で技術:エンジニアとしての心構えみたいなやりとりが多いです。
    • 文章作成やプレゼンテーションはおおむね高評価
    • ログやDBの分析調査など計算が必要なシーンで、正確かつ早く結果を出した
    • スクラムの手法を用いてタスクを整理し、メンバーが安心して仕事に取り組めるようにした
  • チームで仕事をしている時に気をつけていることはなにか。
    • 情報を体系的に整理し、共有する。チーム内WikiRedmineなどのツール、ボードと付箋を使ったアナログな手法を使い分ける
    • タスクのインプットとアウトプットを明確にする。手戻りが少なく効率的な仕事ができる
  • HTTPリクエストから、HTTPレスポンスを返すまでに行われるコンピュータの仕組みについて、話してください。
    • ネットワークに接続しているサーバーコンピュータにHTTPリクエストが到達し、サーバー上で常時動作しているApache Web Serverなどのサーバーソフトウェアが受信する。それを同じくサーバー上で動作しているTomcatなどのWebアプリケーションサーバーに送信し、Tomcat内で動作しているアプリケーションが時にさらに他のサーバーと通信しながらレスポンスデータを計算する。最後にTomcatからApache Web Serverにデータが送信され、ApacheはHTTPレスポンスを返却する。
    • (こんな感じでいいのかな…というか聞かれるんだろうか)
  • 分散システムを構築するにあたり、注意することはなにか。
    • 分散コンピューティング、という認識か?
    • 多数の端末を介するため、セキュリティ面で脆弱になりやすい
    • 分散・集計処理に時間がかかり、却って性能が落ちる可能性がある
  • sessionの保存の仕方と役割
    • ブラウザにCookieを用いて保存する手法が一般的
    • 本来ステートレスであるHTTP通信に保存できる情報を付加することができる
    • セキュリティ上問題ない場合は、リクエストURLパラメータに含めることもある
  • DBのインデックスの設定の仕方
    • create table (インデックス名 型 primary key, …)
    • ALTER TABLE table_name ADD [ CONSTRAINT primary_key_name ] PRIMARY KEY (col_name, colname2 ..) ;
    • って感じかなあ、聞かれるかどうか分からんが
  • どんな開発に携わってきたか?
    • 官公庁向け業務システム。数多くのサブシステムを担当しているが、その一つにStruts / Springを使ったWebアプリケーションがある。3月のリプレースでは機能を維持したまま全画面を開発しなおす案件に携わった。
    • その他のサブシステムは、外部システムと特定のインターフェイスに従って連携を取り、リクエストを処理する。法的に重要な情報を取り扱うため、順序性や厳密性が求められる。
    • その他、内部で使うスクリプトやマクロなど
    • テスト工程ではSeleniumの導入をリードした
  • 開発はどれくらい出来るのか?
    • Railsを使ったシンプルなアプリなら3時間程度でリリースできる(面白いかどうかは別として)
    • どれくらいっていうのは、例えば?
  • rails を使った時に困った事は?
    • 割と「暗黙の了解」が多い。メンバを定義したらそれを呼び出すメソッドも自動で定義されたり、そのメソッド命名規則を覚えておく必要がある
    • Eclipseの変数ジャンプやドキュメント自動参照などの機能は気に入っていたが、今使っているAtomにはそれがないので、検索する必要が多くなる
  • 最近どんな技術を勉強しているか?
    • Ruby on Railsを休日や業務後の時間を利用して勉強を進めている。
    • 競技プログラミングサイトで数学問題をRubyで解くことで、Rubyの文法と数学のスキルを勉強しなおす
  • 何かフレームワークを使った事があるか?
    • Struts2 (業務経験あり)
    • Ruby on Rails (趣味)
    • Django (学生の頃のアルバイト。求人票を見る限り、意外に採用している企業は多いようだ)
  • 弊社サービスの改善点(ちゃんと使い込んでないと回答できない)
    • これ一番難しいな…基本BtoBのソフトなんで使えない(その辺は面接官も事情を酌んでくれるはず)
    • サーバーは既存のクラウドサービスを使っているとのことだが、「セキュリティ上の理由」を持ち出してそれを嫌うウチみたいな企業も多い。しかし会計業務の煩雑さはそういった企業組織でも感じているはず。セキュリティの安全性をアピールする、機能を追加する、構築サービスを設けるなど、そういった顧客にも売りこめないか?
    • 顧客となりうる企業の既存データはExcelに記録されていることが多い。初期設定としてExcelからアプリにデータを流し込む設定はあるか
  • チームの人数が増えてきた時にどんな工夫をして上手く回すか?
    • スクラムの手法を活用する。ストーリー・タスクを定義し決められたスプリントで消化するために検討を重ねる
    • 人数が多い時はチームを分割(4〜7人)する。チーム間の干渉は多ければいいというものでもない
    • 当日の割り込み作業が発生しないよう交渉する。期日と目標を聞き出し、日中の依頼はなるべく翌日に回せないか交渉する
  • 小さなチームの集まりで開発を進める際のメリット・デメリットは何だと思いますか?
    • メリット
      • タスクの管理がしやすい
      • チームの合意が早いため開発のスピードも速い
      • メンバーの個性を生かして、各自のみでは作り出せないサービスをチームとして開発できる
    • デメリット
      • 量が多い問題に対しては不向き
      • 新しいメンバーに対する教育が不十分になりがち
      • 事故でメンバーが欠員する時のリスクが大きい

こんな感じか。面接の準備にブログを使うとは当初の予想になかったが、なかなか効果ありそうだ。あとは冷静に挑むのみ。

面接3社目: 今まで何をしてきたの?

1社目、2社目をすっ飛ばして3社目の面接を書いたのには理由がある。記憶が新鮮なうちに記事にしておきたかったのと、結果からして今後に最も残りそうな内容だからだ。

  • 3社目: F社
  • 金融システムを扱うWeb系ベンチャー企業
  • 結果: 合格

三度目の正直である。この日から「面接全敗」状態から脱したわけだ。今の会社での残り勤務期間が、一気に短く感じた。

この日は色々と好条件が重なった。まず会社は運良く有給休暇が取れたため、ゆっくり体を休めることができた。さらに直前にエージェントの面談を受けられたので、現状の悩みや面接のコツまで相談できた。「今後F社の面接なんです」とも正直に言った(「採用ハードルが高い」とのいらん情報もあったが…)。面接に至るまで(向かう電車の中)ほぼ瞑想状態でイメージトレーニングできた。リラックスして面接に臨むと言葉につまることもなかった。

内容を振り返っていく。

Q. Seleniumの導入実績について詳しく
1問目から具体的な出来事の質問が来た。職務経歴書でも特にアピールしている鉄板ネタなので、導入のきっかけから工夫した点、苦労した点、導入した結果を順を追って説明した。それにしても、最初にこの質問が来るのは予想外だった。

Q. 当社を志望した理由
これはどの会社でも必ず聞かれるため、前もってイメージしておいた内容をスムーズに答えられた。とはいえ、今思うと具体的に質問が来たというより、自然と話題がこの内容に移ったという印象がある。 「会計ソフトという既に強力な競合相手がいる中で、クラウドを使って新しいサービスを提供した点が非常に挑戦的であること、かつ事業を成功させて急成長している点に実力を感じました」みたいな内容を回答。「ありがとうございます」との返事。

Q. スクラムカンバン方式などタスク管理の工夫について詳しく
「そういや経歴書に書いたな」くらいの内容だったので準備がなく、思い出しながら答えた。書籍や研修やネットで基礎知識を身につけたこと、チームの状況に合わせて試行錯誤しながらカスタマイズしたこと、結果としてメンバーが抱えるタスクの均一化につながったこと、などと回答。この面接官、経歴書をかなり重視している。「いいですね〜」と好意的な反応が返ってきたので、結構アピールできたと思う。

Q. こちらに聞いておきたいことは
これはもういつもの内容である。

  • 「技術以外に働きやすさや雰囲気作りで取り組んでいることは」
  • →自由な雰囲気作り、メンバー間のコミュニケーションなど
  • 「入社してからのフォロー制度や、少なくともお互い教え合っていく土壌はあるか」
  • →技術は共有するもので、会話や社内SNSでの交流は盛ん。また、勤務時間外で自習する余裕もある
  • 「今の会社だとだんだんマネジメントにシフトしていくキャリアパスとなっているが、ここは希望すれば長くコードを書いていられるか」
  • →プログラミングよりマネジメントを主に担当する立場の社員はいるが、それを希望しない人に無理にやらせることはない

大体この程度質問すれば内容的にも時間的にもいい感じになる。

面接官はいい雰囲気の人で、終始笑顔であった。面接というより、会話の中から相手を引き出す印象があった。また、最初の質問のチョイスからして「今の会社で具体的にどういう実績を積んだか」を最も重視しているようだった。最後には軽く雑談を挟みながら会場を去った。 あとで調べたことだが、この会社は「様々な背景を持つ人が集まって価値を作り出す」ことに重きを置いているようだ。そのため、中には入社時点でプログラミングの経験がほとんどなかった人もいるという。その分、その人には強力なバックグラウンドがあり、入社してから急成長した「伝説の社員」でもある。

返事は意外に早く、翌日夜に合格と二次面接の連絡が来た。転職活動始まって以来の快挙だ、個人的に。具体的な知識より、その人の軸にしている意思、及びそれが具体化したエピソードを重視する採用方針が、自分のストーリーとうまく重なったのだろう。 会社でメールを受け取ったが、その瞬間に社内の景色が違って見えた。確かに、内定通知ではない以上まだまだ油断はできない。しかし、これはもうすぐ、過去の物になる。

転職面接に至る最大の契機は、今思うとCodeIQだった

この記事は当初書く予定は無かった。1本の記事で最初の面談から勉強会に参加するまでの経緯、さらに最初の面接に至るまでを振り返るつもりだったからだ。しかし、前半部分で思いのほかボリュームが出てしまい、書いてから読み返してみると後半の展開が急すぎたため補足しようとしたところである。シルバーウィークのことなんか書いてるからだよな。

さて、転職活動におけるひとつの関門に職務経歴書というものがある。これは今まで会社でした仕事や個人的な活動を記載することで、自分がどのようなスキルを持ち、転職後にどう活躍できるか主張するために使う書類である。もちろん、合わせて履歴書も必要となる。 この職務経歴書は、実は転職活動のかなり早い段階、具体的にいうと最初の面談の時に用意していた。今思うと、この時点で用意しておいたのは得策だった。確かに書くのはなかなか大変だが、一度書いてしまえばあとは使い回せる。半年後に見返してみたが、勉強会のことを追記するぐらいで転職エージェントの人のゴーサインも出たし、質的には問題ないと判断できるだろう。それっぽい文章を書くスキルは学生の経験上自信があるので、もしかしたら思ったより財産なのかもしれない。

勉強会では主にRuby, 特にRuby on Railsを勉強していた。個人的に興味があったのと、もちろん転職先で使いたかったためである。有名な “Ruby on Rails Tutorial” という量質共に最大級のテキストが無料で利用できるため、当面はこのテキストを修了することが目標となった。これが達成できたのが2016年の1月初め、勉強会に参加し出してから3ヶ月ほど経った頃だ。これは勉強会でのひとつの成果である。

もうひとつの成果として、様々な業界・立場の知人が増えたことだろう。「Railsを勉強している」と宣言しておくと、イマドキのRails最前線を知る人から情報がどんどん入ってくる。話を聞けば聞くほど、この業界への興味、及び今のレガシーな環境への後悔が増えていった。具体的に転職を考え出した今の時期がおそらく気持ちの底辺だろう。先月はちょうど会社で取り扱っているシステムのリプレースという時期であり、とにかく残業が多かったことも重なった。「なんでこんな会社入ったんだろう…」と何度思ったことか。

しかし、具体的に面接を受ける踏ん切りはなかなかつかなかった。Tutorialを終わらせた程度では「成果」と言えないことぐらい分かっていた。オリジナリティは何一つないからだ。 だから、Tutorialを終わらせた時点で、次はオリジナルのアプリを作ることを目標にし、実際に作り始めた。Tutorialにはなかった要素として、HAML (簡易HTMLのようなもの。今はSLIM派) を勉強できたのは大きかった。目標としていたのは、高校生の頃に作ったホームページのリプレースだ。実際、結構それっぽく作ることはできたが…ロジックを書く楽しさが感じられず、手探りで地味な設定ファイルを書くことに飽きてしまい、先述の忙しい時期と重なったこともあって中途半端な成果で終わってしまった。 やはりロジックを書きたいし、RailsのまえにRubyの勉強をしっかりしたいとも思っていた。

気分を変えるために、登録しただけで放置していたCodeIQというサービスを使うことにした。早い話が競技プログラミングサイトである。先ほどあった「ロジックを書く楽しさ」が感じられそうであったし、Rubyの基礎も勉強できそうだった。なんか「あなたの回答を見た企業がスカウト!」とか書いてあったが、まあそこはあんまり気にしていなかった。 本格的に使い始めたのが2016年3月初旬で、勉強会の時間で1日で3問ほど進んだ。1日で「Ruby中級」まで行けたので「こりゃ楽しくていいわ」と思ったものだ。久々に頭の体操になり、ゲーム感覚で楽しめたのもよかった。CodeIQは今でもちょいちょい活動している。

で、週が開けて月曜日、CodeIQのスカウトメール欄が意外なことになっていた。「技術力がある方とお見受けしました」「ぜひ新しい環境で実力を発揮しませんか?」こう言われれば悪い気はしない。そのうち2通以上メッセージを送った転職エージェントと面談し、まずは書類選考に至ったというわけである。 数としてはよく覚えている。そのエージェントからは6社に履歴書と職務経歴書を送り、そのうち3社は書類選考通過、1社は追加でエントリーシートの提出を要望(後に対応できず辞退)、残り2社は不採用となった。それとは別にもう1社面接に至った。この時点で書類選考の通過率は4/7, 半分以上だ。まあ、それなりに「イケる」と思ったもんだ。

ここから、本格的に転職活動が始まることになる。このあと体験する苦労は、当時は想像もつかなかった。

転職を決意してから、面接まで

2015年の9月は長めのシルバーウィーク休暇が取れた。日々の喧騒を離れ、九州のリゾート地でのんびりしたあと、遠くに住む親戚とあいさつがてら数日過ごすという、今思い返しても理想的な休暇であった。しかし、そこはかとなく不安になる時間があったのも事実である。家族も恋人も友人もいない一人旅ということもあったんだろうが、少しでも休暇が終わったあとのことが頭をよぎると異様に不安になったものだ。遠く南の島の民宿のベッドに横たわり、深夜「このまま遊んでていいんだろうか」と感じてしまったこともあった。

社会人にとって休暇の過ごし方は永遠の課題である。当時俺は何をやっても日曜の夜には後悔が残る、典型的なサザエさんシンドロームに陥っていた。1日家にいれば無駄にした気になる。外で体を動かせば多少気分は晴れるが、出先でカップルでも見ようもんなら途端に1人で何やってんだと考えてしまう。家族と外出すると気が楽だが、いい歳して独り立ちできていない感がぬぐえない(いつまでも優しくしてくれる家族には感謝している。実際、家族との時間は今でも大事にしている)。これで恋人でも居たら違うんだろうなと考えたこともあるが、想像の域を出ないのでこれ以上はやめておく。とにかく、当時の俺は不満と不安に侵されていた。

「あんた、会社で働くのに向いてない!」と言い放たれたのはそんな折である。こいつらは結局ネズミ講の勧誘員だったのだが、この件で「あ、この会社で働く以外の道もあるんだ」と気付き、そのための行動を起こす踏ん切りがついた。まず行ったのは転職支援サービスへの登録と電話での面談である。そこで言われたことは金言として今でも見に留めている。

転職したいなら、勉強しろ。

(※実際はもっと丁寧な言葉でした)

そう、転職先で求められるスキルを身につけなければ話にならない。この点、入社させてからの将来性を重視する新卒採用とは大きな違いだと感じた。転職で求められるものは「具体的なスキル」だ。つまり、現状では転職したいなど話にならない。ここから数ヶ月を俺は転職準備期間と位置付けた。これをもって、俺の転職活動はスタートした。2015年10月のことである。

ここでDoorkeeperとConnpassを使って勉強会を探すことを勧められたので、さっそく使うことにした。時は10月も半分を過ぎた頃だったが、運良くiOS (Swift) とRuby on Railsをテーマとした勉強会をそれぞれ10月中に見つけることができ、さっそく参加した。改めて思ったのが、技術は触れてみないと分からないという単純な事実である。Swiftは言語仕様を読む限りなかなか快適な言語に思えたが、ことiOSアプリを作るとなると意外にObjective-Cっぽさがある。特に画面表示とプログラム処理を結びつける時の泥臭さは、もはやスマートフォンアプリ開発にいつまでもついてくる課題だろう。俺は見た目の美しさより論理的な美しさが好きなんで、iOSエンジニアへの道は早々に諦めた。

で、論理的な美しさって何よというと、まさしくRubyの設計思想がそれだった。何しろ書いていて快適である。最初は「いちいちendって書くのはPythonよりイケてないな」とか思ったが、PythonPythonでインデントをものすごく注意しなければならないという側面もある。インデントを推奨するが必須ではなく、かつ論理的な区切りをつけやすい「なんでもend」方式に慣れるのにそう時間はかからなかった。少なくとも、予約語に対してブロックの終わりがfiだったりesacだったりodだったりdoneだったりする言語より数倍マシだ。シェルスクリプト、お前だよお前。

勉強会自体も刺激的だった。やはり会社の外の人と会話するのはそれだけで刺激になる。それに自分の話も他の人にウケている様子であった。かくして俺は勉強会にすっかり夢中になり、特に2グループについては常連となった。今でもこの2グループ主催の勉強会にはよほどのことがない限り出席している。この時点では、勉強してスキルを身につけるというより、仕事の鬱憤を雑談で晴らすという目的の方が大きかったのかもしれない。いや、それでいい。消極的だった休日の過ごしかたに、一つの活路が見えた。

勉強会を楽しむ日々がしばらく続いたが、肝心のRubyの技術が身についているかというと、今思えばそうでもなかった気がする。なにしろオリジナルのアプリを結局リリースできていない。Ruby on Rails Tutorialはやりがいがあったが、終わってしまうと急に目標を見失った気がした。やはり俺は教科書の問題があってから行動する習慣から脱していないようだった。この点については今でも最大の課題である。

転機となったのは年が変わって2016年の2月である。先ほど述べた通りTutorialを一通り終わらせ、次何やるかと思い立ったのがCodeIQというサービスである。これは数学的な問題と入力例が提示され、問題に対して正解となるプログラムを投稿することでユーザーの技術力を評価する、広義で競技プログラミングサービスである。ある時の勉強会で3問ほど解いてみたところ、週明けに自分の回答に驚くほど反響があった。まあ、自動投稿的なものもそれなりの割合であったが、自分のプログラミングスキルに自信を持てる一員となったのは事実である。そのうちの1件と連絡を取り、あれよあれよと言う間に面談を経由して面接までこぎつけた。最初の面接は2016年の3月である。ここから本当の戦いが始まった。

サザエさんシンドロームは、いつの間にか消え去っていた。

Initial commit (1) このブログについて・転職を決心するまで

このブログは、大手SI企業入社3年目の若手社員が、Web系ベンチャー企業への転職を目指して四苦八苦する様を綴ったものである。筆者(@strviola)は情報活用に関しては平均以上であると自負しているが、情報発信にはとんと疎く普段はTwitterで愚痴を垂れ流すくらいしかしない。ブログなど高校生の頃に書いていた事があるくらいでほぼ10年のブランクがある。それでも久々にブログなどという時代遅れのメディアを始めたのは、以下の理由からである。

  • 自己反省。転職活動をする中でその時の活動を振り返り記録することで、次に似たようなことがあった時に対処しやすくする。
  • 孤独感。後日触れる予定だが、転職活動とはとにかく孤独な戦いである。LINEやTwitterで愚痴ってもあんまり共感してくれないので、違った経路を試してみる。
  • 文章を作る練習。面接であれ書類であれ、転職活動では文章を作る必要が大いにある。その場になって急に対応するより、事前に練習しておく。
  • コンテンツとしての期待。こうして自分が文章を記録することで、将来似たような立場になった人の役に立つんじゃないかなーと思った。
  • 量的な不安の無さ。転職先が決まるまで内容に事欠くことはないだろう。現にこの記事プラス4本の構想が頭にある。

さらに、今回自分にとって初めての試みとして、Twitterと密に連携したブログを作っていく。Twitterにもブログにもお互いの紹介を載せるし、ブログを更新した時はTwitterにもそう通知する。このブログを「Twitterの延長」として扱うことで、浮かび上がってくるものがあると期待する。

さて、転職を語る前に現職を語らねばなるまい。現職は大手SI企業の官公庁システムのプロジェクトにいるシステムエンジニアである。名前は伏せるが(一部バレているがこのブログでは伏せる)日本人なら知らぬ人はいないレベルの有名企業の名前を冠するグループ企業である。この点、初対面の人に自己紹介する時も通りがいい。この会社に入って良かったと思える瞬間の一つである。

前もって言っておくが、自分の会社は労働環境だけ見ればかなりホワイトな部類である。残業はそこそこあるが多い時で月50時間程度(若手は)、閑散期には10時間を切ることもある。休日出勤もあるにはあるが代休取得のルールが徹底されており、休暇は比較的取りやすい。何より、残業代も休日出勤手当も全額出る。しかも医療保険や住宅補助などの福利厚生もかなり手厚い。おまけに失業のリスクもかなり低い。これらは先輩たちの文字通り血の滲むような努力の上に成り立った環境である。もはや公務員みたいなものである。

自分としても、配属当初は結構楽しんで仕事していた。そもそも配属先がアプリ担当であり、あんまり好きではないJavaがメインではあったもののプログラムを仕事にできることに喜びを感じていた(下手すると全く門外漢の回路系や、全くクリエイティビティのないテスター部隊になっていた可能性もある)。開発案件がいくつもあり、コーディングする機会が割と多かった。おまけにRedmine, Jenkins, Mavenなど官公庁システムとしてはあまり例を見ないモダンなアプリも取り入れていたし、開発手法はスクラムをベースに独自のカスタマイズを加えたものだった。こうしてみるとシステムはレガシーでも進め方はなかなか先進的である。ついでに言うと、国家を支えるインフラエンジニアとしての自負も少なからずあった。この辺が文句言いつつ2年間続いた要因だろう。

が、これらは新人を引き止めるためのある種の方便だったのかもしれない。その後の面接でも実際に引用したが、俺は2年目のある日上司に言われた言葉を忘れない。

「ねこばば君には、今後(担当のシステム名)の運用保守をやってもらうから。開発はあんまりできなくなるねえ

この言葉だけがきっかけではないが、俺はこの会社で働く以上未来はないと確信した。何より、プログラマの地位が低い。ビジネスに最も直結するはずのプログラムを書く人が、使い捨てのハケンさんとして扱われている。それよりも「プログラマを束ねて価値ある製品にするマネジメントが重要だ」という思想が支配的である。プログラマとマネージャ、確かにどちらも重要な仕事であるし、優劣はつけられない。しかし、俺は今までプログラマとして教育を受けてきた。そこからマネージャになることを求められるということは、大学6年間で学んだことを捨てろという宣告にも等しい。確かに、マネージャの道に進んだらそれはそれである程度成功できるんだろうけどさ。それ以上に「プログラマでいる限りこの会社では偉くなれない」と悟ったショックが大きかった。

そんな折、当時親しかった人に上記の話を打ち明けたところ、「あんた、会社で働くのに向いてない!」と豪快に言われた。この言葉は少なからず自分を後押しする結果につながっただろう。この言葉を言った人は、その後色々あって今は最も嫌いな人物の一人まで成り下がったが、この一点についてだけは感謝している。つまり、この時に「なにも嫌いな仕事を我慢する必要はないんだ」とやっと気づけたのである。

かくして、転職を見据えた具体的な行動が始まった。2015年10月のことである。ここから社外の交流を広げ、さらに会社を離れるべきという確信を強めていくのだが、それは次の記事に譲りたい。