フリーランスと正社員の混成開発体制の作り方｜役割分担と運用設計

「フリーランスも正社員も、両方使っていこう」——採用が追いつかない中で、この方針を固めた開発責任者は少なくありません。ところが、いざ正社員とフリーランスを同じチームに混ぜてみると、想定していなかった壁が次々に立ちはだかります。正社員と同じ感覚でフリーランスに細かく指示を出していいのか、コアの機能まで外部に任せてしまっていいのか、そしてフリーランスが契約終了で抜けたとき、その人が握っていた知見ごと消えてしまうのではないか——。

これらは「どちらを選ぶか」という選定の段階では見えてこなかった、運用レベルの不安です。実際、「フリーランス活用 vs 正社員採用、どちらが得か」を比較する情報はたくさんありますが、その先の「両方使うと決めた後、混成チームをどう作り、どう回すか」を体系立てて教えてくれる情報は驚くほど少ないのが実情です。比較記事を読み終えて方針は固まったのに、肝心の「作り方」で立ち止まってしまうのは、ごく自然なことだと言えます。

混成（ハイブリッド）開発体制をうまく機能させられるかどうかは、才能やセンスの問題ではありません。「どこを社内で握り、どこを外部に出すか」という線引きと、その線引きに沿った運用ルールを、最初に設計できているかどうかにかかっています。逆に言えば、設計の論点さえ押さえれば、混成チームは正社員だけのチームよりも柔軟でスピードの出る体制になり得ます。

本記事では、発注企業の目線で混成開発体制を組み立てる手順を、(1) 役割分担（核と周辺の切り分け）、(2) フリーランスへの指示の出し方（偽装請負を避ける運用）、(3) ノウハウが流出しない仕組み、(4) 内製比率の決め方——という4つの設計論点に分けて解説します。読み終えた頃には、「結局どこまで外部に任せ、どこを社内で握るのか」を自分の言葉で説明できるようになっているはずです。

フリーランスと正社員を混ぜると起きる「運用の壁」とは

「両方使う」と決めること自体は、難しい意思決定ではありません。本当に難しいのは、その方針を実際のチーム運用に落とし込む段階です。ここでは、混成体制で発注企業が直面する典型的な壁を言語化し、本記事がそれをどう整理するのかを先にお伝えします。

「両方使う」と決めた後に出てくる4つの壁

正社員とフリーランスを混ぜたチームで、現場が回らなくなる原因をたどっていくと、多くの場合は次の4つの壁のどれかに行き着きます。

• 指示の壁: 正社員には当たり前にできる「ちょっとこれもお願い」「明日までに」といった指示を、フリーランスにも同じ感覚で出してしまう。しかしこれは偽装請負と見なされるリスクをはらみ、契約上も実務上も無理が生じます。
• 役割分担の壁: どの仕事を社内（正社員）で握り、どの仕事を外部（フリーランス）に出すかの基準が曖昧なまま、目の前のタスクを手の空いた人に振ってしまう。結果として、プロダクトの核となる部分まで外部依存になったり、逆に何でも社内で抱えてスピードが落ちたりします。
• ノウハウの壁: フリーランスは契約期間が終われば離れていきます。その人だけが理解していた設計や運用の知見が、引き継ぎ不足のまま失われ、後から手をつけられなくなります。
• 内製比率の壁: 社内エンジニアと外部の割合をどう決めればよいかの指針がなく、「とりあえず足りないから増やす／減らす」を場当たり的に繰り返してしまいます。

この4つは、それぞれ独立した問題のようでいて、実は「どこまでを外部に委ね、どこを社内で握るか」という1つの線引きから派生しています。本記事は、この4つの壁をそれぞれ1つの設計論点として扱い、順番に解いていきます。

本記事の立ち位置 ― 選定ではなく「混成チームの設計・運用」

ここで本記事のスコープをはっきりさせておきます。本記事が扱うのは、「フリーランスと正社員を併用すると決めた後」の、混成チームの設計と運用です。

