.NETのシステムを発注・外注するなら、技術名から会社を探すのではなく、業務要件と運用条件を整理して発注方式・契約・費用・委託先を順番に決めることが重要です。
販売管理、在庫管理、申請承認、顧客管理などを.NETで構築したい一方で、「何をRFPに書けばよいか」「請負と準委任はどちらがよいか」「300万円で足りるのか」と悩む担当者は少なくありません。この記事では、.NETのシステムを発注・外注する具体的な進め方を、パッケージとの切り分け、要件整理、契約形態、費用相場、見積比較、リリース後の保守まで一つの流れで解説します。
▼全体ガイドの記事
・.NETのシステム開発の完全ガイド
.NETのシステムを発注する前に知っておきたい全体像

.NETのシステムとは、Microsoftが提供する開発・実行基盤を使って構築する業務アプリケーションの総称です。C#、ASP.NET Core、Entity Framework Core、SQL Server、Microsoft Azureなどを組み合わせ、Web画面、API、バッチ、外部サービス連携を実現します。したがって、発注時に「.NETで作ってください」とだけ伝えても、必要な画面数や業務範囲、品質、運用体制までは決まりません。
.NETは言語ではなく業務システムの基盤です
.NETという言葉は、C#というプログラミング言語、ASP.NET CoreというWebアプリケーションのフレームワーク、実行環境、ライブラリ群などを含む広い概念です。ブラウザで使う販売管理やワークフローならASP.NET Core、Windows端末で動く現場アプリならWPFやWindows Forms、他システムと連携するならWeb APIやバッチを組み合わせる構成が候補になります。
発注者が最初に決めるべきなのは、フレームワークの細かな設定ではなく、「誰が、どの業務で、どの情報を使い、何を改善するか」です。たとえば月末の請求処理を半日から30分に短縮する、在庫差異を翌日までに把握する、申請の承認状況を可視化する、といったKPIを置くと、必要な機能と優先順位を開発会社と共有しやすくなります。
新規開発と既存.NET Frameworkの移行は分けて考えます
新規開発では、長期運用を前提に現行の.NETとASP.NET Coreを候補にすることが一般的です。一方、既存の.NET Framework、ASP.NET Web Forms、WCF、Windows Formsを使っている場合は、単純なバージョンアップでは済まない可能性があります。認証方式、セッション、帳票、COMやActiveX、外部DLL、SQLの互換性、画面の使い勝手を調査してから、現状維持、周辺機能のAPI化、段階移行、パッケージへの刷新を比較します。
2026年8月時点でMicrosoftの公式サポートポリシーでは、.NET 10はLTSとして2028年11月14日まで、.NET 8と.NET 9は2026年11月10日までサポートされる予定です(出典:Microsoft「.NET Support Policy」、2026年)。発注書には使用するメジャーバージョン、パッチ適用の担当、サポート終了前のアップデート計画を含めておくと、完成直後に再改修が必要になるリスクを下げられます。
発注形態はパッケージ・クラウド・スクラッチを比較して選びます

