一言でまとめると

TinyPilot初のサポートエンジニアを採用しました。

ハイライト

• TinyPilot初のサポートエンジニアを採用しました。
• サポートエンジニアの採用は、想像していた以上に難しいことを学びました。
• 海外のコントラクターへの支払いに使うプラットフォームを検討しています。

目標の振り返り

毎月のはじめに、その月に達成したい目標を宣言しています。目標に対してどうだったか、結果は以下のとおりです。

Voyager 2: PoE Editionのローンチ

• 結果：ついにVoyager 2 PoEをローンチしました
• 評価：A

いやはや、予想よりはるかに時間がかかりました。2021年4月上旬に書いた当初の設計書を見返してみると、2021年5月15日までに200台を用意できると見積もっていました。つまり6週間でできると見込んでいたものが、実際には11か月かかったわけです。

TinyPilotのサポートエンジニアを採用する

• 結果：サポートエンジニア1名とトライアル雇用を開始しました
• 評価：A

このポジションの採用には多大な労力がかかりましたが、新しいメンバーを迎えられてとても嬉しく思っています。この振り返りでは、サポートエンジニア採用のプロセスが中心になるので、詳しくはこの先を読んでください。

TinyPilotウェブサイト刷新のデザインを完了する

• 結果：3月に延期しました
• 評価：N/A

依頼しているデザイン会社が2月に十分な工数を確保できず、デザインを完了できませんでした。3月と4月は工数を確保する合意ができたので、今月末までに完了する見込みです。

TinyPilotの統計

1月以降、売上は安定しています。2月は日数が少ないため総売上はやや減少しましたが、1日あたりで見れば1月を上回っています。

2月の利益は例年になく高くなりましたが、これは主にタイミングの問題です。まだ届いていない高額な請求書がいくつかあるほか、法人クレジットカードの利用枠がようやく2万ドル引き上げられたため、手元に残る現金が多く見えているだけです。

サポートエンジニアの採用：求人票

ここ数か月、サポートエンジニアを採用したいと思っていましたが、なかなか時間が取れませんでした。予想以上に時間はかかりましたが、初のサポートエンジニアを採用できました。最初のステップは求人票を作ることでした。

求人は次の3つのチャネルで告知しました。

採用で難しいことの一つは、小さな会社の経営者として、自分の会社が何をしているかを理解し、それをきちんと伝えてくれる人を採用したいという点です。問題は、多くの企業が候補者をぞんざいに扱っていることです。その結果、応募しても9割は闇に葬られるのだから、特定の企業のために時間をかけるのはやめておこう、という空気が生まれてしまいます。

求人票を書くときは、応募書類すべてに私自身が目を通すことをはっきり書きました。機械学習のボットや、キーワードだけで機械的にふるいにかける素人のリクルーターに送られるわけではありません。あなたが労力をかけてくれるなら、私も労力をかけて応えます、という姿勢を示したかったのです。

また、採用プロセス全体を通じて候補者の時間を尊重していることを感じてもらいたかったのです。一緒に働くときにも、そう感じてもらいたいからです。

多くの求人票には「カバーレターにbananaという単語を入れてください。求人票をきちんと読んだか確認するためです」といった一文があります。私はあえてそれを入れませんでした。関係の出だしから嫌な雰囲気にしたくなかったからです。候補者に「自分は怠け者か無能だと思われているのか」と感じてほしくありません。手抜きの応募かどうかは数秒見ればわかりますし、合言葉など必要ないのです。

報酬額は悩みました。この職種の相場をつかむのは難しく、そもそも報酬を明記している求人が少なく、特にパートタイムの業務委託ではなおさらです。私は時給40ドルに設定しましたが、話を聞いた他の創業者たちは、適任者なら時給20〜30ドルで見つかるはずだと言っていました。

サポートエンジニアの採用：書類選考

求人を公開したら、いよいよ応募書類の選考です。これが全プロセスの中で最も時間がかかる部分でした。

