.NET/C#基幹系システムの外注方法｜Windows環境の判断基準と選び方

Windows Server と .NET Framework で構築した基幹系システムを、そろそろ刷新したい。しかし、いざ外注しようとすると「どの技術構成にすべきか」「どの外注先に頼むべきか」「どんな契約形態が適切か」の判断軸が持てず、経営会議で方針が決められないまま時間だけが過ぎている——。中堅企業の情シス部門で、こうした膠着状態に陥っているケースは少なくありません。

とくに、15 年以上運用してきた VB.NET/C# 製の販売管理・在庫管理・生産管理といった基幹系は、業務ロジックが積み重なり、SQL Server のストアドプロシージャや帳票、Excel/Access 連携などの周辺資産が絡み合っています。「一部でも止まれば業務が止まる」という重みが、意思決定を鈍らせるのは自然なことです。

過去に大手 SIer へ見積を依頼したところ、数億円規模の見積が返ってきて着手できていないという声もよく耳にします。かといって、中堅の受託開発会社やフリーランスチームに任せて本当に大丈夫なのか、判断材料がないまま検討が止まっている企業も多いのが実情です。

本記事では、.NET/C# で構築された基幹系システムの外注を検討している発注者の方に向けて、外注前に整理すべき前提、Windows 環境を維持するか刷新するかの判断基準、外注先 3 タイプの使い分け、費用感の目安、発注時のチェックポイントまでを体系的に解説します。会社紹介ではなく、あなたが社内で意思決定を進めるための判断フローに焦点を当てます。

読み終えたときには、「明日から何を整理し、どこに相談し、どこから見積を取るか」を自分の言葉で組み立てられる状態を目指します。

.NET/C#基幹系システムの外注が今、増えている背景

まず、なぜ今 .NET/C# 基幹系の刷新・外注が経営イシューになっているのか、その背景から整理します。読者の方が「動けない」と感じている状況は、決してあなたの会社だけの問題ではありません。

Windows Server と .NET Framework の EOL・サポート期限が刷新を後押ししている

Windows Server 2012/2012 R2 は 2023 年に延長サポートが終了し、Windows Server 2016 も 2027 年 1 月に延長サポート終了を迎えます（Windows Server サポートライフサイクル）。オンプレの Windows Server 上で稼働している基幹系にとって、OS の EOL は事実上の「刷新期限」として経営に突きつけられます。

.NET Framework も動きが激しい領域です。マイクロソフトは 2019 年に「.NET Framework 4.8 が最終メジャーリリース」となる方針を公表し、以降の新機能開発は .NET（旧 .NET Core）に集約されました（.NET Framework 4.8 の発表と今後）。.NET Framework 自体は Windows に同梱される限りセキュリティ更新は継続されますが、新機能・パフォーマンス改善・クロスプラットフォーム対応の恩恵を受けたい場合は .NET への移行が必須になります。

こうした期限が重なった結果、「まだ動いているから」と先送りしてきた基幹系刷新が、いよいよ経営会議のテーブルに乗るタイミングを迎えているのです。

基幹系を刷新できない「4 つのブラックボックス」

刷新の意思決定が難しい根本原因は、多くの企業で次の 4 つがブラックボックス化していることにあります。

• コードのブラックボックス: 当時の開発担当者が退職し、業務ロジックが誰にも読めない
• データのブラックボックス: SQL Server 上に長年蓄積されたストアドプロシージャや複雑なビューが、業務仕様の唯一の記述になっている
• 帳票のブラックボックス: Crystal Reports や ActiveReports で作られた数百枚の帳票が、現業務に組み込まれている
• 運用ノウハウのブラックボックス: 「毎月末のバッチはこの順番で回す」といった暗黙知が、外部から見えない

このブラックボックスに手を入れることへの恐怖が、外注の意思決定を止めています。しかし裏を返せば、この 4 領域を可視化することが外注準備の第一歩になります。ブラックボックス化した既存資産の解きほぐし方については、レガシーシステム改善の進め方も参考にしてください。

内製が限界に達し、外注前提での意思決定が主流になっている

情報処理推進機構（IPA）の「DX 白書」でも指摘されているとおり、日本企業の IT 人材は事業会社側に偏在せず、依然として SIer 側に集中しています（IPA DX白書2023）。中堅企業の情シスで .NET/C# の設計・実装まで内製で回せるチームを持てているケースは限られており、基幹系刷新のような大規模プロジェクトは外注前提で組むのが現実的な選択肢になっています。

問題は「外注する／しない」ではなく、「どこに、どう発注するか」に移っています。刷新プロジェクト全体の進め方を俯瞰したい場合は、レガシーシステム刷新のガイドを先に押さえておくと、以降の判断がスムーズになります。

