アジャイル開発に外部エンジニアを組み込む方法｜スプリント参加と契約の設計

「スプリントが計画どおりに消化できず、次の四半期のロードマップに遅れが見え始めた」——自社でスクラムを回している開発責任者の方なら、一度はこの危機感を抱いたことがあるのではないでしょうか。正社員の採用は半年単位で時間がかかり、目の前のリリースには間に合いません。そこで現実的な選択肢として浮かぶのが、外部フリーランスエンジニアを業務委託で1〜2名足して開発速度を上げる、という打ち手です。

ただ、ここで多くの担当者が足を止めます。「正社員とは前提が違う外部人材を、スプリントのどのセレモニーに、どこまで、どう関わらせれば、せっかく定着しかけたチームのリズムを壊さずに済むのか」。この判断基準が見当たらないからです。さらに、準委任契約での指揮命令の線引き、いわゆる偽装請負のリスクへの不安も重なり、「増員すべきなのは分かっているのに、最初の一歩が踏み出せない」という状態に陥りがちです。

外部エンジニアの組み込みが難しいのは、「契約」の問題と「スプリント運用」の問題が別々の記事で語られ、自社のチームに当てはめると両者が矛盾してしまうように見えるからです。準委任契約の解説を読んでも具体的なセレモニーの回し方は分からず、スクラム運用の記事を読んでも偽装請負の地雷には触れられていない、というギャップが残ります。

本記事では、この2つを1本につなげて整理します。まず外部エンジニアを足したときの典型的な失敗パターンを起点に、「関わり方のタイプを決める→各セレモニーへの参加を設計する→タスクの渡し方を決める→契約とコミュニケーションの地雷を避ける」という意思決定の流れに沿って、発注担当者が自社のスクラムチームにそのまま当てはめられる判断軸を提示します。読み終えたときに「うちのチームならこう組み込む」という設計図を、自分の言葉で描ける状態を目指します。

外部フリーランスエンジニアをアジャイル開発のスプリントに組み込む3つの失敗パターン

外部エンジニアの組み込みを設計する前に、まず「何が起きると失敗なのか」を言語化しておきましょう。失敗の形が見えていれば、各設計判断が「どの失敗を防ぐためのものか」を意識しながら進められます。よくある失敗は、大きく次の3つに集約されます。

失敗1: 役割と任せる範囲が曖昧で、ベロシティが読めなくなる

「とりあえず人手が増えれば速くなるだろう」と曖昧なまま参加してもらうと、外部エンジニアがどのタスクを・どの粒度で担うのかが定まりません。結果として、既存メンバーが「あの人に何を頼めるのか」を毎回考えることになり、スプリントプランニングでの見積もりが安定しません。チームの開発速度（ベロシティ）が読めなくなれば、ロードマップの遅れを取り戻すどころか、計画の精度そのものが落ちてしまいます。

失敗2: スプリント途中で稼働が落ち、成果物が宙に浮く

フリーランスエンジニアは複数の案件を並行していることが多く、稼働が週3日や時間単位というケースも珍しくありません。この稼働実態を踏まえずに正社員と同じ前提でタスクを割り当てると、スプリントの後半で「着手したが完了していない」タスクが積み上がります。中途半端な成果物はレビューもマージもできず、次のスプリントに持ち越され、チーム全体のリズムを乱します。

失敗3: コミュニケーションコストが増え、既存メンバーの生産性まで下がる

外部エンジニアはプロダクトの背景やコードベースの文脈を持っていません。そのため初期は質問が増え、既存メンバーが回答に時間を取られます。これ自体は当然のコストですが、窓口や情報共有の仕組みを決めずに始めると、特定のメンバーに質問が集中し、その人の開発が止まります。「人を増やしたのに、チーム全体の生産性はむしろ下がった」という事態は、ここから生まれます。

なぜ正社員と同じ入れ方では失敗するのか

これら3つの失敗には共通の根があります。それは「外部人材を正社員と同じ前提で入れてしまう」ことです。正社員であれば、稼働はフルタイムが前提で、プロダクトの背景知識は研修やオンボーディングを通じて時間をかけて共有でき、役割が多少曖昧でも周囲が補い合えます。しかし外部エンジニアは、稼働が限定的で、関わる期間も有限で、契約上「自律的に業務を遂行する独立した事業者」という立場にあります。

