システム開発を依頼する流れを7ステップで解説｜外注前の準備・要件定義・見積もり比較・発注の注意点

「毎月の集計作業をシステムにしたい」「予約受付をWebで完結させたい」「新しいサービスの試作品を作りたい」。こうした思いつきから外注を考え始めたものの、何をどの順番で進めればよいのか分からず、最初の問い合わせで手が止まってしまう方は少なくありません。

この記事は、社内に開発の専門部署がなく、はじめて（あるいは久しぶりに）システム開発を外部に依頼する方を想定して書いています。中小企業の経営者や店舗オーナー、新規事業の担当者、個人で事業をしている方などです。依頼の流れを7つのステップに分け、それぞれの段階で「何が起きるのか」「依頼する側が何を準備し、何を決めるのか」「どこでつまずきやすいのか」を順に説明します。途中には、依頼文の書き方の例、見積もりを比べるときの表、発注前のチェックリストも載せています。

システム開発を依頼する流れの全体像

依頼先や案件の規模によって呼び方や順番は多少変わりますが、おおむね次の流れで進みます。

1. 社内での準備：目的・使う人・欲しい機能・予算と時期を整理する
2. 依頼先への相談・問い合わせ：依頼文を送り、打ち合わせで要望を伝える
3. 要件定義：何を作るか、何を作らないかを具体的に決める
4. 見積もりの取得と比較：範囲・費用・スケジュールを比べる
5. 契約・発注：契約形態や成果物、支払い条件を確認して合意する
6. 開発・途中確認：動くものを見ながら方向性をすり合わせる
7. 受け入れテスト・納品・運用：動作を確かめて受け取り、使いながら改善する

このうち、依頼する側の関わり方で結果が大きく変わるのは、1の準備、3の要件定義、7の受け入れテストです。開発そのものは依頼先の仕事ですが、「何を作るべきか」を一番よく知っているのは依頼する側です。以下、ステップごとに見ていきます。

ステップ1：外注前の準備（社内で整理しておくこと）

最初の相談の質は、事前の整理でほぼ決まります。完璧な資料は必要ありませんが、次の5点はメモ程度でもまとめておくと話が早く進みます。

目的：何に困っていて、何が変われば成功か

「在庫管理システムがほしい」は手段であって、目的ではありません。「店舗ごとの在庫をExcelで集計していて、月末に丸一日かかっている。これをなくしたい」のように、現状の困りごとと、どうなれば成功かを書き出します。目的がはっきりしていれば、依頼先から「その目的なら、この機能は後回しにできます」といった提案も出てきやすくなります。

使う人と場面

誰が、どこで、どの端末で使うのかを整理します。事務所のPCで社員3人が使うのか、外出先のスマホで営業担当が使うのか、一般のお客様が使うのかで、画面の作り方もログインの仕組みも変わります。使う人が複数の立場に分かれる場合（管理者と一般利用者など）は、それぞれ何ができればよいかも分けて書いておきます。

欲しい機能と優先順位

思いつく機能を箇条書きにして、「これがないと使えない」「あると便利」「将来ほしい」の3段階に分けます。はじめての外注で起こりがちなのが、最初から全部入りを目指して費用も期間も膨らんでしまうことです。まずは必須の機能だけで使い始め、実際の運用を見ながら追加するほうが、結果的に無駄が少なくなるケースは多いです。

予算の上限と使い始めたい時期

予算が決まっていなくても、「この金額を超えるなら今回は見送る」という上限の目安は持っておきます。時期についても、「展示会に間に合わせたい」「繁忙期の前に慣れておきたい」など、理由とあわせて伝えると、依頼先は範囲の切り方を考えやすくなります。

参考資料と現状のデータ

いま使っているExcelファイル、紙の帳票、申込フォーム、イメージに近い他社サイトのURLなどを集めておきます。言葉で説明するよりも、実物を一つ見せるほうがはるかに正確に伝わります。個人情報や社外秘の情報が含まれる場合は、ダミーデータに差し替えるか、秘密保持の取り決めをしてから渡すようにします。

ステップ2：依頼先への相談・問い合わせ

