一言まとめ

TinyPilotの利益率をどうやって高めるか。

ハイライト

• 月商3万ドルあっても、TinyPilotはかろうじてコストをまかないえているだけです。
• 大企業にもっと支払ってもらう方法を模索しています。
• 人のマネジメント自体が一つの立派な仕事であることを受け止める必要があります。

目標の振り返り

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

TinyPilotの売上を3万3千ドルにする

• 結果：売上を3万9千ドルまで伸ばしました
• 評価：A

ITハードウェア分野で有数のブログ／YouTubeチャンネルであるServeTheHomeによる大きなレビューをきっかけに、売上が急増しました。

TinyPilotの運用を新オフィスへ完全移転する

• 結果：運用を新オフィスに完全に移行しました
• 評価：A

ようやく自宅から本物のオフィスへ運用を移しました。Linuxで印刷をまったく動かせるか不安になった日など、ストレスの多い日もありましたが、全体として移行はスムーズでした。入荷する部材はオフィスに届き、従業員はオフィスで組み立てとテストを行い、出荷もオフィスから行っています。

Refactoring Englishの目次についてフィードバックを集め、改善する

• 結果：フィードバックは集めましたが、どう反映させるかはまだ決めかねています
• 評価：B

Write Useful Booksコミュニティとメーリングリストからフィードバックをもらいました。登録者202人のうち回答は6人で、期待より少なかったものの、役に立つ意見が得られました。

読者は「より良いブログ記事を書く」といった大きなテーマには興味を示す一方で、動詞の使い方を改善する方法といった章にはあまり関心がないようでした。面白い部分を前に出そうと並べ替えたいのですが、後半の章が前半に依存しているため、どうすればいいか悩んでいます。

わくわくする成果は、地味な基礎よりも当然魅力的に映ります。たとえばビデオゲームの作り方の本を書くなら、「賢いAIを備えた敵キャラの作り方」のような章にはみんな興味を持つでしょうし、「線形代数の基礎」にはあまり惹かれないでしょう。だからといって基礎を飛ばせるわけではありませんが、基礎を教えつつも、実践的で応用しやすい形で伝える工夫が必要なのかもしれません。

TinyPilotの統計

TinyPilotにとって過去2番目に良い月になりました。これだけの販売数でもすべてがスムーズに回ったのは嬉しいことでした。1月に同じような注文ラッシュがあったときは対応しきれずパンクしてしまいましたが、今回は受注から発送までのフローを改善したおかげで、すべてのシステムが通常どおり機能しました。

私はただのマネージャー

2012年から2014年まで、私はiSEC Partnersという会社でソフトウェアのセキュリティコンサルタントとして働いていました。当時の上司Peterはニューヨークのチーム全体を率いていましたが、よく自虐的にこう言っていました。「自分はただのマネージャーだ。間接部門にすぎない」と。部下たちが生産的な仕事をしている横で、自分はただ会社の官僚機構の一部にすぎない、という意味でした。

しかしPeterは極めて優秀なマネージャーで、誰もがそれを知っていました。彼が自分の役割を軽く言っていたのは、マネジメントに時間を取られて、セキュリティ研究やツール開発といった会社の中でもっと楽しいことに割く時間が減ってしまうからだと思います。

今ではPeterの気持ちがよく分かります。一日の終わりに、メールを書いただけで終わったような気がすることがよくあります。ただ一歩引いて考えてみると、そうなる理由も分かります。現在、TinyPilotでは多くの人と一緒に働いています。

• リモートのソフトウェア開発者3名
• 在庫管理・組み立て・出荷を担う現地スタッフ3名
• 3Dプリントと電気工学の分野で密に連携しているベンダー2社

つまり、少なくとも週に一度はやり取りする相手が8人いることになります。さらに、オフィスの大家さんや人事・給与サービス、ナレッジベース、在庫管理ツールなど、関わる人やサービスがほかにもあります。そしてカスタマーサポートと営業は私一人で対応しています。

