2014年から2018年までGoogleでソフトウェアエンジニアとして働いていました。2月1日に仕事を辞め、一人でソフトウェア会社を立ち上げました。

あれから4ヶ月が経ったので、近況を報告しようと思います。

仕事がないってどんな感じ？

これが一番よく聞かれる質問です。どんな感じなのか、と。

最初の数日間は、「やったー！自由だ！」ということばかり考えていました。待ちに待った休暇が始まって、それが永遠に続くかもしれないと知っているような感覚でした。

今では、ただ普通に感じています。楽しいけれど、普通です。

オフィスで働いていたことが今では不思議に思えます。高校時代を思い出すような感覚です。「1日6時間も座って人の話を聞いていたの？それから家に帰ってさらに仕事をしたの？」と。確かにそうしていたのは分かっているのですが、今ではひどく遠いことのように感じられます。

辞めて一番良かったのは、時間を完全に自分でコントロールできることです。1日を好きなように組み立てられますし、予定を変えるときにも何の摩擦もありません。午後の3時に走りに行きたいと思えば、そのまま走りに行けます。会議に遅れることも、誰かの仕事を止めてしまうこともありません。

普段ならやらなかったことをやってみる

自分の時間がたっぷりあることで、会社員だったときには魅力を感じなかったようなことにも、実験的に挑戦したり機会を追い求めたりする意欲が湧いてきます。

3月には、人生で初めてカンファレンスで発表しました。自分の記事「How to Do Code Reviews Like a Human」を基にした内容を、初心者にも優しいマサチューセッツ西部のカンファレンスNERD Summitで発表したのです。

数日後、Talking Drupalポッドキャストの共同ホストの一人であるStephen Crossさんからメールが届きました。彼は私の発表を気に入ってくれて、ポッドキャストでさらに深掘りしないかと誘ってくれたのです。楽しく会話をし、これまで考えたこともなかった角度からコードレビューについて掘り下げました。収録が終わるまでStephenさんには言わなかったのですが、このポッドキャストのエピソードは私にとってもう一つの大きな初めてでした。人生初のポッドキャスト出演だったのです。

退職についてのブログ記事

奇妙なことに、仕事を辞めてから最も注目された成果は……仕事を辞めたことについてブログ記事を書いたことでした。この記事を読んでいる方も、2月に公開した「Why I Quit Google to Work for Myself」がきっかけでこのブログにたどり着いた可能性が高いでしょう。その記事は公開から1週間で30万人の読者を集め、これまでの最多アクセス記事の記録を6倍も上回りました。

記事が公開された日は、一日中メールやコメント、Twitterのメッセージへの返信に費やしました。最高でした！まるで有名人になった気分でした。

翌日もメッセージへの返信を続けました。初日のような高揚感はさすがにありませんでしたが、たくさんの励ましや賛辞を目にするのはやはり嬉しいものでした。

3日目になると、圧倒され始めました。このまま2週間、何もせずに記事へのフィードバックに返信し続けることもできると気づいたのです。多くの読者が、Google退職後に何に取り組んでいるのか尋ねてきました。何と答えればいいのでしょう。「ええと、主にその記事の通知を見るたびに得られる手軽なドーパミンに夢中になっていました」とでも？

フィードバックとの向き合い方

連絡をくれた一人にStephanie Hurlburtさんがいました。彼女は成功しているグラフィックスソフトウェア会社の共同創業者で、洞察に満ちたブログ記事やTwitterスレッドでスタートアップ界隈ではよく知られた存在です。

彼女は記事について温かいメッセージをくれて、何か相談したいことがあればいつでもどうぞと言ってくれました。彼女から連絡をもらう何ヶ月も前からフォローしていたので、彼女が大量のメッセージを受け取っていることは知っていました。どうやってそれらを捌いているのか尋ねたところ、こんな役立つアドバイスをくれました。

……誰かに返信するのに1ヶ月以上かけても全然大丈夫ですし、返事を期待しても構いません。1年かけて返信するのもアリですが、その場合は返事を期待しない方がいいかもしれません（相手はもう他のことに移っているでしょうから）。つまり、届いたメッセージすべてにすぐ取り組む必要はなく、月に1日、まとめて一気に片付ける日を作ればいいのです。

