一行サマリー

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

ハイライト

• TinyPilotで不要に時間を使っているのはどこなのかを探ろうとしている。
• またしてもメール中毒に陥っていることに気づいた。
• 初めてサーバーラックを組み立てた。

目標の成績

毎月のはじめに、達成したいことを宣言している。今回はその目標に対してどうだったかを振り返る。

新しい委託製造業者で製造バッチを開始する

• 結果: 最初の製造バッチがスタートした。
• 評価: A

委託製造業者と発注書を交わしたので、初の生産バッチに向けて動き出した。これまでで事業にとって最も大きな転換になるはずで、正直怖い。うまくいけば素晴らしいことになるし、失敗すれば大惨事だ。前者になることを願っている。

TinyPilot Pro 2.6.0をリリースする

• 結果: TinyPilot Pro 2.6.0を予定通りにリリースした。
• 評価: A

6月のリリースはスムーズに進んだが、どこか物足りなさが残った。ここ2回のリリースでは、アップデートをよりシンプルでエラーが起きにくいものにすることに開発リソースを多く割いてきた。そのおかげでソフトウェアの保守性は大幅に向上したが、リリース告知で盛り上がるような内容ではない。

収益で$95,000を達成する

• 結果: 収益は$93,000に到達した。
• 評価: 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からなり、BでTinyPilotを代表して契約書にサインする必要がある場合だ。そういったケースでも、AとCは委任できるのに、その可能性を考え忘れていることがある。

もうひとつの解決策は、より多くの業務をベンダーに移し、TinyPilotが社内で抱える仕事自体を減らすことだ。今年、我々は自社でのフルフィルメントをやめ、業務を外部の物流業者（3PL）に移管した。エッジケースへの対応は難しくなったが、以前は自分たちで管理していた仕事のカテゴリーごとごっそりなくなった。

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

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

実際には、3PLベンダーと詰めなければならない細かなワークフローが、まだ尾を引いている。

• オフィスから3PLの倉庫へ移動する在庫をどう追跡するか？
• 3PLが倉庫で在庫を紛失していないことをどう確認するか？
• 3PLが注文と違う商品を発送したとき、どう問題を解決するか？
• 当日発送を希望する顧客にどう対応するか？

いずれも解決可能な問題だが、次々と新しい問題に直面するため、3PLのことを考える時間が多くなっている。

ここで時間を減らすには？

ここは、もっとチームの他のメンバーに委任すべき領域だ。

TinyPilotの現地スタッフにもっと積極的に3PLとの関係を管理してもらうように頼み始めていて、うまくいっている。

以前なら、例えば3PLによる在庫紛失を防ぐ問題について、私が在庫レポートを監査するプロセスを自分で定義していた。今は、自分で細かく決めるのではなく、現地スタッフの一人に任せるようにしている。

タスク3：ソフトウェア開発への貢献

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

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

ここで時間を減らすには？

これは難しい。明らかな解決策は「マイケルはコードを書くのをやめるべき」だからだ。

でも、コードを書くのは好きなんだ…

より現実的な解決策は、自分が引き受けるタスクをもっと慎重に選ぶことだ。自分の開発作業は次のようなものに限定すべきだ。

• より良いドキュメント、改善されたテスト、新しい便利スクリプトなど、開発者体験を向上させる改善
• 社内での過去の経緯やコンテキストを知っている私が対応した方が、他の人に指示を出すより早い変更
• うまくいけばプラスになるが、ダメなら捨てられるような実験的な変更

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

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

ドキュメントのレビュー自体は実時間としては長くかからないが、かなりの集中力を要する。自分で文章を明確に書くこと自体が精神的に消耗するのに、他人の文章を読んで何が足りないか、何が不明瞭かを言葉にするのはさらに難しい。

そのため、ドキュメント関連のタスクで私がボトルネックになることが多い。新しいチュートリアルをレビューする1時間の空きがあっても、有益なフィードバックをするための精神的な余裕がないことがよくある。

ここで時間を減らすには？

最も簡単にできる改善は、ピアレビューにもっと頼ることだ。開発チームでは、ソフトウェアエンジニア同士でコードの90%を私を介さずにレビューしている。文章のスタイルをコードほど一貫させるのは難しいが、ドキュメント編集の80%程度はピアレビューで賄えると思う。

もうひとつ変えるべきは、ドキュメントのタスクを割り当てる際に自分のキャパシティを考慮することだ。以前はサポートエンジニアリングチームのタスクキューにチュートリアルを3本続けて追加していたが、一度にすべてをレビューする余裕が自分になかった。レビューする時間を確保できるように、ドキュメントタスクはもっと間隔を空けて配置すべきだ。

メール中毒からの脱却

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

なぜ良いメール習慣を失ったのか

一度健全なメール習慣が身につけば、それを維持するのはそれほど難しくない。習慣が崩れるきっかけになるのは、何かしらの出来事で正当な理由があってメールを頻繁にチェックせざるを得なくなる時だ。

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

ケース不足のような状況では、執拗にメールをチェックすることに正当な理由がある。もし中国のベンダーが金曜の夜にメールを送ってきて、私がそれを月曜の朝まで放置すれば、相手が返信を見るのは中国の火曜の朝になる。3日間の遅延が生じ、その分だけ現地チームは新しいデバイスを作れない期間が延びる。

