TinyPilot:26カ月目
一言でまとめると
採用の難しさは想像以上でした。
ハイライト
- TinyPilotは過去最高の月となり、収益は約8万ドルに達して従来の記録を15%上回りました。
- 求人への応募数は、半年前に同じ求人を出したときの8倍になりました。
- 採用について思うところがたくさんあります。
目標の成績表
毎月初めに、その月に達成したいことを宣言しています。結果は次のとおりでした。
TinyPilot CommunityとTinyPilot Proを次世代アップデートシステムへ移行する
- 結果: TinyPilot Communityは移行できましたが、TinyPilot Proはまだ準備が整っていません。
- 評価: C+
TinyPilotのアップデートシステムの刷新には5月から取り組んでいますが、想定していたよりはるかに時間がかかっています。
この2年間で、TinyPilotのアップデートシステムには多くの技術的負債が積み重なりました。今はそれを返済している最中ですが、次々と想定外の問題が出てきて、そのたびに1週間以上の開発時間が奪われています。あと数週間で終わるところまで来ているはずです。
TinyPilotのライセンス管理の計画を確定する
- 結果: 計画は確定しました。
- 評価: A
TinyPilotのライセンス管理について計画が固まり、関係者全員が納得しています。ユーザー体験はスムーズで、エンジニアリングの複雑さも最小限に抑えられる内容です。
TinyPilot Voyagerをレビュー用にYouTubeクリエイターまたはブロガー2名に送る
- 結果: 採用対応に追われて手が回りませんでした。
- 評価: F
ここはまったく進められませんでした。採用にほとんどの時間を使ったので、本来は採用自体を目標に入れるべきでした。
TinyPilotの統計
| 指標 | 2022年7月 | 2022年8月 | 増減 |
|---|---|---|---|
| ユニーク訪問者数 | 21,242 | 11,903 | -9,339 (-44%) |
| 総ページビュー | 33,578 | 23,214 | -10,364 (-31%) |
| 販売収益 | $56,954.66 | $76,082.06 | +$19,127.40 (+34%) |
| エンタープライズサブスクリプション | $290.70 | $290.70 | 0 |
| ロイヤリティ | $2,513.71 | $3,264.23 | +$750.52 (+30%) |
| 総収益 | $59,759.07 | $79,636.99 | +$19,877.92 (+33%) |
| 利益 | $-12,349.21 | $21,580.82 | +$33,930.03 (+inf%) |
8月はTinyPilotにとって収益も利益も過去最高の月になりました。7月末に価格を11%下げたところ、売上が34%増えたようです。今回も数字を押し上げた外部要因は特になく、いわば「地味な」月だったので、今後もこの水準を維持できるのではないかと楽観しています。
値下げできたのは、ようやく基板の在庫が安定したからです。半導体不足の影響で、在庫切れになった部品を置き換えるために8カ月かけて再設計を余儀なくされました。限られた在庫を売り切らないよう、価格を高めに維持する必要がありました。今は新たにチップを製造し続けられるようになったので、価格や販売ペースをより柔軟に調整できます。
8倍の応募数への対応
8月に2人目のサポートエンジニアを採用しましたが、半年前に同じ職種で採用したときとはまったく違う経験になりました。
前回は30日間で221件の応募がありました。今回はわずか2週間で802件の応募が集まりました。応募が多すぎて意図的にペースを落とさざるを得ず、最終的には2週間で募集を締め切りました。
返信が追いつかない間、求人掲載を一時停止したかったのですが、We Work Remotelyでは求人を一時的に非表示にできません。永久に削除して残りの掲載期間を放棄するか、そのまま掲載し続けて手に負えない数の応募を受け続けるかの二択でした。
苦肉の策として、求人は掲載したまま、勤務地の条件を「世界中」から「米国のみ」に変更しました。この職種が米国在住を必須とするわけではありませんが、募集を完全に取り下げずに応募の流入を抑えるにはこれが最善の方法に思えました。

