個人開発者・フリーランスに頼むのはあり？リスクと向き不向き

相見積もりを取り、開発会社を比較検討してきたものの、届いた見積書の金額を見て手が止まった——という経験をした担当者は少なくないはずです。開発会社に依頼すると数百万円規模になりそうな案件が、知人のつてで紹介された個人のフリーランスエンジニアなら半分以下でできると言われた。あるいはクラウドソーシングサイトを覗いてみたら、法人に頼むより明らかに安い金額を提示してくる個人事業主が何人も見つかった。予算の限られた中小企業の情シス・総務担当者にとって、これは魅力的な選択肢に見えます。

一方で、「個人に頼んで本当に大丈夫なのか」という不安もつきまといます。担当者が体調を崩したら開発が止まるのではないか、納品後に連絡が取れなくなったらどうするのか、そもそも個人と法人とでは契約の結び方が違うのではないか——こうした疑問に答えないまま発注してしまうと、思わぬトラブルに発展することがあります。

結論から言うと、個人開発者・フリーランスへの発注は「あり」か「なし」かで一律に決められるものではなく、依頼する案件の性質によって向き不向きがはっきり分かれる選択肢です。この記事では、これまで19本にわたって解説してきた外注のはじめかたシリーズの締めくくりとして、「開発会社（法人）」と「個人開発者・フリーランス」という発注先の2つの選択肢を正面から比較し、どちらを選ぶべきかを判断するための材料を整理します。

この記事で分かること

これまでの記事では、RFPの作り方、見積書の読み方、契約形態の違い、開発会社の選び方など、主に「法人の開発会社に発注する」ことを前提に解説を進めてきました。しかし実際には、法人ではなく個人のフリーランスエンジニアに直接発注するという選択肢も存在します。この記事では、その選択肢を検討する際に押さえておくべき論点を整理します。

• 個人開発者・フリーランスに発注するメリットとデメリット
• 法人の開発会社と個人、それぞれに向いている案件の特徴
• フリーランスとの契約で法律上どのような保護があるのか
• 個人に発注する際に確認すべき実務上のチェックポイント
• 「個人か法人か」で迷ったときの判断基準

これまでの19本で学んできた「見積もりの読み方」「契約形態の違い」「危険なサインの見抜き方」といった知識は、法人相手でも個人相手でも共通して使えるものです。この記事はそれらの総仕上げとして、発注先という最後の分岐点を扱います。

個人開発者・フリーランスとは何を指すのか

まず言葉の整理から始めます。この記事で扱う「個人開発者・フリーランス」とは、法人格を持たず、個人事業主として、あるいは開業届すら出さずに業務委託でシステム開発を請け負う技術者を指します。クラウドソーシングサイト経由で見つかる人、知人の紹介で仕事を受けている人、独立して数年になる元エンジニアなど、働き方の実態は幅広く存在します。

一方で「開発会社」は、法人格を持ち、複数のエンジニアやディレクターが在籍する組織です。ここまでの19本で扱ってきた発注先は、基本的にこちらを想定していました。

両者の違いは単に「法人か個人か」という登記上の話にとどまりません。実務上の違いとして、次のような点が挙げられます。

この表からも分かる通り、どちらが優れているという単純な話ではなく、発注する案件の性質と、発注者側が許容できるリスクのバランスで選ぶべきものです。

個人開発者・フリーランスに発注するメリット

まず、個人に発注することで得られる具体的なメリットを見ていきます。

コストを抑えやすい

最も分かりやすいメリットは、同等のスキルレベルのエンジニアであれば、法人の開発会社よりも見積もり金額が抑えられる傾向にあることです。開発会社の見積もりには、実際に手を動かすエンジニアの人件費に加えて、営業担当者の稼働、プロジェクトマネージャーの管理費、オフィス賃料などの間接費が反映されます。個人事業主はこうした間接費が少ないため、同じ工数でも請求額を低く設定できる余地があります。

ただし、これは「個人だから必ず安い」という意味ではありません。実績豊富な個人開発者は、法人の開発会社と遜色ない、あるいはそれ以上の単価を提示することも珍しくありません。SOW（作業範囲記述書）（作業範囲記述書）を明確にした上で、複数の候補から相見積もりを取って比較する姿勢は、法人相手でも個人相手でも変わらず重要です。

