一言まとめ

microSDへの書き込みが驚くほど難しいという話です。

ハイライト

• TinyPilotは過去2番目に高い月次売上を記録しました。
• TinyPilotは製造の外部委託先への移管をほぼ完了しました。
• 私はメカニカルキーボードの沼に足を踏み入れてしまったかもしれません。

目標の振り返り

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

製造を外部委託先へできるだけ早く移管する

• 結果: 最初のロットで軽微な問題がありましたが、移管はまもなく完了する見込みです。
• 評価: B

外部委託先から最初の量産ロットが届き、11月にお客様へ発送しています。

このロットが完璧で、移管完了を宣言できることを期待していました。しかし残念ながら、組立工程で軽微なミスがあり、社内で修正する必要があったため、製造元から倉庫、そしてお客様へとスムーズに流れる体制はまだ整っていません。

TinyPilotのソフトウェアリリース工程の手作業を減らす

• 結果: これまで私に紐づいていた手作業を1つなくすことができました。
• 評価: A

私は常にTinyPilotのソフトウェアリリース工程を自動化・簡素化する方法を探しています。とくに、日常的なワークフローのクリティカルパスから自分自身を外すことを重視しています。10月は、TinyPilot Proの新バージョンが公開された際のWebサイト更新を自動化することで、その両方を前進させることができました。

以前は、私がリリースを作成したあと、手作業でWebサイトのダウンロードURLを新しいものに差し替えていました。現在はWebサイトがアップデート配信サービスと同期しているため、新しいリリースを自動で検知してくれます。

TinyPilot Proのライセンス管理を強化する計画を立てる

• 結果: 計画づくりが進みませんでした。
• 評価: F

10月は開発チームの稼働が想定より少なかったため、ライセンス管理強化の計画づくりまで手が回りませんでした。

TinyPilotの数値

これはTinyPilot史上2番目に好調な月でしたが、正直なぜなのかわかりません。アナリティクスを見ても特に目立った動きはなく、新しいレビューや言及も把握していません。2022年10月も好調だったので、単に季節要因なのかもしれません。

製造移管に注力していてマーケティングに投資できていなかったので、数字は少し落ちるだろうと予想していました。勢いだけで乗り切れたのはうれしいことですが、2023年残りの数ヶ月は成長への投資を再び増やし始めています。

新しい製造委託先でmicroSDを正しく用意するまで

消えたディスク

TinyPilotのデバイスはmicroSDという小さなディスクにデータを保存しています。製造委託先がTinyPilotデバイスの最初のサンプルを発送する数日前、彼らは私が送ったリファレンス機にmicroSDが刺さっていることに気づきました。microSDは必要ですか、と聞かれました。

調べてみると、製造委託先の部品表（BOM）にmicroSDが含まれていなかったのです。私もそれに気づいていませんでした。

幸い、microSDの調達と書き込みは迅速かつシンプルにできる工程です。すでにTinyPilotのロゴ入りmicroSDを作ってくれている業者があったので、製造委託先にその業者を紹介し、TinyPilotのソフトウェアをmicroSDに書き込む方法を説明しました。

製造委託先とは、microSDのために最初のサンプル出荷を遅らせるまでもないということで合意しました。デバイス本体はmicroSDなしで先に発送し、microSDは1〜2週間後に送ってもらうことにしました。

ところが最初のサンプルにはあまりにも多くの問題があり、すっかりmicroSDのことを忘れてしまい、結局製造委託先からmicroSDが送られてくることはありませんでした。

microSDが正しく書き込まれているかの確認

10月中旬、製造委託先から、最初のサンプルで指摘した問題はすべて修正したので、お客様へそのまま発送できる完成品として小規模な量産ロットを送ると連絡がありました。

最初のロットは、社内基準を満たしているか追加の品質チェックを行う予定でした。その検証項目の一つが、製造委託先がmicroSDを正しく書き込めているかの確認でした。

ロット到着の2日前になって、ふと気づきました――どうやってmicroSDが正しく書き込まれているかを確認すればいいのだろう、と。ディスク上の1バイトたりとも間違いがないことを確かめたいと思いました。