勤務地の条件を追加したことで、新規応募のペースは約半分に落ち着きました。それでも条件を無視して応募してくる人は多くいました。条件変更後に「米国在住」と答えた候補者は42%で、変更前の18%からは増えましたが、依然として半数以上は条件を満たしていませんでした。
2週間で802件の応募が集まった時点で募集を締め切りました。これ以上受け付けても、候補者一人ひとりにタイムリーに返信できないと判断したからです。
なぜ今回はこれほど応募が増えたのでしょうか。考えられる理由を挙げます。
構造化されたWebフォームはメールよりハードルが低い
最も大きな要因は、今回の応募をWebフォーム経由にしたことだと思います。前回は履歴書とカバーレターをメールで送ってもらう形でした。構造化されたフォームの方が応募者は気軽に感じ、より多くの人が応募しやすくなるのでしょう。
一方で、Webフォームは手抜きの応募も集めやすいという欠点があります。前回はWe Work Remotely経由の応募者のうち18%が書類選考を通過しましたが、今回は最初の段階を通過したのは6%にとどまりました。
掲載チャネルを増やしたことで候補者が増えた
今回はRemoteOKとCraigslistという2つのチャネルを追加しました。Craigslistからの応募はあまり増えませんでしたが、RemoteOKからは2週間で127件の応募がありました。
景気の悪化で求職者が増えている
最後に、世界経済が半年前より悪化していることも影響しています。景気後退への懸念が広がり、採用を控える企業も増えています。年初よりも雇用主側に有利な市況になっているのだろうと思います。
リモート求人の広告チャネル比較
この採用活動を通じて、チャネルによって投資対効果が大きく異なることが分かりました。
私が重視する指標は次の2つです。
- 適格な候補者の数
- 応募者全体に占める適格な候補者の割合
1つの職種につき、適格な候補者が10〜20人程度集まれば、十分な選択肢が得られると考えています。数人の適格者を見つけるために3,000人をスクリーニングしなければならないほどノイズが多いプラットフォームには価値がありません。
ここでの評価では、書類選考を通過した人を適格な候補者とみなしています。また、求人を世界中で公開していた最初の5日間の応募のみを対象にしています。勤務地の条件を変えたことでバイアスがかかることと、それ以降の応募をまだすべて処理しきれていないことが理由です。
| チャネル | 費用 | 応募総数 | 一次スクリーニング通過 | 適格候補者1人あたりの費用 | トライアル採用 |
|---|---|---|---|---|---|
| We Work Remotely | $398 | 359 | 20 (6%) | $20 | 0 |
| Remote OK | $448 | 67 | 0 (0%) | N/A | 0 |
| Craigslist | $25 | 3 | 1 (33%) | $25 | 0 |
| Hacker News | $0 | 2 | 0 (0%) | N/A | 0 |
| その他のアグリゲーター | $0 | 53 | 1 (8%) | $0 | 0 |
| 不明/直接応募* | $0 | 52 | 3 (15%) | $0 | 1 |
| 合計 | $871 | 464 | 25 (5%) | $35 | 1 |
*「不明」にはTinyPilotのWebサイト上のリンクから応募した候補者が含まれます。Twitterなどで私が投稿したのを見た人もここに含まれます。最終的に採用した人は私のツイートから求人を見つけてくれました。
We Work Remotelyはまずまずの成果でした。手抜きやスパムのような応募も少なくありませんが、359件中20人が適格というのは悪くない割合です。
RemoteOKはこの期間では適格者がゼロで、使った感触もあまりに悪かったので、別に章を立てて書きます。
RemoteOKには大きくがっかりさせられました
私はPieter Levelsのファンを長く続けています。Indie Hackersポッドキャストでのインタビューは、同番組の中でも特に素晴らしい回の一つです。ブートストラップという生き方のワクワク感や自由さを、彼は見事に語っています。
しかし残念ながら、Pieterの主力事業であるRemoteOKには大きく失望させられました。これほど利用者である課金ユーザーに寄り添ってくれないプロダクトは、久しぶりでした。
まず求人を作成する時点で、RemoteOKは細かいアップセルを次々と勧めてきます。

