SaaS企業はなぜ「プロダクトはいいのに売れない」のか ── toB SaaS の人材インセンティブ構造

関連記事：

後編：

第1章：「プロダクトはいいのに売れない」の正体

toB SaaS企業で働いていると、こういう場面に出くわすことがある。

プロダクトはリリースされた。機能もそれなりに揃ってきた。なのに、ARRが思うように伸びない。導入しても使いこなされず、1年で解約される。

こうなったとき、まずプロダクトが疑われる。機能追加にリソースが投じられ、CSが手厚いフォロー体制を敷く。それでも数字が動かない。自分自身、プロダクト側から複数のSaaS企業に関わる中でこの光景を何度も見てきた。そしてある時点から、問題はプロダクトだけでも、営業だけでもないのではないかと考えるようになった。

プロダクト側では、顧客の業務構造を深く理解しないまま設計が進み、機能は揃っていても業務に刺さらないプロダクトが生まれる。ビジネス側では、決裁者レベルの商談を作れる人材が組織的に不足し、現場担当者レベルで完結する浅い導入が量産される。そしてどちらの側にも、それを修正できるマネジメント層が足りていない。

これらは個々の企業の努力不足ではなく、SaaS企業の人材を取り巻くインセンティブ構造に根本的な問題があるのではないか。

本稿では、ビジネス人材（セールス、CSM、マーケティング）とプロダクト人材（エンジニア、PdM）の両面から、SaaS企業になぜ構造的に必要な人材が集まりにくく、育ちにくいのかを整理する。

第2章：THE MODELの分業構造が生む「浅さ」

THE MODELとは何だったのか

THE MODELは、福田康隆氏がセールスフォース・ドットコムでの経験をもとに体系化した営業プロセスのフレームワークだ。マーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスの4部門が、リードの獲得から契約継続までを分業で回す。2019年に書籍化され、日本のSaaS企業に広く導入された。

ここで重要なのは、福田氏自身がこのフレームワークの「表面的な導入」を繰り返し警告していることだ。書籍の冒頭で福田氏はこう書いている──どの会社にもそのまま適用できるモデルなど存在しない、自分の会社にとっての「ザ・モデル」を創造することを目指してほしい、と。10万部突破記念のインタビュー（2024年）でも、組織体制や評価指標だけを単純にまねようと形から入るケースが目立つことへの懸念を述べている。

分業が生む「誰も顧客を一貫して理解していない」問題

にもかかわらず、多くのSaaS企業がTHE MODELを「分業の型」として導入した。マーケがリードを獲得し、ISがアポを取り、FSがクロージングし、CSMがオンボーディングする。各工程は「次に渡す」ことを目的に最適化されている。

この分業構造には合理性がある。工程ごとにKPIを設定し、ボトルネックを特定しやすくなる。ただし副作用もある。

各部門が自分のKPIに最適化した結果、顧客の業務課題を一貫して理解している人が組織内に誰もいないという状態が生まれやすい。マーケはリード数を追い、ISは商談設定数を追い、FSは受注額を追い、CSMはチャーン率を追う。どの工程も「顧客の業務構造を深く理解し、プロダクトがどう課題を解くかを翻訳する」という役割を明確に担っていない。

これは「THE MODELが悪い」という話ではない。THE MODELは分業の型であって、分業された各工程に必要なケイパビリティ（能力）を定義しているわけではない。問題は、型だけを導入して、各工程に求められるスキルの深さを設計しなかったことにある。

では、なぜスキルの深さが設計されなかったのか。それを次の章で見ていく。

第3章：SaaS企業の営業人材はなぜ集まりにくいのか ── ビジネス人材のインセンティブ構造

SaaS企業のエンジニア採用と営業採用はなぜ非対称なのか（仮説）

ここからは構造仮説を述べる。エンジニアとビジネス人材がスタートアップを選ぶ動機の差を、職種横断で直接比較した調査は見つからなかった。以下は、複数の環境で観察した傾向と断片的な調査データをもとにした仮説であり、「こう考えると複数の現象が一貫して説明できる」という構造的な推論として読んでほしい。