microSDの検証は簡単ではありませんでした。そこでTinyPilotのサポートエンジニアリングチームに、製造委託先のmicroSDと私たちの「ゴールド」イメージを比較し、差分があれば報告する簡単なシェルスクリプトを作ってもらいました。テストに間に合うよう、ぎりぎりで用意してくれました。

最初のロットが届いたとき、microSDを1枚読み込ませて整合性チェックスクリプトを実行すると、すべて一致すると表示されました。素晴らしいことです！

機能テストもすべて正常でした。とてもうれしくなりました。これで製造委託先がこのロットを完璧に仕上げてくれたことになり、外部委託への移行完了を宣言できると思いました。

最後のTinyPilotのシャットダウン準備をしているとき、気づいたことがありました。映像設定が出荷時のデフォルトではなかったのです。誰かがすでにこのデバイスを使った形跡がありました。

テストしていたデバイスの電源を切り、microSDチェックスクリプトを再実行しました。テスト中に設定をかなり変えたので、今度こそ差分が検出されるはずでした。しかしスクリプトは、私のmicroSDがゴールドイメージと完全に一致していると報告しました。

まずい、と思いました。

サポートエンジニアの環境では正しく動いていたスクリプトが、私のテスト環境では常に偽陽性を返していたのです。

microSDをさらに詳しく調べると、製造委託先が私たちの指示を誤解していたことがわかりました。私たちは、テスト用のmicroSDで品質チェックを行ったあと、出荷前に新しいものに交換してほしいとお願いしていました。しかし製造委託先はその交換をしておらず、テストで使用したままのmicroSDがお客様向けの製品に入ったまま出荷されていたのです。

幸い、このミスは社内で比較的簡単に対処できました。現地チームが箱を一つひとつ開け、microSDをクリーンな状態に再書き込みし、再梱包して倉庫へ送りました。

もちろん、長期的には社内でmicroSDをすべて再書き込みするのは避けたいところです。問題を報告すると、製造委託先はたしかに指示を誤解していたことを認め、お客様に届くすべてのmicroSDが新しいイメージで書き込まれるよう工程を修正したと連絡してきました。次のロットでも改めて検証しますが、この問題も収束に向かいつつあると期待しています。

どうすればmicroSDの問題を防げたか

microSDの問題は、それ以前に起きた複数のミスが積み重なった結果でした。

• 製造委託先の部品表にmicroSDが抜けていることに気づきませんでした。
• 製造委託先がサンプルのmicroSDを送ってこず、私もフォローを忘れてしまいました。
• microSDの検証方法を工程の終盤まで考えていませんでした。
• microSDチェック用スクリプトに必要な厳密さを見誤りました。

BOMを確認したとき、私は記憶を頼りにざっと目を通しただけで、すべて揃っていると思い込んでいました。もっと厳密にやるなら、製品を1台分解して部品を棚卸しし、製造委託先のBOMと1対1で突き合わせるべきでした。

これは製造委託先のコミット漏れをめぐって2度目の問題で、まだ良い解決策が見つかっていません。全体としてはほとんどのタスクはきちんと対応してくれるのですが、フォローしないと約10%のタスクは忘れられてしまいます。何かを待っているときは指摘するようにしていますが、そうするとmicroSDや取扱説明書のような、一見重要に見えない部品が抜け落ちやすくなります。そういった部品こそ、出荷を止めてしまう要因になるのですが。

microSDチェックスクリプトへの投資も不足していました。当時は一度きりのスクリプトという感覚で、お客様向けのコードほど時間と注意をかける必要はないと思っていました。しかし偽陽性が出たとき、このスクリプトが品質チェックで期待どおりに動くことがいかに重要で、ミスがいかに高くつくかを痛感しました。そこで現在は、本番コードを作るのと同じ標準プロセスに則ってスクリプトを書き直しています。

製造委託先の工程を端から端まで検証する方法については、まだ答えが出ていません。内製していた頃は、Notionに手順書を用意し、チーム全員がそれに従っていました。しかし製造委託先とはNotionのワークスペースを共有できません。作業員の全員が英語を読めるわけではないからです。そのため私たちは英語の手順書を渡し、製造委託先がそれをベトナム語に翻訳し、作業員はベトナム語版を読んで作業します。ベトナム語の手順が英語の手順と一致しているかを私が検証することはできません。

