一行サマリー

もっと委譲するにはどうすればいいか？

ハイライト

• プロダクトの意思決定やドキュメント作成を、どうすればより上手く委譲できるかを考えました。
• Nixを学んだ経験とZigを学んだ経験を比較しました。

目標の達成度

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

TinyPilotのライセンス確認機能の設計を完了する

• 結果: 設計ドキュメントが完成し、レビューも完了しました。
• 評価: A

TinyPilotの顧客が最新バージョンへアップデートする前に、有効なライセンスを保持しているかを確認する方法について、計画が固まりました。サードパーティのライセンス管理ソリューション（現在はKeygenが有力候補です）が決まれば細部を詰める必要がありますが、主要な部分は固まっています。

製造ロットごとの抜き取り検査プロセスを整備する

• 結果: 着手できませんでした。
• 評価: F

これは一部、時間的な制約によるものです。ベンダー側で予期せぬ問題が幾つか発生し、その対応に時間を取られました。

もう一つの理由は、この作業が気が進まないものだったため、つい先延ばしにしてしまったことです。製造上のミスを早期に発見するために重要なことではありますが、3PL（サードパーティ・ロジスティクス）へ特別な依頼をする必要があり、彼らはこれまであまり協力的ではありませんでした。

TinyPilotの年末の税務処理をこなす

• 結果: すべてのベンダーからW-9フォームを回収しました。
• 評価: A-

これで完了し、誰からW-9フォームをもらう必要があるのかについても理解が深まりました。今後は直前になって慌てずに済みそうです。

TinyPilotの数値

売上は11月からやや減少していますが、これは毎年見られる季節的な傾向です。通常のレンジは月7万5千〜9万ドル程度なので、今回はその下限に近いものの、心配するほどではありません。

利益が恐ろしい数字に見えるのは、サードパーティの受託製造業者へ移行したことで製造への先行投資が大きく増えているにもかかわらず、私がまだ現金主義で帳簿を付けているためです。第4四半期にTinyPilotは材料費と製造費に15万ドルを費やしましたが、これは四半期として過去最高の支出です。売上原価（COGS）ベースで見ると、12月のTinyPilotの利益は実際には9千ドル（つまりプラス9千ドル）でした。

とはいえ、外部の製造・フルフィルメント業者への移行対応に追われるあまり、マーケティングを疎かにしてしまっていました。ここ数ヶ月、TinyPilotはマーケティングにあまり投資せずとも成長してきましたが、それがいつまでも続くとは限りません。そのため、1月の目標の一つとして、新たなマーケティングチャネルを開拓することを掲げています。

難しいプロダクトの意思決定は委譲できるか？

最近、自分の時間がどこに使われているかを考えると、その多くがいわゆる「難しいプロダクトの意思決定」に費やされていることに気づきます。TinyPilotにどの機能が必要か、それにどれだけ投資すべきか、そして予期せぬ事態が起きたときにリソースの優先順位をどう組み替えるかを考える時間です。

難しいプロダクトの意思決定をTinyPilotのチームに委譲しようとしてきましたが、あまり進展がありません。

もし、機能のコストとそれがユーザーをどれだけ満足させるかを示すチャートを作り、チームに「この線より上に留まるように」と指示できれば理想的です。

しかし、新機能にどれだけ投資すべきかを決める際には、他にも多くの要素があります。例えば：

• その機能は、必要としないユーザーにとって混乱や煩雑さを招かないか？
• その機能を長期的に維持する負担はどれくらいか？
• その機能はサポートチームにどのような影響を与えるか？

たとえこのような多次元のチャートを作れたとしても、すべての変数について意味のある見積もりを出すのは困難です。ある人は5%のユーザーがその機能の恩恵を受けると考えるかもしれませんが、別の同じくらい理にかなったチームメイトは15%と見積もるかもしれません。この一つの変数だけで、機能の価値は3倍も変わります。すべての変数を組み合わせれば、二人の投資対効果の見積もりが100倍も食い違うこともあり得ます。

