一言でまとめると

私の時間はどこへ消えているのか？（2023年版）

ハイライト

• TinyPilotで無駄な時間の使い方をしていないか、洗い出そうとしています。
• またしてもメール中毒に陥っていることに気づきました。
• 初めてサーバーラックを組みました。

今月の目標と自己評価

毎月のはじめに達成したい目標を宣言しています。その目標に対してどうだったかを振り返ります。

新しい製造委託先で製造ロットを開始する

• 結果：最初の製造ロットが動き出しました。
• 評価：A

製造委託先と発注書にサインし、最初の生産ロットが動き出しました。これまでで事業にとって最も大きな単独の変化になるため、正直怖さもあります。うまくいけば素晴らしい成果になりますし、失敗すれば大惨事です。前者になることを祈っています。

TinyPilot Pro 2.6.0をリリースする

• 結果：予定どおりTinyPilot Pro 2.6.0をリリースしました。
• 評価：A

6月のリリースは滞りなく進みましたが、やや物足りなさが残りました。直近2回のリリースでは、アップデートをより簡単で失敗しにくくすることに開発工数を割いてきました。おかげでソフトウェアの保守性は大きく向上しましたが、リリース告知で華やかに語れる内容ではありません。

売上9万5000ドルを達成する

• 結果：売上は9万3000ドルに到達しました。
• 評価：C

TinyPilotの売上はほぼ横ばいでした。新しいレビュー動画が公開されましたが反応は今一つで、期待したほど販売にはつながりませんでした。

TinyPilotの数値

ほぼすべての指標が今月は横ばいでした。仕掛けたマーケティング施策の一つは空振りに終わりましたが、他に準備中の施策にはまだ期待しています。

TinyPilotの広告効率は大きく下がりました。5月は広告費1ドルあたり3.64ドルの売上がありましたが、6月は1ドルあたり2.62ドルまで落ち込んでいます。2.62ドルの売上のうち材料費が約0.90ドルかかることを考えると、広告はまだ黒字ではあるものの、利益率は薄くなっています。

広告はもう1か月様子を見ます。改善が見られなければ、TinyPilotのマーケティングコンサルタントに相談の時間を取って、改善点を探ろうと思います。

自分の時間はどこに消えているのか？

先日参加したインディー系創業者のミートアップで、目下の悩みは重要だが緊急ではないタスクに時間を割けないことだと話しました。

そこにいた他の参加者は驚いた様子でした。なぜ全部を自動化したり、誰かに任せたりできないのか。何がそこまで自分でなければできないことなのか、と。

昨年、自分の時間の使い方を棚卸ししたのが役に立ったので、今回も同じことをやってみることにしました。

以下が、TinyPilotの創業者として私の時間の大部分を占めているタスクです。

タスク1：変更の調整

TinyPilotのチームが2人を超えたあたりから、変更を調整することが私の主要な役割の一つだと気づきました。

TinyPilotは複数の軸で同時に成長しています。ソフトウェアを改善し、ハードウェアを改善し、新しいベンダーを組み込み、チームの人数も増やしていく、といった具合です。

事業のある領域での変更は、たいてい他の領域に波及します。人数も複雑さも増すにつれ、その波及は頻度も影響の大きさも増しています。

ここで自分の時間を減らすには？

ミートアップでは「マネージャーを雇えばいい」と助言する人もいましたが、そう簡単な話ではありません。

TinyPilotには2〜3人で構成された3つのチームがあります。ソフトウェア開発、サポートエンジニアリング、カスタマーサービス／現地オペレーションです。3チームの担当範囲はほとんど重なっていません。

もし1チームだけを任せるマネージャーを雇っても、節約できる時間はわずかでしょう。かといって3チームすべてを任せるとなると、ソフトウェアのマネジメント経験が必要になるため、年収は12万5000ドル以上が相場になります。諸経費を含めると採用コストは年20万ドル以上になり、TinyPilotの今の利益がすべて消えてしまいます。

思いつく最善の策は、昨年と同じ結論です。並行して進めるプロジェクトを絞り、任せられる機会をもっと探すことです。

