システム開発を外注すると、作る作業は開発会社が担います。しかし、発注者の仕事がなくなるわけではありません。何を作るかを決める、必要な資料や情報を提供する、途中の成果物を確認する、仕様を承認する、完成したものをテストして受け入れる。こうした判断と確認は、発注者にしかできない仕事です。外注がうまくいくかどうかは、開発会社の腕前と同じくらい、発注者がこれらの仕事をどのタイミングで、どれだけ果たせるかにかかっています。
外注の流れは、大きく「準備」「依頼先の選定」「契約」「要件定義・設計」「開発・テスト」「受入・納品」「運用開始」の段階に分かれます。それぞれの段階で、発注者が何を用意し、何を確認し、何を承認するのかを先に知っておけば、確認待ちによる遅れや、完成間際の手戻りを大きく減らせます。
この記事は、初めてシステム開発を外注する事業責任者や担当者に向けて、問い合わせから納品・運用開始までの流れを時系列で整理します。段階ごとの発注者の仕事、社内で確保すべき時間、よくある失敗とその避け方まで、計画を立てるときにそのまま使える形でまとめています。
システム開発を外注する流れの全体像
まず、全体の流れと、各段階で発注者が担う仕事を一覧にします。開発会社や契約形態によって呼び方や順番は多少変わりますが、発注者の役割はおおむね共通しています。
| 段階 | 主な作業 | 発注者が用意・提供するもの | 発注者が判断・承認すること |
|---|---|---|---|
| 準備 | 目的と範囲の整理 | 目的、課題、必須機能、予算の目安、期限 | 何のために何を作るか |
| 依頼先の選定 | 問い合わせ、提案、見積もり | 要件の資料、回答してほしい項目 | どの会社に依頼するか |
| 契約 | 契約条件の合意 | 社内の決裁、法務の確認 | 契約形態、範囲、支払い、権利 |
| 要件定義・設計 | 要件の確定、画面と機能の設計 | 業務の情報、既存資料、現場の協力 | 要件定義書と設計の承認 |
| 開発・テスト | 実装、開発会社によるテスト | 質問への回答、途中成果物の確認 | 仕様変更の可否、優先順位 |
| 受入・納品 | 受入テスト、検収 | テストケース、テストの実施者 | 検収（受け入れ）の判断 |
| 運用開始 | 公開、データ移行、利用者への展開 | 移行データ、マニュアル、社内周知 | 公開の判断、運用体制 |
表を見ると分かるとおり、発注者が何かを用意し、何かを判断する場面は全段階にわたっています。計画を立てる際は、この表の右側の二列を自社の担当者の名前で埋めてみると、誰の時間がどの時期に必要になるかが見えてきます。特に要件定義と受入テストは、発注者の関わりが最も大きくなる段階です。
段階ごとに発注者がやること
ここからは、全体の流れを順を追って説明します。各段階で発注者がやることを、番号付きの手順として示します。
- 準備：目的と範囲を社内で固める
- 依頼先の選定：同じ条件で提案と見積もりを集める
- 契約：範囲、責任、権利を文書で合意する
- 要件定義・設計：業務の情報を出し、仕様を承認する
- 開発・テスト：質問に答え、途中の成果物を確認する
- 受入・納品：自分たちでテストし、検収する
- 運用開始：公開し、社内に定着させる
1. 準備：目的と範囲を社内で固める
開発会社に問い合わせる前に、社内で「何のために、何を作るのか」を整理します。目的と成功の基準、対象となる業務と利用者、必須の機能、予算の目安、公開の希望時期とその理由を書き出しておきましょう。完璧である必要はありませんが、これがないと開発会社は提案の前提を置けません。
社内の関係者へのヒアリングも、この段階で済ませておくと後が楽になります。実際にシステムを使う部署、データを受け渡す部署、経理や情報システムの担当など、影響を受ける人の意見を事前に集めておけば、要件定義の途中で新しい要望が噴き出すことを防げます。
この段階で、プロジェクトの担当者と決裁者も決めておきます。担当者は開発会社との窓口となり、日々の質問に答え、社内の調整を行う人です。決裁者は範囲や予算、仕様の重要な判断を下す人です。両者が決まっていないと、後の段階で判断が止まります。
2. 依頼先の選定：同じ条件で提案と見積もりを集める
候補となる開発会社に問い合わせ、提案と見積もりを依頼します。複数社を比べる場合は、全社に同じ資料と同じ質問を渡すことが大切です。条件がそろっていないと、提案や金額の違いが会社の違いなのか、伝え方の違いなのか分からなくなります。
提案を受け取ったら、要件の理解度、体制、見積もりの前提、保守の方針などを比べて依頼先を決めます。問い合わせの際は、相談したい内容の概要、希望時期、予算の目安を最初に伝えると、開発会社は対応できるかどうかをすぐに判断できます。初回の打ち合わせでは、開発会社からの質問に答えるだけでなく、こちらからも進め方や体制、公開後の対応について質問しておくと、提案を受け取る前に相性を見極められます。
選定の観点はシステム開発会社の選び方で詳しく解説しています。
3. 契約：範囲、責任、権利を文書で合意する
依頼先が決まったら、契約の条件を詰めます。確認すべきなのは、作る範囲と範囲外、契約形態（請負か準委任か）、スケジュールと成果物、支払いの時期と条件、検収の方法、仕様変更の扱い、ソースコードなどの権利の帰属、秘密保持、公開後の保守の扱いです。
要件定義と開発を分けて契約するのも一つの方法です。要件定義をまず準委任で行い、要件が固まってから開発の範囲と金額を確定させると、範囲が曖昧なまま大きな金額で契約するリスクを避けられます。契約形態の違いは請負契約と準委任契約の選び方で整理しています。契約の内容は、必要に応じて法務の専門家にも確認してもらいましょう。
4. 要件定義・設計：業務の情報を出し、仕様を承認する
要件定義は、発注者の関わりが最も大きい段階です。開発会社は打ち合わせを通じて要件を聞き取りますが、業務の流れ、例外の処理、社内のルール、扱うデータの実物などを提供できるのは発注者だけです。現場の担当者にも打ち合わせに参加してもらい、実際の業務の情報を出しましょう。
要件定義書や画面の設計がまとまったら、発注者が内容を確認して承認します。承認とは、「この内容で作ってよい」と合意することです。ここで確認が甘いと、後の段階で「こういうつもりではなかった」という手戻りが生まれます。要件定義書の書き方は要件定義書の書き方で解説しています。
5. 開発・テスト：質問に答え、途中の成果物を確認する
開発が始まると、発注者の仕事は減るように見えますが、実際には開発会社からの質問への回答と、途中の成果物の確認が続きます。開発を進める中で、要件定義では決めきれなかった細かな仕様について質問が出てくるのは自然なことです。回答が遅れると開発が止まるため、回答の期限と担当者を決めておきましょう。
定例会では、進捗、課題、決めるべきことを確認します。動く画面を途中で見せてもらえる場合は、必ず実際に触って確認します。この段階で認識のずれに気づけば、修正の手間は小さく済みます。
仕様の変更や追加の要望が出たときは、その場で口頭で了承せず、内容、理由、費用とスケジュールへの影響を確認したうえで、決裁者が判断します。変更の記録も残しておきましょう。変更が重なると、当初の範囲と現在の範囲の違いが分からなくなりがちです。変更の一覧を開発会社と共有し、定例会で確認する習慣をつけておくと、受入テストや検収の段階で「どの仕様が正しいのか」で揉めることを防げます。
6. 受入・納品：自分たちでテストし、検収する
開発会社のテストが終わったら、発注者が受入テストを行います。受入テストは、完成したシステムが合意した要件を満たしているか、実際の業務で使えるかを発注者自身が確かめる作業です。開発会社のテストとは目的が違い、業務の視点での確認が求められます。
受入テストのためには、テストケース（何を、どの手順で確かめ、どうなれば合格か）を用意し、実際に業務を行う担当者にテストしてもらいます。見つかった不具合は記録して開発会社に伝え、修正を確認します。すべての確認が終わったら、検収（受け入れ）を判断します。検収は支払いや契約上の責任の区切りにもなるため、確認が終わる前に検収しないよう注意しましょう。テストケースは、要件定義書をもとに受入テストの直前ではなく開発の途中から作り始めると、テスト期間を圧迫しません。通常の業務の流れに加えて、締め日や月末処理、キャンセルなどの例外も必ず含めます。受入テストの進め方は受入テストの進め方で詳しく扱っています。
7. 運用開始：公開し、社内に定着させる
システムを公開し、実際の業務で使い始めます。既存のデータを移す場合は、移行のデータを準備し、移行後の内容を確認します。利用者向けのマニュアルや説明会を用意し、問い合わせの窓口も決めておきます。
公開直後は、想定していなかった使い方や不具合が見つかりやすい時期です。開発会社との連絡体制を保ち、課題を記録して優先順位を付けて対応します。公開後の保守の範囲と、改善の進め方もこの段階で確認しておきましょう。
公開の判断そのものも発注者の仕事です。受入テストで見つかった軽微な不具合をすべて直してから公開するのか、業務に支障のないものは公開後に直すのかを決める必要があります。判断の基準は「その不具合があっても業務が回るか」「利用者や取引先に迷惑がかからないか」です。公開日を動かせない事情がある場合は、手作業で補う運用を用意したうえで公開に踏み切ることもあります。
発注者が確保すべき社内の時間と体制
外注の流れの中で、発注者側の時間が足りなくなることが、遅れの大きな原因になります。特に時間がかかるのは、要件定義の打ち合わせと受入テストです。担当者が通常業務と兼務している場合、これらの時間をあらかじめ計画に入れておかないと、確認が後回しになり、開発会社が待たされることになります。
体制として最低限決めておきたいのは、窓口となる担当者、仕様や範囲の判断をする決裁者、業務の情報を提供し受入テストを行う現場の担当者の3つの役割です。小さな会社では一人が複数の役割を兼ねることもありますが、誰が何を決めるのかは明確にしておきます。
また、開発会社とのやり取りの方法も最初に決めます。連絡に使うツール、質問への回答期限、定例会の頻度と参加者、決定事項の記録方法などです。こうしたルールがあるだけで、伝わった・伝わっていないという行き違いを防げます。発注側の管理の進め方は発注側のプロジェクト管理も参考にしてください。
外注の流れで受け取る成果物と、発注者が保管すべきもの
外注の各段階では、開発会社からさまざまな成果物が届きます。これらは確認して承認するためだけでなく、将来の保守や改修、依頼先の変更に備えて、発注者の手元に残しておくべき資産です。段階ごとに主な成果物を整理しておきます。
- 選定・契約の段階：提案書、見積書（内訳と前提条件を含むもの）、契約書、秘密保持契約書。後から範囲を確認するときの根拠になります。
- 要件定義・設計の段階：要件定義書、画面設計や画面遷移の資料、データの設計、外部連携の仕様、議事録と決定事項の一覧。仕様の変更履歴もここに含まれます。
- 開発・テストの段階：テストの計画と結果の記録、課題と対応の一覧。どの不具合がどう直されたかを後から追えるようにしておきます。
- 納品・運用開始の段階：ソースコード、本番環境の構成と各種アカウントの情報、運用手順書、利用者向けマニュアル、データ移行の記録。
特に見落とされやすいのが、ソースコードと本番環境のアカウントです。サーバーやドメイン、外部サービスの契約が開発会社の名義になっていると、将来の依頼先の変更や内製化が難しくなります。どの契約が誰の名義で、管理者の権限を誰が持つのかを、納品の段階で一覧にしておきましょう。成果物の受け取りは検収の条件に含めておくと、漏れを防げます。
架空の例：確認待ちでスケジュールが延びかけたケース
ここで、仕組みを理解するための架空の例を紹介します。ある会社が、店舗の在庫を本部で一元管理するシステムの開発を外注しました。要件定義は順調に進み、開発会社は予定どおり開発に入りました。
ところが、開発の途中で開発会社から届いた質問への回答が、なかなか返せませんでした。窓口の担当者は店舗運営の責任者を兼ねており、質問の多くは店舗ごとの在庫の数え方や、返品の扱いといった現場の運用に関するものだったため、担当者一人では答えられなかったのです。回答待ちの質問がたまり、開発会社は一部の作業を止めざるを得なくなりました。
この会社は、質問の種類ごとに回答する担当者を決め、週に一度、質問をまとめて回答する時間を設けました。さらに、決裁が必要な事項は定例会で決裁者がその場で判断する形に改めました。結果として遅れは取り戻せましたが、振り返ると、準備の段階で現場の担当者を体制に組み込み、回答の時間を確保しておくべきだったといいます。
よくある失敗と、外注の流れを確認するチェックリスト
よくある失敗と避け方
- 準備をせずに問い合わせる：目的や範囲が決まっていないまま問い合わせると、提案も見積もりもばらばらになります。最低限、目的、必須機能、予算の目安、期限は整理してから問い合わせましょう。
- 要件定義を開発会社に任せきりにする：業務の情報は発注者にしかありません。現場の担当者を打ち合わせに参加させ、実物の資料を提供します。
- 承認を形式的に済ませる：要件定義書や設計を読み込まずに承認すると、後で認識のずれが表面化します。分からない点は質問し、理解してから承認します。
- 口頭で仕様変更を了承する：影響を確認しないまま了承すると、費用やスケジュールが膨らみます。変更は記録し、影響を確認してから判断します。
- 受入テストを開発会社任せにする：業務の視点での確認は発注者にしかできません。テストケースを用意し、実際の利用者にテストしてもらいます。
- 公開後の体制を決めずに納品を迎える：問い合わせ窓口や保守の範囲が決まっていないと、公開直後の混乱に対応できません。
チェックリスト
- 目的、必須機能、予算の目安、期限を整理してから問い合わせたか
- 窓口の担当者、決裁者、現場の担当者が決まっているか
- 要件定義と受入テストに必要な社内の時間を計画に入れたか
- 契約で範囲、範囲外、検収の方法、仕様変更の扱い、権利を確認したか
- 質問への回答期限と、定例会の頻度と参加者を決めたか
- 要件定義書と設計を理解したうえで承認したか
- 仕様変更の内容と影響を記録しているか
- 受入テストのテストケースと実施者を用意したか
- 公開後の保守の範囲と、問い合わせ窓口を決めたか
よくある質問
Q. 外注の全体の期間はどれくらいかかりますか？
システムの規模や範囲、発注者の準備度合いによって大きく変わります。発注者が準備の段階で目的と範囲を整理し、確認や承認を速やかに行えると、全体の期間は短くなります。期間の考え方はシステム開発の期間はどう決まるかでも解説しています。
Q. 発注者に専門知識がなくても外注できますか？
できます。発注者に求められるのは技術の知識より、業務の情報を正確に伝え、判断を下すことです。技術の選び方やサーバーの構成などは、選択肢と、それぞれの費用や将来への影響を説明してもらったうえで、事業の観点から選べば十分です。分からない用語や技術的な判断は、開発会社に説明を求めましょう。説明を丁寧にしてくれるかどうかも、依頼先を選ぶ際の大切な観点です。
Q. 社内に担当者を置く余裕がない場合はどうすればよいですか？
担当者を置かずに外注すると、確認や判断が止まり、結果的に費用と期間が膨らみます。専任が難しい場合でも、週に一定の時間を確保できる担当者を決めましょう。発注側の管理を外部の専門家に補ってもらう方法もあります。
Q. 要件定義の後に依頼先を変えることはできますか？
要件定義を別契約にしておけば、要件定義書を成果物として受け取り、開発は別の会社に依頼することも可能です。その場合は、要件定義書の権利と、他社が読んで理解できる内容になっているかを確認しておきましょう。
Otsumuに相談できること
社内に窓口の担当者と決裁者がいて、要件定義と受入テストに時間を確保できる場合は、この記事の流れに沿って進めれば、外注は十分にうまく進められます。小規模なシステムであれば、準備の段階で目的と必須機能を1枚にまとめるだけでも、その後の流れはずっと滑らかになります。
一方で、社内に開発の進め方を知る人がいない、何を作るべきかの整理から手伝ってほしい、担当者が兼務で時間を確保しきれない、といった場合は、要件の整理から公開後まで一貫して伴走できる相手に任せたほうが、発注者の負担を抑えられます。
Otsumuは、自らも事業を手がける立場から、目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間に形にしています。構想から開発・運用・改善までを一気通貫で担当するため、段階ごとに依頼先が変わることによる情報の欠落が起きにくいのが特徴です。システム開発のページで種類別の進め方を紹介しています。新規事業であれば新規事業の爆速MVPシステム開発として、検証に必要な範囲から始めることもできます。
外注の進め方そのものについての相談も歓迎しています。まずは30分の無料相談で、検討中の内容をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01