一行サマリー

採用がいかに驚くほど難しいか。

ハイライト

• TinyPilotは過去最高の月となり、収益は約8万ドルに達して従来の記録を15%上回りました。
• 求人への応募数は、半年前に同じ職種を募集したときと比べて8倍になりました。
• 採用について考えさせられることがたくさんありました。

目標の成績表

毎月初めに、その月に達成したいことを宣言しています。結果は次のとおりでした。

TinyPilot CommunityとTinyPilot Proを次世代アップデートシステムへ移行する

• 結果: TinyPilot Communityは移行しましたが、TinyPilot Proはまだ準備ができていません。
• 評価: C+

5月からTinyPilotのアップデートシステムの刷新に取り組んでいますが、誰の予想よりもはるかに時間がかかっています。

最初の2年間で、TinyPilotのアップデートシステムには多くの技術的負債が溜まっていました。今はそれを返済している最中ですが、次々と想定外の問題が出てきて、そのたびに1週間以上の開発時間が消えていきます。あと数週間で終わるとは思っています。

TinyPilotのライセンス管理の計画を確定する

• 結果: 計画は確定しました。
• 評価: A

TinyPilotのライセンス管理の計画が固まり、関係者全員が満足していると思います。スムーズなユーザー体験を提供しつつ、開発の複雑さも最小限に抑えられる内容です。

TinyPilot Voyagerを2人のYouTubeクリエイターまたはブロガーにレビュー用に送る

• 結果: 採用対応で忙しく、手が回りませんでした。
• 評価: F

ここはまったく進捗がありませんでした。本当は採用自体を目標に入れておくべきでした。というのも、今月はほとんどの時間を採用に費やしたからです。

TinyPilotの統計

8月はTinyPilotにとって収益も利益も過去最高の月でした。7月末に価格を11%引き下げたところ、販売数が34%伸びたようです。今回も数字を押し上げた外的要因は特になく、地味に伸びた月だったので、今後もこの水準を維持できるのではないかと楽観しています。

値下げできた理由は、ようやく基板の供給が安定したからです。半導体不足の影響で、在庫切れになった部品を置き換えるために8か月かけて再設計を余儀なくされました。限られた在庫を売り切らないよう、価格を高めに維持せざるを得ませんでした。今は再び新しい基板を製造できるようになり、価格や販売ペースをより柔軟に調整できます。

8倍の応募数への対応

8月に2人目のサポートエンジニアを採用しましたが、半年前に同じ職種を採用したときとはまったく違う経験になりました。

前回は30日間で221件の応募がありました。今回はわずか2週間で802件の応募が集まりました。あまりに多く、意図的にペースを落とさざるを得ず、最終的には2週間で募集自体を締め切りました。

返信が追いつかなくなったので、一時的に求人掲載を止めたかったのですが、We Work Remotelyは求人を一時非表示にすることができません。掲載を完全に削除して残りの掲載期間を捨てるか、そのまま掲載を続けて手に負えない数の応募を受け続けるかの二択です。

苦肉の策として、求人は掲載したまま、勤務地の条件を「全世界」から「米国のみ」に変更しました。この職種がどうしても米国在住でなければならないわけではありませんが、掲載を完全に取り下げずに応募の流入を抑えるにはこれが最善の方法に思えました。

勤務地の条件を追加したことで、新規応募のペースは半分程度に落ちました。それでも条件を無視して応募してくる人は多くいました。条件変更後に米国在住だと答えた候補者の割合は42%で、変更前の18%からは上がったものの、依然として半数以上が条件を満たしていませんでした。

2週間で802件の応募が集まった時点で募集を締め切りました。これ以上受け付けても、候補者にタイムリーに返信できるペースで処理できないと判断したからです。

なぜ今回はこれほど応募が増えたのか。私なりの推測は次のとおりです。

構造化されたウェブフォームの方がメールよりハードルが低い

一番大きな要因は、今回はウェブフォーム経由で応募を受け付けたことだと思います。前回は履歴書とカバーレターをメールで送ってもらう形でした。構造化されたフォームの方が気軽に応募できると感じる人が多く、応募のハードルを下げたのではないでしょうか。

一方で、ウェブフォームは手抜きの応募も集めやすいという欠点があります。前回はWe Work Remotely経由の応募者のうち18%が一次の書類選考を通過しましたが、今回はわずか6%しか次の段階に進めませんでした。

