「そろそろ外部に頼んだほうがいい気がする。でも、どこに・いくらで・何から始めればいいのか分からない」。初めてシステム開発を依頼する担当者の方から、私たちが名古屋・東京・福岡で最もよく受ける相談です。見積もりを取ったら桁が想像と違った、要件が曖昧なまま発注して途中で費用が膨らんだ、という声も珍しくありません。

本記事では、システム開発を外部に依頼するときの準備・流れ・費用・依頼先の選び方・契約で確認すべき点・よくある失敗を、発注する側の目線で一つにまとめました。読み終えたときに「明日、社内で何を決めて、開発会社に何を聞けばいいか」が具体的になることを目指しています。

この記事でわかること

• 依頼前に社内で決めておくべき4つのこと
• 問い合わせから運用開始までの8ステップと、各段階で発注側がやること
• 人月単価とシステム種類別の費用相場、費用を左右する要因
• 大手SIer・中堅開発会社・フリーランス・オフショアの違いと選び方
• 契約前に見抜きたい危険サインと、契約書で確認する4項目

想定読者

• 社内にエンジニアがおらず、初めてシステム開発を外部に依頼する情報システム・DX推進の担当者
• Excel・kintone・Power Automateなどのツール運用に限界を感じ、業務システム化を検討している方
• 開発会社から見積もりを受け取ったが、金額や内容が妥当か判断できない方
• 過去の外注で「思っていたものと違う」経験があり、次は失敗したくない経営者・部門責任者

システム開発を依頼する前に決めておくこと

開発会社に連絡する前の準備で、見積もりの精度と会社選びの精度がほぼ決まります。完璧な資料は要りません。A4で1〜2枚、次の4点が書けていれば、開発会社は的を射た提案を返せます。

解決したい業務課題を1枚にまとめる

「今のExcel管理をシステム化したい」という依頼だけでは、開発会社は見積もりを出せません。現在の業務の流れ・困っている具体的な場面・システムが入った後の理想の状態の3つを、箇条書きで構いませんので言葉にしてください。「受注入力に毎日2時間かかり、月末に転記ミスが必ず出る」のように、頻度と影響が書けていると理想的です。

利用者・利用環境・連携先を洗い出す

• 誰が使うか：利用部門と人数、同時に使う人数の目安
• 何で使うか：PCだけか、現場や外出先のスマートフォン・タブレットでも使うか
• 何とつなぐか：会計・販売管理・勤怠など、既存システムとのデータ連携の有無

とくに連携先の数は費用に直結します。既存システムとつなぐ箇所が1つ増えるごとに、調査・設計・テストの工数が上乗せされるためです。

予算の上限と稼働希望時期を決める

予算は「いくらまでなら投資できるか」の上限で構いません。上限があると、開発会社は機能の優先順位を付けた提案ができます。稼働希望時期は、決算期・繁忙期・既存契約の更新月など、社内の事情から逆算して決めてください。この2つが決まっていない相談は、提案の幅が広すぎて比較できなくなりがちです。

作るか、買うか、ツールで済ませるかを見極める

依頼の前に、開発方式の選択肢を知っておくと会社選びがぶれません。主な方式は3つです。

「パッケージでは業務に合わなかった」「ツールの自動化では限界が来た」という段階で初めて、スクラッチでの依頼が候補になります。内製と外注のどちらが合うかは、次の記事で判断基準を整理しています。

システム開発を依頼する流れ｜問い合わせから運用開始までの8ステップ

ここからが本題です。開発会社との最初の接点から、システムが現場で動き始めるまでを8つの段階に分けて、それぞれで発注側がやることを整理します。「今どこにいて、次に自分たちが何を決めるのか」を見失わないための地図として使ってください。

ステップ1：提案依頼書（RFP）をつくる

提案依頼書（RFP：Request for Proposal）は、システムに求めること・スケジュール・予算・選定基準を書面にして開発会社へ渡す資料です。前章でまとめた1枚の課題整理を、そのまま土台にできます。

口頭で伝えるより書面にしたほうが、複数社に同じ条件で提案を求められ、後から「言った・言わない」になりません。形式にこだわる必要はなく、初回は箇条書きの依頼メモでも十分です。書き方の要点は次の記事にまとめています。