品質チェック工程の動画を送ってもらうのは役に立ちました。製造委託先がどのように品質チェックを行っているかが、言語に依存せずに見て取れるからです。しかし、工程全体を端から端まで動画で捉えるのは困難です。品質チェックの動画だけでは、テストに使ったmicroSDがそのまま最終製品に残ってしまうことがわかりにくく、どう防げばよいのかまだ明確ではありません。

製造委託先からはベトナムの工場見学に招待されましたが、今年はもう出張で疲れ切っていたので断りました。振り返ってみると、行っていれば高くつくミスを防げたかもしれません。現地チームの誰かに行ってもらうという手もあったと思います。

カスタマーサクセスの仕組みづくり

年初の時点では、現地のTinyPilotチームの業務は約20%がカスタマーサポート、80%が組み立てと発送でした。このバランスは今年大きく変わり、製造と発送を外部に移管したことで、2024年初頭には組み立てと発送は現地チームの業務の0%になる見込みです。

一方で、カスタマーサポートは今も週の稼働時間の50%に満たないため、空いた時間をどう使うかが課題になっています。

この問題については年初からチームで話し合ってきました。最も自然な移行先は、サポート依頼に反応的に対応するのではなく、既存のお客様にこちらから主体的に働きかけることだと考えています。こうした役割を「カスタマーサクセス」と呼ぶ企業もあります。

正直に言うと、私自身はめったにお客様にこちらから連絡をしません。重要だが緊急でないタスクとして、常におろそかにしてしまう領域だからです。しかし現地スタッフにやり方を教えられれば、私の時間的制約に縛られずに進められます。

現在、次のようなカスタマーサクセスのプロセスを試験運用しています。

1. カスタマーサポートチームが、TinyPilotに多く支払ってくれているお客様（とくにリピーター）をリサーチします。
2. カスタマーサポートチームが、お客様の会社や注文内容に触れた人間味のあるメールを送り（自動化されたものに見えないようにします）、機能要望や困りごとについて話すための通話を打診します。
3. お客様とミーティングを行い、TinyPilotの使われ方について学びます。
4. お客様からのフィードバックを機能ロードマップに反映します。

私がお客様として他社からアプローチを受けるとき、それは往々にしてあからさまに自分本位です。「お客様のあらゆるニーズを理解するお手伝いをしたい」などと言いながら、実際はもっと買わせようとしているだけだったりします。

私はTinyPilotからの働きかけを、寄生的・貪欲なものではなく、協働的なものにしたいと考えています。お客様が求めている機能に合わせてロードマップを調整するのに役立つはずですし、そうでなければ気づけなかったTinyPilotの新たな可能性を発見するきっかけにもなるでしょう。

サイドプロジェクト

Ansibleよ、さようなら、Nixよ、こんにちは

ここ数年、開発環境の管理にAnsibleを使ってきましたが、多くの悩みの種を抱え、負担に感じるようになってきました。ここ数ヶ月、AnsibleをNixに置き換えようと試みてきましたが、ようやく完了したと思います。

以前Nix Home Managerを見かけたときは、意味がわかりませんでした。ホームディレクトリのファイルを管理する？ NixOSですでにシステム全体を管理しているのに？

私が見落としていた重要な点は次のとおりです。

• Home ManagerはNixOSだけでなく、あらゆるLinuxやMacで動作します。
• テキストファイルの管理に最適化されているため、テキストファイルの扱いに関してはNixOSよりもインターフェースが優れています。

今ではAnsibleで開発用マシンを管理する代わりに、Home Managerとプロジェクト固有のNix flakesですべてを管理しています。1ヶ月以上Ansibleのプレイブックを実行していません。

顕著な変化の一つは、よく使うコマンドのbashエイリアスをより頻繁に定義・活用するようになったことです。以前エイリアスを追加する手順は、Ansibleのプレイブックに追記し、エイリアスを使いたいすべてのマシンでプレイブックを再実行するというものでした。しかしAnsibleのプレイブック実行は遅く失敗しやすいため、結局エイリアスを知っているマシンと知らないマシンが混在してしまいます。手間がかかりすぎて、新しいエイリアスを追加して日常的に使いこなす気になれませんでした。