掲載チャネルを増やしたことで候補者が増えた

今回は掲載チャネルを2つ追加しました。RemoteOKとCraigslistです。Craigslistはそれほど応募を増やしませんでしたが、RemoteOKは2週間で127件の応募をもたらしました。

景気の悪化で求職者が増えている

最後に、半年前と比べて世界経済の状況が悪化していることも挙げられます。景気後退への懸念が広がり、採用を控える企業も増えています。今年の前半よりも、企業側に有利な雇用環境になっているのだと思います。

リモート求人の掲載チャネルを比較する

今回の採用活動を通じて、求人掲載チャネルによって投資対効果が大きく異なることが分かりました。

私が重視する指標は2つです。

• 適格な候補者の数
• 応募者全体に占める適格な候補者の割合

1つの職種につき10〜20人程度の適格な候補者が集まれば、十分な選択肢の中から選考できると考えています。適格者が数人しか見つからないのに3000人もの応募を screening しなければならないようなプラットフォームでは、価値がありません。

この評価では、履歴書のスクリーニングを通過した人を適格な候補者とみなしています。また、求人を全世界向けに公開していた最初の5日間の応募だけを対象にしています。これは、勤務地の条件を変えたことでデータに偏りが出るためと、まだすべての応募を処理しきれていないためです。

*「不明」にはTinyPilotのウェブサイト上のリンクから応募した候補者が含まれます。つまり、Twitterなどで私が投稿したのを見て応募してきた人も含みます。最終的に採用した人は私のツイートから求人を見つけました。

We Work Remotelyはまずまずの出来でした。手抜きやスパムのような応募も少なくありませんが、359件中20人が適格というのは悪くない割合です。

RemoteOKはこの期間では適格な候補者がゼロで、使った体験自体があまりにひどかったので、別に章を立てて書く価値があります。

RemoteOKにはひどくがっかりした

私は長い間Pieter Levelsのファンでした。Indie Hackersポッドキャストでの彼のインタビューは、シリーズの中でも最高のエピソードの一つです。ブートストラップという生き方のワクワク感や自由さを、彼は見事に語っています。

残念ながら、彼の看板事業であるRemoteOKには大きく失望させられました。金を払っているユーザーである私に対して、これほど執拗に敵対してくるプロダクトは久しぶりです。

まず求人を作成する段階で、RemoteOKは細かいアップセルを次々と押し付けてきます。

We Work Remotelyも似たようなアップセルを勧めてきますが、あそこまで露骨で不快には感じません。おそらく、We Work RemotelyはQRコードの作成に134ドルも請求したりしないからでしょう。

RemoteOKの求人には応募者が検索するためのタグがあります。そこでlinuxやcustomer support、flexible scheduleといったタグを付けました。数時間後に求人を見返すと、RemoteOKがmicrosoftやwindows、webdev、developmentといったまったく関係のないタグを勝手に追加していました。追加されたタグを削除しましたが、翌日にはまた復活していました。最終的に、自分でさらにタグを追加することでようやく勝手な追加を止めることができました。

RemoteOKがユーザーのコントロールを奪う最もひどい例が「マジックキーワード」です。RemoteOKは「応募する際は、求人を最後まで読んだことを示すために[ランダムな単語]という言葉を必ず含めてください」という指示を勝手に追加します。しかも、この指示が追加されることは雇用主には知らされず、削除することもできません。

私はこの機能が大嫌いです。このことを知っていたら、そもそもRemoteOKに求人を掲載しませんでした。

こうした「マジックキーワード」の要求は応募者に対して失礼だと思っており、私は求人を出す際に意図的にそういうものを排除しています。自分がお金を払って掲載した求人票に、RemoteOKがこっそりそれをねじ込んでくるのは本当に腹立たしいことです。

そして何より致命的なのは、RemoteOKが本来の役割である「適格な候補者を届けること」に完全に失敗したことです。同じ期間にWe Work Remotelyが20人の適格な候補者を紹介してくれたのに対し、RemoteOK経由の候補者で一次スクリーニングを通過した人は一人もいませんでした。

追記（2022-09-25）: この投稿を受けて、Pieter Levelsは指摘した問題に取り組むことを約束し、支払いを丁寧に返金してくれました。

Homerunは悪くないが、素晴らしくはない