もしあなたがまだ「そもそもフリーランスを使うべきか、正社員を採用すべきか」という選定の段階にいるのであれば、本記事より先に読むべきものがあります。コスト・リスク・スピードの3観点で選定の判断軸を整理したフリーランスエンジニア活用vs採用｜コスト・リスク・スピードで選ぶをご覧ください。そちらで「どちらを、どんな案件に使うか」の意思決定を済ませた上で、本記事の「混成チームの作り方」に戻ってくると、内容がすっと入ってくるはずです。

逆に、すでに「両方使う」と決めている、あるいは現にフリーランスを1〜数名アサインしていて運用に手応えのなさを感じている方は、このまま読み進めてください。次の章から、4つの壁を1つずつ設計論点として解いていきます。

役割分担を設計する ― 「コア」と「差し替え可能な周辺」を切り分ける

混成体制の設計は、役割分担から始めます。具体的には、自社のプロダクトを「社内（正社員）で握るべき核（コア）」と「外部（フリーランス）に出せる差し替え可能な周辺」に切り分けることです。この切り分けが、後続の指示・ノウハウ保全・内製比率の議論すべての土台になります。

なぜ「核と周辺の切り分け」が出発点なのか

混成体制をうまく回している企業に共通するのは、「すべてを均等に扱わない」という発想です。プロダクトを構成する要素には、競争力に直結し頻繁な意思決定を要する部分と、仕様が固まっていて誰がやっても結果が大きく変わらない部分があります。前者を社内で握り、後者を外部に出す——この切り分けこそが、混成体制の出発点です。

内製と外注の良いとこ取りを実現する第一歩は、社内で守るべき核と、外に出せる周辺を見極めることだ、という論点は複数の専門メディアでも共通して指摘されています（CLYR: 内製チーム vs 外注チームのハイブリッド活用法）。切り分けをせず、目の前のタスクを手の空いた人に割り振っていると、いつの間にかプロダクトの根幹を外部に依存する状態に陥り、後戻りが効かなくなります。

社内（正社員）で握るべき領域

次のような領域は、原則として社内の正社員が握るべきコアです。

• プロダクトの差別化要素: 競合と差がつく機能や独自のロジック。ここは事業の競争力そのものであり、外部に丸投げすると主導権を失います。
• 頻繁に意思決定が必要な領域: 仕様が流動的で、ビジネス判断と密接に絡む部分。逐一の判断を外部に委ねると、後述する指揮命令の問題（偽装請負リスク）にも直結します。
• アーキテクチャの根幹: システム全体の設計思想やデータ構造の中核。ここが揺らぐと、周辺をいくら整えても破綻します。

これらは「将来にわたって自社が責任を持って育てていく部分」と言い換えられます。知見が社内に蓄積されないと、プロダクトを自分たちでコントロールできなくなるため、コアは社内に残すのが原則です。

フリーランスに任せやすい領域

一方、次のような領域はフリーランスに任せやすく、混成体制の柔軟性を生かせる部分です。

• 仕様が明確に定義できる実装タスク: 入力と出力、完成条件がはっきりしているもの。成果物で握れるため、後述する偽装請負リスクも抑えやすくなります。
• 周辺機能・付随的な開発: コアではないが必要な機能。管理画面、バッチ処理、外部サービス連携など。
• スポットで必要になる専門領域: インフラ構築、特定フレームワークの導入、パフォーマンスチューニングなど、一時的に高い専門性が必要な領域。常時雇用するより、必要なときに専門家を起用するほうが合理的です。

ポイントは、フリーランスに出す仕事ほど「何をもって完成とするか」を明確に定義することです。定義が曖昧なまま外部に出すと、成果物の握りが効かず、結果として細かい指示を出さざるを得なくなり、指揮命令の問題に発展します。

切り分けを誤るとどうなるか

