レベニューシェアの相場は？割合・売上原価の考え方とWebサービス開発で見るべき判断軸

レベニューシェアとは

レベニューシェアとは、事業で発生した売上や利益を、あらかじめ決めた割合で複数の関係者が分け合う契約形態です。

Webサービスの開発では、開発会社が初期費用の一部を抑える代わりに、公開後の売上から一定割合を受け取る形で使われることがあります。弊社セルバでもレベニューシェアで開発しているサービスがあります。
求人サイト、マッチングサイト、比較サイト、会員制サービスなど、公開後に継続的な売上を見込む事業で検討されやすい方法です。

誤解されがちですが、レベニューシェアは「初期費用を安くできる便利な契約」ではありません。
売上が立つまでのリスクを誰が負うのか、集客を誰が担当するのか、どこまで開発会社が関与するのかによって、契約の意味は大きく変わります。

売上や利益を分ける契約

レベニューシェアには、大きく分けて「売上」を分ける形と、「利益」を分ける形があります。

売上を基準にする場合は、入金額や決済額に対して一定割合を支払います。
計算しやすい一方で、広告費や人件費、外注費などを差し引く前に支払いが発生するため、運営側の利益が残りにくくなるケースもあります。

利益を基準にする場合は、売上から一定の費用を差し引いた後の金額を分けます。
ただし、何を費用として認めるのかを決めておかないと、後から認識がずれます。

たとえば、以下のような費用をどこまで差し引くかで、分配額は変わります。

同じ「30％」という割合でも、売上に対する30％なのか、利益に対する30％なのかで、実際の負担はまったく違います。

割合だけを見るのではなく、何を基準に分ける契約なのかを先に確認する必要があります。

開発費を抑える手段にもなる

Webサービスを立ち上げる際、初期開発費は大きな負担になります。
特に、データベース、検索機能、会員登録、管理画面、掲載情報の登録・編集、問い合わせ、決済、メルマガ配信などの機能を持つサイトは、Webシステムの領域になり、単純なホームページ制作とは異なります。
機能が増えるほど設計範囲も広がり、開発費も開発期間も大きくなります。

そこで、初期費用を抑える方法としてレベニューシェアを検討するケースがあります。
たとえば、事業会社が企画や営業を担当し、開発会社がシステム開発を担当する形です。
開発会社は初期費用を一部抑える代わりに、公開後の売上から一定割合を受け取ります。

この形が成立するには、開発会社側にも「売上が立つ見込みがある」と判断できる材料が必要です。
単に「アイデアはあるので作ってほしい」という段階では、開発会社にメリットが薄いため承諾されにくいです。

成果が出るまでの負担もある

レベニューシェアは、売上が出れば双方にメリットがあります。しかし、公開後すぐに売上が立つとは限りません。

求人サイトであれば、掲載企業を集める必要があります。
マッチングサイトであれば、利用者と事業者の両方を集めなければなりません。
比較サイトであれば、掲載情報の質や数、送客先との関係づくりも必要になります。

よくある失敗は、システムを作れば自然にユーザーが集まると考えてしまうことです。
実際には、公開後に次のような作業が発生します。

開発会社がこれらすべてを担うのか、事業会社が担うのかによって、レベニューシェアの割合は変わります。
開発だけを担当する場合と、集客や運営改善まで関わる場合では、同じ割合で考える方が不自然です。

相場はどう決まるか

レベニューシェアの相場は、業界や契約内容によって変わります。

Webサービス開発の場合、「売上の何％が一般的」と簡単に決めるよりも、初期費用、開発会社の負担範囲、公開後の運営体制、事業の収益性を見て考える方が現実的です。

同じWebサービスでも、すでに顧客基盤がある会社が始める場合と、ゼロから集客する場合では、開発会社が負うリスクは異なります。

一律の割合は決めにくい

レベニューシェアの割合は、10％、20％、30％のように数字だけで比較されがちですが、実務では「何に対する割合か」「どこまでの業務を含むか」で意味が変わります。
たとえば、以下の2つはどちらも「レベニューシェア30％」ですが、内容は大きく違います。

