Webシステム開発の発注プロセス完全ガイド——構想・RFP・検収まで発注者がやるべきことを全解説

Webシステムの開発を発注しようとしたとき、「何から始めれば良いのか」「RFPって何？」「検収はどうやればいいの？」と壁にぶつかった経験はありませんか。

Webサイト（LPやコーポレートサイト）の発注と違い、システム開発の発注には独特のプロセスがあります。要件定義・RFP・請負契約・準委任契約・UAT（ユーザー受入テスト）・検収——これらの言葉は知っていても、「自分が何をすれば良いのか」が分からないまま動き始めてしまうと、後から大きなトラブルに発展しがちです。

その難しさは、発注者側が業務の専門家であってもシステム開発の「発注プロセス」に不慣れなことが多いからです。そして残念ながら「丸投げしたら後はベンダーが何とかしてくれる」という期待は、多くの現場で裏切られます。

でも安心してください。発注プロセスを一度正しく理解してしまえば、初めての発注でも自信を持って進められます。本記事では、Webシステム開発の発注プロセスを構想段階からRFP作成・提案比較・要件定義・開発中の関与・検収・保守契約まで、発注者がやるべきことをフェーズ別・チェックリスト形式で解説します。

Webシステム開発の発注プロセスとは——全体像を把握しよう

まずは全体の地図を頭に入れましょう。Webシステム開発の発注プロセスは、大きく以下の8つのフェーズに整理できます。

フェーズ	主な内容	発注者の関与度
1. 構想・要件の整理	目的・課題・機能要件の社内整理	高（主導）
2. RFP作成・提案依頼	開発会社への条件提示と提案依頼	高（主導）
3. 提案比較・発注先決定	複数社の評価と契約	高（意思決定）
4. 要件定義	機能仕様の確定と合意	高（主役）
5. 設計・開発	実装（ベンダー主体）	中（確認・承認）
6. 開発中の進捗確認	定例ミーティング・仕様変更対応	中（意思決定）
7. テスト・検収	受入テストと納品確認	高（主導）
8. 納品・保守契約	成果物受領と継続体制の整備	高（意思決定）

SCROLL→

Webシステム開発の発注プロセス——8つのフェーズ

上の表を見ると分かるように、発注者が「主導」または「高い関与度」で動くフェーズが大半を占めます。「発注したらベンダーが何とかしてくれる」と思っていると、要件定義段階での認識ズレや検収時の不具合発見が深刻なトラブルになります。

ただし、「全部自分でやらなければいけない」というわけでもありません。重要なのは、どのフェーズで何を決断する責任が発注者にあるかを理解した上で、ベンダーと適切に役割分担することです。

発注者とベンダー、それぞれの役割とは

発注プロセスにおける役割の基本的な考え方は以下のとおりです。

• 発注者の役割: 業務知識・課題・目標の提供。意思決定とGO/NO-GOの判断。成果物の検証と受入
• ベンダーの役割: 技術的な実装。プロセスの進行管理。成果物の品質担保

「業務のことは発注者が一番よく知っている」というのが大前提です。だからこそ、要件定義や検収では発注者が主役になります。

フェーズ1——構想・要件の整理（社内でやるべき最初の仕事）

発注前にまず行うべきことは、社内での要件整理です。このフェーズを省略・手抜きすると、後のすべてのフェーズがうまくいきません。

「何を作りたいか」より先に「なぜ作るか」を固める

多くの発注者が陥る落とし穴は、「作りたい機能の話」から入ることです。たとえば「顧客管理の機能が欲しい」「メール配信を自動化したい」という機能の話よりも先に、「なぜそのシステムが必要なのか」「どんな課題を解決するのか」を明確にすることが重要です。

目的が曖昧なままでは、提案を受けた開発会社も的外れな提案しかできません。また、後になってから「こんなはずじゃなかった」という後悔につながります。

まず以下の問いに答える時間を作りましょう。

• このシステムで解決したい業務上の課題は何か
• 誰が（どのユーザーが）どういう場面で使うのか
• システム導入後に何が変わっていれば「成功」と言えるか（KPI）
• 予算の上限はいくらか。リリース希望時期はいつか

社内要件整理のためのヒアリングと業務フロー可視化

「システム化したい業務」については、実際にその業務を行っている担当者から現状のフローを聞き出すことが不可欠です。現状の業務フローが分からないままシステムを作ると、「使いにくいシステム」ができあがります。

