開発会社とのレベニューシェア：成果報酬型開発の注意点と契約

開発会社とのレベニューシェアは、開発費の一部または全部を後払いにする代わりに、完成したサービスの売上や利益を一定の割合で開発会社に配分し続ける契約形態です。手元資金が限られる新規事業にとっては魅力的に見えますが、実際には「何を基準に配分するか」「権利は誰に帰属するか」「いつ・どうやって関係を終えるか」の三点を最初に決めておかないと、事業が伸びたときにも伸びなかったときにも揉めやすい契約です。

結論から言うと、レベニューシェアは「資金の代わりに開発会社を事業のパートナーにする」選択です。単なる支払い方法の工夫ではありません。開発会社に事業リスクを一部負ってもらう以上、意思決定への関与、売上データの開示、将来の買い取り価格などで、発注側も相応の譲歩をすることになります。その前提を理解したうえで、配分基準・権利・終了条件を契約に落とし込めるかどうかが判断の分かれ目です。

この記事は、新規事業の担当者や経営者で、開発費の工面に悩みレベニューシェア型の開発を検討している方に向けて書いています。仕組みと種類、向く事業・向かない事業、契約で決めるべき項目、交渉の手順、よくある失敗とその避け方までを順に整理します。

レベニューシェア型開発の仕組みと、通常の受託開発との違い

通常の受託開発では、発注側が開発費を支払い、開発会社は約束した成果物を納めるか、作業を提供した時点で対価を受け取ります。事業が成功しても失敗しても、開発会社の取り分は変わりません。一方、レベニューシェアでは開発会社の取り分の一部が事業の成果に連動します。売上が立たなければ開発会社は投下した工数を回収できず、売上が大きく伸びれば固定の開発費以上の対価を得られます。

つまり、開発会社は「作業の請負人」から「事業の共同出資者に近い立場」に変わります。用語としての意味はレベニューシェアの解説ページにまとめていますが、開発の文脈では次のような違いが生まれます。

この表の右列を見ると分かるとおり、レベニューシェアは発注側にとって「初期費用が下がる」以外は負担や制約が増える方向に働きます。それでも選ぶ価値があるのは、資金の制約が事業の検証そのものを止めてしまう場合や、開発会社の持つ技術・販路を事業に取り込みたい場合です。

レベニューシェアの主な種類と配分基準

一口にレベニューシェアと言っても、配分の基準や初期費用の扱いで中身は大きく変わります。代表的な型を押さえておくと、開発会社からの提案を比較しやすくなります。

売上連動型

サービスの売上高に一定の割合を掛けて配分する型です。計算が単純で、売上の把握さえできれば揉めにくいのが利点です。ただし、広告費や決済手数料、外部サービスの利用料などのコストを差し引く前の数字で配分するため、利益率の低い事業では発注側の手元に残る額が想像以上に小さくなります。

利益連動型

売上から一定の費用を差し引いた利益に割合を掛ける型です。発注側の利益を守りやすい一方、「どの費用を差し引くか」の定義で揉めやすくなります。人件費や本社経費を含めるのか、広告費は全額か一部かなど、費用の範囲を契約で細かく決める必要があります。

ハイブリッド型

初期費用を一部支払い、残りをレベニューシェアで回収する型です。開発会社のリスクが下がるため配分率の交渉がしやすく、実務では最も現実的な形になりやすいと言えます。初期費用を払う部分は通常の受託として扱い、成果連動部分だけを別の条項で定める設計がよく使われます。

上限付き・期間限定型

配分の総額に上限を設ける、または配分期間を一定年数に限る型です。発注側にとっては将来の負担が読みやすくなり、開発会社にとっても回収の見通しが立ちます。上限に達した時点や期間満了の時点で配分を終了し、以後は通常の保守契約に切り替える設計が考えられます。

レベニューシェアが向く事業・向かない事業

レベニューシェアは万能ではありません。事業の性質によって、合う・合わないがはっきり分かれます。判断の目安を表にまとめます。