外注前に発注者側で整理すべき 5 つの前提

外注先の情報収集を始める前に、社内で確定させておきたい 5 項目があります。これを整理しないまま複数の外注先に相談を始めると、各社の提案がバラバラの前提で返ってきて比較不能になります。

目的・KPI の定義

「基幹系を刷新する」だけでは目的として弱く、外注先も提案を絞りきれません。次の 4 つのうち、どれを最優先にするかを言語化してください。

• コスト削減: 保守費・ライセンス費・インフラ費を年間いくら下げたいか
• 業務効率: 特定業務の処理時間を何割短縮したいか、どの部署の作業を減らしたいか
• 拡張性: 新規事業や海外拠点展開に対応できるアーキテクチャに変えたいか
• 法対応・監査対応: インボイス制度・電子帳簿保存法・IT 監査対応の要件を満たしたいか

すべてを同時に達成するのは非現実的です。優先順位を 1 位から順に並べておくと、外注先が提案の方向性を絞りやすくなります。

現行資産の棚卸し

現行システムの中身を、次の 6 項目で棚卸しします。この情報がないと、外注先は「フルスクラッチで作り直す」提案しか出せません。

• コード: プロジェクト構成、行数、主要な業務ロジックの所在
• データ: テーブル数、レコード数、ストアドプロシージャ数、ビュー数
• 帳票: 帳票数、使用エンジン（Crystal Reports / ActiveReports 等）、月次で使う帳票の比率
• 連携システム: 会計・給与・EDI・EC など、外部システムとの連携本数と方式
• 利用者: 利用部署、同時接続数、ピーク時のアクセス集中
• 利用頻度: 毎日使う機能、月次で使う機能、ほぼ使われていない機能

「ほぼ使われていない機能」を洗い出せると、刷新スコープを大幅に絞れます。全機能を再現する必要はないケースが大半です。

スコープの切り分け

刷新の範囲を、次の 4 パターンから選びます。

• 全刷新: 現行を全廃し、新基盤で作り直す
• 段階移行: 業務単位で切り出し、順次新基盤に移す
• 機能追加: 現行を残したまま、新機能のみ別基盤で追加する
• 保守継続: 大きな刷新はせず、当面は保守と部分改修で乗り切る

「全刷新」を選ぶと数億円規模になりやすいのは自然なことです。中堅企業の多くは「段階移行」または「機能追加」から着手するほうが現実的です。

発注者側の体制と役割

外注はしても、発注者側で必ず 3 つの役割を置きます。

• プロジェクトオーナー: 経営層。予算と期間の最終責任を持つ
• 業務側代表: 現場業務を熟知したメンバー。要件の是非を判断する
• 情シス: 技術面の窓口。外注先とのコミュニケーションを担う

この 3 者が揃っていない状態で外注を始めると、要件の判断が止まって外注先が動けなくなります。とくに業務側代表が不在のプロジェクトは、ほぼ確実に炎上します。

予算・期間の目安レンジと調達方法

予算は、「使える金額の上限」と「本音の希望額」の 2 つを持っておきます。外注先には上限を伝え、希望額とのギャップを提案で埋めてもらう形が理想です。

期間についても、「業務都合の絶対期限」（OS の EOL、法対応の期限など）と「理想的な期間」を分けておきましょう。絶対期限が近い場合、スコープを絞る判断が必要になります。

Windows環境を維持するか、Web/クラウドへ移行するかの判断基準

ここが本記事の核です。.NET/C# 基幹系の刷新では、次の 3 つの選択肢が現実的に検討対象になります。

選択肢A: .NET Framework 継続（延命）保守の適用条件

「あと 3〜5 年しか使わないと決まっている」「業務プロセスの大幅変更は避けたい」「予算が数百万〜数千万円レンジ」に該当する場合、.NET Framework を継続して延命保守する選択肢は現実解です。

具体的には、次のような対応を組み合わせます。

• Windows Server のバージョンアップのみ実施し、アプリはそのまま
• 一部の脆弱性対応・帳票追加・法改正対応のみをスポットで発注
• 保守は月額固定の準委任契約で少人数チームに依頼

この選択肢は「時間を買う」判断です。将来の刷新を否定するのではなく、経営環境や業務プロセスの変化を待ってから本格刷新する戦略として有効です。

選択肢B: .NET（旧 .NET Core）への移行の判断基準

「今の業務プロセスは大きく変えたくないが、あと 10 年は使いたい」「クロスプラットフォーム化・コンテナ化の余地を残したい」場合、.NET Framework から .NET への移行が中心的な選択肢になります。

