一行サマリー

リリースのクリティカルパスから自分を外す

ハイライト

• 私が直接どのリリース作業も担当しない、史上初の TinyPilot リリースを完了しました。
• リリースを委譲して公開したことで、リリースプロセスの中にあった多くの未文書化のステップや、設計が甘かったステップが明らかになりました。
• Zig でバイトコードインタプリタを書く作業を、引き続き楽しんでいます。

目標の達成度

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

TinyPilot Pro 2.6.3 を公開する

• 結果: リリースを公開できました。
• 評価: A

私に属人化していたリリース手順を洗い出すことが目的だったので、今回は私が直接どのリリース手順も担当しない初めてのリリースでした。チームは共有されたドキュメントに基づいてすべてのステップを実行し、変更履歴やリリース告知文の作成なども含めて対応しました。

TinyPilot Pro のリリースプロセスを社内向けに文書化する

• 結果: リリースをカバーするのに十分な文書化はできましたが、まだ改善の余地があります。
• 評価: B+

リリースプロセスを文書化するのは、とても良い取り組みでした。文書化されていないプロセスが明らかになっただけでなく、プロセス自体の弱点も浮き彫りになりました。

リリースプロセスの中には、これまで批判的に見直してこなかった部分が多くありました。いざ文書化しようと腰を据えてみると、不必要に手間がかかったり、ミスを誘発しやすかったり、車輪の再発明になっていたりするステップがいくつも見つかりました。

2023年分の確定申告をする

• 結果: 書類の大部分は集めましたが、まだ申告していません。
• 評価: B

結局 TinyPilot のリリースに気を取られて、まだ申告できていません。とはいえ、今年中には申告した方が政府にも喜ばれるでしょうから、そろそろやらなければと思っています。

TinyPilot の統計

年次レビューが注目を集めたことで訪問者数は大きく伸びましたが、TinyPilot の売上にはあまり影響がなかったようです。売上が17%減少していますが、これは主に1月が例年になく好調だった反動です。通常の売上は月あたり7万5千〜9万5千ドル程度です。

月次の利益の報告方法を改める必要があります。製造を外部委託に切り替えたことで、1ヶ月単位のキャッシュベースの利益の数字がほとんど意味をなさなくなってしまったからです。毎月の利益は、3〜4ヶ月ごとに支払う製造費用のタイミングに大きく左右されます。

とはいえ、直近3ヶ月の移動平均で見た利益は、私が目安としている1万〜2万ドルの範囲に戻ってきています。

実はリリースプロセスは25ステップもあった

当初、TinyPilot のソフトウェアリリースはすべて私の仕事でした。プロダクトが成熟し、プロセスにステップが増えるにつれて、リリースは10〜20時間かかる作業になっていきました。

開始から約18ヶ月が経った頃、最も大変なリリース作業をチームメンバーに委譲しました。それには手動テストの大部分が含まれます。これで私の作業時間は1リリースあたり3〜5時間まで減り、うまく委譲できたと感じていました。

前回の TinyPilot リリースでは、あえてすべてを委譲することに挑戦しました。自分が対応できないときでもリリースを進められるようにしたかったからです。

自分がまだ担当していたタスクについて手順書を書き始めました。文書化するのは数ステップ程度だろうと予想していました。

毎回自分がやっていたことをすべて書き出してみると、リリースごとに25もの異なるタスクがあることに気づきました。

リリース候補のテスト

1. リリース候補ビルドを作成する
2. 変更履歴のドラフトを作成する
3. セキュリティアドバイザリのドラフトを作成する（該当する場合）
4. リリース告知文のドラフトを作成する
5. 機能変更をカバーするようテスト計画を更新する
6. Voyager デバイスでリリース候補をテストする
7. リリース済みビルドからリリース候補へのアップデートをテストする
8. DIY デバイスでリリース候補をテストする
9. 実機に対して自動 E2E テストを実行する
10. テスト結果をレビューする
11. リリースを公開するかどうかを決定する

リリースの公開

1. セキュリティアドバイザリを公開する（該当する場合）
2. 変更履歴を公開する
3. TinyPilot Pro の本番リリースを公開する
4. 最新バージョンへのアップデートが正常に動作することを検証する
5. TinyPilot チームにリリースを告知する
6. 変更履歴にイメージハッシュを追加する
7. 少なくとも48時間、バグ報告を監視する

リリースの告知

1. TinyPilot Community 版を公開する
2. リリース告知のブログ記事を公開する
3. EU の販売代理店にリリースを共有する
4. 製造委託先にリリースを共有する
5. 社内プレイブック内のリンクを更新する
6. 一般向けメーリングリストにリリース告知を送信する
7. TinyPilot の Twitter でブログ記事をシェアする

私がこれまでに文書化して委譲していたのは、手動テストが必要な3つのタスクだけでした。残りの22個は、まだ自分でやっていたのです。

リストを眺めると、リリースのためだけに25ステップもあるのは多いと感じます。実際には、いくつかのタスクの中にさらに何十ものサブステップがあるので、25どころではありません。

これだけ手動のステップが多いと、もっと自動化すべきだと感じますが、明らかに自動化すべき対象は見当たりません。たとえば変更履歴にイメージハッシュを追加したり、社内プレイブックのリンクを更新したりといったステップは自動化できますが、年間2時間の手作業を削減するために10時間かけて自動化するような話になってしまいます。