特に注意したいのは「顧客の需要がまだ全く見えていない段階」です。開発会社から見ると回収の見込みが立たないため、配分率が高く設定されたり、初期費用を求められたりして、結果的にレベニューシェアの利点が薄れます。需要の手応えを先に小さく確かめ、その結果を材料に交渉するほうが条件はよくなります。

レベニューシェア以外に検討したい選択肢

初期費用を抑える方法はレベニューシェアだけではありません。比較の候補として、次のような選択肢も並べておくと判断を誤りにくくなります。

• 開発範囲を絞って段階的に発注する。 最初の検証に必要な機能だけを通常の契約で作り、手応えが見えてから次の範囲を発注する方法です。総額の見通しが立ちやすく、権利関係も単純です。
• 既存のSaaSやノーコードツールで代替する。 予約・決済・顧客管理などは既製のサービスで足りる場合があります。独自開発が必要な部分だけを作れば、開発費そのものが小さくなります。
• 分割払いや支払い時期の調整を相談する。 成果連動ではなく、支払いのタイミングを後ろにずらすだけで資金繰りの問題が解決することもあります。
• 出資や補助金など外部資金を検討する。 事業の性質によっては、開発会社に事業リスクを持ってもらうより、資金そのものを調達するほうが自由度は高くなります。制度の要件は変わりやすいため、最新情報は公的機関や専門家で確認してください。

これらと比べたうえで、それでも「開発会社を事業のパートナーにしたい」理由があるときに、レベニューシェアは最も力を発揮します。

契約で必ず決めておくべき項目

レベニューシェアの契約は、通常の開発契約よりも決めるべき項目が多くなります。ここを曖昧にしたまま着手すると、後から変更するのは困難です。

配分の基準と計算方法

配分の対象を売上とするのか利益とするのか、対象となるのはどのサービス・どの収益か、返金やキャンセルはどう扱うか、税の扱いはどうするかを明記します。将来サービスにオプション機能や別プランを追加した場合に、それも配分の対象に含めるかどうかも決めておきます。

売上の報告と確認の方法

開発会社は配分額が正しいかを確かめる手段を求めます。月次の売上報告の形式、管理画面の閲覧権限を渡すかどうか、帳簿を確認する権利（監査権）の範囲と頻度を決めます。発注側としては、事業全体の数字まで見せる必要があるのか、対象サービスの売上だけで足りるのかを整理しておきます。

知的財産とソースコードの帰属

開発したソースコードの著作権が誰に帰属するかは、レベニューシェアで最も揉めやすい論点です。開発会社が費用を負担している以上、権利を自社に残したいと考えるのは自然です。一方、発注側が権利を持たないと、将来の内製化や売却、資金調達の際に大きな障害になります。権利帰属の基本的な考え方はソースコードの著作権の決め方で詳しく扱っています。

運用・保守・追加開発の扱い

リリース後のサーバー費用、障害対応、機能追加の費用を誰が負担し、配分にどう反映するかを決めます。「追加開発もレベニューシェアの範囲内で対応する」と決めると、開発会社は優先度の低い要望を後回しにしがちです。追加開発は別途有償とし、配分は既存部分に限るなど、線を引いておくほうが運用は安定します。

終了条件と買い取り条件

最も重要なのが終わり方です。配分期間の満了、配分総額の上限到達、事業の撤退、どちらかの契約違反などの終了事由を定めます。あわせて、発注側が途中で配分を終わらせたい場合に一括で買い取る権利と、その価格の決め方（直近の配分額の何年分か、あらかじめ定めた額か）を決めておきます。撤退時にソースコードやデータをどう扱うかも忘れずに書きます。

競業と独占の扱い

開発会社が同じ仕組みを他社向けに転用してよいか、発注側が同種の開発を他社に依頼してよいかも論点になります。お互いの自由を過度に縛らない範囲で、転用の可否を決めておきます。

契約形態の選び方そのものについては、請負契約と準委任契約の選び方も参考になります。レベニューシェアは、これらの基本的な契約形態の上に成果連動の条項を組み合わせる形で設計されることが多いためです。なお、契約書の最終確認は、システム開発やライセンス契約に詳しい弁護士に依頼してください。