ステップ2：複数の会社に相見積もりを取る

同じ依頼書を使って、3社前後に見積もりを依頼します。1社だけだと相場が分からず、交渉の材料も持てません。逆に6社以上になると提案の読み比べだけで工数が膨らむので、本命2〜3社に保険で1〜2社を加えた3〜5社が現実的な数です。

見積もりと一緒に、提案内容・開発体制・似た案件の実績も必ず出してもらってください。金額だけでは比較できません。

ステップ3：提案と見積もりを比較する

比較の軸は「総コスト」です。単価で並べると判断を誤ります。開発費に加えて、リリース後の保守・運用費を5年分足した金額で並べると、判断を誤りにくくなります。見積もりに保守費が含まれているか、何が含まれて何が含まれないかも、この段階で確認します。

不明点は遠慮なく質問してください。回答の丁寧さと速さは、契約後のコミュニケーションの質をそのまま映します。見積書の内訳の読み方は、次の記事で項目ごとに解説しています。

ステップ4：契約を結ぶ

依頼先が決まったら、秘密保持契約（NDA）と開発契約を結びます。契約書で確認すべき項目は後の章で詳しく扱いますが、この時点で最低限押さえたいのは「今回のスコープはどこまでか」と「追加費用が発生する条件」の2つです。ここを文書で合意しておくと、開発中の「それは仕様外です」というやり取りが激減します。

ステップ5：要求定義と要件定義を行う

要求定義は、発注側が「システムに何をしてほしいか」を明確にする作業です。要件定義は、その要求を受けて開発側が「具体的にどう実現するか」を、機能・データ・画面・性能・セキュリティの観点でまとめる作業です。ここで機能の範囲、予算、体制、期間が確定します。

この工程は、双方が納得するまで時間がかかることがあります。それでも要件定義に力を入れた案件ほど、設計以降がまっすぐ進みます。開発費全体の15〜25%を要件定義に充てるのは合理的な投資です。

期間の目安も持っておいてください。中規模の業務システム（開発全体で100〜300人月程度）なら、全体ヒアリングに1〜2週、部門別の業務フロー整理に3〜6週、現行システムの調査に2〜4週、要件の整理と合意に3〜6週で、合計3〜6か月が標準的な密度です。小規模なツールなら数週間で済みますが、「1回の打ち合わせで要件が決まりました」という進め方は規模を問わず危険信号です。

ステップ6：設計を行う

設計は外部設計と内部設計に分かれます。外部設計は利用者が触れる画面や操作の流れを決めるもので、使いやすさはここで決まります。内部設計はデータ構造や処理の仕組みを決めるもので、将来の保守や改修のしやすさに効いてきます。

発注側が深く関わるのは外部設計です。画面案が出てきたら、実際に使う現場の担当者に見てもらってください。「この順番では入力しない」「この項目は現場では使わない」といった指摘は、この段階なら小さな修正で済みます。

ステップ7：開発とテストを進める

設計が固まると、開発会社がプログラミングを進めます。発注側は週次または隔週の進捗報告を受け、認識のずれを早めに直す役割を担います。

テストは、部品ごとの単体テスト、部品を組み合わせた結合テスト、要件どおりに動くかを見る総合テスト、実際の業務の流れで確認する運用テストの順に進みます。運用テストには必ず現場の担当者が参加してください。リリース後に「思っていたのと違う」が起きる案件の多くは、テストを開発会社任せにしていたケースです。

ステップ8：納品し、運用・保守へ移る

テストで問題がなければ納品です。発注側は、システムが動く環境（端末、ネットワーク、権限）を現場に整えておきます。納品後は、正しく動き続けているか、セキュリティ上の問題がないかを見続ける必要があります。

運用・保守も同じ会社に頼む場合は、リリース直後のサポート期間（不具合対応や操作の問い合わせ対応）の条件と費用を、納品前に確認しておきましょう。

各ステップで発注側が握っておくもの（早見表）

8ステップを通して、発注側の手元に残しておくべき成果物と、つまずきやすい点を一覧にしました。開発会社との打ち合わせ前に、該当する行だけ確認する使い方を想定しています。