エンジニアやPdMがスタートアップを選ぶ理由には、大企業では得にくいものがある。ゼロからのプロダクト設計、技術選定の裁量、小さいチームでのスピード感、新しい技術スタックへの挑戦。Findyが2023年にエンジニア305名を対象に実施した調査では、「働いてみたい企業」の上位に技術力の高さで知られる企業が並んでおり、転職の決め手として「事業やプロダクトの将来性」が上位に挙がっている。技術的な環境と成長機会を重視する傾向が読み取れる。大企業の開発組織、特にSIerの開発現場では、実績のあるコードの使い回しやウォーターフォール型の工程管理が優先されやすく、エンジニア個人の技術的裁量は制限される傾向がある。スタートアップには、技術的な挑戦を求めるエンジニアを引きつける構造的な引力がある。

ではセールスやCSMはどうか。

興味深いのは、エンジニア向けには上記のような「なぜこの環境を選ぶのか」を問う転職動機調査が多数存在するのに対し、SaaS営業職を対象にした同種の調査がほとんど見当たらないことだ。あるのは「SaaS営業への転職は未経験者でも可能」「THE MODELの分業体制でスキルアップできる」といったエージェント発信のキャリア記事が中心で、「なぜ大企業ではなくスタートアップの営業を選んだのか」というリサーチ自体が少ない。動機の解像度の差自体が、この領域の構造的な未成熟を映しているように見える。

なお、ビジネス側の動機を直接裏付ける調査データには限りがある。AMBI（エン・ジャパン）がスタートアップ転職希望者1,000名に行った調査（2023年）では、転職理由の上位は「多様な経験を積みたい」「先進性のある事業に携わりたい」であり、「営業スキルの向上」に相当する選択肢は上位に入っていない。ただしこの調査は職種横断であり、エンジニアとビジネス人材の動機を直接比較できるものではない。この根拠の非対称は、仮説の信頼性を割り引く材料として認識しておいてほしい。

営業力を磨きたい人にとって、大企業の方が環境として優位な面が多い。大きな予算を持つ顧客、複雑な利害関係者を巻き込む商談、長期のアカウントマネジメント、経験豊富な上司からのフィードバック、体系化された育成プログラム。これらは大企業の営業組織に構造的に組み込まれている。

スタートアップの営業組織では、これらの多くが未整備だ。プロダクトは成熟途上で、顧客基盤は小さく、営業プロセスは整備中で、育成の仕組みが体系化されていないケースも多い。「営業スキルを高めたい」という動機でスタートアップを選ぶインセンティブは、エンジニアの場合と比べて構造的に弱いのではないか、というのがこの仮説の骨子だ。

スタートアップのビジネス職を選ぶ動機の構造

では、何がスタートアップのビジネス職を選ぶ動機になるか。

実際にSaaS企業の採用現場や転職エージェントの発信を見ると、ビジネス職の入社動機として最も多く挙がるのは事業やミッションへの共感だ。freeeの「スモールビジネスを世界の主役に」、SmartHRの「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。」──こうしたミッションに惹かれてSaaS企業を選ぶ人は少なくない。他にも、カルチャーへの共感、経営に近い距離で働ける経験、タイトル（肩書き）やストックオプションへの期待といった動機がある。これらは個人の選択として何も間違っていない。

ただし、ここに構造的な非対称がある。

エンジニアの場合、スタートアップを選ぶ主な動機──技術選定の裁量、新しいスタックへの挑戦、プロダクトをゼロから設計する経験──は、エンジニアとしての職能そのものの向上と直結している。スタートアップで働くことが、そのままエンジニアとしてのスキルの蓄積になる。

ビジネス人材の場合、主な動機──ミッション共感、カルチャー、裁量──は、それ自体は重要な選択理由だが、「営業力」や「顧客の業務構造を理解する力」の向上とは別の軸にある。ミッションに共感して入社しても、その環境で営業スキルが構造的に鍛えられるかどうかは別の問題だ。

つまり、ビジネス人材がスタートアップを選ぶ動機がないのではない。動機の軸が、職能の向上ではなく、環境や価値観に寄りやすい構造がある。そして、職能の向上が動機の中心にない環境では、組織として営業力を底上げする力学が働きにくい。