業務フローの可視化には、フローチャートや箇条書きのシンプルな形でも構いません。「誰が・何を・どの順番で・どんな条件で」という情報を整理できれば十分です。

発注前に揃えるべき情報チェックリスト

以下の項目を社内で揃えてから、開発会社への問い合わせに進みましょう。

• システム化の目的・課題（なぜ必要か）
• 主な利用者と利用シーン
• 必須機能の概要（詳細でなくてよい）
• あれば嬉しい機能（任意）
• 予算の上限（概算でOK）
• リリース希望時期
• セキュリティ・個人情報に関する要件（ある場合）
• 既存システムとの連携有無

フェーズ2——RFP（提案依頼書）の作成と開発会社への提案依頼

「RFPを送ってください」と言われて戸惑う発注者は多いですが、恐れる必要はありません。RFPは「こんなシステムを作りたいので、提案と見積もりをください」という文書です。

RFPとは？——要件定義書・仕様書との違いを整理

ドキュメント	作成者	タイミング	目的
RFP（提案依頼書）	発注者	開発会社への依頼時	提案・見積もりを比較するための条件提示
要件定義書	発注者 + ベンダー	契約後の要件定義フェーズ	開発する機能・仕様の詳細な合意
仕様書	ベンダー	設計フェーズ	実装の詳細仕様（技術的なドキュメント）

SCROLL→

RFPは完璧に書く必要はありません。複数社に「同じ条件」で提案を依頼するための土台となる文書です。詳細な仕様はRFP後の要件定義フェーズで固めていきます。

RFPに必ず盛り込むべき7つの項目

1. プロジェクトの背景・目的: なぜこのシステムが必要なのか
2. 主な機能要件: 必須機能と任意機能を分けて記載
3. 非機能要件: 想定ユーザー数・セキュリティ要件・パフォーマンス目標など
4. 予算規模: 「〇〇万円以内」という上限の提示（ざっくりでOK）
5. スケジュール: リリース希望日・提案書提出期限
6. 成果物の定義: 何を納品してもらいたいか（ソースコード・ドキュメント・テスト結果など）
7. 選定基準: どんな観点で発注先を選ぶかの評価軸

RFPなしで発注できる？——初回から完璧を目指さなくていい

小規模な開発や初期の相談段階では、RFPなしで「ざっくり相談」から始めるアプローチもあります。特に要件が固まっていない段階では、開発会社と一緒に要件を整理する形が現実的です。

ただし、複数社に同時に提案を依頼して比較したい場合は、RFPを用意することで比較の公平性を保てます。各社が「同じ条件」で提案できる状態を作ることが、正しい比較評価の前提です。

フェーズ3——提案書・見積もりの比較評価と発注先の決定

複数社から提案書と見積もりが集まったら、いよいよ比較評価と発注先の決定です。このフェーズでの判断ミスが、後の大きなトラブルにつながることがあります。

提案書・見積もりの比較で見るべき5つのポイント

1. 技術的な適合性: 必須機能の実現方法が具体的に記載されているか。曖昧な提案は後から問題になりやすい
2. 類似案件の実績: 同規模・同業種のシステム開発実績があるか。実績なしの挑戦はリスクになり得る
3. コミュニケーション体制: 担当PM（プロジェクトマネージャー）は誰か。週次報告などの定例体制が明示されているか
4. 保守・アフターサポート: リリース後の保守体制と費用が明示されているか
5. 価格の根拠: 工数（人日）と単価の内訳が明確か。「一式〇〇万円」という提示のみの場合は内訳を確認する

価格だけで選ぶと、後から「実はこの機能は別途費用」という追加請求が発生するケースがあります。安い見積もりには理由があることが多く、見積もりに含まれる範囲（スコープ）を必ず確認してください。

請負契約 vs 準委任契約——どちらを選ぶべきか

システム開発の契約には大きく2種類があります。

契約形態	報酬発生条件	ベンダーの責任	向いているケース
請負契約	成果物の完成	契約不適合責任あり	機能・仕様が明確に決まっている場合
準委任契約	業務の遂行	契約不適合責任なし	仕様が未確定・要件定義から一緒に進める場合

SCROLL→

一般的に、要件定義フェーズは準委任契約、詳細設計・開発フェーズは請負契約という組み合わせが多く用いられます。

仕様が固まっていない段階で「全工程請負」で契約すると、ベンダー側が仕様変更に対応しにくくなり、追加費用の原因になります。