この段階で私が評価していたのは次の点です。

• 文章は明確で、文法的に正しいか
• TinyPilotについて学ぶ時間をかけているか
• サポートやユーザー向けドキュメント作成の経験があるか
• 技術的な要件を満たしているか

際立って良い候補者を見つけたら、すぐに返信するようにしました。それ以外の人には、すぐに不採用を伝えるか、時間が取れ次第返信するキューに入れました。

すぐに、選考段階ごとに候補者を管理する仕組みが必要だと気づき、進行中のすべてのスレッドをメールのフォルダに振り分けました。

instant-reject

instant-rejectフォルダは、応募方法の指示に従わなかった候補者用です。具体的には次のようなケースが該当します。

• 本文が空で履歴書だけが添付されたメールを送ってきた候補者
• 職務内容やTinyPilotについて具体的に触れておらず、使い回しの応募文だとわかる候補者
• 求人の要件を満たしておらず、そのギャップについてカバーレターで触れていない候補者

これらの候補者については、応募をinstant-rejectフォルダに移し、返信はしませんでした。

138名（全体の62%）をinstant-rejectフォルダに入れました。

cover-letter-reject

cover-letter-rejectフォルダは、真摯に応募してくれたものの、カバーレターや履歴書から明らかにミスマッチだとわかる候補者用です。

このグループの候補者には個別に返信を送りました。例えば次のような内容です。

Joeさん、

TinyPilotに興味を持っていただき、時間をかけて調べてくださりありがとうございます。

残念ながら、今回はご一緒するのは難しいと判断しました。

LinuxやRaspberry Piに関する素晴らしいご経験をお持ちのようですが、今回のポジションでは顧客向けコンテンツの執筆経験がより求められます。英語はとてもお上手ですが、お手紙や履歴書にいくつか誤りがあったため、この役割には合わないと感じました。

今回はご縁がありませんでしたが、今後のご活躍をお祈りしています。

よろしくお願いいたします。
Michael

返信では、「あなた自身を否定する」のではなく「あなたの応募書類をお断りする」ことを意識しました。あなた自身を否定していると受け取られないようにしたのです。候補者が一つの不注意なミスだけで落とされたと感じたり、私が粗探しをしていると感じたりしないよう、あえて詳細に踏み込みすぎないようにしました。

ほとんどの企業は個別の不採用通知を送りませんし、その気持ちはわかります。膨大な時間がかかり、企業側にメリットもありません。それでも、私と一緒に働くために無償の時間をかけて応募してくれた人を、無視したり定型文で済ませたりするのは失礼だと感じています。

不採用通知を送った候補者のうち、約65%からは返信がありませんでした。約25%の方からは「フィードバックに感謝します」と返信をいただきました。その中には詳細を求める方もいて、修正すべき点や文章力を高めるためのおすすめ資料を具体的にお伝えしました。

不採用通知を受け取った候補者の約10%は、選考課題をやらせてくれれば実力を証明できると食い下がってきました。気持ちはわかりますが、選考課題のフィードバックはカバーレター段階でお断りするのに比べて桁違いに時間がかかるため、お互いの時間を無駄にしないよう、お断りしました。

返信をくれた方の多くは、応募書類の具体的な問題点に触れた返信が来たことに驚き、感謝してくれました。どうやらそれは珍しいことのようです。敵意を示すような返信をしてくる人は一人もおらず、皆さん最後までプロフェッショナルでした。

62名（28%）をcover-letter-rejectフォルダに入れました。instant-rejectと合わせると、書類選考を通過したのは19名（9%）だけでした。

pending-questions

カバーレターの英語が明確で文法的に正しく、技術的な要件も満たしている候補者には、応募のどこが良かったか、なぜTinyPilotに合うと思ったかを個別に伝える返信を書きました。

そのうえで、顧客対応をどう行い、技術的な解決策をどう提示するかを見るため、架空のカスタマーサポート依頼3件への回答をお願いしました。

