ひとことで

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

ハイライト

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

目標の振り返り

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

Voyager 2: PoE版のローンチ

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

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

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

• 結果: サポートエンジニアをトライアル採用で迎えました
• 評価: A

この採用にはかなりの労力がかかりましたが、新しいメンバーを迎えられてとても嬉しく思います。この振り返りでは、サポートエンジニア採用のプロセスについて集中的に書いていますので、ぜひ続きをご覧ください。

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

• 結果: 3月に延期しました
• 評価: 評価なし

依頼しているデザイン会社が、2月は確保できる工数が足りず、デザインを完了できませんでした。3月と4月は時間を確保してもらうことで合意したので、月末までの完了を見込んでいます。

TinyPilotの数値

売上は1月から安定しています。総売上は2月が短い分だけやや減っていますが、1日あたりで見ると1月を上回っています。

2月の利益は例年になく高くなりましたが、これは主にタイミングの問題です。まだ届いていない大きな請求書がいくつかあり、事業用のクレジットカードの利用枠が2万ドル増枠されたことで、手元のキャッシュが一時的に多くなっています。

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

数か月前からサポートエンジニアを採用したいと思っていましたが、なかなか時間が取れませんでした。想像以上に時間はかかりましたが、初のサポートエンジニアを採用できました。まずは求人票の作成から始めました。

求人は次の3か所で告知しました。

採用で難しいのは、小規模な事業主として、応募者に自社が何者かを理解し、それを自分に伝えてほしいと思っていることです。一方で、ほとんどの企業は応募者をぞんざいに扱います。その結果、どの企業に対しても時間をかけて応募する気が失せます。どうせ9割は闇に葬られるのだから、という諦めが生まれてしまうのです。

求人票を書く際は、応募の一つひとつに私自身が目を通していることを明確にしました。機械学習のボットや、キーワードだけで機械的に足切りする事情を知らないリクルーターに送られるわけではありません。応募者が effort をかけてくれれば、私も effort をかけてお返しします。

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

よくある求人票には「この説明をちゃんと読んだことが分かるように、カバーレターにbananaという単語を入れてください」といった一文があります。私はあえてそうしませんでした。そうすると、関係の出だしから雰囲気が悪くなると感じたからです。応募者が怠惰だったり無能だったりすることをデフォルトで想定していると思われたくありません。手を抜いた応募かどうかは数秒見れば分かりますし、隠しキーワードは必要ありません。

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

サポートエンジニアの採用：応募のスクリーニング

求人を公開したら、次は応募のスクリーニングです。ここが最も時間のかかる工程でした。

この段階で見ていたのは次の点です。

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

目立って優秀な応募者には素早く返信しました。それ以外の方については、すぐにお断りするか、対応できるタイミングで返信するためにキューに入れました。

すぐに、選考のステージごとに候補者を管理する仕組みが必要だと気づき、進行中のスレッドをメールフォルダで整理することにしました。

instant-reject

instant-rejectフォルダは、応募方法の指示に従っていない方向けです。具体的には次のようなケースです。

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

こうした応募はinstant-rejectフォルダに移し、返信はしませんでした。

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

cover-letter-reject

cover-letter-rejectフォルダは、誠実に応募してくれたものの、カバーレターや履歴書からミスマッチが明らかな方向けです。

この方々には個別に返信しました。例えば次のような文面です。

Hi Joe,

ご連絡ありがとうございます。TinyPilotについて学ぶ時間を取っていただき感謝します。

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

LinuxやRaspberry Piでの素晴らしいご経験をお持ちのようですが、今回のポジションでは顧客向けコンテンツの執筆経験をより重視しています。英語力は十分に高いのですが、お手紙や履歴書にいくつか誤りがあったため、今回の役割には合わないと判断しました。

今回は残念な結果となりましたが、今後のご活躍を心よりお祈りしています。

Best,
Michael

返信では、応募者「本人」を否定するのではなく、あくまで「応募内容」をお断りしていることを意識しました。リンク先で触れている「youを主語にしない」という考え方です。些細なミスをあげつらえていると感じさせたくなかったので、あまり具体的に踏み込みすぎないようにしました。

不採用の連絡を個別に書かない企業がほとんどなのは理解できます。非常に手間がかかりますし、企業側に直接のメリットもありません。それでも、一緒に働かないかと声をかけ、無給の時間をかけて応募してもらった方を無視したり、定型文で済ませたりするのは失礼だと感じます。

