フリーランスエンジニアの継続依頼術｜優秀な人に長く関わってもらう発注者の設計

「ようやく自社のプロダクトを深く理解してくれたエンジニアが、契約更新のタイミングで他社に移ってしまった」——外部エンジニアを起用したことのある発注企業なら、こうした経験や不安に心当たりがあるのではないでしょうか。技術力もコミュニケーションも申し分なく、社内の事情まで把握してくれている。だからこそ、その人がいつまで関わってくれるのかが読めないことは、大きな経営リスクになります。

外部エンジニアの起用は「立ち上げに成功すれば終わり」ではありません。むしろ難しいのは、立ち上がったあとに「いかに長く関わってもらうか」という継続の局面です。優秀な人ほど複数の案件を抱え、より条件のよい仕事を選べる立場にあります。発注者が何もしなければ、相手の都合で関係が終わってしまうのは自然なことです。

そして中核エンジニアが抜けたときに発注者が支払うコストは、想像以上に大きくなります。新しい人を探す採用コスト、プロダクトを理解してもらうまでの立ち上げ期間、失われるドメイン知識、その間に落ちる開発スピードと品質。これらを「また一からやり直す」のは、誰にとっても避けたい事態です。

ただ、ここで知っておきたいのは、長期継続は「相手の善意」や「運」で決まるものではないということです。継続依頼を勝ち取れる発注者には、契約・単価・関わり方に共通する設計があります。逆に無自覚に人材を手放してしまう発注者にも、共通するパターンがあります。

本記事では、一度起用したフリーランス・業務委託エンジニアに長く関わってもらうために、発注者が主体的に取れる打ち手を整理します。選ばれ続ける発注者の条件、後手にならない契約更新の設計、単価アップ要望や正社員化への判断軸、偽装請負を避けながら深く連携する方法、そして長期化の裏で起きる属人化への対策まで、継続依頼を「設計できるもの」として解説します。

なぜ「フリーランスエンジニアの長期活用・継続依頼」が発注者の課題になるのか

外部エンジニアを起用する企業は年々増えています。背景にあるのは、深刻化するIT人材不足です。経済産業省の試算では、2030年には最大で約79万人のIT人材が不足するとされており（日本経済新聞「IT業界の人材不足とは 2030年に最大79万人」）、社内での正社員採用だけで開発体制をまかなうのは年々難しくなっています。

こうした市場では、優秀なフリーランス・業務委託エンジニアの争奪戦が起きています。発注者にとって本当の課題は「最初に良い人を見つけること」よりも、「見つけた良い人に長く関わってもらうこと」へと移っているのです。

ここで重要なのは、「初回起用の成否」と「継続の成否」がまったく別の問題だという点です。立ち上げがうまくいったからといって、その人が長く関わり続けてくれる保証はありません。継続は継続で、発注者が意図的に設計すべきテーマなのです。

外部エンジニアが離れたときに発注者が失うもの

中核を担っていた外部エンジニアが離れると、発注者は次のようなコストを一度に背負うことになります。

• 再採用コスト: 新たに人材を探す手間、エージェント費用、面談・選考の工数
• 立ち上げ期間: 新しい人がプロダクトやコードベース、業務ドメインを理解するまでの数週間〜数ヶ月。この間、開発スピードは大きく落ちます
• ドメイン知識の喪失: 「なぜこの仕様になっているのか」「過去にどんな判断をしたのか」といった、ドキュメントに残りにくい暗黙知。離れた人と一緒に消えてしまいます
• 品質低下: コードの全体像を把握していない人が触ることで生じるバグや手戻りのリスク

つまり、中核エンジニアの離脱は単なる「人手の減少」ではなく、「これまで積み上げた理解と速度のリセット」を意味します。だからこそ、継続依頼を維持することは、開発体制の安定そのものに直結します。

「優秀な人ほど離れやすい」市場構造

もう一つ理解しておきたいのが、優秀なエンジニアほど離れやすいという構造です。

