7年前、私はGoogleの開発者としての仕事を辞め、自己資金で自分のソフトウェア会社を立ち上げました。毎年、その歩みやインディー創業者としての暮らしについて近況を綴っています。

会社を売却しました

この1年で最も大きな出来事は、2020年に創業したTinyPilotを売却したことです。

妻と私は家族を持ちたいと考えていました。7人規模の会社を一人で切り盛りしながら、新生児の良い父親でいることは両立できないと思ったのです。会社へのビジョンを共有できる買い手が見つかり、2024年4月に売却が完了しました。

売却の経緯や売却から学んだことについてはすでに記事やポッドキャストで語っていますが、ひと言でいえば、すべてがうまくいったことに感謝しています。

親になりました

8月、妻と私たちの間に第一子となる男の子が生まれました。

出産直後、看護師の方が私たち3人の素敵な写真を撮ってくれました。下に載せています。息子のプライバシーを守るため、手作業で調整した高速フーリエ変換で生体情報を取り除く加工を施しました。

インディー創業者ならではの柔軟な働き方と、TinyPilot売却のタイミングに感謝しています。ここ5か月は、人生で最も幸せな時間でした。

教育コンテンツに取り組みました

TinyPilotは4月に売却しましたが、引き継ぎのため5月中旬まで会社に残りました。

息子は8月生まれの予定で、生まれたら休みを取るつもりでした。となると、新しいことを始める猶予は3か月ほど。しかも出産後の生活が落ち着くまで、数か月棚上げにできるものである必要がありました。

そこでこの3か月に最適なのは、ダウンロード形式のコースや書籍だと考えました。教育コンテンツなら作業を中断しやすいですし、たとえ購入者がいてもサーバーの運用やサポート対応に追われることがありません。

教育コンテンツを作った経験は、2021年に一度だけあります。技術者向けのブログ運営についての動画コースを収録しました。初年度に7.6kドル、その後さらに2.2kドルの収益がありました。ヒットコースと呼べる額ではありませんが、制作にかかったのは約100時間で、内容には誇りを持っています。インディー創業者になってから最も投資対効果の高いプロジェクトでした。

夏の間、2021年のブログ講座の内容を改訂しました。まずは少人数の受講生に週1回のライブビデオ通話で教えることから始めました。受講生のフィードバックをもとに内容を磨き、最終的にダウンロード販売できる完成版を収録して販売する計画でした。

ライブ講座の出来はまずまずでしたが、受講生からは「集客よりも、文章そのものの技術をもっと学びたい」という声がありました。最後まで完成させたい気持ちはありましたが、息子が予定より数週間早く生まれたため、収録を終えることができませんでした。

息子が生まれてからは自宅での動画収録が難しくなったので、開発者向けの効果的なライティング技法についての本の執筆に切り替えました。章ごとに公開し、読者からのフィードバックをもとに内容を改善しています。

撮りかけのブログ講座の動画がまだたくさん手元にあり、使い道に迷っているので、そのうちの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ツールに価値を感じる開発者。
• おすすめポイント
  • ソフトウェアプロジェクトでは、すべての依存関係をソースコードとして定義できます。誰でもワンコマンドで同じ環境を再現できます。
  • NixOSはNixの思想に基づいて設計されたLinuxディストリビューションです。コンピューター全体の設定をプレーンテキストのファイルで定義できます。ゼロから再構築したり、以前の設定にロールバックしたりすることが簡単にできます。
  • NixにはDockerの利点が多く備わっていますが、Dockerイメージよりもパッケージの組み合わせに優れています。
• いまいちな点
  • Nixは学習曲線が急で、開発者向けの良い入門ガイドが見つかっていません。最も近いのはDevOpsエンジニア向けのNixOS in Productionです。
  • 「flakes」と呼ばれる機能をめぐってコミュニティに分裂があります。flakesを使うと、使っていないチュートリアルやドキュメントが理解しづらくなり、その逆も同様です。
  • Nixコミュニティはリーダーシップの問題から健全とは言えない状態にあります。
  • 継続的インテグレーション（CI）では、Nixは小規模なジョブでスケールしません。Nix専用のCIベンダーに切り替えない限り、Nixに依存するCIジョブを55秒以内で実行する方法が見つかっていません。
• 試してみるには
  • 小さな範囲から少しずつNixを試してみてください。狭い機能だけを学ぶだけでも大きな価値を得られます。
  • Determinate SystemsのインストーラーでNixをインストールし、nix shellでプログラムを実行してみてください（例：nix shell -p cowsayとしてからcowsay howdy, human）。パッケージリポジトリで、ワンライナーでインストールできるすべてのパッケージを検索できます。
  • 一時的なシェルが気に入ったら、プロジェクトの1つでdev shellを作ってみてください。すべての依存関係や開発ツールを1つのファイルで管理できます。

htmx

数年前から友人たちがhtmxを絶賛していましたが、私にはその良さがピンと来ませんでした。

