エンジニア面接で「開発力」を見るために聞いていること
こんにちは！AnotherBall Avvy事業部でテックリード 兼 技術責任者をやっている @fortkle です。普段はプロダクト開発をしつつ、サーバーサイドエンジニアの一次面接も担当しています。
最近、その面接で使っている質問の聞き方を少し変えました。大きく面接プロセスを変えたわけではなく、これまで一つの設計に関する質問として聞いていた内容を、いくつかの段階に分けた程度です。
ただ、なぜ質問を分けたのかを振り返ってみると、私たちがエンジニアの「開発力」として何を見ようとしているのかが、よく現れていることに気づきました。この記事では、実際に面接で使っている質問を一例として紹介しながら、その背景にある考え方について書いてみます。
面接の中で、プロダクト開発を少しやってみる
サーバーサイドエンジニアの一次面接では、Avvyで実際に起こりそうなプロダクト開発を題材に、候補者の方と会話する時間を設けています。私がPdM役となって、まだ詳しい仕様が決まっていない相談を持ちかけ、候補者の方にはAnotherBallのサーバーサイドエンジニアとして考えてもらいます。
面接の途中で、次のように伝えます。
ここからは、私がAvvyのPdM役として相談します。
AnotherBallのエンジニアとして、必要なことを自由に質問してください。
質問には私がPdM役として回答します。候補者の方には、その回答を受けてさらに質問を深めたり、要求や前提を整理したりしながら、何を作るのかを具体化し、技術的な設計へ進んでもらいます。面接の中で短時間だけ、AnotherBallでのプロダクト開発を一緒に進めてみるような形式です。
例えば、以下のような題材です。
- イベント期間中にギフトランキングと現在の順位をリアルタイムで表示したい
- Avvyでは、ユーザーは配信者のライブ配信を視聴しながら、配信中にギフトを送れます
- アプリ内では定期的にイベントが開催されており、期間中の応援（ギフトなど）により獲得したポイントをもとに、他のユーザーとランキングを競います
- 一定の条件を満たしたユーザーだけが参加できるイベントを作りたい
- 例えば「一定期間内に初配信をした」「コインの獲得数が一定以上」といった条件のイメージです
- 配信できない日でもリーグ降格を防げる仕組みを作りたい
- Avvyには配信者が参加する「リーグ」というランクに似た仕組みがあり、日々の配信の成果に応じてリーグが上がったり下がったりします
Avvyの現在の実装や、私たちが採用しているアーキテクチャを当ててもらいたいわけではありません。曖昧な相談を受けたときに何を質問するのか、PdMから返ってきた回答をどう解釈するのか、最初に考えていた案を会話の中でどう更新していくのか。そういったことを知りたいと考えています。
今回は、この中から「イベント期間中にギフトランキングと現在の順位をリアルタイムで表示したい」という題材を例に説明します。
「ギフトが送られたら、ランキングへリアルタイムに反映したい」
今回の例では、イベント期間中に送ったギフトをもとに、ユーザー同士でランキングを競うものとします。ここで、PdMとして次のような相談をします。
ギフトが送られたら、ランキングへリアルタイムに反映したいです。
まだ詳しい仕様は決まっていません。この相談を受けて、あなたがAnotherBallのサーバーサイドエンジニアだったら、どのように進めるでしょうか。
一つの質問で見ようとしていたものが多すぎた
以前は、この相談を伝えたあと、そのまま「どのように進めますか？」「どのように設計しますか？」と聞いていました。実際のプロダクト開発でも、雑談ベースで整理されていない相談から始まることもあります。
一方で、以前の聞き方では、面接官から最初に共有する情報と、候補者に質問を通じて引き出してほしい情報が整理できていませんでした。さらに、その一連の回答から、要求を整理・理解する力、技術的な設計力、異常系への対応力といった複数の観点をまとめて評価しようとしていました。
そのため、候補者の回答に考慮が足りない部分があったときも、候補者が必要な前提を確認できなかったのか、面接官の説明が不足していたのか、あるいは設計力そのものに課題があったのかを切り分けにくい状態でした。
これらを整理しないまま質問すると、「情報が足りない問題を自由に解いてください」とお願いすることになります。
例えば、相談を聞いてすぐにRedisやWebSocketを使った設計の話を始めた人がいたとします。それは要求を整理する力が不足しているのでしょうか。それとも、面接官から設計問題を出されたため、すでに仕様は決まっているものとして回答しただけなのでしょうか。
反対に、細かな仕様をたくさん質問できたとしても、確認事項の数が多ければよいわけではありません。PdMから返ってきた回答を受けても次の質問や設計が変わらないのであれば、実際のプロダクト開発で行う会話とは少し異なります。
考えてみると、この質問では大きく三つのことを見ようとしていました。
- 曖昧な相談から、背景にある要求や必要な条件を整理できるか
- 整理された条件をもとに、技術的な設計を考えられるか
- 欠落や重複など異常が起きても、あとから回復できるように考えられるか
それならば、一つの大きな質問ですべてを見ようとせず、段階を分けた方がよいのではないかと考えました。
そこで、質問を3段階に分けた
現在は、同じ題材を使いながら、質問を大きく三つの段階に分けています。
1. まず、PdMに何を確認しますか？
最初は、技術的な設計をすぐには求めません。
PdMから「ギフトが送られたら、ランキングへリアルタイムに反映したい」と相談されました。
まず、PdMに何を確認しますか？PdM役の私に自由に質問してください。
ここでは、まだ曖昧な「リアルタイムランキング」という言葉から、設計に必要な条件を整理しようとするかを見ています。例えば、次のようなことが会話の中で論点になります。
- なぜランキングをリアルタイムに更新したいのか
- 誰に、どの画面で見せたいのか
- どの程度の遅延までを「リアルタイム」と考えるのか
- 画面上の一時的なズレは許容できるのか
- 最終順位にも同じ即時性が必要なのか
ただし、これらをすべて質問できたかどうかを、チェックリスト形式で採点しているわけではありません。PdM役から返ってきた回答を受けてさらに質問を深められるか、最初に持っていた仮説を更新できるかといったことも含めて対話します。
2. 共通の条件を渡して、設計してもらう
要求や前提についてある程度会話したあと、面接官から共通の条件を伝えます。例えば、以下のような条件です。
- ランキングへの反映は10〜30秒程度遅れてもよい
- 配信中の画面では自分の順位を表示する
- イベントページのランキング画面では上位100人の順位を表示する
- イベント終了直前にはギフト送信が大きく増える可能性がある
- 画面上の順位には一時的なズレを許容する
- 最終順位は報酬に使うため、正確でなければならない
そのうえで、次のように聞きます。
この条件であれば、サーバー側をどのように設計しますか？
ここで候補者ごとに共通の条件を渡しているのは、要求を整理する力と、技術的な設計力を少し分けて見たいからです。自分で聞き出した情報だけをもとに設計してもらうと、質問によって得られた情報量の違いが、そのまま設計問題の難易度の違いになってしまいます。
そのため、第1段階ではPdMとの会話を見たうえで、第2段階では同じ条件を渡し、その条件に対してどのような設計を考えるのかを会話します。ここでは、Redisや特定のクラウドサービスの名前を答えられること自体を評価したいわけではありません。
事実として確定したギフトの記録はどこに、どのように残すのか。表示用のランキングをどのように作るのか。画面表示と最終順位の確定を分けるのか。条件に対して、なぜその設計を選んだのかを聞いていきます。
3. 最後に、一つだけ失敗を起こす
正常系の設計について話したあと、最後に一つだけ失敗する条件を加えます。
ギフトの送信処理には成功しましたが、ランキングへの反映処理に失敗しました。
このような状況が発生する場合に備えてどのような点を考慮すべきですか？
ここでは、ギフトの記録と、画面に表示するランキングを分けて考えられるか等を見ます。他にも失敗した処理を再実行できるか、同じ処理が複数回動いても二重に反映されないか、正式な記録からランキングを再計算できるか、といったことを会話します。
正式な記録と派生データを分ける考え方や、再実行と冪等性の扱いなど、書きたいことは別にありますが、長くなってしまうためここでは概要にとどめます。
実際のシステムでは、すべての処理が毎回予定どおりに完了するとは限りません。途中で失敗してもデータを失わず、あとから回復できるように考えることも、サーバーサイドエンジニアの開発力の一つだと思っています。
なぜ最初に「まず何を確認しますか？」と聞くのか
ここまでのうち、今回特に書きたいのは、最初に「まず、PdMに何を確認しますか？」と聞いていることです。完成した要件をもとに技術設計ができることはもちろん重要ですが、実際のプロダクト開発では、最初から「表示は10秒以内」「一時的な不整合は許容する」「最終順位は正確にする」といった要件がきれいに整理されているとは限りません。
最初に出てくるのは、
リアルタイムにランキングを更新したい
という、まだ背景や目的が十分に言語化されていない相談であることも多いです。そこからPdMと会話し、何を実現したいのかを理解し、技術的な条件へ具体化していく。私たちは、そのプロセスも含めてエンジニアの「開発力」だと考えています。
要件は、会話の中で具体化される
以前、個人ブログで「要件ではなく要求を正しく理解するために」という記事を書きました。その記事でも触れましたが、私は「要求」と「要件」を次のように分けて考えています。
- 要求：ユーザーや事業に、どのような状態や価値を実現したいのか
- 要件：その要求を実現するために、システムが満たす具体的な条件
今回の「ギフトが送られたら、ランキングへリアルタイムに反映したい」という相談は、一見すると具体的な要件のように見えます。特に「リアルタイム」という言葉が入ることで、「リアルタイムなランキングをどう実装するか」という技術的な問題に見えやすくなります。
しかし、この時点では「リアルタイム」が何秒程度を指すのかも、なぜリアルタイムにしたいのかも分かっていません。もしかすると、PdMが実現したいことは次のようなことかもしれません。
ギフトを送った結果がすぐに順位へ反映されることで、イベントの盛り上がりを感じてほしい
この要求が分かって初めて、1秒以内に反映されなければ体験が成立しないのか、10秒や30秒程度の遅れなら許容できるのか、一時的な順位のズレを許容できるのか、最終順位にはどの程度の正確性が必要なのか、といった会話ができます。
つまり、「リアルタイムランキング」という言葉には、要求を実現するための解決策がすでに少し混ざっているのだと思います。
その要件は、本当に必要条件なのか
アジャイル開発の入門書としてよく読まれている『アジャイルサムライ』を読んだときに印象に残ったのが、「要件」という言葉によって、それが最初から必要不可欠で、交渉できないもののように扱われやすくなる、という話でした。
例えば「リアルタイムであること」をそのまま固定された要件として受け取ると、そこから先はリアルタイムな仕組みをどう作るか、という話になります。一方で、「なぜリアルタイムにしたいのか」まで戻ることができれば、要求を満たすために本当に守るべき条件を考えられます。
会話した結果として、1秒以内の反映が重要だと分かることもあると思います。その場合は当然、それを要件として設計します。しかし、10〜30秒程度の遅延でもユーザー体験を満たせるのであれば、集計やクライアントへの反映方法には、より多くの選択肢が生まれます。負荷やコストを抑えながら、十分な体験を提供できるかもしれません。
要求を理解することは、単にユーザーに寄り添うためだけのものではありません。何を守り、何を緩められるのかが分かることで、技術的な選択肢が増え、より適切なトレードオフを選べるようになります。
要求と要件の間には、会話がある
今回の例を整理すると、次のような流れになります。
ここで大切なのは、要求を聞いたあと、エンジニアが一人で要件を考えることではありません。PdMは、どのようなユーザー体験や事業上の成果を実現したいのかを知っています。一方でエンジニアは、条件によって技術的な難易度や負荷、コストがどう変わるのかを知っています。それぞれが持っている情報を会話に持ち寄ることで、要求を満たしながら実現可能な要件を一緒に考えられます。
こうした共通理解を作る方法の一つとして、Avvyの開発では、新しい機能や体験を考えるときにユーザーストーリーマッピングを使うことがあります。ユーザーがどのような流れでAvvyを使うのかを並べながら、PdM、デザイナー、エンジニアで話し、どの体験が重要なのか、今回はどこまで作るのかを整理します。
ユーザーストーリーマッピングを提唱したJeff Pattonの書籍『ユーザーストーリーマッピング』から学んだことの一つは、完成された仕様をきれいに書いて受け渡すこと以上に、ストーリーをきっかけに会話し、チームで共通理解を作ることが大切だということでした。完成したマップそのものにも価値はありますが、個人的には、マップを作る過程で会話が生まれ、チームの共通理解が作られることに大きな価値を感じています。
面接で行っているやり取りも、実際のプロダクト開発をそのまま再現できるものではありません。それでも、PdMから完成した要件を一方的に渡すのではなく、曖昧な相談から会話を始めることで、普段の開発で大切にしているプロセスを少しだけ一緒に体験できます。
振り返ってみると、面接の最初に「まず、PdMに何を確認しますか？」と聞くことで見たかったのも、まさにこの会話だったのだと思います。
おわりに
エンジニアの開発力というと、プログラミング能力や、データベース、インフラ、アーキテクチャなどの知識を思い浮かべることが多いと思います。もちろん、これらはすべて重要ですし、今回紹介した質問でも、要求や前提を整理したあとは技術的な設計や失敗時の挙動について詳しく会話します。
一方で、実際のプロダクト開発は、完成した要件を受け取るところから始まるとは限りません。まだ曖昧な相談からPdMやデザイナーと会話し、ユーザーに届けたい価値を理解したうえで、技術的な制約や選択肢を伝えながら何を作るのかを具体化していく。そうしたプロセスも含めて、私たちが面接で見たい「開発力」なのだと思います。
これは、エンジニアがPdMの代わりにすべてを決めるという話ではありません。PdMが持っているユーザーや事業への理解と、エンジニアが持っている技術的な知識を、会話の中に持ち寄るということです。
この記事を読んだうえで面接に来ていただいて構いません。題材は面接ごとに変わりますし、見たいのは正解を知っているかではなく、PdM役の回答を受けて質問や設計をどう変えるかです。事前に考えてきていただけるなら、その分だけ会話は深くなると思っています。
もちろん、この形式にも課題はあります。その場で考えを言葉にするのが得意な人に有利で、時間をかけてじっくり考えるタイプの人にはつらい面があるかもしれません。口頭だけに頼らず、図やチャートを示しながら考えを共有できるようにするなど、進め方は改善していくつもりです。
面接の中で短時間だけ、AnotherBallでのプロダクト開発を一緒にやってみる。今後も実際の面接を通じてお互いのことを知る時間にしていきたいです。
We’re Hiring!
AnotherBallでは、プロダクトの要求を理解し、職種を越えて会話しながら、一緒に形にしていくエンジニアを募集しています。Avvyのプロダクト開発に興味を持っていただけた方は、ぜひ採用情報をご覧ください！
参考書籍
- Jonathan Rasmusson『アジャイルサムライ――達人開発者への道』オーム社
- Jeff Patton『ユーザーストーリーマッピング』オライリー・ジャパン