意思疎通が速い

法人の開発会社に依頼すると、発注者の要望が営業担当者からプロジェクトマネージャーへ、そして実際にコードを書くエンジニアへと伝言される過程で、細かいニュアンスが失われることがあります。個人開発者に直接発注する場合、要望を伝える相手がそのままコードを書く本人であるため、伝達のロスが起きにくく、質問への回答も速いという利点があります。

ひとり情シス・総務兼任の担当者にとって、この「話が早い」という感覚は実務上のストレスを大きく減らす要因になり得ます。仕様の細かい確認を何往復もするような案件では、特にこのメリットが活きます。

小規模な改修・保守に機動的に対応しやすい

「ちょっとしたExcelマクロの不具合を直してほしい」「既存のシステムに小さな機能を1つ追加したい」といった小規模な依頼は、法人の開発会社では最低受注金額に満たず断られることがあります。開発会社側にも、営業・見積もり作成・契約手続きといった固定的な事務コストがかかるため、案件規模がそのコストに見合わないと判断されれば、丁重に断られてしまうのが実情です。個人開発者であれば、こうした小口の依頼にも柔軟に対応してもらえる可能性が高くなります。

「小さく発注して試す」という考え方自体は、開発会社への発注でも重要な原則です。関連記事「小さく発注して試す：PoC発注のすすめ」もあわせて参考にしてください。

発注者側の意向を反映したカスタマイズ対応がしやすい

複数の顧客を抱える開発会社では、社内の標準的な開発フローや使用技術が決まっていることが多く、発注者側の細かい要望（特定のツールとの連携、独自の運用ルールへの対応など）に対して「弊社の標準対応外です」と断られる場面があります。個人開発者は、こうした社内標準に縛られにくく、発注者の要望に合わせて柔軟に技術選定や実装方針を調整してくれる場合があります。

ただし、これは諸刃の剣でもあります。標準化されたプロセスがないということは、後述する「対応できる範囲が個人のスキルに限定される」というデメリットと表裏一体の関係にあるためです。

個人開発者・フリーランスに発注するデメリットとリスク

メリットの裏側には、法人にはない固有のリスクも存在します。ここが最も重要な論点です。

事業継続性のリスクが個人に集中する

最大のリスクは、開発を担う人がそのまま事業の全てであるという点です。法人であれば、担当エンジニアが退職しても、社内の別の担当者が引き継いだり、組織としてのナレッジが残っていたりする可能性があります。個人事業主の場合、本人が病気やケガで動けなくなる、家庭の事情で廃業する、より条件の良い会社に就職して個人事業をやめる、といった事態がそのまま「発注先の消滅」に直結します。

これは特に、納品後も継続的な保守・改修が必要なシステムで深刻な問題になります。関連記事「保守契約の内容を契約前に確認すべき理由」で解説した保守契約の考え方は、個人に発注する場合はより一層重要になります。相手が個人である以上、「もしこの人と連絡が取れなくなったら」を前提にした備えが必須です。

• ソースコードは必ず発注者側でも保管できる状態にしておく（Gitリポジトリの権限、納品物の受け渡し方法を事前に確認）
• 開発に使った環境・手順のドキュメント化を成果物に含めてもらう
• 連絡が取れなくなった場合の代替手段（別の技術者への引き継ぎ可否）を事前に相談しておく

対応できる範囲が個人のスキルに限定される

システム開発には、実装だけでなく、デザイン、インフラ構築・運用、セキュリティ対策、テストなど多岐にわたる専門性が求められます。法人の開発会社であれば、社内で役割分担してこれらをカバーできますが、個人開発者は自分の得意領域以外については外部の協力者に再委託するか、対応範囲外として断るかのいずれかになります。

発注前に「この案件に必要な専門性を、この人がすべてカバーできるか」を確認しておかないと、途中で「インフラ周りは専門外なので対応できません」と言われ、追加で別の技術者を探すことになりかねません。

契約・請求の実務が法人ほど整っていない場合がある

開業して間もない個人事業主や、副業としてフリーランス案件を受けている人の場合、契約書の作成、請求書の発行、インボイス対応といった事業者としての実務に不慣れなケースがあります。発注者側から見ると、「契約書のひな形がない」「請求書の記載事項に不備がある」といった手間が発生する可能性があります。