ここで論じているのは個人の能力の話ではない。どの環境にも優秀な人はいるし、スタートアップの営業で大きな成果を上げている人もいる。問題は、組織として「営業力の高い人材を引きつけ、育成する」インセンティブ構造がスタートアップには弱いのではないかという点だ。個人の奮闘で補えるうちはいいが、組織が拡大するにつれて、構造の弱さが数字に出始める。

SaaS営業採用の現況から見える傍証

SaaS営業に特化した転職エージェントが複数登場していること自体が、この構造を反映している。エムエム総研の調査（2025年1月）によれば、SaaS企業の採用で最も力を入れている職種はインサイドセールス（32.4%）で、フィールドセールス（26.1%）、マーケティング（25.2%）と続く。採用に力を入れているということは、裏を返せば充足していないということだ。

また、JACリクルートメントは「SaaS企業の営業への転職は未経験者でも増加している」としている。SaaS市場の成長に人材供給が追いついていないこと自体は健全な成長痛とも言えるが、問題は、未経験者が「THE MODELの型」の中に配置されたとき、顧客の業務構造を深く理解する機会が分業構造の中で失われやすいことだ。

SaaS企業のビジネス人材不足を生む三重の構造

ここまでの議論を整理すると、ビジネス人材のケイパビリティ不足は、3つの構造が重なって生まれている。

1つ目は、動機の構造だ。 前節で述べたように、営業スキルの向上を主な動機としてスタートアップを選ぶインセンティブが弱い。ミッション共感やカルチャーへの惹かれで入社する人材は優秀であっても、それが即座に「顧客の経営課題をPLの言葉で語れる営業力」を意味するわけではない。

2つ目は、採用プールの構造だ。 これは動機の話とは別の、より即物的な問題でもある。大企業の営業組織で実績を積んだ人材は、次のキャリアとしてもう一段大きな企業、外資、コンサルティングファームを選びやすい。スタートアップの知名度・報酬水準・安定性では、そもそも同じ採用プールで競争しにくい。結果として、スタートアップの営業採用は中小企業経験者や異業種からの転職者が中心になりやすい構造がある。

さらに、シリーズA〜Bの急拡大フェーズでは「人数を揃える」圧力が強まる。だがこのタイミングで必要なスキル──エンタープライズ営業の経験、業界知識、経営層との折衝力──を持つ人材は市場に限られており、採用ペースとスキル要件が噛み合わない。組織が20人から50人、50人から100人に拡大する過程で、ビジネス側のスキル密度がむしろ薄まっていく構造が生まれやすい。

そしてこの構造が最も深刻に現れるのが、営業マネジメント層の不足だ。大企業の営業組織では、10年以上の経験を持つ営業部長がメンバーの案件を見て修正し、育成する仕組みがある。スタートアップでは、営業マネージャー自身がSaaS営業歴2〜3年というケースも珍しくない。育成する側のケイパビリティがなければ、メンバーが入社後に成長する力学が組織的に働かない。

3つ目は、入社後の育成環境だ。 第2章で論じたTHE MODELの分業構造が、ここで効いてくる。仮にスキルの高い人材が入社し、マネジメントが機能していたとしても、分業構造の中でISは商談設定数を、FSは受注額を、CSMはチャーン率を追う体制になっていると、顧客の業務構造を一貫して理解する経験が各工程に蓄積されにくい。大企業の営業組織にある「大きな案件を通じて鍛えられる」「上司のフィードバックで修正される」といった育成の力学が、スタートアップの分業組織では構造的に働きにくい。

動機の軸がスキル向上に向いていない。採用プールが構造的に限られ、急拡大フェーズでスキル密度が薄まり、育成できるマネジメント層も不足している。そして入社後の分業構造がスキルの底上げを阻害する。この三重の構造が、SaaS企業のビジネス側のケイパビリティ不足を生んでいるのではないか、というのがこの章の仮説だ。

第4章：Web系エンジニアとSIer ── ドメイン知識の蓄積はなぜ差がつくのか

Web系エンジニアにドメイン知識が蓄積されにくい理由