システム開発の依頼にかかる費用｜人月単価と規模別の目安

システム開発の費用は、その大半が人件費です。「誰が・何か月働くか」で決まるため、見積書は人月（1人が1か月働く工数）×単価の形で組み立てられます。

人月単価の相場

単価は会社の規模、エンジニアの経験、地域で幅があります。同じ「SE 1人月」でも上流工程に強い人と実装中心の人では中身が違うため、単価の高低だけで良し悪しは判断できません。

システムの種類・規模別の費用目安

基幹システムの規模別の詳しい相場は、次の記事で500万円から3億円までの目安を工程別に解説しています。

見積書で確認する内訳の粒度

相場を知っていても、見積書の粒度が粗ければ妥当性は判断できません。健全な見積書は、少なくとも次の粒度で内訳が出ています。

• 工程ごとの人月数×単価：要件定義・設計・開発・テスト・移行・運用引き継ぎのそれぞれに、何人月かかり単価がいくらか
• 役割ごとの分解：PM・SE・PG・テスターの単価が分かれているか
• ハードウェア・ライセンスの個別品目：サーバー費用や外部サービスの利用料が「別途」でなく品目と数量で示されているか
• 予備費（バッファ）の扱い：10〜20%程度が明示され、使わなかった場合の扱い（返金または別作業に充当）が書かれているか

「要件定義一式」「開発一式」のように工程単位の金額しかない見積書は、開発会社側も詳細を詰めずに概算で出している可能性が高く、契約後の追加請求につながりやすい形です。内訳の提示を求めたときの反応も、会社を見極める材料になります。

費用を左右する4つの要因

• 連携するシステムの数：既存システムとのAPI連携が増えるほど、調査・設計・テストの工数が増える
• 利用者数・同時接続数：サーバー費用やライセンス費、性能要件に影響する
• 要件の明確さ：曖昧なほど開発中の仕様変更が増え、追加費用につながる
• 保守・運用費：リリース後に年間で開発費の10〜20%程度が目安。見積もりに含まれているか必ず確認する

見積もりを受け取ったら、これらの要因がどう積み上がっているかを内訳で確認してください。工程ごとの人月数と単価、役割ごとの分解、予備費（バッファ）の有無が読み取れる見積書が健全な形です。

依頼先の種類と選び方｜大手SIer・中堅開発会社・フリーランス・オフショア

「どこに頼むか」は、会社名の前に「どの種類の依頼先が自社の案件に合うか」から考えると迷いが減ります。

中堅・中小企業の業務システムでは、業務を理解して要件から一緒に組み立てられる中堅の開発会社が選ばれることが多くあります。規模より「自社の案件にどれだけ注力してくれるか」「責任者の顔と名前が分かるか」を軸にすると、規模に関係なく良い依頼先が見つかります。

開発会社を選ぶ3つの判断軸

軸1：自社の業種・規模に近い実績があるか。開発会社には得意分野があります。製造業の受発注管理、店舗向けの予約システム、既存基幹との連携開発など、自社のニーズに近い実績を持つ会社を優先してください。経験のない領域では見積もりが甘くなりがちです。公式サイトに載っていない非公開の実績もあるので、商談の場で直接聞くのが確実です。

軸2：要件定義など上流工程に強いか。「言われたものをそのまま作る」会社と、「課題を一緒に整理して解決策を提案する」会社では、できあがるものの質が変わります。初回のヒアリングで、現状の課題をどう整理して返してくるかを見れば姿勢が分かります。

軸3：開発後の保守・サポート体制があるか。業務システムはリリースがゴールではありません。業務の変化に合わせた機能追加、不具合修正、操作の問い合わせ対応が続きます。開発と保守を一貫して担える会社のほうが、長い目で見たコストと安心感で有利です。

初回の打ち合わせで確認する4つのこと

3つの判断軸を満たしそうな会社が見つかったら、初回の打ち合わせで次の4点を直接確認してください。提案書には書かれにくく、聞かなければ分からないことばかりです。