そう考えると、一日の大半をメールのやり取りに費やすのも当然に思えてきます。もっとマネジメントに徹する方向へ、やり方を変えていく必要があります。

自分以外のメンバーができる仕事は抱え込まない

今の私がやっている最も愚かなことの一つは、チームの他のメンバーが十分にできるはずのタスクまで自分で引き受けてしまうことです。先月、1日にコーディングに使えるのは1時間だけだと書きましたが、よく考えてみると、その1時間すらやるべきではありません。チームメンバーがコードを書けるのですから、私は私にしかできないタスクで遅れを取っているのです。

「自分にしかできない」タスクを手放す

他の人でも理論上はできるものの、実際には必要なアクセスや知識が私にしかなくて任せられないタスクがいくつかあります。

これらは主に複数の領域や役割にまたがるタスクで、地元スタッフしか使わないツールの管理などが該当します。私から切り離して任せるべきことを、難易度が低い順に挙げると次のとおりです。

• Shopifyと在庫スプレッドシートをつなぐグルーコードの管理
• TinyPilotの本番イメージをビルドするスクリプトの管理
• 在庫スプレッドシートの数式の管理
• カスタマーサポートへの回答
• TinyPilotリリース時の最終QAテスト

月商3万ドルなのに、なぜ利益が出ないのか

先日、恋人にTinyPilotを成長させる上での悩みをこぼしていたとき、解決策はきっとあるのに、自分のようなビジネスをやっている人とのつながりがなくて気づけていないのだろうと話しました。すると彼女に、誰に相談したいか考えて、思いついた人に直接メールしてみればいいじゃないかと言われました。

最初に思い浮かんだのは、Sidekiqの創業者であるMike Perhamでした。Indie Hackersでの彼のインタビューは私のお気に入りの一つで、まだGoogleの社員だった頃に聞きました。彼のビジネスは、理想的なインディーソフトウェアビジネスとしてずっと印象に残っています。オープンソースソフトウェアを書きながら月商約8万ドルを稼いでいました。しかも顧客はSidekiqを自分のマシンで動かすので、緊急対応を求められる事態がまず起きず、彼自身がすぐに対応を迫られることがないのも最高でした。

面識はありませんでしたが、自己紹介のメールを送り、TinyPilotについて何かアドバイスがないか尋ねました。すると翌日、たくさんの親切な提案とともに返信が届きました。中でも印象に残ったのは、私の収支に対する彼の反応でした。

利益を上げなさい。利益率5%では健全なビジネスとは言えません。コストを下げるか、価格を少し調整するか、あるいは純粋な利益に近いソフトウェアだけのアドオンを見つけなさい。

目を覚まさせられる一言でした。利益が低いことは分かっていましたが、月商3万ドルあれば十分良い位置にいると感じていました。しかし利益率5%という見方をすると、状況がはっきりします。

Mikeの助言をもとに、経費を詳しく見直してみました。5月分の帳簿はまだ締めていないので、例として4月の数字を使います。

原材料費は、想定の範囲内です。ハードウェア製品の利益率はだいたい50〜60%なので、売上約3万ドルに対して1万5千ドルというのは見合った数字です。ここに削れる余地はあまりありません。買っている部材に安い代替品がないからです。ケーブルのように品質のために少し高めのものを選んでいるものもありますが、それは1台あたり1〜2ドルの差で、販売価格は300ドルです。高額な部品は、Raspberry PiやHDMIキャプチャチップのように、そもそも安い代替品が存在しないものばかりです。

2番目に大きい支出はソフトウェア開発費で、自分でコードが書けるのにと思われるかもしれません。問題は、良いコードを書くには途切れない集中時間が必要なのに、TinyPilotにはソフトウェア以外にも動かさなければならないことが多すぎて、その時間が取れないことです。2020年末には、私が唯一の開発者で、新製品の対応など物流面に追われていたため、ソフトウェア開発がほとんど進まなくなりました。

もっと安い開発者を雇うこともできますが、すぐに悲惨なことになるでしょう。今一緒に働いている開発者はとりわけ優秀で、コードベースの品質を高く保ってくれているおかげで、ソフトウェアは保守しやすくバグも少なくなっています。

