ブートストラップ起業家としての7年目
原文は Michael Lynch により に公開されました。 このブログを購読する
7年前、私はGoogleの開発者としての仕事を辞め、自己資金でソフトウェア会社を立ち上げました。毎年、近況報告を投稿して、その後の歩みやインディー起業家としての生活について綴っています。
会社を売却した
この1年で最も大きな出来事は、2020年に創業した会社TinyPilotを売却したことです。
妻と私は家族を持ちたいと考えていましたが、7人規模の会社を一人でマネジメントしながら、生まれたばかりの子どもの良い父親でいることは両立できないと思いました。会社のビジョンに共感してくれる買い手が見つかり、2024年4月に売却が完了しました。

家族を始めるためにTinyPilotを手放す私
売却についてはすでに記事やポッドキャストで語り、売却の経緯や学んだ教訓についても書きましたが、端的に言えば、すべてがうまくいったことに感謝しています。
親になった
8月に、妻との間に第一子となる男の子が生まれました。
出産直後、看護師の1人が私たち3人の素敵な写真を撮ってくれました。下に載せています。息子のプライバシーを守るため、手作業で調整した高速フーリエ変換で生体情報を取り除く加工を施しています。

私と妻、そして生まれたばかりの息子の写真。プライバシー保護フィルターで加工済み
インディー起業家という働き方の柔軟性と、TinyPilot売却のタイミングには感謝しています。この5ヶ月は、これまでの人生で最も幸せな時間でした。
教育コンテンツに取り組んだ
TinyPilotは4月に売却しましたが、引き継ぎをサポートするため5月中旬まで会社に残りました。
息子は8月に出産予定で、生まれたら休みを取るつもりでした。新しいことを始めるには3ヶ月しかありませんでしたが、数ヶ月棚上げにしても大丈夫なものでなければなりませんでした。出産後の生活がどうなるか見極める時間が必要だったからです。
そこで、この3ヶ月に最適なのはダウンロード形式のコースか書籍だと考えました。教育コンテンツなら作業を一時中断しやすく、有料の顧客がいてもサーバーを稼働させ続けたりサポート対応に追われたりする必要がありません。
教育コンテンツを作った経験は2021年に一度だけありました。技術者向けのブログ運営についての動画コースを収録したのです。初年度に7,600ドルの売上があり、その後さらに2,200ドルの収益がありました。コース販売としては大ヒットとは言えませんが、制作にかかった時間は約100時間で、内容には誇りを持っています。インディー起業家になってから取り組んだプロジェクトの中で、最も投資対効果の高いものでした。