お断りの連絡に対して、約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つの理由で非常に重要でした。1つ目は、私たちが候補者を真剣に考えており、面接プロセスにも多大な時間を投資していることを示せるからです。2つ目は、候補者にFirebaseで働くイメージを持ってもらえるからです。「コーディング課題のレビューをここまで丁寧にやってくれるなら、実際のプロダクションコードではどれだけ素晴らしいチームなんだろう！」と思ってもらえるわけです。

-Andrew Lee, “How Firebase Interviewed Software Engineers”

Andrew氏のプロセスは、人への向き合い方として正しいとずっと心に残っていました。だから、どの職種の採用でもその考え方を実践しようとしています。

多くの方は詳細なフィードバックを喜び、役に立ったと言ってくれました。一人からは評価基準が狭すぎるという指摘をいただき、そのフィードバックをもとに質問自体を修正しました。

質問に回答してくれた方のうち、17名（19名中の89%）をquestions-rejectフォルダに入れました。

maybe-trial-hire

採用活動の最初の1週間で、スクリーニング質問にかなり良く答えてくれた方が一人いましたが、まだ少し引っかかる点がありました。その時点では最も良い候補者でしたが、もう少し選択肢を見たいと思いました。数週間以内に結論を出すと伝え、maybe-trial-hireフォルダに入れました。最終的によりマッチする方を見つけたので、後日、別の方に決めた旨をお伝えしました。

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

今もmaybe-trial-hireフォルダは残しています。数か月後にサポートを増員する可能性に備えてです。候補者には、すでにトライアル中の方がいることを正直に伝え、そのまま選考を続けて次回増員時の候補リストに残るか、一旦中断して同じ段階から再開するかを選んでもらっています。

trial-hire

一度にトライアルするのは一人だけだったので、このステージの管理は簡単でした。ただ、採用ファネルを漏れなく示すために、最終ステージ用のフォルダも作りました。

まとめ

フォルダ管理を「採用ファネル」に置き換えると、各ステージの人数は次のとおりです。

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

現在、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は海外のコントラクターについては、毎回固定額をドルで支払う場合にしか対応していません。週ごとに稼働時間が変わるコントラクターには使えません。

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

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

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

サイドプロジェクト

Lenny

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

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

スパマーが1通あたり数分の一セントと数か月ごとのドメイン取得だけで、私の受信箱に侵入し時間を奪い続けられることに腹が立ちました。しかも返信があるまで手間をかけずに済むので、数千人に同じことを仕掛けています。そこで、大量の半ターゲティングメールが割に合わなくなるよう、スパマー側のコストを上げられないかと考えました。

ヒントになったのは、あるYouTubeチャンネルです。音声チャットボットでテレマーケターの時間を浪費させています。チャンネルはVoIP番号を運用し、テレマーケターからの電話を、親切なオーストラリア人男性Lennyの録音で応対します。Lennyはいつも商品に興味を示しつつ、とりとめのない脱線を繰り返します。Lennyのおかげでテレマーケティング会社は数万〜数十万ドルの損失を被ったと言われています。

私はそのLennyのメール版を自作しました。スパムが届いたら、自分のメール版Lennyに転送します。Lennyは熱心に返信しつつ、すぐに話を逸らして会話を堂々巡りさせます。

次に示すのは、私がチャットボット用に書いた同じメッセージシーケンスに対して、2人の異なるスパマーが返してきた反応です。Lennyはそれぞれのスパマーから同じところで諦められるまでに5往復の返信を引き出しています。2つ目の例では、途中からLennyの返信が文脈的におかしくなっていますが、それでもスパマーはしばらく食らいついてきます。

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

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

Lennyを今後どうするかはまだ決めていません。無料のオープンソースとして公開するかもしれませんし、ホスティング型の有料サービスとして需要がある気もしています。当面は自分の楽しみのために作っていますが、数か月以内に他の方にも使ってもらえるようにしたいです。

PicoShare

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

ファイルをホストして共有できるサービスは山ほどありますが、どれも何かしら邪魔が入ります。例えばGoogle Driveに動画をアップロードしてリンクを送るだけでも、再エンコードに10分待たされ、ようやく公開されても、受け取った側はGoogle Driveの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の新しいサポートエンジニアのオンボーディングを完了する