役割分担を誤ると、典型的には2つの失敗パターンが生じます。

1つは、コアまで外部に丸投げして主導権を失うパターンです。差別化要素やアーキテクチャの根幹を外部に任せきると、その人が抜けた瞬間にプロダクトを動かせなくなり、知見も社内に残りません。短期的にはスピードが出ても、中長期で見ると事業の土台が外部に握られた状態になります。

もう1つは、逆に何でも社内で抱え込んでスピードが出ないパターンです。外部に出せる周辺タスクまで正社員が抱えると、コアに集中すべき人材が雑多な作業に追われ、せっかく混成体制を組んだ意味が薄れます。混成体制の価値は「コアに社内の力を集中させ、周辺を外部で素早く回す」ことにあります。

この2つの失敗を避けるための線引きが、次章以降の運用設計の前提になります。

混成チームのマネジメント ― フリーランスへの指示の出し方と偽装請負

役割分担で「フリーランスに何を出すか」を決めたら、次は「どう指示を出すか」です。ここが混成体制で最もつまずきやすく、かつ法的リスクを伴う論点です。結論から言えば、フリーランスに正社員と同じ感覚で指示を出してはいけません。理由は「偽装請負」と見なされるリスクがあるからです。

なぜフリーランスに正社員と同じ指示を出してはいけないのか

業務委託契約（請負・準委任）で働くフリーランスは、雇用関係にある正社員とは法的な位置づけが根本的に異なります。雇用であれば企業はその人を指揮命令下に置き、業務の進め方や時間を管理できます。しかし業務委託では、原則として委託者（発注企業）が受託者（フリーランス）に対して具体的な作業指示や勤怠管理を行うことは想定されていません（業務委託契約における指揮命令の範囲や注意点）。

契約上は業務委託であっても、実態として発注企業がフリーランスを指揮命令下に置いていると、それは「偽装請負」と見なされ、労働者派遣法違反に該当する可能性があります。重要なのは、偽装請負かどうかは契約書の名称ではなく、実際の業務運用の実態で判断されるという点です（偽装請負とは？判断基準や問題点、罰則）。

そもそも労働者に当たるかどうかは、厚生労働省の基準で「他人の指揮監督下で業務が行われているか」「報酬がその指揮監督下の労働の対価か」という2つの観点から判断されます（偽装フリーランスとは？労働者の判断基準や裁判例）。つまり、正社員と同じように出退勤を管理したり、業務の進め方を逐一指示したりすると、それだけで「実態は雇用」と判断されかねないのです。

加えて、2024年11月に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）により、発注事業者には業務内容の明示などが義務付けられ、フリーランスとの取引における契約内容の明確化が一層求められるようになりました（出典: 厚生労働省「フリーランス・事業者間取引適正化等法」、2024年）。混成体制を組むなら、この潮流を踏まえた運用が前提になります。

偽装請負を避ける指示の出し方 ― 成果物・タスク単位で握る

では、どう指示を出せばよいのでしょうか。鍵は「人」ではなく「成果物・タスク」を管理することです。具体的には次のような運用に切り替えます。

• 成果物と期待値で握る: 「この機能を、この仕様で、この期日までに」という形で、何を納品してほしいかを明確に定義する。作業の進め方そのものは、原則としてフリーランス本人に委ねます。
• 業務単位・タスク単位で依頼する: 「手が空いたらこれもお願い」のような追加指示を都度かぶせるのではなく、依頼する業務の範囲をあらかじめ切り出して渡します。役割分担で「定義できる実装タスク」をフリーランスに出すべきと述べたのは、この握り方を成立させるためでもあります。
• 勤怠管理や逐一の作業指示を避ける: 始業・終業時刻の管理、常駐の強制、作業手順の細かい指定は、指揮命令と見なされやすい典型例です。これらは正社員に対する管理であって、業務委託では行いません。