発注先決定前に確認すべきコミュニケーションの質

提案書の内容だけでなく、「このベンダーと一緒に仕事をしたい」と思えるかも重要です。提案プレゼンや質疑応答の場で以下を確認しましょう。

• 質問に対して分かりやすく答えてくれるか
• 懸念点を正直に伝えてくれるか
• プロジェクト全体を俯瞰した視点でアドバイスをくれるか

開発期間は数ヶ月〜1年以上にわたることも多く、日常的なコミュニケーションのしやすさがプロジェクト成否を左右します。

フェーズ4——要件定義への参加——発注者の最重要タスク

要件定義は、発注者にとって最も重要で、最も関与すべきフェーズです。「要件定義はベンダーがやるもの」という誤解が、後のトラブルの大きな原因になります。

要件定義は発注者が主役——業務知識のオーナーとして関わる

要件定義とは、「このシステムで何ができるか」を詳細に定義するフェーズです。画面の構成・操作フロー・データの持ち方・システム間の連携など、実装の前提となるすべての仕様を文書化します。

ここで重要なのは、「業務のことを一番よく知っているのは発注者側」という事実です。ベンダーは技術の専門家ですが、あなたの会社の業務フローや顧客の特性を詳細には知りません。

発注者の役割は以下のとおりです。

• 業務知識・業務フローの提供
• 画面・機能の要件に対する承認
• 優先順位の決定（予算・期間との兼ね合い）
• 「使う人」の観点からのフィードバック

機能要件・非機能要件の確認ポイント

要件定義では「機能要件」と「非機能要件」の2種類を確認します。

機能要件: システムが「何をするか」

• どんな画面があるか
• データをどのように入力・表示・出力するか
• どんな処理・計算・連携が必要か

非機能要件: システムが「どのような条件で動くか」

• 同時接続ユーザー数の上限
• ページの表示速度
• セキュリティレベル（ログイン認証・データ暗号化など）
• バックアップ・障害復旧の要件

非機能要件は見落とされがちですが、後から変更しにくい要素です。特にセキュリティ要件や個人情報の取り扱いについては、この段階でしっかり確認しておきましょう。

要件定義書のサインオフ前に確認すべきこと

要件定義書が完成したら、正式に合意（サインオフ）する前に以下を確認してください。

• 必須機能が全て盛り込まれているか
• 業務フローとシステムの操作フローが一致しているか
• 現場の担当者（実際に使う人）がイメージを持てるか
• スコープ外（今回は作らないもの）が明記されているか
• 追加・変更が発生した場合の費用・工数の取り扱いが明示されているか

サインオフ後の仕様変更は追加費用と工期延長の原因になります。「後で何とかなる」は禁物です。

フェーズ5〜6——開発中の進捗確認と意思決定

契約・要件定義が完了し、実際の開発が始まったフェーズです。開発はベンダー主体で進みますが、発注者の関与が完全に不要というわけではありません。

開発中の定例ミーティングで確認すべきこと

週次または隔週の定例ミーティングを設定し、以下を確認する習慣をつけましょう。

• スケジュールは予定通りか（遅延があれば早期に把握）
• 発注者側が判断を求められている事項はあるか
• 懸念事項・リスクの共有
• 次回ミーティングまでに発注者が対応すべきこと

「問題が起きたら教えてください」だけでは不十分です。定期的な場を設けることで、小さな問題が大きくなる前に対処できます。

仕様変更の依頼は慎重に——スコープクリープを防ぐ方法

開発中に「やっぱりこの機能も追加したい」「ここを変えたい」という要望が出るのは自然なことです。しかし、安易な仕様変更（スコープクリープ）はコストと工期に直接影響します。

仕様変更が発生した場合のルールを事前に決めておきましょう。

1. 変更内容を書面で記録する
2. ベンダーから追加工数・費用の見積もりを取る
3. 優先順位を判断し、今回に含めるかどうかを決定する
4. 合意した内容を書面（変更合意書）に残す

「口頭でOKと言った」「なんとなく追加してもらった」という曖昧な対応が、後から「言った・言わない」問題に発展します。

発注者が迅速に判断すべき「承認事項」とは

開発中、ベンダーから発注者への確認・承認依頼が随時発生します。これらへの対応が遅れると開発がストップします。代表的な承認事項は以下のとおりです。