私にとってより重要な学びは、リリースにタスクを追加することには慎重になるべきだということ、そして既存のタスクについても本当に必要かどうかを問い直すべきだということです。

リリース前のバグをどう見つけるか

リリース作業の委譲は、通常の委譲よりも難しいことがわかりました。たとえ自分の意思決定の方法を説明できたとしても、チームメンバーにはその判断を下すためのコンテキストが不足していたからです。

例として、最終テストで遭遇したバグを紹介します。

通常、デバイスをネットワークに接続すると、ルーターが割り当てたローカル IP アドレスがそのまま使われます。一方で、TinyPilot のユーザーの中には、予測可能な固定の IP アドレスをデバイスに割り当てたいという要望を持つ人もいます。今回のリリースでは、TinyPilot のウェブインターフェースで固定 IP アドレスを設定できる機能を追加しました。

リリース前テストでの、この機能の動きは次のとおりでした。

カスタマーサービスチームがテストを実行しましたが、問題なしとの報告でした。テスト計画どおり、ページは新しい IP アドレスで読み込まれていました。サポートエンジニアリングチームもテストの動画を確認し、機能は正しく動作していると報告しました。

私が動画を確認すると、重大な問題に気づきました。ウェブインターフェースが新しいアドレスで読み込まれるまでの数秒間、ユーザーには次のような不安を煽るエラー画面が表示されていたのです。

開発チームに見せると、彼らはがっかりしていました。

私たちは、動的 IP から固定 IP へユーザーを案内する UI に何週間もの開発時間を費やしていました。DNS キャッシュやローカルの TLS 証明書、クロスドメインリクエストに対するブラウザのセキュリティ保護などが絡み、特に難しい対応でした。多くのテストとオーケストレーションのコードを経て、開発チームはようやくうまくいったと思っていましたが、TinyPilot のオフィスではスムーズに動作しなかったのです。

では、私が細かく管理しなくても、こうしたバグをどう見つければよいのでしょうか。異なるチーム間で、機能がどう動くべきかという期待のズレを、どう防げばよいのでしょうか。

そこで、開発チームが新機能をリリースしたり既存の挙動を変更したりした際には、リリース前のテスト映像を開発チーム自身がレビューし、期待どおりに動作しているか確認するようにプロセスを変更することにしました。

どのバグを修正するか、どう決めるか

リリースプロセスの委譲における次の課題は、リリースマネージャーがリリース前テストで見つかったバグをどう扱うかでした。リリースを延期するべきか、それともバグを残したままリリースすべきか。

リリースが私に一極集中していたときは、リリースするか修正するかの判断は比較的簡単でした。チームを横断するコンテキストを持っていたからです。開発チームとも常に連携しているので、バグの修正にどれくらい時間がかかるか、修正によって他を壊すリスクがどれくらいあるかがわかっていました。またプロダクトオーナーでもあるので、バグが顧客に与える影響の大きさも理解していました。バグ修正のコストに対して機能が十分に重要であれば、修正のためにリリースを遅らせる判断をしていました。

リリースマネージャーが私でない場合、バグ修正のためにリリースを遅らせるべきかどうかをどう判断すればよいのでしょうか。

私たちの新しい方針では、リリースマネージャーは決定を下さず、他のチームから必要な情報をすべて集めて、プロダクトオーナーが判断できるようにします。そうすることで、意思決定に必要な情報を集めるプロセスと、実際に決定を下すプロセスを分離できます。これは、私にしかできないリリースタスクを最小限にするという目標にも合致します。

サイドプロジェクト

世界最速の（未完成の）Ethereum 実装を書きました

先月触れたとおり、Zig とインタプリタ、そして Ethereum について楽しく学べる方法を見つけました。Zig で Ethereum のバイトコードインタプリタを書いているのです。

Zig は開発者にパフォーマンスを高度に制御する手段を与えてくれます。そのため、インタプリタに取り組む初期の段階で、自分の実装と公式の Go 実装を比較するベンチマークを継続的インテグレーションに組み込みました。

しばらくは、私の Zig 版は Go 版にわずかに及ばない性能でした。そこからベンチマークスクリプトをリファクタリングしたところ、なぜかパフォーマンスが急落しました。

Ziggit という Zig のフォーラムで助けを求めたところ、ベンチマークスクリプトと Zig のコードの両方にバグがあることが判明しました。その2つの単純なバグを修正すると、私の Zig 版は Go 版を一気に追い抜きました。

私の Zig 版 Ethereum 実装は、現在では公式の Go 実装を30〜40%上回る性能を発揮しています。

公平を期すために言うと、私のバージョンは Ethereum の約3%しか実装していないので、有利な条件ではありますが、それでも楽しいプロジェクトであることに変わりはありません。

まとめ

何を成し遂げたか？

• TinyPilot Pro 2.6.3 を公開しました。
• TinyPilot のリリースプロセスにおける未文書化のステップを洗い出し、その大部分を文書化しました。

学んだこと

• チームをまたがる協働が必要な作業では、タスクの委譲がより難しくなる。
  • 最終的にはプロダクトオーナーが下さなければならない決定もあるが、決定に必要な情報を集めるプロセスと決定自体を分離するように、チームはプロセスを調整できる。

来月の目標

• TinyPilot のリリースドキュメントの不足部分を埋める。
• 2023年分の確定申告を完了する。