1時間あたり約30ドルの安い開発者と働いたこともありますが、彼らはそもそも作業の進め方が分からないか、分かったとしても安直な実装をして、後でバグや保守の面で問題を残すことがありました。もし低コストの開発者だけで進めれば、数か月のうちにコードベースは保守不能な悪夢と化すでしょう。

これ以外に、意味のある削減ができる経費はありません。3番目に大きい支出は現地のフルフィルメントスタッフですが、仮に50%削減できたとしても、全体の経費は2.4%しか減りません。うまく回っている仕組みをいじる価値はありません。

Mike Perhamの助言に従うもう一つの方法は、売上を増やすことです。

大口顧客から正当な対価を得る

今年の初め、大企業のあるITマネージャーと話しました。彼はTinyPilotを気に入り、社内で従来の2,000ドルもするエンタープライズ機器の置き換えとして推進してくれました。そしてそれは成功し、同社ではある部署全体に40台のTinyPilotが導入され、さらに追加する計画もありました。

この導入でTinyPilotがどれだけ稼いだと思いますか。答えはゼロです。

彼らは私からハードウェアを買う代わりに、自分たちでデバイスを自作したのです。そしてソフトウェアは寛容なオープンソースライセンスで公開しているため、社内で無償で使うことができました。

これはオープンソースでは極めてよくある問題です。オープンなライセンスは製品を見つけてもらいやすく、使ってもらいやすくしますが、同時に大企業が対価を払わずに成果だけを利用することを許してしまいます。

この点についてもMike Perhamに相談しました。彼の答えはこうでした。

ライセンスのせいで大口顧客にいいようにやられているようだね。これは君のコードなんだろう？ライセンスを変えなさい。たとえば、個人利用に限り1インスタンスだけ使えるようにするとか。MITやBSDライセンスはコードを無償で提供するには最適だが、ビジネスを築く土台としては適していない。

私のコードではあります…一応は。TinyPilotで働くフリーランスは、貢献したコードの知的財産権は私に帰属するという契約を結んでいますが、一方でボランティアの開発者からのコントリビューションもいくつか受け入れています。私の理解では、無償でコードを提供してくれた開発者は、私と共同でTinyPilotのコードの著作権を保有していることになります。

TinyPilotをMITライセンスで公開したのは、私自身にも柔軟性を持たせたかったからです。自分でコードをフォークして別のライセンスにし、MITライセンスのコードも使っているという形にできるはずだと思いますが、そのあたりがどうなるのかは、まだよく分かっていません。

大口のエンタープライズ顧客からより多くの価値を得る方法について考えてみました。次のような案です。

TinyPilot向けエンタープライズ機能の提供

大口顧客から要望があり、それ以外からはまず来ない機能の一つに、TinyPilotへのプログラム的なアクセスがあります。たとえば「リモート画面を監視して、対象デバイスがクラッシュしたことを検知したらアラートを出す」といった使い方です。

この機能を備えたTinyPilotのエンタープライズ版について、大口顧客と話をしていく予定です。1台あたり月50ドルといった価格は個人ユーザーには法外に感じられるでしょうが、もし何週間もかけて自前で解決策を構築する手間が省けるなら、Fortune 500企業にとっては取るに足らない金額です。

SaaSアドオンの提供

TinyPilotはデバイスと同じローカルネットワークにいれば簡単に使えますが、インターネット越しにアクセスしたい場合、現在はサードパーティのソリューションに頼らざるを得ません。いくつかの顧客には「TinyPilot Cloud Portal」というアイデアを打診しています。インターネット上のどこからでもTinyPilotデバイスに安全にリモートアクセスできるウェブインターフェースです。

これは、高い利益率でTinyPilotのハードウェアを補完する、良いサブスクリプション型SaaSの機会になるでしょう。

とはいえ、自分が常時待機しなければならないようなサービスの運用は避けたいと思っています。サービスの運用面を任せられるベンダーと連携する可能性を探っています。