この前提の違いを無視して「チームの一員なのだから、正社員と同じように何でも頼もう」とすると、稼働のミスマッチ（失敗2）も、役割の曖昧さ（失敗1）も、コミュニケーションの属人化（失敗3）も、すべて噴き出します。外部エンジニアの組み込みとは、「正社員のコピーを増やすこと」ではなく、「限定された稼働と独立した立場という制約のもとで、最大の成果を引き出す設計をすること」だと捉え直す必要があります。

失敗を分ける本質は「契約」ではなく「スプリントへの関わらせ方の設計」

外部人材の活用というと、まず「準委任か請負か」という契約の話に意識が向きがちです。契約形態の選択はもちろん重要で、本記事の後半でも詳しく扱います。しかし、失敗するチームと成功するチームを分ける本質は、契約書の種類そのものではありません。

本質は「スプリントへの関わらせ方をどこまで具体的に設計したか」にあります。どのセレモニーに参加してもらい、どの粒度のタスクを渡し、誰が窓口になり、日々の進め方の判断は誰が持つのか。この運用設計が明確であれば、それはそのまま偽装請負を避ける設計（後述する「自律的な業務遂行」の確保）にもつながります。逆に運用設計が曖昧なまま契約形態だけ整えても、現場では失敗1〜3が起きます。

つまり、契約と運用は別々の論点ではなく、「関わらせ方の設計」という1本の軸でつながっています。次の章からは、この設計を「関わり方のタイプ→セレモニー参加→タスクの渡し方→契約・コミュニケーション」という順番で、具体的に組み立てていきます。

組み込む前に決める「外部エンジニアの3つの関わり方タイプ」

設計の第一歩は、外部エンジニアに「どのくらいの深さでスプリントに関わってもらうか」を決めることです。ここを最初に決めておくと、後続のセレモニー参加やタスクの渡し方の判断がすべてここから導けます。関わり方は、稼働日数とタスクの調整難易度を軸に、次の3つのタイプに整理できます。

3類型の比較（稼働日数・任せるタスク粒度・向いている案件）

このように整理すると、「うちは週3稼働で機能追加を任せたいからB型だ」「専門領域の調査だけお願いしたいからC型だ」と、自社の状況を1つのタイプに当てはめられます。重要なのは、稼働日数とタスクの独立性を見て、最初にタイプを1つ選ぶことです。タイプが決まれば、参加してもらうセレモニーもタスクの渡し方も、おのずと方向性が定まります。

週3以下の稼働ならどう設計するか

実務で最も多く、かつ最も悩ましいのが「稼働が週3日以下のフリーランスをスクラムチームに入れたい」というケースです。スクラムはデイリースクラムを毎営業日に開く前提で設計されているため、週3稼働のメンバーは構造的に「出ない日」が生まれます。

スクラムチームと業務委託エンジニアの協働事例を公開している atama plus の知見でも、週3稼働のメンバーが全セレモニーにフル参加するのは現実的でなく、参加するセレモニーを取捨選択する工夫が必要だったことが語られています（atama plusのスクラムチームと業務委託エンジニアとの協働で工夫したこと）。ここから一般化できる設計の指針は、次の3点です。

• 稼働日に必ずデイリーが当たるようにする：週3稼働なら、その3日のいずれかにチームのデイリーが重なるよう曜日を調整します。出社日（稼働日）とデイリーの開催曜日をずらさないだけで、情報の取り残しが大きく減ります。
• 担当タスクを「その人の稼働内で完結する粒度」に切る：週3稼働の人に、5日かかるタスクをスプリント内で渡すと必ず宙に浮きます。稼働日数からの逆算でタスクの大きさを決めるのが、B型・C型設計の肝です（タスクの渡し方は後述します）。
• 非同期のコミュニケーション手段を整える：出ない日の情報共有は、デイリーの議事メモやチャットのスレッドで非同期に追えるようにします。これは同時に「特定メンバーへの質問集中」を防ぐ仕組みにもなります。

つまり、週3以下の稼働は「B型（プランニングとデイリーには入ってもらう）」または「C型（スプリント外で独立タスクを処理してもらう）」を基本とし、フル参加を前提とするA型は避ける、という判断になります。