気取って聞こえるかもしれませんが、最終的な判断を下す人には「プロダクトビジョン」が求められます。顧客、開発チーム、そしてサポートチームと繋がっている必要があるのです。そしてTinyPilotにおいて、その立場にいるのは私だけです。

一つの解決策として、ハイレベルな戦略を受け取って計画に落とし込み、チームと一緒に実行する役割のプロダクトマネージャーを雇うことが考えられます。しかし、これはあまり現実的ではありません。管理すべき人が一人増え、チームとのコミュニケーションの輪にもう一人加わることになるからです。現在6人をマネジメントしていますが、これが私が効果的に管理できる上限だと感じています。

別の可能性として、既存のチームメンバーにプロダクトマネージャーの役割を担ってもらうことも考えられますが、これも現実的ではないと感じています。朝の郵便物を取りに行くような単なる雑務とはわけが違います。ほぼすべての顧客やチームとのやり取りに関わる必要があるため、週にさらに10〜20時間の業務が増えることになります。仮にそうしたとしても、的確なプロダクト判断ができるレベルまで誰かを育成できるか自信がありません。

今のところは、開発チームにハイレベルな戦略と、バグ修正や機能開発に使える工数の大まかな予算を示し続けるつもりです。これまでのところはうまくいっていますが、彼らがより自律的に意思決定できるようにする方法を、引き続き模索しています。

ドキュメント作成の委譲をもっと上手くできるか？

私はドキュメントにはこだわりが強い方です。改善できる点が見つかれば、できる限り良くするまでは公開したくありません。

今でもTinyPilotのブログ記事、FAQ、チュートリアルはすべて私がレビューしており、公開のボトルネックになることがよくあります。ファウンダーとしての時間のかなりの部分が、ドキュメントのレビューに費やされていると感じています。

単純な作業時間が長いというわけではなく、「深く考える」ための気力を多く消耗しているのです。私は1日に1時間程度しか文章を書くことができません。他人の文章をレビューするのは、自分で書くよりもさらに消耗します。なぜなら、アイデアをどう表現するかを考えるだけでなく、なぜそのように表現するのかまで考えなければならないからです。

かつてコードレビューでは完璧主義に悩まされ、些細なことは見逃すことを学ばなければなりませんでした。コードが可能な限り美しくなくても、ユーザー体験には影響しないので問題ありません。しかし、ドキュメントは誰の目にも触れますし、Aランクの文章とBランクの文章には明確な違いがあります。

では、どうすれば自分をプロセスの依存先にすることなく、文章の質を高く保てるのでしょうか？

フリーランスのテクニカルライターに依頼することも考えましたが、そうすると執筆プロセスが複雑になってしまいます。また、専任のライターがいると、かえってメンバーが文章力を磨こうとしなくなるのではないかと心配しています。「適当に書いても、テクニカルライターが直してくれるだろう」と思われてしまうかもしれません。

文章をレビューする際に私が直面する課題の一つは、典型的なTinyPilotの顧客像について頭の中にモデルがあるものの、それを他人に正確に言語化して伝える方法がわからないことです。そして、そのモデルを理解してもらえたとしても、TinyPilotの顧客像に合った書き方をしてもらうのは難しいのです。

これを改善する一つの方法は、過去のレビューを振り返ってパターンを探すことかもしれません。パターンが見つかれば、「レビューに出す前に、スクリーンショットを追加すると分かりやすくなる箇所はないか、新しい用語を使う前にきちんと説明しているか、といった点をチェックしてください」と伝えられます。

チームではGrammarlyを契約していますが、ワークフローにうまく馴染んでいません。最初のドラフトでは使うかもしれませんが、編集のたびに記事全体をコピー＆ペーストしてGrammarlyにかけ直したいと思う人は誰もいません。Valeという開発者向けのツールを調べましたが、Grammarlyに比べると原始的に感じられます。ノイズの少ないチェックだけを設定して使えるかもしれないので、試してみようと思います。