前者は計算がシンプルですが、運営会社側の資金繰りを圧迫しやすくなります。
後者は利益を見て分配できますが、どの費用を差し引くかで揉めやすくなります。

また、開発会社が初期費用をどれだけ負担するかでも割合は変わります。
初期費用を通常通り支払うなら、レベニューシェアの割合は低くなるのが自然ですが、開発会社が初期費用を大きく抑えるなら、公開後の取り分は高くなるのが自然です。

相場を考えるときは、割合そのものよりも「誰がどのリスクを負うか」を見る方が判断しやすくなります。

初期費用の有無で変わる

Webサービス開発のレベニューシェアでは、初期費用をどう扱うかが大きな分岐点になります。
主な形は次の3つです。

初期費用をまったく払わない形は、事業会社にとって魅力的に見えますが、開発会社側から見ると、開発人員を投入しても売上が立たなければ回収できません。
そのため、初期費用なしのレベニューシェアが成立するには、少なくとも次のような材料が必要です。

「サイトを作れば売上が出るはず」という段階では、開発会社が費用を負担する理由がありません。

役割分担で率が変わる

レベニューシェアの割合は、開発会社と事業会社の役割分担でも変わります。

たとえば、開発会社が担当する範囲がシステム開発だけであれば、公開後の売上に対する取り分は限定的になるのが自然ですが、SEO設計、運営改善、機能追加、集客施策まで関わるなら、開発会社側の関与は深くなります。

役割分担を決めるときは、次のように整理すると考えやすくなります。

項目	主に誰が担うか
事業企画	事業会社
初期開発	開発会社
掲載企業の営業	事業会社
SEO設計	開発会社または双方
コンテンツ作成	事業会社または外部
保守運用	開発会社
機能改善	双方で協議
広告費負担	事業会社

表にしてみると、意外と「開発会社に期待していること」と「自社で担当すべきこと」が混ざっていると気づくことがあります。
レベニューシェアの交渉では、割合の話に入る前に、まずこの役割分担をそろえる方が話が進みます。

割合を決める前の確認点

レベニューシェアの契約では、割合を先に決めたくなりますが、数字を決める前に確認すべきことがあります。
特にWebサービスの場合、売上が出るまでの道筋があいまいなまま契約すると、公開後に「誰が集客するのか」「追加開発は誰が負担するのか」「売上の定義は何か」で認識がずれます。

契約前にすべてを完璧に決める必要はありませんが、最低限の前提をそろえておかないと、せっかく公開しても運営が止まりやすくなります。

誰が集客を担うのか

Webサービスは、公開しただけでは使われません。
求人サイトなら求人企業と求職者、マッチングサイトなら提供者と利用者、比較サイトなら掲載事業者と閲覧者を集める必要があります。片方だけ集まっても、サービスとしては動きません。

たとえば、求人サイトで求職者ばかり集まっても、掲載求人が少なければ応募は増えませんし、求人を集めても求職者が来なければ、掲載企業は継続しません。
このとき、集客を誰が担うのかを決めておかないと、公開後に次のような会話が起きます。

このズレは、レベニューシェア契約では特に大きな問題になります。
売上が立たなければ、双方に収益が入らないためです。

レベニューシェアを組むなら、集客責任をあいまいにしたまま契約しない方が安全です。

追加開発の負担を決める

Webサービスは、公開後に必ず改善点が出ます。

ユーザーが使い始めると、検索条件を増やしたい、管理画面の項目を変えたい、メール通知を追加したい、決済方法を増やしたい、といった要望が出てきます。
問題は、その追加開発の費用を誰が負担するかです。

初期開発費を抑えたレベニューシェア契約では、開発会社が初期費用を負担をしている場合が多いです。
その状態で追加開発まで無償で求めると、開発会社側の負担が大きくなりすぎます。
一方で、事業会社から見ると、売上がまだ十分でない段階で追加費用が発生すると、資金繰りが苦しくなります。

