正しいエンジニア採用のやり方！チーム開発に向いている人とそうでない人

はじめまして、sinsinchangです。

今回、Ruby現場の責任者のときに採用をしていたときのお話をしたいと思います。

チーム開発に向いている人、そうでない人についてをテーマとします。

手順

まずは、エンジニアの候補者を募ると思いますが、これはエージェント経由がほとんどで、次にWantedlyやクラウドワークス経由、稀に直接連絡をする方もいますね。

今回は、エージェント経由をメインにお話しましょう。

エージェント経由

会社名は伏せますが、エージェントからエンジニアを紹介してもらうときに、まずは「ほしいスキル」や「働く環境のメモ」などをエージェントに伝えます。

欲しいスキル

例えば「Java歴1年以上」「Ruby歴1年以上」などのくくりとフレームワークなども伝えると思います。

働く環境のメモ

例えば割と具体的な状況を伝えておくとマッチングしやすいと思います。

「継続的インテグレーションを採用。GitHubでコード管理をし、PRに対し2人以上のコードレビューが必須なルールになっていて、チーム同士のコミュニケーションについて積極的な方」

実際にこの環境から読み取れるのは、以下です。

• CIあり、テストをちゃんと書く現場
• GitHubをメインで利用
• コードレビューが割と厳しめ
• コミュニケーション

以下の本を読んで実践しているようなイメージです。

チーム開発実践入門──共同作業を円滑に行うツール・メソッド WEB+DB PRESS plus

この環境だと、自分のコードがキレイでない（こだわっていない、あるいはレビューされたくない）プログラマはまず応募してきません。

例えば、普段からコードレビューありの現場で働いていてそれが当たり前になっている、あるいはレビューによってコードをより洗練したいというプログラマが好んで応募してきます。双方ともにモチベーションが高いのでおすすめです。どちらがほしいのか、というのは面接で「コードレビューありの現場でしたか？」と問えば良いでしょう。

年齢で言うと、若い方が多いです。たまに40代の方がいますが、20〜30代の方がメインでしょう。男性と女性の比率は8：2ぐらいです。

「要件定義から設計／開発、運用／保守まで一貫して経験がある方。人数が少ないので、アラート対応（業務時間内）も積極的にやってくれる方、また改善の提案もしてくれる方」

実際にこの環境から読み取れるのは、以下です。

• 開発だけでなく、要件定義や運用周りも経験ある必要がある
• チーム人数が少ない
• アラート対応をしなくてはいけない（開発中に横槍が入るのに抵抗がない）
• 改善提案をしないといけない

どちらかと言うと、SEというポジションの方が応募されることが多いでしょう。SIerや社内SEをやってきた方もこの条件だと好んでやってきます。実際に、そういう方のほうが良いと思います。ガチのプログラマはアラート対応はまずやりません。頼んでも相当後回しにされる可能性が高いです。

また、SIerや社内SEをやってきた方ということで、SEの方ですと、改善に対する業務経験も豊富なので、現場で1ヶ月ほどやっていると無駄なところが見えてきて改善提案もけっこうしてくれますし、そのための解決方法も提示してくれるので非常に助かります。

注意点としては、要件定義や運用のスキルは高くても開発力が低い方が多いので、そこをあまり期待しすぎないほうが良いと思われます。一応開発をお願いできるイメージです。どちらかといえば、上流メインで活動してもらったほうがパフォーマンスは高いでしょう。

年齢的には30代〜40代ぐらいの方が多いですね。僕の経験上ほぼ男性です。女性のSEが応募に来ることはあまりないです。

以下の本おすすめです。

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

エンジニアのための時間管理術

「営業と開発の距離が近いので、要望が直接来ることが多いです。効率よく、要望の是非を判断して処理できる方。解決方法はエクセルの関数を使うことが多いので詳しい方だと尚良い」

実際にこの環境から読み取れるのは、以下です。

• 営業と一緒の現場で仕事しているイメージ
• エクセルをメインで使う

より上流で働いていた方になるでしょう。ただし、システムの知識も必須なポジションにはなるので、開発未経験の方はやめたほうが良いと思います。

例えば、営業が持ってきた仕事をコードから読み解かなくてはいけない時は多いので、勘を頼りにスピード感持ってコードを読んでその是非を判断しなくてはならないときもあります。仕様をすばやくコードの部分で把握していないと、仮にプログラマに依頼するときも指示が正しく出せませんので仕事が遅いです。

また、エクセルをメインとは言いましたが、要件によっては例えばPythonのPandasなどを用いることでデータ分析をスピーディに終わらすことは可能です。また、定期的にやる処理であるなら都度実行するのではなくジョブ形式（例えばJenkinsなど）をすばやく構築するぐらいのインフラ知識は必要です。

スキルについて

とはいえ、スキルのマッチングが難しいときもありますよね。例えば、大手企業ならともかく小さな会社だったりすると知名度に欠けるので候補者を集めにくいという事実が在ります。確かに単価を上げれば候補者はすぐに集まりますが、それは最終手段になります。

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?

Ruby on Rails5年以上経験者

このスキルを提示してしまうと、エンジニアを集めるのが難しくなってしまいます。

理由を簡単に述べますと、5年以上ということは具体的には、「2013年11月以前」から現場で継続して経験している必要があるからです。

2013年といえば、まだRails3系が主流だった頃です。もちろん4系にアップデートした会社もあったかもしれませんが、4系から始めたならともかく3系から4系に追従している会社はそんなに多くなかった肌感です。その状況を知っていて、さらに現在まで継続してRailsをちゃんと使って開発してきたエンジニアとなると、僕の周りには多くないです。

