フリーランス×アジャイル開発｜発注者が押さえるスクラム運営7つの要点

「ロードマップは詰まっているのに、社員エンジニアの稼働が足りない」「中途採用は半年待ちで、ボードからは外部委託でも構わないから前倒ししろと言われている」——成長期の SaaS や自社プロダクト企業の開発マネージャーであれば、一度はこうした板挟みを経験されたのではないでしょうか。

そこで候補に挙がるのが「フリーランスエンジニアの活用」です。ところが、いざ検討を始めるとすぐに別の不安が頭をもたげてきます。「外部の人を入れたらスプリントの速度が落ちるのではないか」「受託開発に発注したときのように、要件凍結と追加見積もりで疲弊するのではないか」——アジャイル開発を回しているチームほど、外部人材の迎え入れには慎重になりがちです。

結論からお伝えします。フリーランスとアジャイル開発（スクラム）は、契約・体制・コミュニケーション・受入準備の 4 つを発注者が設計しておけば、十分に両立できます。逆に、これらを設計せずに「とりあえず1人入れてみる」と、ほぼ確実にベロシティ（チームの生産速度）が半減します。両者の差は、スキルや相性ではなく「迎え入れ方の設計の有無」にあります。

本記事では、Workee（発注者向けフリーランス活用支援サービス）の現場知見と、IPA（情報処理推進機構）が公開しているアジャイル開発版モデル契約書、情報処理学会（IPSJ）の制度設計論文などの一次資料をもとに、発注者が押さえるべき 7 つの要点を順に解説します。読み終わるころには、社内稟議に持ち込める発注前チェックリストと、契約後 4 週間のロードマップを手に入れた状態を目指します。

フリーランスとアジャイル開発は両立できるのか

最初の疑問にストレートに答えます。条件付きで両立できます。ただし、受託開発のように「丸投げ」した瞬間にスクラムは崩れます。これがこのセクションの結論です。

結論 — 契約と運営を設計すれば両立できる、丸投げすれば崩れる

スクラムの本質は「短いサイクルで小さく作って学ぶ」ことにあります。フリーランスを 1 人迎えただけでこの本質が崩れるわけではありません。実際、アジャイル開発の外部委託で先行する企業の事例では、業務委託エンジニアを既存スクラムチームに迎え入れ、週次同期や完了後のポイント付与といった運用工夫でベロシティを維持している例も公開されています（atama plus・スクラムチームと業務委託エンジニアとの協働で工夫したこと）。

崩れるのは「フリーランスに要件定義から実装、テストまでまとめてお願いし、社員はレビューだけする」といった発注パターンです。これは外形的には準委任契約でも、運営としては受託開発に近く、優先順位の変更や仕様の創発に追従できません。

両立を阻む3つの構造的な壁

両立可能とはいえ、放っておけば崩れるのも事実です。発注者が事前に意識しておくべき構造的な壁は次の 3 つです。

1. 契約期間の短さ: フリーランス契約は 3 カ月単位の更新が一般的です。プロダクトの長期方針を共有する前に契約が切れる、引き継ぎが追いつかないといった問題が起こり得ます。
2. 稼働日数のばらつき: 週 5 日フルコミットのフリーランスもいれば、週 2〜3 日の並行稼働を前提とする方もいます。同じ「業務委託」でもベロシティへの寄与は大きく異なります。
3. スクラムイベント参加の制約: 複数案件を並行するフリーランスにとって、デイリースクラム・プランニング・レビュー・レトロのすべてに固定時間で参加するのは現実的でない場合があります。

これらの壁は、それぞれ「契約形態の設計」「体制設計」「コミュニケーション設計」で解消可能です。本記事の後続セクションで順に扱います。

本記事の進め方

ここから先は、次の順番で 7 つの要点を解説します。