第3章で、エンジニアがスタートアップを選ぶ主な動機は「技術的裁量」であり、それが職能の向上と直結していると述べた。この動機構造には裏面がある。技術的裁量を求めて集まったエンジニアにとって、顧客の業務構造を深く理解することは、技術的な挑戦とは別の種類の仕事だ。そして、その「別の種類の仕事」にインセンティブが設計されていないことが、プロダクト側のドメイン知識不足を生む構造に繋がっている。

toB SaaS企業の求人を見ると、エンジニアに求められるスキルセットはWeb系の技術スタック（Ruby、PHP、TypeScript、AWS等）が中心だ。SaaS企業の採用がWeb系エンジニアを主なターゲットにしている構造は、求人情報から明らかと言ってよい。実際、レバテックキャリアの解説では「WebエンジニアからSaaS業界に転職する場合」のケースが想定されているし、SaaS企業の中にはSIer出身者を歓迎する求人もあるが、主流はWeb系のキャリアを前提にした採用だ。

こうしたWeb系キャリアのエンジニアが持つ経験は、toC向けWebサービスや、ホリゾンタルSaaS（業界を問わず使える汎用的なSaaS）の開発が中心であることが多い。顧客企業の業務構造──会計、物流、製造、人事労務、営業管理といったドメインの深い理解──を持っているとは限らない。

近年はバーティカルSaaS（特定業界に特化したSaaS）が増えており、プロダクトの設計には業界固有の業務フロー、規制、商慣行の理解が不可欠になっている。だが、Web系のキャリアでこうしたドメイン知識を組織的に蓄積する機会は少ない。toC向けサービスでは「ユーザー体験」が設計の中心であり、ホリゾンタルSaaSでも業界固有の業務プロセスに踏み込む必要は限定的だったからだ。

SIerが持っている蓄積

対照的に、SIerはまさにこの領域を何十年もかけて組織的に蓄積してきた。NTTデータ、野村総合研究所、富士通、日立製作所といった大手SIerは、金融、製造、物流、公共といったインダストリーごとに専門部隊を持ち、業務知識を組織のナレッジとして体系化している。

SIerのエンジニアにとって、顧客の業務を理解することは仕事の一部だ。要件定義の段階で顧客の業務フローをヒアリングし、業務上の制約や例外処理を含めてシステムに落とし込む。この経験が10年、20年と積み重なることで、個人ではなく組織としてのドメイン知識が蓄積される。

ただし、SIerの「組織的な蓄積」がどこまで形式知として整理されているかには幅がある。業界テンプレートや要件定義書のパターンとしてドキュメント化されている部分もあれば、特定のシニアSEの経験と勘に依存している部分もある。蓄積の深さとその再現可能性は、SIerの中でも組織やインダストリーによって差が大きい。それでも、Web系のスタートアップがゼロからドメイン知識を積み上げるのとは、出発点のスケールが異なる。

これはSIerのすべてが優れているという話ではない。SIerには、技術的な柔軟性の低さ、多重下請け構造の弊害、レガシーシステムへの依存といった別の構造的課題がある。だが、「顧客の業務構造を深く理解してシステムを設計する」という能力の組織的な蓄積においては、Web系出身のエンジニアが個人の努力で追いつけるスケールの話ではない。

一方で、SaaS企業がSIer以上のドメイン蓄積を持つケースも存在する。freeeは会計・税務の領域で、SmartHRは労務手続きの領域で、プロダクトチームが業務構造を深く理解した上でプロダクトを設計している。

注目すべきは、これらの企業のドメイン知識がWeb系キャリアの延長から生まれたものではないことだ。freeeの佐々木大輔氏はGoogle出身だが、自身が中小企業の経理業務の煩雑さを直接体験したことが起業の原点にある。SmartHRの宮田昇始氏は、自社の労務手続きの非効率さから起業している。いずれも創業者自身がドメインのペインを原体験として持っていた。その上で、ドメインエキスパートの採用やCSからのフィードバックループを意識的に設計し、組織としてのドメイン蓄積を作っている。