返信を送った後は、課題が提出されるまでpending-questionsフォルダに入れておきました。

この段階まで進んだのは19名（9%）で、そのうち回答を提出したのは10名（53%）でした。ただし、2〜3名は課題を受け取ったのがここ数日なので、まだ回答が来る可能性があります。

questions-reject

候補者からサンプル課題の回答が届いたら、トライアル雇用に進むかどうかを判断しました。

サンプル課題に回答してくれた候補者全員に、オファーを出すかどうかに関わらず詳細なフィードバックを送りました。このアイデアはFirebaseの創業者であるAndrew Lee氏から得たものです。

候補者の時間が無駄になったと感じさせないことが極めて重要です。Firebaseでは、そのためにテイクホームテストのプロセス自体に多大な労力をかけました……回答を提出してもらった後は、（伝説的な@mikelehenによる）徹底的で詳細なコードレビューを返していました。

私たちはそれを本番のプロダクションに対するコードレビューと同じように扱い、選考を通過させるかどうかに関わらず実施しました。このレビューは2つの理由で非常に重要でした。第一に、私たちが候補者を真剣に考え、自分たち自身も採用プロセスに多大な時間を投資していることを示せるからです。第二に、候補者にFirebaseで働くことがどんな感じかを伝えるからです。「コーディング課題にこれほど丁寧にコードレビューをしてくれるなら、このチームと本番のコードで一緒に働くのが楽しみだ！」と思ってもらえるわけです。

-Andrew Lee, “How Firebase Interviewed Software Engineers”

Andrew氏のプロセスは、人への接し方として正しいとずっと心に残っていたので、どのポジションの採用でもその考え方を実践しようとしてきました。

ほとんどの方は詳細なフィードバックに感謝し、役に立ったと言ってくれました。一人からは私の評価基準が狭すぎるという指摘を受け、そのフィードバックをもとに課題を修正しました。

課題に回答した候補者のうち、19名中17名（89%）をquestions-rejectフォルダに入れました。

maybe-trial-hire

採用活動の最初の週に、選考課題にかなりよく答えてくれた候補者が一人いましたが、まだ迷いがありました。これまでで一番良かったのですが、他にも選択肢を見てみたかったのです。数週間以内に結論を出すと伝え、maybe-trial-hireフォルダに入れました。結果的によりマッチする候補者が見つかったため、後に「別の方と進めることにした」と連絡しました。

最初のサポートエンジニアを採用した後、複数の候補者と同時にトライアル雇用を行うのは難しすぎることに気づきました。開発者であれば別々のタスクを渡せば並行してトライアルできますが、サポートエンジニアがヘルプフォーラムで互いの回答を見ながら同じポジションを競い合うのは、あまりに殺伐としすぎると感じたのです。

maybe-trial-hireフォルダは、数か月後にサポートエンジニアを増員する場合に備えて残しています。候補者には、すでにトライアル雇用を進めていることを正直に伝えつつ、応募を続ければ追加採用時に優先的に検討すること、あるいは応募を一時中断して同じ段階から再開する選択肢もあることを伝えています。

trial-hire

一度にトライアル雇用するのは一人だけだったので、この段階の管理は簡単でした。ただ、念のため採用ファネルの最終段階用のフォルダも作りました。

まとめ

フォルダ管理を「採用ファネル」に置き換えると、各段階の人数は次のようになりました。

サポートエンジニアの採用：報酬の支払い

現在、3人のフリーランスの開発者と仕事をしており、それぞれ別の国に住んでいます。支払い方法も3人ともバラバラです。4人目のコントラクターが加わるのを機に、支払いプロセスを一つのソリューションに統一しようと考えました。

リモートワーカー向けの支払いプラットフォームに求めた条件は次のとおりです。

• 請求書発行や支払いにかかる全員の時間を最小限にすること
• コンプライアンス関連の書類を管理できること
• 契約書類を管理できること
• コントラクターが経費を記録できること
• スパイウェアをインストールせずに、コントラクターが稼働時間を簡単に記録できること