1. アジャイル開発における発注者の役割の再確認（外部化できない責務の切り分け）
2. 契約形態の設計（準委任を基本にする理由）
3. 体制設計（稼働日数・役割配置・チームサイズ）
4. コミュニケーション設計（イベント参加層別整理・SLO・ドキュメント）
5. 発注前の受入準備チェックリスト（社内合意・開発環境・ドキュメント・契約の 4 カテゴリ）
6. 初回スプリント完走までの 4 週間ロードマップ
7. まとめ（設計の問題としての捉え直し）

アジャイル開発における発注者の役割を再確認する

外部人材活用の話に入る前に、もう一度だけ確認しておきたい論点があります。フリーランスを入れても、外部化できない発注者責務があるということです。ここを曖昧にすると、後段の契約論・体制論がすべて「手続きの話」に矮小化してしまいます。

アジャイル開発における発注者の責務（優先順位・Done の定義・受入判断）

スクラムにおいて、発注者（または PO: プロダクトオーナー）が担うべき責務は大きく 3 つです。

• 優先順位の決定: プロダクトバックログのどの項目を次のスプリントに入れるかを判断する
• Done の定義の合意: 何をもって「完成」と見なすかをチームと合意する
• 受入判断: スプリントレビューで実装された機能を受け入れるか、追加で調整するかを判断する

これらは「コードを書く速度」ではなく「意思決定の速度」を司る責務です。発注者がここをフリーランス側に丸投げすると、フリーランス側は推測で優先順位を決めざるを得なくなり、スプリント末に「これじゃない」が頻発します。これがベロシティが半減する典型パターンです。

スプリント速度のボトルネックは「コードを書く速度」より「意思決定の速さ」

経験のある開発マネージャーであれば直感的にご存じだと思いますが、スプリントが詰まる原因の多くは実装速度ではなく、意思決定の遅延です。仕様の確認待ち、レビュー待ち、優先順位の再調整待ち——これらが累積するとベロシティは目に見えて落ちます。

フリーランスを入れた瞬間にベロシティが半減する企業の多くは、実装速度の問題ではなく「外部の人だから確認が必要」「念のため一度持ち帰る」といった意思決定経路の追加によって、判断待ち時間が増えています。外部人材活用で守るべきは、意思決定のスピードを落とさない運営設計です。

外部化できる責務 / できない責務の切り分け

ここまでを表に整理します。

この切り分けが曖昧なまま発注すると、契約形態の議論をいくら詰めても運営は崩れます。次のセクションで「なぜ準委任契約が必要か」を扱いますが、その背景には「外部化できる責務とできない責務を分離するため」という設計意図があります。

フリーランス活用に適した契約形態 — 準委任を基本にする理由

契約形態は競合記事でも頻出のテーマですが、本セクションでは「なぜ準委任か」を スプリント速度の観点 から再構成します。法務的な比較ではなく、運営現場の判断軸として読んでいただきたい部分です。

請負契約がスプリント速度を落とす構造

請負契約は「成果物の完成」に対して報酬を支払う契約です。法的にはシンプルですが、アジャイル開発との相性は本質的に良くありません。理由は次の 3 点です。

• 要件凍結が前提: 請負契約では契約締結時点で成果物の範囲を確定させる必要があります。スプリントごとの優先順位変更や仕様の創発は、原則として契約変更が必要になります。
• 変更見積もりの摩擦: スコープ変更があるたびに見積もり依頼→回答→合意→発注書修正のフローが発生し、スプリント内で完結しません。
• 検収プロセスの硬直化: 検収が成果物単位に紐づくため、スプリント末のインクリメント（部分的にリリース可能な機能）と相性が悪く、検収待ちでベロシティが滞ります。

IPA（独立行政法人 情報処理推進機構）が公開しているアジャイル開発版モデル契約書も、「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としています」と明記しています（情報システム・モデル取引・契約書（アジャイル開発版））。

準委任契約（履行割合型 / 成果完成型）の使い分け