つまり、SaaS企業がドメイン知識を深く持つことは不可能ではないが、Web系キャリアの延長では自然に蓄積されない。創業者の原体験、ドメインエキスパートの意図的な採用、CSからプロダクトへの構造的なフィードバック──こうした仕組みを設計して初めて成立する。そしてこの設計がないまま、技術的裁量だけを求めてエンジニアが集まると、第4章冒頭で述べたドメイン知識のギャップが構造的に生まれる。

SaaS企業のプロダクト開発におけるインセンティブ構造

エンジニアやPdMがスタートアップを選ぶインセンティブは「技術的裁量」や「プロダクトをゼロから作る経験」だと第3章で書いた。これは事実だが、裏を返すと「顧客の業務構造を深く理解する」ことにインセンティブが設計されていない、とも言える。

SaaS企業のエンジニアが「いいプロダクトを作りたい」と思うとき、その「いい」は技術的な完成度やUXの洗練さを指すことが多い。顧客の業務フローを観察して、どこに標準化の余地があり、どこは個社固有なのかを切り分ける──この種の作業は、エンジニアのキャリアにおいてあまり評価されにくい。

そしてここには、ドメイン知識の不足とは別のもう一つの問題がある。技術的な完成度への自信が、顧客理解の不足を覆い隠す構造だ。アーキテクチャは整っている、コード品質も高い、UXリサーチもやっている──こうした技術的な正しさが、「プロダクトとしては正しく作られている」という確信を生む。だが「正しく作られたプロダクト」と「顧客の業務構造に刺さるプロダクト」は別の話だ。技術的に正しいことがプロダクトとしての正しさを保証するわけではないのに、プロダクト側の内部ではその区別がつきにくい。

この構造が典型的に現れるのが、顧客要望の扱い方だ。CSや営業から上がってくる個社の要望が、そのままプロダクトバックログに積まれていく。だが、個社の要望と業界共通の構造的課題は別物だ。この切り分けには顧客の業務構造への深い理解が要るが、その理解がプロダクト組織の中に蓄積されていなければ、場当たり的な機能追加が量産される。プロダクト側からは「顧客の声を聞いて開発している」ように見えるが、実際には本質的な課題の整理ができていない──この力学はプロダクト組織の中にいると問題として可視化されにくい。

これは個人の驕りの問題ではなく、プロダクト組織の評価軸が技術的な完成度に寄っている構造が生む帰結だ。

結果として、プロダクト側にも「顧客の業務を深く理解しないままプロダクトを作る」構造が生まれる。機能は揃っているが、業務の構造に刺さっていないプロダクト。導入しても現場のワークフローに馴染まないプロダクト。第1章で書いた「プロダクトはいいのに売れない」の一因は、ここにもある。

さらに、エンジニアの市場価値の測られ方自体がこの構造を強化している。Web系エンジニアのキャリアにおいて、技術コミュニティでの評価──OSS貢献、技術ブログ、カンファレンス登壇、GitHub上のアクティビティ──は可視化されやすく、転職市場でも重視される。一方、「顧客の業務構造をどれだけ深く理解しているか」は外部から見えにくく、転職時のアピール材料にもなりにくい。ドメイン知識への投資がキャリア上のリターンに繋がりにくい以上、エンジニア個人がそこに時間を割くインセンティブは構造的に弱い。これはエンジニア個人の志向の問題ではなく、技術コミュニティと転職市場が作り出している評価構造の問題だ。

SaaS企業のプロダクト側マネジメント層が不足する構造

第3章でビジネス側の営業マネジメント層の不足を論じたが、これはプロダクト側にも当てはまる。

プロダクトの設計をドメイン知識の観点から方向付けられるエンジニアリングマネージャーやVPoEが、スタートアップには少ない。技術的な意思決定──アーキテクチャ、技術スタック、開発プロセス──を導けるマネージャーはいても、「このプロダクトは顧客の業務構造のどこを抽象化すべきで、どこは個社対応にすべきか」を判断できるマネジメント層は限られる。SIerであれば、業界ごとのプロジェクトを何十件も経験したシニアSEやアーキテクトがこの役割を担うが、Web系キャリアのマネージャーにはその蓄積がない構造は、メンバー層と同じだ。

ビジネス側もプロダクト側も、メンバーのスキル不足だけでなく、それを修正し方向付けるマネジメント層の不足が問題を再生産している。