言い換えると、正社員には「プロセス（働き方）」を管理してよいが、フリーランスには「アウトプット（成果物）」で握る、という発想の切り替えが必要です。この切り替えができていれば、混成チームでも偽装請負リスクを抑えながら運用できます。なお、どこまでの指示が許容されるかの線引きは契約形態（請負か準委任か）や業務の性質によって変わるため、判断に迷うケースでは契約段階で専門家に確認しておくことをおすすめします。

混成チームのコミュニケーション設計

指示の出し方を整えたら、チーム全体のコミュニケーションも混成前提で設計します。正社員だけのチームの感覚をそのまま持ち込むと、情報共有の範囲や定例の持ち方で齟齬が生じます。

• 情報共有の範囲を決める: フリーランスに渡す情報は、依頼した業務の遂行に必要な範囲に整理します。コアの意思決定に関わる議論まですべて巻き込む必要はありませんが、逆に必要な前提情報が不足すると成果物の品質が落ちます。「業務に必要十分」を基準にします。
• 定例は成果物の確認の場にする: フリーランスとの定例ミーティングは、進捗の細かい監督ではなく、成果物のレビューと次の依頼範囲のすり合わせの場と位置づけます。これも「プロセスではなくアウトプットで握る」運用の一環です。
• 正社員との知見のやり取りを設計する: 後述するノウハウ保全とも関わりますが、フリーランスが持ち込む専門知識を正社員が吸収できる接点（コードレビュー、設計レビューなど）を意図的に作っておくと、混成体制の価値が高まります。

なお、本記事で扱うのは「指示系統や情報共有の範囲をどう設計するか」という体制づくりの観点です。実際に混成チームが立ち上がった後、日々の進捗管理・モチベーション維持・正社員とフリーランスの一体感づくりといった日常マネジメントでつまずいている場合は、正社員×フリーランス混在チームの運営方法で運用面の実践ポイントを補完できます。本記事の「設計」とあわせて読むと、体制の構造と日々の運営の両面を押さえられます。

ノウハウが流出しない仕組みを体制に組み込む

混成体制を運用していて、多くの発注企業が後から痛感するのが「フリーランスが抜けたら知見ごと消える」問題です。これは性格の問題でも契約の問題でもなく、構造的に起きやすい現象です。だからこそ、ノウハウ保全は「気をつける」ではなく「仕組みとして体制に組み込む」必要があります。

フリーランス活用でノウハウが流出しやすい理由

フリーランスは、定義された業務を遂行して納品し、契約期間が終われば離れていく存在です。正社員のように長期にわたって組織に知見を蓄積していく前提ではありません。そのため、その人が実装の過程で得た判断の経緯や、運用上の勘所といった「ドキュメントに残りにくい知見」は、本人の離任とともに失われやすいのです。フリーランスエンジニアの活用では離任時のノウハウ流出が課題になりやすく、明文化や引き継ぎの設計が重要だという指摘は、人材領域のメディアでも共通しています（フリーランスエンジニアの採用方法・注意点）。

放置すると、「コードは動いているが、なぜこう作ったのか誰も説明できない」「障害が起きても当時の担当者がいないため手がつけられない」といった状態に陥ります。これを防ぐには、知見が本人の頭の中だけに留まらない仕組みが要ります。

ノウハウを社内に残す3つの仕組み

ノウハウ保全は、次の3つを体制設計に組み込むことで実現します。

1. 明文化の義務付け: 設計の意図、運用手順、依存関係などのドキュメント化を、成果物の一部として契約・依頼に含めます。「動くコード」だけでなく「後任が理解できるドキュメント」までを納品物と定義することで、知見が形に残ります。役割分担の章で「成果物を明確に定義する」と述べたことが、ここでも効いてきます。
2. 正社員とのペアリング／レビュー経由での知見移転: フリーランスの作業を正社員がコードレビューや設計レビューで受け止める接点を常設します。レビューを通じて、なぜその実装にしたのかという判断の背景が正社員側に蓄積され、本人が抜けても社内に知見が残ります。
3. コアの仕様判断は社内に残す: 役割分担で「コアは社内で握る」と決めたことが、ノウハウ保全でも生きます。プロダクトの根幹に関わる仕様判断を社内に残しておけば、フリーランスが担当した周辺機能の知見が多少失われても、システム全体のコントロールは保てます。