そのため、契約前に次のような線引きをしておくと、後から揉めにくくなります。

特に、管理画面や検索条件は後から変更が入りやすい部分です。
最初から細かく作り込みすぎるのではなく、公開後の改善余地を残す設計にしておく方が進めやすくなります。

売上の定義をそろえる

レベニューシェアでは、「売上」という言葉の定義をそろえる必要があります。

たとえば、月額課金型のサービスであれば、入金ベースなのか、請求ベースなのかを決めます。
成果報酬型のサービスであれば、申し込み時点なのか、成約時点なのか、入金確認後なのかを決めます。
広告収益がある場合は、広告媒体からの入金額を基準にするのか、手数料を差し引いた金額にするのかも確認が必要です。

売上の定義があいまいだと、売上が立ち始めてから認識の違いが表面化します。
初期段階では小さな差でも、月商が大きくなると金額差も大きくなります。

売上の定義では、最低限次の点を確認しておくとよいです。

契約書に落とし込む際は、会計処理や税務上の扱いも含めて、専門家に確認した方が安全です。

売上原価として考える場合

レベニューシェアの支払いを売上原価として考えてよいのかは、契約内容や会計処理によって変わります。

会計上の分類は、会社の処理方針や税理士・会計士の判断も関係するため、ここでは会計処理を断定せず、事業計画を作るうえでの見方として整理します。
実務上は、レベニューシェアの支払いが売上に連動して発生するなら、収支シミュレーション上は変動費として扱っておく方が現実に近くなります。

会計処理は契約で変わる

売上原価とは、商品やサービスを提供するために直接かかった費用を指します。

Webサービスの場合、レベニューシェアの支払いが売上原価にあたるかどうかは、契約の中身によって変わります。
たとえば、仕入れやサービス提供に直接関係する支払いとして扱うのか、業務委託費や販売手数料のように扱うのかで、処理が変わることがあります。

ここを曖昧にしたまま収支計画を作ると、後から利益率の見え方が変わります。

たとえば、月間売上が500万円あり、開発会社へのレベニューシェアが売上の30％だとします。この場合、150万円が毎月の支払いになります。
さらに広告費、サーバー費、営業人件費、運営人件費がかかると、手元に残る利益は想像より小さくなることがあります。

レベニューシェア率は、売上規模が大きくなるほど利益に強く影響します。

事業計画では変動費として見る

会計上の分類とは別に、事業計画ではレベニューシェアを「売上に連動して増える費用」として見ておくと判断しやすくなります。

固定費であれば、売上が増えても金額は大きく変わりません。たとえば、一定額の保守費やサーバー費がこれに近い費用です。
一方、レベニューシェアは売上が増えるほど支払いも増えます。初期費用を抑えられる代わりに、売上が伸びた後も継続的に支払いが発生します。

次のように、売上規模ごとに試算してみると見え方が変わります。

月間売上	レベニューシェア30％	残り
100万円	30万円	70万円
500万円	150万円	350万円
1,000万円	300万円	700万円

この「残り」から、広告費、人件費、サーバー費、外注費、管理コストなどを支払います。
売上が増えているのに利益が残りにくい場合は、レベニューシェア率や契約期間を見直す必要があります。

粗利が残るかを試算する

レベニューシェア契約を検討するなら、最初に月商ごとの粗利を試算しておくと判断しやすくなります。

たとえば、求人サイトを立ち上げる場合、収益源として掲載課金、成果報酬、スカウト課金、広告掲載などが考えられます。どの収益モデルを採用するかで、利益の出方は変わります。

掲載課金なら、掲載企業数が増えれば売上は読みやすくなります。
成果報酬なら、成約までの期間が長く、売上の発生タイミングが遅れることがあります。
広告収益なら、アクセス数が伸びるまで収益化に時間がかかります。

この段階で確認したいのは、細かい会計処理よりも、事業として成り立つかどうかです。
少なくとも、次の3パターンは試算しておくとよいです。