ここまでの議論を整理すると、プロダクト側のドメイン知識不足もまた、複数の構造が重なって生まれている。Web系キャリアの出自がドメイン蓄積と構造的に合わないこと、技術コミュニティと転職市場の評価構造がドメイン知識への投資インセンティブを弱めていること、そしてマネジメント層も同じキャリア構造にあるため修正の力学が働かないこと。第3章で論じたビジネス側の三重構造と対称ではないが、こちらも複数の構造が連鎖して問題を再生産している。

第5章：SaaS企業の商談が決裁者に届かない構造

SaaS企業のビジネス側とプロダクト側の構造問題が合流する場所

第3章と第4章で見たビジネス側・プロダクト側の問題は、**「決裁者に届かない」**という一点で合流する。

DXプロダクトの導入は、業務プロセスの変革を伴う。変革である以上、導入先企業の経営層や事業責任者レベルの意思決定が必要になる。現場担当者だけで「便利だから使いましょう」で完結するツールではない。

ここで一つ区別が必要だ。PLG（Product-Led Growth）やフリーミアムのモデルでは、「まず現場担当者に使ってもらい、利用が広がってからエンタープライズ契約に引き上げる」という設計を意図的に選んでいる。この場合、現場レベルでの導入はGo-to-Market戦略の第一段階であって、人材の問題ではない。

問題になるのは、業務プロセスの変革を伴う提案をしたいのに、人材構造のせいで決裁者に届かず、現場担当者レベルに留まってしまうケースだ。意図してボトムアップ導入から入るのと、決裁者に届かないから結果的に現場止まりになるのでは、構造がまったく異なる。本稿が論じているのは後者だ。

ところが、実際に顧客と接しているセールスやCSMが、経営層と対等に議論できるケースは構造的に限られている。大企業の営業経験がなく、顧客の業界構造を深く理解しておらず、経営課題をPL/BSの言葉で語れない。結果として、商談が現場担当者レベルで完結する案件ばかりになる。

現場担当者レベルで入った案件は、組織的なコミットメントが弱い。予算が限られ、業務プロセスの変更を伴う本格導入に至りにくい。そして「使ったけど成果が見えない」「予算見直しで切られた」という形でチャーンする。

この構造の傍証として、SaaS企業のACV（年間契約額）とチャーン率の関係がある。KeyBanc Capital Markets & Sapphire Venturesの2024年SaaS Surveyでは、ACVが高い企業ほどGross Retention Rateが高い傾向が報告されている。ACVが高い案件では、導入に際して決裁者レベルの意思決定が介在しやすく、組織的なコミットメントや予算の裏付けが伴いやすい。一方、現場担当者レベルで完結する低ACV案件は、予算削減や担当者の異動といった外部要因でチャーンしやすい構造がある。ただし、ACVとRetentionの関係にはプロダクトのフィットや業界特性など複数の要因が絡んでおり、決裁者の関与だけで説明できるわけではない。

一方、プロダクト側も、顧客の業務構造を十分に理解しないまま設計しているため、決裁者が「これは投資に値する」と判断できるだけの構造的な価値提案が弱い。「便利になります」「効率化できます」ではなく、「御社の○○プロセスの構造的課題を、こう解きます」と語れるプロダクトになっていない。

ビジネス側は決裁者に届く営業ができず、プロダクト側は決裁者を納得させる構造的な価値を設計できていない。この両方が重なったとき、SaaS企業は「売れない」「解約される」というループに入る。

第6章：BPaaS（Business Process as a Service）とFDE（Forward Deployed Engineer）── 対症療法の構造

売れない、解約される。この課題に対して、SaaS企業が選ぶ対症療法がある。

先に広がったのはBPaaSだ。SaaS単体での成長が頭打ちになった企業が、プロダクト提供に加えて業務プロセスの運用代行を行うモデルに軸足を移すケースが増えている。より最近になって注目を集めているのがFDE（Forward Deployed Engineer）で、Palantir由来のこの概念が日本のSaaS界隈でも語られるようになった。FDEについては前回の記事で詳しく論じた。

