Happy Hiring !!

ハッピーなエンジニア採用について書いてます

募集要項テンプレートを使って開発チームにインタビューしてみた -1-

f:id:sezemi:20170817150029j:plain Joshua Ness

これまでの Happy Hiring !!

  1. 連載第1回では Happy Hiring !! でやろうとしていることをまとめました
  2. 連載第2回ではエンジニアの応募に繋がる募集要項を考えてみました

今回は第2回でまとめた募集要項テンプレートをもとに、実際に自社の開発チームにインタビューしたので、その模様をお届けします。
また、インタビューしてみると、募集要項テンプレートの問題点があったので、その改善内容もまとめています。

開発チームへのインタビュー準備

開発チームとインタビューでは 打合せ時間 = 開発時間の減少に繋がるため、出来る限り、時間を抑える必要があります。
このため、事前に募集要項テンプレートを開発チームに共有し、回答してもらいました。

開発チームの事前回答

開発チームの主力メンバーとチームリーダーにお願い、回答してもらいました。

事前調査をみた感想

インタビューをスムーズに進行させるため、事前にザッと回答内容を見てみました。

  • 課題が多いため、抽象度の高い回答になっているなぁ
  • ”サーバスペックの定期監視” のような掴みにくい表現もある
  • 深掘りする必要がありそうなので、それぞれの回答に質問を2つ用意
    • Q.これはどういうことを指しているのだろう?
    • Q.これはなぜ問題なのか?

開発チームにインタビュー!!

hitorigoe と sep-mk の同席のもと、それぞれの回答内容を深掘りする質問を中心に、インタビューしました。
(インタビュアー:広瀬 [Q]、インタビュイー:開発チーム[開発])

質問:あなたに何を解決してほしいのか?

  • サービスの品質チェック
    • Q. これはどういうことですかね?
    • 開発 これは募集対象のサービス開発体制が1人なので、実行結果を非エンジニアが見て、問題なければリリースになっているという状態を指してます
    • Q. なぜ、これは問題になるんですかね?
    • 開発 この状態だとコードレビューできず、たまたま今はOKでも、将来的なバグに繋がったり、可用性や拡張性などに配慮したコードになってるか不安なんです
    • (私のメモ)新しいメンバーには、ゼロからコードレビュー体制を一緒に作って欲しい、ということが期待される
  • 開発チームのクロス体制
    • Q. 続いて、これも説明お願いします
    • 開発 ↑にも関連しますが、病気など不足の事態で自分が長期離脱した場合、 :scream: なことになるので。。 ((((;゚Д゚))))ガクガクブルブル
    • (私のメモ)新しいメンバーには、早く来て欲しい、、
  • 技術ドリブンのサービス改善
    • Q. 続いて、こちらはなんとなくわかりますが、説明もらってよいです?
    • 開発 新しい技術をどんどん検証して、現在のサービス改善に繋がりそうであれば、提案・適用していく、ということが出来ていないんです
    • Q. これが問題に挙がるのはどうしてでしょう?
    • 開発 技術の進化に伴って、パフォーマンスが改善されたり、開発そのものを効率化し、その分、もっと機能拡張につなげたり、といった技術進化の恩恵をサービスのユーザーに提供できてないのが問題なんです
    • 開発 例えば、機械学習、深層学習の技術で、例えば、受講ログをもとにテスト問題の配信や学習スケジュールの設定などに繋げる、などが考えられますね
    • (私のメモ)新しいメンバーには、技術のキャッチアップと、それによりユーザー体験がどう改善するのか、そういったことが好きな人が合いそう
  • サーバスペックの定期監視
    • Q. 続いて、こちらは読んで分からなかったので詳しくお願いします!
    • 開発 いま外部のデータセンター保守会社に監視をお願いしていて、ログ等のメトリクスを定期監視出来ていない状態なんです
    • Q. ふむふむ。なぜ、これは問題になるのでしょう?
    • 開発 これだと、問題が起きてから、後手に対応するということになってしまいます。幸い、大きなトラブルが起こったことはないんですが
    • 開発 なので、自社でログなどの監視体制を作って、予兆を把握して、障害などの先回りをする、という状態にしたい、ということですね
    • (私のメモ)新しいメンバーには、こういったインフラ寄りのログコレクションや結果を見える化する、ヘルシーチェックにも手を出してみたい人が良さそう

以上のようにまとめながら、優先度を決めようとしたところで、1時間近くになってきました。 実際のログ

また、インタビューしていると、課題がとても抽象度が高く、事前回答で挙がった現状の開発も抽象的になっています。
これでは応募者がみたときに、具体的なスキルや技術が抜けてしまって、手を動かして解決しているイメージが湧きません。。

インタビューを一旦終了 -> テンプレート見直し

現状の開発や開発チームに質問も残っていたのですが、掘り下げるのに時間が掛かるため、テンプレートを見直して、改めてインタビューを設定することになりました。。orz

将来の課題と現状との差分を取れば、具体的なスキルや技術が出てくると思ってましたが、見通しが甘かったようです。

何が問題だったのか

テンプレートの問題

挙がった問題や課題の抽象度に比例して、解決方法も抽象度が高くなってしまうため、Tobeに関する質問もしくはAsisの質問、どちらかを具体化する必要があります。

となると、Tobeの解決方法は候補者が具体化することであり、Asisを具体化するほうが良さそうです。
そこで修正したテンプレートが↓です。

  • あなたに何を解決してほしいのか? (Tobe)
  • 現在どういうプロダクト/サービスを、どういう技術を使って開発しているのか? (Asis)
  • 誰と解決するのか? (with who)

改訂した 募集要項テンプレート

インタビュー時間の問題

やってみると、1時間はあっという間に終わります。
このため、時間が許す限り、オンラインで、開発チームが何を意図しているか読めば分かるところまで深掘りする必要があります。

とはいえ、はじめて開発チームにインタビューする場合、少なくとも1.5時間は想定したほうがよさそうです。

まとめ

  • 募集要項テンプレートを使って、実際に自社の開発チームにインタビューしてみました
  • 解決して欲しい課題が見える化されたものの、抽象度が高く、具体的なスキルや技術に言及できませんでした
  • 一旦、インタビューを終了し、テンプレートを見直しました
  • 現在どういうプロダクト/サービスを、どういう技術を使って開発しているのか?、という質問に変えてみました

では、これで2回目のインタビューをやってみます!

来週もお楽しみに!!
Happy Hiring !!