システム開発の発注完全ガイド｜流れ・要件定義・見積もり・契約

「システム開発を外部に発注したいが、何から手をつければいいか分からない」——初めての発注で必ずぶつかる悩みです。さらに、発注側に技術が分かる人がいないと、提案や見積もりが妥当なのかを判断できず、価格だけで選んでしまいがちです。結論から言うと、発注の成否は「契約してから」ではなく「契約する前」、つまり目的と要件をどれだけ整理できているかでほぼ決まります。

本記事では、発注の全体像を流れに沿って、各ステップでやること、見積もりの読み方、契約の選び方（一括か多段階か）、規模別の進め方、社内体制、よくある失敗までを解説します。あわせて、RFPの目次例・要件定義の洗い出し項目・見積もりチェック表・ベンダーへの質問例・検収チェック項目を、そのままコピーして使える形で載せています。まず、次の3点を押さえるだけでも、手戻り・追加費用・納期遅延の多くを防げます。

1. 1目的・要件を固めてから動く
2. 2RFPで各社を同じ条件で比較する
3. 3契約形態を工程に合わせて選ぶ（必要なら多段階で発注する）

システム開発の発注とは？まず全体の流れを押さえる#

システム開発の発注とは、自社の課題をシステムで解決するために、要件を整理し、開発会社（ベンダー）に依頼して、開発から運用までを進める一連の取り組みです。「会社を選ぶこと」と思われがちですが、実際にはその前後に複数の工程があり、成否の大半は会社選びの前で決まります。まずは下図の全体像を押さえ、各段階で何を判断すべきかをつかみます。

以下、各ステップを順に、発注側が「何を準備し、何を判断するか」に絞って具体的に見ていきます。

ステップ1：目的と優先度を整理する#

最初にやるべきは、ツール選びでも会社選びでもなく、「なぜ作るのか」の整理です。まず、次の3点を言語化します。

• 解決したい課題（いまどの業務が、どう困っているか）
• 対象業務と関係部署
• 達成したい状態（できるだけ測れる形にする。例：受注処理の時間を半分に、在庫差異をなくす）

あわせて、実現したいことを次の3つに切り分けておくと、後の見積もり比較や予算調整で判断がぶれません。

• Must（必須）
• Want（あれば良い）
• Won't（今回はやらない）

ここがあいまいなまま進むと、各社の提案を比較する基準を持てず、結局は価格だけで選んでしまいます。「何のために・何を・どこまで」を1枚にまとめるところから始めるのが、遠回りに見えて最短です。

ステップ2：要件定義で「何を作るか」を固める#

要件定義は、次の3つを具体化する工程です。

• 業務要件：どんな業務をどう変えるか
• 機能要件：そのために必要な機能（例：見積作成、在庫引き当て、承認フロー）
• 非機能要件：性能・セキュリティ・可用性・運用（例：同時利用者数、応答速度、バックアップ）

システム開発の失敗や手戻りは、この要件定義のあいまいさに起因することが多く、ここに時間をかけるほど後工程の負担が軽くなります。

要件定義で洗い出す項目（例）#

次の観点で洗い出すと、抜け漏れを防げます。そのままチェックリストとして使えます。

• 業務要件：対象業務／現状の業務フロー／困っていること／変更後のあるべき流れ／関係する部署・人
• 機能要件：必要な画面・帳票／扱うデータ項目／処理（登録・検索・承認・出力・外部連携）／利用者の権限
• 非機能要件：性能（同時利用者数・応答速度）／可用性（停止が許される時間）／セキュリティ（認証・権限・ログ）／運用・保守（バックアップ・監視）／データ移行（移行対象・量）

要件定義は発注側が主導し、実際に使う現場のキーマンを巻き込むほど精度が上がります。なお「要件がまだ固まらない」段階で無理にすべてを決めようとせず、PoC（試作）やプロトタイプで確かめながら固める、あるいは要件定義のフェーズだけ先に切り出して進める、という進め方も有効です（後述の多段階発注）。詳しい進め方は要件定義の進め方で解説しています。

ステップ3：RFP（提案依頼書）で各社を同じ土俵に乗せる#

RFPは、発注の目的・要件・前提・予算・評価軸・スケジュールをまとめ、各社へ同じ条件で提案を依頼する文書です。RFPがないと、会社ごとに前提のバラバラな提案・見積もりが返ってきて、比較になりません。逆にRFPを整えるだけで、提案の質が上がり、各社の理解度（要件をどれだけ読み解けているか）も見抜けます。