これは個人の能力の問題ではなく、事業者としての経験年数に左右される部分が大きいため、契約実務に不安がある場合は発注者側でひな形を用意して提示するのが実務的な対処法です。関連記事「開発会社との初回打ち合わせで聞くべきこと」で挙げている質問リストは、相手が個人であっても基本的にそのまま使えます。むしろ、法人であれば当然整っている社内チェック体制（契約書のリーガルチェック、請求書発行の経理フローなど）が個人にはないケースがあるため、発注者側が意識してリードする姿勢が求められます。

品質のばらつきが見えにくい

法人の開発会社であれば、社内でのコードレビュー体制やテスト工程が一定の水準で標準化されていることが期待できます。個人開発者の場合、そうした品質担保の仕組みが本人の裁量に委ねられており、外部からは見えにくいという課題があります。「動くものはできたが、セキュリティ面の考慮が甘い」「テストがほとんど行われないまま納品された」といった事態は、個人開発者に限った話ではありませんが、チェック機能が働きにくい分、発注者側での確認がより重要になります。

関連記事「検収とは？発注者がやるべきテスト」で解説した検収の考え方は、個人への発注では特に念入りに実践する価値があります。「担当者を信頼しているから検収を簡略化する」のではなく、信頼している相手だからこそ、双方のために検収の手順を明確にしておくという姿勢が実務上は望ましいといえます。

個人か法人か、案件の性質で判断する

ここまでのメリット・デメリットを踏まえ、実際の判断基準を整理します。次のような案件は、個人開発者・フリーランスへの発注が比較的向いています。

• 小規模な改修・追加開発（既存システムへの機能追加、バグ修正など）
• PoC（概念実証）（概念実証）やMVP（実用最小限の製品）のような、まず小さく試したい段階の開発
• 要件がすでに明確に固まっており、要件定義の作業がほぼ完了している案件
• 個人の実績・専門分野（特定の技術スタック、業界特有の知見など）が案件と強く合致している場合
• 継続的な保守が不要、または発注者側で保守を巻き取れる体制がある場合

逆に、次のような案件は法人の開発会社への発注を優先的に検討すべきです。

• 事業の基幹となる、止まると業務に大きな影響が出るシステム
• デザイン・インフラ・セキュリティなど、複数分野の専門性を横断的に必要とする開発
• 長期にわたる保守・運用体制が前提となるシステム
• 発注者側に技術的な知見が乏しく、対応範囲の切り分けを自力で判断しづらい案件

判断に迷う場合は、「このシステムが1週間止まったら、会社の業務にどれくらいの影響が出るか」を自問してみることをおすすめします。影響が軽微であれば個人への発注のハードルは下がり、影響が深刻であれば継続性の観点から法人を優先すべき理由が強くなります。

ケースで考える：向いている例・向いていない例

抽象的な基準だけでは判断しづらいという方のために、具体的な場面を想定して考えてみます。

個人への発注が向いているケース

• 社内向けの勤怠管理ツールに、部署別の集計機能を1つ追加したい。要件は明確で、既存システムへの部分的な改修にとどまる
• 新しいサービスのアイデアがあり、まずは最小限の機能で市場の反応を試したい（MVPの開発）
• 特定の技術（例えば特定の会計ソフトのAPI連携）に強い個人が見つかり、その専門性がまさに必要な案件と合致している

法人への発注が向いているケース

• 顧客の個人情報を扱う基幹システムを新規に構築する。セキュリティ・法令対応・継続的な運用体制が必須
• デザイン、フロントエンド、バックエンド、インフラの全てを一貫して任せたい大規模なリニューアル案件
• 発注者側にIT知識が乏しく、要件定義の段階から専門家に伴走してもらう必要がある

このように整理すると、「金額の大小」よりも「止まったときの影響の大きさ」「必要な専門性の幅」「継続的な保守の要否」の3点が判断の軸になっていることが分かります。

フリーランスとの取引を保護する法律：フリーランス新法

「個人に発注すると、法律上の保護が何もないのではないか」と不安に思う担当者もいるかもしれません。この点について、2024年11月1日に施行されたフリーランス新法（正式名称：特定受託事業者に係る取引の適正化等に関する法律）が、発注事業者に一定の義務を課しています。発注する側の立場として、この法律の内容を理解しておくことは重要です。

