先日、あるブログ記事を読んで、採用観がちょっと変わった。
テーマは「シニア開発者はなぜ専門知識をうまく伝えられないのか」というもの。コピーライターのトゥヒン・ナイール氏が書いた記事で、技術者向けの話なんだけど、読んでいたら採用面接の失敗が頭に浮かんできた。
ナイール氏によると、シニア開発者には2タイプいる。「新しいツールを使えばいい」「ベストプラクティスではこうだ」と言うタイプ。もう一方は「それ本当に必要?」「今あるもので間に合わない?」と問うタイプ。ナイール氏が評価するのは後者だ。
正直、私はずっと前者を採ろうとしていた。「何を作れるか」「どのスタックを知っているか」ばかり見ていた。面接でも「これ実装できますか」という質問が多かった。でも本当に聞くべきだったのは、「いらないものを作らない判断を、どうやってしていますか」だったと思う。
8人規模のスタートアップで複雑さが増えると何が起きるかは、身をもって知っている。去年、機能を追加しすぎてデプロイのたびにヒヤヒヤしていた時期があった。あれはまさにナイール氏が言う「複雑さという怪物」に食われていた状態だった。
ナイール氏はビジネスを2つのループで説明している。市場にプロダクトを出してフィードバックを得るループと、既存ユーザーにサービスを提供して収益を得るループだ。前者は「不確実性」を怖がる。後者は「複雑さ」を怖がる。
これ、そのまま私とエンジニアの会話に当てはまる。私は「早く出して反応を見たい」と言う。エンジニアは「それをやるとシステムが複雑になる」と言う。お互い間違ってないんだけど、恐れているものがズレているから話がかみ合わない。採用の場でも同じことが起きていたと思う。
記事の中でナイール氏は「誕生日ケーキを丸ごと焼こうとしているなら、サンドイッチにろうそくを立てればいい」と書いている。相手が本当に必要としているのが「誕生日を祝えること」なら、最初からケーキを丸ごと作る必要はないという話だ。これ、プロダクト開発だけじゃなくて採用要件の設計にも言えると思った。
私がほしいのは「何でも作れる人」じゃなくて、「ゴールから逆算して最小で動かせる人」だ。それを面接の設問に落とし込めていたかというと、正直できていなかった。
ナイール氏が提案しているのは、速く試すためのシステムと、安定して運用するためのシステムを分けるというやり方だ。スピード版はAIや未レビューのコードも使って素早く仮説を検証する。スケール版はシニア開発者が安定性を重視して整える。野心的な依頼が来たら「スピード版は3日、スケール版は約6週間」と伝えられる、という話だ。
これを読んで、採用要件を2種類に分けて考えるといいかもと思った。PMFを探している今のフェーズで必要な人と、スケールするフェーズで必要な人は、たぶん別の人だ。同じJDで採ろうとするから、どちらにも中途半端な人を採ってしまう。
次の採用では面接に「作らなかった判断の経験を教えてください」という質問を入れてみるつもりだ。そこで出てくる答えが、スピード型かスケール型かの見極めにもなると思っている。
テーマは「シニア開発者はなぜ専門知識をうまく伝えられないのか」というもの。コピーライターのトゥヒン・ナイール氏が書いた記事で、技術者向けの話なんだけど、読んでいたら採用面接の失敗が頭に浮かんできた。
「作れる人」より「作らない判断ができる人」を採れていたか
ナイール氏によると、シニア開発者には2タイプいる。「新しいツールを使えばいい」「ベストプラクティスではこうだ」と言うタイプ。もう一方は「それ本当に必要?」「今あるもので間に合わない?」と問うタイプ。ナイール氏が評価するのは後者だ。
正直、私はずっと前者を採ろうとしていた。「何を作れるか」「どのスタックを知っているか」ばかり見ていた。面接でも「これ実装できますか」という質問が多かった。でも本当に聞くべきだったのは、「いらないものを作らない判断を、どうやってしていますか」だったと思う。
8人規模のスタートアップで複雑さが増えると何が起きるかは、身をもって知っている。去年、機能を追加しすぎてデプロイのたびにヒヤヒヤしていた時期があった。あれはまさにナイール氏が言う「複雑さという怪物」に食われていた状態だった。
ビジネス側とエンジニア側でそもそも恐れているものが違う
ナイール氏はビジネスを2つのループで説明している。市場にプロダクトを出してフィードバックを得るループと、既存ユーザーにサービスを提供して収益を得るループだ。前者は「不確実性」を怖がる。後者は「複雑さ」を怖がる。
これ、そのまま私とエンジニアの会話に当てはまる。私は「早く出して反応を見たい」と言う。エンジニアは「それをやるとシステムが複雑になる」と言う。お互い間違ってないんだけど、恐れているものがズレているから話がかみ合わない。採用の場でも同じことが起きていたと思う。
記事の中でナイール氏は「誕生日ケーキを丸ごと焼こうとしているなら、サンドイッチにろうそくを立てればいい」と書いている。相手が本当に必要としているのが「誕生日を祝えること」なら、最初からケーキを丸ごと作る必要はないという話だ。これ、プロダクト開発だけじゃなくて採用要件の設計にも言えると思った。
私がほしいのは「何でも作れる人」じゃなくて、「ゴールから逆算して最小で動かせる人」だ。それを面接の設問に落とし込めていたかというと、正直できていなかった。
「スピード版」と「スケール版」を分けるという考え方
ナイール氏が提案しているのは、速く試すためのシステムと、安定して運用するためのシステムを分けるというやり方だ。スピード版はAIや未レビューのコードも使って素早く仮説を検証する。スケール版はシニア開発者が安定性を重視して整える。野心的な依頼が来たら「スピード版は3日、スケール版は約6週間」と伝えられる、という話だ。
これを読んで、採用要件を2種類に分けて考えるといいかもと思った。PMFを探している今のフェーズで必要な人と、スケールするフェーズで必要な人は、たぶん別の人だ。同じJDで採ろうとするから、どちらにも中途半端な人を採ってしまう。
次の採用では面接に「作らなかった判断の経験を教えてください」という質問を入れてみるつもりだ。そこで出てくる答えが、スピード型かスケール型かの見極めにもなると思っている。