スプリントの各セレモニーに外部エンジニアをどう参加させるか

関わり方のタイプが決まったら、次はスクラムの各セレモニーに「参加してもらう／任意にする／参加しなくてよい」を1つずつ決めていきます。ここが、冒頭で挙げた裏テーマ「どのセレモニーに・どこまで関わらせるか」に直接答える、本記事の中核です。全セレモニーに何となく呼ぶのでもなく、実装だけ頼んで孤立させるのでもなく、各セレモニーの目的に照らして要否を判断します。

必ず入ってもらうべきセレモニー（プランニング・デイリー）

タイプを問わず、外部エンジニアに原則として参加してもらうべきなのはスプリントプランニングとデイリースクラムです。理由は、この2つが「何を・どの優先順位で・どこまで終わらせるか」というスプリントの土台を共有する場だからです。

スプリントプランニングは、外部エンジニアが今スプリントで何を担当するのかを本人が理解し、見積もりに参加する場です。ここに入ってもらわないと、担当範囲が「誰かが決めて渡したもの」になり、当事者意識も見積もり精度も上がりません。失敗1（役割と範囲の曖昧さ）を防ぐ最初の関門が、このプランニングへの参加です。なお、外部エンジニアに「やってもらうこと」を直接指示するのではなく、プロダクトバックログの優先順位を示したうえで、担当範囲は本人を含めたチームで合意する形にする点が重要です（この点は契約の章で詳しく扱います）。

デイリースクラムは、進捗の同期と障害（ブロッカー）の早期発見の場です。外部エンジニアが「着手したが詰まっている」状態を抱え込むと、失敗2（成果物が宙に浮く）に直結します。デイリーで状況を共有してもらえれば、ブロッカーを早期に解消でき、スプリント後半の持ち越しを減らせます。ただし、稼働日の都合で毎日は出られない場合、デイリーへの参加は「稼働日には必ず出る」を基準にし、出ない日は非同期で情報を追える形にします。

任意で良い／外しても良いセレモニー（レトロ・リファインメント）

一方で、参加を必須とまではしなくてよいセレモニーもあります。代表がスプリントレトロスペクティブとプロダクトバックログリファインメントです。

レトロスペクティブは、チームの働き方そのものを振り返り改善する場です。チームの一員として中長期で関わるA型なら参加してもらう価値がありますが、稼働が限定的なB型・C型では「参加は任意」とするのが現実的です。レトロはチーム文化や人間関係に踏み込む話題も出るため、短期で関わる外部メンバーが無理に同席する必要はありません。ただし、レトロで決まった「外部メンバーとの協働で改善すべき点」は、後で本人に共有する流れを作っておくとよいでしょう。

リファインメントは、将来のスプリントに向けてバックログを精緻化する場です。外部エンジニアが担当する見込みの領域に関わる項目を扱う回には参加してもらうと見積もり精度が上がりますが、毎回フル参加は不要です。「自分が担当する可能性が高いテーマのリファインメントだけ参加する」という選択的な関わり方が、稼働効率の面でも合理的です。

セレモニー参加 早見表（関わり方タイプ × セレモニー）

ここまでの判断を、関わり方タイプ別に一覧化したのが次の早見表です。自社で選んだタイプの行を見れば、各セレモニーへの参加方針が一目で分かります（◎＝必須、○＝推奨、△＝任意・選択的、−＝原則不要）。

なお、スプリントレビュー（完成した成果物をステークホルダーに見せ、フィードバックを得る場）は、自分が作ったものがどう評価されるかを本人が知る機会として、B型でも自分の成果物が対象の回には参加してもらうと、品質と当事者意識の両面で効果があります。

この早見表は出発点であり、絶対的なルールではありません。チームの成熟度や外部エンジニアの関わる期間に応じて調整してください。大切なのは、「何となく全部呼ぶ／実装だけ頼む」ではなく、各セレモニーの目的に照らして意図的に参加方針を決めることです。

外部エンジニアへのタスクの渡し方と期待値設定

