.NETのシステム開発の発注/外注/依頼/委託方法について

.NETのシステム開発の発注は、業務要件を整理し、方式と契約を選び、提案と見積もりを比べる流れで進みます。運用条件に合う開発につなげるための手順です。

各段階で何を決めるかを、方式、RFP、契約、費用、委託先の順に見ていきます。

▼全体ガイドの記事
・.NETのシステム開発の完全ガイド

.NETのシステムを発注する前に知っておきたい全体像

.NETはMicrosoftの開発・実行基盤で、業務アプリケーションの構築に用いられます。開発ではC#、ASP.NET Core、Entity Framework Coreを使い、SQL ServerやMicrosoft Azureも組み合わせます。そのうえで、Web画面やAPI、バッチ、外部連携を実現します。

「.NETで作る」と伝えるだけでは、画面数や業務範囲、品質、運用体制は決まりません。そのため発注者は、誰が何の業務でどの情報を使い、何を改善したいのかを先に整理します。

業務システムの基盤としての.NET

.NETには、C#、ASP.NET Core、実行環境、ライブラリ群が含まれます。ブラウザで使う販売管理やワークフローでは、ASP.NET Coreが候補になります。

  • Windows端末:現場アプリなら、WPFやWindows Formsが候補になります。
  • 他システム連携:Web APIやバッチを組み合わせて対応する形です。

改善目標をKPIとして示すと、必要な機能と優先順位を関係者で共有できます。たとえば、月末請求を半日から30分に短縮する、在庫差異を翌日までに把握する、承認状況を見える化するといった目標があります。

新規開発と既存.NET Frameworkの移行の切り分け

新規開発では、長期運用を前提に、現行の.NETとASP.NET Coreを候補にします。一方で、既存の.NET Frameworkなどは、単純なバージョンアップでは済まない場合があります。

  • 既存技術:ASP.NET Web Forms、WCF、Windows Formsの利用状況。
  • 移行候補:現状維持、API化、段階移行、パッケージ刷新を並べて比べます。

現行環境の調査結果が移行範囲を左右します。そのため、比較の前に、認証や帳票などの仕組み、COMやActiveXなどの依存関係を調べます。さらに、外部DLLやSQL互換性、画面の使い勝手も確かめます。

2026年8月時点では、.NET 10はLTSとして2028年11月14日まで、.NET 8と.NET 9は2026年11月10日までサポートされる予定です(出典:Microsoft「.NET Support Policy」、2026年)。

発注書には、メジャーバージョン、パッチ適用の担当、サポート終了前の更新計画を書いておきます。これにより、完成直後に再改修が必要になるリスクを下げられます。

発注形態の選び方:パッケージ・クラウド・スクラッチ

既存サービスが販売・会計を担い、.NET開発が特殊な見積計算と工場端末連携を担うハイブリッド構成図。
標準領域と独自領域を分けて組み合わせます。

標準業務はSaaSやパッケージに任せ、独自の計算や既存連携は.NETで開発する、というように分けられます。こう分けると、すべてをスクラッチ開発する場合に比べて、費用と保守負担を抑えやすくなります。

標準化できる業務のパッケージやSaaS

勤怠や経費、一般的なワークフローは、標準機能で満たせるかを確認します。定型的な顧客管理も、標準機能で足りるかを見ます。Dynamics 365やPower Platformも比較の対象になります。

既存のMicrosoft 365やEntra IDと連携できれば、その環境を活かせる場合があります。一方で、標準機能を大量にカスタマイズすると、更新のたびの検証や、ベンダーへの依存が増えます。

  • 利用条件:利用料とユーザー数、データ保管先、権限の範囲。
  • 連携と終了:API接続の方法と、解約時のデータ返却の扱い。

機能一覧だけでなく、上の項目を含めた5年程度の総保有コストで比べます。

独自業務と複雑な連携の.NETスクラッチ開発

独自業務や複雑な連携が競争力に関わる場合は、.NETのスクラッチ開発を検討します。

  • 独自業務:価格計算、製造・物流の現場フロー、複数拠点の在庫引当。
  • 技術と連携:会計・ERPとの接続、C#、ASP.NET Core、Entity Framework Coreの活用。

独自業務と技術・連携の両方を.NETで組むと、将来の拡張を見据えた設計を取れる点が強みです。

自由度が高い分、要件定義が曖昧なままだと費用と納期に直結します。そのため、初回から全機能を作り込まず、業務効果を測れるMVPを切り出します。利用状況を見ながら、二次開発へ進みます。

パッケージと.NETを組み合わせるハイブリッド構成