類似業界・類似規模の実績。同じ業界の事例を3件、同じくらいの売上規模・従業員数の事例を2件、できれば今回の責任者が関わった事例を出してもらいます。「業界が違うので参考になりません」と返す会社は、経験を汎用化して使う力が弱い可能性があります。

プロジェクト責任者との顔合わせ。提案の場で話す営業担当と、実際に案件を動かす責任者は別の人であることが普通です。契約前に責任者本人と会い、経験年数、似た案件の実績、ほかに何件を兼任しているか、途中で交代する場合の方針を聞いてください。兼任が多すぎる責任者は、自社の案件に割ける時間が限られます。

開発体制と連絡の取り方。責任者1名・SE2〜3名・PG3〜5名のような体制図が出てくるか、定例会議は週次か、日常の連絡はチャットかチケット管理ツールか、レビューやテストの責任者は誰か。ここが曖昧な会社は、開発が始まってからの意思疎通で苦労します。

過去のトラブルと対応。過去の案件で起きたトラブル、その原因、顧客への説明、そこから変えた進め方を自分から話してくれる会社は信頼できます。「トラブルは起こしたことがありません」と言う会社は、経験が浅いか、正直に話していないかのどちらかです。

候補を客観的に比べる4軸スコアリング

複数社を比較するときは、点数で並べると判断が安定します。次の配点で採点し、70点以上を最低ラインにする方法をおすすめしています。

80点以上なら安心して進められる候補、60点台なら他社と再比較、60点未満は候補から外す、という目安で使ってください。

「どこに頼めばいいかわからない」という段階でも、c3indexにご相談ください。費用感・進め方を無料でご説明します。

契約前に見抜きたい5つの危険サイン

依頼先選びの失敗には、ほぼ共通したパターンがあります。契約前の提案・ヒアリングの段階で出ている警告を見逃していることです。良い提案書は誰でも作れますが、危険サインは隠しても出てしまいます。

見積もりの内訳が一式表記だけ

「要件定義一式」「開発一式」のように工程単位の金額しかなく、人月数や単価、予備費が見えない見積書は要注意です。開発が始まってから「想定より工数がかかった」を理由にした追加請求が起きやすくなります。工程ごと・役割ごとの内訳と、10〜20%程度の予備費が明示されている見積書を求めてください。

「全部おまかせください」と言う

心強く聞こえますが、業務のことを外部が1〜2回のヒアリングで理解しきることはできません。丸投げで作ったシステムは、中身を知っているのが開発会社だけという状態になり、保守費用の交渉力を失います。「業務はお客様が一番詳しいので、役割分担を決めて一緒に作りましょう」と言う会社のほうが信頼できます。

要件定義を1回の打ち合わせで終わらせようとする

ヒアリングが1〜2回で終わり、すぐ提案書と見積書が出てくる場合は、要件を詰める気がないか、まず契約を取りたいだけかのどちらかです。要件定義を浅く済ませた案件は、開発中に「それは要件に入っていません」が続き、最終的な総額が当初見積もりの2〜3倍になることがあります。

契約書の保守条件と成果物の権利が曖昧

保守を続ける条件や、ソースコードの権利・開示について契約書に明確な記載がない場合、後から保守料金を値上げされたり、他社に保守を頼めない状態になったりします。次の章で確認項目を具体的に挙げます。

動くものを見せずに本契約を急かす

数千万円規模の案件で、提案書だけで本契約を急ぐ会社は避けたほうが安全です。PoC（概念実証）として、本契約予定額の5〜10%程度で2〜3か月かけて中核機能を実際に動かし、性能や既存システムとの連携を確認してから本契約に進む方法があります。健全な会社は、この進め方を自分から提案してきます。

契約時に確認する4項目

契約前は、開発内容や費用の変更を何度でも相談できます。契約後の変更には手数料やキャンセル料が発生することがあるため、契約書は責任者だけでなく複数人で読み込んでください。とくに次の4項目は、曖昧な箇所があれば文書で明確化を求めるのが鉄則です。