「HTMLの<button>要素でPOSTリクエストが送れる？それがどうした？」

ある長いフライトの間に、htmxの思想について書かれた無料の電子書籍Hypermedia Systemsを読みました。そこで気づいたのです。htmxの価値は<button>でPOSTを送れることではなく、カスタムJavaScriptや何層もの抽象化に頼らず、HTMLに手軽なインタラクティビティをもたらすことにあるのだと。

Web開発には面倒なJavaScriptがたくさん伴うことは分かっていましたが、それが当たり前だとずっと思い込んでいました。HTMLとCSSが見た目を、JavaScriptがインタラクションを担う。両者をつなぐグルーコードは必要で、それは本質的につまらないものだと。

htmxの主張は、HTML/CSS側により多くのインタラクティブ性を持たせることで、グルーコードや定型的なJavaScriptをなくせるというものです。しかもnpmやWebpack、巨大なフロントエンドフレームワークのような複雑さや依存関係を持ち込む必要はありません。

• こんな人におすすめ
  • ReactやVueのような重量級フレームワークより、素のJavaScriptやjQueryを好む開発者。
• おすすめポイント
  • htmxを使うと、これまでどれだけ不要なJavaScriptを書いてきたかに気づかされます。
  • htmxはフレームワークではなくライブラリなので、ReactやVueのようにすべてを置き換える必要はありません。Webアプリの1つのフォームだけで試すことができます。
  • ビルドステップがないため、プレーンテキストのHTMLやCSS、JavaScriptを生成するためにWebpackやNode.jsを通す必要がありません。書いたコードがそのままブラウザで動くコードになります。
• いまいちな点
  • htmx的な発想への切り替えは難しいと感じましたが、結果的によりシンプルなコードになることが多かったです。
  • htmxのエラーハンドリングはぎこちないと感じますが、まずまずの回避策を見つけました。
  • htmxはContent Security Policy（CSP）を弱めてしまいます。
• 試してみるには
  • 私のより詳しいhtmxのすすめを読んでみてください。
  • ScreenJournalをhtmxに移植した経験を読んでみてください。
  • Hypermedia Systemsの最初の数章を読んでみてください（無料でオンライン公開されています）。共感できるか確かめてみてください。
  • 自分のWebアプリケーションの1つのフォームでhtmxを試してみてください。

Zig

Zigの発想はこうです。いまだにCのような低水準言語で書く必要のあるプログラムは存在するのに、50年前の言語を使い続けることで自ら困難にしている、というものです。

ZigはCと同等のパワーとパフォーマンスを提供しながら、Cが生まれた当時にはなかったハードウェアやコンパイラの進歩を活かしています。

私はすぐにZigの思想が大好きになりましたが、題材が見つからず苦労しました。個人プロジェクトでCやC++を使ったのは15年ぶりです。普段は小規模なWebアプリを作ることが多く、Zigはそうした用途には最適とは言えません。

それでもZigはとにかく楽しいです。もしインターネットのない孤島にノートPC1台で1年取り残されたら、やりたいことは、子供の頃に遊んだゲーム（例：Age of Empires IIやCommand and Conquer）のオープンソース再実装を、洗練されていないC++コードからエレガントなZigへ移植することです。

• こんな人におすすめ
  • C/C++プログラマーで、それらの言語を現代的に再解釈したものに興味がある人。
• おすすめポイント
  • Zigは久しぶりに心から楽しいと感じさせてくれたプログラミング言語です。普段からプログラミングは楽しいのですが、Zigにはまた別格の楽しさがあります。極めて低い抽象度でコードを書き、メモリの特定領域にアプリケーションが何回触れるかを完全にコントロールする高揚感があります。
  • Zigは制御フローとメモリ確保を明示的にすることを重視しているので、コードの挙動を追いやすいと感じます。
  • Zigコミュニティは温かく前向きです。質問すればいつも丁寧で親切な答えが返ってきます。Zigチュートリアルを公開すると、コミュニティが熱心に歓迎してくれます。
• いまいちな点
  • まだ安定版の1.0がリリースされておらず、コンパイラを更新するたびにコードの一部を書き直すことになるでしょう。
  • コンパイラの仕様変更が頻繁なため、ブログ記事や時には公式ドキュメントのサンプルコードも手直しが必要になります。
  • 言語を学ぶための良い教材が見つかっていません。まだZigの書籍はありません。私は主にバラバラなブログ記事やフォーラムの議論、Zig言語仕様をかき集めて学んでいます。
• 試してみるには
  • 普段CやC++で書くようなシンプルなプログラムを、Zigで書いてみてください。
  • Zigを学ぶための初心者向け演習、Ziglingsを試してみてください。
    • Ziglingsの演習はプレリリース版のZigコンパイラに依存しています。Nixを使っているなら、最新のプレリリース版を簡単に入手する方法は次のコマンドです：nix shell 'github:mitchellh/zig-overlay#master'

