一言でまとめると

翌日配送――どれほど難しいというのだろう？

ハイライト

• 翌日配送オプションの提供に、驚くほど手こずりました。
• Handmade Seattleカンファレンスに参加しました。
• ZigとオープンソースのAIチャットボットを試してみました。

目標の達成度

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

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

• 結果：移管は完了しました。
• 評価：A

委託先は、内製していたときと同等の品質でTinyPilotデバイスを製造できるようになりました。委託先からデバイスは直接3PL（外部物流倉庫）の倉庫へ発送されるため、TinyPilotが自社オフィスを持つ必然性はなくなりました。

顧客ヒアリングを5件実施する

• 結果：3名の顧客に連絡しましたが、通話は0件でした
• 評価：F

今回は私が優先順位付けを忘れてしまいました。カンファレンスと休暇の移動でほぼ2週間を失い、カスタマーサポートチームもいつもより手が回らない状況でした。事業の長期的な持続可能性のために継続的に投資すべき領域なので、もっとチームに働きかけて優先度を上げるべきでした。

TinyPilotのオフィスから古い在庫と予備パーツをすべて処分する

• 結果：一旦中断することにしました
• 評価：対象外

大家さんが退去時期についてかなり柔軟だったため、思っていたほどオフィスを急いで閉める必要はありませんでした。また、単にゴミとして捨てずに片付けようとすると、想像以上に手間がかかることも分かりました。1個あたり1〜50ドル程度の価値があるものが何十種類もありますが、それぞれ在庫は数個ずつしかありません。

例えば、中古のArduino Unoが3枚あります。新品は1枚28ドルですが、3枚をeBayで売っても合計30ドル程度にしかなりません。しかも出品から発送まで一連の作業に約2時間かかります。つまり、売却益よりも人件費のほうが高くついてしまうのです。

そこで新しい計画として、退去が近づいたタイミングで日時を告知し、欲しい人が自由に持ち帰れるようにしようと考えています。

TinyPilotの数値

利益の数字は恐ろしく見えますが、これは外部委託製造への移行で支出が「一時的かつ集中して」発生するようになったためです。10月は原材料費の請求がありませんでしたが、11月は原材料費だけで5万7千ドルかかりました。本来は売上原価として計上すべきですが、現時点では単純な現金の出入りで報告しています。

8万〜10万ドルがTinyPilotの通常の売上レンジで、今回もその範囲に収まっています。ブラックフライデー／サイバーマンデーを活用することも考えましたが、製造移管で在庫が少なくなっていたため、値下げするほどの在庫がありませんでした。

翌日配送――そんなに難しいのだろうか？

TinyPilotの歴史のほとんどの期間、私たちは翌日配送やお急ぎ便を提供してきませんでした。

自社で発送していた頃は、週6日オフィスに人を配置して注文を処理していましたが、1日あたりの担当は1名だけでした。誰かが病欠や休暇で不在になれば翌日発送が不可能になることが分かっていたため、翌日配送は提供していませんでした。

発送業務を外部物流倉庫（3PL）に切り替えたことで、人員面の脆弱性は解消されました。3PLは私たちよりはるかに人員に余裕があるため、どんな状況でも注文は1営業日以内に発送されるはずです。

3PLへの切り替えによって、ようやく翌日配送の選択肢を提供できるようになったのです！

複雑化した配送の仕組み

3PLに切り替えたことで、配送オプションを管理するロジックはより複雑になりました。以前、TinyPilotの顧客に配送オプションを提示する流れは次のとおりでした。

1. 私がShopifyで顧客に提示する配送オプションを選びます。
2. 顧客がチェックアウト時に配送オプションを選びます。
3. 私たちが顧客の選択に合わせてShopifyで送料を購入します。

この仕組みでは、Shopifyが体験をエンドツーエンドで管理しており、しかもそれをうまくやっていました。