準備した内容をもとに、依頼先に問い合わせます。依頼先の候補としては、開発会社、フリーランスのエンジニア、マッチングサービスなどがあり、規模や予算、求めるスピードによって向き不向きがあります。

最初の依頼文は長くなくてかまいません。次のような一段落があれば、相手はかなり具体的に検討できます。以下はあくまで書き方の例です。

（例）飲食店を3店舗経営しています。現在、各店舗の食材在庫を店長がExcelに入力し、本部で毎月集計していますが、集計に丸一日かかり、入力ミスも多いのが悩みです。店長がスマホから在庫数を入力し、本部のPCで店舗別・品目別の一覧を見られる仕組みを作りたいと考えています。必須なのは在庫入力と一覧表示、CSV出力の3つで、発注機能は将来検討です。予算は○○万円以内、来月末から試験的に使い始めたいです。現在のExcelファイル（ダミーデータ）を添付します。

この例には、業種と規模、現状の困りごと、使う人と端末、必須機能と後回しの機能、予算の目安、希望時期、参考資料がすべて入っています。依頼文に含めておきたい項目を表にまとめると次のとおりです。

相談の段階では、分からないことを分からないまま伝えてかまいません。「サーバーのことはよく分からない」「スマホアプリとWebアプリの違いが分からない」と正直に書いておけば、相手も説明の仕方を合わせてくれます。逆に、よく分からないまま専門用語で指定してしまうと、本来は不要な作りを求める結果になりかねません。

なお、当サイトの VibeCoder でも、AIを活用した開発の依頼を依頼フォームから受け付けています。依頼の送信は無料で、送信後は担当者より2〜3営業日以内にご連絡します。上の例のような一段落の依頼文があれば、十分に検討を始められます。

ステップ3：要件定義とは何か、依頼者は何をするのか

要件定義とは、作るシステムが「何をできればよいか」を、関係者が同じ理解を持てるところまで具体的に決める工程です。機能の一覧だけでなく、画面の数と流れ、扱うデータの項目、権限（誰が何を見られるか）、対応する端末やブラウザ、そして「今回は作らないもの」までを明文化します。

開発会社によっては、要件定義を独立した有償の工程として扱う場合もあれば、見積もりの前段としてヒアリングの中で行う場合もあります。どちらの形になるかは、最初の相談の段階で確認しておくと安心です。

依頼する側が決めること

• 業務の流れ：今どういう手順で仕事をしていて、システム導入後はどう変わるのか
• 例外のケース：キャンセル、返品、入力の修正、担当者の不在時などをどう扱うか
• データの項目：顧客名、日付、金額など、何を記録し、どの項目が必須か
• 権限：管理者と一般ユーザーで、見られる情報や操作できる範囲をどう分けるか
• 作らないもの：今回の範囲に含めない機能を明示する

要件定義でつまずきやすい点

一番多いのは、「普段の流れ」だけを伝えて、例外の扱いを決めていないケースです。たとえば予約システムなら、予約の登録は誰でも思いつきますが、「前日のキャンセルはどうするか」「同じ時間に二重予約が入りそうなときはどうするか」は、実際に運用している人でないと気づきにくい部分です。こうした例外は後から追加すると手戻りが大きくなるため、要件定義の段階で洗い出しておくのが効果的です。

もう一つは、「作らないもの」を決めていないことです。範囲が曖昧なままだと、依頼する側は「当然入っていると思っていた」、依頼先は「頼まれていない」と、納品間際になって認識のずれが表面化します。今回は対象外とするものを一行でも書いておくだけで、こうした行き違いはかなり減ります。

ステップ4：見積もりの取得と比較のポイント

要件がある程度固まったら、見積もりを受け取ります。複数の依頼先から見積もりを取る場合は、同じ依頼内容・同じ資料を渡すことが大前提です。条件がそろっていないと、金額の差が作る範囲の差なのか、進め方の差なのか判断できません。

見積もりを比べるときは、総額だけでなく、次の観点を並べて見ると違いが見えやすくなります。

金額が大きく違うときは、安い・高いで判断する前に、上の観点のどこが違うのかを確認します。安い見積もりはテストや公開作業が含まれていなかった、高い見積もりは将来の拡張まで見込んだ作りになっていた、ということもあります。不明な点は遠慮なく質問し、その回答の丁寧さや分かりやすさも依頼先を選ぶ材料にしてください。

