レベニューシェア型開発が頓挫した場合の開発費請求｜成功報酬型契約の実務

レベニューシェア型開発が頓挫した場合の開発費請求は、通常のシステム開発費の未払いとは違う考え方が必要です。固定報酬型の開発では、合意した開発費、納品、検収、未払いの有無が中心になります。これに対し、レベニューシェア型・成功報酬型の開発では、そもそも「開発費を後で請求できる合意だったのか」「収益分配で回収する前提だったのか」「報酬発生条件は何だったのか」が問題になります。

受注者側から見ると、長期間の開発に人員を投入したにもかかわらず、サービスがリリースされない、契約書が未締結のまま交渉が止まる、発注者が別会社に開発を切り替える、といった場面では、何らかの開発費を請求したいと考えるのが自然です。しかし、レベニューシェア型を選んだ以上、単に「工数をかけた」というだけでは、固定報酬と同じように請求できるとは限りません。

執筆者：弁護士 坂尾 陽（企業法務・M&A担当）

レベニューシェア型開発で開発費請求が問題になる場面

レベニューシェア型開発とは、開発時点で通常の開発費を全額支払うのではなく、リリース後の売上、利益、利用料、広告収入などを発注者と受注者で分配することを予定する取引です。スタートアップの新規サービス、アプリ開発、ECサイト、ゲーム、SaaS、業務提携型のシステム開発などで使われることがあります。

この仕組みは、発注者にとって初期費用を抑えられる一方、受注者にとっては、将来の収益が大きければ通常の開発費を上回る回収ができる可能性があります。しかし、サービスが完成しない、リリースされない、売上が立たない、運用開始前に契約交渉が決裂するという場合には、受注者側が開発費を回収できないリスクが表面化します。

そのため、頓挫後の請求では、単に「作業したから払ってほしい」と主張するのではなく、当初の合意がどのようなリスク分担だったのかを確認する必要があります。

最初に確認すべき報酬合意のタイプ

レベニューシェア型開発のトラブルでは、最初に報酬合意のタイプを分けます。ここを曖昧にしたまま請求すると、発注者側から「成功報酬型だった」「売上が出ていないから報酬は発生しない」「リリースできていないので条件を満たしていない」と反論されやすくなります。

固定報酬型に近い場合

名目上はレベニューシェアと呼んでいても、実際には、要件定義費用、初期開発費、月額保守費、追加開発費などを別途支払う合意がある場合があります。この場合、まずはその合意に基づく請求を検討します。見積書、発注メール、請求書、議事録、契約書案に、初期開発費や最低保証額が記載されている場合は、固定報酬部分として整理しやすくなります。

完全成功報酬型に近い場合

完全成功報酬型では、開発段階の固定報酬を受け取らず、将来の収益分配で開発費を回収する前提が強くなります。この場合、受注者は大きなリスクを引き受けているため、サービスが開始されず収益が発生しなかったときに、当然に通常開発費を請求できるとは限りません。

混合型の場合

実務上は、固定報酬とレベニューシェアが混ざっていることもあります。たとえば、初期費用は低額に抑え、リリース後の売上の一定割合を受け取る、または一定期間の保守費と収益分配を併用する、といった形です。この場合は、固定報酬部分、成功報酬部分、実費負担部分を分けて請求可能性を検討します。

開発費を請求できる可能性があるケース

レベニューシェア型だからといって、開発費請求が常に否定されるわけではありません。次のような事情がある場合は、受注者側に請求の余地があります。

最低報酬・初期費用・フェーズ費用の合意がある

契約書や契約書案に、初期開発費、要件定義費、月額固定費、最低保証額、フェーズごとの報酬が記載されている場合は、その部分について請求を検討できます。契約書に署名押印がなくても、メールで金額を承認している、作業開始を依頼している、請求書に異議を述べていないなどの事情があれば、黙示の合意を主張できることがあります。

この点は、通常の契約書なし開発の問題と重なります。契約書がない場合の考え方は、契約書なしのシステム開発で報酬請求できるかも参照してください。

発注者が成果物を利用している

受注者が作成したソースコード、画面、設計資料、データベース、API、仕様書、デザイン、管理画面などを発注者が受領し、自社サービスや別会社への引継ぎに利用している場合は、相当額の請求可能性が高まります。発注者が成果物を使っているのであれば、単なる営業提案や途中作業にとどまらず、相手方のために具体的な価値を提供したと説明しやすくなるためです。

