Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

Twitter でスカウトされるまでの流れと、スカウトされた理由を整理した

f:id:tbpg:20150507235554j:plain

概要

Twitter でスカウトされるまでの流れと、スカウトされた理由を整理しました

経緯

私は、 2013 年の 3月に Twitter で声を掛けられて今の会社に転職 しました。
Twitter 採用の事例は社内ではじめてかつ、現時点で唯一です。
今までは一般的な転職支援サービスなどを利用して採用をしていたそうです。

今所属している会社はさほど大きくなく、 現状では 「技術的な挑戦ができる」
「ゆとりのある勤務(残業がほとんどない)」 などのアピールポイントがあるものの、
転職支援サービス経由で紹介してもらえる人材は要求レベルに満たないことが多かった そうです。
(実際には、私の上長が非常に優秀で、「一緒に仕事をしたい」と思わせる人物であり、
私はその点において最終的に転職を決めました。ただ、それは転職支援サービスの広告では表現しにくいものです。)

プレイングマネージャーである現在の私の上長 は痺れを切らしました。 そこで 人事部をすっとばしてダイレクト採用に踏み切る ことにしたのです。
※社長や人事部の承認を得た上での話

現在組織を大きく変えるための計画を練っています。
採用面も根本的に仕組みを変えていく予定です。
そのために、私の採用例を分析し直し、
経営層に ダイレクト採用の重要性 を説明することになりました。
( 長期的には色々と計画があるのですが、そのあたりは準備ができてから会社の開発ブログを
立ち上げ、公開していく予定。まだ大分先になりそうですが。 )

以上が、 今日、私が業務中に自分の過去のツイートを読みあさるという妙な仕事 をしていた経緯になります。

転職までの流れ

前職について

  • いわゆる SI'er の下請け SE・プログラマ
  • 常時激務。 250- 300 時間労働が基本
  • 有給はほとんど取得できず(雰囲気的に)
  • 低基本給( しかも標準労働時間が月 174 時間。超低時給ということ。 )
  • 残業代は出る( 時間外も深夜も休日も 1.0 倍計算だったが )

前の職場に転職する際は、 システム開発のブランクがあった関係で転職可能な企業がほとんどなく、
求職者としての選択肢があまりなかった
という経緯があります。
また、 社内で自社のサービス開発を行うことができると聞いて入社を決めたのですが、
なぜか 初日から下請けとして元請け会社に常駐 することになり、 退職するまでずっと
社外案件のみを担当
していました。

数ヶ月でブランクは克服し、毎日激務の合間に学習を怠らなかった成果か、
半年程度たった頃にはチームのサブリーダーなどをする立場になっていました。
現場では業務外でプログラミングに関する学習をする人はほとんどいなかったこともあり、
相対的にランクアップしやすかった、という点もあります。
入社直後はともかく、どんどん業務内容と給与が釣り合わなくなっていきます。

個人の学習内容は業務に関連することと、それ以外と半々くらい。
業務は Java でしたが、 家では Ruby を覚えたりしていました。
学習内容はできるだけ 当ブログ にアウトプットするようにしていました。

2012 年 ~ 2013 年 2 月

要件定義の段階から 毎月 250 - 300 時間労働 というデスマプロジェクトで消耗していました。
毎日 8 時 30 分始業で 24 時終業。
通勤片道 1 時間 30 分以上。
基本週休 1 日。
たまに 3 週間休みなしで勤務したり。
終電を逃して漫画喫茶やカプセルホテルで宿泊することも少なからず。

深夜、2 時前後に帰宅してから 1 - 2 時間、
また朝は 30 分 から 1 時間前に出社して会社近くの喫茶店で技術書を読むなどして学習時間を確保していました。

ちなみに、プロジェクトの参画直前に次女が生まれました。
しかし、このプロジェクトに参画したことで、 次女が 0歳 - 1歳の間は
ほとんどまともに相手をすることができず
、妻にも負担をかけ過ぎることになりました。
結果として、 妻は心身ともにまいってしまいました
このまま継続していたら、妻は体調を大きく崩していたでしょうし、
仮に体調面は問題なかったとしても 離婚の危機 だったでしょう。

2013 年 3 月

上長からツイッターで声を掛けられる。
Ruby 転職」でツイート検索したところ、ヒットしたのが私だけだった とのこと。
そして、過去のツイートやブログの記事から

・自発的に学習を行う意欲
・デスマへの不満を漏らすだけではなく、改善のために考え・実際に行動している点
・文面から伝わる人柄

などが評価され、スカウトすることを決断したそうです。
ちなみにこの時点では GitHub のアカウントはありません。