レベニューシェア型開発を交渉・合意するまでの手順

開発会社にいきなり「レベニューシェアでお願いできますか」と持ちかけても、良い条件は引き出せません。開発会社にとっては投資判断と同じだからです。次の順序で準備すると、話が具体的に進みます。

1. 事業の仮説と検証結果を整理する。 誰のどんな課題を解くのか、顧客と話した結果どんな反応があったのかを資料にまとめます。開発会社が回収の見込みを判断できる材料が必要です。
2. 初期費用として出せる上限を決める。 全額をレベニューシェアにするのか、一部を前払いできるのかで交渉の余地が変わります。社内で出せる上限を先に確定させます。
3. 開発範囲を最小限に絞る。 開発会社のリスクを下げるには、最初に作る範囲を小さくすることが最も効きます。検証に必要な機能だけに絞った範囲を提示します。
4. 配分基準・期間・上限の希望を用意する。 売上連動か利益連動か、何年間か、総額の上限はいくらかの希望案を持って臨みます。
5. 複数の開発会社と話す。 レベニューシェアを受ける会社は限られますが、比較対象がないと条件の妥当性が判断できません。可能な範囲で複数社に打診します。
6. 権利と終了条件を先に合意する。 配分率よりも先に、ソースコードの帰属と買い取り条件を詰めます。ここで折り合わない相手とは、配分率が魅力的でも組まないほうが安全です。
7. 契約書に落として専門家に確認する。 合意した内容を条項に落とし込み、弁護士の確認を受けてから署名します。

具体的な場面の例：小規模な予約サービスの場合

ここでは架空の一般例で考えます。地域の整体院やサロン向けに、予約と顧客管理をまとめた月額制のサービスを作りたい事業者がいるとします。手元資金では開発費の全額を賄えず、知人の紹介で開発会社にレベニューシェアを打診しました。

最初の打ち合わせで開発会社が知りたがったのは、配分率ではなく「すでに使いたいと言っている店舗があるか」でした。事業者は十数店舗にヒアリングし、そのうち数店舗が試験利用に前向きだという記録を持っていたため、話が具体的に進みます。

交渉の結果、初期費用は一部だけ支払い、残りは月額売上の一定割合を一定期間配分する、配分総額には上限を設ける、ソースコードの権利は事業者に帰属させる、事業者が希望すれば残りの配分見込み額を基準に一括で買い取れる、という条件で合意しました。追加機能の開発は別途見積もりとし、配分の対象は既存のプランの売上に限定しています。

この例のポイントは、配分率の高低よりも「どこで関係を区切れるか」を先に固めたことです。事業が伸びて内製化したくなったときにも、伸びずに撤退するときにも、契約上の出口が用意されています。

もう一つ、この事業者が事前に行っていたのが、売上の見込みを「慎重」「標準」「好調」の三つのシナリオで試算し、それぞれの場合に開発会社へ支払う総額と、通常の開発費で発注した場合の総額を並べた表を作ることでした。好調なシナリオでは通常発注より支払いが多くなることを受け入れたうえで、慎重なシナリオでも事業が続けられる資金繰りになっているかを確かめています。この比較表があったことで、配分率の交渉も感覚ではなく数字を前提に進められました。

よくある失敗とその避け方

レベニューシェア型開発でつまずく場面には共通点があります。代表的なものと避け方をまとめます。

• 配分の対象が曖昧で、新プランの売上を巡って揉める。 対象となるサービスと収益の範囲を契約に列挙し、新たな収益源を追加する際の扱いも定めておきます。
• 事業が伸びた後、配分が重荷になる。 配分期間か総額に上限を設け、一括買い取りの権利と価格の算定方法を最初に決めます。
• 事業が伸びず、開発会社の対応が遅くなる。 回収の見込みが立たないと、開発会社が優先度を下げるのは自然な反応です。保守の最低限の対応水準を有償部分として切り出し、配分とは別に確保します。
• ソースコードを持てず、内製化や売却ができない。 権利帰属は配分率より先に合意します。開発会社が権利を残したい場合は、発注側に十分な利用許諾と、一定条件での譲渡を受ける権利を確保します。
• 売上報告の負担が想定以上に重い。 報告の頻度と形式をシンプルにし、可能なら決済サービスの管理画面の閲覧権限で代替します。
• 開発会社の経営状態が悪化して運用が止まる。 ソースコードとインフラのアカウントを発注側の管理下に置き、第三者に引き継げる状態を保ちます。

