受託開発を初めて頼むとき、多くの発注者がつまずくのは「依頼したあと、自分は何をすればいいのか分からない」ことです。開発会社に任せれば勝手に進むわけではなく、受託開発の流れの各段階で、発注側が決めたり確認したりすることがはっきりあります。ここが抜けると、できあがったシステムが業務に合わない、追加費用が出る、納品直前で揉める、といった失敗につながります。
この記事では、相談・見積もりから要件定義、設計・開発・テスト、納品・検収、運用まで、受託開発の流れを工程順に整理します。単なる工程の名前ではなく、各工程で発注側が準備すること・確認することに絞って解説します。全体像をつかんでおけば、開発会社との打ち合わせで何を聞かれ、何を決めればよいかが見えるようになります。
この記事のポイント
- 受託開発の流れは相談・見積もりから要件定義・設計・開発・テスト・検収・運用まで連なる
- 各工程で発注側が決めること・確認することがあり、丸投げにすると失敗しやすい
- 契約は請負が基本で、要件定義だけ準委任にする組み合わせも多い
- 期間・費用は要件定義の精度で変わり、発注側の準備が全体の成否を左右する
すでに開発会社に相談する予定がある場合でも、この流れに沿って自分の準備状況を確認しておくと、初回の打ち合わせから話が具体的に進みます。
目次
受託開発の流れと依頼から納品までの全体像
受託開発の流れの全体像をつかむ
受託開発とは、外部の開発会社にシステム開発を委託し、成果物を納品してもらう頼み方です。仕組みや契約・費用の基本から知りたい場合は、受託開発とは何か（仕組みと契約・費用の基本）を先に読むと全体像がつかみやすくなります。
受託開発の流れは、大きく次の順で進みます。相談・問い合わせ、見積もり・契約、要件定義、基本設計・詳細設計、開発・実装、テスト、納品・検収、本稼働、運用・保守です。開発会社が主に手を動かすのは設計から開発・テストですが、その前後の「何を作るか決める段階」と「受け取って確認する段階」は、発注側の関与なしには進みません。
| 工程 | 主な内容 | 発注側がやること |
|---|---|---|
| 相談・見積もり | 課題の共有、概算見積もり | 目的・予算感・体制を整理して伝える |
| 契約 | 請負・準委任の取り決め | 範囲・成果物・検収条件を確認する |
| 要件定義 | 機能・非機能の確定 | 業務の実態と優先順位を決める |
| 設計・開発 | 画面・処理の作り込み | 中間成果物をレビューする |
| テスト・検収 | 品質確認、受入テスト | 実業務で使えるか確認して合否を出す |
| 運用・保守 | 本稼働、改修対応 | 保守範囲と連絡体制を決める |
この表のとおり、受託開発の流れは「開発会社に任せる工程」と「発注側が決める工程」が交互に現れます。どこで自分の判断が必要かを先に知っておくことが、スムーズな進行の第一歩です。
相談・問い合わせ前に発注側が整理すること
相談の前に、まず「なぜ作るのか」「どの業務を変えたいのか」を言葉にしておきます。ここが曖昧なまま問い合わせると、開発会社も提案の的を絞れず、見積もりの前提がばらつきます。売上を伸ばしたい、入力ミスを減らしたい、問い合わせ対応の手間を減らしたいなど、解決したい課題を具体的に書き出しておきましょう。
あわせて、使える予算の幅、希望する時期、社内で誰が判断するのかも整理しておきます。金額を一切示さないと提案の粒度がばらつくため、上限のイメージだけでも共有できると精度が上がります。この段階の準備が薄いと、後の工程すべてに影響します。
もう一つ大切なのが、社内の体制を決めておくことです。開発会社の窓口になる人、業務の要望を出す現場の代表、予算を判断できる人、運用を担う人を、誰にするか決めておきます。関係者が多いほど要望は増えて収拾がつかなくなるため、最終的に判断する人を一人決めておくと、後の工程で意見が割れても前に進めます。相談の場に「何も決まっていない状態」で臨むより、たたき台を持って行くほうが、開発会社からも具体的な提案を引き出せます。
見積もり・契約で決めること
見積もりを受け取ったら、金額の大小だけで判断せず、どこまでの作業が含まれているかを確認します。受託開発は請負契約が基本で、開発会社が成果物の完成に責任を負います。一方、仕様がまだ固まっていない要件定義のフェーズだけは、成果物の完成責任を問いにくいため準委任契約にする組み合わせも多く見られます。
契約では、開発する範囲、納品する成果物、検収の条件、追加が発生したときの扱いを明確にしておきます。契約や著作権・不具合対応の観点は、法的な判断そのものではなく確認すべきポイントとして押さえておくと安心です。範囲と検収条件が曖昧なまま進むと、納品時に「これは含まれていない」と揉める原因になります。
特に注意したいのが、途中で出てくる仕様変更や追加要望の扱いです。開発が始まってから「あの機能も欲しい」となるのは珍しくありませんが、その都度どう見積もり直し、どちらの負担にするかを最初に決めておかないと、費用や納期で認識がずれます。変更が起きる前提で、変更依頼のルールを契約段階で握っておくと、後のトラブルをかなり減らせます。
要件定義で発注側が固めること
要件定義は、受託開発の流れの中で最も発注側の関与が重い工程です。開発会社はヒアリングと構造化を担いますが、業務の実態や優先順位、社内の承認事情は発注側にしか分かりません。ここを丸投げすると、きれいな資料はできても現場で使えないシステムになりがちです。
目的、業務フロー、利用者と権限、機能要件と非機能要件を、決まっていることと未確定のことを分けて整理します。具体的な進め方や成果物の中身は、要件定義書の作り方と成果物サンプルで工程ごとに確認できます。要件定義の精度が、この後の見積もり・期間・品質をほぼ決めると言っても過言ではありません。
設計・開発・テストで発注側が確認すること
設計・開発は開発会社が主導しますが、発注側は「任せきり」にせず、区切りごとに中間成果物を確認します。基本設計の画面イメージや処理の流れをレビューし、認識のズレを早い段階で潰しておくと、後戻りの手戻りコストを抑えられます。
テストの段階では、開発会社側のテストとは別に、発注側が実際の業務に近い形で動かす受入テストの準備を進めます。誰が、どの業務シナリオで、いつ確認するかを決めておくと、検収がスムーズになります。テスト観点を開発の途中から用意しておくのがコツです。
私の感覚では、この工程で問い合わせや確認を止めてしまう発注者ほど、後で「思っていたものと違う」となりやすい印象があります。仕様の判断で迷う質問が開発会社から来たときに、返事が遅れると開発全体が待ち状態になります。担当者が即答できないなら、いつまでに社内で決めて返すかだけでも伝えておくと、開発会社は段取りを組み直せます。レビューは粗探しではなく、認識をそろえる場だと考えると関わりやすくなります。
納品・検収・運用開始でやること
検収とは、納品物が契約どおりの品質・機能を備えているかを発注側が確認する作業です。ここで「画面ができたから完了」ではなく、「どの業務が、どの条件で動けば合格か」という検収条件に沿って合否を出します。開発規模が大きい場合は、工程ごとに区切る中間検収や分割検収を組み合わせることもあります。
検収が終わったら、運用・保守のフェーズに入ります。障害時の連絡体制、保守で対応してもらう範囲、改修を頼むときの流れを、運用開始前に決めておきましょう。ここを曖昧にすると、稼働後に「どこまで見てもらえるのか」で困ることになります。
受託開発の流れで発注側がやることと注意点
受託開発の期間の目安とスケジュールの立て方
受託開発の期間は、規模によって大きく変わります。一般的な目安として、小規模なら1〜3か月、中規模で3〜6か月、大規模になると1年以上かかることもあります。期間は要件定義の精度と、途中の仕様変更の多さで前後します。あくまで一般的な目安であり、実際の期間は個別の見積もりで確認してください。
スケジュールを立てるときに見落としやすいのが、発注側が確認する時間です。中間レビューや受入テスト、社内の承認には日数がかかります。開発会社の作業だけでなく、発注側の確認日程も最初から組み込んでおかないと、待ちが発生して全体が後ろにずれます。
| 規模 | 期間の目安 | 費用の目安 |
|---|---|---|
| 小規模 | 1〜3か月 | 100〜500万円 |
| 中規模 | 3〜6か月 | 500〜3,000万円 |
| 大規模 | 1年以上 | 3,000万円〜 |
費用が流れのどこで確定するか
受託開発の費用は、相談段階の概算から、要件定義を経て確定していきます。最初の見積もりはあくまで前提付きの概算で、要件が具体化するにつれて金額が動くのが普通です。だからこそ、要件定義の前後で見積もりを見直すタイミングを設けておくと安心です。
見積もりを受け取ったら、範囲の抜けや前提のズレがないかを点検しておくと、後の追加費用を防げます。見積もりの危険サインを見抜く60項目チェックシートを使うと、抜けやすい項目を発注前に確認できます。人月単価の考え方や規模別の相場は、受託開発の見積もり・人月単価の読み方で詳しく整理しています。
丸投げで失敗しない発注側の関わり方
受託開発でよくある失敗の多くは、「プロに任せれば大丈夫」と発注側が関与を減らしたときに起きます。要件を決めきらない、レビューをしない、検収条件を曖昧にする、といった状態だと、開発会社がどれだけ優秀でも認識のズレは埋まりません。
関わり方のコツは、意思決定者と窓口担当をはっきりさせ、確認の頻度をあらかじめ決めておくことです。すべての会議に出る必要はありませんが、要件の確定、中間レビュー、検収という節目には必ず発注側が判断を下します。この関与が、受託開発の流れを成功させる分かれ目になります。
現場でよく見るのは、担当者一人に発注のすべてを背負わせてしまうケースです。その人が忙しくて確認が滞ると、開発全体が止まります。窓口は一本化しつつも、要望を出す現場と最終判断者を巻き込み、節目には短時間でも判断の場を持つ。この体制を最初に作っておくことが、丸投げを避ける一番の近道です。
受託開発の流れでよくある質問
初めて受託開発を進める発注者から、打ち合わせでよく受ける質問をまとめました。細かな判断は個別の状況によりますが、考え方の目安として参考にしてください。
- Q. 受託開発は要件定義まで自分で用意しないと頼めませんか？
- A. 完璧な要件定義書がなくても相談は可能です。多くの開発会社は要件定義から支援します。ただし目的や解決したい課題、予算感は発注側で整理しておく必要があります。ここが白紙だと提案も見積もりも定まりません。
- Q. 契約は請負と準委任のどちらを選べばよいですか？
- A. 成果物を完成させて納品してほしいなら請負が基本です。仕様がまだ固まらない要件定義のフェーズだけを準委任にし、確定後に請負へ切り替える組み合わせもよく使われます。範囲と成果物、検収条件をどう決めるかで判断します。
- Q. 発注してから納品まで、どのくらいの期間を見ておけばよいですか？
- A. 規模によりますが、小規模で1〜3か月、中規模で3〜6か月が一般的な目安です。要件定義の精度や仕様変更の有無で前後します。発注側の確認や社内承認にかかる日数も、あらかじめスケジュールに含めておくと安心です。
