面談の話
LITALICOでは、数百名規模のエンジニアがさまざまな案件に参画しています。エンジニアが案件に携わる際、顔合わせや面談を実施しています。本記事では、面談で受け入れ側がどのような話をし、どのような観点で判断しているかをご紹介します。
面談と一口に言っても、形式はカジュアルなものからフォーマルなものまで多岐にわたり、正社員、アルバイト、業務委託など雇用形態や契約形態もさまざまです。また、成長を期待して採用するのか、即戦力を求めるのかによっても面談の期待値は異なります。本記事では、特定のプロダクトやプロジェクトへの参画において、短時間で総合的な適性を判断するための面談を想定しています。主に受け入れ側の視点で記述していますが、面談を受ける方にも参考になる部分があるかと思います。
本記事は筆者個人の考えや経験をまとめたものであり、面談の観点は担当者や案件ごとに異なります。また、LITALICOとしては法令やガイドラインを遵守し、採用や面談を実施しています。
弊社VPoEの亀田さんの記事もぜひ併せてご覧ください。
触れない話題
- 雇用・契約形態の詳細
- 単価やコスト
- 面談テクニックやマナー
面談の流れ
- あいさつ
- 業務（会社）説明
- 職務経歴の紹介・自己PR
- 受け入れ側の質問タイム
- エンジニアの質問タイム
- お礼、終了
面談の時間は1時間を設定することが多いです。時間配分は柔軟に対応し、質問も自由なタイミングでその場の流れで行っています。
心構え
面談でわかることは限られる
いきなりで身も蓋もないですが、面談で得られる情報は限定的です。
どんな印象を受けたとしても、一緒に働いてみると想定外のギャップが発生することもあります。エンジニアの性質がより明らかになるにつれ、それらに対応したハンドリングの方が重要だったりします。発生したギャップをどう埋めていくか、または活用していくことについての見極めや判断も受け入れ後の方がずっと長く続いていきます。面談は重要ですが、その印象に固着し過ぎずダイナミックな動きも視野に入れておきます。予めいくつかの稼働パターンを想定しておけると右往左往することなく動きやすいです。
出来るだけ言葉にする
情報の整理は後からでも出来るので、面談では可能な限り言葉にして情報を伝えることが重要です。こちらのアウトプットは相手のインプットとなり、それがまたアウトプットに繋がります。お互いの解像度を上げていくには、ノイズも込みで多くの情報が必要です。
即時的なレスポンスが苦手な方は、自分のスキルや経験を伝えられるように、Githubでのコード公開や、開発や設計について文章での発信があると、イメージを共有しやすくなります。面談する側、される側も判断材料不足でせっかくの機会を逃さないようにしたいところです。
求める人材
重視しているのは、全体目標や優先順位を意識し、そのフェーズにおける求められる役割を理解し動いてくれる人材です。例えばアーキテクチャ設計や戦略を立てている段階では、柔軟に可能性を検討したい為、多様な意見出しや提案を行ってほしいと思います。一方で、開発の枠組みが決まりリソースを投入しタスクをどんどん片付けていくようなフェーズまで進んでいる場合、ちゃぶ台のひっくり返しをされたり、不要な停滞を招くような動きは避けたいものです。想定工数やスケジュールに沿ったマネジメントを行う観点では、特に以下のようなメンバーを重宝します。
- 現場のやり方、文化に合わせ柔軟に対応出来る
- 標準的なペースで物事を進められる
- 円滑な意思疎通が可能
経歴書で見ているところ
案件で採用しているアーキテクチャに近いスキルセットを持っている方はキャッチアップが早いという意味で歓迎されるもしれません。しかし、例えば一言に同種のFWを扱ったことがあるといっても、その利用方法が一緒とは限りません。かえって固定観念に支配されて理解の妨げになることもあります。大事なのは、アーキテクチャの採用意図や運用のメリットデメリットを把握していることです。
大きな企業に所属していた方はOJTがしっかりしていて、また仕事の進め方など基本的な素養が身についてる事が期待できます。中小での経験がある方は幅広く役割を担当する事が多いので一人で何でもこなしてきた方かもしれません。
所属、勤続年数が短いスパンで繰り返されている場合があります。我々はある程度長い期間ともに仕事をしたいと考えている会社なので、その理由を気にして聞きます。
経歴書だけでも、どのようにしたら読み手が求める情報を的確かつ簡潔に伝えられるかの工夫を見て取ることができます。相手が知りたいことを推察し表現出来ることはアウトプットの能力そのものです。
質問タイム
質問タイムでは、気になったポイントを掘り下げ、話を広げていきます。定型の質問項目というのはほとんど持ちません。
例えば以下のような調子です。
コーディング
- 😺「コードを書くときに意識していることは何ですか」
- 🥴「可読性を意識し、わかりやすさを重視しています」
- 😺「可読性は何によってもたらされると思いますか」
- 🥴「変数名を省略しないこと、コメントをしっかり残すことです」
- 😺「コメントを残さないと設計意図が伝わらなくなってしまう状況はどうしたときに発生しやすいと思いますか。それを回避するにはどうしたらいいでしょうか」
分析、キャッチアップ
- 😺「システム概要や勘所を掴む為に、どういったアプローチをとりますか」
- 🥴「業務理解をするところからはじめます。その上でユースケースを整理し、コアなアクションの入出力のIFを見ていきます」
- 😺「それらの整理をする際に視覚的に分かるようなツールや手法など使われているものはありますか」
- 🥴「ユースケース図やラフなシーケンス図を書いたりします」
- 😺「複数のシステムや機能をグループ化して整理していくときに、どういった基準で分けて見ていきますか」
受け答えに明確な正解はありませんが、表面的な回答ではなく、対象についてどれだけ理解を深めているかを見て取れます。
質問を重ねていく中で、技術面で問題なさそうと判断できたら、その方の最もリスクになりそうなところへ話題を切り替えていきます。優先順位は以下になることが多いです。
- 技術面
- タスクの進め方、コミュニケーションの取り方
- 課題解決能力、タスクを開始できる仕様の粒度
- チーム、メンバーとの相性
- 環境、体調、時間の制限等
人への向き合い方
チャット等のテキストベースのやり取りではなく、実際の対話でしか分からないことがあります。例えば、話しやすさです。威圧的だったり、否定的な言葉使いが多いと、それだけで普段のコミュニケーションに支障が出る可能性を考えてしまいます。
質問への回答は、質問の意図を汲んでくれているか、また回答が難しい内容の場合にどのように応えるか、質問者が回答内容をよく理解できなかった場合にどのように説明してくれるかなど、正直さや誠実さも見ていきたいところです。
この辺りの印象は、一緒に働いたときのイメージに直結しますから意外と大きなウェイトを占めていたりするものです。
採用可否の判断
採用は時間との勝負です。人材は他の案件との取り合いでもあるので、迅速な判断が求められます。人材は製品ではないのですから、こちらの期待する型に無理に収められるものでもありません。特性を理解し、学習してもらい、それぞれの強みを活かしながらチームを作っていくものです。最終的には、面談を通しての総合的な印象を持って、その方と一緒に働くイメージが持てるかで決めています。
正社員採用や責任あるポジションの場合、さらに多くの慎重さが求められますが、判断のベースとなるのは共通です。
記事を書いての感想
この記事は、自身の面談経験を整理するために執筆しました。冒頭でも触れましたが、面談の重視ポイントは案件や人によって異なるため、必ずしも一般化できるものではありません。フィーリングの要素が多い気もしますが、実際そんな感じです。
実績として、これまで筆者が担当して参画頂いた方たちは優秀な方が割合として多かったと思います。逆に採用後問題があった場合は、思い返してみれば面談のときに違和感を感じていた部分が顕在化してしまったなという印象です。
皆さんの面談・採用活動のヒントになれば幸いです。