中には、自分しかできない部分があるからと自分で抱え込んでしまうタスクもあります。たとえばタスクがA、B、Cの3つに分かれていて、BでTinyPilotを代表して契約書にサインする必要があると、「これは自分しかできない」と考えてしまうのです。そうした場合でも、AとCは任せられるのに、その可能性を考えずに丸ごと引き受けてしまうことがあります。

もう一つの解決策は、より多くの業務をベンダーに寄せて、内製する範囲を減らすことです。今年は自社での発送業務をやめ、物流代行（3PL）ベンダーに移管しました。例外対応は難しくなりましたが、これまで抱えていた一連の業務そのものをなくすことができました。

タスク2：3PLパートナーとの関係管理

3PLベンダーへの移行作業は、初期に負荷が集中するものだと予想していました。ベンダーを選定して切り替えるまでは大変でも、その後はほぼ順調にいくだろうと考えていたのです。

しかし実際には、3PLベンダーと詰めるべき細かな運用がまだ次々に出てきます。

• 在庫が自社オフィスから3PLの倉庫へ移動する間、どうやって追跡するのか？
• 3PL側で在庫が紛失していないことをどう確認するのか？
• 3PLが誤った商品を発送してしまった場合、どう解決するのか？
• 当日発送を希望する顧客にどう対応するのか？

いずれも解決可能な問題ですが、新たな課題が絶えず出てくるため、3PLのことに多くの時間を割いています。

ここで自分の時間を減らすには？

ここはもっとチームに任せるべき領域です。

TinyPilotの現地スタッフにもっと主体的に3PLとの関係を管理してもらうようにし始め、うまく機能しつつあります。

以前なら、たとえば「3PLによる在庫紛失を防ぐ」という課題に対して、私が在庫レポートを監査する手順まで自分で定義していました。今は自分で細部まで決めるのではなく、現地スタッフのメンバーに任せるようにしています。

タスク3：ソフトウェア開発への関与

TinyPilotのソフトウェア開発にも多くの時間を割いています。それがTinyPilotの中で最も楽しい部分だからです。あまりコードを書く時間は取れなくなりましたが、根っこは今でも開発者です。

数時間空きができると、つい小さなバグを直したり、コードを少しきれいにしたりして過ごしてしまいます。ただ、一見小さな変更が何日もの作業に膨らむこともあります。

ここで自分の時間を減らすには？

これは難しい問題です。端的に言えば「Michaelはコードを書くのをやめるべき」ということになるからです。

でも、コードを書くのが好きなのです……

より現実的な解決策は、自分が引き受けるタスクをより慎重に選ぶことです。自分が担う開発作業は次のものに絞るべきだと考えています。

• ドキュメントの改善、テストの拡充、便利スクリプトの追加といった開発者体験の向上
• 社内での経緯や背景を知っている私が対応したほうが、他の人に仕様を説明するより早い変更
• うまくいけば有益で、ダメなら捨てられるような実験的な変更

タスク4：ドキュメントのレビュー

サポートエンジニアリングチームは、日々のカスタマーサポートに加えて、ドキュメントやチュートリアルも執筆しています。私は公開するドキュメントの品質にこだわりがあるため、チームの文章をレビューし、文体や分かりやすさ、技術的な表現についてフィードバックするのに多くの時間を割いています。

ドキュメントレビュー自体は実作業時間としては長くありませんが、非常に集中力を要します。自分で文章を分かりやすく書くこと自体が頭を使うのに、他人の文章を読んで何が不足しているか、何が分かりにくいかを言語化するのはさらに大変です。

そのため、ドキュメント関連のタスクでは私がボトルネックになることがよくあります。新しいチュートリアルをレビューする1時間が空いていても、有益なフィードバックを返すだけの集中力が残っていないことが多いのです。

ここで自分の時間を減らすには？

最も手軽な改善は、ピアレビューをもっと活用することです。開発チームでは、コードの90%はエンジニア同士でレビューし、私を介さずに済んでいます。文章の英語スタイルをコードほど一貫させるのは難しいですが、ドキュメント編集の8割程度はピアレビューで賄えるはずです。

もう一つ見直すべきは、ドキュメントのタスクを割り振る際に自分のキャパシティを考慮することです。以前はサポートエンジニアリングチームのタスクキューにチュートリアルを3本続けて積んでいましたが、結果として一度にすべてをレビューする余力がありませんでした。レビューする時間を確保できるよう、ドキュメントタスクの間隔をもっと空けるべきです。