売上が伸びない場合は当然厳しくなりますが、想定以上に伸びた場合にも注意が必要です。
レベニューシェア率が高いままだと、売上が増えても利益率が改善しにくくなるためです。

企画中のWebサービスが事業として成り立つかを知りたい場合は、セルバが用意するWebサービス企画の簡易整理フォームを使うのも一つの方法です。
収益モデル、必要機能、集客方法、初期費用の考え方を一度言語化できます。

回答後は、原則として簡単なフィードバックメールが1回届く形で、継続的な営業メールや打ち合わせ前提の案内は、希望されない限り行いません。
企画が固まりきっていない段階でも、自分たちの構想を整理する材料になります。

開発方式も比較する

レベニューシェアの割合を調べていると、どうしても「何％なら妥当か」に意識が向きますが、Webサービスを立ち上げる方法はレベニューシェアだけではありません。

通常の受託開発、WordPress、ノーコード・ローコード、構築パッケージ、フルスクラッチなど、複数の選択肢があります。
初期費用を抑えたいという理由だけでレベニューシェアを選ぶと、後から契約や運営の面で苦しくなることがあります。

レベニューシェアだけで考えない

レベニューシェアは、売上が伸びれば双方にメリットがありますが、開発会社が事業リスクを負う以上、すべての企画に向いているわけではありません。

たとえば、次のような状態だと、レベニューシェアよりも通常の開発契約や小さな検証から始める方が現実的です。

反対に、すでに顧客接点があり、掲載企業や利用者を集める見込みがある会社なら、レベニューシェアや共同事業に近い形を検討できる余地があります。

初期費用だけを見るのではなく、「自社がどこまで事業を動かせるか」を見た方が、開発方式を選びやすくなります。

安く始める方法の限界

WordPressやノーコード・ローコードは、スピードと費用面で魅力があります。
まずLPを作る、簡単な会員登録を試す、手動運用でニーズを確認する、といった段階では有効です。
まだ事業性が見えていない段階で、いきなり大きな開発費をかける必要はありません。

一方で、検索機能、会員機能、掲載企業向け管理画面、一般ユーザー向けマイページ、スカウト機能、決済、権限管理などが増えると、簡易的なツールでは対応しにくくなり、後から次のような課題が出やすくなります。

小さく始めることは悪い選択ではありません。ただ、最初から掲載数や会員数を増やす前提があるなら、後で作り直すコストも見ておく必要があります。

構築パッケージという選択肢

ポータルサイトのように、データベース、検索機能、会員機能、管理画面を持つWebサービスなら、構築パッケージを使う選択肢もあります。

構築パッケージは、必要になりやすい基本機能をあらかじめ備えた状態から開発する方法です。
フルスクラッチより費用や期間を抑えやすく、WordPressやノーコードより拡張性やセキュリティを確保しやすいのが特徴です。

もちろん、すべての企画に合うわけではありません。独自性の高い仕組みや、特殊な業務フローを前提にする場合は、個別開発の比重が大きくなります。
ただ、求人サイト、マッチングサイト、検索型ポータル、比較サイトのように、必要な機能がある程度共通しているサービスなら、パッケージを土台にした方が進めやすいケースは多いです。

セルバでは、データベース・検索機能・会員機能を持つポータルサイトの構築パッケージを提供しています。
スタートアップから大企業まで120社以上のポータルサイト構築実績があり、特に人材業界の実績が多く、求人サイトだけで70サイト以上の構築実績があります。
要件が合えば最短2ヶ月でのリリースも可能です。

ポータルサイトは、公開後に後からSEO対策しようとしても、URL構造、詳細ページの作り方、検索結果ページ、内部リンク、掲載情報の持たせ方などが制約になります。
そのため、最初の設計段階からSEOを考慮することが欠かせません。
セルバのポータルサイト構築では、こうした設計面も含めて検討できます。