.NET への移行では、次の判断ポイントがあります。

• Windows Forms / WPF を残すか: マイクロソフトは .NET でも Windows Forms・WPF をサポートしているため、UI を Windows デスクトップに残したまま移行できます（Windows デスクトップ アプリの移行）
• Windows 依存 API の切り離し: System.Web や WCF など、.NET では別実装が必要な領域を洗い出す
• OS を Windows のままにするか、Linux にするか: .NET 化するとサーバー OS を Linux にしてコストを下げる選択肢が生まれる

「業務ロジックは資産として残し、基盤は現代化する」ケースに最も向く選択肢です。全刷新より工数が読みやすく、段階移行との相性も良好です。

選択肢C: Web・SaaS 化へのフル刷新

「業務プロセス自体を見直したい」「クラウド前提の運用に変えたい」「10 年以上の長期利用を前提にする」場合、Web ベースへのフル刷新が視野に入ります。

この選択肢では、次の要素が絡んできます。

• 業務プロセス再設計（BPR）が並行して必要
• ユーザー教育・マニュアル整備・並行運用期間の設計が必須
• 帳票の再設計、Excel/Access 連携の代替手段設計が必要

見えないコストが最も大きい選択肢である一方、10 年後の運用効率とスケーラビリティを最大化できるのもこの選択肢です。

Windows 資産（帳票・AD・Excel/Access 連携）を捨てるコスト

Windows 環境固有の資産を「捨てるコスト」は、事前に必ず見積もっておきます。

• 帳票エンジン: Crystal Reports・ActiveReports 資産を Web ベースの帳票エンジンへ置き換える工数は、帳票 1 枚あたり数万〜数十万円のオーダーになりやすい
• Active Directory 連携: シングルサインオンやアクセス権管理を AD で行っている場合、クラウド化時は Microsoft Entra ID（旧 Azure AD）や別の ID 基盤への統合設計が必要
• Excel/Access 連携: 業務担当者が Excel マクロや Access のクエリを日常的に使っている場合、代替手段（Power BI、Power Apps、業務システム側の CSV エクスポート等）を設計する必要がある

これらのコストを可視化せずに「クラウド化しましょう」と提案してくる外注先は、要注意です。

判断基準を表で整理

3 つの選択肢を判断軸で整理すると、次のようになります。

自社が「どの列に近いか」を判定するだけで、外注先への相談内容が大きく絞れます。

.NET/C#基幹系開発を依頼できる外注先の3タイプ

外注先は、大きく 3 タイプに分類できます。それぞれ強み・弱み・費用感が異なるため、フェーズによって使い分けるのが実務的です。

大手 SIer（数億円規模・全刷新・要件確定型）

大手 SIer は、要件が確定した全刷新プロジェクトに強みがあります。

• 向く場面: 全刷新型、要件がある程度固まっている、10 年以上の長期保守を前提にできる、経営層への説明責任として「大手に発注した」が価値を持つ
• 強み: 大規模プロジェクトのマネジメント経験、業種別のパッケージ資産、監査対応、多拠点展開
• 弱み: 見積が高額になりやすい、意思決定のスピードが遅い、要件変更に弱い
• 費用感: 数千万〜数億円

中堅受託開発会社（数千万円規模・準委任と請負のハイブリッド）

中堅の受託開発会社は、部分移行や機能追加に強みがあります。

• 向く場面: 段階移行、業務単位での刷新、要件がまだ流動的、期間 6 ヶ月〜1 年半程度
• 強み: コストと品質のバランス、要件変更への柔軟性、業種特化の実績を持つ会社が多い
• 弱み: 全刷新のマネジメント経験は会社によってばらつく、保守フェーズの体制継続に不安が残るケースもある
• 費用感: 数百万〜数千万円

準委任型のフリーランス・小規模チーム

スキルの高いフリーランスや、複数フリーランスで構成された小規模チームによる準委任契約も、基幹系案件で成立するケースが増えています。

• 向く場面: アジャイル的な段階移行、機能追加、既存システムの改善保守、内製人材と混成でチームを組みたい
• 強み: コミュニケーションが密、要件変更に強い、単価は中堅受託より抑えられるケースが多い、長期的なパートナーシップを組める
• 弱み: 全刷新型の大規模マネジメントには不向き、体制継続のためには発注者側での関係構築が必要
• 費用感: 月額数十万〜数百万円/人・複数人体制で月数百万〜1 千万円台