ただし、利用の有無は証拠で示す必要があります。サーバーへのデプロイ履歴、リポジトリのアクセスログ、納品メール、受領確認、移管資料、後続ベンダーへの引継ぎ資料などを確認します。

発注者側の事情でリリースが止まった

開発自体はサービス開始に近い状態まで進んでいたにもかかわらず、発注者が事業方針を変更した、必要な情報提供をしなかった、テストや承認を止めた、資金調達の失敗を理由に中止した、といった場合も検討対象になります。もっとも、この場合でも、リリースできる状態に達していたか、発注者側の中止がどの程度原因になったかを丁寧に整理する必要があります。

レベニューシェアとは別の追加開発がある

レベニューシェアの対象となる当初開発とは別に、発注者から追加機能や仕様変更を依頼され、別途費用が発生する前提で対応した場合は、その追加開発費を請求できることがあります。この場合は、通常の追加費用請求に近い問題です。追加開発の考え方は、システム開発の追加費用を請求できるかで詳しく整理しています。

開発費請求が難しくなりやすいケース

反対に、次のような事情があると、受注者側の請求は難しくなりやすいです。特に、完全成功報酬型の合意が強く、リリースも売上発生もない場合は、請求の組み立てに注意が必要です。

レベニューシェア型では、受注者側が「通常ならこの工数は数千万円に相当する」と主張しても、当初から通常の固定報酬を取らない代わりに将来収益で回収する合意だったと評価されると、その主張は通りにくくなります。

法的構成は合意と商法512条を中心に考える

レベニューシェア型開発が頓挫した場合の法的構成は、まず当事者間の合意から考えるべきです。契約書、契約書案、メール、チャット、議事録、見積書、請求書、提案書を確認し、固定報酬、最低保証、フェーズ費用、収益分配率、報酬発生条件、契約終了時の精算条項があるかを見ます。

合意が明確でない場合には、商法512条に基づく相当報酬請求を検討します。商法512条は、商人が営業の範囲内で他人のために行為をしたときに、相当な報酬を請求できるとする規定です。詳しくは、商法512条とは｜契約書なし・報酬合意なしで相当報酬を請求できる場合で整理します。

もっとも、レベニューシェア型では、商法512条を使えば必ず工数相当額を請求できるわけではありません。当事者が将来の収益分配で開発費を回収する前提を選んでいた場合、裁判所は、その合理的意思を踏まえて、成果物がどの段階まで到達していたかを重視する可能性があります。

裁判例からみるレベニューシェア型開発の限界

レベニューシェア型開発の頓挫後の開発費請求では、東京地裁平成30年2月27日判決が参考になります。この事案では、システム開発会社が、開発に多数の時間を要したとして、商法512条に基づく相当報酬を請求しました。しかし、裁判所は請求を認めませんでした。

同判決では、当事者間で収益分配による開発費回収が予定されていたこと、開発が遅れ、最終的にサービス開始に至らなかったことなどが重視されています。裁判所は、単に労力を投じたことだけでは足りず、少なくともシステムを開発し、相手方がそのシステムに基づいてサービスを開始できる状態に至ったことが必要である、という方向で判断しました。

この裁判例からは、受注者側が請求する場合、工数表や人件費単価だけでなく、成果物がどこまで完成し、相手方がどのように利用可能だったかを示す必要があることが分かります。反対に、サービス開始可能な状態に達していない、テスト段階にとどまる、品質や進捗に問題があるという場合は、商法512条による請求も難しくなります。

請求前に整理すべき証拠

レベニューシェア型開発の請求では、証拠を「合意」「成果」「頓挫原因」「金額」の四つに分けて整理します。固定報酬型よりも報酬発生条件が複雑なため、作業ログだけを並べても説得力が出にくいからです。

合意に関する証拠

成果に関する証拠

頓挫原因に関する証拠

発注者側の仕様変更、資料提供の遅れ、テスト未実施、承認遅延、事業中止、資金調達失敗などが原因で頓挫した場合は、その経緯を示す証拠が重要です。他方、受注者側の遅延、品質不良、体制不足、連絡不備がある場合は、請求額の減額や請求否定の理由になり得ます。自社に不利な事情も含め、時系列で整理しておく必要があります。

金額に関する証拠

請求額を算定する際は、作業時間、担当者、単価、外注費、クラウド費用、ライセンス費用、通常の見積基準、過去案件の単価などを整理します。ただし、完全成功報酬型に近い場合は、通常単価で積み上げた金額がそのまま認められるとは限りません。合意したリスク分担を踏まえて、請求範囲を現実的に絞ることも重要です。

