2026年10月3日発注の準備執筆：林部（株式会社リベライズ代表）

初めてのシステム開発発注ガイド｜相談から納品までの全体の流れ

初めてシステム開発を発注する方向けに、相談から開発会社選び、見積、契約、開発、検収、運用までの流れを工程ごとに解説。発注者がやることと期間の目安、つまずきやすい点もまとめました。

初めてシステム開発を発注する担当者の多くは、「何から始めて、いつ何を決めればよいのか」が分からないまま開発会社に相談します。この記事では、システム開発の発注の流れを、構想から運用まで工程ごとに整理します。発注者がやることと開発会社がやること、期間と社内人員の目安、つまずきやすい点まで一度に確認できます。

システム開発の発注の流れは7つの工程に分かれます

システム開発の発注は、大きく次の7つの工程で進みます。

構想: 何のために作るのか、どの業務を変えたいのかを決める
発注先探し: 相談先の開発会社を探し、候補を絞る
見積・提案: 候補の会社から見積と提案を受け、比較する
契約: 契約形態、範囲、支払い条件を決めて契約する
開発: 要件定義、設計、実装、テストを進める
検収: 納品物が要件どおりか、発注者が確認して受け取る
運用: 本番で使い始め、保守と改善を続ける

ここで押さえておきたいのは、「開発」の中にも複数の段階がある点です。要件定義（何を作るかを文章と画面で決める工程）、設計、実装、テストと進みます。

IPAと経済産業省が公開している情報システム・モデル取引・契約書も、工程ごとに個別契約を結ぶ「多段階契約」の考え方をとっています。最初から全工程を一括で契約しなくても、要件定義だけを先に契約し、その結果を見て開発を発注する進め方ができます。

工程ごとに発注者がやること・開発会社がやること

外注しても、発注者の仕事はなくなりません。決めること、確認することは発注者に残ります。工程ごとの分担は次のとおりです。

工程	発注者がやること	開発会社がやること
構想	目的・課題・予算・期限・優先順位を決める	（相談を受けた場合）整理を手伝う
発注先探し	候補を探し、相談内容を伝える	実績・体制を説明する
見積・提案	前提条件をそろえて比較し、1社に決める	要望を聞き取り、提案と見積を出す
契約	範囲・契約形態・支払い条件を確認する	契約書案と前提条件・除外事項を示す
開発（要件定義）	業務ルールを決め、画面イメージを確認・承認する	要件を文書化し、確認事項を一覧で出す
開発（設計〜テスト）	定例で進捗を聞き、仕様の質問に答える	設計・実装・テストを行う
検収	受入テストを行い、合否を判断する	不具合を修正し、納品物を引き渡す
運用	社内に定着させ、改善要望をまとめる	保守・障害対応・改善提案を行う

表の左列を見ると分かるとおり、発注者は「決める」「確認する」「受け取る」の役割を最後まで持ちます。特に要件定義と受入テストは、発注者の関与が欠かせない工程です。詳しくは要件定義で発注者がやるべきことで解説しています。

工程ごとの期間と社内に必要な人員の目安

期間は規模によって大きく変わるため、一律の数字はありません。ここでは、中小規模のWebシステムや業務アプリの提案で示されることの多い期間を目安として載せます。数字がない行は、案件ごとの差が大きい工程です。

工程	期間の目安	社内で必要な人員
構想・社内整理	社内の検討次第（目的と予算が決まるまで）	担当者1名、意思決定者
事前調査（必要な場合）	2〜3ヶ月	担当者、関係部門の代表者
発注先探し・見積比較	候補の数と各社の提案準備による	担当者、情報システム担当（いれば）
社内承認（稟議）	1ヶ月程度を確保	担当者、決裁者
要件定義〜実装〜テスト	3〜4ヶ月（中小規模の例）	担当者、業務を知る現場の代表者
受入テスト・検収	テスト範囲による（開発日程に組み込む）	担当者、実際に使う現場の担当者