フリーランス新法は、業務委託の相手方である事業者で従業員を使用しない者（フリーランス）と、フリーランスに業務委託する事業者で従業員を使用する者（発注事業者）との間の取引を対象としています。中小企業の情シス・総務担当者が個人のエンジニアに発注する場合、多くのケースでこの法律の対象になります。

発注事業者に課される義務は、従業員を使用しているかどうか、業務委託の期間が一定以上かどうかによって段階的に変わります。主な義務項目は次の通りです。

1. 書面等による取引条件の明示：業務委託をした場合、書面等により直ちに「業務の内容」「報酬の額」「支払期日」「業務委託をした日」などの取引条件を明示する義務
2. 報酬支払期日の設定・期日内の支払：発注した物品等を受け取った日から数えて60日以内のできる限り早い日に報酬支払期日を設定し、期日内に支払う義務
3. 禁止行為：1か月以上の業務委託をした場合、受領拒否・報酬の減額・返品・買いたたき・購入や利用の強制・不当な経済上の利益の提供要請・不当な給付内容の変更やり直しの7つの行為の禁止（従業員を使用し、一定期間以上の業務委託を行う発注事業者が対象）
4. 募集情報の的確表示：フリーランスの募集情報に虚偽や誤解を招く表示をしてはならない義務
5. 育児介護等と業務の両立に対する配慮：6か月以上の業務委託について、フリーランスからの申出に応じた配慮義務
6. ハラスメント対策に係る体制整備：ハラスメント行為に関する方針の明確化や相談体制の整備義務
7. 中途解除等の事前予告・理由開示：6か月以上の業務委託を中途解除・不更新とする場合、原則30日前までの予告義務

発注事業者が「従業員を使用していない」場合でも、義務項目①（書面等による取引条件の明示）は課されます。つまり、発注者自身が個人事業主であっても、フリーランスへ業務委託をする以上は取引条件の書面明示義務から逃れられません。

特に中小企業の担当者が実務上まず押さえておくべきは、①の書面明示義務と②の60日以内の支払期日です。これまでの記事で解説してきた契約書の重要性（関連記事「発注前チェックリスト（契約・権利・データ・保守）」参照）は、個人への発注においても、むしろ法律上の義務としてより明確に求められることになります。「知人の紹介だから」「小規模な案件だから」といって口頭発注で済ませてしまうと、法律違反になり得る点に注意してください。

なお、この法律は発注事業者に義務を課すものであり、フリーランス側の義務ではありません。フリーランス新法を理由に「相手も法律を守っているはずだから安心」と考えるのではなく、発注者自身が義務を果たす立場にあるという理解が実務上は重要です。

個人発注ならではの実務チェックポイント

法人の開発会社に発注する場合と共通する確認項目（請負契約契約か準委任契約か、著作権の帰属、検収の基準など）はこれまでの記事で解説済みです。ここでは、個人開発者・フリーランスに発注する場合に追加で確認しておきたいポイントを挙げます。

• 事業者としての実在確認：屋号や個人事業の開業届の有無、過去の実績や取引先の実在性を、可能な範囲で確認する
• 稼働可能時間・体制の確認：専業か副業か、他の案件と掛け持ちしていないか、繁忙期の対応可否
• 代替不能なリスクへの備え：ソースコード・ドキュメントの受け渡し方法、連絡が取れなくなった場合の対応方針を契約前に相談しておく
• 請求・支払いの実務確認：インボイス発行事業者かどうか（消費税の仕入税額控除に関わるため、発注者側の経理処理に影響する場合がある）
• 契約書の有無：口頭やチャットのやり取りだけで進めず、簡易でもよいので書面（電子的なものも含む）で取引条件を残す

これらの確認は、相手を疑うためではなく、個人という働き方の特性上、法人よりも変数が多いという前提に立って、双方が安心して取引できる土台を作るためのものです。信頼できる個人開発者であればあるほど、こうした事前確認を面倒がらずに応じてくれる傾向があります。

見積もり・契約形態の考え方は法人相手と共通