準委任契約は、業務遂行そのものに対して報酬を支払う契約形態です。アジャイル開発と相性が良いのは、スプリントごとの優先順位変更が契約上の摩擦を生まないためです。準委任契約には次の 2 つの類型があります。

フリーランスとの契約では、履行割合型を基本とすることをおすすめします。情報処理学会（IPSJ）の研究グループが発表した制度設計論文でも、発注側企業がアジャイル開発を推進する際の契約スキームとして、履行割合型の準委任契約をベースに据えた制度設計を提案しています（アジャイル開発推進を目的とした発注側企業における準委任契約制度の設計）。

成果完成型は「スプリント末に Done の定義を満たした機能」のような中間成果物に紐づけることも理屈上は可能ですが、Done の定義が変動した際の解釈リスクが残ります。初めてフリーランスを迎え入れるチームは、まず履行割合型でスタートする方が運営の安定性が高くなります。

フリーランスとの準委任契約で確認すべき条項

契約書の細部は法務部門や顧問弁護士に確認いただくとして、発注者が必ず内容を把握しておきたい条項は次のとおりです。

• 成果報告書のフォーマットと提出頻度: 履行割合型準委任では、業務遂行の証跡として成果報告書（または作業報告書）を残します。スプリント単位（2 週間）の提出が一般的です。
• 知的財産権の帰属: 開発したソースコード・ドキュメントの著作権の帰属を明示します。原則は発注者帰属で問題ありませんが、汎用的なライブラリ・既存資産の取り扱いは別途定めることがあります。
• 再委託の可否: フリーランスがさらに別の個人・法人に作業を委託する「再委託」を許容するか、事前承諾を求めるかを明示します。スクラムチームへの参画を前提とする場合は、原則として再委託禁止（または事前承諾必須）にしておく方が認知負荷の管理がしやすくなります。
• 善管注意義務: 準委任契約では、業務を「善良な管理者の注意」をもって遂行することが法的に求められます。請負と異なり成果物の完成義務は負いませんが、専門家としての注意義務は負う、という整理です。

これらは IPA のモデル契約書にも雛形があります。発注時には IPA のモデル契約書をベースに、自社の運営に合わせてカスタマイズするアプローチが現実的です。

偽装請負を回避する指揮命令の整理

準委任契約で発注者が最も気をつけるべきは「偽装請負」のリスクです。準委任契約は、発注者がフリーランスに直接の指揮命令（例: 「今日はこれをやってください」「この時間にこの作業をしてください」）を行わない前提の契約です。発注者が直接指揮命令を行うと、実態として労働者派遣に該当する可能性があり、労働者派遣法違反となります。

スクラムチームに迎え入れる場合の実務上の整理は次のとおりです。

• タスクの依頼は「スプリントバックログ」を経由する: 個別タスクを口頭で指示するのではなく、スプリントプランニングで合意したバックログ項目をフリーランスがプル（自発的に取得）する形にする
• 進捗確認はデイリースクラムなどの場で行う: 1on1 形式で進捗を問い詰める形にせず、チーム全員でのスクラムイベントの場で透明性高く共有する
• 勤務時間・勤務場所の指定をしない: 「9 時に出社」「定時まで在席」といった指示は避ける。スクラムイベントの参加時間は「業務遂行上必要な打ち合わせ時間」として合意する

この整理は、運営の柔軟性と労務リスクのバランスを取るためのものです。詳細は IPA のアジャイル開発外部委託モデル契約解説資料（ブレークモア法律事務所 梅本大祐弁護士・アジャイル開発外部委託モデル契約について）も参考になります。

スクラムチームに外部エンジニアを迎えるための体制設計

契約形態が整っても、体制設計を誤ると速度は維持できません。本セクションでは「稼働日数」「役割配置」「チームサイズ」の 3 つの軸で体制設計の選択肢を整理します。

稼働日数別の現実解

フリーランスの稼働日数は契約で最も柔軟に設計できる項目です。代表的なパターンを整理します。

