C#エンジニアのフリーランスがつまずきやすい点と対策

フリーランスのC#エンジニアがつまずきやすいのは、移行案件で「どこまで移すか」と「何をもって終わりとするか」が決まっていないこと、現地作業の時間と費用の扱い、古い.NETの現場の癖、そして.NETのサポート期限に合わせて契約が区切られることです。どれも、C#が長く動く業務システムや工場の設備とつながる仕組みで使われることから起きます。

対策の基本は、参画前に範囲と終わり方を言葉にしておき、参画後は動かした環境と判断の記録を残すことです。この記事では、契約・現場・技術・お金の4面で、C#ならではの場面と対策を整理します。独立前の準備はC#エンジニアがフリーランスになるにはで扱っているので、ここでは参画してから起きやすいことに絞ります。

契約でのつまずき

移行案件の「範囲」が後から広がる

.NET Frameworkのアプリを新しい.NETへ移す案件は、始めてみると対象が増えやすい仕事です。最初は「画面と業務ロジックを移す」と聞いていたのに、帳票の部品、外部の機器とつながる部分、バッチ、インストーラーまで含めてほしいと言われる、という形で広がります。古いアプリほど、使っている部品の一覧が残っていないためです。

対策：参画前に、移す対象（プロジェクトの単位、画面、バッチ、帳票、外部連携）と、対象外のものを確かめます。参画後に対象外の依頼が来たら、まず影響と工数の見込みを出してから扱いを相談します。範囲が変わったときの考え方は業務範囲が変わったときの記事をご覧ください。

請負なのか準委任なのかで、終わり方が違う

C#の案件には、移行や小規模な業務アプリの開発を請負で受ける形も見られます。請負では成果物を完成させて引き渡すことが約束の中身になり、検収に通るまで報酬が確定しないことがあります。準委任では、作業を専門家として通常求められる注意を払って行うことが約束の中身です。この違いを意識しないまま受けると、「動かない部分が残っているので支払えない」と言われる場面が生まれます。

対策：契約の形を確かめ、請負なら検収の条件（何を、いつまでに、誰が確かめるか）を契約前に言葉にします。違いは準委任と請負の違い、検収の流れは検収の記事で解説しています。

社員と同じ指示の受け方になっていく

社内システムの保守の案件では、発注側の情報システム部門の席に入り、社員と同じように朝の作業指示を受けて動く形になりがちです。準委任の契約で、勤務時間や作業の手順まで細かく指示される状態が続く場合は、契約と実態がずれていないかを確かめてください。考え方は偽装請負の記事をご覧ください。

現場でのつまずき

動かせる環境がそろうまで時間がかかる

C#の業務アプリは、特定のVisual Studioの版、社内のライブラリ、ライセンスの要る部品、接続先のデータベースがそろって初めて動きます。手順書が古く、ビルドが通るまでに数日かかることも珍しくありません。その間「まだ何も進んでいない」と見られるのが、参画直後のつらいところです。

対策：環境づくりで詰まった点と解決した手順を、その日のうちにメモに残し、窓口に共有します。その手順書は次の人の役にも立ち、現場への最初の貢献になります。初月の進め方はC#エンジニアの参画初月にやることで整理しています。

現地作業の頻度が聞いていた話と違う

製造・制御系や社内ネットワークの中で動く業務システムでは、リモートの案件と聞いていても、装置の立ち上げや本番への切り替えのときに現地での作業が入ることがあります。移動の時間や交通費の扱いが決まっていないと、負担だけが増えます。領域ごとのリモートとの相性はC#エンジニアのリモートの記事で解説しています。

対策：参画前に、現地作業の頻度の見込み、移動時間を稼働に含めるか、交通費や宿泊費をどう扱うかを確かめます。参画後に頻度が増えてきたら、記録をもとに早めに相談します。

前任者の書き方を一気に直そうとする

長く改修を重ねたアプリには、今の目で見ると直したくなる書き方が多く残っています。しかし、テストがない古いコードを広く書き直すと、思わぬところで動きが変わり、障害の原因を作ってしまうことがあります。