オープンソースライセンスに詳しい弁護士に相談する

オープンソースライセンスについてはまだ分からないことが多いので、選択肢が何なのか弁護士に相談すべきです。理想は、個人ユーザーが手頃な価格で自宅で試せ、職場に持ち込んだ際には商用向けのより高価なライセンスを購入してもらう形で、Sidekiqと同様のモデルです。

これまでのプロジェクト

ここでは、現在も維持はしているものの、開発の主軸ではないプロジェクトについて簡単に近況を報告します。

Is It Keto

Is It Ketoは引き続き裏側で動き続けていますが、今月は珍しく少し手を入れました。Amazonアソシエイトのリンクの多くが古くなり、存在しない商品を指していたので、2時間ほどかけて修正しました。

何か月も触っていなかったコードを久しぶりに開くと、ついあれこれいじりたくなってしまいます。ただ、できるだけTinyPilotに集中した方がいいので、自制しています。

Hit the Front Page of Hacker News

このコースは今でも月に数件売れていますが、宣伝にはあまり時間をかけていません。

一つのハイライトは、Dan Willoughbyがコースで学んだことを活かして記事を書き、Hacker Newsで2位まで上がったことです。しかも「ハック」でシステムを出し抜いたわけではありません。質の高い記事を書くために時間をかけた結果、それにふさわしい反応が得られたのです。それを見るのはとても嬉しいことでした。

Zestful

Zestfulは今もメンテナンスモードですが、先週末に公式のPythonパッケージを公開しました。ずっとあるべきだと思いながら、PyPIへの公開方法が分からず先延ばしにしていました。3月にResticで遊んでいたときに公開方法を学んだので、その知識を活かしてZestfulのパッケージを作ることにしました。

これで、ユーザーは数分でZestfulを使い始められます。パッケージは次のようにインストールします。

pip install zestful-parse-ingredient

次に、parse_ingredientモジュールをインポートして、食材を渡します。

import json
import parse_ingredient

ingredient = parse_ingredient.parse('2 1/2 tablespoons finely chopped parsley')
print(json.dumps(ingredient.as_dict()))

すると、次のようなJSONが出力されます。

{
  "quantity": 2.5,
  "unit": "tablespoon",
  "product": "parsley",
  "productSizeModifier": null,
  "preparationNotes": "finely chopped",
  "usdaInfo": {
      "category": "Vegetables and Vegetable Products",
      "description": "Parsley, fresh",
      "fdcId": "170416",
      "matchMethod": "exact"
  },
  "confidence": 0.9858154,
}

まとめ

できたこと

• TinyPilotの運用を自宅から本物のオフィスへ移した
• 在庫マネージャーと協力して、すべての業務プロセスをNotionに文書化した。
  • Notionには確かに癖や落とし穴もありますが、以前使っていたGoogle Docsよりは大きく前進です。
• TinyPilotの初代在庫マネージャー（私の恋人）から新しい現地スタッフへ業務を引き継いだ。
  • 恋人は来週から大学院の授業が再開するため、TinyPilotに割ける時間がなくなります。

学んだこと

• 新人研修は「見せるより、書いて伝える」。
  • 最初の現地スタッフの研修は、口頭での説明ではなく、ほぼ文書だけで行いました。
  • 立ち上がりが非常にスムーズだったことに全員が満足し、新しいスタッフへの業務引き継ぎも円滑に進みました。
  • 2人目の現地スタッフが5月中旬に入社しましたが、すべてがすでに文書化されているので、立ち上がりはさらにスムーズになるはずです。
• マネジメントにも時間が必要。
  • うまくマネジメントしたいなら、自分以外のメンバーができるタスクは手放す必要があります。
• TinyPilotはもっと利益率を高める必要がある。
  • 経費を削るより、売上を伸ばす方が容易です。

来月の目標

• TinyPilotの新バージョンをリリースする。
• TinyPilotで売上3万5千ドルを達成する。
• Power over Ethernetを内蔵したTinyPilot Voyager 2のプロトタイプを作る。