一行サマリー

翌日配送なんて、どれほど難しいというのだろう？

ハイライト

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

目標の評価

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

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

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

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

顧客インタビューを5件実施する

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

今回は私が優先順位付けを怠ってしまいました。カンファレンスと休暇でほぼ2週間不在にし、カスタマーサポートチームも通常より手が足りない状況でした。事業の長期的な持続性のためにも、この取り組みへの投資を続ける必要があるので、もっとチームに働きかけて優先すべきでした。

TinyPilotオフィスの古い在庫と予備パーツを一掃する

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

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

例えば、中古のArduino Unoが3枚あります。1枚の定価は28ドルです。eBayで3枚まとめて売れば合計30ドルほどにはなるかもしれませんが、出品から発送までの作業に約2時間かかります。従業員の人件費を考えると、売って得られる金額よりもコストの方が高くなってしまいます。

そこで新しい計画として、退去が近づいたら開放日を告知して、欲しいものがあれば自由に持ち帰ってもらおうと考えています。

TinyPilotの数字

利益の数字は恐ろしく見えますが、これは外部委託製造への移行によって経費の発生タイミングがまとまってしまったためです。10月は原材料費の請求がありませんでしたが、11月は原材料費が57,000ドル発生しました。本来は売上原価として計上すべきですが、今は単純な現金収支として報告しています。

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にあることを突き止めました。ShipStationは翌日配送と2日配送を「似たようなもの」とみなしており、2日配送の方が常に安いため、翌日配送のオプションを決して表示しないのです。

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

ShipStationに関してあまりにも多くの問題を抱えていたため、お客様への配送オプションの提示については以前の構成に戻すことにしました。現在は、ShipStationからレートを問い合わせるのをやめ、Shopifyを通じて配送オプションと料金をそのままお客様に表示しています。

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

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

翌日配送を選ぶお客様は4倍シビアです

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

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

ブラックフライデー明けの月曜日、UPSで奇妙なトラブルがあり、集荷した荷物の追跡情報がまったく更新されないという事態が起きました。倉庫はUPSが確かに集荷したと主張していましたが、UPSの追跡上は何も表示されませんでした。

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

そして、その気持ちはよくわかります。私自身、翌日配送で何かを注文したときは、到着を心待ちにしますし、販売者が何日も発送を放置していたらイライラします。

この翌日配送を選ぶお客様は諸刃の剣です。通常送料の5倍を払ってでも早く手に入れたいと思うのであれば、おそらくたくさんお金を使ってくれるお客様であり、TinyPilotの売上を押し上げてくれるでしょう。一方で、彼らはかなり要求水準が高く、大多数のお客様が持っていない切迫感を抱えているため、サポートチームにとってはストレスになりかねないこともわかってきました。

はじめてのHandmadeカンファレンス

11月に、シアトルで開催されたはじめてのHandmadeカンファレンスに参加しました。低レベルソフトウェアに取り組む人たちのためのインディーカンファレンスです。

以下が、カンファレンスから得た気づきです。

定番の技術スタック以外にも選択肢はあります

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

二匹の若い魚が泳いでいると、向こうから年配の魚が泳いできて、会釈しながら言いました。「おはよう、坊やたち。水の調子はどうだい？」二匹の若い魚はしばらく泳ぎ続け、やがて一方がもう一方を見て言いました。「水って何だ？」

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

私は、ソフトウェアとは最終的にユーザーが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代前半で、Tildeという、LLVMを一から置き換えるプロジェクトに取り組んでいます。参考までに、LLVMは20年にわたって活発に開発が続けられてきたコンパイラバックエンドです。彼の発表では、コンパイラの背景はなかったけれど、Handmadeの議論でLLVMの代替を求める声が非常に多かったので、「じゃあ、自分がやろう」と思ったのだそうです。

そして、とても親切なAndrew Kellyさんにも会うことができました。その会話がきっかけで、ついに私もZigのコードを書いてみることにしました。

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

カンファレンスについて一つ不満があったとすれば、その論調が私には不合理に思えるほどビッグテック批判一色だったことです。

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

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

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

関連レポート

• Carl Sverre

ほかにレポートをご存じの方がいれば教えてください。リンクを追加します。

サイドプロジェクト

WanderJest

WanderJestは、数年前に私が始めたウェブアプリで、近くのライブコメディを探す手助けをすることを目的としています。COVIDが流行したときに一旦棚上げしましたが、その後も断続的にいじり続けています。

WanderJestの最大の課題の一つは、今後のショーに関する情報を集めることでした。コメディショーに関する正規の情報源は、たいてい次のようなポスターです：

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

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

しかし今、AIの画像認識が進歩してきたことで、別のアイデアが浮かびました。ショーのポスターを見つけて、オープンソースのAIツールを使ってそこからショー情報を抽出するという方法です。

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

残念ながら、LLaVA 1.5の画像に対する精度は、私が必要とするレベルにはまだ達していないようです。コメディショーのポスターを見せて質問すると、回答の正答率は約70%程度でした：

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

それでも、この分野でオープンソースのソリューションが進歩し、競争が生まれているのを見るのはわくわくします。詳しくは以下をご覧ください：

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

まとめ

今月やったこと

• TinyPilot Pro 2.6.2を公開しました
• Handmade Seattleカンファレンスに参加しました
• 重要なベンダーの1社との間で、配送エクスポートに関する問題を解決しました

学んだこと

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

来月の目標

• TinyPilotのライセンスチェックの設計を完了させます。
• 新デバイスの製造ロットごとに抜き取り検査を行うプロセスを作ります。
• TinyPilotの年末の税務処理を片付けます。