対策：頼まれた改修の範囲を守り、直したい点は一覧にして提案にとどめます。直すときは、変える前と後で同じ動きになることを確かめる手順を先に決めておきます。

技術でのつまずき

古い.NETと新しい.NETの違いでつまずく

.NET Frameworkの経験が長い人が新しい.NETの案件に入ると、設定ファイルの扱い、依存性の注入（DI）を前提にした組み立て、ASP.NET Coreの処理の流れなど、似ているのに違う点で手が止まります。逆に新しい.NETに慣れた人が古い.NET Frameworkの保守に入ると、Web Formsや古い部品の扱いで戸惑います。

対策：面談の段階で、案件の.NETの版と使っているフレームワークを確かめ、経験との差を自分で把握しておきます。差がある部分は、参画前に手元で小さく動かしておくと立ち上がりが早くなります。必要なスキルの全体像はC#に求められるスキルの記事をご覧ください。

サポート期限を前提にした判断を任される

.NETは毎年11月に新しい版が出て、偶数の版は3年、奇数の版は2年サポートされます。.NET 8と.NET 9のサポートは2026年11月10日に終わり、.NET 10は2028年11月14日まで続くと案内されています。.NET Frameworkは4.5.2以降がWindowsの部品として扱われ、Windowsのサポートに合わせて支えられますが、4.6.2は2027年1月12日に終わります（いずれも2026年10月時点、Microsoftの案内による）。

こうした期限を前に、「どの版へ移すか」「いつまでに移すか」の判断を外部のエンジニアに求められることがあります。判断を丸ごと引き受けると、後で問題が出たときに責任が自分に向きやすくなります。

対策：選択肢と根拠、それぞれのリスクを整理して出し、決めるのは発注側という形をとります。決まった内容と経緯は議事録に残します。

生成AIで書いたコードの扱い

移行や改修で生成AIの支援を使う現場も増えていますが、社外のサービスにソースコードを入れてよいかは、発注側の決まりによります。決まりを確かめずに使うと、情報の扱いの問題になります。

対策：使ってよい道具と、入れてよい情報の範囲を参画時に確かめます。決まりがない場合は、使う前に窓口に尋ねてください。

お金でのつまずき

切り替えや装置の立ち上げで稼働が膨らむ

本番への切り替えや工場の装置の立ち上げは、夜間や休日に行われることがあり、短い期間に稼働が集中します。精算幅を超えた分の扱いを決めていないと、報酬に反映されないまま負担が増えます。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。夜間・休日の作業の扱いも、契約前に確かめておきます。精算の仕組みは精算幅の記事で解説しています。

移行が終わった時点で契約も終わる

移行の案件は、移し終えた時点で役割が終わることが多く、その後の保守まで続くとは限りません。サポート期限に合わせた計画なら、終わりの時期も読みやすい反面、周りの案件も同じ時期に区切られやすくなります。

フリーランス法では、6か月以上続く業務委託を発注側が解除したり更新しなかったりする場合、少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。それでも、空白をなくせるわけではありません。

対策：契約期間と移行の計画の節目を並べて見ておき、更新の見込みを早めに確かめます。次の案件の相談は、契約の終わりの1〜2か月前に始めると準備しやすくなります。更新の考え方は契約更新の記事をご覧ください。

よくある質問

移行の見積もりを出してほしいと言われました。どう出せばよいですか？

古いアプリは使っている部品や外部連携の全体が分からないことが多いため、最初から一つの数字で出すのは危うい面があります。まず調査の期間を区切って対象を洗い出し、その結果をもとに移行の見積もりを出す、という二段階にすると、見込み違いを小さくできます。

現地作業があるとは聞いていませんでした。断ってもよいですか？

まずは、契約で決めた作業場所と業務範囲を確かめてください。契約にない作業であれば、扱いを相談する余地があります。紹介を受けたエージェントや発注側の窓口に、頻度と費用の扱いを含めて早めに伝えることをおすすめします。

古いコードの不具合を見つけました。直してもよいですか？

頼まれた範囲の外であれば、自分の判断で直すのは避け、見つけた内容と影響の見立てを窓口に伝えます。直すかどうかと、その作業の扱いを決めてもらってから手を付けると、範囲や責任の食い違いを防げます。