ここで重要なのは、稼働日数を契約前に明確にし、ベロシティ計画に織り込むことです。「週 3 日のフリーランス」を社員と同じ係数で計画に入れると、スプリント末に未完了タスクが累積します。

迎え入れるロールの選択肢

フリーランスをスクラムチームに迎え入れる際、どのロールで参画してもらうかも設計対象です。

• Developer として迎える: 最も一般的な形。スクラムイベントに参加し、バックログ項目を担当する
• 専門スポット支援として迎える: スクラムイベントには参加せず、特定領域（インフラ・セキュリティ・パフォーマンス改善等）を非同期で支援する
• SM 補佐・PO 補佐として迎える: スクラムマスター経験者やプロダクトマネージャー経験者を、内製チームの SM/PO の補佐として迎える。立ち上げ初期や運営改善期に有効

迎え入れるロールは、フリーランスの経歴・自社チームの弱点・契約期間に応じて決めます。「とりあえず Developer として 1 人入れる」ではなく、ロールごとに期待値を言語化することが速度維持の出発点になります。

チームサイズと認知負荷

スクラムの推奨チームサイズは 2020 年版 Scrum Guide では「通常 10 人以下」とされています。これに対し、外部メンバーの比率が高くなりすぎると、内製チームの認知負荷が急上昇します。経験則として:

• 既存メンバー比 30% まで: 安全圏。オンボーディングを段階的に進められる
• 既存メンバー比 50% 程度: 注意圏。専任のオンボーディング担当を置くべき
• 既存メンバー比 50% 超: チームを分割するか、フェーズを区切って迎え入れる方が安全

「ロードマップが詰まっているから一気に 3 人迎え入れたい」という気持ちは分かりますが、認知負荷を超えた瞬間にチーム全体のベロシティが落ちます。段階的な拡大が結果的には最短距離になります。

完了後ポイント付与によるベロシティ把握の手順

フリーランス参画時にベロシティを把握する実務的な手法として、「完了後のポイント付与」があります。これは、スプリント開始時点でフリーランス担当タスクのポイント見積もりを行わず、スプリント内で完了したタスクに対して事後的にポイントを付与する手法です。前述の atama plus の事例で公開されている工夫の 1 つです。

手順は次のとおりです。

1. スプリント開始時: フリーランス担当のタスクは「ポイント未確定」のままバックログに置く
2. スプリント中: フリーランスがタスクを完了するごとに、内製チームがレビュー時にポイントを後付け（例: 3, 5, 8）
3. スプリント末: 完了タスクのポイント合計をフリーランスのベロシティとして計測
4. 2〜3 スプリント後: 安定したベロシティが見えてきたら、通常通り事前見積もりに切り替える

この方式は、フリーランスの実力把握に必要な 1〜2 スプリントの「見積もりが当たらない期間」を緩衝するためのものです。初回スプリントから事前見積もりを強制すると、見積もりのズレがそのまま運営の混乱に繋がります。

スプリント速度を落とさないコミュニケーション設計

体制が整っても、コミュニケーション設計が崩れるとベロシティはあっさり半減します。本セクションでは、スプリント速度を維持するための運用ルールを整理します。

スクラムイベントの参加層別整理

フリーランスにすべてのスクラムイベントへの固定時間参加を強制すると、複数案件を並行するフリーランスは契約自体を辞退するか、稼働率が極端に下がります。現実的な解は、イベントを 3 層に分けて運用することです。

この 3 層整理を契約前に発注者・フリーランスの間で合意しておくと、運営開始後の認識ズレを大幅に減らせます。

レビュー応答時間と非同期コミュニケーションのルール化

非同期コミュニケーションの最大のリスクは、レビュー応答待ちでベロシティが落ちることです。これを防ぐためには、応答時間 SLO（Service Level Objective）を運用ルールとして明文化することが有効です。例:

