提案有償型のシステム開発コンペ｜参加費・要件整理・知財をどう決めるか

監督だ。結論から言う。システム開発コンペで複数社に具体的な設計や試作まで求めるなら、提案作業を無償前提にしない方が比較の質を保ちやすい。ただし参加費を払えば公平になる、という単純な話でもない。求める成果、利用権、選定方法を先に決めないと、発注側も参加会社も消耗する。

渚由希です。映像制作でも、企画案、絵コンテ、サンプル編集までを選定前に求められることがあります。システム開発も同じで、「提案」の言葉が要件整理や設計作業まで膨らむと、無償で扱う範囲を超えます。この記事では、提案有償型のコンペを実務として成立させる条件を整理します。

無償提案と有償提案の境界

監督「会社紹介、類似実績、概算、体制、基本方針を比べるだけなら、通常の営業提案に収まる場合が多い。だが、画面設計、データモデル、検証用プロトタイプ、詳細な移行計画まで要求するなら、それはもう作業だ」

渚「素材不足のまま具体案を出せと言われると、制作側は仮定を増やすしかありません。仮定の多い提案を並べても、比較条件がそろわないんです」

有償化を検討する目安は、参加会社が独自調査を行う、複数回のヒアリングに参加する、成果物を納品する、発注後も使える設計を作る、専門家を長時間拘束する、といった場合です。

参加費の考え方

提案費に公的な一律相場はありません。金額は、拘束する人数・時間、成果物の細かさ、試作環境、データ提供、プレゼン回数で変わります。そのため「他社はいくら払っているか」より、発注側が求める作業を分解して予算化します。

監督「例えば、2名が3日使う提案と、5名が3週間使う試作を同じ参加費で扱うのは無理がある。まず工数と外部費用を見えるようにする」

参加費は提案コストの全額補填とは限りません。参加会社も受注機会を得るため一定の営業投資をします。発注側が通常提案を超えて要求する部分をどこまで負担するか、事前に示すことが重要です。

渚「交通費、撮影や素材購入、クラウド利用料など、実費が出る項目は別建てにした方が分かりやすいです。後から『そこまで含むと思った』となるのが一番つらいので」

RFPでそろえる比較条件

提案依頼書には、背景、現行業務、対象範囲、利用者、必須要件、希望要件、制約、予算の考え方、選定日程を記載します。未確定のことは未確定と明記し、参加会社ごとの質問回答は原則共有します。

最低限、次をそろえます。

• 提案書のページ数と書式
• 必須の成果物と任意の成果物
• ヒアリング回数と参加者
• 概算見積の前提
• デモや試作の範囲
• 評価項目と配点
• 不採用時の成果物の扱い
• 機密情報の管理方法

監督「評価軸を後出しすると、プレゼンが上手い会社だけが勝つ。技術、運用、体制、費用、リスクを分けて採点する。シンギュラリティを待たなくても、比較表は今すぐ作れる」

知的財産と利用権

不採用会社の画面案や方式を、そのまま採用会社へ渡すのは避けるべきです。提案書の所有権、著作権、ノウハウ、利用許諾、返却・廃棄を募集要項や契約で定めます。

渚「企画案は、完成品ではなくても作り手の工夫が詰まっています。発注側が必要なのは、比較のために閲覧・評価する権利なのか、将来その案を実装する権利なのか。そこを分けて書いてください」

有償だから自動的に知的財産が移転するわけではありません。参加費が評価用成果物の対価なのか、利用権まで含むのかを明記します。既存ライブラリ、テンプレート、一般的なノウハウは参加会社に残す整理も必要です。

要件整理をコンペ前に行うか

要件が曖昧すぎる場合、開発会社を比べる前に、第三者または別契約で要件整理を行う選択肢があります。コンペ参加会社の一社へ要件整理を依頼するなら、その会社が選定で有利になる情報差をどう扱うか決めます。

監督「問題が分からないまま解決策だけ競わせると、各社が別の問題を解く。見積の数字が並んでも比較にならない」

渚「逆に、細部まで固定しすぎると、現場に合う提案が出ません。変えられない条件と、提案を期待する余白を分けるのが大事です」

評価と意思決定の記録

評価者は経営、現場、情報システム、管理部門など複数の立場から参加します。各評価者が先に採点し、その後に差の理由を話すと、声の大きい人だけで決まりにくくなります。

評価軸	確認例
課題理解	現状の制約と優先順位を捉えているか
実現性	体制・技術・移行計画に無理がないか
運用性	導入後の保守・教育・権限が考えられているか
費用	前提、範囲外、追加条件が明確か
リスク	未確定事項と対策が示されているか

監督「最低価格だけで選ぶと、範囲外が後から積み上がることがある。総額ではなく、何を含む数字かを見る」

契約へ移る前の確認

選定後は、コンペの提案をそのまま契約書とみなさず、要件定義の範囲、成果物、検収、変更管理、支払条件を改めて合意します。試作が本番品質ではないこと、提案時の概算が確定見積ではないことも確認します。

渚「プレゼンで見せた画面が、そのまま納品されると思われることがあります。試作の役割と、本番で作り直す部分を説明しておくと、期待のずれを減らせます」

監督「やれることはAIに任せて、人は創るほうへ。ただし選定責任までAIに丸投げはできない。比較表の集計は自動化できても、事業の優先順位を決めるのは人だ」

見積依頼前のチェックリスト

• なぜコンペにするのか説明できる
• 参加会社数を必要以上に増やしていない
• 通常営業提案を超える作業を定義した
• 参加費と実費の扱いを示した
• 不採用成果物の利用範囲を決めた
• 評価基準と意思決定者を決めた
• 選定後の要件定義・契約工程を分けた

提案有償型のシステム開発コンペは、参加費を払う制度ではなく、発注前に必要な作業と権利を公正に扱う仕組みです。自社のRFPや評価表でどこまで準備すべきか判断しにくい場合は、開発見積もりの前段階から整理すると比較可能な条件を作りやすくなります。

開発見積もりの相談

提案有償型のコンペに必要なRFP、参加会社へ求める成果物、評価表、知財条件を整理したうえで、システム開発コンペの費用を含む開発見積もりを依頼できます。比較可能な前提づくりからご相談ください。