実力のあるフリーランスエンジニアは、常に複数の案件オファーを受けています。フリーランスエンジニア案件の月額平均単価は74万円前後とされ（PR TIMES「フリーランス市場月額単価の動向」）、需要の高いスキルを持つ人ほど、より条件のよい仕事を選べる立場にあります。

逆に言えば、発注者が「居心地のよい関係」を提供できなければ、相手にとって乗り換える理由はいくらでもあるということです。優秀な人を長く引き留めるには、相手が「ここで続けたい」と感じる環境を発注者側が用意する必要があります。次の章では、その「続けたいと思われる発注者」と「離れられる発注者」の違いを具体的に見ていきます。

長期継続される発注者・離れられる発注者の違い

エンジニア側が「この発注者となら続けたい」「この発注者からは離れたい」と感じる要因は、実は発注者がコントロールできる範囲に多く含まれています。運や相性の問題に見えて、その多くは設計次第で変えられるものです。

報酬・裁量・コミュニケーション・成長機会・事務処理の負担という5つの観点で、両者を対比すると次のようになります。

この対比からわかるのは、エンジニアの定着が「気持ちよく働ける環境かどうか」という、極めて実務的な要素で決まっているということです。

続けたいと思われる発注者の共通点

長く関わってもらえる発注者には、いくつかの共通点があります。

第一に、裁量を与えていることです。優秀なエンジニアほど「どう作るか」を任されることを望みます。ゴールと制約条件を明確に伝えたうえで、進め方は本人に委ねる。これは後述する偽装請負の回避にもつながる、本質的に重要な姿勢です。

第二に、専門性への敬意があることです。技術的な判断を尊重し、安易に「もっと早く」「もっと安く」と言わない。相手を「業者」ではなく「パートナー」として扱う姿勢は、必ず伝わります。

第三に、適正な報酬と、その見直しに前向きなことです。相場を無視した安い単価で据え置こうとすれば、相手は黙って次の案件を探し始めます。

第四に、支払いが速く確実なことです。フリーランスにとって、報酬の支払いタイミングは死活問題です。締め日・支払日が明確で、遅延がないことは、それだけで大きな信頼につながります。

無自覚に離れられる発注者がやっていること

一方で、悪気なく人材を手放してしまう発注者には、次のような行動が見られます。

• 無償の追加依頼: 「ついでにこれもお願い」「ちょっとした修正だから」と、契約範囲外の作業を無償で求める
• 連絡過多: 稼働時間外のチャットや、即レスを暗に求める頻繁な連絡。これは指揮命令とみなされ偽装請負のリスクにもなります
• 評価のなさ: 良い仕事をしてもフィードバックがなく、貢献が見えていない
• 支払い遅延: 検収の遅れや支払日のずれ込み。一度でも信頼を損ないます

これらはいずれも、発注者が「気づいていない」ことが多い行動です。だからこそ、自社の関わり方を一度棚卸しして、無自覚に相手の不満を積み上げていないかを確認する価値があります。継続的なマネジメントの考え方については、業務委託エンジニアのマネジメント方法もあわせて参考にしてください。

継続依頼につなげる契約・更新の設計

「続けたいと思われる発注者」になったうえで、次に必要なのが契約・更新の設計です。多くの発注者がつまずくのが、契約更新を「期限が来てから慌てて確認する」後手の運用になっていることです。

外部エンジニアとの契約は、3〜6ヶ月の準委任契約で都度更新するケースが一般的です。準委任契約とは、成果物の完成ではなく「業務の遂行」そのものに対して報酬を支払う契約形態で、開発の継続的な支援を依頼する場合に適しています。この更新を仕組み化できているかどうかで、継続の安定性は大きく変わります。

更新を後手にしない更新サイクル

更新の話を切り出すのが気まずく、つい後回しにしてしまう——これは多くの発注者が抱える悩みです。しかし、相手側からすれば「次も継続できるのか」が見えない状態は不安そのものであり、その不安が他案件への乗り換えを後押しします。

おすすめは、契約満了の1〜2ヶ月前に更新のすり合わせをルーティン化することです。例えば次のような流れです。