標準領域はパッケージに寄せ、独自計算と周辺連携を.NETで作ると、差別化と導入スピードを両立できます。

  • 既存サービス:販売と会計の領域。
  • .NETで開発:取引先向けポータル、特殊な見積計算、工場端末連携を構築します。

RFPには、データの正本とAPIの責任範囲を書きます。さらに、ユーザーと権限の同期方法、障害時の切り分けも書きます。境界が曖昧だと、問い合わせ先が不明確になります。

ポイント

業務ごとに、パッケージやSaaSで足りるか、独自の計算や既存連携に.NET開発が要るかを分けて考えます。判断に迷う業務は、5年程度の総保有コストで比べて決めます。

RFPと要件整理:業務の目的から作る方法

RFPに整理する背景・目的・対象範囲、業務シナリオとデータ項目、非機能要件と運用条件を3枚のパネルで示す図。
目的から運用までの要件を3領域に分けて整理できます。

RFPは、開発会社に同じ前提で提案と見積もりを依頼するための書類です。背景、対象業務、成果を共有し、さらに制約、納品物、選定基準も示します。完璧な仕様書でなくても、候補会社が不明点を質問できる状態にしておけば足ります。

背景・目的・対象範囲を1枚にまとめる方法

現場の手順を書き出し、時間がかかる箇所、ミスや二重入力が起きる箇所、承認待ちが生じる箇所を探します。対象部門、利用者数、拠点数を記載します。さらに、利用時間やピーク処理量も書いておきます。

「在庫管理を改善する」と書くより、「入出庫を登録し、拠点別在庫と引当可能数を同じ画面で確認する」のように書くと、機能の中身がはっきりします。

今回作る機能と対象外を分け、既存システムとの間でどこまでを誰が受け持つかも明記します。範囲外を示しておくと、こうした整理が、見積もり後の追加依頼を減らせます。

  • 業務範囲:販売と在庫、購買と請求、会計、顧客、承認。
  • 入出力と連携:帳票とCSV、メール、外部API。

機能要件の表し方:業務シナリオとデータ項目

利用者の入力、システムの計算や判定、帳票や通知を、業務シナリオとしてまとめます。たとえば「受注登録」であれば、取引先と商品・数量・単価、在庫引当と承認を書きます。さらに、採番や納期回答、会計連携も示します。

マスタや取引データ、履歴、添付をどう扱うか、削除や訂正をどうするかも決めます。ExcelやAccessから移す場合は、件数や重複、欠損を確認します。加えて、コード、保存年限、対象日も見ておきます。

品質が不明なまま全件の移行を依頼すると、クレンジングや検証の費用が後から追加されやすくなります。

RFPに含める非機能要件と運用条件

性能、可用性、セキュリティは、後から追加しにくい要件です。バックアップ、監視、復旧、拡張性も、後から足すのが難しい領域です。そのため、可能な範囲で数値にします。

  • 性能と稼働:同時利用者数、目標応答時間、運用時間。
  • 復旧と保持:計画停止の扱い、復旧目標、バックアップの保管期間。

認証にMicrosoft Entra IDや多要素認証を使うかどうかを決めます。加えて、権限は部門・役職・拠点ごとに分け、監査ログに誰のどの操作を残すかも定めます。

個人情報や機密情報を扱う場合は、暗号化と秘密情報の管理を要件に含めます。脆弱性スキャン、ログの閲覧権限、再委託の条件も、あわせて定めます。

ポイント

RFPは、業務の目的と対象範囲を先に示し、候補会社が同じ前提で見積もれる内容にします。画面の一覧から書き始めると、目的が見えないまま要件が増えてしまいます。

契約形態と発注からリリースまでの進め方

契約では、成果物と責任範囲、受入基準を定めます。加えて、変更手続きや障害対応、知的財産権の扱いも決めておきます。特に、要件が固まる前に全工程を請負にすると、仕様変更のときに対立しやすくなります。

請負・準委任・フェーズ分割の使い分け

要件の確定度や依頼内容に応じて、契約形態を選びます。

  • 請負:成果物を完成させ、検査と受入の後に納品する形。機能などが明確な開発が対象になります。
  • 準委任:一定期間の業務や専門人材を支援する形。調査、要件定義、技術検証で使われます。

請負では、大きな要件変更があると追加の見積もりや納期の変更が生じます。ただし、修正を無制限に頼めるわけではありません。

準委任では、稼働時間だけでなく、会議体や報告の方法を契約書に明記します。成果物や品質確認の方法も、あわせて書きます。

調査と要件定義は準委任、確定後の設計・開発・テストは請負、リリース後の改善と保守は準委任とする方法があります。法的影響があるため、契約書は法務担当者や専門家にも確認します。

要件定義から運用までの責任者配置

