技術面接の継続的改善について - ウェルスナビ開発者ブログ

はじめに

こんにちは、ウェルスナビでフルスタックエンジニアをしている水馬です。今回は趣向を変えて、ウェルスナビの技術面接についてお話ししたいと思います。

ウェルスナビでは、フルスタックエンジニアという職種が重要な役割を果たしています。このポジションは特定の技術領域に限定されることなく、事業やプロジェクトを技術的な視点から成功へと導く役割を担っています。そのため、求められるスキルセットは多岐に渡り幅広い専門性と他チームとの調整能力、さらには経営レベルの意思決定に関与することもあります。

特定の技術領域に特化しないという性質上、採用における候補者の見極めの難易度は高くなります。本記事では、ウェルスナビの技術面接の継続的改善についてお話ししたいと思います。

※ 本記事は「技術面接」に特化した内容となっています。人物評価やカルチャーマッチの観点については述べていません。

※ 本記事での取り組みはフルスタックエンジニアポジションに限った内容となっています。他のポジションでは異なる選考フローを実施しています

※ ポジション充足により2023.05の時点で、フルスタックエンジニアの採用は一旦中断していますが、近々募集を再開予定です!。

技術面接の継続的改善の必要性

エンジニアの皆さんであれば「継続的改善」の考え方に馴染みが深いのではないでしょうか。これは一度きりの設計で完了とするのではなく、反復的なフィードバックを活用して絶えず改善を続けるという考え方です。この思想はソフトウェア開発やマネジメントなど絶対的な正解が存在しない分野でよく用いられます。

技術面接においても同様の考え方を適用できると考えています。言うまでもなく、全てのポジションにマッチする面接手法のようなものは存在せず、会社、ポジションごとにその設計方針は異なります。

危険なのは明確な採用方針を定義せずに、曖昧な状態で技術面接を進めてしまうことです。以下に私が過去に経験したいくつかの事例を挙げてみます。

技術面接に関係ない候補者のパーソナリティや職務経歴が評価に影響を与えてしまっている
他社の方法を無批判に模倣する（「あの有名企業がやっているからウチもやろう！」）
課題の出題傾向が面接官の興味(趣味)に偏ってしまう
面接官によって評価基準がブレる

とはいえ、いきなり完璧な技術面接を設計することは不可能です。実際、弊社フルスタックエンジニアの採用過程でも過去にこういった傾向が見られました。そこで、次のような取り組みを通じて技術面接の継続的な改善に取り組んでいます。

【継続的改善のためのステップ】

候補者からどのような能力を引き出したいのかを言語化する
技術面接のフィードバックを定期的に集める
合否の理由を明確にテキストに残す
候補者からもフィードバックを得る
面接官のトレーニングを行う
面接官をスケールさせる

次項からは各項目を詳しく紹介していきます。

1. 候補者からどのような能力を引き出したいのかを言語化する

この工程は継続的改善の前段階にあたるステップです。このステップをベースに技術面接の改善フローを回すことになります。まずは、技術面接の中で候補者のどういった能力を引き出したいか？を言語化します。*1 このフェーズで他社の受け売りや、実際の業務に沿っていない課題を出すことは避けたほうが良いです。また、この時によくある傾向として、面接官の得意な技術領域に課題の比重が偏ってしまうことが挙げられます。そういったことを防ぐためにも、候補者からどう言った能力を面接で引き出すべきかを面接官のみならず、採用担当者やマネージャーといった関係者全員で共有することが重要です。

弊社フルスタックエンジニアの技術面接では主に2つの技術試験を行っています。

1.コーディングインタビュー(30~45分)