逆算も大切です。たとえば構築に3〜4ヶ月かかるなら、4月に使い始めたい場合は前年の12月には発注している必要があります。稟議の期間も含めると、相談はさらに前倒しになります。

社内の人員は、専任でなくてもかまいません。ただ、担当者が週に1回、1時間半程度の打合せに出られることは前提になります。担当者のほかに、最終判断をする意思決定者と、業務を知っている現場の代表者がいると、手戻りが減ります。

大きく作るほど計画どおりに進みにくい点にも注意が必要です。JUAS（日本情報システム・ユーザー協会）の分析でも、開発プロジェクトの工期・予算・品質は規模が大きくなるほど計画未達となるケースが多いと報告されています。

初めての発注でつまずきやすいポイント

初めての発注で起きやすい失敗を、工程別にまとめます。

工程	つまずきやすい点	防ぎ方
構想	目的があいまいなまま機能の話から入る	解決したい課題を1〜2文で書いておく
構想	予算を決めずに「いくらかかるか」から相談する	上限額と、段階ごとに出せる額を決める
見積	各社に伝えた条件がばらばらで比較できない	同じ資料を全社に渡し、除外項目もそろえる
見積	最も安い見積を選び、後から追加費用が出る	前提条件と除外事項を読み比べる
契約	範囲があいまいなまま契約する	「含むもの・含まないもの」を一覧で確認する
開発	担当者が忙しく、確認が遅れて工程が止まる	定例の時間枠を先に押さえる
検収	受入テストの準備をしておらず、確認が形だけになる	テストする業務シナリオを先に決める
運用	保守費やインフラ費を見込んでいない	初期費用と月額費用を分けて見積をとる

どれも、発注者が「先に決めておく」ことで防げるものです。発注前に決めておく項目は発注前に社内で決めておくべき5つのことにまとめています。

受託開発の現場から

初めて発注する企業の相談を受ける受託開発の現場で、発注の流れについて提案の場で繰り返し伝えられていることを紹介します。

いきなり全部を作らず、段階に分けて投資する

モック（画面イメージ）、小規模なPoC（試作して効果を確かめる段階）、本格開発と、段階に分けて進める方法が有効です。投資額はシステムの進み具合ではなく、事業の検証結果に合わせて決めるべきだという考え方です。段階ごとに「次に進むかどうか」を発注者が判断する場を置き、結果が基準に届かなければ中止や見直しができる契約にしておきます。

開発会社を選ぶ前に「事前調査」だけを切り出す

目的がまだ揺れている場合は、本開発の前に「構想策定（フェーズゼロ）」だけを小さく発注する進め方が有効です。現状の棚卸し、あるべき姿、要件、詳細見積までをまとめ、その成果物は発注者のものとして他社に見せてもよい扱いにします。そうすれば、開発会社は同じ条件であらためて比較できます。

契約前に技術確認と社内承認の時間を確保する

受託開発の提案でよく使われる進め方として、契約前にNDA（秘密保持契約）を結び、開発体制との顔合わせや情報システム部門を交えた技術確認を行います。そのうえで、発注者の社内承認に1ヶ月程度を見込んだ工程を組みます。稟議の期間を工程表に入れておかないと、着手が遅れて導入日に間に合わなくなるからです。

まとめ

システム開発の発注は、構想、発注先探し、見積、契約、開発、検収、運用の7工程で進む
外注しても、決める・確認する・受け取る役割は最後まで発注者に残る
期間は導入したい月から逆算し、稟議の期間も工程に入れる
大きく一度に作るより、段階に分けて投資し、結果を見て次を判断する方が安全
つまずきの多くは、目的・予算・比較条件を先に決めておくことで防げる

何から決めればよいか分からない段階でも、FastProposal の無料AI相談なら、案件の整理と費用の目安を数分で確認できます。相談内容をもとに、提案書と動くモックを用意した開発会社3社と、営業電話なしで比較できます。