一行サマリー

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

ハイライト

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

目標の達成度

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

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

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

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

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

TinyPilotのソフトウェアリリースプロセスの手作業を減らす

• 結果: 私に紐付いていた手作業のリリースタスクをなくしました。
• 評価: A

常にTinyPilotのソフトウェアリリースプロセスを自動化・簡素化する方法を探しています。特に、日常的なワークフローのクリティカルパスから自分自身を外すことに強い関心があります。10月は、TinyPilot Proの新バージョンが利用可能になった際にTinyPilotのウェブサイトを更新する方法を自動化することで、両方で前進できました。

以前は私がリリースを作成した後、手作業でウェブサイトを更新して新しいダウンロードURLを指すようにしていました。現在はウェブサイトがアップデートサービスと同期されているため、新しいリリースを自動的に検出します。

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が正しく書き込まれているかの検証

10月中旬までに、製造委託先は最初のサンプルで指摘した問題をすべて修正したと言ってきました。そして、お客様へそのまま発送できる完成品であるはずの小ロットの生産バッチを送る予定でした。

それでも最初のバッチについては、社内基準を満たしているか追加のQAを行う予定でした。その検証の一部が、製造委託先がmicroSDを正しく書き込んだかどうかの確認でした。

バッチが到着する2日前になってようやく、「製造委託先がmicroSDを正しく書き込んだかどうかを、どうやって確認するんだ？」と考えました。ディスク上の1バイトたりとも間違いがないか確認したかったのです。

microSDの検証は一筋縄ではいかなかったので、TinyPilotのサポートエンジニアリングチームに、製造委託先のmicroSDと私たちの「ゴールデン」ディスクイメージを比較して差分を報告する簡単なシェルスクリプトの作成を依頼しました。彼らは私のテストに間に合うよう、ぎりぎりでスクリプトを作ってくれました。

最初のバッチが到着したとき、microSDを挿して整合性チェックスクリプトを実行したところ、すべて一致していると報告されました。よし！

機能テストも実行しましたが、すべて期待通りに動作しました。とても嬉しくなりました。これは製造委託先がこのバッチを完璧に仕上げたということで、外部委託先への移行が成功したと宣言できると思ったのです。

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

テストしていたデバイスをシャットダウンし、microSDチェックスクリプトを再実行しました。今回はテスト中に設定を大幅に変更したので、当然変更が検出されるはずでした。ところがスクリプトは、私のmicroSDがゴールデンイメージと完全に一致していると報告したのです。

おや、まずいことになりました。

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

microSDをさらに詳しく調べた結果、製造委託先が私たちの指示を誤解していたことが明らかになりました。私たちは、テスト用のmicroSDでQAを行い、顧客向けに梱包する前に新品に交換してほしいと伝えたかったのです。製造委託先はその交換をしておらず、使い古しのmicroSDが刺さったままのユニットをお客様に出荷していたのです。

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

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

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

microSDの問題は、それ以前に起きていたいくつかのミスが積み重なった結果でした。

• 製造委託先の部品表からmicroSDが欠落していることに気づきませんでした。
• 製造委託先はサンプルのmicroSDを一度も送ってこず、私もフォローアップを忘れていました。
• microSDをどう検証するかについて、プロセスの終盤まで考えていませんでした。
• microSDチェック用スクリプトにどれだけ厳密さが必要かを過小評価していました。

BOMを確認したとき、私は記憶を頼りに目視で「あるはずのもの」があるかチェックしただけでした。もっと厳密に、既存の製品を分解して構成部品を棚卸しし、製造委託先のBOMと1対1で一致するか確認すべきでした。

これは製造委託先が約束を守らなかったことで問題が起きた2度目のケースですが、まだ良い解決策が見つかっていません。全体として彼らはほとんどのタスクをきちんとこなしてくれますが、私がフォローアップしないと約10%のタスクを忘れてしまいます。何かを待っているときは問題を提起するようにしていますが、そうするとmicroSDや取扱説明書のような、一見重要ではなさそうで、実は出荷を止めてしまうような部品が見落とされがちになります。

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

製造委託先のプロセスをエンド・ツー・エンドで検証する解決策も、まだ見えていません。内製していたときはNotionに手順書があり、チーム全員がそれに従っていました。製造委託先とはNotionのワークスペースを共有できません。作業員全員が英語を読めるわけではないからです。そのため、私たちは英語の手順書を渡し、製造委託先がそれをベトナム語に翻訳し、作業員はベトナム語版を読んでいます。ベトナム語のプロセスが英語のプロセスと一致しているか、私には検証できません。

