- SaaS連携は開発者が製品そのものに集中できるようにしてくれると言われるが、実際には毎回 隠れた5つのコスト（税） が存在する
- 導入前の 発見、登録、統合、ローカル開発、運用 の各段階で、時間、複雑さ、精神的負担が継続的に発生する
- SaaSではなく 統合型プラットフォーム（Cloudflare、Supabase など） を選べば、この反復的なコストと複雑さを大きく減らせる
- ベンダーロックインは避けられない現実であり、複数サービスの寄せ集めよりも 1つの統合プラットフォームで開発フロー（Flow） を守るのが最善である
- 結局もっとも重要なのは フレームワークやサービスそのものではなく、自分が作りたいソフトウェア である
SaaSは単にブランディングがうまいだけのベンダーロックイン
- 開発者は「製品開発だけに集中せよ」と言われるが、実際には auth、キュー、ファイル保存、画像最適化のような SaaSベンダー を導入するとさまざまな負担が発生する
- 金銭的コストだけでなく、時間の消耗、摩擦、そして精神的な疲労もある。
1. 発見税（Discovery Tax）
- SaaSサービス導入前には、実際に 何の機能と価値を売っているのか を把握するプロセスが必要である
- 問題解決の範囲、既存スタックとの互換性、規模に見合う妥当な価格、ドキュメントの明確さ、独特な実装方式などの細部を評価しなければならない
- こうした調査プロセスは過去の経験として簡単に共有・再利用できるものではなく、その多くは主観的な判断である
- マーケティングメッセージ が自分に合うか、そのサービスが本当に役立つかを自分で見極めなければならない負担がある
2. 登録税（Sign-Up Tax）
- サービスを選んだ後は、メールアドレスとカード情報 を提供しなければならない
- 従量課金が可能か、サブスクリプション型のロックインしか用意されていないかを確認する必要がある
- チームメンバーがダッシュボードへアクセスするために追加費用が発生するなど、不透明な料金体系が問題になる
- 無料トライアルなしでもテスト可能か、初期段階から支払いが求められるかを点検しなければならない
- コードを1行も書く前から、ベンダーとの契約関係が成立してしまう
3. 統合税（Integration Tax）
- 実際の導入では、ドキュメント確認、ライブラリのインストール、フレームワークとの接続、ドキュメント外の追加トラブルシューティング が必須になる
- しばしばツールとの衝突や予想外の問題に直面する
- SaaSが 最小公倍数 だけを対象にしている場合、最新スタックや特化した環境ではさらに多くの作業が必要になる
4. ローカル開発税（Local Development Tax）
- SaaSサービスが ローカル環境をサポートしているか は不確かである
- ローカルエミュレーターの提供や、テスト目的でスタブ化できることが求められる
- 一部機能の確認のためにクラウドトンネリングなどが必要になり、環境構成が複雑になる
- 本番、ステージング、ローカル それぞれで設定を分岐させることが避けられない状況になる
5. 本番税（Production Tax）
- サービス統合後は 本番環境 で新たな負担が発生する
- ステージングやPRプレビュー環境でも使えるか、APIキー管理、監視とロギング、通知など追加の管理が必要になる
- 開発環境では問題なくても、実際の運用環境でのみ発生するエラーや不整合に備えなければならない
- サービスの安定性を維持する責任は、結局のところ開発者に転嫁される
結論
- 現代の SaaSのスローガン は「車輪の再発明をするな」だが、サービスを追加するたびに摩擦が伴う
- サービス導入は単なる統合ではなく 契約 であり、依存関係の増加とアーキテクチャの変化を伴う。ベンダーロックインは不可避であり、置き換え時には相当なコード書き換えの負担が発生する。
- したがって、こうした意思決定を繰り返すよりも、最初から 一体型プラットフォーム を選ぶほうが効率的である
- 重要なのは、開発者が本当に作りたいソフトウェアである
- Cloudflare、Supabase のような統合プラットフォームは、データベース、キュー、画像、ストレージを同じ環境で提供し、前述の税の負担を大幅に減らしてくれる。
- 複数ベンダー間を行き来する必要がない（コンテキストスイッチング不要）
- APIキー をいじる問題が発生する頻度を減らせる
- 互換性や環境ごとの分岐管理の必要性を最小化できる
- 開発環境と本番環境で一貫した統合体験を提供する
- こうしたプラットフォームは、まるですべてが同じマシン上で動いているような感覚をもたらし、コードとサービスの距離を最小化することで、どんなSaaSでも提供できない 開発への没入感（「Flow」） を取り戻させてくれる。
> 重要なのはフレームワークやサービスの選択ではなく、自分が作りたいソフトウェアとフロー（Flow）を守ること である
2件のコメント
Supabase が良い例として挙げられていますが、ではどのような SaaS が避けるべきサービスなのでしょうか？
Hacker Newsの意見
これはアダム・スミスのいう「rent seeking（レントシーキング）」を、現代における超大規模な拡張形として見る視点だと思う
このような経済行為は社会的に有害なので避けるべきであり、犯罪化すべきだと考える
一方で、自由ソフトウェアの極端なあり方も経済的には問題があり、その理由はソフトウェア制作者の努力がユーザーの得る価値に比例しないからだ
ソフトウェアを購入することと、別途サービス契約を結ぶことは分けるべきで、それぞれが実際に別個の価値を提供すべきだと主張する
SaaSではこうしたものが一つに束ねられ、実際にはサービスそのものよりもパッケージングが過度にいびつになっている点が問題だと思う
もし自分がそこまで強い信念を持っているなら、自分でSaaSを構築してオンプレミス配備・運用を行う会社を立ち上げ、現在のSaaSと似た価格で提供すべきだという主張
企業がデータの統制権を維持し、ベンダーロックインを防ぎつつ、SaaSと同じ品質・保証・価格を提供できるなら、市場を支配できるはずだという
こういうことはいつも悩むのだが、バイナリだけ提供して、ユーザーがAWSやGCP、あるいはCloudflare Workers上で実行できるようにすればいいのではないかと思う
自分にとってsaasは開発者としては魅力的だが、消費者としては嫌いな構造なので、倫理的ジレンマに陥る
もし自分がソフトウェアを販売するとしたら、ユーザーが無断で再配布してしまったらどうすればいいのか？ SaaSのように配布を制御できないはずだ
自分はfoss（オープンソース）の支持者だが、言われているようにこの方式も経済的には問題がある
GitHub Sponsorsでライセンスを発行するような方式も考えており、プロジェクトによっては認証をSSPLにし、あるいはライセンス購入時にBSD/MITへ切り替えるモデル（昔のRedisに近い）も検討している
ただ、こうしたモデルを実際に適用したときに本当に人々が購入するのか疑問で、両方の方法をサポートすることも考えているが、明確な答えがなく助言を求めている
参考までに、自分が作ったプロジェクトには、誰でも無料で暗号資産を作れるツール、YouTubeからブログを取り込む機能、YouTubeコミュニティと動画をGoogleフォトの代替として使う無制限ストレージなどがあり、プライバシー強化も考えている。収益化のアイデアがあれば教えてほしい
SaaSの大半は、提供側にとってホスティング、サポート、R&Dなど継続的なコストが発生することに言及
この構造がなぜ「レントシーキング」なのか、論理に納得しにくい
SaaSがすべてレントシーキングだとは言えず、ソフトウェアの「stickiness（張り付き、ロックイン）」自体が本質的にrent-seekingに近いと指摘
ほとんどのSaaS事業者はstickinessを追求するが、それはSaaS固有の性質ではないという見方
自分は、自分のSaaS製品を市場で妥当な価格で購入しようとする顧客に販売する立場だ
ベンダーロックインというのは、たいてい社内で「なぜNEWTHINGツールを導入しないのか？」と聞かれたときに、すでにOracleやMS、IBM、Salesforceと5年の長期契約を結んでいるからどうしようもない、という答えに表れる
だから10年もすると本当にその会社に完全に縛られ、もう変えられなくなる構造ができる
事業が10年も続くほどなら、むしろ祝福か退屈な悩みかもしれないが、創業初期にいろいろなツール選定に時間を使うより、素早く一つのプラットフォームを選んで集中したほうがよいと助言したい
こうした場合でも、サービスを標準化されたインターフェースで抽象化しておくのがよいという見解
抽象化しておけば、後で別のサービスへ切り替える際も代替実装を用意するだけで済む
この方法は将来志向だが、今の多くの企業はこうした準備が不足していると指摘する
依存関係の最小化は、製品とビジネスの持続可能性を高めるうえで最も重要な要素の一つだと思う
前職では、DocuSign風の電子署名体験を自社製品に統合する仕事を担当していた
DocuSign、Adobeなど主要ベンダーと話したが、APIの制約が多く、製品や顧客の要件にうまく合わないと感じ、結局は社内で自前実装することにした
通常ならDocuSignのようなツールを自分で作るのは悪手だが、うちの製品はすでに顧客から信頼されていたので導入障壁は低かった
実装当初は作業量が多かったが、実際に顧客向けの小さなカスタマイズが必要になったとき素早く対応でき、ベンダー製品を使っていたらはるかに面倒な大工事になっていただろうという点で、自前実装の判断は正しかった
書き手はSaaSはベンダーロックインだから買うなと言っているように読める
しかし本文ではCloudflareという特定プラットフォームに全面的に乗ることを勧めている
結局どんな選択でもすべてロックインであり、オープンソースやセルフホスティングですら置き換えるには大量のコードを書き直さなければならない、という話になる
単にベンダー依存の機能を使うことと「本当のロックイン」は別であり、ロックインとは、むしろ乗り換えるほうが現状維持より多くのコストと時間を要するときに生じる
ソフトウェアを疎結合で凝集度高く作れば、特定部分の置き換えは容易になる
なぜならインターフェースが単純なら差し替えも簡単だからだ
したがって「どうせ全部ロックインだから、いっそもっと強く一つのプラットフォームに縛られる」という選択は、開発者にとっては楽でも、経営者にとってはよくない戦略であり、会社の柔軟性と変化可能性に注目すべきだ
経営者の立場では、会社に柔軟性と変化可能性を与えるソリューションを選ぶべきで、代替案もなくSaaSに縛られるのは愚かだと思う
立ち上げ期や売上がないうちはSaaSよりプラットフォームを使うほうが有利で、成長してスケール段階に達したら長期的な技術変化まで考えるべきだ
自分はCloudflare Workersをよく使っており、コードもどこへでも移植できるように書いている
wrangler devでローカル実行も可能で、実際にpure node/bun/denoでも大きな修正なしに動かせるOP（投稿者）はSaaSそのものに反対しているわけではなく（実際、CloudflareやSupabaseのようなas a serviceソリューションを勧めている）、あまりに多くの提供者と契約・管理する運用コストや関係管理の負担を指摘しているのが要点だ
ベンダー数が少ないほど、依存関係が少ないほど運用は容易になるという話
実際、すべての機能を標準ライブラリだけで実装するのはあまりに理想論で、現実にはかなり難しい
何かを始めるときに複数のサービスを混ぜるのではなく、一つのプラットフォームを使ってみようという提案が核心だ
自分がCloudflareを好む理由は、バインディングを
fetchのように標準化しており、fetchがWebの世界でUnixパイプのように感じられるからだベンダーロックインを避けると言いながら、一つのプラットフォームに全面的に依存して、かえってもっと強く一社に自分を縛るのは皮肉だという見方
SaaSにも分散コストという「税金」があるからだ
むしろこの議論はオープンソース擁護に近いと見る
オープンソースとセルフホスト方式なら、文中で挙げられた大半の「税金（発見、登録、統合、ローカル開発に関するコスト）」は解消される
オープンソースのproduction tax（運用負担）は、エコシステムの活性化やプラグイン、モジュールのエコシステムで解決可能だと思う
（宗教とカルトの違いになぞらえて）データを標準フォーマットでエクスポートして離れられるなら、それはベンダーロックインではない
顧客は自分のデータを手にできれば被害者意識が薄れるが、それを不可能にしているSaaSが多すぎるという問題意識も語られている
現在は主にMITで公開配布し、重要な部分は非公開にしておく形で運用している
SaaSの限界は、ソフトウェアの「ほぼゼロに近い限界費用」から得られる恩恵を顧客が享受できなくしてしまう点にある
SaaS事業者もある程度はその利益を価格に反映して値下げするが、利用者が十分多く単価も高い段階になると、結局SaaS利用者のほうが損をする
とはいえ、スタートアップ初期に自前構築を選ぶのは無謀であり、「生き残ること」と「初期費用の最小化」が重要な段階ではSaaSは非常に賢い戦略だ
事業が成長し、SaaSが日常に深く組み込まれてから初めて、ロックイン、移管、切り替えコストの問題が発生する
SaaSの問題というのも、結局は成功の副作用なのだと思う
だからこそ、この種のSaaSモデルは非常に多い
年金のように繰り返し収益が入り、価格決定権まで持てる事業モデルはあまりにも魅力的だ