RFPの目次例（そのまま使えるひな形）#

最低限、次の項目を盛り込みます。コピーして自社の内容に置き換えれば、RFPの骨子になります。

1. 1案件概要（背景・目的・解決したい課題）
2. 2現状と課題（業務フロー・既存システム・データ量）
3. 3要件（業務要件／機能要件／非機能要件）
4. 4前提条件・制約（既存システム連携・利用環境・期間・予算感）
5. 5提案依頼事項（実施体制・実績・スケジュール・見積もり内訳・保守内容）
6. 6評価基準（何を重視して選ぶか）
7. 7スケジュール（説明会・質問受付期限・提案提出期限・選定時期）
8. 8提出方法・様式・問い合わせ窓口

記載項目とテンプレートの考え方はRFP（提案依頼書）の書き方でさらに具体的に解説しています。

ステップ4：ベンダーを選ぶ（5つの判断軸）#

提案が出そろったら、価格だけでなく次の5つの軸で総合的に比較します。

実績・専門性、要件定義力、意思疎通、費用の妥当性、保守体制の5つです。重要なのは、各軸を「どんな質問で見抜くか」までセットで準備すること。提案書のきれいさではなく、実力と相性が見えてきます。

各社に聞く質問例（5軸別）#

• 実績・専門性：「自社に近い業種・規模の開発実績は？そのとき御社が担当した範囲は？」
• 要件定義力：「要件のうち曖昧な点を、どう確認・補完して進めますか？」
• 意思疎通：「窓口体制と、進捗・課題の報告頻度・方法は？」
• 費用の妥当性：「この見積もりに含まれない作業は？追加費用が出るのはどんな時ですか？」
• 保守体制：「リリース後の保守の範囲・対応時間・費用はどうなりますか？」

各軸の見極め方は失敗しないシステム開発会社の選び方で整理しています。

ステップ5：契約形態を選ぶ（請負と準委任）#

契約は、成果物の完成責任を求めるなら請負（民法632条）、要件が動く前提で柔軟に伴走してほしいなら準委任（同656条ほか）が基本です。2020年の民法改正で、準委任には「履行割合型」と「成果完成型」の2類型が明確化され、選択の幅が広がりました。実務では「要件定義は準委任で密に、本開発は請負で」と工程ごとに分ける方法がよく使われます。それぞれの責任範囲や使い分け、注意点は請負契約と準委任契約の違いで解説しています。

一括発注か、多段階（分割）発注か#

契約と関連して、もう一つ重要な判断が「まとめて一括で発注するか、工程ごとに分けて発注するか」です。下図のイメージです。

要件が固まりきっていない段階で全工程を一括請負にすると、仕様変更のたびに追加費用や交渉が発生しがちです。そこで参考になるのが、独立行政法人情報処理推進機構（IPA）と経済産業省が公表する情報システム・モデル取引・契約書（第二版）｜IPAです。工程ごとに個別契約を結ぶ構造を前提に作られており、段階を分けて進めるときの下敷きになります。

具体的には、次のように工程を区切り、各段階の入口で内容と費用を確認しながら進めます。

1. 1要件定義（準委任）
2. 2設計・開発（要件が固まれば請負）
3. 3運用・保守

仕様が明確で動きにくい案件は一括でも問題ありませんが、新規性が高い・要件が動く案件ほど、多段階のほうが仕様変更の影響を小さく抑えられます。発注側に技術が分かる人がいない場合は、この区切り方や各段階の見積もりの妥当性を、外部の技術責任者にレビューしてもらう方法もあります。

ステップ6：開発・検収・運用まで#

契約後は、設計・開発・テストと進み、納品物が要件を満たしているかを発注側が確認する「検収」を行います。検収では、要件定義で決めた基準をもとに、機能が満たされているか、非機能（性能・セキュリティなど）に問題がないかを確認します。トラブルを避ける鍵は、検収基準（何をもって合格とするか）を契約・要件定義の段階で決めておくこと。これがないと「言った・言わない」になりがちです。

検収チェック項目（例）#

検収では、最低限このあたりを確認します。事前に要件定義書とつき合わせられるよう、項目を決めておきます。