私たちの3PLはShipStationという（あまり出来の良くない）倉庫管理システムを使っています。このツールがShopifyストアと連携するため、現在の構成は次のようになっています。

1. ShipStationが対応している配送オプションの一覧を3PLに提示します。
2. 3PLがその一覧から、顧客（TinyPilot）に提供したい配送オプションを選びます。
3. ShopifyがShipStationに問い合わせて、ShipStationと3PLの双方が合意している配送オプションを確認します。
4. 私がShopify上で、顧客に提供したい配送オプションを選びます。
5. チェックアウト時に、ShipStationが不透明なロジックで顧客にとって「最適」なオプションを推測し、表示される配送オプションを2〜3個に絞り込みます。
6. 顧客がチェックアウト時に配送オプションを選びます。
7. 3PLが顧客の選択に合わせてShipStationや他のベンダーから送料を購入します。

これだけ多くのプレイヤーが関わると、問題が起きる可能性は無数にあり、責任のなすり合いが起きる余地も山ほどあります。

翌日配送を有効にしようとしたところ、3PLからShipStation、Shopifyを経て私のところに設定が反映される頃には、翌日配送の選択肢が一つも表示されないことが分かりました。

数ヶ月にわたるやり取りの末、問題がShipStationにあることを突き止めました。彼らは翌日配送と2日配送を「似たようなもの」とみなしており、2日配送のほうが常に安いため、翌日配送の選択肢を決して表示しないのです。

はい、読み間違いではありません。荷物の送料を販売することを本業とするShipStationが、2日配送より高い翌日配送を誰が選ぶのか理解していないのです。

ShipStationで問題が多発したため、顧客への配送オプション提示については以前の構成に戻すことにしました。現在はShopifyを通じて配送オプションと料金を表示するだけで、わざわざShipStationに料金を問い合わせることはしていません。

チェックアウトのプロセスからShipStationを外すことによる問題は、3PLがShipStationの高いレートで送料を購入している一方で、Shopifyが顧客から徴収する配送料はより安いShopifyのレートに基づいていることです。たとえば顧客が翌日配送で30ドルしか支払わなくても、ShipStation経由の実際の送料は100ドルかかります。その差額70ドルはTinyPilotが負担しなければなりません。

それでも、この方法ならShipStationに間抜けな具合に上書きされることなく、提供したい配送オプションを提示できます。そして70ドルの追加送料を負担する方が、販売機会を逃すよりはましです。

翌日配送を選ぶ顧客は4倍要求が厳しい

ほとんどの場合、3PLは1営業日以内に注文を発送します。時々何かあって2営業日かかることもあり、ごく稀に3日かかることもあります。ウェブサイトでは取り扱い（ハンドリング）に最大3日かかると案内していますが、顧客はあまり気にしていないようです。

通常配送や2日配送を選んだ顧客は、取り扱いに1日遅れが出ても90%の場合は何も言ってきません。

ブラックフライデー明けの月曜日、UPSで奇妙な不具合が発生し、集荷したすべての荷物の追跡情報が更新されませんでした。倉庫はUPSが確かに集荷したと主張しましたが、UPSの追跡情報には何も表示されなかったのです。

このUPSの追跡不具合は、翌日配送を依頼していた5名の顧客に影響しました。24時間以内に、そのうち2名から遅延についての苦情メールが届きました。つまり、翌日配送の顧客の40%が苦情を寄せたのに対し、通常配送や2日配送で遅延に気づいて連絡してくるのは約10%でした。

気持ちは分かります。私自身、翌日配送で何かを注文したときは早く届くのを心待ちにしますし、販売店が何日も発送せずに放置していたらイライラします。

翌日配送を選ぶ顧客は諸刃の剣です。通常配送の5倍の配送料を払ってでも早く手に入れたいというなら、TinyPilotの売上を押し上げてくれる太い顧客である可能性が高い。一方で、彼らはかなり要求水準が高く、多くの顧客が持っていない切迫感を期待するため、サポートチームにとってはストレスの元になることも分かってきました。

