システム開発の発注は、家を建てるよりも難しいと言われます。
お見積りの見方、契約の種類、要件の伝え方...。
発注者が知っておくべき「武器」を、ここですべて公開します。
ステム開発会社にお見積りを依頼するとき、「こんなシステムを作りたいんです」と口頭で伝えていませんか？
それは、レストランで「美味しいものを作って」と注文するようなものです。
出てくる料理も、値段も、あなたの想像とは全く違うものになるでしょう。
RFP (Request For Proposal) とは、発注者が開発会社に対して「こういうシステムを作ってほしい」という要件を文書化したものです。
これがないと、開発会社は「リスク」をお見積りに上乗せします（バッファ）。
精度の高いRFPを用意することは、そのままコストダウンに直結するのです。
A社は300万円、B社は1000万円。同じ要件を伝えたはずなのに、なぜこれほど差が出るのでしょうか？
安いからといって飛びつくと、後で「追加請求」の嵐に見舞われることになります。
IT業界の多くのお見積りは「人月（にんげつ）」で計算されます。
1人のエンジニアが1ヶ月働く値段（単価）と、完成までにかかる期間（工数）です。
安さの裏には理由があります：
経験の浅いジュニアエンジニアが担当する可能性があります。
品質が低く、バグだらけになるリスクがあります。
「テスト工程」や「要件定義」を省いている可能性があります。
あるいは、要件を過小評価しており、後で「それは別料金です」と言われるリスクがあります。
契約形態の選択を間違えると、プロジェクトは地獄と化します。
それぞれのメリット・デメリットを理解し、フェーズによって使い分けるのが正解です。
| 契約形態 | 対価の対象 | 特徴・向いているフェーズ |
|---|---|---|
| 請負契約 | 成果物の 完成 |
完成責任あり。要件が完全に固まっている場合に有効。 ただし、後からの仕様変更は原則不可（別料金）。 推奨：明確なウォーターフォール開発 |
| 準委任契約 (SES/ラボ) |
業務の 遂行 |
完成責任なし。エンジニアの時間/技術力を買う。 仕様変更に柔軟に対応できるが、完成しなくても費用は発生する。 推奨：アジャイル開発、要件定義、保守運用 |
💡 Pro Tip:
「要件定義」はスコープが見えないため準委任契約で行い、要件が固まった後の「製造」は請負契約で行う、というハイブリッド方式も一般的です。
ここまで読んで、「やっぱり難しそうだ」と感じたら。
私たちがあなたの代わりにRFPを書き、ベンダーを選定し、プロジェクトを管理します。