Nixを使ったファズテスト

Nixの話は終わったと思いましたか？まだ続きます！

10年前にVLCの深刻な脆弱性を見つけて以来ファジングツールを使っていなかったので、脆弱性発見のためにファズテストを試してみたいと思っていました。

Antonio Morales氏の2021年のファズテストチュートリアルは楽しめましたが、演習のたびに動作するファジング環境を整えるための退屈な準備作業が必要でした。

Nixでファジングのワークフローを実装してみたところ、格段に快適でした。もっと時間があればNixを使ったファジングチュートリアルを増やしたいくらいです。世界はNixをファジングツールとして過小評価していると感じています。

• こんな人におすすめ
  • ファズテストを行う人、特にC/C++コードを対象にする人。
• おすすめポイント
  • Nixはファジングのワークフローを再現可能にします。
    • 一度Nix上でファザーを動かせば、誰でもnix runと入力するだけで同じファジング設定を実行できます。Nixが使った環境を自動的に再現するため、依存関係を自分で解決する必要がありません。
  • Nixは依存関係のインストールを簡素化します。
    • Nixは最も大規模なパッケージリポジトリの1つを持っており、ファズ対象に依存関係があっても、たいていはすでにリポジトリに用意されているため、依存ごとに特別なビルド手順を考える必要がありません。
  • Nixはカスタムパッチの適用を簡単にします。
    • 対象をファズするためにカスタムパッチを当てる必要がある場合でも、Nixなら簡単に適用でき、パッチファイルをファジングワークフローの他のファイルと同じソースツリーに置いておけます。
  • Nixはビルドをキャッシュします。
    • 異なるコンパイルオプションを試しても、毎回ゼロからコンパイルする必要はありません。同じオプションで以前コンパイルしたことがあれば、Nixがそれを記憶して再利用します。make cleanをしたりバイナリを手動で削除したりする必要がありません。
• いまいちな点
  • テスト対象のコードをNix経由でどうビルドするかを、抽象化レイヤーを一枚挟んで考えなければなりません。
  • NixはCMakeベースのプロジェクトのビルドを助けるために魔法のようなことをしてくれますが、ビルドオプションがすべて暗黙的なため、挙動を理解するのが難しくなります。
  • Nixでデバッグシンボルを出力させるのに苦労し、今でも何が悪かったのかよく分かっていません。
• 試してみるには
  • Nixとhonggfuzzを使ってオープンソースのPDFリーダー向けファジングワークフローを作った、私の初心者向けチュートリアルを試してみてください。

この1年を振り返って

毎年、自分は今もインディー創業者として楽しめているか自問しています。

ここ数年、この問いに答えるのは難しいと感じていました。TinyPilotという会社を誇りに思い、チームとの仕事も楽しんでいましたが、ハードウェア企業のペースと複雑さは自分には荷が重すぎたのです。

今年は、再びインディー創業者であることを楽しめました。妻や息子と過ごす自由な時間を心から愛おしく思いました。仕事復帰のタイミングを自分で完全に決められ、出産後の生活にどう仕事を組み込むかを自分の裁量でコントロールできたことに感謝しています。

TinyPilotの売却はストレスが多く楽しいものではありませんでした。ただ振り返ってみると、記憶に残っているのは妻や友人と即興で回った西マサチューセッツのデザートツアーでお祝いしたことです。

5月にはGoogleのリクルーターから無面接で前の職への復帰を打診されましたが、まったく心は動きませんでした。

私は今もインディー創業者としての人生を楽しんでおり、できる限り長く続けていきたいと思っています。

学んだこと

働かなくてもいい

息子が生まれる前、どれくらい休みを取るべきか悩みました。一ヶ月休むのは当然いい。でも一ヶ月がいいなら、二ヶ月はどうだろう。四ヶ月は？一年休んでもいいのだろうか。

息子が生まれてからの数か月、突然自分の時間がなくなりました。さらに怖い疑問が湧いてきました。もし、赤ちゃんがいる今、戻りたくても仕事に戻れなくなったらどうしよう。まとまった作業時間を二度と確保できなくなったらどうしよう、と。

一呼吸置いて気づきました。「時間がない」と感じていたのは、週に何日も妻と息子と街中を散歩し、屋外でブランチを楽しんでいたからでした。あるいは遠方からの来客を迎えて赤ちゃんに会ってもらったり。そうした時間はすべて、自分が「やりたくてやっている良いこと」なのだと、そして仕事を再開しようと思えば、自分の時間は今も自分でコントロールできるのだと、自分に言い聞かせました。

結局、仕事への復帰は自然な流れで訪れ、家族との時間と対立するものではありませんでした。妻と私は二人にとって心地よい育児のバランスを見つけ、息子の成長や他の家族のサポートも得ながら、今も調整を続けています。

ドキュメントは誰かが使って初めて完成する

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に熱中しているので、この技術スタックを試してみたいと思っています。