2021年に制作した技術者向けブログのコースは、4年間で合計1万ドルの収益を上げています。
夏の間、2021年のブログコースの教材を改訂しました。まずは少人数の受講生に毎週ライブのビデオ通話で教えることから始めました。受講生からのフィードバックをもとにコースを磨き上げ、最終的に販売用のダウンロード版を収録する計画でした。
ライブコースはまずまずの出来でしたが、受講生からは読者を集める方法よりも、文章そのものの技術をもっと学びたいという声がありました。コースを完成させたい気持ちはありましたが、息子が予定より数週間早く生まれたため、収録を終えることができませんでした。
息子が生まれてからは自宅で動画を収録するのが難しくなったため、開発者向けの効果的なライティング技法についての本の執筆に切り替えました。章ごとに公開し、読者のフィードバックをもとに内容を改善しています。
部分的に収録したブログコースの動画がまだたくさん手元にあり、どう扱うべきか決めかねているので、そのうちの1本を紹介します。人気のブートストラップ著者であるPatrick McKenzie氏からブログ対決を挑まれたら、なぜ受けるべきなのかを語ったものです。
面白い技術を学んだ
TinyPilotを経営していた頃は、技術的な作業に割く時間がありませんでした。ソフトウェアを書くのが大好きなので、残念なことでした。
以前からプログラミングは好きでしたが、この1年ほどワクワクしたことはありません。無料で公開されている素晴らしいオープンソースソフトウェアの数々に圧倒されています。
Nix
この1年で私の仕事に最も大きな影響を与えた技術は、NixとNixOSです。
Nixはapt-getやyumのようなパッケージマネージャーであり、同時にCMakeやBazelのようなビルドツールでもあります。この2つの機能を統合することで、ソフトウェアプロジェクトの依存関係を管理し、配布用にパッケージ化するのが容易になります。
少しずつNixを取り入れてきましたが、すっかり気に入ってしまい、今ではあらゆるプログラミングプロジェクトでNixを使い、すべてのコンピューターでNixOSを動かしています。
- 試してみるべき人は?
- Docker、Ansible、TerraformのようなInfrastructure as Codeツールを好む開発者。
- おすすめポイントは?
- ソフトウェアプロジェクトでは、Nixを使うとすべての依存関係をソースコードで定義できます。誰でもワンコマンドであなたの環境を再現できます。
- NixOSはNixの思想を中心に設計されたLinuxディストリビューションです。NixOSでは、コンピューター全体の設定をプレーンテキストのファイルで定義できます。コンピューターをゼロから再構築したり、以前の設定にロールバックしたりするのが簡単になります。
- NixはDockerの多くの利点を持ちつつ、DockerイメージよりもNixパッケージの方がうまく合成できます。
- 欠点は?
- Nixは学習曲線が急で、開発者向けの良い入門ガイドが見つかっていません。最も近いのはNixOS in Productionですが、これはDevOpsエンジニア向けです。
- 「flakes」という機能をめぐってコミュニティが分断されています。flakesを使うと、flakesを使っていないチュートリアルやドキュメントが理解しづらくなり、その逆もまた然りです。
- Nixコミュニティはリーダーシップの問題から健全とは言えない状態にあります。
- 継続的インテグレーション(CI)では、Nixは小規模な構成でスケールしません。Nix固有のCIベンダーに切り替えない限り、Nixに依存するCIジョブを55秒以内で実行する方法が見つかっていません。
- どうやって試すのが良い?
- 小さな単位から少しずつNixを試してみてください。Nixの機能の狭い範囲を学ぶだけでも大きな価値を得られます。
- Determinate SystemsのインストーラーでNixをインストールし、
nix shellでプログラムを実行してみてください(例:nix shell -p cowsayの後にcowsay howdy, human)。パッケージリポジトリを検索すれば、ワンライナーでインストールできるすべてのパッケージを確認できます。 - 一時的なシェルが気に入ったら、プロジェクトの1つでdev shellを作ってみてください。単一のファイルですべての依存関係や開発ツールを管理できます。
htmx
友人たちは数年前からhtmxを絶賛していましたが、私にはその概念がピンときませんでした。
「HTMLの<button>要素でPOSTリクエストが送れる?それがどうした?」
ところが、長時間のフライトの間に、htmxの思想について書かれた無料の電子書籍Hypermedia Systemsを読みました。この本で、htmxの価値は<button>でPOSTが送れることではなく、カスタムJavaScriptや何層もの抽象化に頼ることなく、HTMLに手軽なインタラクティビティをもたらす点にあるのだと気づきました。
ウェブ開発には面倒なJavaScriptが大量に必要だとは分かっていましたが、それが当たり前だと受け入れていました。HTMLとCSSが表現を担当し、JavaScriptがインタラクションを担当する。両者をつなぐグルーコードが必要で、グルーコードは本質的に退屈なものなのだと。
htmxの主張は、ウェブアプリのHTML/CSS側により多くのインタラクティビティを持たせることで、グルーコードや定型的なJavaScriptをなくせるということです。しかもnpmやWebpack、巨大なフロントエンドフレームワークのような複雑さや依存関係を持ち込む必要はありません。
- 試してみるべき人は?
- ReactやVueのようなヘビーなフレームワークよりも、素のJavaScriptやjQueryを好む開発者。
- おすすめポイントは?
- htmxは、これまでどれだけ不要なJavaScriptを書いてきたかを気づかせてくれます。
- htmxはフレームワークではなくライブラリなので、ReactやVueのように全面的に乗り換える必要がありません。ウェブアプリの1つのフォームだけで試して、気に入るかどうか確かめられます。
- ビルドステップがないので、プレーンなHTML、CSS、JavaScriptを生成するためにわざわざWebpackやNode.jsにコードを通す必要がありません。書いたコードがそのままブラウザで動くコードになります。
- 欠点は?
- htmx的なウェブアプリの書き方に思考を切り替えるのは難しいと感じましたが、結果的によりシンプルなコードになることが多かったです。
- htmxのエラーハンドリングは扱いづらいと感じていますが、まずまずの回避策は見つけました。
- htmxはContent Security Policy(CSP)を弱めてしまいます。
- どうやって試すのが良い?
- 私のhtmxについてのより詳しい紹介を読んでみてください。
- ScreenJournalをhtmxに移植した際の体験記を読んでみてください。
- Hypermedia Systems(無料でオンライン公開)の最初の数章を読んで、自分に合うか確かめてみてください。
- 自分のウェブアプリの1つのフォームでhtmxを試してみてください。
Zig
Zigの発想は、Cのような低水準言語で書く必要があるプログラムは今でも存在するが、50年前のプログラミング言語で書き続けることで自らを苦しめているというものです。
ZigはCと同じパワーとパフォーマンスを提供しつつ、Cが作られた当時にはなかったハードウェアやコンパイラの進歩を活かしています。
Zigの考え方にはすぐに惹かれましたが、適したプロジェクトがなかなか見つかりませんでした。個人的なプロジェクトでCやC++を使ったのは15年ぶりです。普段は小規模なウェブアプリを作ることが多く、そうした用途にZigは最適ではありません。
それでもZigはとにかく楽しいです。もしインターネットのない環境でノートPCだけを持って無人島に1年取り残されるとしたら、子ども時代に遊んだコンピューターゲーム(例えばAge of Empires IIやCommand and Conquer)のオープンソース再実装を、洗練されていないC++コードからエレガントなZigへ移植して過ごすのが夢です。
- 試してみるべき人は?
- それらの言語を現代的に再解釈したものに興味があるC/C++プログラマー。
- おすすめポイントは?
- Zigは久々に味わった最高に楽しいプログラミング体験です。もともとプログラミング自体が楽しいと思っていますが、特に低い抽象度でコードを書き、アプリケーションがメモリに触れる回数を完全にコントロールする感覚には高揚感があります。
- Zigは明示的な制御フローとメモリ確保を重視して設計されているため、コードの挙動を追いやすいと感じます。
- Zigコミュニティは温かく前向きです。質問すればいつも丁寧で親切な答えが返ってきます。Zigチュートリアルを公開すると、コミュニティが熱心に歓迎してくれます。
- 欠点は?
- どうやって試すのが良い?
- 普段CやC++で書くようなシンプルなプログラムを、代わりにZigで書いてみてください。
- 初学者向け演習のZiglingsを試してみてください。
- Ziglingsの演習はプレリリース版のZigコンパイラに依存します。Nixを使っているなら、最新プレリリース版のZigコンパイラを
nix shell 'github:mitchellh/zig-overlay#master'で簡単に入手できます。
- Ziglingsの演習はプレリリース版のZigコンパイラに依存します。Nixを使っているなら、最新プレリリース版のZigコンパイラを
Nixを使ったファズテスト
Nixの話はこれで終わりだと思いましたか?まだ続きます!
10年前にVLCの深刻な脆弱性を見つけて以来ファジングツールを使っていなかったので、脆弱性発見のためにファズテストを試してみたいと思っていました。
Antonio Morales氏の2021年のファズテストチュートリアルは楽しめましたが、演習のたびにファジング環境を整えるための退屈な下準備が必要でした。
Nixでファジングのワークフローを実装してみたら、はるかに快適でした。もっとNixを使ったファジングチュートリアルを作る時間があればと思うほど、世界はNixをファジングツールとして過小評価していると感じています。
- 試してみるべき人は?
- ファズテストを行うすべての人、特にC/C++コードを対象にする人。
- おすすめポイントは?
- Nixはファジングのワークフローを再現可能にします。
- Nix上でファザーを動かせるようになれば、誰でも
nix runと入力するだけであなたのファジング設定を実行できます。依存関係を自分で解決する必要はありません。Nixがあなたが使ったのと全く同じ環境を自動的に再現してくれるからです。
- Nix上でファザーを動かせるようになれば、誰でも
- Nixは依存関係のインストールを簡素化します。
- Nixはあらゆるパッケージマネージャーの中でも最大級のパッケージリポジトリを持っています。ファジング対象に依存関係があっても、すでにNixのパッケージリポジトリに用意されていることがほとんどなので、依存関係ごとに特別なビルド手順を考える必要がありません。
- Nixはカスタムパッチの適用を簡単にします。
- ターゲットをファズするためにカスタムパッチを当てる必要がある場合でも、Nixなら簡単に適用でき、パッチファイルをファジングワークフローの他のファイルと同じソースツリーで管理できます。
- Nixはビルドをキャッシュします。
- 異なるコンパイルオプションを試すときも、毎回ゼロからコンパイルし直す必要がありません。Nixは同じオプションで以前コンパイルしたかどうかを記憶し、そのビルドを再利用します。
make cleanを実行したりバイナリを手動で削除したりする必要がありません。
- 異なるコンパイルオプションを試すときも、毎回ゼロからコンパイルし直す必要がありません。Nixは同じオプションで以前コンパイルしたかどうかを記憶し、そのビルドを再利用します。
- Nixはファジングのワークフローを再現可能にします。
- 欠点は?
- テスト対象のコードをNix経由でビルドする方法を、余分な抽象化レイヤーとして理解しなければなりません。
- NixはCMakeベースのプロジェクトのビルドを助けるために魔法のようなことをしてくれますが、ビルドオプションがすべて暗黙的なため、その挙動を理解するのが困難です。
- Nixでデバッグシンボルを生成させるのに苦労し、今でも何が間違っていたのかよく分かっていません。
- どうやって試すのが良い?
- Nixとhonggfuzzを使ってオープンソースのPDFリーダー向けにファジングワークフローを作った方法についての、私の初心者向けチュートリアルを試してみてください。
この一年はどうだったか?
毎年、自分は今もインディー起業家という生き方を楽しめているか自問しています。
ここ数年、この問いに答えるのは難しいことでした。TinyPilotを経営していた頃は、会社を誇りに思い、チームとの仕事も楽しんでいましたが、ハードウェア企業のペースと複雑さは自分には重すぎると感じていました。
今年は再びインディー起業家であることを楽しめました。妻や息子とたっぷり時間を過ごせる自由が嬉しかったです。仕事復帰のタイミングは完全に自分で決められ、出産後の生活にどう仕事を組み込んでいくかを自分の裁量でコントロールできたことに感謝しています。
TinyPilotの売却はストレスが多く決して楽しいものではありませんでしたが、振り返って思い出すのは、妻や友人たちとマサチューセッツ州西部で即席のデザートツアーをして祝ったことばかりです。
5月にはGoogleのリクルーターから面接なしで元の職に戻らないかと声がかかりましたが、全く心は動きませんでした。
今もインディー起業家としての生活を楽しんでおり、できる限り長く続けていきたいと思っています。
学んだ教訓
働かなくてもいい
息子が生まれる前、どれくらい休みを取るべきか悩んでいました。1ヶ月休むのは当然問題ない。でも1ヶ月が大丈夫なら、なぜ2ヶ月ではいけないのか?4ヶ月は?1年は?
息子が生まれてからの数ヶ月、突然自由な時間がなくなりました。さらに怖い問いと向き合うことになりました。赤ちゃんがいる今、たとえ働きたいと思っても仕事に戻れないのではないか?執筆やプログラミングに集中できるまとまった時間を二度と取り戻せないのではないか?と。
深呼吸して気づきました。「自由な時間がない」のは、週に何日も妻と息子と一緒に街の中心部まで長く散歩し、屋外でブランチを楽しんでいたからでした。あるいは遠方からの訪問者を迎えて赤ちゃんに会ってもらっていたからです。これらはすべて自分がやりたくてやっている良いことなのだと、そして仕事を再開しようと思えば自分の時間をコントロールできるのだと思い出す必要がありました。
結局、仕事への復帰は自然な流れで起こり、家族との時間と対立するものではありませんでした。妻と私は自分たちに合った育児のバランスを見つけ、息子が成長するにつれて、他の家族も育児を手伝ってくれるようになり、今も調整を続けています。
誰かがそのドキュメントを使ってみるまで、プロセスは文書化されたことにならない
TinyPilotの売却に向けた数ヶ月間、私はできる限りチームの他のメンバーに業務を委譲することに集中しました。新しいオーナーが引き継いだ際に、私しかやり方を知らないせいで重要なタスクを完了できないと感じてほしくなかったからです。
すべてにプレイブックがあり、自分が担当していたタスクでさえ文書化されていたので、委譲は簡単だと思っていました。しかし実際にチームメートへ引き継ぎ始めると、「文書化されている」はずのプロセスの多くが、実際には自分の頭の中にしか存在していないことに気づきました。「リリース告知を書く」や「公開チェンジログを更新する」といったステップは、その短いフレーズが示すよりはるかに複雑だったのです。
今では、チームメートがドキュメントだけを頼りにプロセスを遂行できたとき初めて、そのプロセスは文書化されたと考えるようにしています。
現金で買える買い手への売却はリスクと書類作業を大幅に減らす
TinyPilotの売却から得た最大の教訓の1つは、クロージングまでの期間がどれほど大きな違いを生むかということです。売却が1ヶ月長引くごとに、売り手がどれだけ多くの追加リスクと書類作業を負うことになるか分かっていませんでした。