メール中毒から抜け出す

この数年、メールとの付き合い方は、健全な状態と不健全な中毒状態を行ったり来たりしています。

なぜ健全なメール習慣を崩してしまったのか？

健全なメール習慣が身についている間は、それを維持するのは比較的簡単です。習慣が崩れるきっかけは、たいてい「メールを頻繁に確認する正当な理由」が生まれたときです。

最近、TinyPilotの金属ケースを製造するベンダーの納品が遅れ、在庫を切らしてしまいました。ケースが切れると新しいデバイスを組み立てられなくなるため、非常に厄介です。そうなると現地チームのタスクを急きょ割り振り直す必要があり、しかも数日後にケースが届けばまた元の作業に戻せるよう、中断しやすいタスクを選ばなければなりません。

ケース不足のような緊急時には、メールをこまめにチェックする正当な理由があります。中国のベンダーから金曜の夜にメールが来たのに、月曜の朝まで放置すれば、相手が返信を見るのは中国の火曜の朝です。それだけで3日遅れ、現地チームが新しいデバイスを組み立てられない期間が3日延びることになります。

問題は、緊急事態が終わった後も、頻繁にメールをチェックする癖が残ってしまうことです。そしてメールをチェックして緊急の用件がないと分かっても、まだドーパミンを求めてSNSをチェックしてしまいます。それは何の生産性にもつながりません。30秒だけメールを確認するつもりが、10〜30分かけて際限なくスクロールしてしまうのです。

解決策1：決めた時間にだけメールをチェックする

これまでメール中毒から抜け出すときに効いたのは、1日の予定を明確に区切る方法でした。

毎朝、その日の稼働時間を30分単位に区切り、それぞれの時間を何に使うか決めます。メールを一日中なんとなく気にし続けるのではなく、メールを読み、返信する時間をあらかじめ確保することで、強迫的にチェックするのを防ぎます。

この習慣に無理にでも戻る必要があります。一度リズムに乗ってしまえば継続は簡単ですが、そのリズムに入るまでが大変です。過去の経験では、最初の数日を気合いで乗り切れば、次第に楽になり、意志の力に頼らなくても続けられるようになります。

解決策2：事後的なフィードバックを促す

これを書いている今は午前10時で、今日はまだメールをチェックするのを我慢できています。ただ、仕事を滞らせているような落ち着かない感覚があります。

そう感じるのは、チームメンバーがサポートチケットについて私にフィードバックを求めることが多く、しかもそれを私自身が推奨してきたからです。

チームメンバーがサポートチケットを私にエスカレーションすると、自分の受信箱がより時間に追われるものになることに気づきつつあります。2人のサポートエンジニアのどちらかが対応すればよかったチケットが、私とエスカレーションした担当者の両方が関わることでブロックされるようになります。そうなると顧客を何日も待たせないよう、すぐに返信しなければというプレッシャーを感じてしまいます。

試したことがない選択肢の一つが「並行エスカレーション」です。私のフィードバックを待つためにサポートチケットを止めるのではなく、チームメンバーには顧客対応を続けてもらいながら、並行して私にフィードバックを求めてもらうようにすべきです。

解決策3：ピアレビューをもっと活用できるようチームを後押しする

ドキュメントレビューのところでピアレビューに触れましたが、あらゆる業務でピアレビューが活きる場面をもっと探すべきです。メンバーが互いにスキルを高め合えますし、私個人がボトルネックになるタスクも減らせます。

サイドプロジェクト

初めての自宅サーバーラックを組む

初めて自宅ラボ用サーバーを組んで以来、オフィスにはサーバーやネットワーク機器がどんどん増えていきました。

婚約者からは、オフィスにケーブルが散乱していて掃除しにくいと指摘されていました。私は「いや、これは普通の量だよ」と思っていましたが、改めて見てみると確かにかなりの量でした……

そこで、サーバーラックを組めば二人ともハッピーになれるのではと思いつきました。私にとっては楽しい自宅ラボのプロジェクトになり、彼女にとってはケーブルが一つの筐体に収まってすっきりします。