「フリーランスに基幹系は無理」と決めつける必要はありません。段階移行や部分改修のフェーズでは、むしろ相性が良いケースが多々あります。判断のポイントは「案件のフェーズ」と「発注者側のマネジメント能力」です。フリーランスや準委任型チームを起用したアジャイル型の外注体制のリスク管理については、アジャイル開発の外注リスク管理で具体的な体制構築例を解説しています。

3 タイプの比較表

「1 社に全部任せる」発想を捨て、フェーズごとに使い分けることが、基幹系刷新のコスト最適化につながります。

発注時のチェックポイント（実績・要件定義力・保守体制・契約形態）

複数の外注先に相談する段階では、次の 7 項目を必ず確認してください。基幹系に限らない汎用的な選定観点については、システム開発会社の選び方にもチェックリストをまとめています。

.NET/C# の基幹系実績（業種・規模・移行案件の有無）

「.NET が書けます」ではなく、「.NET/C# で基幹系の刷新をやった実績」を確認します。

• 自社と同業種の案件経験があるか
• 自社と同規模（利用者数・データ量）の案件経験があるか
• 「.NET Framework から .NET への移行」を実際にやった実績があるか
• 具体的な業種・規模・期間・体制を、守秘義務の範囲で語れるか

抽象的な事例紹介しかできない外注先は避けます。

要件定義・業務理解のフィット感

技術力よりも、業務を理解する力が結果を左右します。

• ヒアリング時に業務用語を正しく理解しているか
• 現場担当者へのヒアリングを重視する体制があるか
• 「なぜこの処理が必要か」を追求する姿勢があるか

「要件は発注者側で確定させてください」というスタンスの外注先は、基幹系刷新には向きません。

保守・運用フェーズの体制継続性

基幹系はリリース後の 10〜20 年が本番です。

• リリース後の保守体制はどう組まれるか
• 開発担当者が保守にも入るか、別チームに引き継ぐか
• 引き継ぎ時のドキュメント整備方針はどうか

「作って終わり」の会社は、基幹系では選ばないほうが安全です。

セキュリティ・監査対応

• オンプレ AD 連携時の権限設計経験はあるか
• クラウド化時の ID 基盤（Microsoft Entra ID、Okta 等）への統合経験はあるか
• 監査対応（J-SOX、ISMS、Pマーク）を経験しているか

金融・医療・上場企業周辺は、監査対応の実績が必須です。

契約形態と業務停止リスクの分担

• 請負・準委任のどちらが提案されているか、その理由は明確か
• 業務停止が発生した場合の責任分担は契約に明記されているか
• 稼働後のバグ修正の範囲・期間・費用はどう規定されているか

契約書に「業務停止時の対応」が書かれていない場合、必ず書き加えるよう交渉します。

段階移行・並行運用のプロジェクト計画立案能力

• 段階移行のプロジェクト計画を描けるか
• 現行と新基盤の並行運用期間の設計を提示できるか
• データ移行のリハーサル回数・タイミングを組み込めるか

ビッグバン刷新しか提案できない外注先は、基幹系では致命的です。

見積の内訳・追加費用の発生条件

• 見積書の粒度は十分か（人月単価 × 工数の内訳が見えるか）
• 「別途対応」「別途見積」と書かれている項目は具体的に何か
• 要件変更時の追加費用のルールは明記されているか

見積の粒度が粗い外注先ほど、後から追加費用が発生しやすい傾向があります。契約後に追加費用が膨らむのを防ぐ観点は、追加費用を回避する発注の型にまとめています。

費用感の目安と見積り比較の観点

外注費用の目安は、フェーズと外注先タイプで大きく変わります。ここでは、あくまで「一般的なレンジ」として整理します。人月単価や工数見積の妥当性を評価する視点は、人月見積りの根拠と見方に体系的にまとめています。

延命保守フェーズ

• 中堅受託: 月額 30 万〜100 万円
• 準委任型チーム: 月額 40 万〜80 万円（0.5〜1 人月体制）

スポット対応中心なら、年間で数百万円レンジに収まるケースが多くあります。

部分移行・機能追加フェーズ

• 中堅受託: 500 万〜3,000 万円（6 ヶ月〜1 年）
• 準委任型チーム: 月額 200 万〜500 万円（3〜5 人月体制、6 ヶ月〜1 年）

業務単位で切り出せる範囲を明確にすると、外注先が見積を出しやすくなります。

フル刷新フェーズ

• 中堅受託: 3,000 万〜1 億円（1〜2 年）
• 大手 SIer: 1 億〜数億円（2〜4 年）

大手 SIer との数億円の差は、規模だけでなく、プロジェクト管理体制の重さ・監査対応・長期保守コミットメントの差でもあります。「高い＝ぼったくり」ではなく、「その体制を必要とするか」で判断してください。

