長期のプロダクト開発を、フリーランスや業務委託のエンジニア1〜2名を中核にして回している——そんな企業は少なくありません。立ち上げ期は、優秀な外部エンジニアのスピードと専門性に何度も救われたはずです。ところが1年、2年と続くうちに、別の不安が静かに大きくなってきます。「あの人しか分からない領域」が増え、契約更新のたびに「もし抜けたら、このシステムは誰が触るのか」と冷や汗をかく状態です。
困るのは、続けてほしい気持ちと、依存への不安が同時に存在することです。長く深く関わってもらうほどプロダクトは前に進みますが、その分だけ「その人がいないと止まる」状態に近づいていきます。引き抜きの噂が聞こえたり、稼働を週5から週3に減らしたいと言われたり、社内から「一人に頼りすぎでは」と指摘されたりして、初めて問題の輪郭が見えてくるケースが多いものです。
この不安は、「いい人にもっと長く居てもらう」という関係づくりの努力だけでは解消できません。なぜなら、関係を深めることと依存が深まることは、放っておくと同じ方向に進んでしまうからです。必要なのは、優秀な個人に長く関わってもらいながら、同時にその人が万一抜けてもプロジェクトが止まらない「体制・仕組み」を設計することです。
本記事では、長期プロジェクトでフリーランスエンジニアを継続活用するための体制構築を、発注者の視点から整理します。具体的には、冗長化・知識継承・契約の積み上げ・出口設計という4つの要素に分けて、コストを抑えながら属人化リスクを下げ、長く関わってもらう設計をどう作るかを解説します。精神論ではなく、発注内容や契約として落とし込める打ち手を中心に扱います。
長期プロジェクトでフリーランスエンジニアを継続活用するとき、本当の難所は「依存」
短期のスポット開発であれば、外部エンジニアの活用はシンプルです。決まった機能を作ってもらい、納品されたら関係はいったん区切られます。ところが長期プロジェクトでは事情が変わります。同じ人に半年、1年と関わってもらううちに、その人はプロダクトの設計思想・過去の意思決定の経緯・運用上の落とし穴まで、ドキュメントに残らない暗黙知を大量に抱えるようになります。
立ち上げを越えた長期活用で起きる「依存の罠」
ソフトウェア開発の現場には「バス係数（トラックナンバー）」という言葉があります。「何人のメンバーが突然いなくなったらプロジェクトが立ち行かなくなるか」を表す指標で、この数字が小さいほどリスクが高い状態を指します。中核を外部エンジニア1人に任せきっている長期プロジェクトは、まさにバス係数が1の状態です。その人が病気・家庭の事情・他社からの引き抜きなど、どんな理由であれ抜けた瞬間に、誰も触れないシステムだけが残ります。
やっかいなのは、この依存が「成功の副作用」として静かに進むことです。優秀なエンジニアほど一人で広い範囲をこなせてしまうため、立ち上げのスピードは上がります。しかしその裏で、知識とコードがその人に集中していきます。気づいたときには、引き継ぎを依頼する時間さえ惜しいほど開発が詰まっており、「依存しているのは分かっているが、いま手を打つ余裕がない」という袋小路に入っているのです。
依存はリスクだけでなく、交渉力の問題も生みます。「この人に抜けられたら困る」という状態は、単価交渉や稼働調整の場面で発注者を弱い立場に置きます。続けてほしい気持ちが、いつのまにか「続けてもらわないと困る」という従属に変わってしまうのです。
継続活用と個人依存からの脱却は両立できる——本記事の前提
ここで強調したいのは、「継続活用」と「個人依存からの脱却」は相反するものではない、ということです。優秀なエンジニアに長く関わってもらうことと、その人がいなくても回る体制を作ることは、同時に追求できます。
両立の鍵は、長期活用を「いい人に長く居てもらう関係づくり」だけで解こうとしないことです。関係づくり——適正な単価、感謝の伝え方、契約更新の安心感——は確かに重要で、これは別の論点として「フリーランスエンジニアの継続依頼術」で詳しく扱っています。本記事はその"次の問い"、すなわち「優秀な人に長く関わってもらいながら、その人への依存リスクをどう構造で減らすか」に焦点を当てます。関係づくりが「居てもらう力」だとすれば、本記事が扱うのは「抜けても止まらない力」です。両方そろって初めて、長期プロジェクトは安定します。
長期で継続活用される体制と、止まる体制の違い
依存を減らすといっても、何から手をつければいいのか分からない——これが多くの発注者の本音でしょう。まずは、長く回る体制と、いつか止まる体制が何によって分かれるのかを整理します。
止まる体制の典型3パターン
長期プロジェクトが中核エンジニアの離脱で止まってしまう体制には、共通する型があります。
1つ目は「都度更新の積み重ねだけ」型です。3ヶ月の準委任契約を、特に設計もないまま機械的に更新し続けている状態を指します。契約は積み上がっているのに、長期を見据えた取り決め（知識を残す約束・離脱時の引き継ぎ・複数人体制への移行計画）が何もありません。更新のたびに不安だけが繰り返されます。
2つ目は「1人に全権集中」型です。設計判断・実装・インフラ・運用対応のすべてを1人が担い、他に状況を把握している人が社内外を問わず誰もいない状態です。本人の能力が高いほど、この集中は進みやすくなります。
3つ目は「ドキュメント不在」型です。コードは動いているが、なぜその設計にしたのか、どう環境を構築するのか、障害時に何を見ればよいのかが、すべて本人の頭の中にしかない状態です。引き継ごうにも引き継ぐ材料がありません。
長く回る体制を構成する4要素
これらの「止まる体制」を裏返すと、長く回る体制を構成する要素が見えてきます。本記事では、以下の4つの要素として整理します。これが記事全体の地図になります。
- 冗長化: クリティカルな領域を1人に集中させず、もう一人が把握できる状態を作る
- 知識継承: 暗黙知をドキュメント・記録として残し、人が入れ替わっても引き継げるようにする
- 契約の積み上げ: 都度更新を「長期前提の更新サイクル」に組み替え、双方の安心と継続性を担保する
- 出口設計: 離脱はいつか必ず起きる前提で、揉めずに引き継ぐ仕組みを最初から織り込む
この4つは独立した打ち手ではなく、互いに支え合います。たとえば知識継承が進んでいれば冗長化のコストは下がり、出口設計があれば離脱の予兆が出ても慌てずに済みます。次の章から、それぞれを発注実務に落とし込んでいきます。
自社の「依存度」セルフチェック
打ち手に入る前に、自社の現状を診断してみましょう。以下に当てはまる項目が多いほど、依存度が高い状態です。
- 中核エンジニアが1週間連絡不能になったら、本番障害に対応できる人が社内外にいない
- 開発環境を一から構築する手順が、本人以外に分からない
- 「なぜこの設計にしたか」を説明できるのが本人だけ
- 契約は都度更新で、長期の取り決めや引き継ぎの約束がない
- その人の稼働が減ったり抜けたりする想定を、一度も具体的に話し合ったことがない
3つ以上当てはまるなら、いまが手を打つタイミングです。すべて当てはまる場合は、バス係数1の典型であり、優先的に着手する価値があります。
冗長化——「2人目」をいつ・どう入れるか
個人依存を解く最初の打ち手は、人を増やす——冗長化です。とはいえ「2人目を入れればいい」と言われて素直に動けないのが現実でしょう。コストは確実に増え、社内に「なぜ余分に人を入れるのか」を説明しきれない。この障害を越えるには、冗長化を「全か無か」で考えないことが重要です。
全領域ではなく「クリティカルパス」から二重化する
冗長化のコストが重く感じられる最大の理由は、「中核エンジニアと同じことを全部できる2人目」をイメージしてしまうからです。それはほぼ二重のコストであり、現実的ではありません。
発想を変えて、まず「ここが止まったらプロジェクト全体が止まる」というクリティカルパスを特定します。多くのプロダクトでは、それは決済まわり・認証基盤・本番インフラ・データベース設計といった、限られた領域に集中しています。機能の8割は止まっても致命傷にはなりませんが、この2割は誰も触れなくなった瞬間に事業が止まります。
冗長化はこのクリティカルな2割から始めます。具体的には、その領域の設計と運用を、中核エンジニアともう一人（社内エンジニアでも、新たに加わる外部エンジニアでもよい）が両方理解している状態を作ります。全領域ではなく急所だけを二重化することで、コストを抑えながら「突然死」のリスクだけを先に潰せます。
2人目を入れる損益分岐の考え方
「費用対効果が見えない」という社内説明の壁は、停止リスクを期待値で考えると越えやすくなります。
考え方はシンプルです。中核エンジニアが抜けて誰も引き継げなかった場合に発生するコストを見積もります。これには、新しいエンジニアがゼロから現状を把握して開発を再開できるまでの「再立ち上げ期間」と、その間プロダクトの改善が止まることによる「機会損失」が含まれます。長期プロジェクトでは、この再立ち上げに数ヶ月かかることも珍しくありません。
この「抜けたときに発生しうる損失」に、それが起きる確率（更新のたびに離脱の不安を感じている時点で、決して低くはありません）を掛け合わせたものが、依存を放置した場合のリスクの期待値です。これと、2人目を入れる追加稼働費を比べます。多くの長期プロジェクトでは、クリティカルパスに限定した冗長化の費用は、突然死の期待損失を大きく下回ります。この比較を数字で示せれば、社内説明は精神論から投資判断に変わります。
稼働を増やさず冗長化する運用
2人目を「フルタイムでもう一人」と考える必要はありません。稼働を大きく増やさずに冗長性を高める運用がいくつもあります。
ひとつは相互レビューの仕組み化です。クリティカルな変更は必ずもう一人がコードレビューを通す運用にすれば、レビュアーは自然とその領域の知識を蓄積していきます。レビューに必要な時間は実装ほど大きくありません。
もうひとつはサブ担当の設定です。クリティカル領域ごとに「主担当」と「副担当」を決め、副担当には月数時間でもよいので定期的にその領域に触れてもらいます。完全な代替はできなくても、いざというとき「ゼロから」ではなく「ある程度分かっている状態から」引き継げる差は大きいものです。
新たに外部エンジニアを加える場合は、参画初期にどう既存チームへ溶け込んでもらうかが成否を分けます。この点は「副業エンジニアのチーム統合」で、正社員と外部メンバーが混在する体制の日常運営は「正社員×フリーランス混在チームの運営方法」で詳しく扱っています。
知識継承——属人化を「発注内容」として設計する
冗長化と並ぶもう一つの柱が、知識継承です。ここで多くの発注者がぶつかるのが、「引き継ぎドキュメントを作ってもらう時間を発注すると、その分だけ機能開発が止まる」というジレンマです。目の前の機能開発を優先すると、知識はずっと本人の頭の中に残り続けます。
ドキュメント整備を稼働に含める発注設計
このジレンマの根本原因は、ドキュメント整備を「機能開発が一段落したらやる、おまけの作業」として扱っていることです。おまけである限り、忙しい長期プロジェクトでは永遠に後回しになります。
解決策は、ドキュメント整備を最初から稼働の一部として発注契約に織り込むことです。たとえば「実装した機能について、設計判断の理由と運用手順を残すところまでを1つの作業単位とする」と取り決めておけば、ドキュメントは機能開発と切り離せない発注内容になります。月の稼働のうち1〜2割を知識を残す作業に充てると最初から合意しておくのも有効です。
これは追加コストに見えますが、先ほどの損益分岐の観点で考えれば、突然死の期待損失を継続的に下げ続ける投資です。後からまとめて引き継ぎを依頼するより、日々少しずつ残すほうが、本人の記憶が新しく質も高くなります。
抜けても回るために残すべき情報の優先順位
「ドキュメントを作って」と漠然と頼んでも、何を残せば抜けても回るのかが曖昧だと形骸化します。優先順位をつけて、効果の高いものから残してもらいましょう。
- 環境構築・デプロイ手順: 新しいエンジニアが開発を始め、本番に反映できるまでの一連の手順。これがないと引き継ぎが一歩も進みません。最優先です。
- 運用ランブック（障害対応手順）: 本番で何かが起きたとき、どこを見て、何をすればよいか。事業の継続性に直結します。
- 設計判断の理由（意思決定ログ）: なぜこのアーキテクチャ・このライブラリを選んだのか。コードを読めば「何をしているか」は分かりますが、「なぜそうしたか」は本人にしか分かりません。将来の改修で同じ落とし穴を避けるために重要です。
- オンボーディング資料: 次に入る人が全体像をつかむための見取り図。
すべてを完璧に揃える必要はありません。この優先順位の上から着手するだけで、バス係数1の最悪の状態からは確実に抜け出せます。
非エンジニアの発注者でも引き継ぎを受け取れる工夫
社内に技術を理解できる人がいない場合、ドキュメントが本当に役立つものになっているかを発注者自身で判断できない、という問題があります。
完璧な検証は難しくても、いくつか工夫の余地があります。ひとつは、重要な設計や手順を口頭で説明してもらう場を録画で残すことです。文章になりにくい暗黙知も、話してもらえば残せますし、次に入るエンジニアにとっては文章以上に理解の助けになります。もうひとつは、新しく加わったエンジニアやレビュー担当に「このドキュメントだけを見て作業を再現できるか」を実際に試してもらうことです。再現できれば、そのドキュメントは引き継ぎに耐える品質だと分かります。発注者が中身を技術的に評価できなくても、「再現できたかどうか」という結果で品質を確認できるのです。
契約の積み上げ——準委任の都度更新を「長期前提」に組み替える
冗長化と知識継承を支えるのが、契約の設計です。3ヶ月ごとの準委任契約をただ機械的に更新しているだけでは、長期の取り決めは積み上がらず、発注者も外部エンジニアも互いに不安定なままです。
都度更新を「長期前提の更新サイクル」に変える
都度更新そのものが悪いわけではありません。問題は、更新が「次もお願いします／分かりました」の繰り返しで終わり、長期を見据えた合意が乗っていないことです。
更新のサイクルを、関係を積み上げる機会として設計し直しましょう。たとえば3ヶ月ごとの更新時に、次の期間で「どのクリティカル領域の知識継承を進めるか」「冗長化をどこまで進めるか」を毎回1つずつ合意していく、といった具合です。こうすると、更新を重ねるたびに体制が少しずつ強くなり、契約の積み上げが文字通り「体制の積み上げ」になります。同時に、長期前提であることを互いに確認できれば、外部エンジニアにとっても見通しが立ち、安心して関わり続けられます。
なお、月額固定で開発パートナーと継続的に組む契約形態など、準委任以外の選択肢もあります。プロジェクトの性質に応じた契約形態の比較は「月額制開発とSIerの違い」も参考になります。
フリーランス新法を踏まえた契約継続・終了の予告設計
長期前提で契約を積むうえで、押さえておきたいのが2024年11月1日に施行された「フリーランス・事業者間取引適正化等法」（通称フリーランス新法）です。
この法律では、6ヶ月以上の業務委託を発注事業者の都合で中途解除または不更新とする場合、原則として30日前までに書面・電子メール等で予告する義務が定められています。また、フリーランスから理由の開示を請求された場合は、これに応じる必要があります（政府広報オンライン、中小企業庁の法律パンフレット）。
これは一見すると発注者の制約に見えますが、長期前提の体制づくりにはむしろ追い風です。30日前予告という枠組みがあることで、双方が「いきなり関係が切れる」ことを前提にしなくてよくなります。発注者側から見れば、相手の離脱にも一定の予告期間が見込める関係を築くことが、引き継ぎ期間の確保につながります。法律が定める最低限の予告を、自社の出口設計（後述）の起点として活用するとよいでしょう。
準委任のまま偽装請負・指揮命令の線を越えない
長期で深く関わってもらうほど、外部エンジニアを社内メンバーのように扱いたくなりますが、ここには注意が必要です。準委任・業務委託の形をとりながら、発注者が外部エンジニアに対して労働者のような直接の指揮命令を行っていると、実態は労働者派遣とみなされ、偽装請負と判断されるおそれがあります。偽装請負と認定されると、発注者側にも罰則が及ぶ可能性があります（偽装請負の判断基準・BUSINESS LAWYERS）。
ポイントは「誰が、どこまで指示しているか」です。「いつ何時間働くか」「どういう手順で作業するか」といった働き方そのものを細かく指示・管理するのは、偽装請負のリスクを高めます。一方、「何を・いつまでに・どんな品質で」という成果や要件を伝え、進め方は相手の裁量に委ねる関係であれば、適正な業務委託の範囲に収まりやすくなります。
長期で継続活用する場合ほど、この線引きを意識的に守ることが大切です。成果ベースで任せる関係は、偽装請負を避けられるだけでなく、相手の専門性を活かし、他案件との両立にも配慮した持続可能な関係につながります。長期だからといって専属を強要せず、月の最低稼働枠を確保しつつ相手の柔軟性を尊重する姿勢が、結果として継続性を高めます。
出口設計——中核が抜けるときに揉めずに引き継ぐ
最後の要素は、出口設計です。これまでの3要素（冗長化・知識継承・契約の積み上げ）を進めても、人はいつか抜けます。重要なのは、離脱を「起きてはいけない事故」ではなく「いつか必ず起きること」として最初から設計に織り込むことです。
離脱は前提——予兆を早期に捉える
中核エンジニアの離脱には、たいてい予兆があります。稼働を減らしたいという相談、返信のテンポが落ちる、新しい技術への関心が薄れる、他案件の話が増える——こうしたサインは、関係が切れる前の貴重な準備期間の合図です。
予兆を「困った話」として身構えるのではなく、「引き継ぎを始めるタイミング」として受け止めることが大切です。冗長化や知識継承が日頃から進んでいれば、予兆が出た時点で慌てる必要はありません。むしろ、関係が良好なうちに引き継ぎを進めるほうが、本人も協力的で、引き継ぎの品質は高くなります。
引き継ぎ期間を契約に織り込む
離脱が決まってから引き継ぎを依頼するのでは遅い、というのはよくある失敗です。引き継ぎは、契約の中にあらかじめ織り込んでおきましょう。
たとえば契約に「終了または不更新の際は、一定期間を引き継ぎ作業に充てる」と定めておけば、離脱時の引き継ぎが当然の前提になります。先述のフリーランス新法による30日前予告の枠組みは、この引き継ぎ期間を設計する自然な起点になります。予告から終了までの期間を、後任への引き継ぎ・ドキュメントの最終整備・残課題の洗い出しに充てる流れを、契約と運用の両面で準備しておくとよいでしょう。引き継ぎの完了をもって契約終了とする、という受け入れ条件を設けておくのも有効です。
関係を壊さずに属人化を解いていく進め方
属人化の解消というと、本人に「あなたへの依存を減らしたい」と切り出すようで、関係を悪くしないか不安に感じるかもしれません。しかし、伝え方次第で、これはむしろ信頼を深める取り組みになります。
ポイントは、「あなたを外したい」ではなく「あなたが安心して休めたり、他のことに集中できたりするために、チームとして支える体制を作りたい」という文脈で進めることです。優秀なエンジニアほど、一人にすべてが集中している状態の危うさを理解しています。冗長化・知識継承を「本人の負担を減らし、プロジェクト全体を強くする取り組み」として一緒に進めれば、本人も協力しやすくなります。属人化の解消は、本人を信頼しなくなることではなく、その人がいてもいなくてもプロダクトが続く——つまり長く健全に付き合える関係を作ることなのです。
なお、「抜けてほしくない、もっと続けてほしい」という関係づくりの側の打ち手は、本記事とは別軸として「フリーランスエンジニアの継続依頼術」で扱っています。出口設計と関係づくりは矛盾せず、両方そろって初めて長期プロジェクトは安定します。
まとめ——長期活用は「依存」ではなく「設計」で続ける
長期プロジェクトでフリーランスエンジニアを継続活用するとき、本当の難所は「特定個人への依存」でした。続けてほしい気持ちと、依存が深まるほど高まる突然死リスク・交渉力低下のジレンマは、関係づくりだけでは解けません。必要なのは、依存リスクを構造で減らす体制設計です。
本記事では、その体制を4つの要素として整理しました。
- 冗長化: クリティカルパスから段階的に二重化し、停止リスクの期待値で投資判断する
- 知識継承: ドキュメント整備を「おまけ」ではなく発注内容に織り込み、抜けても回る情報を優先順位をつけて残す
- 契約の積み上げ: 都度更新を長期前提の更新サイクルに変え、フリーランス新法を踏まえつつ偽装請負の線を越えない
- 出口設計: 離脱を前提に、引き継ぎ期間を契約に織り込み、関係を壊さずに属人化を解いていく
今日から着手するなら、まず自社の依存度をセルフチェックし、クリティカルパスを1つ特定してその二重化に手をつける。そして次の契約更新時に、ドキュメント整備を稼働に含める合意を1つ加える——この小さな一歩から始められます。
長期での継続活用は、優秀な個人への依存によってではなく、発注者が設計する仕組みによって実現します。中核エンジニアに長く関わってもらいながら、その人が万一抜けても止まらない体制を持つこと。この両立こそが、長期プロジェクトを突然死リスクから解放し、外部人材活用を持続可能なものにします。