1. 契約満了の2ヶ月前: 「次の期間も継続をお願いしたいと考えています。稼働や進め方で調整したい点はありますか」と早めに意思を伝える
2. 1ヶ月前: 単価・稼働日数・業務範囲を確認し、双方合意のうえで次期契約を確定する
3. 更新後: 新しい契約書を速やかに取り交わす

ポイントは、発注者側から先に「続けてほしい」という意思を示すことです。これにより相手は安心して中長期の見通しを立てられ、わざわざ別案件を探す動機が薄れます。気まずさを避けて後手に回るより、定例の業務として淡々と進めるほうが、結果的に双方にとって楽になります。

稼働日数の柔軟設計で「長く・薄く」関わってもらう

継続を考えるうえで見落とされがちなのが、稼働日数の柔軟性です。

「フルコミットでないと意味がない」と考えてしまうと、相手が他案件との兼ね合いで稼働を下げたいと申し出たときに、関係を切るしかなくなります。しかし、週2〜3日でも長く関わってもらえれば、ドメイン知識は維持され、いざというときに頼れる存在であり続けてくれます。

優秀なエンジニアほど複数案件を並行したいと考えるものです。発注者が稼働日数の調整に柔軟であれば、相手は「この発注者なら自分のペースに合わせてくれる」と感じ、長期的な関係を選びやすくなります。「フルコミットで短期」よりも「適度な稼働で長期」のほうが、トータルで見れば発注者の利益にかなうケースは少なくありません。

フリーランス新法で発注者が守るべき更新・通知ルール

契約・更新の設計を考えるうえで、2024年11月に施行されたフリーランス新法（正式名称: 特定受託事業者に係る取引の適正化等に関する法律）への対応は避けて通れません。この法律は、発注事業者がフリーランスとの取引で守るべき義務を定めたものです（政府広報オンライン「フリーランスが安心して働ける環境づくりのための法律」）。

継続依頼との関係で特に重要なのが、契約終了・不更新に関するルールです。発注事業者は、6か月以上の業務委託を中途解除する場合や更新しないこととする場合は、原則として30日前までに予告することが義務付けられています。また、予告日から契約満了までの間にフリーランスが理由の開示を請求した場合、発注者はその理由を開示しなければなりません。

このほか、発注事業者には次のような義務があります。

• 取引条件の明示: 業務委託をする際、業務内容・報酬額・支払期日などを書面または電磁的方法で明示する
• 報酬の支払期日: 成果物等を受け取った日から60日以内のできるだけ短い期間内に支払期日を設定し、期日内に支払う

継続的に発注する関係だからこそ、これらのルールを最初から仕組みに組み込んでおくことが大切です。法令を守ること自体が、前の章で触れた「事務処理がスムーズで信頼できる発注者」という評価につながり、結果として継続の土台になります。なお、フリーランス新法の詳細や個別ケースの判断については、必要に応じて専門家に確認することをおすすめします。

単価アップ要望・正社員化の打診をどう判断するか

継続フェーズで発注者が最も悩む意思決定が、お金と契約形態に関する判断です。「単価を上げてほしいと言われたが、いくらまでなら妥当なのか」「いっそ正社員になってもらうべきか、それとも業務委託のまま続けるべきか」——こうした判断には、明確な軸を持っておくことが欠かせません。

単価アップ要望への判断軸

単価アップを要望されたとき、感情的に「高い」と感じて拒否するのも、関係を壊したくない一心で言い値を飲むのも、どちらも得策ではありません。判断には次の3つの軸を使います。

1. 市場相場: その人のスキル・経験・職種に対して、要望された単価が市場相場の範囲内かを確認する。フリーランスエンジニアの月額平均単価は74万円前後で、職種・言語によって幅があります（HiPro Tech「ITフリーランスエンジニアの平均月額単価ランキング」）。相場を知っておくことで、要望が妥当かを冷静に判断できます
2. 貢献度: その人が自社にもたらしている価値。ドメイン知識、開発スピード、他メンバーへの波及効果などを含めて評価する。立ち上げ当初より明らかに貢献が増しているなら、単価の見直しには合理性があります
3. 代替コスト: その人が抜けた場合に発生する再採用・再立ち上げのコスト。前の章で見たとおり、このコストは想像以上に大きくなります。単価アップ分が、離脱による損失を下回るなら、応じるほうが合理的です

