システム開発や業務効率化ツールの相談では、複数の開発者や開発会社に相談し、費用や納期を比較する相見積もりが行われることがあります。
これは一般的な商習慣であり、依頼者さまが複数の選択肢を比較すること自体は問題ありません。
ただし、相談の中で開発者が作成した要件定義書、画面案、処理フロー、設計案、コード方針などを、契約前の段階でそのまま別の出品者や生成AIに渡して使う場合は注意が必要です。
この記事では、開発者の立場から、依頼者さまに知っておいていただきたい相見積もり時の線引きを整理します。法律の専門的な断定ではなく、開発現場とフリーランス実務の視点からの一般的な注意喚起です。
相見積もり自体は問題ありません
まず前提として、相見積もりそのものは問題ありません。
依頼者さまが複数の開発者に相談し、金額、納期、対応範囲、進め方を比較することは、一般的な発注活動の一部です。
たとえば、以下のような行為は基本的に問題ありません。
- 複数の出品者や開発会社に相談する
- 費用や納期を比較する
- 開発者ごとの提案内容や進め方を比較する
- 自分の業務内容、困りごと、希望機能を説明する
- 現在使っているExcel VBA、スプレッドシート、業務フローについて説明する
依頼者さま自身の業務内容や希望機能は、依頼者さまの情報です。
そのため、「自分の業務をどう改善したいか」を複数の相手に説明すること自体は、通常の相談の範囲と考えてよいでしょう。
どこから注意が必要なのか
注意が必要なのは、開発者が相談の中で作成した「整理済みの内容」を、そのまま別の相手に渡してしまうケースです。
たとえば、Aさんという開発者に相談し、Aさんが以下のような資料を作成したとします。
- 要件定義書
- 提案資料
- 画面構成案
- 処理フロー図
- データベース設計案
- 実装方針
- コード案や疑似コード
これらを契約前・無償の段階で受け取り、そのまま別の出品者に渡したり、AIに貼り付けて開発させたりする行為は、トラブルにつながる可能性があります。
なぜなら、その資料には単なる「依頼者さまの希望」だけでなく、開発者の経験、判断、整理力、設計力が含まれているからです。
「伝わっているはず」の落とし穴でも整理したように、開発では、希望を聞くだけでなく、曖昧な条件を仕様として使える形に変換する作業が必要です。その変換作業自体に価値があります。
要件定義や提案資料は成果物になることがあります
ここで大切なのは、アイデアと成果物を分けて考えることです。
たとえば、以下のような希望やアイデアは、依頼者さまの業務上の要望です。
- 予約管理システムを作りたい
- Excelの集計を自動化したい
- Google Apps Scriptでフォーム回答を集計したい
- 受注データから請求書を自動作成したい
- CSVを取り込んで帳票を出力したい
このような「何をしたいか」という要望自体を、複数の開発者に説明することは問題ありません。
一方で、その要望をもとに開発者が次のような内容を整理した場合、それは開発者の知見が入った成果物といえます。
- どの画面が必要か
- どのデータを保存するか
- どの処理を自動化するか
- どのような順番で実装するか
- どこにエラー対策を入れるか
- どの機能を優先すべきか
つまり、依頼者さまの「やりたいこと」と、開発者が整理・設計した「具体的な実現方法」は、同じものではありません。
文章化、図解化、設計化された内容には、開発者の経験や判断が含まれます。そのため、それを無断で別の出品者やAIに流用することは、著作権などの権利面、マナー面、信頼関係の面で問題になりやすいと考えた方がよいでしょう。
なお、具体的に権利上の問題にあたるかどうかは、資料の内容、作成経緯、利用範囲、契約内容、各サービスの利用規約などによって変わります。ここでは「個別判断が必要な領域なので、無断流用は避けた方が安全」という線引きで扱います。
AIに貼り付けて作らせる場合も注意が必要です
最近は、生成AIを使ってコードを書いたり、仕様書を整えたりすることも一般的になってきました。
AIを活用すること自体は、決して悪いことではありません。自分で整理した要件をAIに伝えて、実装方法を相談することは、多くの場面で有効です。
しかし、他の開発者が作成した要件定義書や設計案を、そのままAIに貼り付けて、次のように指示する場合は注意が必要です。
AIに入力する場合でも、元になっている資料が誰の成果物なのか、どの範囲まで利用してよいのかを確認する必要があります。
開発者Aが作成した資料をAIに渡して開発することは、見方によっては「Aさんの成果物を使って、別の手段で開発している」状態に近くなります。AIに任せる場合であっても、他者が作成した資料を無断で利用してよいわけではありません。
他の出品者に渡す場合も同じです
AIだけでなく、別の出品者や別の開発会社に渡す場合も同じです。
たとえば、Aさんに相談して詳細な要件定義をしてもらい、その資料をBさんに渡して「この内容で安く作れますか？」と依頼するケースです。
この場合、Bさんは仕様整理の手間を省いて見積もることができます。一方で、Aさんは本来有償であるべき要件定義や設計の作業だけを、無料で提供したような形になってしまいます。
依頼者さま側に悪意がない場合でも、開発者側から見ると「提案内容だけ使われた」と感じやすく、信頼関係を損なう原因になります。
もちろん、依頼者さまが自分の要件を整理し直し、自分の言葉で別の開発者に相談することは問題になりにくいでしょう。問題になりやすいのは、開発者Aが作成した文章、図、設計、構成を、そのまま別の相手に渡すことです。
やってよいこと・避けた方がよいこと
判断に迷う場合は、「その内容は自分が元々持っていた情報か」「開発者が整理・設計した情報か」で分けて考えると分かりやすいです。
| 行為 | 考え方 |
|---|---|
| 複数の開発者に相談する | 基本的に問題ありません |
| 費用・納期・対応範囲を比較する | 相見積もりとして自然です |
| 自分の業務内容や希望機能を説明する | 問題ありません |
| A社の提案を見て、自分の要望を整理し直す | 表現や資料をそのまま使わなければ比較的問題になりにくいです |
| A社の要件定義書をそのままB社に渡す | トラブルになる可能性があります |
| A社の画面案・設計案をAIに貼り付ける | 注意が必要です |
| 契約前に詳細な仕様書や設計書まで無料で求める | 有償作業として相談した方が安全です |
| 最初から発注する気がないのに、詳細な提案だけ求める | 不誠実な印象を与えやすいです |
自分の業務内容や希望機能を説明することは問題ありません。しかし、開発者が整理した文章、図、画面案、処理フロー、設計方針をそのまま使う場合は、事前に確認した方が安全です。
トラブルを防ぐために依頼者ができること
トラブルを防ぐためには、依頼者さま側でも次のような対応をしておくと安心です。
要件定義だけ有償で依頼する
詳細な要件定義書や仕様書が必要な場合は、「要件定義だけ有償でお願いできますか」と相談するのがおすすめです。
開発まで依頼するかは未定でも、要件整理そのものに対価を支払えば、その後の比較検討や社内検討もしやすくなります。
資料の利用範囲を事前に確認する
提案資料や仕様書を別の出品者やAIに渡したい場合は、事前に「この資料を他社にも共有してよいでしょうか」と確認しておくと、無用なトラブルを避けやすくなります。
発注予定や検討状況を誠実に伝える
「現在、複数名に相談しています」「まだ発注先は決まっていません」「まずは要件整理だけお願いしたいです」のように最初から伝えておくことで、開発者側も適切な範囲で提案しやすくなります。
詳細な設計を求める場合は有償作業として相談する
画面案、処理フロー、DB設計、コード方針などを具体的に整理してもらう場合、それは見積もりの補助を超えて、実質的な設計作業になることがあります。
その場合は、要件定義費・設計費として依頼する方が、お互いに安心です。
開発者側も無料相談と有償要件定義を分ける
これは依頼者さまだけでなく、開発者側にも関係する話です。
開発者側も、無料相談の中で詳細な要件定義や設計まで行ってしまうと、後から「どこまでが無料相談だったのか」が曖昧になります。
そのため、見積相談の段階では概要確認にとどめ、詳細な要件定義書や画面設計が必要な場合は、有償作業として切り分けることが大切です。
たとえば、以下のような案内文を事前に用意しておくとよいでしょう。
正確なお見積りのため、概要レベルでの確認は無料で対応いたします。
ただし、具体的な要件定義書、画面設計、処理フロー、実装方針、コード案など、
他の開発者様やAI等でもそのまま利用可能なレベルの資料作成については、
有償の要件整理作業として対応させていただきます。
開発者側があらかじめ線引きを示しておくことで、依頼者さまも「どこからが有償作業なのか」を理解しやすくなります。
開発相談を進めるときの実務的な線引き
開発相談では、最初から完璧な仕様書があることは少ないです。そのため、概要レベルの相談、概算見積もり、要件整理、有償設計を段階的に分けると進めやすくなります。
- 概要相談: 何をしたいか、現在何に困っているかを確認する
- 概算見積もり: 大まかな範囲、想定工数、費用感を確認する
- 要件整理: 画面、入力、出力、条件、例外、優先順位を整理する
- 実装: 合意した要件をもとに開発する
この流れにしておくと、無料相談でどこまで話すか、有償作業としてどこから依頼するかが見えやすくなります。
関連して、開発依頼で認識ズレを減らす考え方は「伝わっているはず」の落とし穴でも整理しています。AIを活用した開発相談の考え方は生成AIを活用した新しいシステム導入サービスの考え方も参考になります。
見積もり金額の考え方を確認したい場合は、ココナラ見積・手取り・予算逆算ツールも用意しています。
まとめ
相見積もりは、依頼者さまにとって大切な比較検討の手段です。複数の開発者に相談し、費用や納期、進め方を比較すること自体は問題ありません。
ただし、開発者が作成した要件定義書、提案資料、画面案、設計案、コード案などを、無断で別の出品者やAIに渡して利用することは、トラブルの原因になる可能性があります。
相談はOK。
でも、他者が整理・設計した成果物の無断流用は避ける。
この線引きを意識しておくことで、依頼者さまも開発者も、安心して気持ちよく開発を進めやすくなります。
Excel VBA、Google Apps Script、Webアプリなどの開発相談をご希望の方は、まずは概要レベルでお気軽にご相談ください。具体的な要件定義書や設計資料の作成が必要な場合は、別途「要件整理」として有償で対応可能です。
注意書き
本記事は、開発相談や相見積もりに関する一般的な注意喚起として作成したものです。個別の法的判断については、弁護士などの専門家へご相談ください。