.NETで開発することを前提にしていても、すべてをスクラッチ開発する必要はありません。業務の標準化が目的ならSaaSやパッケージ、独自の計算や既存システム連携が競争力になるなら.NET開発というように、領域ごとに方式を分けると費用と保守負担を抑えやすくなります。
標準化できる業務はパッケージやSaaSを優先します
勤怠、経費、一般的なワークフロー、定型的な顧客管理など、業界共通の業務は、既存パッケージやSaaSの標準機能で満たせるかを先に確認します。Dynamics 365やPower PlatformなどMicrosoft製品を含めて比較すれば、既存のMicrosoft 365やEntra IDとの連携を活かせる場合があります。
ただし、標準機能を大量にカスタマイズすると、アップデート時の検証やベンダー依存が増えます。機能一覧だけでなく、利用料、ユーザー数の増加、データ保管、権限、API連携、解約時のデータ返却までを5年程度の総保有コストで比較しておくことが大切です。
独自業務と複雑な連携は.NETのスクラッチ開発を検討します
自社独自の価格計算、製造・物流の現場フロー、複数拠点の在庫引当、会計やERPとの複雑な連携などは、スクラッチ開発の適性が高くなります。C#の型安全性、ASP.NET CoreのWeb API、Entity Framework Coreのデータアクセスを組み合わせ、将来の拡張を見据えた設計を取りやすい点が.NETの強みです。
一方で、自由度が高い分、要件定義の曖昧さが費用と納期に直結します。初回から全機能を作り込まず、業務効果を測れるMVPを切り出し、利用状況を確認しながら二次開発へ進む方式も発注時の有力な選択肢です。
パッケージと.NETを組み合わせるハイブリッドも有効です
標準化領域はパッケージに寄せ、独自計算と周辺連携だけを.NETで構築するハイブリッド方式なら、業務の差別化と導入スピードを両立しやすくなります。たとえば販売・会計は既存サービスを利用し、取引先向けポータル、特殊な見積計算、工場端末との連携をASP.NET Coreで作る構成です。
この方式では、データの正本をどのシステムに置くか、APIの責任範囲、障害時の切り分け、ユーザーと権限の同期方法をRFPに明記します。システム間の境界を曖昧にすると、導入後に「どちらの会社へ問い合わせるのか」が不明確になるためです。
RFPと要件整理は画面一覧より業務の目的から作ります

RFPは、開発会社に同じ前提で提案と見積もりを出してもらうための依頼書です。技術用語を並べる書類ではなく、背景、対象業務、達成したい成果、制約条件、納品物、選定基準を共有する書類として作成します。最初から完璧な仕様書を作る必要はありませんが、候補会社が不明点を質問できる状態には整えます。
背景・目的・対象範囲を1枚で説明できるようにします
まず、現場が現在どのような手順で仕事をしていて、どこに時間、ミス、二重入力、承認待ちが発生しているかを整理します。対象部門、利用者数、拠点数、利用時間、ピーク時の処理量も記載します。「在庫管理を改善する」だけでなく、「入出庫を登録し、拠点別在庫と引当可能数を同じ画面で確認する」と書くと、必要な機能が具体化します。
対象範囲は、今回作る機能と作らない機能を分けて記載します。販売、在庫、購買、請求、会計、顧客、承認、帳票、CSV、メール、外部APIのどこまでを含むのか、既存システムと新システムの責任分界はどこかを明確にします。範囲外を明示することが、見積もりの後出し追加を減らします。
機能要件は業務シナリオとデータ項目で表します
機能要件には、利用者が何を入力し、システムが何を計算・判定し、どの帳票や通知を出すのかを業務シナリオで書きます。たとえば「受注登録」なら、取引先の選択、商品・数量・単価の入力、在庫引当、承認条件、受注番号の採番、納期回答、会計連携までを一連の流れで示します。
マスタ、トランザクション、履歴、添付ファイル、削除・訂正の扱いも早めに決めます。現行ExcelやAccessから移行する場合は、データ件数、重複、欠損、コード体系、保存年限、移行対象日を確認します。データの品質が不明なまま「全件移行」と依頼すると、後からクレンジングや検証の費用が追加されやすくなります。
非機能要件と運用条件をRFPに含めます
性能、可用性、セキュリティ、バックアップ、監視、障害復旧、拡張性は、完成後に追加しにくい非機能要件です。ピーク時の同時利用者数、検索や登録の目標応答時間、稼働時間、計画停止の可否、復旧目標、バックアップ保持期間を可能な範囲で数値化します。
認証はMicrosoft Entra IDや多要素認証を使うのか、権限は部門・役職・拠点単位で分けるのか、監査ログに誰のどの操作を残すのかも定義します。個人情報や機密情報を扱うなら、暗号化、秘密情報の保管、脆弱性スキャン、ログの閲覧権限、委託先からの再委託条件まで要件に含めます。
契約形態と発注からリリースまでの進め方を決めます