見積の差を生む 4 つの変動要因

同じ規模の案件でも、見積が 2 倍以上変わるケースは珍しくありません。差を生むのは主に次の 4 つです。

• 規模: 画面数・帳票数・テーブル数
• 帳票資産: 帳票の量と、代替手段の選択（既存資産を活かすか、Web 帳票に置き換えるか）
• 連携数: 会計・給与・EDI・EC など、外部システムとの連携本数
• 業務変更幅: 現行踏襲か、業務プロセス再設計を含むか

見積を比較するときは、この 4 要因が同じ前提で見積られているかを必ず確認します。

相見積り時の比較観点

複数社の見積を比較するときは、「合計金額」だけを見てはいけません。次の 3 つの掛け算で分解します。

• 人月単価: 各社の技術者単価はいくらか（大手 SIer で 150 万〜200 万円/人月、中堅受託で 80 万〜130 万円/人月、準委任型チームで 70 万〜120 万円/人月が目安）
• 工数: 各社が想定している総工数は何人月か
• リスク負担: 請負か準委任か、業務停止時の責任分担、追加費用の発生条件

同じ人月単価でも、工数の見積もり方が違うと合計金額は倍増します。工数見積の根拠を各社に説明させてください。

外注後の内製移管・保守体制の設計

基幹系は「作って終わり」ではなく、リリース後の 10〜20 年の保守が本番です。外注に頼りきりにならず、要所を内製で押さえる「共同運用モデル」の考え方を最後に整理します。

ドキュメント継承と設計書の作り方

• 業務要件書・機能仕様書・データベース設計書を、外注先の成果物として必ず受け取る
• コードコメントとは別に、業務ロジックの意図を記した「業務ロジック解説書」を作らせる
• 帳票仕様書・バッチ処理仕様書を独立ドキュメントで維持する

これらのドキュメントは、次の外注先に引き継ぐときや、内製化するときに命綱になります。

内製人材の育成と外注チームとの並行運用

• リリース直後から、社内エンジニアを 1 名は外注チームに常駐（またはリモート常駐）させる
• コードレビュー・障害対応の場に必ず社内メンバーが同席する
• 保守フェーズで徐々に内製比率を高める計画を、契約前から外注先と合意しておく

「外注 100％」の期間は 2〜3 年に留め、その後は徐々に内製比率を上げていくのが健全です。

保守契約の粒度

保守契約は、次の 3 つの組み合わせで設計します。

• 月額固定契約: 定常的な保守作業（監視・バッチ確認・軽微な問い合わせ対応）を担う
• スポット契約: 機能追加・大規模改修を都度発注する
• SLA 型契約: 障害発生時の対応時間・復旧時間を SLA で規定する

すべてを月額固定に押し込むと外注先が疲弊し、すべてをスポットにすると継続性が失われます。組み合わせのバランスが、長期保守の質を決めます。基幹系の保守費用相場と、その根拠となる原価構造については、システム保守費用の相場と根拠で詳しく整理しています。

まとめ・次の一歩

.NET/C# 基幹系の外注は、判断軸を持たないまま始めると必ず迷走します。本記事で整理した判断フローを、最後にまとめておきます。

• Windows Server と .NET Framework の EOL・サポート期限が経営イシューになっている
• 外注前に、目的・KPI、現行資産の棚卸し、スコープ、体制、予算の 5 項目を社内で確定させる
• 技術構成は、.NET Framework 延命保守／.NET 移行／Web・クラウド刷新の 3 択で判断する
• 外注先は、大手 SIer／中堅受託／準委任型チームをフェーズで使い分ける
• 発注時は、実績・要件定義力・保守体制・契約形態・段階移行能力・見積粒度の 7 項目を確認する
• 費用は「合計金額」ではなく「人月単価 × 工数 × リスク負担」で比較する
• 保守フェーズは「共同運用モデル」で内製比率を徐々に高める

明日から取れる 3 つのアクションを提案します。

1. 現行資産の棚卸し: コード・データ・帳票・連携システムの数量を、まず数字で把握する
2. 目的・KPI の言語化: 経営層と業務側代表を交えて、優先順位を 1 位から並べる
3. 複数外注先タイプへの相談: 大手 SIer・中堅受託・準委任型チームの 3 タイプそれぞれから、1 社ずつ話を聞く

会社紹介記事に載っている「◯選」の中から選ぶのではなく、判断軸に沿って自社に合う外注先タイプを選ぶこと。これが、失敗しない .NET/C# 基幹系外注の第一歩です。