Deel（採用）

最終的にDeelを選びました。求めていた条件をすべて満たしていたからです。使い始めてまだ1週間ですが、今のところ順調です。

Deelは、コントラクターの銀行口座に現地通貨でいくら着金するかを、他のプロバイダーよりも透明性高く示してくれるように感じます。他のプロバイダーは良い為替レートを探す努力はすると約束しますが、最終的なレートは口座に着金して初めてわかる仕組みです。

Deelは今後、米国在住の従業員向け給与計算サービスにも拡大する予定です。それは私にとってありがたいことです。JustworksにもGustoにも満足していないので。

Pilot

PilotはDeelとよく似ています。どちらもY Combinatorの支援を受けており、UIも同じように洗練されています。Pilotはタイムトラッキングに対応していないのに対し、Deelは対応しています。

最初に登録したのはPilotで、そのまま使うつもりでしたが、アカウントが有効になるまで丸々1週間かかりました。その間に別の創業者からDeelのことを聞き、乗り換えました。顧客のオンボーディングをきちんとやることが大事だということでしょう。

Remote

Remoteはコントラクターへの支払いを無料で提供しています。素晴らしいですよね？でも、無料という点が私にとっては決め手にならず、見送りました。

他のサービスがコントラクター1人あたり月30〜50ドル取っているサービスを、Remoteが無料で提供できるなら、何か裏があるはずです。為替レートに手数料を隠して稼いでいるのかもしれません。あるいは、コントラクターは彼らにとってどうでもいいユースケースで、いつ突然サービスを打ち切るかわからない、ということも考えられます。Googleが無料サービスで何度もやってきたように。

Gusto

私はすでに地元のスタッフの給与計算にGustoを使っています。Gustoに特別満足しているわけではありませんが、支払いを一つのサービスにまとめられれば便利です。

残念ながら、Gustoは海外のコントラクターについては、毎回の支払いサイクルで固定額を支払う場合にしか対応していません。週ごとに稼働時間が変わるコントラクターには使えないのです。

レガシープロジェクト（RIP）

以前は振り返りの中でレガシー事業の近況を定例コーナーにしていましたが、内容がかなりマンネリ化してきました。どれも「何もしていません。その結果、指標はこうなりました」という話ばかりです。

「レガシープロジェクト」のコーナーを「サイドプロジェクト」に置き換え、週末や夜にいじっている趣味のプロジェクトについて書くことにします。

サイドプロジェクト

Lenny

Lennyは、私に代わってスパムメールに返信してくれるチャットボットです。

スパムはどんどんしつこくなっています。最初のメールに返信しないと、自動で追撃メールを送ってくるスパマーもいます。

スパマーが1通あたり数分の一セントと数か月ごとのドメイン取得だけで、私の受信箱に侵入して時間を奪い続けられることに腹が立ちました。しかも彼らは、返信が来るまで何の労力もかけずに、何千人もの人に同じことをしています。そこで、ばら撒き型の半ターゲティングメールが割に合わなくなるよう、スパマー側のコストを上げる方法が欲しいと思ったのです。

ヒントになったのは、テレマーケターの時間を音声チャットボットで浪費させるYouTubeチャンネルです。このチャンネルはVoIP番号を運用し、テレマーケターからの電話を取ると、Lennyという名の親切なオーストラリア人男性の録音で応答します。録音された返事は、テレマーケターが売ろうとしているものに常に興味を示しつつ、脱線話を延々と続けます。Lennyはテレマーケティング会社に数万から数十万ドル規模の損失を与えたとみられています。

私はそのLennyの自分版を、電話ではなくメール用に作りました。スパムメールが届いたら、それを自分用のメール版Lennyに転送します。Lennyはスパマーに熱心に返信しますが、すぐに話をそらして会話を堂々巡りにします。