RemoteOKは雇用主に対し、QRコード生成に134ドルかかるものを含む9種類のアップセルを勧めてきます。
We Work Remotelyでも似たようなアップセルはありますが、そこまで下品には感じません。We Work RemotelyがQRコードの作成に134ドルも請求してこないからかもしれません。
RemoteOKの求人には検索用のタグがあり、linuxやcustomer support、flexible scheduleといったタグを追加しました。数時間後に求人を見返すと、RemoteOKがmicrosoft windows webdev developmentといった、求人内容とまったく関係のないタグを自動で追加していました。追加されたタグを削除しても、翌日にはまた復活していました。最終的に、自分でさらにタグを追加することでようやく消すことができました。
RemoteOKがユーザーのコントロールを最も露骨に奪っている例が、いわゆるマジックキーワードです。RemoteOKは「応募の際は、求人を最後まで読んだことを示すために[ランダムな単語]という言葉を必ず含めてください」という指示を自動で追加します。しかもこの指示が追加されることは雇用主には知らされず、削除することもできません。


RemoteOKは雇用主には見えない形で、候補者向けの求人票に追加の指示を挿入します。この動作を無効にすることはできません。
私はこの機能が大嫌いです。こんな仕様があると知っていたら、RemoteOKには最初から掲載しませんでした。
こうした「マジックキーワード」の要求は応募者に対して失礼だと思っており、私自身は求人で意図的に避けています。それをRemoteOKが、お金を払って掲載した求人にこっそり挿入してくるのは、非常に腹立たしいことです。
そして何より致命的なのは、RemoteOKが本来の役割である適格な候補者の提供にまったく失敗したことです。同じ期間にWe Work Remotelyでは20人の適格な応募者がいたのに、RemoteOK経由では一人も書類選考を通過しませんでした。
追記(2022-09-25): この投稿を受けて、Pieter Levels氏は指摘した問題の改善に取り組むことを約束し、支払った掲載料を快く返金してくれました。
Homerunは良いが、素晴らしくはない
前回の採用では、候補者に直接メールを送ってもらい、受信トレイのラベルで応募を管理していました。結果的に煩雑で分かりづらくなってしまいました。
今回はいくつかの採用管理システム(ATS)を試した末に、Homerunに落ち着きました。
採用プロセス全体で使ってみて、Homerunにはおおむね満足しています。UIは見た目がきれいで、必要な機能は一通りそろっていました。操作もおおむね直感的で、応募を体系的に処理しやすかったです。