Nixを学ぶこととZigを学ぶこと

TinyPilotの製造とフルフィルメントを外部ベンダーに移管した結果の一つとして、新しい技術を学ぶための時間と心の余裕が生まれました。ここ2年間、遠くから注目していた技術がNixとZigの2つで、2023年末にようやく両方を試すことができました。

両方とも初心者レベルまで学んでみて、Nixを学んだ経験とZigを学んだ経験を比較するのは興味深いことです。

Zigは理屈で理解する — Nixはコピペで覚える

Zigについてよく聞く不満の一つに、ドキュメントが貧弱だというものがあります。私自身もドキュメントはかなり簡潔で、開発者というよりコンパイラ設計者の視点で書かれていると感じましたが、それでも議論を漁ったり自分で試したりしながら、Zigについて正確なメンタルモデルを築くことができました。

Nixを使い始めて半年が経ちますが、いまだにNixのメンタルモデルはお粗末なままです。複数の解説を読んできましたが、概念がどうもしっくりきません。Nixファイルを作るときは、既存のサンプルをコピーして自分のやりたいことに合わせて調整することしかできません。ファイルの大部分はただのボイラープレートで、なぜそうなっているのか理解できていません。

Zigでエラーに遭遇したときは、たいてい筋道立てて考えることでコンパイラが何を伝えようとしているのか理解できます。Nixでエラーに遭遇したときは、完全に手も足も出ない気持ちになります。

大きな違いの一つは、私がC系言語での開発経験は豊富である一方、純粋関数型言語の経験がまったくないことだと思います。ZigはCやC++の開発者をターゲットにしているので、10年間それらの言語で仕事をしてきた私には概念がすんなり理解できます。

NixはHaskellをはじめとする関数型言語から強い影響を受けているように見えます。Haskell開発者にとってはNixの方が直感的に感じられ、逆にポインタやメモリアロケータといった関数型言語ではあまり前面に出てこない概念を重視するZigに戸惑うかもしれません。

Zigの開発体験は「狭く深く」、Nixは「広く浅く」

Zigにはパッケージ管理やコードカバレッジのためのツールがありません。Zigで私ががっかりした点の一つは、マイクロコントローラのサポートがほとんど存在しないように見えることです。

しかし、Zigが「できる」と主張することについては、きちんとやってのけます。gccのドロップイン置換になれるという主張には懐疑的でしたが、gccをzigに置き換えるたびに、すべてが問題なく動きました。Zigは.cファイルをZigファイルにそのままインポートできると謳っていますが、実際にできます。

一方のNixは、Node.jsプロジェクトのビルドのような単純なことから、OS全体のビルドと管理のような壮大なことまで、はるかに幅広いことをやろうとしている印象です。

プロジェクトがNixの想定通りにぴたりと合致していれば、すべてが素晴らしくうまくいきます。しかし、自分のセットアップがNixの想定と少しでもずれると、途端に壁に突き当たります。例えば、任意のPythonプロジェクトをNixで実行する方法がいまだに分かりません。

Nixで最も驚いた欠落の一つは、インストールしたいパッケージのバージョンを指定する公式な方法がないことです。8年間議論が続いていますが、解決策はおろか、これを修正するのかしないのかという公式な見解すらないようです。

Nixのリーダーシップは分散型、ZigにはBDFLがいる

Andrew KellyはZigの生みの親です。他にも何人かがプロジェクトに加わっていますが、Andrewは今も実質的に終身のbenevolent dictator（慈悲深き独裁者、BDFL）です。Zigのドキュメントやヘルプを探していると、GitHubのissueやフォーラムでの議論でAndrew本人やプロジェクトの公式メンバーが回答しているのをよく見かけました。

Nixのことを初めて聞いたとき、私はEelco DolstraがNixのBDFLなのだろうと思っていました。少なくとも表向きには、そうではないようです。