-Stephanie Hurlburt (@sehurlburt)

このアドバイスは単純に聞こえるかもしれませんが、とても気持ちが楽になりました。私は普段1、2日以内に返信するタイプなので、何百ものメッセージやメールが溜まっていると、常に遅れを取っているように感じていたのです。

Stephanieさんと話してから、時間をかけてもいいんだという許可をもらえたような気がしました。ソフトウェアのプロジェクトに再び集中しつつ、数日ごとに時間を取って、メールなら5通、Twitterのメッセージなら10件といったように、決めた数のメッセージに返信するようにしました。

余談：Stephanieさんは1ヶ月遅れても大丈夫だと言っていましたが、私の質問に対して数分以内に、思慮深い3段落の返信をくれました。Twitterで最も親切な人という地位を守るために、私を騙している可能性もあります。

Stephanieさんは、すべてのメッセージに返信するのは現実的ではないとも指摘してくれました。今でもメールを無視すると罪悪感を覚えますが、すぐに返信しなければという考えから抜け出すことで、少し距離を置いて、どのメッセージに答えるか合理的に選べるようになりました。例えば、ブログ用の漫画家探しについて質問をくれた人には、漫画家と組んでいるブロガーはあまりいないので、話すのが楽しくて優先して返信します。Googleへの就職について一般的な質問をしてきたメールよりも先に答えることにしています。

ストレスとの付き合い方

辞める前は、小さなビジネスを始めるだけでも激しいストレスがかかるという話をよく耳にしました。「それはあの人たちには当てはまるんだろうけど、自分は毎日パジャマで過ごすんだ。どれだけストレスがかかるっていうんだ？」と思っていました。

でも彼らは正しかったのです。確かにストレスを感じました。お金や顧客といった、警告されていたことについてではありません。誰も気にしていない、自分で勝手に決めた締め切りにストレスを感じていたのです。それはGoogleで経験したどんな外部からの締め切りよりも大きな不安をもたらしました。

問題は、プロジェクトを抱えすぎたことでした。会社員だった頃は、1日8時間オフィスにいることが永遠のように感じられました。オフィスにいる時間をなくせば、永遠の自由な時間が手に入ると考えたのです。

悲しいことに、1日は相変わらず24時間しかないことに気づきました。それでも、一つひとつは小さく見えたので、新しい機会に次々と「はい」と答え続けました。数週間後には、細々したタスクを抱えすぎて、どれ一つとして進まなくなっていました。

今はプロジェクトを引き受けることにもっと慎重になっています。小さく見えても、それらを管理するだけで多くの精神的エネルギーを消費するからです。最近は、このブログと一つのソフトウェアプロジェクト（ネタバレですが、やがて両者は絡み合うことになります）に絞って取り組んでいます。

失敗したプロジェクト：Space Duck

最初のビジネスアイデアは、Siaという分散型ストレージプラットフォームの上にサービスを構築することでした。Siaについては何度も書いてきました。

Siaの目標は、データストレージをコモディティ化して誰でも販売できるようにすることです。AmazonやGoogleの料金の10分の1の価格をうたっています。Siaの技術がまだあまり知られていないのは、使い方を理解している人が少なく、その上にサービスを構築する方法となるとなおさらだからです。

私は、Siaをビジネスを構築できるレベルで深く理解している数十人のうちの一人でした。その知識を活かして、通常は帯域幅やストレージが制約となる市場（例えばファイルバックアップや動画ストリーミング）に参入すれば、インフラコストが10倍も高い競合に対して圧倒的な優位性を得られるはずでした。

正確に何を作りたいかは決まっていませんでしたが、ユーザーを引きつけるユニークな方法は分かっていました。Siaについて語る人は少なく、開発者の視点から書いている人は誰もいませんでした。個人ブログで書いたSiaの記事が何千人もの読者を集めていたので、技術的なコンテンツには需要があると分かっていました。そこでSpace Duckというブログを作り、プラットフォーム上での探索的なテストについて書き始めました。

