ソフトウェアエンジニアの hota です。今回はソフトウェアエンジニアの採用についてお話したいと思います。
FLYWHEEL におけるソフトウェアエンジニアの採用プロセスでは、我々ソフトウェアエンジニアが面接官をつとめ技術試験を行っています。最初の頃は体制が整っていなかったため、前職で技術面接の経験があるエンジニアの基準で技術面接を実施していました。しかしもちろん会社によって技術面接の方法・採用基準は異なりますから、一貫した採用プロセスを実行できているのか、統一基準で採用できているのかという不安があり、FLYWHEEL における採用基準の明確化が必要になってきました。そこで以下のようなことを行いました。
- 時間配分や内容など、面接についてのガイドラインをドキュメント化し共有する。
- 面接の技術試験問題を共有する。
- ルーブリック（評価基準表）を策定する。
今回はあまり聞き馴染みの無いかもしれない「ルーブリック」を策定したときの経験を共有します。
ルーブリックの策定
ルーブリックとは候補者の評価したい項目に対して評価基準を明確化し一貫した評価を下せるために書かれたドキュメントです。 「Google re:Work – ガイド: 構造化面接を実施する」によるとGoogle社内では以下のように使われているようです。
Google では、応募者の資質や応募要件のフィットを探る面接での質問に対して、悪い回答、あいまいな回答、良い回答、優れた回答はどのようなものかを、実例を交えて文書化しています。 面接担当者には回答を詳細にメモしてもらいます。そうすることで、独立した採用委員会が面接担当者の評価を検討し、検証することができます。
例えば以下の表は、ソフトウェアエンジニアのルーブリックの例として、「コンピュータ科学の知識」や「コーディング」にたいして、Poor・Border・Good・Excellent の四段階を定めます（説明用であり、実際に弊社で使用されているものとは異なります）
| Attribute | Poor | Border | Good | Excellent |
| コンピュータ科学の知識 | コンピュータ科学について知識・関心がない、説明ができない。 | コンピュータ科学について大学で習う程度の最低限の知識を持つ | コンピュータ科学の全般的な知識をもち、専門分野において面接者よりも詳しい知識を持つ。 | 専門分野において最先端の技術を熟知し、リードできる能力を持つ。 |
| コーディング | 単純なコードが書けない。 | 意図したアルゴリズムをコードに落とせるが、計算量やエッジケースなどの問題がある。 | 計算量について把握しており、エッジケースなどで問題がある場合も自分で修正できる。 | コードの内容を明確に説明でき、Advancedな問題もコーディングまで含めて解くことができる。 |
弊社でソフトウェアエンジニアのルーブリックを定めた際には、以下の3つのステップを取りました。
- 意見を集める
- ルーブリックを策定する
- 採用プロセスに反映させる
Step 1. 意見を集める
まず採用基準を定める上で、どういう人と働きたいかという考えを集めました。人を集めてミーティングで議論するだけでなく、これまでの面接のフィードバックや、Slack 上の議論などいろいろなところに残っているいたため集めました。たとえば yuku さんは Increments 時代に採用に関する考え方を「どういう人を雇うべきか」という記事で文章化しており、とても参考になりました。特に「どういう人と一緒に働きたいか」という議論は、会社のカルチャーやバリューを、実践していく一つの方法になります。
Step 2. ルーブリックを作成する
次にソフトウェアエンジニアに求める資質を定め、それぞれ Poor, Border, Good, Excellent の行動を埋めることでドラフトをつくり、具体的な評価基準について議論しました。最終的に「コンピュータ科学の知識」や「コーディング」などのエンジニアの技術的な資質の6つと、「リーダーシップ」などのエンジニアに関わらないソフトスキルの6つの計12軸を定め、それぞれ4段階の行動を定めました。12 x 4 の 48項目を埋めなければならないのは結構たいへんでしたが、ある程度定まった時点でレビューして初稿の完成版を定めました。
レベル感としては、すべての項目で Excellent な行動を取れる人材はおそらくいないでしょう。またこのルーブリックは採用基準でしかないため、採用時に評価できる項目にフォーカスできるようにしました。「どんな人と働きたいか」を指針を考えることは、自分の行動を鑑みるのに大変有意義なものになりました。
Step 3. 採用プロセスに反映させる
ルーブリックを定義するだけでは、実際の採用に活かすことは難しいです。そこで採用ツールのフィードバックに、各軸に関して「Poor・Border・Googd・Excellent」の4段階の評価を書けるドロップダウンリストを追加し、その評価に至った理由を書ける欄も準備しました。その結果個人的には以下のような効果を実感しました。
- 面接で見るべきポイントを面接の前に見直せるようになった
- 感覚的に下していた総合評価を、より細かい評価に基づいて下せる様になった
- 次の技術面接で見てほしい資質を明確化できた
またルーブリックを定義することで、「今の技術面接の方式は、我々が気にする12個の資質を見るのに適切か」や「技術面接の回数は、12個の資質を見るのに十分か」といった議論がおき、面接プロセス自体を見直すこともできるようになりました。
Future Works
採用を改善するためにはまだまだできることはあります。
- ルーブリックを改善していく。今回は一旦エンジニアの採用にフォーカスして初版をつくりましたが、運営していく上で改善したり、会社のステージに合わせて変更し、他の職種や全社的に合わせて改善していく必要があります。
- 技術試験問題を社内で共有・評価しやすくする。これまでは技術試験問題を Google Docs で共有していましたが、ちょうどよい問題を見つけるのが難しかったり、問題の議論をやりづらいという問題がありました。現在はJiraを使えないか検討中です。
- 面接官を育てる。今までは中途採用で面接経験のある社員が面接を担当していましたが、今後はより面接官を増やしつつ、一貫した評価を持てる用に訓練を積んでもらう必要があります。そのために他の面接官の面接に参加し、フィードバックだけを書くシャドーイングなどのプロセスを設定していきたいです。
最後に採用についていちばん大事なことを……FLYWHEEL ではソフトウェアエンジニアを募集中です！