交渉では請求額を分解して提示する

レベニューシェア型開発が頓挫した場合、請求書に「開発費一式」とだけ書いても、発注者側は応じにくいことが多いです。交渉では、請求額を次のように分解して提示すると、争点が整理しやすくなります。

このように分けることで、強く請求できる部分と、和解的に調整すべき部分を分けられます。特に、完全成功報酬型の合意がある場合は、通常開発費全額を当然に請求するよりも、成果物の利用、固定費の合意、追加依頼、実費負担など、証拠の強い部分から組み立てる方が現実的です。

発注者側から想定される反論

請求を行う前に、発注者側からどのような反論が出るかを想定しておくことも重要です。レベニューシェア型では、次のような反論がよく問題になります。

これらの反論に対しては、単に感情的に反論するのではなく、証拠に基づいて、合意内容、成果物の到達度、発注者の利用状況、頓挫原因を一つずつ説明する必要があります。

今後同じトラブルを避けるための契約条項

レベニューシェア型開発では、契約書を作る段階で、頓挫時の精算を明確にしておくことが特に重要です。将来収益に期待して開発費を低額又は無償にする場合でも、何が起きたら最低限の費用を回収できるのかを決めておかなければ、紛争時に受注者側の立場が弱くなります。

特に、サービス開始前に事業中止となった場合、成果物を発注者が利用する場合、後続ベンダーへ引き継ぐ場合の精算条項は重要です。この部分が空白のままだと、頓挫後に商法512条や黙示合意をめぐって争うことになりやすくなります。

他の記事との整理

レベニューシェア型開発の開発費請求は、通常の追加費用請求や契約書なし開発の報酬請求と似ていますが、主戦場が異なります。通常の追加費用請求では、当初スコープを超える作業があったかが中心です。契約書なし開発では、黙示の有償合意や商法512条が中心です。

これに対し、レベニューシェア型では、将来収益で回収する前提を受注者がどこまで引き受けたのか、報酬発生条件が満たされたのか、サービス開始可能な状態に至ったのかが中心になります。したがって、通常の開発費未払いと同じ感覚で請求書を出す前に、合意の性質を整理する必要があります。

よくある質問

レベニューシェア契約書がない場合でも請求できますか

請求できる可能性はあります。ただし、契約書がない場合は、メール、チャット、提案書、見積書、議事録などから、固定報酬部分、最低保証、収益分配の条件、成果物の利用を立証する必要があります。完全成功報酬型に近い場合は、商法512条による請求も慎重に検討する必要があります。

リリース前に頓挫した場合でも開発費を請求できますか

リリース前でも、固定報酬やフェーズ費用の合意がある場合、発注者が成果物を利用している場合、発注者側の事情で中止された場合などは請求余地があります。ただし、報酬発生条件がリリースや売上発生とされていた場合や、サービス開始可能な状態に達していない場合は、請求が難しくなります。

工数表があれば商法512条で請求できますか

工数表は重要な証拠ですが、それだけで十分とは限りません。商法512条では、相手方のために行った行為であること、成果や利益、相当額の根拠が問題になります。レベニューシェア型では、さらに、当事者が将来収益で回収する前提を置いていたか、サービス開始可能な状態に達していたかも重要になります。

発注者が別会社に開発を依頼した場合は請求できますか

発注者が別会社に切り替えたことだけで直ちに請求できるわけではありません。自社の成果物が引き継がれたか、発注者都合で契約が打ち切られたか、開発中止の原因がどちらにあるか、契約書案やメールに終了時精算の合意があるかを確認します。

ソースコードを渡していない場合でも請求できますか

ソースコードを渡していない場合でも、設計、要件定義、試作、調査などの役務に対する請求余地がないわけではありません。ただし、成果物の引渡しや利用可能性を示しにくくなるため、請求は難しくなりやすいです。紛争化した場合でも、無断削除やアクセス遮断は避け、証拠保全と引渡し条件を整理することが重要です。

まとめ

レベニューシェア型開発の頓挫後に開発費を請求する場合、受注者側は、通常の未払い開発費と同じ発想で請求するのではなく、合意したリスク分担を踏まえて主張を組み立てる必要があります。固定報酬部分、成果物の利用部分、追加開発部分、実費部分を分け、証拠の強い部分から請求方針を立てることが重要です。

関連記事