前回採用したときは、候補者に直接メールを送ってもらい、受信トレイのラベルで応募を整理していました。結果的にごちゃごちゃして分かりにくくなってしまいました。

今回はいくつかの採用管理システム（ATS）を試した末に、Homerunに落ち着きました。

Homerunを採用プロセス全体で使ってみて、概ね満足しています。UIはきれいで、必要な機能は一通り揃っていました。操作もかなり直感的で、応募を整理しながら処理しやすかったです。

特に気に入ったのはHomerunのメールテンプレート機能です。候補者に完全に定型文を送ることはめったにありませんでしたが、よくある返信の骨組みが用意されているのは助かりました。例えば次のようなものです。

• Linuxの経験が不足している
• 英語が職種に求められるレベルに達していない
• 素晴らしい候補者なので、サンプル課題に進みましょう

Homerunの料金は月71ドルで、ほとんどの小規模事業者にとって手の届く価格帯です。しかも課金が良心的で、採用活動をしていない月は支払う必要がありません。他のほとんどの採用管理プラットフォームは、月額料金の支払いを止めるとデータがすべて削除されてしまいますが、Homerunでは採用していない期間は無料プランにダウングレードでき、データはそのまま保持されます。無料プランの制限は、新たな応募を受け付けられなくなるだけです。

とはいえ、Homerunにもいくつか大きな弱点がありました。

候補者を絞り込めない

応募数が非常に多かったので、有望な候補者から早めに連絡を取りたいと思いました。英語圏に住んでいて、Linuxの習熟度を「得意」と自己評価している人だけに絞り込みたいといったニーズです。Homerunはこのデータを持っているのに、それで候補者をフィルタリングする方法がありません。キューの中からそうした応募者を見つけるには、1件ずつ目を通すしかありませんでした。

メールのUXが悪い

HomerunのUIで最悪な点の一つがメール機能です。すべての採用管理システムと同様に、Homerunでもウェブアプリ内から候補者にメールを送れます。ただ、その際にモーダルウィンドウがポップアップするのです。

このモーダルウィンドウが、候補者が応募フォームに書いた内容を完全に覆い隠してしまいます。自分のメモも、履歴書も、応募フォームの回答も参照できません。候補者に返信する際に明らかに必要な情報なのに、これはひどい設計です。

私はHomerunを2つのウィンドウで並べて開くことで回避しました。これでも一応は動きましたが、Homerunは複数のブラウザウィンドウ間での同期がうまくいきません。片方のウィンドウで候補者を不合格にすると、もう片方のウィンドウが混乱して応募者リストの先頭から再読み込みされてしまいました。

メールの到達率が低い

サンプル課題をPDFへのリンクとして候補者に送ったのですが、何人かの候補者から届いていないと言われました。Homerunが使っているメールサーバーの評価が低く、リンクを含むメールがスパムフィルタに引っかかっているのだと思います。

ウェブアプリが遅い

Homerunのウェブアプリはイライラするほど遅いです。私は高性能なデスクトップと光回線を使っているのに、ほとんどのページの読み込みに2〜5秒、長いものでは10秒もかかります。

次回の採用で改善したいこと

今回の採用で、候補者への対応の仕方には満足していません。応募数の多さに準備ができておらず、妥当な期間内に処理しきれない数の応募を受け付けて、応募者の時間を無駄にしてしまいました。

次回、採用体験を全員にとってより良いものにするために変えようと思っていることは次のとおりです。

返信はより慎重にする

Homerunで応募を処理し始めた当初、メールテンプレートが便利なあまり、返信しすぎてしまいました。前回の採用では、手抜きの応募にはそもそも返信していませんでした。ところがHomerunではテンプレートのおかげで、あまり力を入れていない応募にも簡単に返信できてしまったのです。

コピペで応募してきた人向けに、「コピペの応募では採用されない」という趣旨のフィードバックを伝えるテンプレートまで作りました。せめてコピペが不利に働いていることを伝えた方が親切だと思ったのです。

この戦略はうまくいきませんでした。

返信があった候補者のうち、約50%は素直に感謝してくれたので、それは良かったです。約20%は無礼だったり敵対的だったりして、これは困りました。

残りの30%は、ようやく生身の人間が対応してくれたことで、自分の応募が闇に葬られたわけではないと気づきました。そこで改めて会社について調べ直し、実はTinyPilotに specifically 興味があるのだと主張し始めました。そうなると立場が難しくなります。最初から丁寧な回答を書いてくれた候補者に対して不公平になるのに、彼らの応募を再考すべきなのかどうか。