残念ながら、これらのテストでSiaは皆が思っていたほど安くないことが明らかになりました。Siaの実際の価格帯では、より安定していて機能も豊富なプロバイダーが他に存在したのです。他のストレージプロバイダーに対して実用的な優位性がなければ、Siaは行き止まりでした。

KetoHubの材料問題

そこで、昨年ケトジェニックダイエットのレシピ探しを手助けするために作ったウェブサイトKetoHubに再び目を向けることにしました。

KetoHubの主な機能の一つは、手持ちの材料からレシピを探せることです。例えば、「ground beef」で検索すると、それを使ったケトジェニック対応のレシピが50件表示されます。

このタイプの検索は、材料のテキストのどの部分が関連性があるかをKetoHubが判断する必要があるため困難です。上のスクリーンショットでは、元の材料は「1 pound of ground beef」でしたが、KetoHubは検索結果のスニペットを「Ground beef」まで削ぎ落としています。

不要な単語を捨てるのは見た目より難しい作業です。当初はたくさんのルールを書くことでこれを解決しました。一つのルールは「計量単位を取り除く」でした。誰かが「tab…」と入力し始めたとき、「Tabasco」は良い一致ですが、「2 tablespoons vinegar」はそうではありません。何かが大さじ1杯入っているという理由だけでレシピが表示されてほしい人はいないでしょう。

では「dash」はどうでしょう？これは非公式な計量単位（「a dash of cinnamon」）ですが、Mrs. Dashという人気のシーズニングもあります。よし、ルールを「『Mrs.』が前に付く『dash』でない限り、計量単位は捨てる」に改良しましょう。

しかしそのルールも常にうまくいくわけではありませんでした。あるレシピの作者は、Mrs. Dashの婚姻状況は他人が口を出すことではないと考えたのか、そのシーズニングを「Ms. Dash」と表記していました。

これが、ランダムなウェブデータに厳格なルールを適用することの本質です。最初は単純でも、バリエーションやエッジケースが増えるにつれて、ルールは複雑さを増し、互いに衝突するようになります。

KetoHubに新しいレシピソースを追加するたびに、既存のルールを壊さずに新しいサイトの癖に対応できるよう、ルールの調整に何時間も費やさなければなりませんでした。

KetoHubが材料を処理するための、もっと柔軟な方法が必要でした。

新プロジェクト：サービスとしての材料パース

KetoHubの初期に、Indie Hackersのコメント欄で、ある人が教えてくれたブログ記事がありました。The New York Timesが、過去の膨大なレシピアーカイブから材料をパースするために機械学習を活用した方法について書かれたものでした。

それは面白そうでしたが、私の小さなレシピアグリゲーターサイトには大げさすぎると感じました。浴室が汚れているからといってハウスクリーニングのスタートアップを立ち上げるようなものです。問題は解決するかもしれませんが、解決策の方が対処すべき課題よりも大きいのです。

そこで気づいたのです。もし材料のパース自体がビジネスになるとしたら、と。

KetoHubは楽しいプロジェクトでしたが、まだ収益化の方法を見つけられずにいました。材料のパースがKetoHubにとって問題なら、他のアプリにとっても問題かもしれません。材料パースを提供する既存のサービスもありましたが、評価したものはどれも不正確だったり、法外に厳しい利用規約を課していたりしました。

そこでフリーランスの友人であるFerngullyさんに、Timesの材料パース手法で実験を始めてもらいました。初期の結果は有望だったので、私たちは数週間、機械学習と自然言語処理の沼にどっぷりとハマることになりました。

現在、動くデモができています。1 1/2 cups chopped red onionsや2 tablespoons minced parsleyのようなレシピの材料を与えると、構造化された要素に分解してくれます。

今後数週間は、様々なアプリ開発者にIngredient Parser APIがどのように役立つかを伝えることに集中する予定です。6月までには、彼らのフィードバックを基にAPIを磨き、MashapeやRapidAPIのようなマーケットプレイスで公開したいと考えています。追記：(7/15)：現在公開中です。

イラスト：Loraine Yow。Space Duckロゴ：Marina Mocanu。