.NETのシステム発注では、契約書の名称だけでなく、成果物、責任範囲、受入基準、変更手続き、障害対応、知的財産権を具体的に定めます。要件が固まっていないのに全工程を一つの請負契約にすると、仕様変更のたびに対立しやすいため、フェーズごとに契約を分ける方法も検討します。
請負・準委任・フェーズ分割を使い分けます
請負契約は、合意した成果物を完成させ、検査・受入を経て納品する形に向いています。機能、画面、性能、移行対象、納期、受入条件が明確な開発に適していますが、発注後に要件を大きく変えると、追加見積もりや納期変更が発生します。請負だから無制限に修正してもらえるわけではない点に注意します。
準委任契約は、一定期間の業務遂行や専門人材の支援を依頼する形です。現状調査、要件定義、技術検証、既存.NET Frameworkの移行調査など、作業内容を進めながら成果の形を固める段階に向いています。稼働時間だけを管理するのではなく、会議体、成果物、報告内容、品質確認の方法を契約書に明記します。
実務では、現状調査と要件定義を準委任、確定した設計・開発・テストを請負、リリース後の改善と保守を準委任とするフェーズ分割が使いやすい場合があります。契約形態の選択は法的な影響があるため、契約書の最終確認は自社の法務担当者や専門家にも相談します。
要件定義から運用までの責任者を置きます
発注側は、業務責任者、情報システム担当、現場代表、意思決定者を早い段階で決めます。開発会社に丸投げすると、現場の暗黙知や経営上の優先順位が伝わらず、完成してから使われない機能が見つかるためです。週次の進捗会議、課題管理、変更承認、月次の意思決定会議など、プロジェクトの運営方法もRFPに書きます。
進行は、現状調査と要件定義、基本設計とUI確認、詳細設計と開発、単体・結合・総合テスト、移行リハーサル、受入テスト、リリース、運用引継ぎの順に区切ります。各工程の終了条件と、次工程へ進むための承認者を決めておくと、問題を後工程へ持ち越しにくくなります。
受入基準と引き渡し物を契約書に落とし込みます
受入テストでは、発注者がどの業務シナリオを確認し、どの不具合を未解決のまま受け入れられるかを定めます。たとえば重大度の高い障害が残っていないこと、主要な帳票の計算結果が合意したサンプルと一致すること、権限外のデータを閲覧できないことなど、確認可能な基準にします。
ソースコードだけでなく、設計書、API仕様書、データ定義、テスト結果、移行手順、運用手順、監視設定、インフラ構成、IaC、第三者ライセンス一覧も引き渡し物に含めます。ソースコードの権利、再利用部品の扱い、契約終了時の引継ぎ、保守会社を変更できる条件も発注前に確認します。
.NETのシステム開発費用相場とコストの内訳