• 機能要件を満たしているか（要件一覧と19つずつ突き合わせる）
• 非機能（性能・応答速度・セキュリティ）に問題がないか
• データ移行の結果（件数・内容が正しいか）
• 異常系・エラー時の挙動（想定外の入力で落ちないか）
• マニュアル・運用手順が揃っているか
• 障害時の連絡・対応フローが決まっているか

さらに、システムは公開して終わりではなく、運用・保守・改善が続きます。保守の範囲・費用・対応時間（SLA）を発注前に取り決めておくことが重要です。

発注費用はどう決まる？見積もりの内訳の見方#

費用は「開発工数 × 単価（人月単価）」が基本で、機能数・画面数・外部連携・非機能要件・体制によって大きく変わります。金額の一般的な目安としては、業務システムでおおむね100万〜1,500万円、保守・運用は年間で初期開発費の15〜20%程度がよく挙げられますが、これはあくまで目安で、要件の複雑さで上下します。

大切なのは、総額の大小ではなく「内訳」で見ることです。見積もりは、下図のように工程ごとの工数で構成されます。

見積もりチェック表（そのまま使える）#

見積書を受け取ったら、次の観点で確認します。相見積もりは、同じRFP・同じ前提で依頼してはじめて比較できます。

前提がそろわない見積もりを金額だけで比べると、安く見えて実は必要な作業が抜けている、ということが起きます。見積もりの妥当性を測る客観的な参考として、ソフトウェア開発分析データ集2022｜IPAがあります。5,546プロジェクトの実績データから、工数・工期・規模などの目安が業種別に整理されており、自社の見積もりが相場から大きく外れていないかを確かめる材料になります。費用の詳しい見方はシステム開発費用の相場で解説しています。

規模・タイプ別の進め方#

同じ「システム開発」でも、規模によって進め方・期間・体制・契約の組み方が変わります。

規模が大きいほど、要件定義に時間をかけ、多段階で進めるほうが安全です。どの規模でも共通するのは、「要件定義に十分な時間をかける」こと。ここを焦ると、後工程の手戻りで全体がかえって延びます。内製と外注のどちらで進めるかを迷う場合は内製と外注どっちがいい？もあわせてご覧ください。

ウォーターフォールとアジャイル、どちらで進める？#

進め方には、要件をすべて固めてから順に作る「ウォーターフォール（一括）」と、小さく作って動くものを見ながら要件を詰める「アジャイル（段階的）」があります。仕様が固く、作るものが明確なら一括（請負契約）、要件が動く・新規性が高いならアジャイル（準委任で伴走）、というように案件の性質で選びます。どちらが優れているということではなく、「要件がどれだけ固まっているか」で向き・不向きが決まります。要件が固まっていない段階を一括請負にすると、仕様変更のたびに追加費用が発生しがちです。

発注を進める社内体制#

発注は、担当者一人で進めるより、役割を決めて体制を組むほうが成功します。最低限、次の役割を巻き込みます。

• 旗振りをする発注担当
• 実際にシステムを使う現場のキーマン
• 予算・仕様を決められる意思決定者

既存システムとの連携がある場合は、情報システム部門も関わります。ベンダーとのやり取りは窓口を一本化し、「誰が何を決めるか」を明確にしておくと、意思決定の遅れによる失敗を防げます。逆に、現場が関与しないまま進めると、「作ったのに使われない」システムになりがちです。

課題になりやすいのが、「社内に技術が分かる人がいない」ケースです。この場合、見積もりの妥当性やベンダーの提案を評価できず、丸投げになりがちです。対策として、外部の技術責任者（スポットCTO）に、発注側の立場で要件・見積もり・進捗をレビューしてもらう方法があります。詳しくは開発の外注先をうまく管理できない（ベンダーコントロール）、スポットCTOとはもご覧ください。

よくある失敗と、その回避策#

発注でよくある失敗は、次の4つに集約されます。

• 要件があいまいなまま相見積もりを取る
• 条件を揃えずに各社へ依頼する
• 現場を巻き込まず「作ったのに使われない」
• 検収基準・保守を後回しにする

いずれも、要件定義に時間をかけ、RFPで条件をそろえ、検収基準を先に決めることで防げます。技術力そのものより、要件の詰めと意思疎通で差がつく、と考えておくのが実務的です。よくある失敗とその回避策はシステム開発が失敗する理由で整理しています。

発注で失敗しないためのチェックリスト#

発注前に、最低限このあたりが揃っているかを確認しましょう。