この試験では特定のお題に基づいて候補者にその場でコードを書いてもらいます。フルスタックエンジニアにはアーキテクチャの設計だけでなく、実際のコードを書く能力も求められます。この試験ではある程度慣れ浸しんだ言語が一つ以上あることを求めています。複雑な処理や考え方が必要になることもありますが、高度なデータ構造とアルゴリズムの知識を求めているというよりは、複雑な問題に対処できるレベルでコードの表現力を有しているかどうか評価しています。(もちろんデータ構造とアルゴリズムの知識があるに越したことはないですし、すでに十分な能力を持っておられる方は、その点を評価できる仕組みになっています

2.アーキテクチャデザイン(45分~60分)

フルスタックエンジニアはアーキテクトとしての能力が求められます。そのため、アーキテクチャデザインの試験では、ホワイトボードを使って候補者に特定のシステムのアーキテクチャを設計してもらいます。この試験では、候補者がアーキテクトとしての視点を持ち、技術的な議論を通じて他者とコミュニケーションをとれるかを評価します。

また、いずれの試験もこちらから特定の技術スタックを指定することはありません。例えば、弊社ではJavaやTypeScript、クラウドにはAWSを使う機会が多いですが、現時点でこれらの技術に精通していないからといって評価に影響することはありません。プログラミング言語においては、一つの言語に十分に精通している場合、新たに別の言語を取得することは優秀なエンジニアであれば比較的に容易であると考えているためです。また、アーキテクチャデザインの観点においても、基本的な技術要素、設計思想の勘所は特定のクラウドベンダーに依存しないと考えています。(例えば、キューの考え方、分散システムの考え方、NoSQL,とRDBの違い..等)

*1 「候補者の能力を引き出したいのか」という表現をあえて選んだのは、面接官が候補者の能力を十分に引き出せない可能性があるという点を常に意識しておくべきだと考えているためです。残念ながら不合格のご報告をせざる得ない場合であっても、それはもしかすると面接官が十分に候補者の能力を引き出せていなかっただけの可能性もあります。

2.技術面接の定期なフィードバックを受ける

課題の難易度設定が適切でないと、候補者の能力を十分に引き出すことができません。特にアーキテクチャデザインの試験では、非常に抽象度の高い課題を解いてもらうことになるため、面接官には高いファシリテーション能力が求められます。面接官がファシリテーションを怠った場合、候補者はどの方向性で議論を進めて良いのかわからなくなってしまい、本来の能力を引き出すことが難しくなります。(自分もファシリテーションが至らなかったと反省することがよくあります..

課題の難易度や面接官のファシリテーション能力を評価するために、定期的に技術面接のフィードバックを受けることにしています。最近では、CTOに候補者役を演じてもらい、面接官としての役割が適切に果たされているかを評価してもらいました。

3.合否の理由を明確にテキストに残す

当たり前のことに思われるかもしれませんが、合否の判断は必ずテキストとして残すようにしています。これは不合格となった候補者に対しても同様です。合否の根拠をテキスト化することで、面接官の評価のばらつきを防ぐことができます。もし非合理的な判断が行われていた場合、人事部やVPoE、CTOがその判断を修正することが可能となります。

合否の根拠には以下の項目を含めています。

成果物（ソースコード、ホワイトボードの内容）
合格基準（設計であれば、「A,B,Cの観点が述べられていること」、「D,Eにも気付けたらA評価」といった形式）
成果物の中で評価に値した部分（ソースコードやホワイトボードに書かれたもの、候補者の発言等）
合格基準がどの程度満たされたのか？
合格基準以外で評価すべき点があるか？その場合その詳細
上記を踏まえた総合評価（C～S、B以上が合格基準）
面接官が原因で候補者の良さを引き出せなかったポイント（ファシリテーション能力の欠如や機器トラブルなど)

また、これらの評価シートは面接後にすぐ書くことをお勧めします。面接直後に書くことで、面接官の記憶が鮮明な間に評価を行うことができます。評価シートへの記入を1日遅らせてしまうと、有力な候補者が他社に内定を決めてしまうかもしれません。選考フローを1日でも早く進めることは人材獲得において非常に重要であると考えています。

4.候補者からもフィードバックを得る

面接官が候補者からのフィードバックを収集することも重要です。候補者からのフィードバックを得ることで、課題の難易度設定や、自分が気付かなかった面接官の問題点に気付くことができます。弊社ではフィードバックを得る手段として、候補者に対しGoogle Spread Sheetを用いたアンケートのご協力をお願いしています。

候補者からのアンケートを収集する際には、以下の項目を確認しています。

コーディングインタビューの難易度 (5段階)
アーキテクチャデザインの難易度 (5段階)
面接時間の長さ(5段階)
自分のスキルをアピールできたと思うか(5段階)
面接官は候補者のスキルを引き出せていたか(5段階)
面接体験の総合満足度(5段階)
その他コメント(自由記述)

アンケートへの回答は任意としているので全ての候補者から回答を得れるわけではありませんが、意外と自己評価と候補者評価が一致せず驚くことがあります。(総じて自己評価の方が高い)

興味深い傾向として、6番の「面接体験の総合的な満足度」に関しては、半数以上の人が5（最高評価）をマークしているのに対し、その他のより具体的な質問項目では5の評価が付くことがほとんどありませんでした。(どの項目も3.5~4の間くらいです) つまり、こちらから具体的な質問を投げかけない限り候補者としては「良い面接だった」と評価するしかなく、面接官としては誤った評価認識が定着する可能性があると学びがありました。アンケートの内容についてもどう言ったフィードバックを得たいのかを言語化した上で項目を吟味する必要があります。

アンケート回答率を上げる方法としては、あらかじめアンケート用のQRコードを用意しておき面接後に候補者にその場でアクセスしてもらうといったことが挙げられます。その際も強制的なニュアンスを出さず、あくまで任意のお願いであり採用結果には影響しないことを改めて強調すると良いと思います。

5.面接官のトレーニングを行う

ここからの内容は弊社もまだ十分に取り組めていない内容です。

コーディングインタビュー、アーキテクチャデザインを行うにはそれなりの訓練が必要になります。こちらから候補者の技術スタックを指定することはないため、面接官は不慣れなコードであってもある程度候補者が書いたコードの意図を理解できる必要があります。また、アーキテクチャデザインに関しては、技術面だけでなく前述したようなファシリテーション能力や、候補者の回答に対して適切にフィードバックを返すことが求められます。面接官が安定したパフォーマンスを発揮するためには、専用の訓練が求められます。また、面接官の中で評価の基準がブレないよう、面接に臨む際の心構えや評価軸をドキュメントで共有する必要があります。

6.面接官をスケールさせる

弊社はフルスタックエンジニアの面接を行える人間が現状筆者一人しかおらず、選考フローにおいて面接官がボトルネックになる状況がしばしば発生します。こう言った状況を防ぐためにも面接官の人数をスケールさせることは人材獲得競争において必須と言えます。

この活動については4.と合わせて引き続き改善に取り組んでいきたいと考えています。

まとめ

本記事では、技術面接における継続的な改善の重要性と、弊社（フルスタックエンジニアポジション）での取り組みについて紹介しました。技術面接の設計には正解が存在せず、自社の事業や文化に合わせて適切な設計を行う必要があります。「技術面接で候補者からどのような能力を引き出したいのか」を明確に言語化し、関係者に共有することで、継続的な改善を行うことが重要です。

我々もまだ改善の道なかばではありますが、本記事が皆様の技術面接の改善に少しでも役立てば幸いです。

ウェルスナビでは、一緒に働く仲間を募集しています。

https://hrmos.co/pages/wealthnavi/

筆者プロフィール：

水馬拓也(みずまたくや) 2022年2月ウェルスナビにフルスタックエンジニアとして入社。前職はAmazon Web Service Japanでソリューションアーキテクトとして働いていました。好きな技術はフロントエンド、AWSです。