.NET専用の受託開発統計は限られるため、以下の金額は公開されている業務システム開発費用とC#人材単価を組み合わせた予算取りの目安です。画面数、データ移行、外部連携、非機能要件、納期、発注先の体制、クラウドやライセンスの有無で変動するため、確定金額として扱わず、RFP作成時の仮説として利用します。
規模別の初期費用は300万円台から1,000万円以上まで広がります
小規模な.NET Webシステムで、1部門向けのマスタ管理、一覧・登録、簡易承認、外部連携1〜2本に収まる場合は、300万〜500万円程度が一つの目安です。複数部門、権限、ワークフロー、帳票、API、データ移行を含む中規模業務システムなら、500万〜1,000万円程度を見込むケースがあります。
複数拠点の販売・在庫・購買、会計やERPとの連携、監査ログ、段階移行、高い可用性まで必要な場合は、1,000万〜3,000万円程度のレンジを検討します。全社基幹の刷新、大量データ、複数システム同期、24時間運用、並行稼働を組み合わせると、3,000万円から1億円超まで広がる可能性があります。
これらの区分は、.NET(C#)やASP.NETにも対応するSIA株式会社の公開料金目安で、小規模Webシステムを300万〜500万円、中規模業務システムを500万〜1,000万円、大規模システムを1,000万円以上とする情報を参考にしています(出典:SIA株式会社「Webシステム開発・業務システム開発」、2026年確認)。公開料金は個別案件の見積もりではないため、自社の要件を添えて複数社へ確認します。
見積もりは人件費・インフラ・移行・保守に分解します
見積書では、要件定義、プロジェクト管理、UI設計、アーキテクチャ設計、実装、テスト、移行、リリース支援を分けて確認します。開発者の稼働だけでなく、業務ヒアリング、レビュー、品質管理、セキュリティ検査、ドキュメント作成が含まれているかで、同じ総額でも内容が変わります。
2025年2月のエン・ジャパンのフリーランスエンジニア月額単価レポートでは、C#.NETの月額平均単価が68.9万円と公表されています(出典:エン・ジャパン「フリーランスエンジニア月額単価レポート」、2025年)。この数値は人材市場の平均であり、受託開発の総額ではありません。PM、設計、テスト、会社の間接費、請負リスクを加えると、単純に人数と月数を掛けただけでは比較できません。
クラウド費用、データベースや監視の利用料、証明書、バックアップ、外部API、ライセンス、端末、移行用の一時環境も別枠で確認します。保守・運用は、調査ノートにある一般的な目安として初期開発費の年15〜25%程度を予算化し、脆弱性修正、OSやミドルウェア更新、.NETのメジャーアップデート、障害時の対応時間が含まれるかを契約書で明確にします。
委託先の選定と見積比較で確認すべきポイント

「C#が書ける会社」と「自社の業務システムを最後まで任せられる会社」は同じではありません。要件定義、データ移行、Azure設計、認証・監査、受入支援、障害対応、利用定着までを確認し、同じRFPで3社以上から提案を受けると比較の軸を揃えやすくなります。
実績は技術名ではなく自社に近い案件で確認します
確認したいのは、C#の経験年数だけではありません。ASP.NET Coreの新規開発、古い.NET Frameworkから現行.NETへの移行、SQL ServerやPostgreSQLの設計、Azureのネットワーク・監視・バックアップ、Entra IDの認証・権限、外部API連携の実績を、自社と近い業務規模で示してもらいます。
提案時には、実際に担当するプロジェクトマネージャー、業務担当、アーキテクト、開発者、テスト担当、保守担当が誰かを確認します。営業担当が説明した実績をそのまま評価せず、同じ担当者が参加するか、再委託先があるか、再委託先の管理責任を誰が持つかを質問します。
見積もりは総額より前提条件と成果物を横並びにします
比較表を作るときは、要件定義、設計、開発、テスト、移行、教育、リリース支援、保守を同じ行に並べます。各社の工数、体制、期間、納品物、含まれない作業、想定する発注側の作業、仕様変更の単価、追加連携の単価も記録します。安い見積もりが、単に移行やテストを別料金にしているだけの場合もあるためです。
特に、データクレンジング、移行リハーサル、受入テストの支援、性能試験、脆弱性診断、Azureの初期設定、監視設計、運用マニュアル、リリース後の問い合わせ対応は抜けやすい項目です。見積もりに「一式」とだけ書かれている項目は、作業内容と完了条件を質問して明細化します。
セキュリティと保守体制を発注条件に含めます
2026年のIPA「情報セキュリティ10大脅威」では、組織向けの2位にサプライチェーンや委託先を狙った攻撃、3位にAIの利用をめぐるサイバーリスク、4位にシステムの脆弱性を悪用した攻撃が挙げられています(出典:IPA「情報セキュリティ10大脅威 2026」、2026年)。委託先のセキュリティは、認定資格の有無だけでなく、開発端末、ソースコード、秘密情報、ログ、再委託、脆弱性報告の運用で評価します。
契約では、脆弱性が見つかったときの報告期限、修正の責任、緊急パッチの適用、バックアップと復旧テスト、障害の一次受付、対応時間、サービスレベル、再委託の承認、情報漏えい時の連絡と費用負担を確認します。生成AIを開発に使う場合は、入力してよい情報、生成コードのレビュー、ライセンス確認、テスト責任を定めます。
Microsoft Solutions PartnerやAzureの認定は、技術力を確認する入口として役立ちますが、認定数だけで発注先を決めません。大規模基幹、Microsoft製品横断、クラウド運用、レガシー移行、製造・物流など、自社の課題に近い実績と、納品後に誰が伴走するかを確認することが大切です。
よくある質問(FAQ)

.NETのシステムを発注するときに、担当者から特に寄せられる質問をまとめます。相場だけでなく、発注前に何を決め、どこを開発会社へ確認するかを判断材料にします。
.NETで開発するかパッケージを導入するか、どう判断しますか?
業界共通で標準化できる業務はパッケージやSaaS、独自計算や競争力に直結する業務は.NET開発を優先します。初期費用だけでなく、月額利用料、カスタマイズ、連携、移行、アップデート、解約時のデータ返却までを含む総保有コストと、現場が業務を変えられるかで判断します。
.NETのシステムは300万円で発注できますか?
1部門向けの小規模Webシステムで、機能、連携、データ移行、非機能要件を絞れば、300万〜500万円程度が公開情報上の一つの目安になります。ただし、複数部門の権限、帳票、複雑な計算、既存データのクレンジング、厳格な性能・監査要件まで含める場合は、500万〜1,000万円以上になる可能性があるため、要件を分けて段階導入も比較します。
請負契約と準委任契約はどちらを選べばよいですか?
成果物と受入条件が固まっている開発は請負、現状調査や要件定義、技術検証、継続的な改善は準委任が基本的な考え方です。要件定義を準委任、確定後の開発を請負にするなど、フェーズ分割もできます。自社の法務担当者や専門家に相談し、成果物、責任範囲、変更管理を契約書に落とし込みます。
.NET Frameworkの既存システムはすぐに移行すべきですか?
すぐに全面移行するのではなく、依存ライブラリ、OS、認証、帳票、外部DLL、WCF、データベース、テスト資産を棚卸しして判断します。業務を止められない場合は、既存システムを運用しながらAPI化や画面単位の段階移行を進め、移行対象と現状維持の範囲を分ける方法が現実的です。
まとめ

.NETのシステムを発注・外注するときは、最初に技術名で会社を決めるのではなく、業務課題とKPI、対象範囲、パッケージと個別開発の境界を整理します。そのうえで、RFPに機能要件、データ移行、性能、認証、監査、運用、納品物を記載し、同じ条件で複数社から提案を受けます。
費用は開発費だけでなく総保有コストで判断します
予算は、小規模Webシステムなら300万〜500万円程度、中規模業務システムなら500万〜1,000万円程度、大規模システムなら1,000万円以上という公開目安から出発できます。ただし、これは要件定義前のレンジです。人件費、クラウド、ライセンス、データ移行、教育、保守、アップデートを含めた数年分の費用を確認してから投資判断をします。
発注前に現状資料と質問事項を準備します
次に行うことは、現行業務の流れ、画面や帳票の一覧、データ項目、外部連携、利用者と権限、非機能要件、希望時期、予算の上限を一つの資料にまとめることです。既存.NET Frameworkからの移行なら、依存関係と業務を止められない期間も整理します。発注先には、同じRFPで見積内訳、担当体制、契約条件、保守SLA、リリース後の改善方法を質問します。
▼全体ガイドの記事
・.NETのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