月商9億円以上のサイトに成長した構築実績もありますが、当然ながら、同じ成果がどの事業でも再現できるわけではありません。実績は「必ず伸びる根拠」ではなく、「似た構造のサイトを扱ってきた会社かどうか」を見る材料として捉えるのがよいです。

具体的な開発方式を比較したい場合は、以下のページで、ポータルサイト構築の考え方や対応範囲を確認できます。

相談前に整理したいこと

レベニューシェアで進めるにしても、通常の受託開発で進めるにしても、開発会社に相談する前に整理しておきたいことがあります。

完璧な企画書は必要ありません。むしろ、最初から細かく決めすぎていると、開発側から見て「事業上の優先順位」と「作りたい機能」がずれていることもあります。
大事なのは、何を作りたいかだけでなく、誰に使ってもらい、どこで売上が発生し、誰が運営するのかを言葉にすることです。

企画の粗さは問題ではない

Webサービスの企画は、最初からきれいにまとまっていない方が普通です。

「業界特化の求人サイトを作りたい」
「地域の事業者とユーザーをつなぐマッチングサイトを作りたい」
「比較サイトを作って問い合わせにつなげたい」

このくらいの段階でも、整理すべき論点は見えてきます。

たとえば、求人サイトなら、誰向けの求人を扱うのか、掲載企業はどのように集めるのか、求職者はどこから流入させるのかを考える必要があります。
マッチングサイトなら、供給側と需要側のどちらを先に集めるのかを決めなければなりません。

相談前にすべてを確定させる必要はありませんが、次の問いには仮でも答えを持っておくと話がスムーズに進みます。

これらを整理すると、レベニューシェアが合うのか、通常の開発が合うのか、小さな検証から始める方がよいのかを判断しやすくなります。

必要機能を書き出す

Webサービスを開発しようとすると、思っている以上に機能が必要です。
最初は「検索できるサイトを作りたい」だけだったとしても、実際に設計を始めると、会員登録、ログイン、掲載情報の登録、管理画面、問い合わせ、メール通知、権限管理などが必要になることがわかります。

たとえば求人サイトなら、次のような機能が候補になります。

すべてを初期リリースに入れる必要はありません。むしろ、最初から盛り込みすぎると、公開までの期間が延びます。

初期リリースでは、売上や利用状況を確認するために必要な機能を優先し、後から追加できるものは分けて考える方が進めやすくなります。

収益化までの流れを見る

Webサービスの開発は、「作れるか」よりも「運営できるか」を考える必要があります。

たとえば、掲載課金型のポータルサイトなら、掲載企業を獲得できなければ売上は立ちません。
成果報酬型なら、成果の定義や確認方法を決める必要があります。
広告収益型なら、一定のアクセス数が必要になります。

ここを曖昧にしたまま開発に進むと、公開後に「どうやって売上を作るのか」を考えることになり、事業として難しいことが判明しても開発費は回収できません。

開発前に整理しておきたいのは、次の流れです。

レベニューシェアの割合や相場は、この流れが見えてから考えた方が現実に近くなります。
収益化の流れが見えていない状態で割合だけ決めても、売上が立たなければ双方に分配する原資がありません。

すでに企画の方向性があり、開発方式や必要機能を比較したい場合は、自社で対応する範囲と外部に相談する範囲を分けて考えると整理しやすくなります。

まとめ

• レベニューシェアの相場は、割合だけでなく、売上・利益の定義や役割分担によって変わる
• 初期費用を抑えられる一方で、集客責任や追加開発の負担を曖昧にすると公開後に揉めやすい
• Webサービスを立ち上げるなら、レベニューシェアだけでなく、通常開発・ノーコード・構築パッケージも比較して考える

レベニューシェアは、初期費用を抑えて事業を始められる方法の一つです。
ただし、売上が立つ見込み、運営体制、集客方法、必要機能が整理されていない状態では、契約条件だけを調べても判断しにくいです。

まずは、自社の企画がどの段階にあるのかを整理し、そのうえでレベニューシェアが合うのか、別の開発方式が合うのかを検討すると、無理のない進め方を選びやすくなります。