一言でまとめると

TinyPilotの利益率をどうやって上げるか？

ハイライト

• 月商3万ドルあるにもかかわらず、TinyPilotはかろうじてコストを賄えている程度だ。
• 大企業にもっと支払ってもらう方法を模索している。
• 人をマネジメントすること自体が立派な仕事であるという現実を受け入れなければならない。

目標の成績表

毎月のはじめに達成したい目標を掲げている。結果は次のとおりだ。

TinyPilotの売上を3万3000ドルに伸ばす

• 結果: TinyPilotの売上を3万9000ドルに伸ばした
• 評価: A

TinyPilotは、ITハードウェア分野でトップクラスのブログ／YouTubeチャンネルであるServeTheHomeによる大規模なレビューをきっかけに、売上が大きく跳ね上がった。

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

• 結果: TinyPilotの運営を新オフィスへ完全に移転した
• 評価: A

やっと自宅から本物のオフィスへTinyPilotの運営を移すことができた。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を自分のマシンで動かすため、Mikeの即時対応を要する緊急事態がまず発生しないことだ。

Mikeとは面識がなかったが、自己紹介のメールを送り、TinyPilotについて何かアドバイスがないか尋ねてみた。彼は翌日に惜しみなくいくつもの提案を返してくれた。中でも最も印象に残ったのは、私の財務状況に対する彼の反応だった。

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

それは目を覚まさせてくれる有益な指摘だった。利益が低いことはわかっていたが、それでも月商3万ドルあれば良い位置にいると感じていた。しかし5%という利益率で考えると、見方ががらりと変わる。

Mikeのアドバイスをもとに、経費をもう少し詳しく見てみた。5月分の帳簿はまだつけていないので、例として4月の数字を使う。

原材料費はそれほど意外ではない。ハードウェア製品の利益率はだいたい50〜60%なので、売上約3万ドルに対して1万5000ドルというのは想定どおりだ。私が買っている材料にはより安い代替品がないため、そこに大きな調整の余地はない。ケーブルのように品質のためにプレミアムを払っているものもいくつかあるが、それは300ドルで販売する製品1台あたり1〜2ドルの違いでしかない。高価な部品は、Raspberry PiやHDMIキャプチャチップのように、そもそも安い代替品が存在しないものだ。

2番目に大きい経費はソフトウェア開発で、自分でもコードが書けるのに奇妙に思われるかもしれない。問題は、良いソフトウェアを書くには途切れない集中時間が必要なのに、TinyPilotにはソフトウェア以外に動かさなければならないことが多すぎて、その時間が取れないことだ。2020年末には、私が唯一の開発者で、新製品の追加に伴うあらゆるロジスティクスに追われていたため、TinyPilotのソフトウェア開発はほとんど止まってしまった。

より安い開発者を雇うこともできるが、すぐに悲惨なことになるだろう。一緒に仕事をしている開発者たちはとりわけ優秀で、コードベースの品質を高く保ち、ソフトウェアの保守性とバグの少なさを維持してくれている。

これまでに時給約30ドルの安い開発者と仕事をしたこともあるが、彼らはそもそも作業のやり方がわからないか、稚拙な実装をして後でバグや保守の頭痛の種を生むかのどちらかだった。もし低コストの開発者だけでプロジェクトを回せば、数ヶ月のうちにコードベースは保守不可能な悪夢と化すだろう。

これ以外に、意味のある形で削れる経費はない。3番目に大きい経費は現地のフルフィルメントスタッフだが、たとえ50%削減したとしても総経費は2.4%しか減らないので、うまく回っている仕組みをいじる価値はない。

Mike Perhamのアドバイスに従うもう一つの方法は、売上を増やすことだ。

大口顧客から価値を回収する

今年の初め、大企業のあるITマネージャーと話した。彼はTinyPilotを気に入り、社内で従来の2000ドルのエンタープライズ機器を置き換えるために推進したいと考えていた。そしてそれは実現した。その企業はある部門全体に40台のTinyPilotを導入し、さらに増やす計画だった。

その導入でTinyPilotがいくら稼いだと思うだろうか。ゼロだ。

彼らは私からハードウェアを買う代わりに、単に自分たちでデバイスを自作したのだ。そしてソフトウェアが寛容なオープンソースライセンスの下にあるため、彼らは私に一切支払うことなく社内で自由に使うことができた。

これはオープンソースでは極めてよくある問題だ。オープンなライセンスは人々が製品を見つけて使うきっかけになるが、同時に大企業が何の見返りもなくあなたの仕事から利益を得ることを可能にしてしまう。

このことについてもMike Perhamに相談してみた。彼の返答はこうだった。

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

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

私はTinyPilotをMITライセンスで公開した。自分にとっても柔軟性があるからだ。自分自身でコードを「フォーク」して別のライセンスにし、MITライセンスのコードも使っていると言えばいいのだと思うが、そのあたりがどう機能するのかは完全にはわかっていない。

大口のエンタープライズ顧客からより多くの価値を回収する方法について考えてみた。思いついたのは次のとおりだ。

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

大口顧客だけが求め、他の誰も求めない機能の一つに、TinyPilotへのプログラム的なアクセスがある。例えば「リモート画面を監視して、対象デバイスがクラッシュしたことを検知したらアラートを出したい」といった要望だ。

この機能を備えたエンタープライズ版のTinyPilotについて、かなりのプレミアム価格で大口顧客と話をしていく予定だ。1デバイスあたり月50ドルといった価格は家庭ユーザーには法外に感じられるだろうが、自前で何週間もかけてソリューションを構築する手間が省けるのであれば、Fortune 500企業にとっては取るに足らない金額だ。

SaaSアドオンを提供する

TinyPilotはデバイスと同じローカルネットワーク上にいれば使いやすいが、インターネット経由でTinyPilotにアクセスしたい場合、現状では顧客はサードパーティのソリューションに頼らざるを得ない。私は数人の顧客に「TinyPilot Cloud Portal」というアイデアを打診してみた。インターネット上のどこからでもTinyPilotデバイスにリモートアクセスできる、安全なウェブインターフェースだ。

これは素晴らしいSaaSのサブスクリプション機会になり、TinyPilotのハードウェア製品を補完しつつ、より高い利益率をもたらしてくれるだろう。

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

オープンソースライセンスを専門とする弁護士に相談する

オープンソースライセンスについてはまだわからないことが多いので、選択肢が何なのか弁護士に相談すべきだ。理想的なライセンスは、個人ユーザーが自宅で試せるように手頃な価格を保ちつつ、職場に持ち込む際には商用利用としてより高額なライセンスが必要になるようなものだ。Sidekiqと同様に。

過去のプロジェクト

以下は、今も維持はしているが、開発の主軸ではないプロジェクトに関する簡単な近況だ。

Is It Keto

Is It Ketoはバックグラウンドで動き続けているが、今月は珍しく少し手を入れた。Amazonアフィリエイトリンクの多くが古くなり、存在しない商品を指すようになっていたので、数時間かけて修正した。

数ヶ月ぶりにコードの埃を払うと、サイトをいじくり回す沼にハマりたくてたまらなくなる。できる限り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万5000ドルの売上を上げる。
• 組み込みPower over Ethernetを備えたTinyPilot Voyager 2のプロトタイプを作成する。