発注側は、業務責任者と情報システム担当、現場代表、意思決定者を早期に決めます。丸投げすると、現場の暗黙知や優先順位が伝わらず、未使用の機能が生じてしまいます。

RFPには、運営方法も書いておきます。たとえば、週次会議と課題管理、変更承認、月次の意思決定会議があります。

進行は工程ごとに区切り、各工程の終了条件と次工程の承認者を決めておきます。こうすると、問題を後工程へ持ち越しにくくなります。区切りごとに承認を挟みながら、開発は次の8つの工程を順に進みます。

  1. 現状調査と要件定義
  2. 基本設計とUIの確認
  3. 詳細設計と開発
  4. 単体・結合・総合テスト
  5. 移行リハーサル
  6. 受入テスト
  7. リリース
  8. 運用の引き継ぎ

契約書に書く受入基準と引き渡し物

受入テストでは、業務シナリオに沿って確認し、未解決のままでも受け入れられる不具合の範囲を定めます。基準には、重大障害がないこと、帳票が合意したサンプルと一致すること、権限外のデータを見られないことなどを含めます。

コード以外の引き渡し物と権利関係は、発注の前に確認しておきます。さらに、保守会社を変えられる条件もはっきりさせておきます。

  • 資料:設計書とAPI仕様、データ定義、テスト結果。
  • 運用物:移行と運用の手順、監視設定、インフラ構成、IaC。
  • 権利と引継ぎ:第三者ライセンス、コードの帰属、再利用部品。

ポイント

要件が固まった範囲は請負、先が読みにくい調査や要件定義は準委任と分けて考えます。どちらの形でも、成果物と変更手続きを契約書に書いてから進めます。

.NETのシステム開発費用相場とコストの内訳

小規模、中規模、大規模、全社基幹の4段階について、記事に記載された初期費用目安を並べた尺度図。
対象範囲が広がるほど、費用の想定レンジも上がります。

.NET専用の受託開発統計は限られています。そのため、ここで示す数字は、公開された業務システムの費用と、C#人材の単価から見た予算の目安です。

費用は、画面数や移行、外部連携の有無で変わります。さらに、非機能要件や納期、体制、クラウドやライセンスの条件でも変わります。この数字は確定額ではなく、RFPを作るときの仮説として使います。

規模別の初期費用の幅:300万円台から1,000万円以上

初期費用は、システムの規模と必要な機能や運用条件によって幅が出ます。

  • 小規模:1部門向けの管理、一覧と登録、簡易承認、外部連携1〜2本の場合は、300万〜500万円程度。
  • 中規模:複数部門の権限やワークフロー、帳票、API、移行を含むと、500万〜1,000万円程度になる場合があります。
  • 大規模:複数拠点の販売・在庫・購買、会計やERP連携、監査ログ、段階移行、高可用性を含むと、1,000万〜3,000万円程度。
  • 全社基幹:大量データや複数システムの同期、24時間運用、並行稼働を伴うと、3,000万円〜1億円超になる可能性があります。