• UIデザインの確認・承認（モックアップ・プロトタイプへのフィードバック）
• 機能の実装方針に関する選択（A案 vs B案）
• 外部サービス・APIとの連携方法の確認
• セキュリティ仕様に関する確認（個人情報の取り扱い方針など）

承認担当者を社内で事前に決め、「誰が何を承認するか」の権限を明確にしておくことが重要です。

フェーズ7——テストと検収——納品前の最終関門

開発が完了したら、いよいよテストと検収フェーズです。ここでは、発注者が主体となってシステムを検証する「UAT（ユーザー受入テスト）」を実施します。

UAT（ユーザー受入テスト）の設計——発注者が行うテストの作り方

UATとは、開発されたシステムが要件通りに動作するかを発注者側で検証するテストです。ベンダーが行う「単体テスト」「結合テスト」とは異なり、「実際の業務で使えるか」を確認することが目的です。

UATの手順は以下のとおりです。

1. テストシナリオの作成: 実際の業務フローをベースに「誰が・何を・どんな順番で操作するか」を記述したテストケースを作成する
2. テスト実施: テストシナリオに沿ってシステムを操作し、期待通りの結果が得られるかを確認する
3. 不具合の記録: 期待通りでない挙動を記録し、ベンダーに報告する
4. 修正確認: ベンダーが修正した後、再度同じシナリオでテストを実施する

テストシナリオは「正常系」（正しい操作をしたときに正しく動くか）だけでなく、「異常系」（誤った操作をしたときにエラーが出るか）も含めましょう。

検収基準の設定と検収書の発行タイミング

検収とは「発注した内容を確認し、受け入れる」という公式な行為です。検収書に署名することで、ベンダーへの支払い義務が発生することが多いため、慎重に進める必要があります。

検収基準は事前に合意しておくのが理想的です。以下のような基準が一般的です。

• 要件定義書に記載された全機能が動作すること
• クリティカルな不具合（業務遂行を妨げるバグ）が0件であること
• 軽微な不具合は別途修正スケジュールで合意済みであること
• 合意したドキュメント（ソースコード・仕様書・操作マニュアル）が納品されていること

不具合発見時の対応フローと瑕疵担保責任

テスト中に不具合が発見された場合、以下の対応フローで進めましょう。

1. 不具合を記録する（画面キャプチャ・再現手順・発生条件を含める）
2. 重要度を分類する（クリティカル / 軽微 / 要確認）
3. ベンダーに報告し、修正期限を合意する
4. 修正後、再テストを実施して確認する

請負契約の場合、契約不適合責任（旧・瑕疵担保責任）により、納品後一定期間内（通常1年）に発見された不具合はベンダーが無償で修正する義務があります。検収後も不具合が見つかった場合は、まず契約書の「契約不適合責任」条項を確認しましょう。

フェーズ8——納品・保守契約の締結

検収が完了したら、いよいよ本番リリースです。ただし、リリースで終わりではありません。システムの運用・保守の体制整備も発注者の重要な仕事です。

本番リリース後に確認すべき成果物の引き渡しポイント

本番リリース時に必ず確認すべき成果物は以下のとおりです。

• ソースコード（Gitリポジトリの移管または共有）
• インフラ構成図（サーバー・データベース・ネットワーク構成）
• 機能仕様書・画面仕様書
• データベース設計書
• 操作マニュアル（管理者用・一般ユーザー用）
• テスト結果報告書
• 各種アカウント情報（サーバー・ドメイン・クラウドサービスなど）

これらのドキュメントが不完全なまま引き渡しを受けると、将来のベンダー乗り換えや機能追加の際に大きな障害になります。

保守契約の種類と選び方——スポット vs 月額保守

本番リリース後のシステムには、障害対応・セキュリティアップデート・機能改善などの保守が必要です。保守契約には大きく2種類あります。

月額保守契約

• 毎月一定額を支払い、継続的なサポートを受ける
• 障害対応の優先度が高く、対応時間（SLA）が保証されることが多い
• 中規模以上のシステムや業務継続性が重要なシステムに向いている
• 費用目安: システム開発費用の10〜20%/年が一般的な相場

スポット対応

• 問題が発生したときだけ都度依頼する
• 費用は状況次第だが、緊急時は割増料金になる場合がある
• 軽微なシステムや内製で対応できる体制がある場合に向いている

将来的な機能追加・ベンダー乗り換えを見据えて、「ソースコードの所有権はどちらにあるか」「別のベンダーが引き継げる状態か」も保守契約を結ぶ前に確認しておきましょう。

