システム開発の発注は何から始めればいいですか？

まず「何を解決したいか（目的）」と「今困っていること」を箇条書きで整理するところから始めます。要件が固まっていなくても大丈夫です。目的が言葉になっていれば、あとは開発会社との相談の中で具体化していけます。

発注前に要件を完璧に決めておく必要はありますか？

いいえ。完璧な要件書は不要です。むしろ「まず必要な最小限（MVP）」に絞り、作りながら決めていく方が失敗しにくく、費用も抑えられます。要件定義は開発会社と一緒に進めるものと考えてください。

発注してから納品まではどれくらいかかりますか？

規模によりますが、小〜中規模なら最短2〜3週間で動くMVPをお出しし、そこからフィードバックを重ねて仕上げます。全体では1〜3ヶ月程度が目安です。

相見積もりは取ったほうがいいですか？

金額だけの比較なら効果は限定的です。比べるべきは「見積もりの根拠が明確か」「コミュニケーションが取りやすいか」。総額が最初に確定する一律料金なら、相見積もりの手間そのものを減らせます。

システム開発の発注の流れ｜初めてでも失敗しない7ステップ

「システム開発を頼みたいけれど、何から始めて、どう進むのか分からない」——初めての発注では、流れが見えないことが一番の不安です。この記事では、相談から納品までの発注の流れを 7つのステップに分けて解説し、各段階で発注者が何をすべきか・どこに注意すべきかをまとめます。

全体像を先に押さえておくと迷いません。発注は「①目的整理 → ②相談 → ③見積もり → ④要件定義 → ⑤設計・開発 → ⑥フィードバック → ⑦検収・納品」という7段階で進みます。このうち発注者の力が最も要るのは、実は序盤の①〜④です。ここで「何のために作るか」がはっきりしていれば、後半は開発会社主導でスムーズに進みます。逆にここが曖昧なまま開発に入ると、途中で作り直しが発生し、時間も費用も膨らみます。

まず前提として押さえておきたいのが、費用の見え方です。多くの開発会社では、要件定義を終えて機能が固まるまで総額が確定しません。そのため「相談した時点では、いくらかかるか誰にも分からない」という不安が付きまといます。当社のように一律料金（スタンダード100万円／プロ200万円）で追加費用なし・着手前に総額が確定する仕組みなら、この不安を最初の段階で消せます。総額が決まっていると、社内の予算取りや稟議も通しやすく、「どこまで足したら追加請求されるのか」と身構えながら進める必要もありません。

STEP1：目的と課題を整理する

最初にやるのは、立派な要件書づくりではありません。「何を解決したいか」「今、何に困っているか」を箇条書きにするだけで十分です。

例：「FAXと電話の注文を手入力していて時間がかかる」「予約管理がExcelで属人化している」
「誰の・どの業務を・どう楽にしたいか」が言葉になっていればOK

コツは、要望（こういう機能が欲しい）ではなく**課題（こういう状態で困っている）**から書くことです。「在庫管理システムが欲しい」ではなく「棚卸しに毎月2日かかり、在庫のズレも月に何度か起きる」と書けば、開発会社は解決策の幅を広く提案できます。あわせて次の3点をメモしておくと、後の相談が一気に進みます。

困っている業務の頻度と量（1日◯件、月◯時間など、ざっくりで可）
今その業務に関わっている人数と役割
「これができたら理想」の状態（数字で言えると尚良い。例：棚卸しを半日に）

要件が固まっていなくても発注はできます。目的さえ共有できれば、具体化は開発会社と一緒に進められます。

STEP2：相談・問い合わせ

整理した課題を持って、開発会社に相談します。この段階では費用感・実現可能性・進め方をざっくり掴むのが目的です。成果物を決める場ではなく、「この会社と組んで大丈夫そうか」を見極める場だと考えてください。

「これくらいの予算でどこまでできるか」を率直に聞く
専門用語で丸投げせず、業務の背景や優先順位を伝える
似た業種・規模の実績があるか、担当者と話が噛み合うかを見る