Nixでは、Home Managerがすべてのbashエイリアスを管理してくれるようになりました。シェルエイリアスを追加したいときは、~/.config/home-manager/home.nixを編集してからhome-manger switchを実行して変更を反映します（実際にはbashエイリアスでhsに短縮しています）。全工程は1分もかからず、Ansibleのように外部要因で失敗することもありません。

NixOSへの完全移行を試みていましたが、普段使っているDebianの開発環境とNixOSの違いが大きすぎてなかなかうまくいきませんでした。Home Managerは、Nixに完全に乗り換えるのと使い慣れたDebianのワークフローを手放さないことの、ちょうど良い中間地点です。

すっかりメカニカルキーボード沼の住人になりました

Lex Fridman氏がPythonの生みの親であるGuido van Rossum氏にインタビューした中で、Lex氏が長々と語っているのが、自身のKinesis Advantage 2キーボードへの愛です。

Kinesisはメカニカルキーボードの人気メーカーです。キーがくぼんだウェル（窪み）に配置され、キーボードの左右が数インチ離れているのが特徴です。

Lex氏はKinesisキーボードを心から気に入っており、ノートPCのビルトインキーボードを使うよりも巨大なキーボードを持ち運ぶ方を選び、飛行機にも持参するほどです。

私は14歳の頃から、Microsoftのエルゴノミクスキーボードを何らかの形で使い続けてきました。気に入ってはいますが、Lex氏がKinesisについて語るような熱量はありません。そこでここ数ヶ月、メカニカルキーボードが気になっていました。

メカニカルキーボードを使う知り合いは数人いますが、これまでその魅力がわかりませんでした。好きでこだわるのはいいけれど、キーボードから得られる楽しみの上限はたかが知れているのに、なぜそこまでするのだろうと思っていました。

しかし好奇心が湧き、ハイエンドキーボードについて調べ始めました。起きている時間のほとんどをキーボードの前で過ごしているのだから、使い心地を最適化することに投資するべきなのかもしれないと思いました。

Kinesis、Ergodox、ZSAなどの選択肢を検討した結果、最終的にKinesis Advantage 360を選びました。

このキーボードを使った初日は本当に苦労しました。タイプ速度は普段の5%ほどでした。片付けなければならない書類がたくさんあったので、翌朝までキーボードを脇に置きました。

2日目は少し楽になりましたが、それでも苦戦しました。使い続けると、英語の文章を打つときはこのキーボードの方が速くなりましたが、プログラミングでは遅くなりました。[や{、=といった記号がこのキーボードではまだ体に馴染んでいないのです。打ちやすくするためにキーのリマップもしましたが、筋肉の記憶を作るのにまだ時間がかかっています。

Kinesisに慣れても通常のキーボードにすぐ戻れるというレビューを他の人から読んだことがありますが、今のところ私には当てはまりません。Surface Pro 6の窮屈なラップトップキーボードに切り替えると、タイプミスを連発します。いずれ両方で快適に打てるようになるかもしれません。

60日間の返品期間がありますが、現時点ではKinesisを使い続けるつもりです。

まとめ

今月できたこと

• 外部委託先が製造したTinyPilot Voyager 2aの最初のロットを出荷しました。
• TinyPilotのリリース工程から手作業をなくしました。
• メカニカルキーボードに切り替えました。

学んだこと

• 製造委託先のコミットをより積極的に追跡します。
  • 以前も同じミスをしており、正しく対処できていませんでした。
  • microSDの件は、製造委託先が何かをすると約束し、私が任せきりにし、双方が忘れて後で問題になるというパターンの繰り返しです。
  • コミット内容を記録し、忘れられていないか毎週状況を確認する必要があります。
• BOMは部品ごとに突き合わせます。
  • 数ヶ月前に製造委託先から部品表が送られてきたとき、目視で期待どおりかだけを確認し、microSDが抜けているのを見逃しました。
  • 今後はBOMの合意プロセスで、既存製品を分解してすべての部品を棚卸しし、製造委託先のBOMと突き合わせます。

来月の目標

• 製造を外部委託先へできるだけ早く移管します。
• 5件のカスタマーアウトリーチ通話を実施します。
• TinyPilotオフィスから古い在庫や予備部品をすべて片付けます。