• PR レビュー応答時間: 24 営業時間以内に初回コメント。承認まで 48 営業時間以内
• Slack 質問への応答時間: 4 営業時間以内に一次返信（解決でなくてよい）
• 緊急時のエスカレーション経路: PO→ 開発マネージャー→ CTO の順で 1 時間以内

これらを明文化しておくと、フリーランスが「待ち」状態に陥ったときに自発的にエスカレーションできるようになります。

ドキュメント整備（オンボーディング Wiki / ADR / Done の定義）

フリーランスを迎え入れる際、口頭での知識共有に頼るとオンボーディングに 2〜3 週間かかり、その間ベロシティはゼロに近くなります。これを短縮するために、以下のドキュメントを発注前に整備しておくと効果的です。

• オンボーディング Wiki: 開発環境セットアップ、リポジトリ構成、ブランチ戦略、デプロイ手順、主要なコンタクト先
• ADR（Architecture Decision Record）: 過去の主要な技術判断と理由のログ
• Done の定義: スプリント末に「完成」とみなす条件（テストカバレッジ、コードレビュー完了、ドキュメント更新、ステージング動作確認 等）

ドキュメント整備はオンボーディング負荷の軽減だけでなく、属人化リスクの解消にも効きます。フリーランス活用を機にドキュメント整備を進めることは、内製チームにとってもプラスに働きます。

「質問のしやすさ」を仕組みで担保する

最後に見落とされがちな論点が「質問のしやすさ」です。フリーランスは「分からないことを聞きにくい」と感じやすい立場にあります。1 回の質問の遠慮が、24 時間の作業停滞を生むこともあります。

仕組みで担保する方法として:

• 専用質問チャンネル: Slack に #question-onboarding-<freelancer-name> のような専用チャンネルを作る。誰でも回答できる場にすることで、特定の社員の負荷集中を避ける
• オンボーディング期間中の 1on1: 最初の 2 週間は週 2 回、開発マネージャーと 30 分の 1on1 を設定。質問だけでなく「困っていないか」を能動的に確認する
• ペアプロ・モブプロの活用: 初回スプリントは社員エンジニアとのペアプロを 1 タスク含める。コードベース理解と人間関係構築を同時に進める

これらは小さな仕組みですが、初回スプリントの完走率に直結します。

発注前に整える受入準備チェックリスト

ここまでの議論を発注者が「明日動ける」形に落とし込みます。発注前 4 週間でやるべきことを、社内合意・開発環境・ドキュメント・契約の 4 カテゴリ、計 20 項目のチェックリストとして整理します。社内稟議や発注準備の進捗管理にそのまま使えるように設計しています。

社内合意（PO 任命・優先順位整理・期待値合わせ）

• 1. PO（または PO 代理）の任命: フリーランス参画期間中の優先順位決定権限を持つ人物を明示する
• 2. 初回 3 スプリント分の優先順位整理: バックログのトップ 30 項目程度を確定し、Story Point 見積もりを完了させる
• 3. 経営層への期待値合わせ: 「最初の 2 週間はベロシティが落ちる前提」を経営層に共有し、初回 4 週間の評価軸を合意
• 4. 内製チームへの説明: 既存メンバーに「迎え入れの目的・期間・期待ロール」を説明し、オンボーディング担当を任命
• 5. オンボーディング担当の工数確保: 既存メンバーから 1 名を専任のオンボーディング担当に任命し、初回 2 週間で稼働の 30〜50% を割り当てる

開発環境（アクセス権・CI/CD・観測基盤・セキュリティ）

• 6. リポジトリアクセス権の設計: GitHub/GitLab Organization への招待方針、ブランチ保護ルール、PR 承認ポリシーを確定
• 7. CI/CD パイプラインの動作確認: フリーランスが PR を出した際、自動テストが回り、本人が結果を確認できる導線を確保
• 8. 観測基盤の閲覧権限: Datadog / New Relic / Sentry 等のダッシュボード閲覧権限を準備（書き込み権限は段階的に付与）
• 9. 開発環境構築手順の整備: ローカル環境構築のドキュメント（README 含む）を最新化。可能であれば Dev Container 等で再現性を担保
• 10. セキュリティポリシーの明示: 機密情報の取り扱い、本番データの利用可否、VPN/IP 制限の方針を契約前に共有