セレモニーへの参加方針が決まったら、次は「実際にどうタスクを渡すか」です。ここがうまくいかないと、プランニングに参加してもらっても失敗1（範囲の曖昧さ）や失敗2（成果物が宙に浮く）が再発します。外部エンジニアへのタスクの渡し方には、正社員に渡すとき以上に「明文化」と「立ち上がりの見極め」が求められます。

渡すタスクの粒度と「完了の定義」を明文化する

外部エンジニアに渡すタスクは、「他タスクへの依存が少なく、その人の稼働内で完結できる粒度」に切るのが原則です。前述のとおり、週3稼働の人に5日かかるタスクを渡せばスプリント内に終わりません。稼働日数から逆算し、1スプリント内で確実に閉じられる大きさに分割します。機能単位・画面単位など、担当範囲が他メンバーと重ならない切り方ができると、コミュニケーションコスト（失敗3）も最小化できます。

さらに重要なのが、完了の定義（Definition of Done）を明文化して渡すことです。正社員であれば「うちのチームではここまでやって完了」という暗黙の基準が共有されていますが、外部エンジニアはその文脈を持っていません。「実装が動く」だけでなく、「テストを書く」「ドキュメントを更新する」「レビューを通す」など、どこまでやれば完了なのかを受け入れ条件として言語化しておきます。この明文化は、後述する偽装請負の回避（成果物と役割を仕様・受け入れ条件で明確化する）という観点でも有効です。

口頭での「いい感じにお願いします」は、外部エンジニアにとって最も困る依頼です。タスクチケットに「目的・担当範囲・完了の定義・関連する仕様へのリンク」を書いて渡す、という運用を最初から徹底しましょう。

初回スプリントは小さく渡して立ち上がりを見極める

どれだけ事前に設計しても、外部エンジニアがプロダクトのコードベースや開発フローに慣れるまでには時間がかかります。そこで、最初のスプリントは意図的に小さくタスクを渡し、立ち上がりのペースとアウトプットの質をキャリブレーション（較正）することをおすすめします。

初回から本来期待する量のタスクを割り当ててベロシティに織り込んでしまうと、立ち上がりの遅れがそのままスプリントの失敗として現れます。最初のスプリントは「環境構築＋小さめの機能を1つ完結させる」程度に留め、その実績から「この人は1スプリントでどのくらい・どの品質で出せるか」を見極めます。この実測値が得られて初めて、2回目以降のスプリントで安心してベロシティに織り込めます。

期待値設定の面でも、外部エンジニアが加わった直後のスプリントは「増えた稼働がそのまま速度になる」とは考えないことが大切です。立ち上がり期間（おおむね1〜2スプリント）はオンボーディングのコストを織り込み、チーム全体のベロシティが一時的に横ばい、もしくは微減することも想定しておくと、現実とのギャップに慌てずに済みます。上長への提案時にも、この立ち上がり期間を正直に織り込んでおくと、後から「増員したのに速くならない」という誤解を避けられます。

準委任契約と偽装請負を避けるコミュニケーション設計

ここまでの運用設計（関わり方タイプ・セレモニー参加・タスクの渡し方）は、実は契約面のリスク管理と密接につながっています。外部エンジニアを業務委託で受け入れる際、避けて通れないのが「偽装請負」のリスクです。運用と契約を分けて考えると現場で矛盾が生じるため、この章で1本につなげて整理します。

なぜアジャイル開発で準委任契約が選ばれるのか

外部エンジニアへの業務委託では、契約形態として準委任契約が選ばれることが多くあります。理由は、アジャイル開発の性質と請負契約の性質が噛み合わないためです。

請負契約は「あらかじめ定めた成果物を完成させること」に対して対価を支払う契約です。一方アジャイル開発は、スプリントごとに優先順位や仕様を見直しながら段階的に作っていく進め方であり、契約時点で最終成果物を確定させることが構造的に困難です。そのため、「成果物の完成」ではなく「一定の専門性をもって業務を遂行すること」に対して対価を支払う準委任契約のほうが、アジャイル開発の実態に合います。発注側企業における準委任契約の設計を扱った情報処理学会の研究でも、アジャイル開発の推進と準委任契約の整合性が論点として取り上げられています（アジャイル開発推進を目的とした発注側企業における準委任契約制度の設計）。