契約前に確認したいチェックリスト

署名の前に、次の項目が埋まっているかを確認してください。

• 配分の対象（売上か利益か、どのサービスか）と計算方法が明記されている
• 返金・キャンセル・税の扱いが決まっている
• 配分の期間、または総額の上限が設定されている
• ソースコードと知的財産の帰属、または十分な利用許諾が定められている
• 一括買い取りの権利と価格の算定方法が決まっている
• 撤退時のソースコード・データ・アカウントの扱いが決まっている
• 保守・障害対応の最低水準と、その費用負担が決まっている
• 追加開発の扱い（配分内か、別途有償か）が決まっている
• 売上報告の頻度・形式・確認方法が決まっている
• 開発会社が事業を継続できなくなった場合の引き継ぎ方法がある
• 弁護士による契約書の確認を受けている

よくある質問

Q. レベニューシェアにすれば開発費は安くなりますか？

初期費用は下がりますが、総額が安くなるとは限りません。事業が伸びれば、配分の合計が通常の開発費を上回ることは十分にあり得ます。開発会社は回収できないリスクを負っている分、成功時の取り分で埋め合わせる設計になるのが普通です。「資金繰りを楽にする手段」と捉え、総額の比較は配分の上限や期間を前提に行ってください。

Q. アイデアだけの段階でもレベニューシェアに応じてもらえますか？

応じる開発会社もありますが、条件は厳しくなりがちです。開発会社にとって回収の根拠がないためです。顧客へのヒアリングや簡単な試作で需要の手応えを示せると、交渉の材料になります。

Q. 配分率はどうやって決めればよいですか？

一般的な相場で決めるのではなく、開発会社が負うリスクの大きさ、初期費用の有無、配分期間、上限の有無を組み合わせて決めます。配分率だけを見て比較せず、期間や上限、買い取り条件と合わせた「想定される総支払額」を複数の売上シナリオで計算して比べるのが確実です。

Q. 途中で別の開発会社に切り替えることはできますか？

契約で定めていなければ難しくなります。切り替えの可能性があるなら、ソースコードの帰属や引き継ぎへの協力義務、買い取りの条件を最初に決めておく必要があります。

Otsumuに相談できること

レベニューシェアを検討する前に、まず考えたいのは「本当に最初から大きな開発が必要か」です。顧客の需要がまだ見えていない段階なら、ヒアリングや手作業での試験提供、ノーコードツールを使った簡単な試作で検証を進められることも多く、その場合は外部の開発会社と複雑な契約を結ぶ必要はありません。事業の仮説を自社で整理でき、検証の手段も手元にあるなら、まずは自社で進めるのが合理的です。

一方で、開発範囲が絞り切れず見積もりが膨らんでいる、レベニューシェアの提案を受けたが条件が妥当か判断できない、資金の制約の中でどこまで作るべきか決められない、といった状況では外部の視点が役に立ちます。特に、契約条件の妥当性は事業計画とセットで評価しないと判断できません。

Otsumuは、自らも事業を手がける立場から、新規事業開発コンサルティングで事業の仮説整理と検証計画づくりを支援しています。検証に必要な機能だけに絞った開発が必要な段階では、新規事業の爆速MVPシステム開発で、AIを活用した少人数・短期間の開発をご提案できます。事業計画とあわせて開発範囲と投資の段階を見直したい場合は、新規事業レビュー Sprint（48万円・税別、1〜2週間）のように短期間で論点を整理する進め方もあります。

開発費の工面や契約形態について迷っている段階でも構いません。30分の無料相談で、現在の状況と選択肢を一緒に整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01