この3つは独立した施策ではなく、役割分担（コアの社内保持）→ 指示の出し方（成果物としての明文化）→ チーム運用（レビューでの知見移転）という、ここまでの設計が一貫してつながった結果として機能します。

引き継ぎを前提にした成果物定義・契約の作り方

フリーランスはいつか必ず離任します。だからこそ、契約と成果物の定義を「引き継ぎ前提」で作っておくことが、後の混乱を防ぎます。

• 納品物にドキュメントを含める: 前述のとおり、設計書・運用手順・環境構築手順などを成果物として明記します。離任時に「ここまでは必ず残す」というラインを、契約の段階で合意しておきます。
• 離任時の引き継ぎ作業を業務範囲に含める: 契約終了の際に、後任への引き継ぎ（口頭説明やドキュメント整備）を業務の一部として最初から織り込んでおきます。終了間際になって慌てて頼むと、契約範囲外として対応してもらえないこともあります。
• 属人化を避ける範囲を定義する: 「この領域は1人のフリーランスだけが触る状態にしない」というルールを設け、正社員またはもう1人が把握できる体制にしておきます。

これらは契約段階で決めておくべき事項です。アサイン後に追加で頼もうとすると、追加の作業指示と見なされて偽装請負リスクにも触れかねません。最初の契約設計に組み込むことが肝心です。

内製比率をどう決めるか ― フェーズと案件で変える設計指針

ここまでの3つの論点を押さえたうえで、最後に向き合うのが「結局、社内と外部の割合をどう決めるのか」という内製比率の問題です。これは本記事の裏テーマ——「どこまで外部に任せ、どこを社内で握るのか」——に最も直接的に応える論点でもあります。

内製比率は固定ではない ― フェーズと案件で変える

まず押さえておきたいのは、内製比率に唯一の正解はなく、固定すべきものでもないということです。プロダクトの置かれた状況によって、最適な比率は変わります。

• 立ち上げ期（スピード優先）: 市場に素早く出すことが最優先のフェーズでは、外部の力を多めに使ってスピードを稼ぐ判断が合理的です。まだ何が当たるか分からない段階で、すべてを社内人材で抱える必要はありません。
• 成長・運用期（知見の蓄積を優先）: プロダクトの方向性が定まり、長期的に育てていくフェーズに入ったら、コアの知見を社内に蓄積するために内製の比率を高めていきます。外部に任せた周辺機能のうち、継続的に重要になるものを社内に巻き取る判断も出てきます。
• 案件特性で変える: 一時的なスパイク対応（急な開発需要、期間限定のキャンペーン機能など）は外部で、継続的に育てるコア領域は内製で、という案件単位の使い分けも有効です。役割分担の章で述べた「核と周辺の切り分け」を、時間軸でも適用する発想です。

正社員と業務委託・副業を組み合わせた混成チーム（インソーシング型のチーム）を起点に内製化を進めていく、という考え方は、組織づくりの実践者からも提唱されています（エンジニア組織を内製するには、まずハイブリッドなチームを作れ）。混成体制は固定のゴールではなく、フェーズに応じて比率を動かしていく動的なものだと捉えると、内製比率の悩みはぐっと扱いやすくなります。

外部依存が高すぎる／社内で抱えすぎる場合の弊害

内製比率が極端に振れると、それぞれに弊害が出ます。

外部依存が高すぎる場合は、コアの知見が社内に残らず、プロダクトを自社でコントロールできなくなります。フリーランスの離任のたびに事業が揺らぎ、ノウハウ保全の仕組みを組んでいても限界があります。スピードは出ても、事業の持続性が外部の都合に左右される状態です。