この3軸で考えると、「いくらまでなら応じるべきか」は感覚ではなく計算の問題になります。要望された単価アップ額が、市場相場の範囲内で、貢献度に見合い、かつ代替コストより小さいなら、応じることが発注者にとって合理的な判断になります。

正社員化を打診すべきケース／業務委託のまま継続すべきケース

「これだけ頼れるなら正社員になってもらえないか」という発想は自然ですが、正社員化が常に正解とは限りません。相手の志向と自社の体制の両面から判断します。

正社員化の打診を検討すべきケース:

• 相手自身が安定した雇用や、より深い組織へのコミットを望んでいる
• その人にフルタイムで担ってほしい役割（チームリード、技術選定の責任者など）が明確にある
• 自社に正社員エンジニアを育成・評価できるマネジメント体制が整っている

業務委託のまま継続すべきケース:

• 相手がフリーランスとしての働き方（複数案件・裁量・柔軟な稼働）を重視している
• 必要な稼働がフルタイムには満たない（週2〜3日で十分など）
• 自社にエンジニアの評価・育成の仕組みがまだなく、正社員化してもミスマッチが起きやすい

重要なのは、正社員化を「囲い込み」の手段として一方的に打診しないことです。フリーランスを選んでいる人にとって、正社員化の打診はかえってプレッシャーになり、関係が硬くなることもあります。まずは相手の志向を率直に聞いたうえで、双方にとって最適な形を一緒に探る姿勢が、結果的に長期の信頼につながります。

稼働拡大を失礼なく打診する伝え方

「もっと当社にコミットしてほしい」と思っても、週2稼働の人に唐突に「週4にしてほしい」と伝えるのは、相手の事情を無視しているように受け取られかねません。稼働拡大を打診するときは、次のような伝え方を意識します。

• 背景と理由を添える: 「プロジェクトが拡大していて、〇〇さんにもっと深く関わってもらえると非常に助かる」と、なぜ依頼するのかを具体的に伝える
• 相手の事情を尊重する: 「他の案件との兼ね合いもあると思うので、難しければ今のままでまったく問題ありません」と、断る余地を残す
• 条件をセットで提示する: 稼働拡大に見合う単価・役割を併せて示し、相手にとってのメリットを明確にする

稼働拡大は「お願い」であって「要求」ではありません。相手が断りやすい余白を残したうえで打診することが、かえって前向きな返事を引き出しやすくします。

長期で深く関わってもらいながら偽装請負を避ける

長く深く関わってもらう関係を築くほど、発注者が見落としがちなのが偽装請負のリスクです。距離が近くなり、まるで社員のように接してしまうことで、知らず知らずのうちに法的にグレーな状態に陥るケースは少なくありません。

偽装請負とは、契約上は業務委託（請負・準委任）でありながら、実態として発注者が労働者のように指揮命令を行っている状態を指します。これは労働関連法令に抵触するおそれがあり、発注者にとって大きなリスクです。長期・密な連携と、適切な線引きを両立させることが、継続関係を健全に保つ鍵になります。

長期案件で偽装請負に陥りやすいNGパターン

長く関わってもらううちに、次のような「うっかり」が起きやすくなります。発注者目線でのチェックリストとして確認してください。

• 朝礼・定例会議への参加を強制する: 社員と同じように出席を義務づけると、指揮命令とみなされやすくなります
• 勤怠を管理する: 始業・終業時刻を指定したり、勤務時間を管理したりするのは雇用関係に近づきます
• 業務を都度細かく指示する: 「次はこれをやって」「この手順で進めて」と逐一指示するのは指揮命令にあたります
• 契約範囲外の業務を当然のように振る: 「ついでにこれも」と、当初の業務範囲を超えた依頼を重ねる
• 席や設備の使用を社員同様に義務づける: 常駐や特定の働き方を強制する