3年以上

3年以上であれば、どうでしょうか。3年以上ということは具体的には、「2015年11月以前」から現場で継続して経験している必要がありますね。2015年といえば、まだRails5がStableでなく4.1か4.2を使っている現場が多かったと思います。もちろん3系の現場もありました。知り合いの会社などを見ても、スタートアップなどでRailsが流行り始めた時期だったと思います。

この層であれば、まだエンジニアは多いでしょう。ただし、この層のエンジニアは2極化していて、CやJava、C#などを経験していた中堅エンジニアがRuby on Railsに転身したパターンと、スタートアップなどに新卒入社し、最初からRuby on Railsエンジニアとしてキャリアを積んだ若者です。

このうち、前者ならまだしも、後者を集めるのはけっこう難しい気がします。前者は金額を上げると割と集まりますが、後者に関しては金額はもちろんのこと、ビジョナリーや技術の面白さなどを売りにしていかないとなびいてくれないからです。

ちゃんと、マネジメントキャリアパスまで提示して上げる必要があります。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

1年以上

この層になると、かなり多いです。Java2〜3年、Ruby1年というスキルシートは大量にありますので、このあたりを狙っていくのが最もエンジニアを集めやすいと思われます。

ただし、この層はRuby on Railsの作法をわかっていないエンジニアも多いのでちゃんと質問を考えた方が懸命でしょう。コーディングテストはクリアできるかもしれませんが、大事なのはコーディング力だけではないです。

Ruby on Railsのプログラミングテスト

例えば、Ruby on Railsのプログラミングテストを挟んでみると良いかもしれません。サンプル質問を書いておきます。

1. bundle exec rake db:migrate と rake db:migrate の違いは？
2. has_many :user_jobs, dependent: :destroy と has_many :user_jobs, dependent: :delete_all はどういうときに使いわけるか？
3. active_hash activerecord-import active_decorator はどれもよく使われるがそれぞれの使うメリットを答えよ（わかるものだけで良い）
4. ActiveRecordにおけるN+1の解決の仕方について答えよ
5. Rspecは使ったことがあるか？あるならRSpecと一緒によく使うGemを答えよ

   Everyday Rails Testing with RSpec: A practical approach to test-driven development (English Edition)

Ruby on Railsの現場経験に関しての質問

例えば、以下の質問を投げかけてみると良いかもしれません。経験がなかったら次の質問に行くと良いでしょう。

1. Ruby on Railsのデプロイ方法を経験談で語ってもらう
2. Ruby on Railsのメジャーアップデートの時に辛かったこと
3. Skinny Controller, Fat Modelによる弊害はなにか？
4. 実装したことがあるデザインパターンについて教えてください（pattern系のGemを使っていても可）

   Rubyによるデザインパターン

5. リファクタリングをするときに気をつけていること

   リファクタリング:Rubyエディション

6. コード規約はどうしていましたか？

一応、どこまで考えてコードを書いていたかと聞いておかなくてはなりません。

失敗談

僕が直接面接をしたわけではないですが、Java3年、Ruby on Rails3年（プライベート含む）、JavaScript3年、CSS,HTML3年というスキルシートに加え、ものすごい熱量がある方だったので、かなり高評価になり、最終的にはプログラミングテストをせずに、熱意だけで採用してしまったことがあります。最後に顔合わせだけしましたが、特に採用の合否とは関係ないところでした。

採用後、僕の担当するプロジェクトでプログラマをやることになったのですが、作法を全く理解せず独学でRailsをやってきた方だったのでSpecを1行もかかずにPRを出してくるわけです。

まあ他のプログラマは怒りますよね。レビューで指摘しても直さずに勝手にマージしたりしちゃうわけです。Java3年というのもSVNでやっていたようで、コードレビューという文化もなかったようです。Railsはほぼプライベートでちょっとしたアプリを作っていただけだったようでした。後で聞いたら、現場では社内システムのRailsコードを少し直しただけだったようですね（面接のときのあの自信満々な感じどこいったよ）

つまり、何が言いたいかと言うと、「面接だけが得意だった」ようです。スキルシートもそれなりのものを持っているから、面接で良いこと言っているとできるやつだと勘違いしてしまうわけです。

最終的には、現場の不満が溜まってきたので（Rubocopの指摘事項までコードレビューしたくないし、現場の士気が下がる）という話が大きくなってきてその方は終了になりました。

失敗しないために

スキルシートが合格しているエンジニアが取れればOKというものでもありません、チーム開発の場合、プログラミングテストや現場経験の具体的な設計論などについて質問してみるのは必須ということです。

そういうエンジニアは、もう面接が天辺なわけで、そこから下降していくわけです。ある程度の脚色は仕方ないですが、やりすぎなのはどうかと思います（つまり、本当にRails歴3年なのか？？って話です）。そういうエンジニアは結構いますし、若い方に多いです、正直になりましょう。スキルシートに実力より超えたものを書いても自分の腕は何も変わりません、むしろ現場に入ってから辛くなります。もし実力が伴わないけど、年数が長いなら、それを面接時に伝えるべきだと思います。

チーム開発に向いている方

他のエンジニアに対し、誠実に、技術的に、エンジニア的にコミュニケーションがちゃんと取れる方、ということになります。

先の質問に加えて、DBやサーバ系の質問を投げかけてみるのもありだと思います。先の質問はRailsに関してのものになりますね。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)