1. 保守継続の条件と料金見直しの条件：自動更新か毎年再契約か、値上げの条件、開発会社側の都合で保守を終える場合の通告期間と引き継ぎ責任
2. 成果物の権利とソースコード：著作権の帰属、ソースコードの開示義務、第三者への保守委託が可能か。「開発会社に権利・開示なし・他社委託禁止」の組み合わせは、事実上のベンダーロックインになる
3. 契約解除時の取り扱い：開発途中で解除する条件と精算方法、データ・ドキュメント・ソースコードの返還義務、違約金の有無と金額
4. 契約不適合責任の期間：納品物に欠陥があった場合の無償修正期間（6〜12か月が一般的）と、業務影響が出た場合の損害賠償の上限

契約形態は請負か準委任か

開発契約には2つの形があります。請負契約は「完成した成果物」に対して対価を払う形で、要件が固まっている設計以降の工程に向きます。準委任契約は「作業時間や工数」に対して対価を払う形で、要件が動く要件定義やPoC、リリース後の改善に向きます。

実務では、要件定義を準委任で進めて要件を固め、開発を請負で発注する組み合わせがよく使われます。どちらか一方に統一する必要はありません。見積書にどの工程がどの契約形態かが書かれているかを確認し、書かれていなければ質問してください。ここが曖昧だと、仕様変更のたびに「追加費用か、契約範囲内か」の議論が起きます。

「作った会社と保守する会社が別」という状態は、障害が起きたときに効いてきます。保守会社を将来変える可能性も踏まえ、引き継ぎに必要なものが契約上確保されているかを見ておいてください。

社内の進め方｜誰が決めて、誰を巻き込むか

依頼がうまくいくかどうかは、開発会社選びと同じくらい、社内の役割分担で決まります。情報システム部門だけで抱え込んだ案件は、要件定義で現場の実態が漏れ、納品後に使われないシステムになりがちです。

経営層が必ず関与する2つの場面

すべての工程に経営層が出る必要はありませんが、契約書への署名と、プロジェクト責任者との顔合わせの2つは経営判断の領域です。契約書は保守費用・解約条件・成果物の権利に直結し、責任者の力量は数か月から数年の付き合いの質を決めます。この2点だけは、法務や情シス任せにせず、決裁者自身が確認してください。

現場を巻き込むタイミング

現場の担当者に出てもらう場面は、要件定義のヒアリング、外部設計の画面確認、運用テストの3つです。この3つを外して進めると、「今の業務の例外処理が反映されていない」「入力順が実際と違う」が納品後に噴き出します。現場の時間を確保するのは発注側の仕事なので、計画段階で日程を押さえておいてください。

稟議に必要な材料

予算承認の場で決裁者が見るのは、費用の総額よりも「なぜ今か」「やらないと何が起きるか」「効果をどう測るか」の3点です。現状の業務にかかっている時間や手戻りのコスト、属人化や老朽化のリスク、導入後に追う指標（入力時間、ミス件数、月次締めの日数など）を、依頼前の課題整理から引き出して並べると通りやすくなります。

システム開発の依頼でよくある失敗と対策

要件が曖昧なまま発注する

「誰が・何を・どのように・どの頻度で使うか」が決まっていないまま発注すると、開発中に仕様変更が頻発し、費用と期間が膨らみます。対策は、発注前に現在の業務フロー・具体的な課題・理想の状態を1枚にまとめることです。冒頭の準備の章に戻って、書けていない項目がないか確認してください。

最安値の会社を選んで品質トラブルになる

相見積もりで明らかに安い会社を選んだ結果、納品物の品質が低く、修正費が膨らむケースは繰り返し起きています。安さは費用対効果と同じではありません。初期見積もりが3割高くても、要件定義と契約を丁寧に進める会社のほうが、総額では安く収まることが多くあります。

要件定義を急いで「思っていたものと違う」が起きる

早く完成させたい気持ちから要件定義を短縮すると、リリース後に現場から「これでは業務が回らない」が出て、改修費が初期費用の3〜5割に達することがあります。要件定義は保険だと捉え、期間と費用を確保してください。

テストに現場が参加しない

運用テストを開発会社と情報システム部門だけで済ませると、実際に使う現場の手順とのずれが納品後に見つかります。テスト計画を立てる段階で、現場の担当者の参加日程を確保しておくのが対策です。

保守を考えずに契約し、身動きが取れなくなる