どちらも、第3章〜第4章で論じた人材構造の問題を直接解決するのではなく、その帰結を後工程で吸収しようとする対症療法だ。順に見ていく。

BPaaS（Business Process as a Service）：スケーラビリティを手放す代わりの現実解

BPaaSは、SaaSプロダクトの提供に加えて、業務プロセスそのものの運用代行を行うモデルだ。CSM（カスタマーサクセス）の延長として、「何を売っているかが明確」という点では後述するFDEより筋が通っている。

日本のエンタープライズ顧客は、SaaS導入後に業務プロセス自体を変える必要がある場合が多い。CSMの範囲では収まらないから、「業務ごと回します」というBPaaSに発展する。日本市場の現実に即したモデルではある。

ただしBPaaSには、SaaSの本質的な強みを手放すという代償がある。SaaSの価値は限界費用の逓減にある。成熟したSaaS企業の粗利率は70〜80%が業界標準とされており、ベストインクラスでは80%を超える。顧客が増えても、プロダクトのコストはほぼ増えない。BPaaSは売上に人件費が比例するため、粗利率は大きく下がる。BPO業界の粗利率は一般に28〜35%程度とされている。SaaSの評価指標（ARR、NRR、粗利率）で測れなくなり、SaaS的なマルチプルでの評価は諦める必要がある。

この代償は数字だけの話ではない。BPaaSモデルに移行すると、組織内の人材配置の力学そのものが変わる。SaaSモデルでは、エンジニアリングとプロダクトに組織のリソースが集中する。BPaaSモデルでは、業務を回すオペレーション人材の確保と管理が中心課題になる。するとどうなるか。採用ポジションの重心がオペレーション側に移り、プロダクト改善に割けるリソースが相対的に減る。プロダクトが改善されないから、ますます人で埋めるしかなくなる。BPaaS化は一方通行の構造を持っている。

さらに、BPaaSは顧客の業務プロセスに深く入り込むことで高いスイッチングコストを生む一方、その知見がプロダクトに還元されるかどうかは組織の設計次第だ。オペレーション部門が日々の業務で得る顧客の業務知識は膨大だが、それをプロダクトチームが吸い上げてプロダクト設計に反映する仕組みがなければ、「人で回す」部分は永遠に人で回し続けることになる。BPaaSを戦略として選ぶ場合、この「知見の還流」を意識的に設計できるかどうかが、対症療法に留まるか事業モデルとして成立するかの分岐点になる。

FDE（Forward Deployed Engineer）：プロダクトの抽象化不足を人で埋める

FDEはPalantir由来の概念で、エンジニアを顧客先に常駐させてプロダクトのカスタマイズや導入を推進するモデルだ。Palantirの数字や当事者の警告、導入条件の詳細は前回の記事で論じたので、ここでは本記事の文脈に即した論点に絞る。

FDEが必要になるのは、プロダクトが顧客の業務構造を十分に抽象化できていないからだ。第4章で論じたプロダクト側のドメイン知識不足の直接的な帰結でもある。日本市場ではこの構造がさらに厳しくなる。各企業が独自の業務プロセスを温存する傾向が強く、A社で得た知見がB社では使えない。結果として、FDEモデルはSIerと同じ構造──個社ごとの要件定義、カスタマイズ、保守運用──に落ちていく。しかし、その領域ではSIerが何十年もかけて蓄積してきた業務知識と組織体制がある。FDEを数ヶ月送り込んだ程度のSaaS企業が同じ土俵で戦うのは構造的に難しい。

BPaaSとFDEが対症療法になる構造

FDEもBPaaSも、本来セールスとCSMが果たすべき機能を、別の手段で補填しようとしている点では共通している。

セールスが顧客の業務課題を深く理解して提案できれば、エンジニアを顧客先に送り込む必要はない。CSMが顧客のワークフローに寄り添い、「この部分はプロダクトで標準化すべき、この部分は御社固有だから別の方法で」と切り分けるコンサルティングができれば、業務を丸ごと代行する必要もない。

そして、プロダクト側が顧客の業務構造を深く理解して設計していれば、個社ごとのカスタマイズも、業務代行も、そもそも必要な範囲が大きく縮小する。