社内で抱えすぎる場合は、採用と育成のコストと時間が重くのしかかり、需要の波に柔軟に対応できなくなります。一時的なスパイクのために正社員を増やすと、需要が落ち着いたときに固定費として残ります。混成体制を選んだそもそもの目的（スピードと柔軟性）を、自ら手放すことになります。

このどちらにも振れすぎないバランス点を、フェーズと案件で調整し続けるのが、内製比率の設計です。

内製比率を見直すタイミング

内製比率は一度決めて終わりではなく、定期的に見直します。次のようなタイミングが見直しの目安です。

• プロダクトのフェーズが変わったとき: 立ち上げ期から成長期へ、あるいは新規開発フェーズから運用・保守フェーズへ移行するタイミング。
• 特定領域への外部依存が固定化してきたとき: 本来コアであるはずの領域を、長期にわたって特定のフリーランスに依存している場合は、内製への巻き取りを検討します。
• 採用状況が変わったとき: 正社員エンジニアの採用が進んだ、あるいは逆に退職が出たなど、社内のリソースが変動したとき。

見直しの判断軸は、結局のところ役割分担の章で立てた「核と周辺の切り分け」に戻ります。「いま外部に出しているこの領域は、本当に周辺のままでよいか。コアに昇格していないか」を定期的に問い直すことが、内製比率を健全に保つコツです。

フリーランスと正社員の混成開発体制を作る手順のまとめ

ここまで、混成（ハイブリッド）開発体制を4つの設計論点で解いてきました。最後に、混成体制を組む際の設計の順番として、全体を振り返ります。

1. 役割分担を決める: まずプロダクトを「社内で握るコア」と「外部に出せる差し替え可能な周辺」に切り分ける。差別化要素・意思決定・アーキテクチャの根幹は社内、定義できる実装タスク・周辺機能・専門スポットは外部、が基本線です。
2. 外部に出す範囲をタスク単位で定義する: フリーランスに出す仕事は「何をもって完成とするか」を明確に定義し、成果物・タスク単位で握る。これが偽装請負を避ける運用（プロセスではなくアウトプットで管理する）の前提になります。
3. 引き継ぎとノウハウ保全を契約・成果物に組み込む: ドキュメント化を納品物に含め、正社員とのレビューで知見を移転し、離任時の引き継ぎを最初の契約に織り込む。コアの仕様判断は社内に残します。
4. フェーズに応じて内製比率を調整する: 立ち上げ期は外部多め、成長・運用期は内製多めを基本に、フェーズと案件特性で比率を動かし、定期的に見直す。

この順番には意味があります。役割分担という土台を最初に作るからこそ、指示の出し方もノウハウ保全も内製比率も、一貫した基準で設計できます。逆に、土台の切り分けを飛ばして個別の対処に走ると、冒頭で挙げた4つの壁が再発します。

なお、ここで設計した体制を実際に動かし始めると、今度は日々のマネジメント——進捗の追い方、正社員とフリーランスの温度差の埋め方、混在チーム特有のコミュニケーション運用——が次の課題になります。日常の運営面でつまずいたときは、正社員×フリーランス混在チームの運営方法が実践的な手引きになります。本記事の「体制設計」と、そちらの「日々の運営」を両輪で押さえると、混成チームは安定して回り始めます。

次のアクションとして、まずは自社の現在の体制を、この4つの論点で点検してみてください。「コアと周辺の切り分けは明文化されているか」「フリーランスへの指示は成果物で握れているか」「ノウハウ保全は仕組みになっているか」「内製比率はフェーズに合っているか」——この4つを自分の言葉で答えられれば、混成チームの設計に自信を持って踏み出せるはずです。点検の結果、体制設計そのものを外部の知見を借りて見直したくなったときは、開発体制づくりの実務に通じたパートナーに相談するのも一つの選択肢になります。