skillup

技術ブログ

プロジェクト管理

採用面接の質問、判定基準について

投稿日:2022年12月3日 更新日:

採用ネタについて色々と書いていますが、自分の社会人生活で人の横で採用を見ていてあまり良くないな・・と思った質問の類と聞いた方が良いと思う質問(採用基準)に対して。

NG系の質問

志望動機

いろんな本でも書かれてましたが、基本意味ないと思います。

理由としてその場でなんとでも言える、嘘か本当かわからない、やりたいことと業務適性があるかは別だからですかね。

別に志望動機がなくても、しっかり仕事してくれれば全く問題ありません。

ただし、行動事実があれば話は別でその場合は評価できるかとおもいます。

やる気

当たり前ですが、採用面接でやる気がないという人はいないので、意味がないです。

言葉ではなんとでも言えますしね・・・

言葉ではなくとも、面接で熱く語る雰囲気的なものをやる気と判断する採用担当者は多いのではないでしょうか。それよりも行動や実績を見た方が良いと思います。

アクシアの米村社長の記事ですが、100%同意です。

人の熱意は信じてはいけない

やりたい仕事

やりたい仕事のために行動している事実があればOKです。

またやりたい仕事は一般的には得意なことが多いでしょうから結果としてパフォーマンスが上がるということはあり得るかもしれません。

そういう側面で聞いているならば別なのですが、会社は基本会社が儲かるために人を雇うのであって、個人がやりたいことをやる場所ではないと思います。

会社のために仕事をして、その対価としてお金をもらうのであって、好きなことをしてお金をもらうという発想は違うと思います。

稀にそれを実現されてる方もいますが、大人でそれができる方は稀ですので、基本はその人に何ができるか、会社の戦力になるかという視点での質問が正しいと思います。

興味のある技術

やりたい仕事と同じ理由でダメだとおもいます。

ただその技術のために積極的に行動している(例:プライベートでの勉強記録など)事実があればOKです。

長所、短所

過去の行動と紐づいていれば別ですが、そうでない場合、自己申告なのであまり意味がないかと思います。

キャリアパスをどう考えているか

そのために行動している事実があればOKなのですが、そうでない場合、嘘か本当かわからず、行動が予測できません。

どういう人生を送りたいか

繰り返しますが、行動している事実があれば評価対象になります。

そうでない場合、ただ「思っていること」なので評価対象になりません。

私は採用時にこういう質問をする経営者の元で働くことが多かったのですが、会社があまり個人の人生観に立ち入らない方がいいと思います。

積極的な質問、発言が多い

この手の方は面接での評価が高く、採用されやすい傾向にありますが、パフォーマンスの予測にはならないとおもいます。

面接対策が上手とは言えるのでしょうが、やはり言葉だけでは行動がわかりません。

また個人的には実際の業務でも会議などで色々と意見は言うが、勤怠がだらしない、勝手な行動が多い、言われたことをやらない、我が強い、積極的にサボると言う方に結構あってきました。

突飛な質問(自分をものに例えるなら?)

こういった質問をして切り返しを見て「地頭」の良さを測ろうとする方は多いと思うのですが、採用側の自己満足に陥っている可能性が高いです。

能力を測りたい場合は過去の行動の事実(未経験ならば類似の経験)をしつこく聞くのが良いと思います。

趣味

業務に直結する意図があるのなら別ですが、そうでないなら全く意味がないと思います。

共通点があって話が盛り上がり、人として楽しいかを見るにはいいと思うのですが、好きかと言う点と仕事ができるのは基本別だと思います。

知識、現時点でのスキル(一部OKの場合も)

エンジニアだと多くの面接で技術的な質問(試験)をすることが多いのですが、正社員の場合、OKになるケースと最適とは言えないケースもあるかとおもいます。

OKだと思う場合

  • 新卒、未経験、比較的経験が浅い方→後述するキャチアップスキルと同義になるため
  • 業務委託→1ヶ月で既存社員と同じ戦力になってもらう必要があるため
  • 緊急度が高い→業務委託と同義。近年のエンジニアの在籍期間の短さを考慮している場合はあり。
  • 先端技術→情報感度やキャチアップスキルと通じるため
  • ベースとなるスキル測定→エンジニアとして変えにくい自力を見るため
  • 技術領域の類似性→技術領域が遠い場合、簡単にキャッチアップができないため

最適解とは言えないと思う理由