また、見積もりの段階で「最初は機能を絞って小さく作り、使いながら広げる」という提案をしてくれる依頼先は、依頼者の予算や目的をよく見ていることが多いです。範囲を削る提案は売上が減る方向の提案なので、その姿勢自体が一つの判断材料になります。

ステップ5：契約と発注時の注意点

依頼先が決まったら、契約を結んで発注します。ここでは契約形態の一般的な考え方と、確認しておきたい項目を整理します。個別の契約内容の判断については、必要に応じて弁護士などの専門家に相談してください。

請負と準委任の違い（一般的な整理）

システム開発の外注でよく使われる契約形態には、「請負」と「準委任」の二つがあります。

請負は、民法で「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定められています。システム開発でいえば、決めた仕様のシステムを完成させて納品することが約束の中心になります。作る範囲が明確に決められる場合に使われることが多い形です。

準委任は、法律行為ではない事務の委託について委任の規定を準用するものとして民法に定められており、実務では「一定の業務を行うこと」自体を依頼する形として使われます。要件が固まりきっていない段階の支援や、継続的な改善、保守運用などで選ばれることがあります。

どちらが良い・悪いというものではなく、作る範囲がどれだけ明確か、途中で変更が入る可能性がどれだけあるかによって向き不向きがあります。また、同じ案件の中で、要件定義は準委任、開発は請負、というように工程ごとに分けることもあります。実際の権利義務は契約書の条文によって決まるため、名称だけで判断せず、中身を確認することが大切です。

発注前に確認しておきたい項目

• 作業範囲と納品物が、見積もりや要件定義の内容と一致しているか
• 検収（受け入れ確認）の方法と期間、合格の基準
• 支払いの時期と方法（着手時・納品時など）
• 仕様変更や追加依頼が発生したときの手続きと費用の考え方
• 成果物（ソースコードなど）の権利がどちらに帰属するか
• 納品後に不具合が見つかった場合の対応
• 秘密保持と、渡したデータの扱い

特に見落としやすいのが、成果物の権利とソースコードの受け渡しです。将来ほかの依頼先に改修を頼む可能性があるなら、ソースコードを受け取れるか、自社で管理できる形になっているかは、発注前に確認しておきたいポイントです。

ステップ6：開発中の進め方と途中確認

発注後は依頼先が開発を進めますが、任せきりにするのはおすすめできません。できれば、画面の一部だけでも動く状態になった段階で見せてもらい、実際に触って確認する機会を設けてください。仕様書の文章では問題なさそうに見えても、実物を触ると「この項目は入力しにくい」「この順番は現場と逆だ」といった気づきが必ず出てきます。

途中確認を実りあるものにするために、依頼する側では次のような体制を整えておくと進行がスムーズです。

• 窓口を一人に決める：複数の人がばらばらに要望を出すと、依頼先はどれを優先すべきか判断できません
• 確認の返事を早くする：依頼者側の確認待ちで開発が止まることは、珍しくありません
• 実際に使う人にも触ってもらう：決裁者だけで確認すると、現場の使い勝手が見落とされがちです
• 要望は理由とセットで伝える：「ボタンを大きく」ではなく「現場は手袋をしたまま操作する」と伝えると、より良い解決策が出てくることがあります

途中で要望が変わること自体は、悪いことではありません。大切なのは、変更が範囲や費用、スケジュールにどう影響するかをその都度確認し、合意した内容を記録に残しておくことです。口頭だけのやり取りは、後から「言った・言わない」の原因になります。

ステップ7：受け入れテスト・納品・運用

開発が終わると、依頼する側が実際にシステムを動かして、要件どおりに作られているかを確認します。これを受け入れテストや検収と呼びます。ここは依頼者にしかできない仕事です。

確認するときは、思いつくままに触るのではなく、要件定義で決めた内容をもとに、確認項目を事前にリストにしておくと漏れが減ります。普段の業務の流れを最初から最後まで一通り試すことに加え、例外のケース（入力ミス、キャンセル、権限のない人がアクセスした場合など）も試しておきます。本番に近いデータで試すことも大切です。項目数や文字数が実際の業務に近くないと、表示の崩れや処理の重さに気づけないことがあります。