ただし、準委任契約を結べば偽装請負の心配がなくなるわけではありません。むしろ、準委任であっても発注者が受託側の担当者に直接指揮命令をすれば偽装請負と判断され得る、という点が落とし穴になります。

デイリー・レビューでやってはいけない指示／問題ない伝え方（NG・OK 対比）

偽装請負とは、形式的には請負や準委任の契約でありながら、実態として発注者が受託側の労働者に直接、具体的な指揮命令を行って作業させている状態を指します。アジャイル開発については、厚生労働省が「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）に関する疑義応答集（第3集）【アジャイル型開発と契約方式】」を2021年に公表しており、判断の考え方が示されています（厚生労働省 疑義応答集（第3集））。

この疑義応答集の考え方を要約すると、発注者と受託者が対等な関係のもとで協働し、受託側の開発担当者が自律的に判断して業務を行っていると認められる場合は偽装請負に当たらない一方、発注者側が受託側の担当者に対し、直接、業務の遂行方法や労働時間などに関する指示を行うなど指揮命令があると認められる場合は偽装請負と判断される、というものです（出典: 厚生労働省 疑義応答集 第3集、2021年）。

問題が起きやすいのは、まさにデイリースクラムやスプリントレビューの場です。これらは進捗を共有し議論する場であるがゆえに、発注側がつい個々の外部エンジニアへ直接「今日はこれをやって」「これはやり直して」と言ってしまいがちだからです。同じ内容でも、伝え方によって偽装請負のリスクが大きく変わります。

ポイントは、「禁止される情報共有」と「禁止される指揮命令」を混同しないことです。進捗や課題を共有すること自体は問題ありません。NGになるのは、発注者が外部の個人に対して「作業の進め方・順序・労働時間」を直接コントロールしてしまうことです。

偽装請負を避ける3つの現場ルール

疑義応答集の考え方を、現場で守れる具体的なルールに落とし込むと、次の3点になります。

1. 指示は受託側の責任者に一本化する：発注者が個々の外部エンジニアに直接あれこれ指示するのではなく、要望や優先順位は受託側の責任者（フリーランス個人の場合は本人）に伝え、そこから業務に展開してもらう形にします。デイリーで個人に作業を割り振らない、という運用を徹底します。
2. 役割と成果物を仕様・受け入れ条件で明確化する：誰が何を担うのか、何をもって完了とするのかを、契約や仕様書・受け入れ条件であらかじめ合意しておきます。前章で述べた「完了の定義の明文化」は、そのまま偽装請負回避の備えになります。
3. 日々の進め方の判断は受託側が持つ：作業場所・作業時間・手順・使うツールといった日々の決めごとは、原則として受託側が自律的に決められるようにします。発注者がこれらを細かく管理し始めると、指揮命令と見なされるリスクが高まります。

IPA（情報処理推進機構）も、こうしたリスクを低減するために「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しており、契約条項のひな形として参照できます（IPA 情報システム・モデル取引・契約書（アジャイル開発版））。契約書の文言整備は法務・専門家の確認も得ながら進めるとより安心です。

重要なのは、これら3つのルールが「窮屈な制約」ではなく、外部エンジニアを自律した一人のプロとして尊重する設計だという点です。本人が判断の余地を持って働ける環境は、偽装請負の回避になると同時に、外部エンジニアのパフォーマンスとモチベーションを引き出すことにもつながります。

自社のスクラムチームに合わせた組み込み設計のまとめと次のアクション

ここまで、外部フリーランスエンジニアをスプリントに組み込む設計を、失敗パターンから逆算して順番に組み立ててきました。最後に、自社のチームに当てはめて提案書を書けるよう、意思決定の流れとして再整理します。

組み込み設計の意思決定フロー（4ステップの早見）

自社の状況に当てはめるときは、次の4ステップを順に決めていけば、組み込みの設計図が完成します。

