先に要点
- 見積もりを出すための調査に費用を請求すること自体は、おかしなことではありません。実作業(工数)が発生する調査は、本来は対価をもらってよい仕事です。
- ただし商習慣として、営業活動の範囲の概算ヒアリングや概算見積もりは無償 が一般的。線引きは「成果物が残る実作業か」「相手の課題解決そのものか」で判断します。
- 有償化したいなら、いきなり請求書ではなく 「調査フェーズ」を開発本体と分けて契約 する形にします。現状調査・要件定義・有償PoCなどに切り出すのが王道です。
- 無償で抱え込むと、失注時の持ち出しや、調査結果だけ流用されるリスク が出ます。規模が大きい調査ほど、事前に有償か無償かを合意しておくのが安全です。
ちゃんとした見積もりを出すために、現状のシステムを調べて、要件も整理した。でもこの調査の手間って、請求していいんだろうか ── 受託開発やフリーランスでよく出てくる悩みです。見積もりはタダ という空気の中で、調査にかかった工数をどう扱うか迷う人は多いはずです。
結論から言うと、実作業を伴う調査に費用を請求するのは、原則として正当 です。ただし「どこからが請求してよい調査で、どこまでが営業活動の範囲か」の線引きと、角を立てずに有償化する組み立て方 を知らないと、揉めたり失注したりします。この記事では、その判断基準と進め方を整理します。
そもそも「見積もりのための調査」とは何か
ひとくちに調査と言っても、中身はかなり幅があります。ざっくり次のような作業が含まれます。
現状調査
既存システムの構成・データ・連携先を調べる。ソースやDBを読む、ヒアリングする。手を動かす実作業 になりやすい。
要件ヒアリング・整理
何を作りたいかを聞き取り、曖昧な要望を実装できる粒度に落とす。要件定義に近い知的作業。
技術検証(PoC)
実現できるか不安な箇所を試作して確かめる。はっきり工数が出る 検証作業。
ポイントは、概算を出すための軽いヒアリングと、成果物が残る実作業の調査は、性質がまったく違う ということです。前者は営業活動、後者はそれ自体が価値のある仕事です。ここを一緒くたにすると、請求の判断がぶれます。
調査費は請求していいのか
結論は 「実作業を伴う調査なら、請求してよい」 です。理由はシンプルで、調査には人の時間=工数がかかっており、その工数は他の有償作業と質的に変わらないからです。現状調査のためにソースを読み、検証コードを書き、ドキュメントにまとめる作業は、立派な成果物のある仕事です。
一方で、商習慣として無償が一般的な範囲 もあります。初回の打ち合わせ、ざっくりした要望ヒアリング、概算(ラフ)見積もりの提示あたりは、受注を取るための営業活動とみなされ、無償で行われることが多いです。これを「無償でやってくれて当然」と相手が思っているところに、後から「調査費です」と請求すると角が立ちます。
「受注のための営業活動」なら無償慣行、「相手の課題を解決する実作業・成果物が残る作業」なら有償が筋。迷ったら、調査の前に「ここから先は有償の調査になります」と一言伝えて合意を取るのが、最もトラブルが少ないです。
無償が許容される範囲 vs 有償にすべき範囲
実務での線引きを表にすると、次のようになります。あくまで一般的な目安で、最終的には事前合意が優先です。
| 作業 | 性質 | 費用の扱い(一般的な目安) |
|---|---|---|
| 初回打ち合わせ・要望ヒアリング | 営業活動 | 無償が慣行 |
| 概算(ラフ)見積もりの提示 | 営業活動 | 無償が慣行 |
| 既存システムの現状調査(ソース解析・データ調査) | 実作業・成果物あり | 有償にできる |
| 要件定義・業務フロー整理 | 知的作業・成果物あり | 有償が妥当(準委任が多い) |
| 技術検証・PoC | 検証作業・工数明確 | 有償にできる |
| 詳細な正式見積もりに必要な深掘り調査 | 実作業 | 規模次第で有償化を提案 |
境目になりやすいのが「正式な見積もりを出すための深掘り調査」です。見積もりはタダのはず という相手の感覚と、これだけ調べないと正確な数字は出せない という受注側の事情がぶつかります。ここを無言で抱え込むと持ち出しになります。
有償の調査として切り出す典型パターン
有償化のコツは、請求書を後出しするのではなく、調査を「フェーズ」として最初から分けて契約する ことです。代表的な型は次のとおりです。
この「段階契約」は、受注側だけでなく発注側にも利点があります。いきなり大きな開発契約を結ぶより、まず小さな調査で実態と相性を確かめられるからです。契約形態の違い(成果物に責任を負う請負か、作業時間に対価を払う準委任か)は、準委任契約と請負契約で性質が分かれます。調査・要件定義フェーズは準委任で受けるのが一般的です。詳しくは準委任契約と請負契約の違い｜システム開発の契約はどちらを選ぶも参考になります。
なぜタダ働きになりやすいのか
調査費が持ち出しになりやすいのには、構造的な理由があります。
- 提案工数は見えにくい ── 提案・調査の手間は請求項目に出てこないので、コストとして意識されにくい。
- 失注すると丸ごと損になる ── 無償で深く調べたのに受注できなければ、その工数は回収不能。
- 調査結果だけ流用される ── 要件整理や技術選定の知見だけ受け取り、開発は別の安いところへ、というケースもある。
- 「見積もりはタダ」の空気に流される ── 概算と本格調査を区別しないまま、全部無償でやってしまう。
特に規模の大きい調査ほど、ここのリスクが大きくなります。だからこそ、どこまで無償で、どこから有償か を着手前に言語化しておくことが防御になります。要件をどこまで詰めるかという論点は、要件定義で最低限決めることは？受託開発であとから揉めやすい項目を整理ともつながります。
角を立てずに有償化を伝える
有償化は、言い方ひとつで印象が変わります。「それは別料金です」とだけ返すより、なぜ調査が必要で、それが相手にどんな価値をもたらすか を添えると納得されやすいです。
たとえば、こう伝えます。
- 「正確な見積もりを出すには、既存システムの調査が必要です。ここは調査フェーズとして分けて、◯万円・◯日でお受けします。調査結果は報告書としてお渡しするので、仮に弊社で開発しない場合でもお手元に残ります」
- 「実現できるか不安な箇所があるので、先に小さく試作して確かめませんか。上限◯人日で区切るので、ここで難しいと分かれば本開発前に方針を見直せます」
ポイントは、調査の成果物が相手の資産として残ることと、上限を区切ってリスクを抑えていることを示すことです。見積もりそのものの作り方を整理したい場合は、見積もりとは？IT開発の工数・期間・費用の出し方と代表的な見積もり方法もあわせて読むと、調査と見積もりの関係が見えやすくなります。
調査費の請求に関するよくある質問
Q. 見積もりを出すだけなら、調査費は請求できませんか？
A. 概算見積もりを出すための軽いヒアリングは、営業活動として無償が一般的です。ただし、正確な見積もりのために既存システムを実際に調べる、要件を整理する、といった実作業が必要なら、その部分は有償の調査として切り出せます。ポイントは「営業の範囲か、成果物が残る実作業か」です。
Q. 無償でやってしまった調査を、後から請求できますか？
A. 事前に有償と合意していない調査を後から請求するのは、トラブルになりやすく難しいです。相手は無償のつもりでいるからです。次回以降は、調査に入る前に「ここから先は有償の調査フェーズになります」と伝え、合意を取ってから着手するのが安全です。
Q. 調査費はどのくらいが相場ですか？
A. 一律の相場はなく、調査の工数(人日)に技術者単価をかけて算出するのが基本です。小規模な現状調査なら数日分、要件定義フェーズなら数週間分、というように規模で変わります。重要なのは金額の絶対値より、何にどれだけの工数がかかるかを根拠として示すことです。
Q. 調査フェーズはどんな契約にすればよいですか？
A. 調査・要件定義は成果物の完成を約束しにくいため、作業時間に対価を払う準委任契約が向いています。逆に「この調査報告書を完成させて納品する」と成果物を約束する形なら請負になります。実務では、調査・要件定義は準委任、開発本体は請負、と分けることが多いです。
Q. 有償調査を提案したら失注しそうで怖いです。
A. 無償の深掘り調査を続ける方が、長期的にはリスクが高いです。有償化を断る相手は、そもそも調査の価値を認めていない可能性があり、受注しても安く買い叩かれやすい傾向があります。調査の成果物が相手に残ること、上限を区切ることを示せば、誠実な相手なら納得します。
Q. PoC(技術検証)も有償にしていいですか？
A. はい、PoCは工数がはっきり出る検証作業なので、有償にしやすい代表例です。上限の人日や費用を先に決めておき、「ここで実現が難しいと分かれば本開発前に方針転換できる」という価値とセットで提案すると、発注側にも合理的に映ります。
Q. 調査結果だけ持っていかれるのを防ぐには？
A. 調査を有償フェーズとして契約し、成果物(調査報告書・要件定義書)の対価を受け取る形にするのが一番の防御です。無償で深い知見を渡してしまうと、それだけ流用されても請求の根拠がありません。契約で成果物の扱いや二次利用の範囲を明記しておくとさらに安全です。