小規模システムの発注は、課題を定め、RFP（提案依頼書）と要件を固め、見積と検収基準を確かめる順に進めると、現場で使えるシステムにつながります。
RFPと要件定義書の書き方を、発注側の視点で順に見ていきます。
▼全体ガイドの記事
・小規模システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
小規模ならではの要件粒度の決め方
要件定義は、全工数の約20%、工期の約25%を占めるとされます（出典：IPAソフトウェア開発データ白書）。そのため小規模でも、工程を軽くしつつ的確に進める必要があります。
大規模システムのように分厚い資料を作ると、小規模では要件定義だけで予算を使い切るおそれがあります。
まずは、要件の粒度を誤らないことが出発点です。
解決したい課題からの要件の逆算
機能を並べる前に、どの業務の困りごとを解決するのかを明確にします。そこから必要な機能を逆算すると、課題に結び付く要件だけを最小限に絞れます。
- 課題を起点にする：解決に必要な機能だけを残す
- 数値目標を置く：投資で達成したい目標を数字で書く
- 対象外を見極める：課題に結び付かない要件を、削る候補として洗い出す
たとえば、月次集計に2日かかる課題なら、集計の自動化に要件を絞れます。一方で、「あったら便利」を起点にすると機能が増え、中規模帯の300万〜700万円超に膨らむことがあります。
発注側は、要件定義書の冒頭に、解決したい課題と数値目標を書いておきます。
現場ヒアリングで拾う暗黙のルール
要件定義の質は、現場ヒアリングの丁寧さで決まります。
担当者には、普段の仕事の進め方を一つずつ聞き取ることが欠かせません。
- 現在の業務：担当者が今どう処理しているか
- 困りごと：無駄や手戻りが起きやすい箇所
- 例外処理：月末や特定の取引先の扱い
通常の処理は仕様に書きやすいものの、暗黙のルールや例外は、聞かなければ表に出てきません。拾い損ねると、現場から「うちの業務はこうじゃない」と拒まれることがあります。
特に注意したいのは、ベテラン社員が頭の中だけで処理している例外パターンです。
要件が曖昧なまま開発すると、工数が1.3〜1.5倍に膨らむというデータもあります。
だからこそ小規模システムでも、最初のヒアリングに時間をかけて例外まで固めることが、手戻りと費用増を防ぎます。
「やらないこと」の要件定義書への明記
要件の粒度を絞るには、「やらないこと」を明記するのも有効です。
対象外とする業務や自動化、連携を、要件定義書に書き込んでおきます。
- 対応しない業務：今回の範囲から外す業務
- 自動化しない範囲：今回は手作業のまま残す業務
- 連携しないシステム：対象外とする連携先の明示
スコープの外側を言葉にしておくと、「これもついでに」という追加要望が出たときの線引きの根拠になります。そうした要望は、次フェーズの検討事項として分けて扱えます。
開発の途中で要件が増えるスコープクリープは、小規模システムが膨らむ大きな原因です。
やらないことも含めて合意し、初期範囲を守ることが、予算内に収める有効な手立てになります。
RFPに必ず書くべき項目
RFP（提案依頼書）は、作りたいものをベンダーに伝え、見積と提案を得る文書です。
小規模であっても、RFPを作るかどうかで見積の精度と提案の比べやすさが大きく変わります。
背景・目的・機能・予算・スケジュール
RFPに最低限書く項目は、提案の前提を揃えるために欠かせません。
- 背景と目的：導入の背景、解決する課題、システムのゴール
- 機能と予算：優先順位を付けた機能一覧と想定予算
- 実施条件：希望日程、既存システムやSaaSとの連携、保守運用の希望
これらの項目を一通り記しておくと、ベンダーは前提を共有し、現実的な提案を返せます。
予算を伏せたままだと、過剰な提案と最小限の提案が混ざり、比較が難しくなります。
小規模システムでは、おおまかな予算の幅を示しておくことをおすすめします。たとえば「300万〜800万円の範囲で課題を解決したい」と幅を示すと、その範囲で提案を得られます。
予算を示すことは、提案を絞り込むための手段です。
値切られる弱みを見せるものではありません。
契約形態と著作権の扱いの明記
契約形態と成果物の権利をRFPで示しておくと、ベンダーは見積の前提を揃えやすくなります。
- 契約形態：請負か準委任かの区分
- 著作権：成果物の譲渡、または利用・改修権の定め
請負契約は完成責任を負い、準委任契約は善管注意義務を負います。
完成を重視する小規模システムでは、請負が基本になります。
請負では、完成責任のリスクが見積に含まれ、人月計算に1.3〜1.5倍の係数がかかるのが一般的です。
著作権を取り決めない場合は、開発したプログラムの著作権が原則として受託者に帰属します（著作権法）。
このため、別のベンダーに改修を頼む可能性に備えて、発注者への譲渡か改修・利用権を契約に定めておきます。
ソースコードの権利は、RFPと契約の段階で確かめておきます。契約後になってから交渉すると、難しくなります。
見落とされがちな非機能要件
機能要件の検討は進みやすい一方で、非機能要件が抜けてしまうケースもあります。非機能要件とは、性能・セキュリティ・運用に関する要件のことです。
小規模システムであっても、非機能要件を曖昧にしたままだと、リリース後のトラブルや追加費用につながります。
性能・データ量・セキュリティの解像度
設計と見積の前提を揃えるため、性能や情報保護の条件を具体化しておきます。
- 利用規模：想定する同時利用者数と将来の利用者数
- 性能：扱うデータ量と許容する応答速度
- 安全性：情報の機密度に応じたセキュリティ水準
RFPと要件定義書に条件を書いておくと、過不足のない設計と見積につながります。
たとえば、社内10人で使うか将来100人に広げるかで、必要な設計は変わります。数人を前提に作ったあとで大人数に広げると、作り直しになりかねません。
個人情報や決済情報を扱う場合は、暗号化とアクセス制御の水準を要件定義書に記しておきます。水準が曖昧なまま発注すると、後からセキュリティを強化する追加費用が生じることがあります。
非機能要件の解像度を上げ、早く決めるほど、後からの追加費用を防ぎやすくなります。
運用・保守とSLAの範囲の事前決定
運用を始めてから揉めないよう、SLA（サービス品質保証）を含む保守条件は、要件定義の段階で決めておきます。
- 障害対応：初動までの時間の取り決め
- 更新作業：OSやライブラリの更新を、保守の範囲に含めるかどうか
- 対応条件：保守範囲と費用、対応時間
保守費用は、年あたり開発費の15〜25%が目安です。
小規模システムでは保守が軽く見られがちですが、停止したときの対応体制は業務にとって重要です。範囲が曖昧だと、リリース後に契約外の扱いとして問題になることがあります。運用まで見据えて要件を定めることが、長く使える小規模システムの条件になります。
データ移行とインフラ費用の要件への組み込み
移行作業や運用費が見積から漏れないよう、データとインフラの条件は事前に固めておきます。
- 移行対象：データの範囲と量
- 移行準備：データ整形の担当、リハーサルの有無
- 運用費：サーバー、外部API、ドメイン、SSLの費用
Excelや旧システムから移す範囲が決まっていないと、移行作業が見積の外に置かれ、想定外の費用が発生します。
また、クラウドのサーバー代、外部APIの利用料、ドメインやSSLの維持費は、開発費とは別に毎月かかります。合計すると、無視できない金額になることもあります。
こうした隠れたコストは、先に一覧にして毎月の費用を試算しておきます。そのうえで、初期費用と運用費の総額で費用対効果を判断します。
見積妥当性とAI時代の検収基準
要件とRFPが固まったら、見積の妥当性を確かめます。この判断ができないと、安すぎる見積や高すぎる過剰提案を見抜けません。
AIがコードを書く時代には、検収（成果物の受け入れ確認）にも新しい基準が必要です。
そのため、成果物を受け入れる検収基準も定めておく必要があります。曖昧な基準のままでは、検収後に起きる問題を見逃しかねません。
人月単価と工数から読む見積の妥当性
見積の妥当性を読むには、人月単価と工数の相場感が役立ちます。単価や工数に偏りがないかも、あわせて確かめます。
- フリーランス：人月単価50万〜80万円が目安
- 中小開発会社：人月単価80万〜120万円が目安
- 大手SIer：人月単価150万〜200万円が目安
小規模システムでは、中小開発会社が現実的な選択肢になります。
相場から大きく外れて安い見積は、何かを削っている可能性があります。
健全な見積には、全体の10〜20%程度のリスクバッファが含まれています。バッファがないと、想定外の事態が起きたときに追加請求や品質低下を招きます。
そのため、機能ごとの工数、人月単価、バッファの有無を確かめます。不自然に安い項目や過剰な項目も調べます。
発注を検討する企業の約4〜5割が「費用対効果が分からない」ことを課題視しているというデータもあります。
見積を読む力は、ムダな投資を防ぐことにつながります。
AI生成コードを前提とした検収基準
AI生成コードの品質を確かめるには、検収基準を要件定義の段階で文書にしておきます。
- 業務シナリオ：主要な業務が正しく動くかどうか
- 異常入力：想定外の入力を安全に処理できるか
- セキュリティ：安全性に問題がないか
AI活用は、納期と費用を抑えたい小規模開発と相性がよい一方で、検証が不足したコードが納品されるリスクもあります。
見た目は動いていても、脆弱性や想定外の入力での誤動作が残ることがあります。
最終的な品質責任はベンダーが負います。発注側は、人がレビューしたものを納品するよう、契約で担保しておきます。
riplaは、フルスクラッチ受託と国内開発の立場から、AIを活用しつつ人によるレビューを重視しています。
要件定義から検収基準を明確にする進め方も支援しています。
検収を段取りよく進めるための取り決め
検収を段取りよく進めるには、次の項目を要件定義書で取り決めておきます。
- 検収期間：確認に何日確保するか
- 不具合修正：無償で直す範囲
- 完了判定：誰がどの書面で判定するか
検収基準が決まったら、実施手順も要件定義の段階で固めておきます。判定方法やテストの進め方は、事前に取り決めます。
小規模システムでは検収を軽く済ませがちです。基準が曖昧だと、リリース後の不具合対応が有償か無償かで揉めることになります。
テストデータと業務シナリオは、発注側で用意します。ベンダー任せだと、実務とかけ離れた条件で試験され、利用開始後に問題が起きることがあります。
典型的なデータに加えて、月末処理や例外取引など負荷の高いパターンも用意します。それらで動くことを確かめたうえで、検収を完了します。
この段取りを要件定義書に記しておくと、品質を最後に確かめやすくなります。
規模別の要件粒度の使い分けと進め方
300万円規模と800万円規模のシステムでは、要件定義のかけ方が変わります。投資額と業務の重要度に応じて、粒度を調整します。
分厚い資料を一律に作るより、規模に合う量を選ぶことが、コストと品質のバランスを取る鍵です。
金額帯ごとの要件定義のかけ方
金額帯によって要件定義書に書き込む範囲は変わるため、金額と業務の重要度を見極め、規模に見合う詳しさを選びます。
- 300万円前後：数ページの要件定義書で進める
- 700万〜800万円帯：業務フローや連携仕様まで記した要件定義書
- 工数配分：業務の重要度に応じた厚みの調整
相場は、MVP（必要最小限の構成）が300万〜800万円、SFA・CRM系が300万〜700万円程度とされます。
300万円前後の最小構成では、課題、主要機能、想定利用者数、最低限のセキュリティ要件を押さえます。細部は、開発を進めながら詰めていきます。
700万〜800万円帯で基幹業務に近いシステムを作る場合は、そこまで書き込むことで、見積の精度が上がり、認識のずれも減ります。
要件定義は全工数の約20%が目安です。ただし、重要な業務では比率を厚くし、試験的な小さなシステムでは薄くします。
MVPから段階拡張する要件の組み方
小規模システムでは、全機能を最初から盛り込むのではなく、MVPで始めて段階的に拡張します。
- 初期機能：最初のリリースに必須の範囲
- 将来機能：追加候補と拡張方針の共有
第1フェーズの要件だけを固めて開発すると、初期投資を抑えられます。さらに、実際に使った結果を、次の要件に反映できます。
将来100人規模に広げる可能性があるなら、要件定義書に記してベンダーへ伝えておきます。そうすれば、後の作り直しを避ける設計につながります。
最初の要件を絞り、拡張の見通しを共有する二段階の進め方が、システムをムダなく育てる鍵になります。
要件が曖昧だと工数が1.3〜1.5倍に膨らむというデータもあります。だからこそ、各フェーズで要件を明確にすることが、費用を抑えることにつながります。
まとめ
小規模システムでは、解決したい課題から要件を絞り、現場の例外を拾ってRFPに記していきます。あわせて、非機能要件、契約、権利、保守の条件も事前に決めておきます。
見積は、単価、工数、バッファを見て妥当性を確かめます。AIを使う場合も、検収基準を契約に盛り込み、要件を段階ごとに明確にします。
大切なのは、小規模だからといって軽く済ませることではなく、必要な範囲へ的確に絞ることです。非機能要件や契約、権利、保守についても、押さえておくことが欠かせません。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、課題の言語化から要件定義、見積の確認、検収基準づくりまで支援します。
課題から要件を絞り、RFPと非機能要件を固めて、見積と検収まで進める段取りが、小規模でも狙いどおりのシステムにつながります。
▼全体ガイドの記事
・小規模システムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。