1. 関わり方タイプを決める：外部エンジニアの想定稼働日数とタスクの独立性から、A（フルスクラムメンバー型）／B（タスク担当者型）／C（スプリント外タスク処理型）のいずれかを選びます。週3以下の稼働なら、原則BまたはCです。
2. 参加セレモニーを設計する：選んだタイプの行を「セレモニー参加 早見表」で確認し、プランニングとデイリーは原則参加、レトロ・リファインメントは任意、という方針を自社に合わせて微調整します。
3. タスクの渡し方を決める：稼働内で完結する粒度にタスクを切り、完了の定義を明文化して渡します。初回スプリントは小さく渡して立ち上がりを見極め、その実測値を2回目以降のベロシティに織り込みます。
4. 契約とコミュニケーションの地雷を避ける：契約は準委任を基本とし、「指示は責任者に一本化」「役割と成果物を明確化」「日々の判断は受託側」の3ルールで偽装請負を回避します。デイリー・レビューでのNG・OKの伝え方を、チームで事前に共有しておきます。

この4ステップを埋めれば、「うちのチームならB型で、プランニングとデイリーには入ってもらい、レトロは任意。タスクはこの粒度で渡し、契約は準委任で指示はこの形に一本化する」という具体的な設計図を、自分の言葉で上長やチームに提案できる状態になります。

組み込んだ後の継続マネジメントで見るべきポイント

組み込みの設計はスタート地点であり、外部エンジニアが加わってからの継続的なマネジメントこそが成果を左右します。最後に、運用開始後に見ておきたい観点を挙げておきます。

• 立ち上がりの実績とベロシティの推移：初回スプリントのアウトプットから、期待値とのギャップを早めに把握し、タスク量や粒度を調整します。
• コミュニケーションの属人化が起きていないか：特定メンバーに質問が集中していないか、非同期の情報共有が機能しているかを定期的に確認します。
• セレモニー参加方針の見直し：関わる期間が延びたり役割が広がったりした場合は、タイプやセレモニー参加方針をアップデートします。
• 契約・コミュニケーションのルールが守られているか：偽装請負を避ける3ルールが現場で形骸化していないか、特にデイリー・レビューでの伝え方を継続的に振り返ります。

外部エンジニアの組み込みは、最初の設計図を描くことと、加わった後のマネジメントを継続することの両輪で成り立ちます。稼働管理・評価・契約更新の判断・チームへの定着といった継続的なマネジメントの論点は、本記事で扱った「組み込みの設計」よりも広い領域にわたるため、体系的に整理して学んでおくと、運用開始後のつまずきを減らせます。まずは本記事の4ステップで最初の設計図を描き、提案の第一歩を踏み出してみてください。

よくある質問

Q. 週3稼働の外部エンジニアでもスクラムチームに入れられますか？

入れられます。ただし全セレモニーにフル参加するA型ではなく、プランニングとデイリーには参加してもらうB型、または独立タスクを非同期で処理してもらうC型での設計が現実的です。稼働日にデイリーが重なるよう曜日を調整し、タスクを「稼働内で完結する粒度」に切ることがうまくいくコツです。

Q. 外部エンジニアにスクラムマスターを任せても良いですか？

慎重な検討が必要です。スクラムマスターはチームのプロセスや働き方に深く関与し、メンバーへの働きかけを行う役割のため、短期・限定稼働の外部メンバーには馴染みにくい面があります。また、外部の個人がチーム運営を主導する形は、自律性や指揮命令の線引きの観点でも整理が必要です。中長期で深く関わるA型で、かつ契約・役割を慎重に設計できる場合に限り検討する、という位置づけが無難です。

Q. 準委任と請負、アジャイル開発ではどちらが適切ですか？

アジャイル開発では準委任契約が選ばれることが多くあります。アジャイルはスプリントごとに仕様や優先順位を見直しながら段階的に作るため、契約時点で最終成果物を確定させる請負契約とは構造的に噛み合わないためです。準委任は「成果物の完成」ではなく「専門性をもって業務を遂行すること」に対価を支払う形で、アジャイル開発の実態に合います。

Q. デイリースクラムで進捗を直接質問するのは偽装請負になりますか？

進捗や課題を共有・確認すること自体は問題ありません。偽装請負と見なされるリスクが高まるのは、発注者が外部の個人に対して「今日はこれをやって」「この順番で進めて」といった作業の進め方・順序・労働時間を直接指示してしまう場合です。進捗の共有と、作業の進め方への直接指示は別物として扱い、進め方の判断は受託側に委ねるのが安全です（厚生労働省 疑義応答集（第3集））。