- SaaSモデルはかつて 「必要な分だけ支払い、技術ではなくビジネスに集中せよ」 という約束でIT業界を説得したが、実際には顧客を ロックイン(lock-in) する構造へと変質した
- 主要ベンダーは顧客満足よりも 継続課金の維持とデータ収集 に重点を置き、「カスタマーサクセスマネージャー」さえも 離脱防止のための役割 に過ぎない
- 業界全体が 「ベストプラクティス(best practice)」 の名の下に変化と革新を避けた結果、画一的で凡庸なソフトウェア生態系 を量産している
- SaaS市場は 1980年代のアメリカのショッピングモール のように過度に統制され予測可能な構造へと変わり、大規模プラットフォームが 大家と店舗 の役割を同時に担っている
- 真の解決策は、誰もが使う同一のシステムではなく、組織に合った情報システム を構築することであり、それはセルフホスティングのような代替的アプローチで実現できる
SaaSモデルの約束と現実
- SaaSは当初、「必要な分だけ支払う(pay as you go)」、「技術よりビジネスに集中」 という理想を掲げ、IT運用の効率化を約束した
- ユーザーは 資本と時間を節約 でき、技術管理の負担を減らせる というメッセージで説得された
- しかし実際には、Microsoft、Google、Intuit などの主要ベンダーが 顧客中心より顧客従属 を優先する構造へと発展した
- あらゆるやり取りの後に顧客満足度調査を実施するが、これは ビッグデータ収集 のための別の手段にすぎない
- 調査結果は二次的で、実際には 顧客がとどまり、支払い続けること だけを望んでいる
- 収集されたデータは 周辺部分の漸進的改善 のためにしか活用されない
カスタマーサクセスマネージャーの逆説
- ほぼすべてのSaaS企業が カスタマーサクセスマネージャー(Customer Success Manager) という役割を設けている
- 彼らはアカウントに割り当てられ、オンボーディングを支援し離脱を防ぐ 役割を担う
- 「成功」とは組織の実際の成功ではなく、製品を十分に使わせること にすぎない
- 顧客が有用だと感じる製品を作ること自体は悪くないが、SaaSのビジネスモデルは時間とともに 顧客の成功ではなく服従(submission) と 惰性(inertia) に基づく構造へと変質した
- ある時点に達すると、顧客基盤と製品が大きくなりすぎて変化が不可能 になる
Safety in Numbers ― 数の安全性という錯覚
- 多くの企業がSaaSを採用する理由は、「みんながやっているから」 という心理と ネットワーク効果 にある
- 他の誰もがやっているなら、それは良いか、少なくとも 十分に良い最小抵抗の道 になる
- ネットワーク効果にも価値はあるが、数が安全なのはある地点まで だ
- 数は目に見えないリスク、とりわけ ブラックスワン型のリスク を覆い隠す
- まれだが壊滅的なリスクは、あまりに希少で、しかも潜在的に破滅的であるため、誰も真剣に考えない
- バックアップ、災害復旧、事業継続システムは 単一システム障害からは保護 できても、コンテキストやノウハウの喪失 からは守れない
- 本当の問題は損失ではなく 蓄積 にある
- あまりにも多くのプログラム、API、統合、そして洗練されたシステムに偽装された 過剰な複雑性
- コンテキストを復元するシステムは存在しないが、成功している組織は データではなくコンテキストに依存 している
- テラバイト級のデータも、なぜそのデータを保持するのか、何を意味するのか、どう活用すべきか が分からなければ意味がない
情報過剰と意思決定の罠
- 情報とコンテンツは 無限で確率的 であり、必ずしも予測可能ではない
- より多くの情報がより良い意思決定につながるのではなく、単に より多くのデータ につながるだけだ
- これは 知らないことへの恐れとリスク を餌にしている
- 意思決定を下す前にすべての情報を知ることはできないが、未知と不確実性に直面したときの「ベストプラクティス」採用 は心地よい安心毛布を与えてくれる
Undifferentiated Best Practices ― 差別化なきベストプラクティス
- 業界全体に 「ベストプラクティス」テンプレート への盲目的な信頼がある
- ベストプラクティスの問題点は、世界が変化をやめたと仮定している ことだ
- 現実の世界は静的ではなく、絶えず変化し、継続的な改善と進化 を必要としている
- テンプレート化されたベストプラクティスを盲目的に採用することは、最高になる道ではなく平凡な平均へ向かう道 だ
- 「車輪の再発明をするな」という論理が悪用される
- すでに解決済みの問題に時間と労力を費やす必要はない、という主張だ
- 実際には、競合との同等性(parity)を達成することにしか長けていない
- このようなアプローチは 平板な凡庸さ(bland mediocrity) を量産し、真の差別化や発展を妨げる構造として機能する
Bland and Generic Applications ― 画一化されたソフトウェア生態系
- 商用ソフトウェアの環境を見ると、数千のカテゴリに数千のアプリケーションがあるが、それでも ノート作成やカレンダーアプリ の別バリエーションを提供しているにすぎない
- 一部のプログラムはより美しかったり直感的に感じられたりするかもしれないが、問題の定義とアプローチは似通っている
- ソフトウェアが 同じ解決可能な問題を繰り返し解いている 理由は、残された課題が技術で解決するには 本当に難しいから だ
- コミュニケーションとコラボレーションは、デジタル化を拒むニュアンスと機微 に満ちている
- これはSaaS企業に限らず、ほとんどのソフトウェア企業が製品のマーケティングと販売のために SaaSの流れに加わった
- 有料メンバーシップへ誘導するため、十分な機能だけを提供する 無料版
- その後には good, better, best という 標準的な3つのサブスクリプション選択肢 が待っている
- コミュニケーションツールを追加しても コミュニケーションの質は向上せず、単にコミュニケーション量が大幅に増えて ノイズと疲労感の増加 を招くだけだ
Let’s Go to the Mall ― SaaSと1980年代ショッピングモールの類似性
- SaaSは 1980年代のアメリカのショッピングモール のような技術になった
- 過度に高価で予測可能で、どのモールでも 商品はほとんど同じ だ
- これはダイナミックな市場ではなく、非常に統制された市場 である
- landlord がプラットフォームを整備し、小売業者たちはこの素晴らしい立地へ群がって 莫大な利益と規模の優位 を得る
- モールの賃料を負担できる小売業者は、非常に統制された体験 を提供する
- 1980年代のショッピングモールは 大胆な実験やリスクテイクの場ではなく、リスクとは賃貸契約書に署名することだった
- GoogleとMicrosoftはモールの店舗であると同時に、landlordとしてモール体験を統制 している
- Appleは独自のショッピングモールを運営しており、より輝いてはいるが別物ではない
- 今日の物理的ショッピングモールは、Apple Storeが集客しなければゴーストタウンになるだろう
- ある時点で文化はショッピングモール体験に 飽きてしまい、アメリカ全土には 見捨てられたショッピングモール があふれている
- このモデルはある地点までは機能するが、流行は変わる
- 丁寧にキュレーションされた商品を持つ 小さな店 が現れ、人々を引きつける
- 情報技術の未来も 非常によく似ている
- 重要なのは、他の誰もが持っているのと同じシステムを持つことではない
- 重要なのは 自分たちに合った情報システム を持つことだ
1件のコメント
Hacker Newsの意見
消費者が食べ物や服の**「本当の価格」を払いたがらないのと同じように、ソフトウェアの本当の価格も支払いたがらない現象について語っている
以前はPostmanのようなツールを一度に$40で買えたが、今ではサブスクリプションで$30/月を払う構造になっている
SaaSには常に最新バージョンを維持できるという利点がある
しかしソフトウェア開発は本質的に経済的に高コストな作業**であり、オープンソース貢献者の無償労働のおかげでその価値が過小評価されている
この20年間で膨大な量のソフトウェアが作られたが、革新的なブレークスルーはほとんどなかったように感じる
コンピュータ性能は10〜20倍良くなったのに、むしろ遅く複雑になった点を指摘している
今日のソフトウェアはしばしば消費者に半ば強制的に提供され、データ収集や監視に使われるトロイの木馬の役割を果たしていると批判している
消費者は食べ物・水・住居にはお金を払うが、ソフトウェアには払いたがらない
妥当な規模の投資とチームであれば、単なるcurl GUIにAdobe並みの料金を課す必要はなかっただろうと述べている
SaaSがオープンソース貢献者により多くの報酬を与えているわけでもないと指摘している
その会社はすでに複数のクライアントを渡り歩いてきており、Postmanも結局同じ道をたどっているとしている
「AWSが落ちた」といった大げさな投稿が消え、正常な議論に戻ってほしいと願っている
昔はオンプレミスサーバーでも十分に運用でき、今よりはるかに効率的だったと振り返っている
今では開発者もAWSを理解しなければならず、セキュリティリスクやLLMを通じた知識流出まで心配しなければならない時代になったと嘆いている
技術の進歩がかえってディストピア的な開発環境を作り出したと感じ、シンプルで直感的なUXを懐かしんでいる
大半の企業では、メール、カレンダー、VPN、CRMなどで**「十分に良いSaaS」**を使うのが合理的だと主張している
Google WorkspaceやHubSpot、Power BIのようなツールは、過去のオフライン製品よりはるかに優れていると感じている
小さな画面に多くの情報を載せにくい点は理解できるが、それでもなおぎこちないと感じている
SaaSのセキュリティ機能を階層ごとに人質のように売る構造を批判している
フィッシングに引っかかるのは会社の問題であって、ベンダーの責任ではないと述べている
SaaSの議論で欠かせない**「海賊版（piracy）」**の問題を提起している
インストールが不要である点が導入を容易にした
知的財産の盗用はありふれているが、データには結局自由になろうとする性質があると付け加えている
SaaS自体は悪い概念ではなく、必要な分だけ費用を払う構造としては合理的だと説明している
問題はサブスクリプションモデルが過剰になり、ベンダーロックインによってデータ移行が不可能になる点だ
AWSの**「モート（moat）」戦略**のように、ユーザーが自ら作った依存関係のために抜け出せなくなる
したがって中核機能はSaaSに依存すべきではないと助言している
SaaSの否定的な面ばかりを強調するのは不均衡だと指摘している
B2B SaaSは競争が維持される限り、顧客に大きな利点をもたらし得る
ベンダーは離脱（churn）を防ぐために製品を継続的に改善し、新機能を無料で提供しようとする動機を持つ
一方で、旧式のオンプレミスソフトウェアは保守契約が高価で品質も低かったと振り返っている
結局のところ、購入者は妥協点を選ぶしかないと述べている
PhotoshopやAutoCADのような製品は、短期サブスクリプションの選択肢があればフリーランサーに有用だっただろうと述べている
しかし現実には、サブスクリプションを自由にオンオフするのは難しいという
一度の購入で十分だと強調している
SaaSの根本的なロックインは、二つの要素の組み合わせから来ると分析している
この二つを分離（unbundle）すべきだと主張し、前者はすでにNixが解決できる可能性があると説明している
残る課題は、セルフホスティング基盤のサポート型ビジネスモデルを作ることだ
技術的には解決できると信じているが、まだ実現されたことはないとしている