初めてのHandmadeカンファレンス

11月に、シアトルで開催された初めてのHandmadeカンファレンスに参加しました。低レイヤーのソフトウェアに携わる人々のためのインディーなカンファレンスです。

カンファレンスから得た気づきをいくつか紹介します。

人気の技術スタック以外にも選択肢はある

デヴィッド・フォスター・ウォレスは、有名な2005年のケニヨン大学卒業式スピーチを、魚についてのジョークから始めました。

2匹の若い魚が泳いでいると、向こうから泳いできた年長の魚が2匹にうなずいて声をかけます。「おはよう、少年たち。水の調子はどうだい？」2匹の若い魚はしばらく泳ぎ続け、やがて一方がもう一方を見て言います。「『水』って一体なんだ？」

私にとって、水とはウェブブラウザのことです。

ソフトウェアとは、ユーザーが最終的にHTMLとJavaScriptを通じて操作するものだという考えに慣れきっていて、他に選択肢があることをほとんど忘れています。90年代に静的な文書を表示するために作られた技術を前提に、すべてを設計していることがいかに奇妙か、長い間考えたことがありませんでした。

しかしHandmadeで出会った開発者のほとんどは、ウェブブラウザをまったく扱っておらず、私が使い慣れた技術も使っていませんでした。

スマートフォンやタブレットでソフトウェアを書くためのアプリMobileCodeの作者に会いました。何の言語を使っているのか尋ねたとき、Flutter、あるいはおそらくReact Nativeと答えるのだろうと予想していました。彼が「Cです」と答えたときは唖然としました。

それだけでなく、彼はCでモバイル開発をすることに良い手応えを感じていると言っていました。モダンなフレームワークの何層もの抽象化を経由するのではなく、iOSやAndroidのネイティブなグラフィックスAPIを直接呼び出せるからだそうです。

止まらないインディーの野心

そもそもHandmadeのことを知ったのは、SerenityOSの作者であるAndreas Klingをフォローしていたからです。彼はサードパーティのライブラリや依存関係を一切使わずに初期のOSを一人で作り上げ、2021年にHandmadeでそのプロジェクトを発表しました。

Handmadeでは、私がしばらく前から関心を持っているインディーなプログラミング言語Zigについてのトークも行われます。Zigの作者であるAndrew Kellyは、2021年にCoRecursiveポッドキャストに出演し、世の中のすべてのCコードをZigに置き換えたいと語っていました。

Adam：Cを倒したとき、世界はどうなっているんでしょう？

Andrew：ああ、美しいですよ。見た目はほとんど変わりません。ただ、すべてのアプリがほんの少しだけうまく動き、クラッシュが減り、メモリ使用量が減り、速度が上がるんです……

教科書でオペレーティングシステムや組み込みデバイスの仕組みを示すとき、みんながそうしているから当然Zigをサンプルコードに使う、というのが当たり前になるんです。

私はAndrewのような野心やソフトウェアへの熱意がとてもクールで刺激的だと思っており、それこそが私がHandmadeに求めていたものでした。

Handmadeはインディーの野心という期待に応えてくれました。このカンファレンスは「車輪の再発明」を称賛する場でした。

ソフトウェアの世界で「車輪の再発明だ」と指摘するのは、たいていは批判です。しかしHandmadeはそれを歓迎します。なぜ車輪を再発明してはいけないのか？もしかしたらあなたの車輪は、みんなが使っている車輪より優れているかもしれない。そして車輪を再発明しようとするだけで、車輪がどう動くのかをより深く理解できるのです。

Cameron Riekesは学部生で、2D RPGの制作について発表しました。ところが彼は「気づいたら」自作の3Dゲームエンジンをゼロからコーディングしていたのです。