まずはダイレクトメッセージでやりとりし、その後メールでのやりとりに移行しました。

  • 直接会う

声を掛けられた 1 週間後に直接会うことになりました。
※この日は用事があることにして定時退社した

出席者は社長・上長・私の 3 名。

ここで、事業内容や技術的な業務に関する大まかな説明を受けました。

  • 数週間後

喫茶店で話してから数週間後、 1 次試験を受けに行きました
試験内容はペアプロ
一緒に仕事をする人を選ぶなら、一緒に(疑似的に)仕事をするのが一番ということでしょう。
マイキーボード( HHKB )を持参しました。

お題は、上長が前日に考えたもので、 ツイッターAPI を利用したツール作り
業務中のペアプログラミングのように、
二人で並んで API のドキュメントを見ながら
設計・実装方法について相談したり 、実装例をググったり

しながら 2 時間くらい開発を行いました。

上長曰く、 プログラミング自体のスキルよりも、
検索スキル・考え方・細かなテクニックを自分なりに身に着けているか

などのセンスや上長との相性を見ていたそうです。
その他細かい点についてはチェックポイントがあるそうなのですが、 秘密 だそうです。

  • さらに翌週

人事・役員面接と適正試験(最終面接)を受けました。
適正試験は性格診断的なやつ。
共感性が著しく低かったらしい が、他は問題無し。

  • しばらく後

採用通知をいただく。 そして前職の社長に退職願を提出。

2013 年 4 月

前職のプロジェクトのリリース予定だった月。

直前でリリースが延期になりました。
ただ、安全策としてのリリース延期だったため、
タスク量的には大分落ち着いていました。
そのため、予定通り 4 月いっぱいで離職することで話がまとまりました。

そんなこんなで、 4月いっぱいは 引き継ぎメインでのんびり過ごす・・・はずが結局新規タスクを割り振られ
最後の数日でバタバタと引き継ぎをして現場を去りました
。 有給は 1 日も使わせてもらえず。

引き継ぎに関する多くの情報は元々 RedmineWiki に残していたため、
引き継ぎのための資料作成はほとんどありませんでした。

そんなこんなで円満退社

2013 年 5 月

現在の会社に入社。

転職して変わったこと

  • 残業がほとんどないため学習時間を多く確保可能になった
  • 技術的挑戦が可能
  • Java から Ruby
  • 自律的な開発
  • 改善に対する政治的障壁の低さ
  • 意思決定に深くかかわることができる
  • SI'er の下請けに少なからずいるような、 お荷物的な人材 がいない
  • 管理業務 よりも 開発業務中心 へ
  • 家庭の時間を多く取れるようになった
  • 業務外において、個人で仕事をいただけるようになった
  • 開発に集中できる環境になった
  • 時間給で比較すると単価アップ

スカウトの決定打になったポイント

スカウトの決定打になったポイントについて。

  • 継続的学習とアウトプット
  • Ruby
  • 改善スキルと行動力

学習成果をアウトプットしておくことで、
ある程度の能力と今後の成長性
を示すことができたと思われます。

今回は Ruby を扱う職場だったため、 Ruby を学習しておいたことがプラスになりました。
ただ、 Ruby だからというだけではなく、
業務で利用しない言語を自発的に学習している
という視点での評価もあるでしょう。

最後に、 Twitter での仕事に関する発言が

  • 問題は何か?
  • 問題の解決案は何か?
  • 解決案を導入してどうなったか?

などのように、単なるデスマへの愚痴ではなく、
実際に直面した問題を分析し、どうやって解決するか試行錯誤し、
行動に移していること
を示していたことが良かったようです。

逆に、今まで仕事で出会ってきた人で、
「ほんとこの現場はダメな所。 俺が本気出すのもバカバカしいので手抜きをする
とか言って、改善のために行動しない人は 大きな事を言っていても仕事をできない人が多かった
仕事が出来る人は愚痴だけではなく、実際に改善のための行動をしていた。
たとえ大きな制約があるとしても、制約の中で最善を尽くしていた。

会社側からみた Twitter 採用のポイント

  • Twitter, Blog などで人柄やある程度の能力について類推できる
  • 吟味がうまくいき、リトライ回数が少なければ転職支援サービスを利用するよりも採用コストが安上がり
  • 転職支援サービスでは出会えない人材に会うことができる
  • 企業ブランドや採用面でのアピールの準備が整っていない段階のデメリットを、直接会うことで埋めることができる

関連資料

なぜ,エンジニアの採用は難しいのか?