問題は、緊急事態が終わった後も、常にメールをチェックする習慣が残ってしまうことだ。そしてメールをチェックして緊急のものが何もないと分かっても、まだドーパミンを求めてSNSをチェックしてしまう。それは何の生産性もない。メールをチェックする30秒の休憩のつもりが、10〜30分ダラダラとネガティブな情報を漁る時間になってしまう。

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

これまで、悪いメール習慣から抜け出す方法は、その日のスケジュールを明確に区切ることだった。

毎朝、その日の仕事を30分ごとのブロックに分割し、それぞれの時間をどう使うか決める。衝動的にメールをチェックしないように、メールを一日中なんとなく気にするのではなく、メールを読み返信するための時間をきちんとスケジュールするのだ。

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

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

これを書いている今は午前10時で、今日はまだメールをチェックするのを我慢している。だが、仕事を滞らせているのではないかという焦燥感がある。

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

チームメンバーがサポートチケットを私にエスカレーションすることで、受信トレイがより時間にシビアなものになっていることに気づきつつある。2人のサポートエンジニアのどちらかが手が空くのを待つ状態ではなく、特定のサポートエンジニアと私の両方が対応可能になるまでチケットが止まってしまうのだ。そうなると、顧客を何日も待たせないために、すぐに返信しなければというプレッシャーを感じてしまう。

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

解決策3：チームにもっとピアレビューを活用してもらう

ドキュメントレビューのところでピアレビューについて触れたが、あらゆる種類の業務でもっとピアレビューを活用する機会を探すべきだ。メンバーが同僚と共にスキルを伸ばせるし、私個人に依存してタスクが止まることも減らせる。

サイドプロジェクト

初めての自宅サーバーラックを作る

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

婚約者からは、オフィスはケーブルがあちこちに散らばっているせいで掃除がしにくく汚れやすいと指摘されていた。私は「え、普通の量じゃない？」と思っていたのだが、改めて見てみると、確かにケーブルがかなり多い…

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

そこで、初めてのサーバーラックを組み立てた。作るのは楽しかったし、確かに全体がすっきりした。すべてを縦に積み重ねたことで床のケーブルが減り、全体がキャスター付きで動かせるので掃除も簡単になった。

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

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

Nixを学ぶ

Nixはこの1年、気になる技術リストの最上位にあったので、最近時間を取って学んでみた。

Nixでの最初の体験についてノートを書いたところ、意外にもHacker NewsやTwitterで大きな注目を集めた。Nixコミュニティの人たちが連絡をくれて、詰まっていた部分を手伝うと申し出てくれている。

この反応に励まされて、よく理解していない技術を試している時に、もっとノートを残していこうと思うようになった。

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

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

サードパーティの認証サービスは一応は機能したが、オープンソースプロジェクトの普及を妨げる要因にもなった。他の開発者が私のアプリをデプロイするには、私と同じ認証サービスを使わなければならなかったからだ。

サードパーティ認証のもうひとつの問題は、エンドツーエンドテストが遅く、信頼性が低く、複雑になることだ。

最新のプロジェクトであるScreenJournalでは、サードパーティのサービスに頼らずに認証を行う方法を探した。まずは利用可能な認証ライブラリを調査することから始めた。私の要件は以下の通りだった。

1. オープンソースであること。
2. Go製であること。Goは現在ウェブアプリで私が選んでいる言語だ。
3. アプリに組み込むライブラリであること。アプリと並走する別サービスではないこと。
4. データストアとしてSQLiteをサポートしていること。

goth（旧gomniauth）は最も人気のある認証ライブラリのようだが、外部のサードパーティサービスに依存するため、要件（3）を満たさない。

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

午後をかけてauthbossでシンプルなウェブアプリを実装しようとしたが、基本的な部分すら動かせなかった。authbossについて知れば知るほど、自分の求めているものとは違うと感じるようになった。authbossは、認証だけでなくページのレンダリングやURLのルーティングまで担うことを想定しているようで、それは認証ライブラリに求める範囲を超えている。

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

今のところできるのは、ユーザーのパスワードが正しいかどうかをチェックすることだけだ。まだ再利用可能とは言えない。というのも、クライアント側でパスワードハッシュを作成しなければならないからで、本来はそこを認証ライブラリが担うべきだと思っているからだ。

再利用可能な認証ライブラリの開発は面白い挑戦だ。普段使わないGoの機能を使わざるを得なくなるし、ライブラリが物事をどれだけシンプルにするかと、異なる認証方式に対してどれだけ柔軟であるべきかというトレードオフを考えることで、アーキテクチャのスキルも試される。

まとめ

何ができたか

• 委託製造業者とともに、TinyPilot Voyager 2aデバイスの初の生産バッチに着手した。
• 初めての自宅サーバーラックを組み立てた。
• NixとNixOSの基礎を学んだ。

学んだこと

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

来月の目標

• 販売収益で$98,000を達成する。
• TinyPilotの委託製造業者への移行を予定通りに進める。
• メールに費やす時間を40%未満に抑える。