これらはいずれも、「長く一緒にいるから」という気の緩みから生じがちです。関係が深まるほど意識的に線引きを確認する必要があります。指揮命令の範囲については、業務委託エンジニアに頼める業務・出せない指示もあわせてご覧ください。

指揮命令ではなく「成果・情報共有の設計」で密に連携する方法

「では深く関わってもらうにはどうすればいいのか」という疑問が当然湧きます。答えは、指揮命令ではなく、成果と情報共有の設計で連携することです。

具体的には次のようなアプローチが有効です。

• ゴールと成果物で依頼する: 「いつまでに、何を達成してほしいか」を明確にし、進め方は本人に委ねる。これは前の章で触れた「裁量を与える」姿勢とも一致します
• 情報共有の場に招く（参加は任意）: プロダクトの方向性やビジネスの背景を共有する場に、強制ではなく「役立つ情報があれば共有します」という形で関わってもらう。深い理解は密な連携を生みますが、出席義務にはしません
• ドキュメントベースで非同期に連携する: リアルタイムの即レスを求めるのではなく、ドキュメントやチケットで情報を残し、相手が自分のペースで確認できるようにする

深い連携は「拘束」ではなく「情報の豊かさ」で実現できます。背景や意図をしっかり共有された相手は、指示されなくても自社にとって最適な判断をしてくれるようになります。これこそが、偽装請負を避けながら長期で深く関わってもらう、本質的な方法です。

長期化のリスク「属人化」を関係を壊さずに解消する

継続依頼に成功すればするほど、その裏返しとして避けられないのが属人化のリスクです。「その人がいないと誰もコードを触れない」「仕様の理由はあの人しか知らない」——こうした状態は、長期活用の最大の落とし穴です。

ここで多くの発注者が躊躇します。ドキュメント化や引き継ぎ準備を持ちかけると、「自分を切る前提なのか」と相手に不信感を与えてしまうのではないか、と。しかし、属人化対策は進め方しだいで、関係を壊すどころか、むしろ信頼を深める機会になります。

属人化を「相手のため」の文脈で解消する

ドキュメント化の依頼は、伝え方次第で受け取られ方がまったく変わります。「あなたがいなくなっても困らないように」というニュアンスで伝えれば、相手は不安になります。しかし、次のような文脈で伝えれば、むしろ前向きに受け止められます。

• 相手の負担軽減として位置づける: 「〇〇さんに問い合わせが集中して負担になっているので、よくある質問や設計の意図をドキュメントに残しておけば、〇〇さんがいちいち対応しなくて済むようにしたい」
• 業務の一部として正式に依頼する: ドキュメント化を「ついで」ではなく、稼働の一部として正式に依頼し、対価を支払う。無償の追加依頼にしないことが重要です
• 品質向上の取り組みとして共有する: 「チーム全体の開発品質を上げたい」という前向きな目的を共有する

ドキュメント化を相手の負担を減らす取り組みとして位置づければ、属人化対策と良好な関係は両立します。引き継ぎや設計情報のドキュメント化の進め方については、外部エンジニア引き継ぎドキュメントの作り方も参考になります。

サブ人材・引き継ぎ余地を確保しつつ中核人材を不安にさせない設計

ドキュメント化に加えて、中長期的にはサブ人材の確保や引き継ぎ余地の設計も検討したいところです。ただしこれも、中核エンジニアを不安にさせない配慮が欠かせません。

• 増員として位置づける: 「あなたの代わり」ではなく「あなたの仕事が増えているので手を増やす」という文脈で、サブのエンジニアをアサインする
• 中核人材にリードを任せる: 新しく入る人の立ち上げを中核エンジニアに主導してもらい、その役割に対価を払う。これは相手のポジションを高める提案でもあります
• 役割を分担する: 中核エンジニアには重要度の高い領域に集中してもらい、定型的な作業を別の人材に振り分ける

こうした設計は、リスク分散になると同時に、中核エンジニアの負担を減らし、より価値の高い仕事に集中してもらうことにもつながります。属人化対策は「保険」であると同時に、中核人材にとっての「働きやすさの向上」でもあるのです。

