開発会社から「まず要件定義を有償で」と言われたら｜下期に先行発注した要件定義が来年度予算と相見積もりに使えなくなる4つの失敗

開発会社に業務システムの相談をすると、「見積もりの前に、まず要件定義を有償でやらせてください」と言われることがあります。たとえば、要件定義に3か月で150万円かけ、開発費は要件定義が終わってから出すという提案です。10月に発注すれば1月に終わるので、決まった開発費を来年度予算に載せられます。計算としては筋が通っています。ただ、契約の書き方とスケジュールの置き方によっては、この計画がうまく進まないことがあります。

要件定義が終わったのに、開発費が「1,200万〜2,000万円」の幅のまま出てきます

要件定義は、作業の完成ではなく作業そのものに対価を払う準委任契約で結ぶことがよくあります。そのため、何がそろえば完了なのかが契約に書かれていないまま進みがちです。その結果、議事録と打ち合わせ資料の束が成果物として納められ、開発費の幅も狭まりません。

防ぐには、成果物の目次を契約の別紙に入れておきます。業務フロー、画面と帳票の一覧、データ項目、外部との連携先、移行するデータの範囲、非機能要件を並べます。そのうえで、完了時にどのくらいの幅で開発見積もりを出すかも条件に含めます。非機能要件が抜けると見積もりが大きくぶれる理由は、見積もりが3社でバラバラになる理由で詳しく書いています。

あわせて読みたい業務システムの見積もりが3社でバラバラになる理由｜下期の決裁に載せる前に発注側が揃える前提条件と非機能要件

要件定義書を他社に見せようとしたら、契約で止められました

開発会社の標準の契約書では、成果物の著作権は開発会社に残り、秘密保持条項で第三者への開示も禁じられていることがよくあります。著作権の譲渡を受ける場合も注意が必要です。翻案（改変）の権利を明記しておかないと、その権利は元の会社に残ると著作権法で推定されます。

相見積もりに使うだけであれば、著作権の譲渡までは要りません。発注側が複製・改変し、見積もり依頼のために他社へ開示できるという利用許諾があれば足ります。開発会社がもともと持っているノウハウは対象から外し、線を引いておくと、相手も受け入れやすくなります。なお、開発を受注する前提で要件定義の費用を抑えている会社もあるため、他社への開示を条件にすると要件定義の見積もりが上がることがあります。

項目	書いていないと起きること	契約で決めておくこと
成果物の範囲	議事録の束で完了とされること	目次と各章の中身を別紙で示しておくこと
開発見積もりの精度	完了しても開発費の幅が狭まらないこと	完了時に出す見積もりの幅を条件にしておくこと
第三者への開示	他社に見せられず相見積もりが取れないこと	見積もり依頼と他社開発のための開示を認めておくこと
改変の可否	他社が手を入れた版を使えないこと	複製と改変を認め、翻案の権利も明記しておくこと
開発会社の既存資産	どこまでがノウハウかで揉めること	対象外の部分を成果物の中で示してもらうこと

ソースコードや仕様書の扱いも同じ考え方で決めておけます。詳しくはベンダー乗り換え前に確認する契約と資産にまとめています。

あわせて読みたい開発会社を変えたいのにソースコードも仕様書も手元にない｜業務システムのベンダー乗り換え前に確認する契約と資産

他社に渡しても、その会社の製品名で書かれていて見積もれません

開発会社が自社のパッケージや部品を前提に要件定義を進めると、「標準機能で対応」「○○モジュールを利用」といった書き方が並びます。こうした要件定義書を受け取っても、他社は中身を読み解けません。

防ぐには、業務として何が要るか（要件）と、それをどう作るか（方式）を別の章に分けてもらいます。他社に渡す前に、社内の誰か1人が読み手になり、各行がどの業務の話なのか分かるかを確かめておくと安心です。

要件定義が2月にずれ込み、来年度予算に開発費を載せそびれます

10月に発注すると、現場へのヒアリングが年末の繁忙期に重なります。そこで社内の確認待ちが続き、完了が後ろへずれていきます。予算編成の締めが2月中旬であれば、要件定義は1月末に終わっていなければ間に合いません。

対策として、12月末の時点で概算の開発費を中間成果物として出してもらいます。予算には、相見積もりで出る差の分も含めて幅を持たせて載せます。開発会社は4月以降に決めても間に合います。要件定義の費用を今期の経費にできるかどうかは、資産計上と下期の投資時期を参考に、顧問税理士にも確認してください。発注前には、次のような確認を開発会社へ送っておくと、あとで食い違いにくくなります。

件名：要件定義のお見積もりについて確認させてください

1. 要件定義書を、開発の相見積もりのために他社へ開示してもよいでしょうか。
2. 開示してよい場合、契約書のどの条項に書いていただけますか。
3. 完了時に、開発費の見積もりをどの程度の幅で出していただけますか。
4. 12月末までに、概算の開発費を中間でいただくことはできますか。

えらびの道は、卸売の受発注・請求、出張販売の管理、介護のシフト管理、ECサイトなどの業務システムをオーダーメイドで開発しています。データの可視化やレポートの自動化から、機械学習による予測やリアルタイムなデータ収集の基盤まで対応しています。要件定義だけを先にお受けする場合は、成果物の目次と他社への開示条件を契約の前に一緒に決め、ほかの会社が読んで見積もれる書き方で作成します。開発に入る場合も、小さく作って動かしながら育てる進め方をとっています。

要件定義を発注する前に、えらびの道でお手伝いできること

合同会社えらびの道は、中小企業向けのシステムの受託開発と、データ活用・DXの支援を本業にしています。これまでに、卸売の受発注・請求、介護のシフト管理、出張販売の管理、EC・決済といった仕組みを、要件の整理から開発まで手がけてきました。

開発会社から要件定義を有償で行う提案を受けている段階でも、作る側の目線で一緒に中身を確かめられます。成果物の目次をどこまで別紙に書くか、完了時の見積もりの幅をどう条件にするか、他社への開示と改変をどう認めてもらうかを整理します。要件と方式を章で分ける書き方も含めて、御社の業務と予算を組む時期に合わせて詰めていきます。

進め方としては、すべての業務を一度に固めるのではなく、止まると困る1業務から要件をまとめて動かし、残りは様子を見ながら移すことをお勧めしています。打ち合わせから開発まで同じ人間が担当するので、要件定義で決めたことが開発の途中で伝わらなくなるおそれを抑えられます。

発注を決める前に、ほかの開発会社の意見も聞いておきたいときは、えらびの道にご相談ください。オンラインで30分、費用はかかりません。提案書や契約書のひな形がお手元にあれば、それを見ながらお話をうかがいます。

よくある質問

要件定義だけを別の会社に発注してもよいですか？

発注できます。ただし、要件定義書を開発の相見積もりや他社での開発に使えるよう、複製・改変・第三者への開示を認める条項を契約に入れておく必要があります。入れておかないと、要件定義を担当した会社にそのまま開発も頼む以外の選択肢が狭くなります。

要件定義にはどのくらいの期間がかかりますか？

対象業務の数と、社内で確認を返す速さによって変わります。10月に発注して1月末に終える計画であれば、現場へのヒアリングを年末の繁忙期より前に済ませる日程を最初に押さえておくと、遅れにくくなります。

要件定義書の著作権は誰のものになりますか？

契約で決めていなければ、通常は作成した開発会社に残ります。譲渡を求める方法もありますが、相見積もりに使うだけであれば、発注側が複製・改変し、他社へ開示できる利用許諾を契約に明記する形でも足ります。