開発費だけを見て契約し、保守の条件やソースコードの権利を確認しなかった結果、数年後に保守料金の値上げを飲むしかなくなった、他社に乗り換えたくても引き継ぎに必要な資料がない、という相談は珍しくありません。契約時に確認する4項目を、開発が始まる前に文書で固めておくことが唯一の対策です。

外部に依頼するメリットと、内製が向くケース

外部に依頼する利点は3つあります。社内にエンジニアがいなくても要望に合ったシステムを作れること、採用や育成にかかる時間と費用を省けること、過去の案件から見通しを立てられる会社なら完成までのスケジュールを最初に共有してもらえることです。発注側が関わる時間は、依頼書づくり、要件確認の打ち合わせ、テストへの参加に集中します。

一方で、仕様変更が日常的に起きる領域や、社内に開発を担える人材と育てる意思がある場合は、内製のほうが合うこともあります。どちらが自社に向くかの判断基準は、先ほど紹介した内製と外注の比較記事で整理しています。

よくある質問

Q. 要件がまだ固まっていなくても相談できますか？

A. できます。むしろ固まる前の相談をおすすめします。「何を作るか」を一緒に整理するところから支援できる会社を選ぶと、仕様のずれが少なくなります。持参するものは、困っている業務の場面を書いたメモだけで十分です。

Q. 予算が100万円以下でもシステムを作れますか？

A. 機能を絞れば可能です。「申請フォームと承認通知」「シンプルな在庫台帳」のような単機能なら、100万円以下で実現できるケースがあります。まず一番解決したい課題1つに絞って相談してください。

Q. 今のExcel管理をそのままシステムにできますか？

A. 技術的には可能ですが、そのまま移すよりも「そのExcelで何を管理したいのか」を整理し直してから設計するほうが使いやすくなります。Excel固有の手作業の流れをシステムに持ち込んでしまうと、かえって手間が増えることがあるためです。

Q. 大手SIerと中堅の開発会社、どちらに頼むべきですか？

A. 規模より「自社の案件への注力度」で判断してください。大手は安心感がありますが、多数の案件の1つになると担当の注力度が下がることがあります。中堅は規模が小さい分、注力度が高い傾向があります。責任者の顔と名前が分かるか、判断が早いかを基準にすると、規模に関係なく合う会社が見つかります。

Q. 何社に声をかければいいですか？

A. 3〜5社が現実的です。1〜2社では比較にならず、6社以上では提案の検討だけで手が回らなくなります。本命2〜3社に保険で1〜2社を加える形が効率的です。

まとめ

• 依頼前に「課題・利用者と環境・予算と時期・開発方式」の4点を1枚にまとめると、見積もりと会社選びの精度が上がる
• 流れは、依頼書→相見積もり→比較→契約→要件定義→設計→開発・テスト→納品・運用の8ステップ。発注側の出番は依頼書・要件確認・テスト参加に集中する
• 費用の大半は人件費。人月単価と規模別の目安を押さえ、比較は開発費に保守費5年分を足した総コストで行う
• 依頼先は大手SIer・中堅開発会社・フリーランス・オフショアで向き不向きが違う。類似実績・上流工程の強さ・保守体制の3軸と、4軸スコアリングで客観的に比べる
• 契約前に5つの危険サインを確認し、契約書では保守条件・成果物の権利・解除条件・契約不適合責任の4項目を明確にする

システム開発の依頼は、開発会社に任せる部分と、発注側が決める部分の線引きができていれば怖くありません。要件が固まっていない段階でも、課題のメモを持って相談を始めるのが、結果として一番の近道です。

c3index に相談する

シースリーインデックスは、名古屋本社・東京支社・福岡の3拠点で、製造業・流通業をはじめとする中堅企業のシステム受託開発と、その後の保守・運用を一貫して担っています。受発注管理、生産管理、ワークフロー、顧客管理などの業務システムを、要件の整理から一緒に組み立ててきました。

「作るべきか買うべきか迷っている」「受け取った見積もりが妥当か見てほしい」「要件がまだ固まっていない」という段階からご相談いただけます。費用感と進め方を、無料でご説明します。