よくある質問（FAQ）

Q. 優秀なフリーランスエンジニアに長く続けてもらうには、まず何から始めればいいですか。

まずは自社の関わり方を棚卸しすることから始めてください。支払いは速く確実か、裁量を与えているか、契約範囲外の無償依頼をしていないか、専門性に敬意を払っているか。これらを確認し、改善できる点から手をつけるのが第一歩です。そのうえで、契約満了の1〜2ヶ月前に更新のすり合わせをする習慣を作り、発注者側から「続けてほしい」という意思を早めに伝える仕組みを整えると効果的です。

Q. 単価アップを要望されたら、どこまで応じるのが妥当ですか。

「市場相場」「貢献度」「代替コスト」の3つの軸で判断します。要望された単価が市場相場の範囲内で、その人の貢献度に見合い、かつその人が抜けた場合の再採用・再立ち上げコストよりも単価アップ分が小さいなら、応じることが合理的です。感覚ではなく、この3軸での比較として考えると判断しやすくなります。

Q. 業務委託のまま長期で続けてもらうのと、正社員化、どちらが得ですか。

一概には言えず、相手の志向と自社の体制で判断します。相手が安定雇用や深い組織コミットを望み、自社にフルタイムの役割と育成・評価体制があるなら正社員化を検討する価値があります。一方、相手がフリーランスの働き方を重視し、必要な稼働がフルタイムに満たない場合は、業務委託のまま続けるほうが双方にとって良い結果になりやすいです。まずは相手の希望を率直に聞くことをおすすめします。

Q. 週2〜3稼働の人に、もっと当社にコミットしてほしいと伝えるのは失礼ですか。

伝え方しだいです。「プロジェクトが拡大していて、もっと関わってもらえると助かる」と背景と理由を添え、「他案件との兼ね合いもあると思うので難しければ今のままで問題ない」と断る余地を残し、稼働に見合う単価・役割をセットで提示すれば、失礼にはなりません。要求ではなくお願いとして、相手が断りやすい余白を残して打診することがポイントです。

Q. 長く深く関わってもらうと偽装請負になりませんか。

深い連携と偽装請負は別物です。偽装請負になるのは、勤怠管理・業務の都度指示・会議参加の強制など、発注者が相手を労働者のように指揮命令する場合です。これを避けつつ深く連携するには、ゴールと成果物で依頼して進め方を任せ、情報共有は任意参加とし、ドキュメントベースで非同期に連携することが有効です。深い理解は「拘束」ではなく「情報の豊かさ」で実現できます。

まとめ｜継続依頼は「運」ではなく発注者が設計できる

一度起用したフリーランス・業務委託エンジニアに長く関わってもらえるかどうかは、相手の善意や運で決まるものではありません。発注者が契約・単価・関わり方を意図的に設計することで、継続の確率は大きく高められます。

本記事で整理した打ち手を振り返ります。

• 選ばれ続ける発注者になる: 適正報酬・裁量・敬意・速い支払いを提供し、無償の追加依頼や連絡過多といった無自覚なマイナス行動を避ける
• 更新サイクルを仕組み化する: 契約満了の1〜2ヶ月前に更新をすり合わせ、発注者側から継続の意思を早めに伝える。稼働日数は柔軟に設計し「長く・薄く」を許容する
• 単価・契約形態の判断軸を持つ: 単価アップは「市場相場×貢献度×代替コスト」で、正社員化は「相手の志向×自社の体制」で判断する
• 偽装請負を避けながら深く連携する: 指揮命令ではなく、ゴール・成果物と情報共有の設計で密な関係を築く
• 属人化に先回りする: ドキュメント化やサブ人材確保を「相手のため・負担軽減」の文脈で進め、中核人材を不安にさせない

これらはどれも、特別な才能ではなく「設計」で実現できることです。まずは自社の更新サイクルと、単価アップ要望が来たときの判断軸を見直すところから始めてみてください。中核となる外部エンジニアが安心して長く関わってくれる体制は、IT人材不足が深刻化するこれからの時代において、開発体制そのものを支える大きな資産になります。