個人的にはケースを考慮する必要はありますが、あまり最適解ではないケースもあると思っています。理由としては以下のような点です。

  • 技術的な要素は「変わりやすい」ものの筆頭であり、採用では「変わりにくいもの」を中心に見るべき(変えにくいものをあえて見ている場合はOK)
  • 技術領域が近い場合、短期間でキャッチアップが可能
  • 聞くのであればキャッチアップ行動(プライベートでの勉強)やキャッチアップ経験(新しい技術を獲得している経験があるか)を聞くべき
  • エンジニアの場合、技術的な経験は陳腐化スピードが速いため、現時点でのスキルの価値はそれほど高くない(価値がある期間は短い)
  • 経験を聞くケースが多く、本人の能力以外(会社側の事情など)の要因が大きい

聞くべき、見るべき質問

NG系の質問に関して散々ディスっているので、聞くべき質問に関して書いていこうとおもいます。

基本的に聞くのは「過去の行動」「変わりにくい性質」「普段プロジェクトのアサインメンバーを選ぶときの基準」です。

基本印象値

ともすればコミュニケーション能力に入りそうなのとNG系に少し入れてますが、第一印象や基本的な人当たりです。

変えにくいものなので見るべき項目に入れておきました。

と言っても多少愛想がないくらいであればOKで、どちらかというと以下のような問題のある人を外すと言う感じだとおもいます。(お客さんと折衝する場合は基準値が上がるとおもいます。)

悪い方の場合、組織崩壊につながるので全力で見つけ出す必要があります。

  • 身なりが無頓着な方、見た目が不潔な方(悪い人でないとしても、他人からどう見られるかの意識が低い場合、厳しい。)
  • 喋り方が高圧的な方
  • 正論をそのまま言う方(エンジニアに結構多い)
  • 話し方から自己中心的なニュアンスが感じられる方
  • その他全体的に話し方に嫌悪感を持つ方

エンジニアとしての自力

言語化が難しいですが、変えいにくいエンジニアとしての自力要素です。ある程度経験がある場合、ほぼ能力的なものが決まってしまうため、それを見るという意味で技術的な試験などをやる意味はあるとおもいます。そうでない直近の開発トレンドの狭い領域を聞くのはあまり意味がないかとおもいます。(単に経験の有無&変わりやすい要素のため)

キャッチアップスキル

今あるスキルは変えやすいため、それほど神経質になる必要はないかもですが、新しいスキルを身につける行動は変えにくいので注意深く探る必要があります。

一番いい例としてプライベートで勉強している、そういう勉強会に参加している事実が記録としてある、新技術のキャッチアップをしている経験が多いなどでしょうか。

経験、仕事のスタイル

本人の性格とは関係ないところで、長くやってきた仕事の流儀などは染み付いていると変えるのが非常に難しかったりします。

私も去年までの仕事はウォーターフォール型の案件だったのですが、スタイルが会わずにかなり苦痛でした・・・汗

メンバーがいい人たちばかりだったのと、期間が限定されていたので何とかなりましたが・・

ある程度の経験者の場合、体に染み付いていてもう変えられない場合難しいので、人格的に問題がなく、自走能力があっても適応に本人が苦しみ、周りも迷惑するため厳しいかとおもいます。

勤怠、時間感覚

エンジニアだと働き方が自由なため、ともすれば現実的にはだらしない人が結構多いです。

時間にルーズな人、遅刻癖のある人(=時間に対する意識が低い人)って基本的に治らない、治りにくいので、全力で見つけるべきです。

自分からだらしないを告白する人はいないので、過去にどういう働き方をしているかを注意深く聞くこと。それほどのスキルがないのに週5で働きたがらない方、過度に自由に働いてきた方(業務時間などを自分で決める方)は組織に自分を合わせるのではなく、思うがままに行動する傾向にある方が多く、変えるのは難しいです。

また面接の時間などでベストなのは5分前ですが(早すぎるのも失礼なので)、どのように準備してきたかも聞くようにしたほうが良いとおもいます。

報連相

現状の作業の問題点や進捗度合いなど。どの仕事でも共通で必要になりますが、弱い方は往々にして時間感覚に弱く、仕事では自己中心的な傾向(嫌味な性格とかではなくナチュラルに自己中心的)にあります。

  • ミーティングではどんなことを報告していましたか?
  • 困ったのはどんなことでしたか?
  • その時、どんな行動を取りましたか?

ルーズな人の場合、隠す方は多いので、「そういった作業が好きですか?」「マメに進捗確認などをプロジェクトで求めていますが、問題ないですか?」とセルフスクリーニングするのが良いかもです。