相談のとき、こちらから投げておくと相手の力量が分かる質問があります。

「今回の課題だと、どんな作り方（進め方）になりそうですか」
「追加費用が発生するのは、どんなときですか」
「納品後の修正や不具合対応は、どういう扱いになりますか」

これらに具体的に・分かりやすく答えられる会社は、その後のやり取りも安心です。逆に、質問をはぐらかしたり専門用語で煙に巻いたりする相手は、開発が始まってからも意思疎通で苦労しがちです。相談は複数社にしても構いませんが、比べるべきは金額そのものより「説明の透明性」と「話しやすさ」です。会社選びの具体的な観点は失敗しない開発会社の選び方にまとめています。

STEP3：見積もり・プランの確認

相談内容をもとに、見積もりとプランが提示されます。ここで確認すべきは金額だけではありません。

見積もりの根拠が明確か（何にいくらかかるのか）
含まれる範囲（要件定義・テスト・納品後の対応）はどこまでか
追加費用が発生する条件は何か

とくに見落としやすいのが、**見積もりに「入っていないもの」**です。次の項目が含まれるか、この段階で確認しておきましょう。

確認したい項目	見積もりに含まれるか
要件定義・設計の工数	含む／別料金
テスト・不具合修正	含む／別料金
サーバー・ドメインなど運用費	含む／別料金・実費
納品後の保守・サポート	含む／月額別途
仕様変更が出たときの追加費用	どこから発生するか

一般的な見積もりは「人月（にんげつ）×単価」で積み上がるため、機能が増えるほど金額が動きます。相場や人月の考え方はシステム開発の費用相場と人月の意味と単価の目安で詳しく解説しています。一方で当社の一律料金は、この積み上げ計算そのものをなくし、着手前に総額を固定する仕組みです。「機能を1つ足すたびに見積もりを取り直す」という往復が発生しないため、社内調整も進めやすくなります。

STEP4：要件定義（一緒に決める）

「何を作るか」を具体化する工程です。ここが曖昧だと後工程で手戻りが増えるため、最も重要な段階と言えます。

表面的な要望だけでなく、その裏にある目的まで掘り下げる
「まず必要な最小限（MVP）」と「あとで足すもの」を分ける
画面イメージや業務フローを一緒に確認する

この工程の成果物は、多くの場合「要件定義書」や「画面イメージ（ワイヤーフレーム）」です。専門的な文書を発注者がゼロから書く必要はありません。開発会社がヒアリングをもとに叩き台を作り、それを見ながら「ここは違う」「この操作が抜けている」とすり合わせていくのが正しい進め方です。確認するときは、次の視点を持つとズレを潰せます。

例外・イレギュラーの扱い：正常時だけでなく「キャンセルが出たら」「入力を間違えたら」どうなるか
誰が使うか：パソコンに不慣れな人でも操作できるか、スマートフォンでも使うか
既存の業務・ツールとの接続：今使っているExcelやツールからの移行はどうするか

要件定義のまとめ方や陥りやすい罠は要件定義の進め方で掘り下げています。発注者側で完璧に決める必要はありません。開発会社と対話しながら固めていくのが正しい進め方です。

STEP5：設計・開発

要件をもとに設計し、開発に入ります。おすすめはいきなり全部を作らず、まず動くMVPを早く出す進め方です。MVPとは「価値を出せる最小限の製品」のこと。全機能を数ヶ月かけて一気に作るのではなく、まず核となる1業務が動く状態を短期間で作り、そこから育てていく考え方です。

最短2〜3週間で「触れる最小版」を確認できる
早い段階で実物を見られるので、認識のズレを防げる
効果を早く体感でき、社内の合意も取りやすい

この期間、発注者は「待つだけ」ではありません。開発中の関わり方が、仕上がりを大きく左右します。

定期的に途中経過を確認する：週1回など、動くものを見せてもらう場を決めておく
質問には早めに返す：仕様の判断待ちで開発が止まると、その分だけ完成が遅れます
仕様変更は早いほど安い：作る前の変更は簡単ですが、完成後の変更は作り直しになりがちです