Yasser Arguellesは20代前半で、LLVMをゼロから置き換えるTildeに取り組んでいます。補足すると、LLVMは20年にわたって活発に開発が続けられているコンパイラバックエンドです。Yasserは発表の中で、コンパイラのバックグラウンドはないけれど、Handmadeの議論で最も要望が多かったのがLLVMの代替だったので、「じゃあ自分がやろう」と思ったと語っていました。

そして私はAndrew Kelly本人にも会うことができ、彼はとても親切でした。その会話がきっかけで、ついにZigのコードを書いてみようという気になりました。

ビッグテックへの極端な懐疑

このカンファレンスについて一つ不満があったとすれば、ビッグテックへの批判的なトーンが、私には非合理的だと感じられるほど強かったことです。

カンファレンス全体を通じて語られていたのは、ビッグテックは基本的に毒だ、という物語でした。彼らが生み出すものはすべてバグだらけで、肥大化し、信頼性が低く、値段が高すぎるというのです。

登壇者によれば、より多くの人がビッグテックの欠点に気づいていない理由は、ビッグテックがソフトウェアカンファレンスを支配しているからだそうです。彼らは登壇者がビッグテックのソフトウェアの問題について正直に語ることを禁じているのだと。私自身、いくつかの中規模カンファレンスで登壇したことがありますが、ビッグテックを批判してはいけないと言われたことは一度もないので、この話は腑に落ちませんでした。

私は反ビッグテックの見方に共感する部分もあります。できる限りインディーな技術を好んで使いますが、ビッグテックが多くのことを上手くやっており、技術を前進させるための大半の重労働を担っているとも思っています。ただ鼻で笑って、インディーなものが常にビッグテックの同等品より優れていると決めつけるのは間違いだと思います。

その他の参加記

• Carl Sverre

他にも参加記をご存知でしたら教えてください。リンクを追加します。

サイドプロジェクト

WanderJest

WanderJestは、数年前に私が始めた、近くのライブコメディを探すためのウェブアプリです。コロナ禍で一旦棚上げしましたが、それ以来時々いじり続けています。

WanderJestで最も大きな課題の一つは、今後開催されるショーの情報を集めることでした。コメディショーに関する正規の情報は、たいてい次のようなポスターの形で存在します。

出演者はポスターを作ったうえで、同じ情報を別の場所にわざわざ入力し直したいとは思いません。そこで、ポスターから情報を「タダで」取得する方法を考えてきました。

最初のアイデアは、ショーの主催者がポスターを作成するのを支援するツールを作ることでした。数日間試作してみましたが、最初に提案したコメディアンには興味を持ってもらえませんでした。このアイデアを完全に諦めたわけではありませんが、改善を続けるほどワクワクしなかったのです。

しかし最近はAIの画像認識が進歩してきたので、別のアイデアとして、ショーのポスターを見つけてオープンソースのAIツールでショー情報を抽出することを考えています。

Simon Willison氏のLlamafileに関する投稿を読んだとき、画像を扱えるチャットボットを試すのがいかに簡単になったかに気づき、ポスターの問題で試してみることにしました。

残念ながら、画像に対するLLaVA 1.5の精度は、私が必要とする水準にはまだ届かないようです。コメディショーのポスターを見せて質問すると、正答率は70%程度にとどまります。

設定をやみくもにいじってみましたが、結果を改善することはできませんでした。

それでも、この分野でオープンソースのソリューションが進歩し競争が生まれているのを見るのはワクワクします。詳細については、こちらをご覧ください。

• LlamafileとLLaVA 1.5でのざっくりとした実験

まとめ

今月できたこと

• TinyPilot Pro 2.6.2を公開しました
• Handmade Seattleカンファレンスに参加しました
• 重要なベンダーの1社との出荷データ連携の問題を解決しました

学んだこと

• 翌日配送は、より多く支払う意思のある顧客を引き寄せるが、その分要求も厳しくなります。

来月の目標

• TinyPilotのライセンス認証の設計を完了させる。
• 新デバイスの製造ロットごとの抜き取り検査プロセスを構築する。
• TinyPilotの年末の税務処理を片付ける。