NixはEelcoの発案によるもので、彼の2006年の博士論文から生まれました。EelcoはNix Foundationのプレジデントですが、同時にNixを推進するサードパーティのコンサルティング企業であるDeterminate Systemsでも働いています。しかしDeterminate Systemsはあくまでサードパーティであり、Nixの中核ではありません。彼らがリリースするものは、ときにNix内部のチームの成果物と衝突し、物議を醸すこともあります。

Zigが中央集権的に計画されているように感じられるのに対し、Nixは舵取り役がいないように感じます。何か分からないことがあって検索すると、GitHubやNix Discourseフォーラムでの延々と続く議論にたどり着くことがよくあります。会話はいつも、偶然発見した異星のテクノロジーについて語り合っているかのようです。Nixのコアチームの誰かが意見を述べているのを見たことがなく、そもそもコアチームが存在するのかさえ分かりません。

古い解決策はNixでもZigでも大抵そのままでは動かない

Zigはまだ安定版の1.0をリリースしていないため、コンパイラのアップデートで破壊的変更が入るのが常です。Zig 0.8.0では有効だったコードが、Zig 0.11.0では有効でなくなることもあります。私の経験では、Zigのツールはコードを自動で修正してくれることが多いですが、100%正確というわけではありません。

Nixでも同様に、古いサンプルで問題に直面しました。Nixはflakesという、かなり新しくまだ正式ではない機能をめぐって論争の渦中にあります。しかし最近のガイドはすべてflakesを使い、古い議論はすべて非flakes前提なので、flakes以前の解決策をflakes以降の環境に適用するのに苦労します。

Zigはチーム全体の合意が必要だが、Nixは部分的導入が容易

Nixの良い点の一つは、自己完結していることです。プロジェクトにflake.nixを一つ置くだけで、他には何も変えず、チームメイトに何も求めることなく、依存関係を自動的に管理できます。

たとえチームでNixを使っているのが自分一人だけでも、flake.nixは他の誰にもコストをかけず、誰にも新しいツールを使わせることなく、私にとって大きな価値を提供してくれます。プロジェクトに.vscodeディレクトリを追加するようなものです。VS Codeを使う人には役立ち、他の人にとっては特に邪魔になりません。

一方のZigは、導入に覚悟とチーム全員の合意が必要です。CやC++のプロジェクトがあり、Zigに切り替えたいと思っても、自分の使い勝手の良いツールを楽しみつつ、チームメイトが追いつくのを待つ、というわけにはいきません。プロジェクトにZigのコードを一つでも導入した途端、全員がC/C++コンパイラではなくZigコンパイラでビルドしなければならなくなります。

これはZigの欠点というわけではありませんが、Zigに触れるのは、自分でコードをいじったりZigのプロジェクトを眺めたりしてZigの世界を訪れたときに限られるのに対し、Nixは今やどこへ行くにも一緒にもっていける存在になった、ということを意味します。

まとめ

今月やり遂げたこと

• TinyPilotのライセンス確認機能の設計を完了しました。
• 新たに3本のブログノートを公開しました。
  • 「Using Zig to Unit Test a C Application」は、Hacker News、Lobsters、Ziggitで話題になりました。
• 年末の税務処理を完了しました。

学んだこと

• ドキュメントレビューの定期的なメタレビューが有効かもしれません。
  • 現在は記事ごとに改善点を議論しているだけですが、多くの記事にまたがって繰り返し現れるパターンをレビューすることで、チームの文章力がより向上するかもしれません。
• Valeはレビュー前の軽微な問題の発見に役立つかもしれません。

来月の目標

• 年次レトロスペクティブを公開する。
• 5人のブロガーにTinyPilotとのコラボレーションについて連絡する。
• 2023年分の税務申告に向けて記録を準備する。

お願い

• 少量（月100〜200件）の出荷に対応してくれる良い3PLをご存知でしたら、ぜひ教えてください。良い3PLを探しています。