個人開発者だからといって、見積もりの読み方や契約形態の選び方が変わるわけではありません。関連記事「システム開発の見積書、この内訳の見方で損を防ぐ」で解説した工数・単価・バッファの考え方はそのまま適用できますし、請負契約と準委任契約のどちらが適しているかも、開発の内容次第という判断基準は変わりません。

強いて個人発注ならではの注意点を挙げるとすれば、次の2点です。

1. 単価の妥当性を複数の情報源で確認する：個人の場合、市場相場からかけ離れた単価（極端に高い・安いどちらも）を提示されることがあります。関連記事「システム開発の費用相場：小規模案件は結局いくらかかるのか」も参考にしながら、極端な金額には理由を確認する姿勢が大切です
2. 見積もりの前提条件を書面で残す：口頭やチャットでのやり取りが中心になりやすい個人発注では、「言った・言わない」のトラブルを避けるため、見積もりの前提となった要件を書面（メールやドキュメントでも可）で残しておくことが特に重要です

稟議・社内説明での扱い方

個人開発者への発注は、社内の決裁者にとって「聞き慣れない」選択肢に映ることがあります。「なぜ会社ではなく個人に発注するのか」という疑問に対しては、コスト面だけでなく、この記事で整理した向き不向きの判断軸に沿って説明することで、納得感のある説明がしやすくなります。関連記事「稟議で社内の反対を乗り越える説得材料の作り方」もあわせて参考にしてください。特に、事業継続性のリスクをどう手当てしているか（ソースコードの保管、代替手段の検討など）を説明に含めると、決裁者の不安を軽減しやすくなります。

よくある誤解を解いておく

個人開発者への発注をめぐっては、いくつかの誤解も見られます。

誤解1：「個人は法人より技術力が低い」 これは事実ではありません。フリーランスとして独立している技術者の中には、大手企業での開発経験が豊富な人や、特定分野で高い専門性を持つ人が多く含まれます。技術力の高低は法人か個人かではなく、その人・その組織の実績と専門分野で判断すべきです。

誤解2：「フリーランスとの契約には法律上の保護が一切ない」 前述の通り、フリーランス新法により、発注事業者には書面明示義務や支払期日の義務などが課されています。加えて、契約の内容によっては準委任契約契約や請負契約に関する民法の規定も、法人相手の契約と同様に適用されます。

誤解3：「個人に発注すれば必ず安く済む」 実績や専門性によっては、個人開発者の単価が法人の開発会社と同等、あるいはそれ以上になることもあります。安さだけを理由に個人を選ぶのではなく、案件の性質に合っているかどうかで判断することが重要です。

まとめ：発注先の選択は「案件の性質」で決める

この記事では、外注のはじめかたシリーズの締めくくりとして、法人の開発会社と個人開発者・フリーランスという2つの発注先を比較しました。要点を整理します。

• 個人開発者・フリーランスへの発注は、コストの抑えやすさ・意思疎通の速さ・小規模案件への機動性というメリットがある一方、事業継続性のリスクが個人に集中する、対応範囲が本人のスキルに限定される、という固有のデメリットがある
• 判断基準は「個人か法人か」の二択ではなく、発注する案件の性質（規模・継続性の必要性・専門性の幅）と、発注者側が許容できるリスクのバランスで決めるべき
• 2024年11月1日施行のフリーランス新法により、発注事業者には取引条件の書面明示や60日以内の報酬支払など一定の義務が課されている。個人への発注は「法律上の保護がない」わけではなく、発注者自身が果たすべき義務がある取引である
• 個人発注ならではの追加チェックポイント（事業継続性への備え、稼働体制の確認、契約書の有無）を押さえた上で発注すれば、リスクを抑えながらメリットを活かせる

外注のはじめかたシリーズは、この記事で全20本の解説を終えます。RFPの作り方から要件のまとめ方、見積書の読み方、契約形態の選択、開発会社の見極め方、そして発注先の最終的な選択まで、初めての発注で迷いやすいポイントを一通り整理してきました。実際に発注を進める際は、当メディアの「発注前チェックリスト」もあわせてご活用ください。

発注が完了し、開発がスタートした後の進め方については、カテゴリ「開発会社とのつきあいかた」で、仕様変更の伝え方や検収の進め方、トラブル時の対処法を解説しています。あわせてご覧ください。