ドキュメント（オンボーディング Wiki / ADR / Done の定義）

• 11. オンボーディング Wiki の更新: 開発環境セットアップ、リポジトリ構成、ブランチ戦略、デプロイ手順、主要連絡先を最新化
• 12. 主要 ADR の整備: 過去 1 年間の主要な技術判断（フレームワーク選定、DB 設計方針、API 設計方針）をドキュメント化
• 13. Done の定義の明文化: スプリント末の「完成条件」をテキスト化し、フリーランスと事前共有
• 14. コーディング規約・PR テンプレート: lint/formatter 設定、PR テンプレート（変更点・テスト観点・動作確認）を整備
• 15. 既存テストカバレッジの現状把握: フリーランスが手を入れる主要モジュールのカバレッジ・テスト方針を文書化

契約（準委任 SOW・NDA・成果報告書フォーマット）

• 16. NDA（秘密保持契約）の締結: 業務開始前に締結。雛形は法務に確認
• 17. 準委任契約書（SOW 含む）の準備: IPA のアジャイル開発版モデル契約書（情報システム・モデル取引・契約書（アジャイル開発版））をベースに、自社条項をマージ
• 18. 成果報告書フォーマットの確定: スプリント単位の成果報告書（実施タスク・所要工数・課題・次スプリント予定）テンプレートを準備
• 19. 偽装請負回避ガイドの社内共有: 内製チームメンバーに、フリーランスへの直接指示の禁止・スプリントバックログ経由での依頼ルールを共有
• 20. 契約期間と更新条件: 初回契約期間（推奨: 3 カ月）、更新条件（双方合意による更新）、契約終了時の引き継ぎ条項を明示

20 項目すべてを完璧に揃えてから発注する必要はありません。ただし、「社内合意」と「契約」カテゴリは発注前に完了させ、「開発環境」と「ドキュメント」は契約後 1 週間以内に完了させる、という運用が現実的です。

初回スプリント完走までの4週間ロードマップ

最後に、発注者が契約後に何をいつやればよいかを 4 週間の時系列で整理します。初回から大量の課題を渡さず、段階的に拡大すること がスプリント速度維持の鍵です。

Week 0: 受入準備完了の最終確認

契約締結日を Day 0 とします。Week 0 は契約締結直後の 1 週間で、本格稼働の前準備期間です。

• アカウント発行（GitHub Organization、Slack、各種 SaaS）
• NDA の最終確認、SOW の双方押印完了
• オンボーディング Wiki の最終チェック
• 初回プランニングミーティングの日程確定（Week 1 末）
• フリーランス向けの「ようこそ」メッセージ送付（自己紹介、初週の流れ、質問ルートの案内）

このタイミングで前章のチェックリスト 20 項目を再確認します。1 つでも欠けていれば Week 1 のオンボーディングが滞ります。

Week 1: オンボーディングと小タスクでの慣らし

Week 1 は「コードを書く」よりも「環境を理解する」週です。スプリントには参加せず、独立した小タスク（半日〜1 日程度）で慣らします。

• Day 1: キックオフミーティング（30 分）。チーム紹介、コミュニケーションルール、Done の定義の確認
• Day 1-2: 開発環境セットアップ、リポジトリ構成の理解、Wiki の読み込み
• Day 3-4: 小タスク（例: ドキュメント修正、軽微なバグ修正、テスト追加）を 1〜2 件こなす。ペアプロを 1 件含める
• Day 5: 初回 1on1（30 分）、初回プランニングミーティング参加