買い手の資金調達方法はクロージングまでの期間に大きく影響します。買い手が銀行から借り入れをする場合、銀行が取引の重要な意思決定者になります。銀行は動きが遅く、大量の書類を要求し、取引が破談になっても痛みを感じないため交渉が困難です。
もし次に会社を売却する機会があれば、手元に現金を持つ買い手を惹きつけるためのインセンティブを用意するつもりです。
去年の目標の採点
昨年、私は年内に達成したい3つの大きな目標を立てました。その結果は次のとおりです。
TinyPilotの運営を週20時間に抑える
- 結果: マネジメントを週20時間まで削減
- 評価: A
会社を4月に売却したため、TinyPilotをマネジメントしたのは1年のうち短い期間だけでしたが、ようやく週20時間での運営という目標を達成できました。これは過去3年間繰り返し掲げてきた目標でした。
最終的にうまくいったのは、他に選択肢がなかったからです。デューデリジェンスと売却対応だけで週15〜20時間を取られ、以前のように他の業務に時間を割く余裕がまったくなかったのです。幸い、チームがそれまで委譲しようとも考えていなかったタスクを引き受けてくれました。
コースまたは書籍を出版する
- 結果: ライブコースは実施したが、コースや書籍は出版できず。
- 評価: C
ライブ版を省けばコースをリリースできていたかもしれませんが、試運転をしたことでコースの方向性について有益なフィードバックが得られたので、やってよかったと思っています。
週10時間はコードを書く
- 結果: 週10〜20時間ソフトウェアを書いている。
- 評価: A
より頻繁にコードを書くようになり、心から楽しんでいます。
来年の目標
5万ドルの利益を上げる
すべてのプロダクトを合わせて、5万ドルの利益を上げたいと考えています。継続的な収益である必要はなく、一時的な売上も含めて構いません。自分のプロダクトの販売で少なくとも5万ドルを稼ぐ方法を見つけたいです。
コースまたは書籍を出版する
2021年から毎年、本を出版することを目標に掲げてきました。一度も達成できていませんが、今年こそ実現できそうな気がしています。
新しいプログラミング言語を学ぶ
新しいプログラミング言語を学ぶたびに、プログラミング全般に応用できる洞察が得られます。
お気に入りのブロガーの多くがElixirとPhoenixに夢中になっているので、この技術スタックを試してみたいと思っています。
記事をランダムに読む
コメント
ログインしてコメントする