目的・優先度の言語化、RFPの作成、2〜3社での比較、内訳・追加費用の確認、保守体制の確認——この5点が揃っていれば、価格だけに振り回されない発注ができます。逆に、要件があいまいなまま相見積もりを取る、条件を揃えずに各社へ依頼する、保守の取り決めを後回しにする、といった進め方は失敗のもとです。

弊社（株式会社TryWith）の開発支援について#

弊社では、システムの受託開発に加えて、発注の前段となる目的・要件の整理、RFP作成、ベンダー選定、見積もりの妥当性チェックまで、発注側の立場でご支援しています。企画・設計・開発・導入・保守まで一貫して対応できる体制で、「何を作るか」だけでなく「なぜ作るか」から一緒に整理します。社内に技術が分かる人がいない場合も、スポットCTO的な関与で、要件・見積もり・ベンダー管理を発注側の視点で補えます。「発注の進め方から相談したい」「もらった見積もりの妥当性を見てほしい」といった段階でも、お気軽にご相談ください。

よくある質問（FAQ）#

Q. システム開発の発注は何から始めればいいですか？

A. 会社選びより先に、「目的と要件の整理」から始めます。解決したい課題と、機能の優先度（Must／Want）を言語化し、RFPにまとめてから各社へ依頼すると、提案を同じ条件で比較できます。

Q. 発注から納品まではどれくらいかかりますか？

A. 規模によりますが、小規模で数か月、中〜大規模では半年〜1年以上かかることもあります。要件定義に十分な時間をかけるほど後工程の手戻りが減り、結果的に全体期間が安定します。

Q. 一括発注と多段階（分割）発注はどう違いますか？

A. 一括は要件を固めてからまとめて発注する方法、多段階は要件定義・設計開発・運用などを工程ごとに分けて発注し、段階ごとに見積もり直す方法です。IPAと経済産業省のモデル契約も、工程ごとに個別契約を結ぶ構造を前提にしています。新規性が高い案件ほど多段階が向きます。

Q. 見積もりが妥当かどうかは、どう見分けますか？

A. 総額ではなく内訳で見ます。工程別（要件定義・設計・開発・テスト・保守）に分かれているか、人月数と単価が妥当か、含まれない作業は何かを確認し、同じRFP・前提で相見積もりを比べます。IPA「ソフトウェア開発分析データ集」も相場の参考になります。

Q. 社内に技術が分かる人がいなくても発注できますか？

A. できますが、見積もりや提案の妥当性を判断しづらく、丸投げになりがちです。外部の技術責任者（スポットCTO）に発注側の立場で要件・見積もり・進捗をレビューしてもらうと、技術が分かる人がいなくても対等に進められます。

Q. 要件が固まっていなくても発注できますか？

A. できます。その場合は、要件定義のフェーズを準委任契約で先に進め、要件が固まってから本開発を請負契約で、という多段階の分け方が有効です。

Q. 費用を抑えるにはどうすればいいですか？

A. 機能の優先度を絞り、Mustから段階的に作るのが基本です。安さだけで選ぶと要件の取りこぼしで追加費用が増えがちなので、総額ではなく内訳と範囲で比較してください。

Q. 発注先は何社くらい比較すべきですか？

A. 一般には2〜3社程度が現実的です。同じRFPで依頼し、提案の内訳と要件の理解度で比較します。多すぎると比較・対応の負担が増えます。

まとめ#

システム開発の発注は、目的・要件の整理 → RFPで条件をそろえる → 5つの軸でベンダーを比較 → 工程に合わせた契約（必要なら多段階発注）→ 検収・運用、という流れで進めます。成否を分けるのは契約後の管理よりも、発注前の準備です。本記事のRFP目次例・要件定義の洗い出し項目・見積もりチェック表・検収チェック項目を、自社の発注準備にそのままお使いください。見積もりは総額ではなく内訳で見て、規模に合った進め方を選び、社内体制を整える——この基本を押さえれば、価格だけに振り回されず、運用まで任せられるパートナーと進められます。社内に技術が分かる人がいない場合は、外部の技術責任者の関与も選択肢になります。

（出典：情報システム・モデル取引・契約書（第二版）｜IPA・経済産業省（2020年12月22日公表）、ソフトウェア開発分析データ集2022｜IPA）

発注の進め方や要件整理、見積もりの妥当性チェックでお困りの場合は、現状の課題整理からご相談いただけます。まずはお問い合わせはこちらからお気軽にご相談ください。