Week 1 の目標は「コードを書く」ではなく「来週から本格参加できる状態を作る」ことです。ベロシティは事実上ゼロで問題ありません。

Week 2-3: 初回スプリント参加とベロシティ計測

Week 2 から最初の 2 週間スプリントに参加します。

• スプリントプランニングで、フリーランス担当タスクを 通常の半分程度 に抑えて割り当てる
• タスクは「完了後のポイント付与」方式で進める（前述）
• 毎日のデイリースクラムには参加（最初の 2 週間はリアルタイム参加推奨）
• レビュー応答時間の SLO を遵守し、フリーランスが「待ち」にならないよう内製チームが応答を優先
• スプリント末に Velocity を測定。フリーランス担当タスクの完了数・ポイントを記録

Week 3 末のスプリントレビューで、フリーランスのベロシティが見えてきます。この時点での実績ベロシティを Week 4 の判断材料にします。

Week 4: レトロと拡大判断

Week 4 はスプリントレトロスペクティブと、次の 1〜2 カ月の運営方針を決める判断週です。

• スプリントレトロ（60〜90 分）で、フリーランス参画後の運営課題を洗い出す
• 観点例: 質問のしやすさ、レビュー応答時間、ドキュメント不足、スクラムイベント参加の負荷感
• フリーランスとの 1on1 で本人の手応え・改善希望を確認
• 次の 2 カ月の運営方針を決める:
  • 担当タスク量を通常水準まで戻すか
  • 追加のフリーランスを迎え入れるか
  • 担当領域を広げるか、専門領域に絞るか
• 契約更新の判断（初回 3 カ月契約の場合、Week 8 までに次の判断が必要）

このロードマップに沿って進めれば、初回スプリントを完走できないリスクは大幅に下がります。逆に Week 1 を省略して「初回スプリントから本タスクを渡す」アプローチは、よほど経験豊富なフリーランスでなければ失敗します。

まとめ — フリーランス×アジャイルは「設計の問題」である

ここまで、フリーランスを活用したアジャイル開発の進め方を、契約・体制・コミュニケーション・受入準備の 4 軸で解説しました。最後に主張を再整理します。

フリーランスとアジャイル開発の両立は、「相性」の問題ではなく「設計」の問題です。スプリント速度を維持できるかどうかは、フリーランス本人のスキルや内製チームとの相性ではなく、発注者が以下の 4 つを事前に設計しているかで決まります。

1. 契約形態: 履行割合型の準委任契約をベースに、IPA モデル契約書を参考に条項を整える
2. 体制: 稼働日数・ロール・チームサイズを「ベロシティ計画」に織り込んで設計する
3. コミュニケーション: スクラムイベントの 3 層整理・応答時間 SLO・ドキュメント整備で速度を担保する
4. 受入準備: 4 カテゴリ 20 項目のチェックリストを契約前に完了させる

そして、契約後は 初回 4 週間ロードマップに沿って段階的に拡大する ことで、初回スプリントを必ず完走できる状態を作れます。

冒頭の不安に立ち戻ります。「外部人材を入れたら速度が落ちるのではないか」——この問いへの答えは「設計しなければ確実に落ちる、設計すれば維持できる」です。本記事で示した発注前チェックリストと 4 週間ロードマップは、その設計を社内稟議に持ち込み、発注プロセスを動かすための道具立てです。

外部人材活用の意思決定材料をより体系的に整理したい場合は、業務委託エンジニアのマネジメント実践ガイドもあわせてご活用ください。

参考文献・一次資料:

• 情報システム・モデル取引・契約書（アジャイル開発版）｜独立行政法人 情報処理推進機構（IPA）
• アジャイル開発推進を目的とした発注側企業における準委任契約制度の設計｜情報処理学会（IPSJ）
• アジャイル開発外部委託モデル契約について｜ブレークモア法律事務所 梅本大祐 弁護士
• atama plus のスクラムチームと業務委託エンジニアとの協働で工夫したこと｜Zenn