不具合を見つけたら、「どの画面で」「何をしたら」「どうなったか」「本来どうなるべきか」を具体的に伝えます。画面のスクリーンショットがあると、再現と修正がぐっと早くなります。

納品後は、実際の運用が始まります。使い始めると、想定していなかった要望や改善点が出てくるのが普通です。運用開始から少し経ったところで改善点をまとめ、優先度をつけて追加開発を相談する、という流れを最初から想定しておくと、はじめの範囲を無理に広げずに済みます。サーバーやドメインの契約、パスワードや管理画面のアカウントといった情報を、誰がどこで管理するのかもこの段階で整理しておきます。

発注前のチェックリスト

ここまでの内容を、発注前に見直せるチェックリストにまとめました。すべてが埋まっていなくても発注はできますが、空欄の項目は依頼先と相談して決めておくと安心です。

• 解決したい困りごとと、成功の状態を一文で説明できる
• 使う人（立場ごと）と、使う端末が整理できている
• 機能を「必須」「あると便利」「将来」に分けている
• 今回は作らないものを明示している
• 予算の上限の目安と、使い始めたい時期とその理由を伝えている
• 現在使っている資料やデータ（必要に応じてダミー化）を共有している
• 見積もりの作業範囲・前提条件・別途費用を確認している
• 契約形態、検収方法、支払い条件を確認している
• 成果物の権利とソースコードの受け渡しについて確認している
• 社内の窓口担当者と、確認に参加する現場の担当者を決めている
• 納品後の不具合対応と、追加開発の相談方法を確認している

よくある質問

要件がまだ固まっていなくても相談してよいですか

問題ありません。むしろ、要件が固まる前に相談することで、技術的にできること・できないことや、費用のかかりやすい部分を早めに知ることができます。その際は、この記事のステップ1で挙げた「目的」と「使う人」だけでも伝えられるようにしておくと、相談が具体的になります。

見積もりは何社から取るべきですか

決まった数はありません。比較の目的は、金額の安さを競わせることではなく、作業範囲や進め方の違いを知って、自分の案件に合った依頼先を選ぶことです。依頼内容と資料をそろえ、比べられる状態をつくることのほうが、社数よりも大切です。

開発の途中で要望を変えることはできますか

多くの場合は相談できますが、変更の内容や時期によっては、費用やスケジュールに影響します。契約前に、仕様変更が発生したときの手続きを確認しておき、変更を依頼するときは影響範囲を確認したうえで、合意内容を書面やメッセージで残しておくのが確実です。

専門知識がなくても依頼できますか

できます。依頼する側に求められるのは、技術の知識よりも、自分たちの業務や困りごとを具体的に説明することです。専門用語で指定するより、「今こうしていて、ここに困っている」と伝えるほうが、適切な提案を受けやすくなります。

納品までどれくらいかかりますか

作るものの規模や内容、要件の固まり具合、確認のやり取りにかかる時間によって大きく変わるため、一概には言えません。VibeCoder では最速1日で納品できるケースもありますが、納期は内容・規模によって異なります。希望の時期がある場合は、最初の相談で理由とあわせて伝えてください。

小さな改修や試作品だけの依頼でも受けてもらえますか

依頼先によって受けている案件の規模は異なるため、問い合わせの段階で確認するのが確実です。試作品を先に作り、実際に触ってから本格的な開発に進むかを判断する、という進め方は、はじめての外注でリスクを抑える方法の一つです。

参考

• 民法（e-Gov法令検索）：第632条（請負）、第643条（委任）、第656条（準委任）

まとめ

システム開発を依頼する流れは、準備、相談、要件定義、見積もり比較、契約、開発、受け入れテストと運用の7つのステップに分けて考えると整理しやすくなります。開発そのものは依頼先の仕事ですが、目的や業務の流れ、例外のケース、作らないものを決められるのは依頼する側だけです。

最初からすべてを完璧にそろえる必要はありません。困りごとと使う人、必須の機能、予算と時期の目安を一段落にまとめるところから始め、分からない部分は相談しながら決めていけば十分です。この記事のチェックリストを手元に置いて、最初の一歩を進めてみてください。