前回はメールのラベルで応募者を管理していました(左)。今回はHomerunを使い、カンバン形式で応募を整理できました(右)。
特に気に入ったのはHomerunのメールテンプレート機能です。候補者に定型文をそのまま送ることはめったにありませんでしたが、次のようなよくある返信のたたき台があるのは助かりました。
- Linuxの経験が足りない
- この職種に求めるレベルまで英語力が達していない
- 素晴らしい候補者なので、次のサンプル課題に進みましょう
![Hi [first_name], Thanks for applying for the [job_title] opening at [company_name] and for taking the time to learn more about the company. Unfortunately, I don't think this position would be a good match for your skills. This position requires someone more with more experience writing customer-facing content. Your English is pretty strong, but there were several syntax errors in your application, so I don't think this role would be a good fit. I'm sorry it didn't work out, but I wish you the best of luck in your search.](https://mtlynch.io/retrospectives/2022/09/poor-english-rejection.png)
よくあるケース別にメールのテンプレートを用意しました。
Homerunの料金は月額71ドルで、小規模な事業者でも手が届く範囲です。課金体系も良心的で、採用活動をしていない月は支払う必要がありません。他の多くの採用管理プラットフォームでは、月額料金の支払いを止めるとデータがすべて削除されますが、Homerunでは採用活動をしていない間は無料プランにダウングレードでき、データはそのまま保持されます。無料プランでの制限は、新たな応募を受け付けられなくなることだけです。
Homerunでいくつか大きな弱点も見つかりました。
候補者を絞り込めない
応募数が非常に多かったので、有望な候補者には早めに連絡したかったのですが、英語圏に住んでいてLinuxの習熟度を「得意」と自己評価している人だけに絞り込むといったことがしたかったのです。Homerunはこのデータを持っているのに、それで候補者を絞り込む手段がありません。キューから該当者を探すには、応募を1件ずつ見ていくしかありませんでした。
メールのUXが悪い
Homerunで最もUIとして残念だったのがメールの仕様です。他の採用管理システムと同様、HomerunでもWebアプリ内から候補者にメールを送れます。ただ、その際にモーダルウィンドウがポップアップするのです。

Homerunのアプリ内メールはモーダルウィンドウで表示されるため、候補者の応募内容を参照しながらメールを書くことができません。
モーダルウィンドウが候補者の応募内容を完全に覆い隠してしまうため、自分のメモや履歴書、応募フォームの回答を見ながら返信することができません。雇用主が候補者に返信する際に当然必要になる情報が見られないのは、ひどい設計だと思います。
回避策として、Homerunを2つのウィンドウで並べて開いていました。なんとか使えましたが、ウィンドウ間で同期がうまくいきません。片方のウィンドウで候補者を「不採用」にすると、もう片方のウィンドウが混乱して応募者リストの一番上まで戻ってしまうのです。
メールの到達率が低い
候補者にサンプル課題をPDFへのリンクで送ったのですが、何人かから「届いていない」と連絡がありました。Homerunが使っているメールサーバーの評価が低く、リンク入りのメールがスパムフィルターに弾かれているのだと思います。
Webアプリの動作が遅い
HomerunのWebアプリはとにかく動作が遅いのがストレスでした。性能の良いデスクトップに光回線でつないでいるのに、ほとんどのページの読み込みに2〜5秒かかり、10秒かかることもありました。
次回の採用で改善したいこと
今回の採用では、候補者への対応に満足していません。応募数への備えができておらず、妥当な期間内に処理しきれない数の応募を受け付けてしまい、候補者の時間を無駄にさせてしまいました。
次回、採用体験を全体的に改善するために変えたい点を挙げます。
返信はもっと慎重にする
Homerunで応募を処理し始めた当初は、メールテンプレートが便利で積極的に返信しすぎてしまいました。前回の採用では、手抜きの応募には返信せずに無視していました。Homerunではテンプレートがあるおかげで、手抜きの応募にも簡単に返信できてしまいます。
回答がコピペに見えることを理由に不採用を伝えるテンプレートまで作りました。コピペで応募しても採用されないというフィードバックを伝えるのは良いことだと思ったのです。
![Hi [first_name], Thanks for applying for the [job_title] opening at TinyPilot. Unfortunately, I've decided not to move forward with your application. I read the answers to the questions you submitted, and it didn't seem like there was anything specific about the company or work that appealed to you, so I don't think this would be a good match. Sorry that it didn't work out, but I wish you luck in your job search.](https://mtlynch.io/retrospectives/2022/09/low-effort-rejection.png)
コピペで応募してきた候補者に送る定型文の返信です。
この戦略はうまくいきませんでした。
返信をくれた候補者のうち、約50%は素直に受け止めて感謝してくれたので、その点は良かったのですが、約20%は無礼だったり敵対的だったりして、後味が悪かったです。
残りの30%は、ようやく生身の人間が対応してくれたことで、自分の応募が闇に葬られたわけではないと気づきました。そこで改めて会社について調べ、本当はTinyPilotに specifically 興味があるのだと主張し始めたのです。そうなると立場が難しくなります。最初から丁寧な回答を書いてくれた候補者に対して不公平になるので、考え直して選考に戻すべきかどうか迷うからです。
手抜きの応募への対応で1〜2日を無駄にした後、そのカテゴリーへの返信はやめることにしました。次の条件を両方満たす場合にのみ返信する方針に切り替えました。
- 候補者が職種の基本的な要件を満たしている
- 例:求人要件の一つが「Linuxに慣れていること」なのに、候補者が「Linuxを使ったことがない」と答えている場合は返信しません。
- 候補者が応募に少なくとも数分はかけている
- 例:回答が明らかにコピペだったり、走り書きだったりする場合は返信しません。
この新しい方針にしたところ、敵対的な返信がぱたりとなくなったのは思わぬ副次効果でした。丁寧な回答をくれた候補者に不採用の理由を伝えても、返信がないこともありましたが、返信があったときは皆さん礼儀正しく、フィードバックに感謝してくれました。
一次スクリーニングを手伝ってくれる人を雇う
履歴書や応募内容のスクリーニングには何十時間もかかりますが、賢い人なら少し教えれば任せられる作業です。
単純な自動フィルターや機械学習は使いたくありません。候補者に対して「あなたの応募はちゃんと人間が目を通しています」と胸を張って言えることが大切だからです。ただ、それが必ずしも自分である必要はないのです。
カスタマーサポートに冗長性を持たせる
候補者への返信が遅れた要因の一つに、普段カスタマーサポートを担当しているTinyPilotのメンバーが1週間病欠したことがあります。カスタマーサポートは、サポートエンジニアがフォローでき、最終的には自分が対応できるので、一見冗長性があるように思えます。しかし担当者が病欠したことで、サポート体制がいかにもろいかが分かりました。
自分でサポートをやるとどれだけ大変かをすっかり忘れていました。800件の求人応募への対応も重なり、負担はさらに大きくなりました。加えて数日間休暇を取っていたため、その間サポートを担ったのはサポートエンジニア一人だけでした。彼はShopifyや地元の発送拠点にアクセスできないため、対応できるサポートの範囲が限られてしまい、不安定な状況でした。
サポートエンジニアのチームが落ち着いたら、カスタマーサポートにもう一人加えようと考えています。誰かが病欠や休暇のときでも、スムーズに対応できるようにするためです。
一定数を超えたら応募フォームをウェイティングリストに切り替える
他の人に採用を手伝ってもらったとしても、妥当な期間内に審査できる応募数には限りがあります。400件といった上限を超えたら、応募フォームをウェイティングリストに切り替えるべきです。そうすれば、なぜ私たちと働きたいのかをわざわざ書いてもらって候補者の時間を無駄にせずに済みます。
採用がいかに時間を食うかを忘れない
求人を出して採用した経験は以前にもありますが、実際にまたやってみるまで、どれだけ時間がかかるかを忘れていました。
頭の中では、採用にかかる時間はこんなイメージでした。

想像上の採用プロセス
初日に大量の候補者が応募してきます。候補者を絞り込んで一人に決めます。最後にその人を採用すれば、それまで自分がやっていた業務を引き継いでくれて、すべてがうまくいきます。
実際にかかる時間は、むしろこんな感じです。

実際の採用プロセス
最初に大量の応募があり、それを処理している間も応募は途切れずに来続けます。そしてようやく誰かを採用した後も、採用しなかった全員に連絡を取りつつ、新しいメンバーのオンボーディングとトレーニングを同時に進めなければなりません。
なので、次回採用するときは、この分かりやすいグラフを見返して、取り組むには十分な余裕が必要だということを思い出そうと思います。
まとめ
できたこと
- 2人目のTinyPilotサポートエンジニアを採用した
- 次世代アップデートシステムをTinyPilotのCommunity版に導入した
- ブートストラッパー向け採用管理システムについてのノートを公開した
- PicoShareのメモリ問題のデバッグについてのノートを公開した
学んだこと
- 採用は常に想像以上に大変だ
来月の目標
- TinyPilot Proを次世代アップデートシステムへ移行する。
- TinyPilot Voyagerをレビュー用にYouTubeクリエイターまたはブロガー2名に送る
- 新たなケース製造の選択肢を検討する
記事をランダムに読む