上の目安は、.NET(C#)やASP.NETに対応するSIA株式会社の公開料金を参考にしたものです(出典:SIA株式会社「Webシステム開発・業務システム開発」、2026年確認)。

同社は、小規模を300万〜500万円、中規模を500万〜1,000万円、大規模を1,000万円以上としています。公開料金は個別の見積もりではないため、要件を添えて複数社に確認します。

見積もりの内訳:人件費・インフラ・移行・保守

見積書の総額を比べる前に、工程と費目ごとの内訳を確かめます。

  • 開発工程:要件定義、管理、UI・構成設計と実装、テスト、移行、リリース支援。
  • 品質関連:ヒアリング、レビュー、品質管理、セキュリティ検査、文書作成。
  • 基盤費用:クラウドやDB・監視、証明書とバックアップ、外部API、ライセンス、端末、移行用環境。

同じ総額でも作業範囲は異なります。そのため、上の各項目が見積もりに含まれているかを確かめます。

2025年2月、エン・ジャパンはC#.NETのフリーランス月額平均単価を68.9万円と公表しました(出典:エン・ジャパン「フリーランスエンジニア月額単価レポート」、2025年)。

これは人材市場の平均であり、受託開発の総額ではありません。受託開発には、PMや設計、テスト、間接費、請負のリスクもあります。そのため、人数と月数だけでは比べられません。

保守と運用は、初期開発費の年15〜25%程度を目安に予算化します。契約では、脆弱性修正、OS等の更新、.NET更新の範囲を明確にします。さらに、障害対応時間も定めます。

ポイント

予算は、まず要件の範囲から規模を決め、その規模で複数社の見積もりを取ると、判断の材料がそろいます。総額だけでなく、内訳と保守費用も比べます。

委託先の選定と見積比較で確認すべきポイント

C#が書ける会社と、自社のシステムを最後まで任せられる会社は、必ずしも同じではありません。そのため、要件定義から利用定着までの体制を確認します。

同じRFPで3社以上から提案を受けると、比べる観点をそろえやすくなります。

実績の確認:技術名ではなく自社に近い案件

経験年数だけでなく、自社に近い業務規模での実績を確認します。対象には、新規開発や旧.NET Frameworkからの移行、DB設計も含めます。

SQL ServerやPostgreSQLの設計経験も確認します。さらに、Azureのネットワーク・監視・バックアップ、Entra ID認証・権限、外部API連携の実績も質問します。

実際に担当するPMや業務担当、設計者を確かめます。開発やテスト、保守を担う人まで、名前と役割を確認します。また、再委託の有無と、その管理責任者も聞きます。

見積もりの比較:総額より前提条件と成果物

要件定義から設計、開発、テストまでを、同じ表に並べます。移行や教育、リリース支援、保守も、表に含めます。

工数や体制、期間を記録します。納品物と除外作業、発注側の作業もあわせて書きます。さらに、変更や追加連携の単価も残します。

見積もりが安い理由が、移行やテストを別料金にしていることである場合もあります。「一式」とある作業は、内容と完了条件を尋ねます。

  • 移行・検証:データ整理、リハーサル、受入と性能試験。
  • 安全性:脆弱性診断、Azureの初期設定、監視設計。
  • 運用引継ぎ:手順書とリリース後の問い合わせ対応。

発注条件に含めるセキュリティと保守体制

2026年のIPA「情報セキュリティ10大脅威」では、組織向けの2位が委託先などを狙う攻撃、3位がAI利用のリスク、4位が脆弱性攻撃とされています(出典:IPA「情報セキュリティ10大脅威 2026」、2026年)。

委託先を評価するときは、認定資格だけでなく、運用と契約条件もあわせて見ます。

  • 委託先の運用:開発端末やコード、秘密情報、ログの扱い、再委託、脆弱性報告。
  • 保守条件:報告期限と修正責任、緊急パッチと復旧テスト、障害受付と対応時間、SLA。
  • 再委託・生成AI:承認の取り方、漏えい時の連絡と費用負担。AI利用時の入力情報、レビュー、ライセンス、テストの責任。

Microsoft Solutions PartnerやAzure認定は、技術力を確かめる入口になります。ただし、認定数だけでなく、自社の課題に近い実績と納品後の担当者も確認します。

ポイント

委託先は、C#が書けるかより、自社に近い案件を最後まで任せられるかで選びます。比べるときは、総額の前に、前提条件と成果物がそろっているかを見ます。

よくある質問(FAQ)

.NETの発注時に担当者から寄せられる質問を、相場だけでなく、発注前に決めることや開発会社への確認事項とあわせて取り上げます。

.NETで開発するかパッケージを導入するか、どう判断しますか?

標準化できる共通業務はパッケージやSaaSを、独自の計算や競争力に直結する業務は.NET開発を優先します。

初期費用だけでなく、月額料やカスタマイズ、連携、移行を含む総保有コストで比べます。更新や解約時のデータ返却も含めて見ます。業務のやり方を変えられるかも、判断材料になります。

.NETのシステムは300万円で発注できますか?

1部門向けの小規模Webシステムで、機能や連携、移行、非機能要件を絞れば、公開情報の上では300万〜500万円程度が目安です。

複数部門の権限や帳票、複雑な計算を含む場合は、500万〜1,000万円以上になる可能性があります。加えて、既存データのクレンジングや厳格な性能・監査要件を含む場合も、費用が増える可能性があります。そのため、要件を分けて段階導入も比較します。

請負契約と準委任契約はどちらを選べばよいですか?

成果物と受入条件が固まった開発は請負、現状調査や要件定義、技術検証、継続改善は準委任が基本です。また、要件定義は準委任、開発は請負と分ける方法もあります。

成果物、責任範囲、変更管理を契約書に明記し、法務担当者や専門家にも相談します。

.NET Frameworkの既存システムはすぐに移行すべきですか?

まずは現状を確かめ、そのうえで移行の判断をします。依存ライブラリやOS、認証を確かめ、さらに帳票や外部DLL、WCF、DB、テスト資産も見ます。

業務を止められない場合は、既存環境を動かしたまま、API化や画面単位の段階移行を進めます。移行する範囲と、現状のまま残す範囲を分けます。

まとめ

会社は技術名で決めず、業務課題と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を創業。