販売可能なソフトウェアの最小有効単位

brandur.org 記事 アトム 断片 ニュースレター シーケンス 現在の使用法 著者について 自動 販売可能なソフトウェアの最小有効単位 記事 販売可能なソフトウェアの最小有効単位 🔗 2026年5月31日公開 場所 ベルリン 私はX/Twitterの@brandurです。 2026年5月31日 安い != ゼロ 構築の敷居 実行可能性の領域 Riverがもっともらしいビジネスとして 先週、私はStainlessを辞めて、サイドプロジェクトであるRiverを小さく持続可能なビジネスに育てるという私の意図について書きました。その手紙を送ったとき、何人かの人がAI時代のソフトウェア会社を経営しようとする私の思考プロセスについて尋ねてきました。「正気か？！LLMによって構築された社内パッケージに、出荷するものは何でも即座に置き換えられてしまうぞ！」 この時点で、私も他の誰とも同じくらいLLMの信奉者になっているので、それは非常に的を射た質問であることを認めます。確かに私は正気ではないかもしれませんが、私の思考プロセスを話しますので、皆さんが判断してください。 まずは逸話から始めましょう。今朝、私はインターネットで最も悲惨なエンゲージメント稼ぎと偽情報および架空の逸話の巧妙な勧誘者の巣窟であるLinkedInを閲覧していました。そこにいたあるユーザーは、彼の会社がAtlassianのJiraに月額400ドルを費やしていることについて投稿していました。彼はこの法外な請求に個人的に侮辱を感じたため、彼のチームにClaudeを使って新しい社内タスクトラッカーを構築させました。Jiraと月額400ドルの支出はなくなり、LLMによる継続的な改良によって必要なあらゆる方法でツール化できるカスタムパッケージに置き換えられました。 私たちは長年ソフトウェアの世界で「購入か構築か」について議論してきましたが、昨年その計算式が変わりました。以前は、構築は非常に費用のかかる提案でした。特にエンジニアリングの給与水準や優秀な人材の不足を考えるとそうでした。莫大な初期費用、スケジュール超過、無限に深い泥沼にはまることが予想されました。一般的な知恵としては、コア領域内でのみ構築し、周辺プロジェクトに脇道にそれるのを避けるべきだとされていました。会社が非常に大きくなり、そのような注意散漫による費用が利益の中に快適に消えるようになったら、それらをやる価値があるかもしれません。しかし、LLMはすべてを変えました。突然、モデルに仕事をさせることで、かなりの量のソフトウェアを生産することがかなり可能になりました。 安い != ゼロ LLMはソフトウェアの構築を著しく安価にしましたが、ゼロにはしていません。優れたLLM構築システムには、オペレーターがモデルをしばらく動かし、結果に基づいて調整し、別のパスを要求し、さらに洗練させるといったフィードバックループが依然として含まれ、費やした時間と品質との最適な妥協点である満足のいく結果に到達するまでに数十回のループを要します。そして以前と同様に、メンテナンスは継続的なコストになります。特に複雑なパッケージでは、常に追加すべき機能や修正すべきバグがあります。LLMはこれらの変更を容易にしますが、無料にはしません。最も高価な要素は、結果を監督し検証する方程式の中の人間のパートタイム労働です。 上記の月額400ドルのAtlassianの逸話に戻ると、初期構築の労力（洗練パスを含む）と継続的なLLM駆動のメンテナンスを考慮すると、それが全く臭いテストに合格するでしょうか？タスクトラッカーは依然として複雑なソフトウェアであり、LLMを過度に使用したとしても、最初のプッシュには最低でも数週間（寛大に見ても）を費やすと予想されます。そこから、その内部の所有者はバグ修正と機能開発に切り替わります。状況を定量化するために、いくつかの概算を試してみましょう。 年収20万ドルのエンジニアが週40時間働いているとします（9/9/6はありがたいことに考案されなかったと仮定しましょう）。それは月額16.7万ドル、週額3,850ドル、時給96ドルです。 salary = 200_000.0 { month: salary / 12, week: salary / 52, hour: salary / 52 / 40, }.each { |k, v| puts "%-6s $%0.2f" % ["#{k}:", v] } month: $16666.67 week: $3846.15 hour: $96.15 Atlassianに支払われるはずだった月額400ドルを相殺するために、エンジニアは、コンテキスト切り替えのオーバーヘッドを含まずに、自作のJiraクローンで機能や修正を促したり、データベースを管理したりするために、月に4時間（400 / 96）以上費やすことはできません。LLMの助けがあったとしても、これはすでに完全に非現実的ですが、寛大に見積もって月に2時間まで減らせるとしましょう。それでも、最初の2週間の労力の後、採算が取れるまでに37ヶ月かかります（Atlassianの月額400ドルから月額2時間のメンテナンス労力を差し引いた額を取り戻すまでの月数 = 2 * 3846.15 / (400 - 2 * 96.15)）。誤解しないでください、私はJiraを使ったことがある人と同じくらいJiraが嫌いで、私もJiraを再構築したいという抑えきれない衝動に駆られますが、ここでの計算は成り立ちません 1。 構築の敷居 しかし、それは常に当てはまるのでしょうか？少し別の側面を見て、はるかに高価なSaaS製品を検討してみましょう。Geminiの報告によると、Salesforceのフル装備シートの価格は月額約500ドルです。50シートが必要だとすると、それは月額25,000ドルです！その価格で、あなたは1.5倍のエンジニアリングリソース（25 / 16.7）をあなたのクローンにフルタイムで投入できます。繰り返しますが、CRMはかなり複雑なソフトウェアであり、再構築は些細なことではありませんが、どのように解釈しても、これは中小企業にとっても「構築」の決定に近いでしょう。（そしてSalesforceは年初来30%下落しているので、市場もそう信じているようです。） 実行可能性の領域 私は、任意の複雑さのソフトウェアパッケージについて、適正な価格設定がされている場合、「購入か構築か」という選択において、私たちの日常の仲間となった強力なLLMの存在を考慮しても、「購入」が理にかなう「実行可能性の領域」があると主張しています（または期待しています）。 実行可能性の領域にあるソフトウェアは、次の2つの条件を満たします。 1. LLMによる再構築が些細なものではなく、継続的なメンテナンス負担を伴うだけの十分な新規性があること。 2. LLMによる再構築を強く促すほど法外な価格設定ではないこと。 適正な価格設定がソフトウェアを実行可能性の領域内に維持する限り、ライセンス料として支払われる総額は、初期プッシュを促し、その継続的な存在を維持するための累積費用よりも少なくなります。実行可能性の領域のどこかに、販売可能なソフトウェアの最小有効単位が存在し、それ以下では、サードパーティの購入プロセスを経るのと同等かそれ以下の労力で再構築が可能であり、長期的には費用対効果が高くありません。 継続的な価格 継続的な支出 エンジニア相当時間/月 相当エンジニアリソース 購入 構築 Jira $400/月 $400/月 4.2時間 0.02エンジニア ✔ Salesforce $500/シート/月 $25k/月 260時間 1.5エンジニア ✔ Riverがもっともらしいビジネスとして 過去数年間、Blakeは私たちのオープンソースプロジェクトであるRiver（GoとPostgres用のジョブキュー）に基づいた小規模ビジネスに取り組んできました。そして少なくとも今後数ヶ月間は、私がフルタイムで引き継ぐ予定です。この自己目的的なブログ記事は、世界がLLMの地平線を越えたにもかかわらず、Riverが販売可能なソフトウェアの最小有効単位を超えて、現代において依然としてもっともらしい会社であることを願っている、ということを長々と述べています。 新規性という点では、Riverはオープンソースプロジェクトであり、ほとんどすべてのジョブ関連機能（定期ジョブ、スケジュールジョブ、ユニークジョブ、ウェブUIなど）を無料で利用可能にしていますが、一部の高度な機能（ワークフロー、シーケンシャルジョブ、同時実行数制限付きジョブなど）と請求機能（請求書による請求）はPro版として有料で提供しています。LLMは後者の機能を再現できるかもしれませんが、私たちはそのAPI設計とパフォーマンス特性に十分な思考を投入しているため、同等の忠実度に戻すにはかなりの労力が必要でしょう。 価格の点では、チーム規模に基づいて非線形にスケーリングする価格モデルを使用しており、開発者20人までで月額125ドルから始まり、無制限のサイトライセンスではその複数倍にまでスケーリングします。そのため、中小規模の開発チームにとって、月額125ドルが全員分のオールインコストです。 では、冒頭の質問に戻ります。私はこれを正しく理解しているでしょうか？誰にも分かりません。今のところ、私はこれに生計を賭けており、数ヶ月後には結果が出るでしょう。 冒頭の写真について：これは自然の地形です。