以下は、2人の異なるスパマーが、私のチャットボット用に書いた同じメッセージシーケンスに反応した例です。Lennyは各スパマーから5回ずつ返信を引き出し、同じところで彼らが諦めるまで会話を続けさせています。2つ目の例では、Lennyの返信がスパマーのメッセージの文脈から外れ始めていますが、それでもスパマーはしばらく食い下がっています。

サードパーティへの依存は最小限に抑えたいと思っていますが、2月からBulma CSSフレームワークを使い始め、UIがかなり良くなりました。

それ以外では、新しい返信を定義しやすくする作業を進めています。現在はすべての返信がコードにハードコードされていますが、Web UIから編集できるようにしたいと考えています。

Lennyを今後どうするかはまだ決めていません。無料のオープンソースツールとして公開するかもしれませんが、ホスティングサービスとしてお金を払ってでも使いたいという人がいる気もしています。今は自分の楽しみのために作っているだけですが、数か月以内に他の人にも提供できればと思っています。

PicoShare

PicoShareは、ファイルをシンプルに共有するためのツールです。

ファイルをホストして共有できるサービスは山ほどありますが、どれも何かしら邪魔が入ります。例えば、動画をGoogleドライブにアップロードしてリンクを送るだけ、ということができません。Googleドライブは動画を再エンコードしようとするので、そもそも利用可能になるまで10分も待たされます。しかも受け取った側は、GoogleドライブのUIを経由しないと再生すらできません。Dropboxでもimgurでも同じです。

PicoShareは、飾り気のない、手間のかからないファイル共有サービスです。ファイルをアップロードすると直接リンクが取得でき、リンクを知っている人なら誰でも、アカウント登録や広告表示なしに直接閲覧・ダウンロードできます。

先日、家族のグループチャットで30 Rockの短いクリップを共有するのにPicoShareを使いました。PicoShareにクリップをアップロードして共有リンクを取得する流れは次のとおりです。

PicoShareは共有ファイルに有効期限を設定することもできます。TinyPilot用にファイルを共有したいけれど、機密情報を含むため相手のメールボックスにいつまでも残しておきたくない、ということがあります。これまではクラウドストレージにアップロードしてリンクを共有し、後でファイルを削除するのを覚えておく必要がありました。PicoShareなら、有効期限を過ぎると自動でファイルを削除してくれます。

PicoShareを作り始めたのは数週間前なので、まだ粗削りです。悪用対策のコストが高すぎるため、ビジネスになるとは思っていません。今はオープンソースとして公開していますが、まだ激しく変更を加えている段階なので、ドキュメントにはあまり力を入れていません。

まとめ

何を成し遂げたか？

• TinyPilot Voyager 2 PoEをローンチした
• TinyPilot初のサポートエンジニアを採用した
• PicoShareを作った

学んだこと

• 採用プロセスを、一緒に働く関係性のプレビューとして使おう。
  • 優秀な人は、自分を大切に扱ってくれる人と働きたいと思っている。
  • 求人票や採用プロセスで、相手を尊重し、その時間を大切にする姿勢を示そう。
• 求人票がありきたりだと、使い回しの応募しか見抜けない。
  • ありきたりな求人票を書けば、あなたの会社について何も語らない使い回しの応募ばかりが集まる。
  • 求人票で自社を他社と差別化しよう。候補者があなたの会社について学ぶ努力をしたことをカバーレターで示せるような、独自の話題を用意しよう。
• 候補者を丁寧に扱うのはコストがかかるが、人は喜んでくれる。
  • 不採用の候補者に敬意を持って対応するには10倍の時間がかかるが、だからといって手を抜くべきではない。
  • 創業者なら、直接的な利益にならなくても、人にどう接するかは自分で選べる。

来月の目標

• TinyPilot Pro 2.4.0を公開する
• TinyPilotウェブサイトのデザイン刷新を完了する
• TinyPilotの新しいサポートエンジニアのオンボーディングを完了する