なお、開発中に「やっぱりこの機能も」と追加要望が出るのは自然なことです。ポイントは、追加費用の線引きを最初に握っておくこと。一般的な請負契約では、当初の要件から外れる機能は追加見積もりの対象になります。当社の一律料金は総額が固定されているぶん「どこまでが範囲か」を着手時に明確にするので、進行中に金額で揉めることを避けられます。

STEP6：フィードバックと調整

MVPを実際に触り、気づいた点をもとに修正・改善を繰り返します。

「使ってみて初めて分かること」を反映できる
優先順位を都度すり合わせながら仕上げる

フィードバックは、具体的に・優先順位をつけて伝えると効果的です。「なんとなく使いにくい」ではなく「この画面で、注文と発送のボタンが隣にあって押し間違える」のように、状況と困りごとをセットで伝えます。実際の業務を想定した使い方（複数人で同時に使う、繁忙期の件数を入れてみる等）を試すと、本番で困る点を先に洗い出せます。あわせて、出てきた要望を「今すぐ直すべき／あとでいい」に仕分けると、限られた期間で優先度の高いものから確実に仕上がります。

STEP7：検収・納品

仕上がったものを確認（検収）し、問題なければ納品・お引き渡しです。

想定どおり動くか、実際の業務データで確認する
公開後の保守・運用が必要な場合は、別途どう体制を組むか決めておく

検収は「なんとなく動いた」で済ませず、STEP4で決めた要件を1つずつ突き合わせて確認します。次のチェックリストが目安です。

要件定義で決めた機能がすべて動くか
実際の業務データを入れても問題なく動くか（テスト用の少量データだけで判断しない）
スマートフォンなど想定した環境で正しく表示・操作できるか
操作マニュアルや、引き継ぎに必要な資料が揃っているか
ソースコード（成果物）の権利が自社に渡るか

最後の点は特に重要です。開発会社によっては、納品後もソースコードの権利を渡さず、改修のたびに元の会社に頼らざるを得ない状態（いわゆるベンダーロックイン）になることがあります。当社は成果物の権利を顧客に譲渡する方針なので、将来ほかの会社に引き継ぐことも、自社で手を入れることも可能です。ロックインのリスクについてはベンダーロックインとはで詳しく解説しています。

納品後：公開・運用・保守への引き継ぎ

検収が終わっても、そこで終わりではありません。多くのシステムは「作って終わり」ではなく「使い続ける」ものだからです。納品のあとに待っているのは、公開（本番稼働）→運用→保守という流れです。ここを最初に想定しておかないと、いざ本番で困ります。

公開（本番稼働）：テスト環境から本番環境に移し、実際の業務で使い始める段階。移行のタイミングや、既存データの引っ越しをいつやるかを決めておきます。
運用：日々使う中でのアカウント管理やデータのバックアップなど。誰が管理するかを社内で決めておきます。
保守：不具合の修正や、OS・ブラウザの更新への追従、小さな改善など。

保守は「月額いくらで、どこまで対応してもらえるか」を納品前に握っておくのが理想です。ここが曖昧だと、公開後に軽い不具合が出ただけでも「これは有料ですか？」というやり取りが発生します。あわせて、将来ほかの会社に引き継げる状態かも確認しておきましょう。ソースコードと簡単な設計資料が手元にあれば、保守の相談先を後から選び直せます。当社は成果物の権利を顧客に渡すため、こうした引き継ぎの自由度を確保できます。

ミニ事例：小さく始めて育てた例

例：ある小売店で「予約と在庫の管理がExcelで属人化し、担当者が休むと業務が止まる」という課題があったとします。この場合、最初から全機能を作り込むのではなく、まず予約管理だけを動くMVPとして2〜3週間で用意します。現場で1〜2週間使ってもらうと、「キャンセル待ちの機能が欲しい」「スマートフォンからも登録したい」といった、机上では出てこなかった要望が具体的に見えてきます。それを優先順位順に足していくことで、使わない機能に費用をかけず、本当に効く機能から仕上げられます。総額が最初に固定される一律料金なら、こうした「動かしながら足す」進め方でも費用が読めるため、腰を据えて改善に取り組めます。