納期意識

時間感覚や報連相と近いのですが、「時間が貴重であるという認識」「仕事を間に合わせようとする」危機感ですね。

これもない方結構います。エンジニアの技術力=流行している技術への知見と思っている方は多いので、変に技術への知見があると間に合わせられないけど自己評価が高い方に結構な確率で会います。

過去に納期をどのように対処したか、納期に困ったエピソードをしつこく聞くようにしましょう。

  • 過去に納期がやばい、きついという場面に遭遇したことはありますか?
  • どのフェーズでどのような意識を持ちましたか?
  • 仕事が間に合わなそうな場合、どういう行動を取りましたか?
  • どのような結果になりましたか?

現実的にはメンバー層だとできることが限られるため、アラートをあげるぐらいが最善策ということもあり得ます。

話が長い、結論がわからない

話が長く、何が言いたいかわからないと単純に疲れるのもそうですが、時間感覚が弱い方が多く、仕事を間に合わせる意識が弱い方が多いです。

変えるのは難しいため、悪い人でないとしてもNGにした方が良いとおもいます。

プロジェクト問題化、改善意識

今プロジェクトで起こっている問題に対しての関心ごとです。

プロジェクトの問題を自分ごととして捉えられるかは、かなり変えにくいとおもいますので深ぼって聞くべきかとおもいます。

  • プロジェクトに対して具体的にどのフェーズでどんなことを問題に思っていましたか?
  • なぜそのように思っていましたか?
  • それに対してどのように行動していましたか?
  • プロジェクトで自他問わず問題だと思った行動はなんですか?

意見衝突時の対応

コミュニケーション能力という言葉を使いたくなかったので、こんな言い方にしてみました。

また組織として問題起こす人はこのスキルが弱い方が多いので(自分の考えを押し通す、押し通せない場合キレる、あるいは最初っから全く無関心)確かめておかないといけない質問の類になるかとおもいます。

要は「自分と異なる意見や行動をとる人があった、いたときにそれをどのように対処したか、相手に伝えたか」で人生全般を通して通じるスキルになります。

  • 異なる意見などが挙がった例を教えてください。
  • 異なる意見が挙がった場合、あなたはどうしましたか?
  • なぜそのように考えたのですか?
  • プロジェクトで他人の行動に対して問題があると思った際にどの考え、行動しましたか?

まとめ

基本的に面接の方針としては以下のようなことがあげられるとおもいます。

  • 行動として見えるものを評価し、印象やその人の意見、希望などは大きい判断材料にしない
  • 印象(その人に対してもった印象)と行動事実(仕事をやる上で本人が取り組んだ行動)を分ける(極端に悪い人は考慮すべき、営業なら印象=能力の一部だとおもうのであり。)
  • 実体がなく測れないものを測ろうとしない(曖昧な「コミュニケーション能力」「地頭」など)。測る場合要件定義が必要
  • 変わりやすいものではなく変わりにくいものをみる(現時点でのスキルよりはスキルのキャッチアップ能力)
  • 実際の仕事で信用しているメンバーを選ぶときと同じ基準で選ぶべき

-プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

プロジェクトでの頻出問題点と自分なりの対策など

エンジニアとして仕事をいろいろしてきまして、計画通りに進んだプロジェクトというのは(私以外の方もそうかもしれませんが)ほとんどありませんでした。 不確定要素が絡むためどうしてもしかたないかもしれません …

no image

使える設計書作成に関して

私自身、この仕事を7〜8年やっておりますが、設計書作成については常に悩まされておりました。 設計書のメリット・デメリットとしては以下のようなものですかね。 メリット メンバー間での仕様の認識を統一でき …

no image

コードレビュー時のポイント

コードレビュー(仕様的な点ではなくて規約的なところのチェック)などで気をつけることなど。 ポイントとしては検知ツールで確認するコストを減らすことが一番大事(カスタマイズの方法について調べておく)、ある …

no image

ファジープロジェクト対策 その2

前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 Contents1 テンプレート共通化2 バリデーション3 ログ出し4 異常系の処理5 新規プラグイン+ …

no image

読書感想文:ITエンジニア採用とマネジメントの全て

前回に引き続き採用の本の読書感想文を 今回読んだ本は「ITエンジニア採用とマネジメントの全て(久松剛)」です。 著者の方は某大手企業で有名なエンジニアリングマネージャーを務めている方でここ10年ぐらい …

アーカイブ