1〜2日、手抜きの応募に時間を費やした末に、そうしたカテゴリーの応募者には返信するのをやめました。戦略を次のように変えました。

• 候補者がその役割に最低限必要な資格を満たしている
  • 例えば、職務要件の一つが「Linuxに慣れていること」なのに、候補者が「Linuxを使ったことがない」と答えている場合は、返信しません。
• 候補者が応募に少なくとも数分は時間をかけている
  • 例えば、回答が明らかにコピペだったり、雑に書かれていたりする場合は、返信しません。

この新しい戦略には、敵対的な返信がなくなるという嬉しい副作用もありました。丁寧に回答を書いてくれた候補者に不合格の理由を伝えても、返信がないこともありましたが、返信がある場合はいつもプロフェッショナルで、フィードバックに感謝してくれました。

一次スクリーニングを手伝ってくれる人を雇う

履歴書や応募書類のスクリーニングには何十時間もかかりますが、これは賢い人なら十分に任せられる作業です。

単純な自動フィルタや機械学習は使いたくありません。候補者に対して「あなたの応募はちゃんと人間が目を通しています」と正直に伝えられることが私にとって重要だからです。ただ、それが必ずしも私自身である必要はないのです。

カスタマーサポートに冗長性を持たせる

応募者への返信が遅れた要因の一つは、普段カスタマーサポートを担当しているTinyPilotの従業員が1週間病欠していたことです。カスタマーサポートは冗長性があるように感じていました。サポートエンジニアがフォローできるし、ダメなら最後は私が対応するからです。しかし、通常のサポート担当が休んだことで、カスタマーサポートの体制がいかにもろいかが分かりました。

自分でカスタマーサポートをやるとどれだけ大変か、すっかり忘れていました。特に800件もの求人応募への対応と並行すると、その負担はさらに増します。加えて、私自身も数日間休暇を取っていたため、サポートを提供できるのはTinyPilotのサポートエンジニア一人だけになりました。彼はShopifyや地元のフルフィルメント拠点へのアクセス権を持っていないため、提供できるサポートに限りがあり、状況は不安定でした。

サポートエンジニアリングチームの体制が落ち着いたら、カスタマーサポートにももう一人追加するつもりです。そうすれば、誰かが病気や休暇で休んでも、スムーズに対応できるようになります。

一定数を超えたら応募フォームをウェイティングリストに切り替える

採用を手伝ってくれる人がいたとしても、妥当な期間内に審査できる応募数には限りがあります。400件といった一定数を超えたら、応募フォームをウェイティングリストに切り替えるべきです。そうすれば、なぜ私たちと働きたいのかをわざわざ書いてもらって候補者の時間を無駄にすることもなくなります。

どれだけ時間がかかるかを忘れない

以前にも求人掲載を通じて採用したことがありますが、そのプロセスがどれだけ時間がかかるかを、再びやり始めるまで忘れていました。

頭の中では、時間のかかり方はこんなイメージでした。

初日に大量の候補者が一気に応募してくる。候補者を絞り込んで一人に決める。最後にその人を採用すれば、その人がそれまで自分がやっていた作業を引き継いでくれて、すべてがうまくいく。

実際にかかる時間は、もっとこんな感じです。

最初に大量の応募が押し寄せ、それを処理している間にも新しい応募が来続ける。そしてようやく誰かを採用しても、不採用にした全員に連絡を取りつつ、同時に新しい人のオンボーディングとトレーニングを進めなければならないのです。

だから次に採用するときは、この美しくも分かりやすいグラフを見返して、この作業には十分な余裕が必要だということを自分に思い出させようと思います。

まとめ

やり遂げたこと

• 2人目のTinyPilotサポートエンジニアを採用した
• 次世代アップデートシステムをTinyPilotのCommunity版に導入した
• ブートストラッパー向け採用管理システムについてのノートを公開した
• PicoShareのメモリ問題のデバッグについてのノートを公開した

学んだこと

• 採用は常に想像以上に大変だ

来月の目標

• TinyPilot Proを次世代アップデートシステムへ移行する。
• TinyPilot Voyagerを2人のYouTubeクリエイターまたはブロガーにレビュー用に送る
• 新しいケース製造の選択肢を検討する