こうして初めてのサーバーラックを組みました。作る過程も楽しく、見た目もかなりすっきりしました。すべてを縦に積むことで床のケーブルが減り、キャスターで動かせるので掃除も簡単です。

今回初めてマネージドスイッチとVLANを使いました。当初はVLANが面倒でデバッグも難しいと感じていましたが、基本を掴んだ今ではすっかり気に入り、何でもVLAN化したくなっています。

どのコンポーネントをどう選んだか、どんな失敗をしたかについて、より詳しい記事を準備中です。お楽しみに。

Nixを学ぶ

Nixはこの1年、気になる技術リストの最上位にあり、最近ようやく学ぶ時間を取れました。

初めてNixを触ったときのメモを公開したところ、思いがけずHacker NewsやTwitterで大きな反響がありました。Nixコミュニティの人たちが連絡をくれて、詰まった部分を手助けしようとしてくれています。

この反響が励みになり、まだ十分に理解できていない技術を試すときにも、もっとメモを残していこうと思うようになりました。

Goで自作の認証ライブラリを作る

2018年にウェブアプリを作り始めたとき、自分で認証を実装したくなかったので、常にサードパーティのサービスを使っていました。

サードパーティの認証サービスはまずまず機能しましたが、オープンソースプロジェクトの普及を妨げる面がありました。他の開発者が私のアプリをデプロイしようとしても、私と同じ認証サービスを使わなければならなかったのです。

もう一つの問題は、サードパーティ認証によってエンドツーエンドテストが遅くなり、不安定で複雑になることでした。

最新のプロジェクトであるScreenJournalでは、サードパーティに頼らずに認証を実現する方法を探しました。まずは利用可能な認証ライブラリを一通り調べました。私の要件は次のとおりでした。

1. オープンソースであること。
2. ウェブアプリで現在メインに使っているGoで書かれていること。
3. アプリに組み込むライブラリであること。アプリと並走する別サービスではないこと。
4. データストアとしてSQLiteをサポートしていること。

goth（旧gomniauth）のようですが、外部のサードパーティサービスに依存するため要件の3番目を満たしません。

もう一つの人気のGo向け認証ソリューションがauthbossです。こちらはすべての要件を満たしますが、ドキュメントがかなり乏しいのが難点です。それがサポート依頼を抑えるための意図的な選択だと知りました。

午後をかけてauthbossで簡単なウェブアプリを実装してみましたが、基本的な部分すらうまく動きませんでした。調べるほどに、authbossが自分の求めるものと違うことが分かってきました。認証だけでなく、ページ描画やURLのルーティングまでauthbossに任せる前提になっているようで、それは認証ライブラリに求める範囲を超えています。

そこで今は、再利用可能な自作の認証ライブラリを作ろうとしています。人気のオープンソースパッケージにするのが目的ではなく、趣味のプロジェクト間で認証コードをコピペせずに済む、自分用のものが欲しいのです。

今のところできるのはユーザーのパスワードが正しいかを検証することだけで、まだ再利用可能とは言えません。クライアント側でパスワードハッシュを生成しなければならず、本来はそこをライブラリ側で担いたいと考えています。

再利用可能な認証ライブラリの開発は、なかなか面白い挑戦です。普段あまり使わないGoの機能を使わざるを得ませんし、ライブラリがどこまで簡単にし、どこまで柔軟に多様な認証方式に対応するかという設計上のトレードオフを考えるのも良い訓練になります。

まとめ

今月できたこと

• 製造委託先とともにTinyPilot Voyager 2aの最初の生産ロットに着手した。
• 初めて自宅用サーバーラックを組み立てた。
• NixとNixOSの基礎を学んだ。

学んだこと

• 創業者としての時間をより有効に使う余地がいくつかある：
  • 任せられるタスクをもっと探し、大きなタスクは分割して任せやすくする。
  • 引き受ける開発タスクはより慎重に選ぶ。
  • メールに使う時間をより意識的にスケジュールする。
  • チームメンバーにもっとピアレビューを活用するよう促す。
• サーバーラックは、自宅ラボ好きにも、そのパートナーにも楽しい。

来月の目標

• 販売売上で9万8000ドルを達成する。
• 製造委託先への移行を予定どおり進める。
• メールに費やす時間を全体の40%未満に抑える。