QAプロセスの動画をリクエストしたのは役に立ちました。言語に依存せず、製造委託先がどのようにQAを行っているかを示してくれたからです。しかし、プロセス全体を端から端まで動画で捉えるのは困難です。QAプロセスの動画では、テストに使ったmicroSDがそのまま最終製品に残ってしまうことがわからず、それをどう防げばいいのかもまだわかりません。

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

カスタマーサクセスのプロセスを構築する

年初時点では、現地のTinyPilotチームの仕事は約20%がカスタマーサポート、80%が組み立てとフルフィルメントでした。このバランスは今年、製造とフルフィルメントを外部ベンダーに移管するにつれて大きく変わりました。2024年初頭には、組み立てとフルフィルメントは現地チームの業務の0%になるはずです。

問題は、カスタマーサポートが依然として現地チームの週間稼働の50%にも満たないことで、空いた時間をどう活用するかという点です。

チームは年初からこの問題について話し合ってきました。最も自然な移行は、サポートリクエストに受動的に対応するのではなく、既存顧客へ能動的に働きかけることのように思えます。こうした役割を「カスタマーサクセス」と呼ぶ企業もあります。

恥ずかしながら、私はめったに顧客に自ら連絡を取りません。重要だが緊急ではないタスクの典型で、常におろそかにしてしまうのです。ただ、現地スタッフにやり方を教えることができれば、私自身の稼働時間に縛られることはなくなります。

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

1. カスタマーサポートチームが、TinyPilotに多く支払ってくれている顧客（特にリピーター）をリサーチする。
2. カスタマーサポートチームが、相手企業のことや注文内容に具体的に触れた人間味のあるメール（自動化されたものに見えないように）を送り、機能要望や課題について話すための通話を提案する。
3. 顧客とミーティングを行い、TinyPilotをどのように使っているかを学ぶ。
4. 顧客からのフィードバックを機能ロードマップに反映させる。

私自身が顧客として他社からアプローチを受けるとき、それは大抵あからさまに自己中心的です。「弊社のサービスをよりよく理解していただくお手伝いをしたい」などと言いながら、実際はもっと買わせようとしているだけです。

TinyPilotからの働きかけは、寄生的でも強欲でもなく、協働的なものにしたいと考えています。そうすることで、ロードマップを顧客が本当に求めている機能に近づけられますし、そうでなければ気づけなかったTinyPilotの新たな可能性も見つけられると思います。

サイドプロジェクト

Ansibleに別れを、Nixにこんにちは

ここ数年、開発環境の管理にAnsibleを使ってきましたが、多くの悩みの種にだんだん嫌気がさしてきました。AnsibleをNixに置き換えようとここ数ヶ月試行錯誤してきましたが、ようやく完了したと思います。

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

私が見落としていた重要なポイントは次の2つでした。

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

今では、開発システムをAnsibleで管理する代わりに、Home Managerとプロジェクト固有のNix flakesですべてを管理しています。もう1ヶ月以上Ansibleのplaybookを実行していません。

顕著な変化の一つは、よく使うコマンドについてbashエイリアスをより頻繁に使い、定義するようになったことです。以前のbashエイリアス追加の手順は、Ansibleのplaybookに追加してから、エイリアスを使いたいすべてのシステムでplaybookを再実行するというものでした。しかし、私の環境でAnsibleのplaybookを実行するのは非常に遅く、失敗しやすかったため、結局半分のシステムだけがエイリアスを認識し、残りは認識しないという状態になりました。あまりにも手間がかかるので、新しいエイリアスを追加して日常的に使いこなそうという気になれなかったのです。

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

NixOSへの完全移行も試みていましたが、普段使っているDebianの開発環境との違いが多すぎて苦労していました。Home Managerを使うのは、Nixに完全に乗り換えることと、慣れ親しんだDebianのワークフローを維持することの、ちょうど良い中間地点です。

私もすっかり“奇妙なメカニカルキーボード愛好家”になってしまった

Pythonの生みの親であるGuido van Rossum氏へのLex Fridman氏のインタビューで、Lexは自身のKinesis Advantage 2キーボードをどれだけ愛しているかについて長々と語っています。

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

LexはKinesisキーボードを愛するあまり、飛行機に乗るときでさえ持参します。ラップトップの内蔵キーボードを使うより、巨大なキーボードを持ち運ぶ方を選ぶのです。

私は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のオフィスから古い在庫や予備部品をすべて片付ける。