契約形態は「請負」と「準委任」のどちらか

発注の途中で交わす契約には、大きく2つの型があります。用語として知っておくと、見積もりや契約書を読むときに迷いません。

契約形態	特徴	向いているケース
請負契約	「完成」を約束し、成果物に対して支払う	作るものが決まっている。総額を固定したい
準委任契約	「作業（工数）」に対して支払う。完成は保証しない	要件が流動的で、伴走しながら決めたい

初めての発注で「総額を先に確定させて安心して進めたい」なら、成果物の完成を約束する請負型が分かりやすい選択です。当社の一律料金は、この「総額が最初に決まる安心感」を突き詰めた形と言えます。契約書で見るべき条項や注意点はシステム開発の契約で確認すべきことにまとめています。

各ステップにかかる期間の目安

規模により変わりますが、小〜中規模の場合の目安です。

ステップ	期間の目安
目的整理〜相談	数日〜1週間
見積もり・要件定義	1〜2週間
開発〜MVP提示	最短2〜3週間
フィードバック〜検収・納品	2〜4週間

全体では、小〜中規模で1〜3ヶ月程度が目安になります。ここで挙げた期間は、あくまで「順調に進んだ場合」の目安です。実際には、発注者側の確認や判断が滞ると、その分だけ後ろにずれ込みます。開発会社の作業スピードだけでなく、発注者側の意思決定の速さも納期を左右する、と覚えておくと段取りしやすくなります。

発注前に準備しておくとスムーズなもの

次を用意しておくと、初回相談から一気に話が進みます。完璧でなくて構いません。

現状の業務フロー（手書きのメモ程度でOK）
いま使っている紙・Excel・ツールの実物やスクリーンショット
「これができたら嬉しい」の具体例
ざっくりの予算感・希望時期
社内で誰が判断するか（決裁者・窓口担当を先に決めておく）
いつまでに使い始めたいかの目標時期

このうち意外と効くのが「誰が判断するか」を先に決めておくことです。仕様の相談が出るたびに社内で持ち帰り、返事に何日もかかると、開発全体が間延びします。窓口を一本化し、その場である程度の判断ができる体制にしておくと、進行が驚くほど速くなります。

発注でよくあるつまずきと回避策

丸投げしてしまう：「専門的なことは分からないので良い感じに」はNG。業務目的・優先順位は発注者しか決められません。目的だけは自分の言葉で伝えましょう。
要件を盛り込みすぎる：全部を一度に作ると高く・遅くなります。効果の大きい1業務から始め、動かしながら足すのが定石です。
金額だけで選ぶ：根拠の透明性・コミュニケーションの取りやすさを重視しましょう。安さの裏に「あとから追加費用」が隠れていないか確認を。
確認・返事を後回しにする：発注者の判断待ちで開発が止まると、そのぶん納期が延びます。窓口と決裁ラインを最初に決めておきましょう。
検収を甘くする：「動いているっぽい」で受け取ると、本番で不具合が出たときに揉めます。要件と1つずつ突き合わせて確認を。

内製と外注のどちらが自社に合うか迷っている場合は内製と外注の比較も参考になります。

まとめ

発注の流れは「①目的整理 → ②相談 → ③見積もり → ④要件定義 → ⑤開発 → ⑥フィードバック → ⑦検収・納品」の7ステップ。要件は完璧でなくてよく、目的さえあれば始められます。カギは、序盤で「何のために作るか」を自分の言葉で伝えること、そして小さく（MVPで）始めて動かしながら育てることです。総額が最初に決まる一律料金なら、見積もりの不安や相見積もりの手間、進行中の追加費用の心配も減らせます。「何から始めれば？」で迷ったら、まずはお気軽に無料相談へどうぞ。