ただし、BPaaSやFDEを一律に「失敗」や「劣化」と見なすのは正確ではない。Toastのように、ソフトウェアに決済・ハードウェア・導入支援を組み合わせたバーティカルモデルを戦略的に選択し、成功している企業もある。BPaaSが「SaaS単体ではなくソフト＋オペレーションで顧客価値を最大化する」という戦略であるなら、それは対症療法ではなく事業モデルの選択だ。

問題になるのは、戦略的に選んだのではなく、人材構造の帰結として流れ着いた場合だ。「セールスとCSMのケイパビリティが足りないから人を貼り付けるしかない」「プロダクトのドメイン理解が浅いからエンジニアを送り込むしかない」──この場合、BPaaSやFDEは戦略ではなく、構造的な弱さの補填になっている。そして補填を続ける中で、根本にある人材のインセンティブ構造には手が届かないまま時間が過ぎる。

第7章：構造のまとめ ── なぜこれが解きにくいのか

本記事で論じた構造を整理する。

起点：人材のインセンティブ構造（仮説）
ビジネス人材（セールス・CSM）にとって、営業スキルを磨く環境として大企業の方が構造的に優位な面が多い。プロダクト人材（エンジニア・PdM）にとって、スタートアップは技術的裁量の面で魅力的だが、顧客の業務構造を深く理解するインセンティブが設計されにくい。これに加えて、採用プールの制約、マネジメント層の不足、THE MODELの分業構造が重なる。

帰結として考えられるもの：
ビジネス側は、決裁者レベルの商談を作る力が組織的に不足しやすい。プロダクト側は、業務構造に刺さるプロダクト設計の知見が蓄積されにくい。結果として、現場担当者レベルで完結する浅い導入が量産され、成果が出ず、チャーンする。

チャーンの原因を「プロダクトの問題」と捉え機能追加やUI改善に投資する、あるいは「導入支援の問題」と捉えBPaaSやFDEで後工程を補填する──これらの打ち手が選ばれやすい構造がある。もちろん、これらが人材のインセンティブ構造だけで説明できるわけではない。SaaS市場がまだ若いこと、日本のIT営業市場がSIer中心であること、エンタープライズ営業の経験者自体が市場に少ないことなど、複数の要因が絡んでいる。本記事で提示したのは、それらの中でもあまり語られていない「人材のインセンティブ構造」という切り口だ。

なぜ解きにくいのか

この構造が解きにくいのは、個社の努力だけでは変えられない市場構造が含まれているからだ。

スタートアップが「優秀な営業人材を採りたい」と思っても、報酬体系、育成環境、キャリアパスの面で大企業と競争する構造的なハンデがある。エンジニアのように「この環境でしか得られない経験」を営業職に提供することが構造的に難しい。

プロダクト側のドメイン知識の蓄積も、組織として時間をかけて積み上げるものであり、採用で一気に解決できるものではない。ただし、freeeが会計領域で、SmartHRが労務領域で深いドメイン知識をプロダクトに組み込んでいるように、SaaS企業がSIerを超えるドメイン蓄積を持つケースも存在する。できないという話ではなく、意識的にその構造を作らなければ自然には蓄積されない、という話だ。

そして厄介なのは、この構造が自己診断を誤らせることだ。チャーンが起きたとき、課題設定の主導権はエンジニアリング組織が握りやすい。スタートアップの中で最も言語化能力が高く、課題を構造的に整理して経営に伝える力があるからだ。一方、ビジネス側のケイパビリティ不足は、ビジネス側自身がそれを構造的に言語化できないから、課題として上がりにくい。結果として、打ち手の議論がプロダクト側の視点に偏りやすく、根本にある人材のインセンティブ構造には手が届かないまま時間が過ぎる。

「プロダクトの問題」として処理され続ける限り、この構造は再生産される。

本稿に処方箋はない。そもそも筆者にそれを書ける立場がない。ただ、構造を正確に認識することには意味があると思っている。「なぜ売れないのか」「なぜ解約されるのか」をプロダクトの問題として矮小化せず、人材とインセンティブの構造として捉えること。少なくともそこが、的外れな打ち手に投資し続けることを止める出発点になるのではないかと思う。

2026年3月