発注プロセスを成功させる「伴走型パートナー」の選び方

発注プロセス全体を振り返ると、「発注者が主導するフェーズ」と「ベンダーが主導するフェーズ」が交互に来ることが分かります。初めての発注で一人でプロセスを完璧にこなそうとすると、プレッシャーになりがちです。

発注プロセスで失敗しないための「パートナー選びの基準」

発注の成功率を高めるために重要なのは、「一緒にプロセスを進めてくれるパートナー」を選ぶことです。具体的には以下のような特徴を持つベンダーを選びましょう。

• 機能の提案だけでなく、「何を作るべきか」の相談に乗ってくれる
• 要件が固まっていない段階から一緒に整理してくれる
• 発注者の業務知識を引き出しながら要件定義を進める姿勢がある
• リリース後の保守・成長を見据えた提案ができる

このような「構想段階からの伴走型」のアプローチは、発注者が初めてシステム開発を依頼するケースで特に効果を発揮します。

構想段階から伴走してくれるベンダーが成功率を高める理由

「要件が固まってからRFPを送る」という順番ではなく、「要件を一緒に整理するところから始める」というアプローチを取ることで、以下のメリットがあります。

• 要件定義の精度が上がり、後からの仕様変更が減る
• 発注者が知らない技術的な選択肢を提案してもらえる
• ベンダーが業務を理解した状態で開発が始まるため品質が上がる
• 「言った・言わない」問題が発生しにくい信頼関係が構築される

秋霜堂株式会社のTechBandは、「社内にシステム開発部門ができたようだ」と評価されるほど、構想段階から発注者に密に伴走するアジャイル型の開発スタイルを採用しています。要件が固まる前の段階からでも、まず相談できる体制を整えています。

まとめ——Webシステム開発の発注プロセス全体タイムラインと所要期間目安

本記事で解説した発注プロセスを一覧表にまとめます。

フェーズ別タイムラインと所要期間の目安（規模別）

フェーズ	主な発注者タスク	小規模（〜300万円）	中規模（300〜1,000万円）
構想・要件整理	社内ヒアリング・要件整理	1〜2週間	2〜4週間
RFP作成・提案依頼	RFP作成・3〜5社へ依頼	1〜2週間	2〜3週間
提案比較・発注先決定	比較評価・契約交渉	1〜2週間	2〜4週間
要件定義	仕様確定・サインオフ	2〜4週間	4〜8週間
設計・開発	定例参加・承認対応	1〜2ヶ月	3〜6ヶ月
テスト・検収	UAT実施・検収書発行	1〜2週間	2〜4週間
納品・保守契約	成果物確認・契約締結	1週間	1〜2週間

SCROLL→

合計: 小規模で3〜4ヶ月、中規模で6〜12ヶ月が目安です（開発規模・要件の複雑さにより大きく変動します）。

発注プロセス全体のチェックリスト

最後に、本記事で紹介した発注プロセスのチェックリストをまとめます。

フェーズ1（構想・要件整理）

• システム化の目的・解決したい課題を明確化した
• 主な利用者と利用シーンを整理した
• 必須機能の概要をまとめた
• 予算上限・リリース希望時期を設定した

フェーズ2（RFP作成・提案依頼）

• RFPに7つの必須項目を記載した
• 3社以上に提案を依頼した

フェーズ3（提案比較・発注先決定）

• 価格だけでなく5つのポイントで比較した
• 請負 vs 準委任の契約形態を確認した
• コミュニケーションの質を確認した

フェーズ4（要件定義）

• 業務知識オーナーとして積極的に参加した
• スコープ外が明記されていることを確認した
• 変更対応のルールを合意した上でサインオフした

フェーズ5〜6（開発中）

• 定例ミーティングを設定した
• 仕様変更は書面で記録・合意した

フェーズ7（テスト・検収）

• UATのシナリオを作成し実施した
• クリティカルな不具合が0件であることを確認した
• 検収書を発行した

フェーズ8（納品・保守契約）

• ソースコード・ドキュメント類の引き渡しを確認した
• 保守契約の内容と費用を合意した

発注プロセスは複雑に見えますが、一つひとつのフェーズで「発注者がやるべきこと」を把握していれば、自信を持って進められます。初めての発注で不安を感じているなら、構想段階から気軽に相談できるパートナーを見つけることが、成功への近道です。