複業エンジニアをスクラムに組み込む設計｜非同期参加・契約・成果評価

開発リソースが足りず、機能追加がスプリントからあふれ続けている。けれど正社員の採用は時間がかかり、フルタイムのフリーランスは予算的にも確保のスピード的にも現実的ではない。そんなとき、選択肢に上がるのが「本業を持つ優秀な複業エンジニア」です。週1〜2日、夜間や週末だけでも手伝ってもらえれば、と考える発注者は少なくありません。

ところが、いざ自社のスクラム開発に複業エンジニアを入れようとすると、急に手が止まります。スクラムは毎日のデイリースクラムやプランニングへの同席など、メンバーが同じ時間に集まる「同期参加」を前提とした手法に見えるからです。デイリーに毎日出られず、稼働時間も不規則な複業人材を、その枠組みにどう噛み合わせればスプリントが破綻しないのか。稼働が少ない人の成果をどう測って契約継続を判断するのか。さらに、稼働時間がバラバラな相手に「今夜これをやってほしい」と指示することが偽装請負にならないか。判断軸がないまま、増員に踏み切れずにいるのではないでしょうか。

結論から言えば、複業エンジニアをスクラムに組み込めないわけではありません。つまずきの原因は人材側ではなく、「フルタイム・同期参加を前提としたスクラム運用を、低稼働・非同期の複業人材にそのまま当てはめようとすること」にあります。前提条件が違う相手には、運用そのものを作り替える必要があるのです。

本記事では、複業エンジニア（週1〜2日・夜間/週末・非同期）を発注者目線でスクラムに組み込むための設計を、「スプリント参加範囲の振り分け」「タスクの渡し方」「契約形態と偽装請負を避ける指示」「限られた稼働の成果評価」という4つの観点から整理します。読み終えたときに、自社のスプリント長や稼働時間に当てはめた組み込みの設計図を描き、チームや上長に提案できる状態を目指します。

複業エンジニアをスクラム開発に入れるとつまずく3つのギャップ

最初に、本業を持つ複業エンジニアをフルタイム前提のスクラムにそのまま入れたときに、どこで噛み合わなくなるのかを言語化しておきます。この3つのギャップを理解しておくと、以降の各セクションが「どのギャップを埋めるための設計なのか」が明確になります。

ひとつ目は、同期前提のセレモニーに毎日出られず、情報が分断するギャップです。スクラムのデイリースクラムは毎日決まった時間に集まることを前提としていますが、本業を持つ複業エンジニアは平日の日中に参加できないことがほとんどです。何も対策をしないと、複業メンバーだけが議論の文脈から取り残され、手戻りや認識のズレが生まれます。

ふたつ目は、稼働が少なくタスクがスプリント内に収まらず、ベロシティが読めないギャップです。週10〜16時間しか動けない人に、フルタイムを前提とした粒度のタスクを渡すと、1スプリント内で終わりきりません。中途半端な状態でスプリントをまたぐタスクが増えると、チーム全体の進捗見通し（ベロシティ）が不安定になり、計画が立てづらくなります。

3つ目は、稼働がバラバラで成果が見えず、評価も指示の仕方も手探りになるギャップです。稼働時間が不規則だと、正社員と同じ物差しでは成果を測れません。過小評価して早々に契約を切ってしまうか、逆に感覚だけで継続するかになりがちです。さらに、稼働が読めない相手につい細かく直接指示を出してしまい、それが契約形態と整合しなくなるリスクも潜んでいます。

フリーランス（フルタイム）と複業（本業あり・低稼働）は前提がまったく違う

ここで押さえておきたいのは、同じ「外部エンジニア」でも、フルタイムのフリーランスと本業を持つ複業エンジニアでは前提条件がまったく異なるという点です。

フルタイムのフリーランスは、平日の日中フルに稼働できるため、デイリーやプランニングへの同期参加が可能で、正社員に近い形でスプリントに組み込めます。一方、複業エンジニアは本業があるため、稼働は週1〜2日・10〜16時間程度に限られ、しかもその時間帯は夜間や週末に偏ります。「いつでも連絡が取れる」前提も崩れます。

つまり、フルタイム外注の組み込み方をそのまま複業に流用すると、同期前提の部分がことごとく機能しなくなるのです。外部エンジニアをスプリントに組み込む一般的な進め方については、外部エンジニアをスプリントに組み込む方法で整理しているため、フルタイム想定の基本を確認したい場合はそちらも参考にしてください。本記事は、そこから一歩踏み込んで「複業＝低稼働・非同期」という制約条件に特化します。

つまずきの本質は「人材」ではなく「同期前提のスクラム運用をそのまま当てはめること」

3つのギャップに共通するのは、問題の根が複業エンジニアの能力や意欲ではなく、運用の前提条件にあるということです。優秀な人材であっても、フルタイム・同期参加を暗黙の前提にした運用に低稼働・非同期の人を入れれば、噛み合わないのは当然です。

逆に言えば、運用の側を「複業向けに作り替える」ことができれば、複業エンジニアは十分に戦力になります。具体的には、(1) どのセレモニーを同期で残し、どこを非同期に切り替えるか、(2) 限られた稼働でも完結するタスクをどう渡すか、(3) 稼働がバラバラな相手とどんな契約・指示の形を取るか、(4) 限られた稼働の成果をどう測るか、という4点を設計し直すことです。次のセクションから、この順番で具体化していきます。

複業エンジニアの稼働実態に合わせたスプリント参加範囲を設計する

最初に手をつけるべきは、スプリントの各セレモニーのうち「複業エンジニアに同期で参加してもらうもの」と「非同期に切り替えるもの」を振り分けることです。ここが、裏テーマである「同期前提のスクラムと低稼働・非同期の複業をどう噛み合わせるか」に最も直接的に答える部分になります。

ポイントは、すべてのセレモニーを非同期化するのではなく、同期の価値が高いものだけを残し、それ以外を非同期化するという割り切りです。すべてを非同期にすると認識合わせが甘くなり、すべてを同期にすると複業エンジニアが参加できません。価値の高い接点に同期の時間を集中させるのが現実解です。

なお、スプリントやスプリントレビューの基礎的な進め方そのものはスプリントの基礎と発注者の関わり方で解説しています。スクラムのセレモニーの役割をおさらいしたい場合は先にそちらを確認すると、本セクションの振り分けが理解しやすくなります。

同期で残すセレモニーと非同期化できるセレモニーを振り分ける

セレモニーごとに、同期の価値と非同期化の可否を整理すると次のようになります。

• スプリントプランニング（同期を推奨）: スプリントで何をどこまでやるかを決める場であり、複業エンジニアが「自分が今スプリントで何を担当するか」「ゴールは何か」を理解する出発点です。ここで認識がずれると以降すべてが空回りするため、複業メンバーには可能な限り同期で同席してもらうのが望ましいセレモニーです。週末稼働の人であれば、プランニングの一部を週末や夜間に短時間設定するなど、複業メンバーの参加を前提に時間を調整します。
• デイリースクラム（非同期化が現実的）: 毎日同じ時間に集まる前提は複業エンジニアと相性が悪いため、後述するテキストベースの非同期共有に切り替えます。
• スプリントレビュー（録画・非同期コメントで代替可能）: 成果物を確認する場ですが、複業メンバーが担当した部分のデモを録画で共有し、フィードバックを非同期のコメントで受け取る形にすれば、リアルタイム参加がなくても成立します。
• レトロスペクティブ（非同期コメントで代替可能）: 振り返りは「気づいたことを書き出す」形でも機能します。複業メンバーには事前に非同期で改善点を書いてもらい、本会議の結果を共有する運用にできます。
• リファインメント（一部同期が望ましい）: 複業メンバーが担当する見込みのバックログ項目については、仕様の曖昧さを潰すために、可能なら短時間の同期、難しければ非同期テキストで質疑を行います。

稼働パターン別の参加範囲を早見表で決める

稼働パターンによって、どこまで参加してもらうかの現実的なラインは変わります。自社の複業エンジニアの稼働に当てはめて、参加範囲の初期設計に使ってください。

この表はあくまで初期設計の出発点です。最初のスプリントで運用してみて、複業メンバーが文脈から取り残されていないか、手戻りが起きていないかを見ながら、同期/非同期の比率を調整していくことを前提にしてください。

非同期デイリーをテキスト共有と週1ハドルで実装する

非同期化の要になるのがデイリースクラムです。同期で毎日集まる代わりに、複業メンバーには稼働したタイミングで以下の3点をテキスト（Slack やプロジェクト管理ツールの専用チャンネル）に書いてもらいます。

1. 前回稼働以降にやったこと
2. 次に稼働するときにやる予定のこと
3. 詰まっている点・確認したいこと（誰に何を聞きたいか）

この3点は、デイリースクラムで本来共有される内容そのものです。テキストに残しておけば、複業メンバーが稼働していない時間帯にも、チームのメンバーが非同期で回答や調整をしておけます。複業メンバーが次に稼働を始めるときには、すでに疑問が解消されている状態を作れるため、限られた稼働時間を「待ち」で浪費せずに済みます。

ただし、テキストだけでは温度感や複雑な論点が伝わりにくい場面もあります。そこで、週に1回だけ複業メンバーと短時間（15〜30分）の同期ミーティング（ハドル）を設けて、テキストでは解消しきれなかった論点をまとめて話す運用を併用すると、非同期の取りこぼしを補えます。「日々は非同期テキスト、週1回だけ同期ハドル」という組み合わせが、低稼働・非同期の複業エンジニアと最も噛み合いやすい型です。

低稼働でもスプリントを止めないタスクの渡し方

参加範囲を設計したら、次は「複業エンジニアに渡すタスクそのもの」の作り方です。ここで埋めるのは、3つのギャップのうち「稼働が少なくタスクがスプリント内に収まらない」というギャップです。

複業エンジニアが成果を出せるかどうかは、本人のスキル以上に「タスクをどう切り出して、どこまで仕様を固めて渡すか」という発注者側の準備で決まります。稼働が限られているからこそ、渡し方のコントロールが成否を分けます。

タスクは1人日以下に割って稼働時間から逆算する

最初の原則は、複業エンジニアに渡すタスクを1人日（8時間）以下の粒度に分割することです。週10〜16時間の稼働であれば、1スプリント（2週間）で動ける時間は20〜30時間程度です。この中に、1つあたり数日かかる大きなタスクを入れると、スプリント内に終わらず中途半端な状態で持ち越され、ベロシティが読めなくなります。

タスクを1人日以下に割っておけば、複業メンバーは1回の稼働でタスクをひとつ完結させられます。「今日は2時間しか取れないが、この1タスクは終わらせられる」という見通しが立つため、進捗が安定し、レビューやマージのタイミングも読みやすくなります。稼働時間から逆算して、確実にスプリント内で閉じられる粒度まで割ることを徹底してください。

仕様の完成度を上げて「待ち時間」をゼロに近づける

ふたつ目は、渡すタスクの仕様（要件・受け入れ条件）の完成度を上げておくことです。複業エンジニアの稼働時間は貴重なので、その時間を「仕様の確認待ち」「質問の回答待ち」で消費させると、実質的な成果が大きく目減りします。

実務では、着手できる状態の条件（DoR：Definition of Ready）を明確にし、タスクを渡す前に仕様の完成度を高めておくアプローチが有効です。複業エンジニアとスクラムを回している実践者からは、仕様の完成度を8割程度まで固めて渡し、残りの曖昧な2割は非同期のチャットで都度解消する、という運用が紹介されています（プロパートナー（副業エンジニア）とスクラム開発をどうできるのか）。完璧な仕様を待つ必要はありませんが、「稼働を始めたらすぐ手を動かせる」状態にしておくことが、限られた稼働を成果に変える鍵になります。

あわせて、完了の定義（Done の定義）も渡す前に明文化しておきます。何をもって「このタスクは完了」とするのか（テストが通る・PR がレビュー承認される・ドキュメントを更新する、など）を受け入れ条件として書いておけば、複業メンバーは自分の判断で完了まで持っていけます。「どこまでやれば終わりか」が曖昧だと、稼働時間を使ったのに手戻りになるという最ももったいない事態を招きます。

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

3つ目は、最初のスプリントでは意図的に少なめ・小さめにタスクを渡すことです。複業エンジニアが入った最初のスプリントは、本人がコードベースやチームの進め方に慣れる立ち上がり期間でもあります。ここでフルに期待量を渡すと、慣れの遅れがそのままスプリントの遅延に直結します。

最初は確実に終わる量だけを渡し、「どのくらいの稼働でどれだけ進むか」「どんなタスクなら自走できるか」を観察します。立ち上がりの実績が見えてから、徐々に渡す量や難易度を上げていけば、ベロシティを崩さずに複業メンバーを戦力化できます。この立ち上がりの観察結果は、後述する成果評価の出発点にもなります。

複業エンジニアに合う契約形態と偽装請負を避ける指示を設計する

運用（参加範囲・タスク）の設計と必ずセットで考えたいのが、契約形態と指示の出し方です。稼働がバラバラな複業エンジニアだからこそ、ここを曖昧にすると「稼働がバラバラな相手への指示が偽装請負にならないか」という不安が現実のリスクになります。

このセクションは、運用と契約を1本につなぐ最も重要な部分です。誤解を避けるために最初に断っておくと、複業エンジニアを業務委託（準委任）で受け入れること自体は何ら問題ありません。問題になるのは「業務委託の形を取りながら、実態は労働者派遣・指揮命令に近い指示をしてしまう」ケースです。

複業エンジニアでなぜ準委任契約が選ばれるのか

複業エンジニアの業務委託では、請負契約ではなく準委任契約が選ばれることが一般的です。両者の違いを押さえておくと、なぜ複業と準委任が相性が良いのかが見えてきます。

請負契約は「成果物を完成させて納品すること」が目的で、エンジニア側は完成責任を負います。一方、準委任契約は「業務（作業）を遂行すること自体」が目的で、完成までの保証義務は負いません（請負契約と準委任契約の6つの違い／レバテック）。

スクラム開発は、スプリントごとに要件が変わり、何を作るかが途中で柔軟に調整されることを前提とした手法です。「最初に決めた成果物を完成させて納品する」請負の枠組みとは噛み合いにくく、「決められた期間・稼働の中で開発業務を遂行してもらう」準委任のほうが、スプリント運用と整合します。複業エンジニアにスプリント内のタスクをこなしてもらう形であれば、準委任契約が自然な選択になります。

稼働がバラバラだからこそ気をつける指示のNG/OK対比

準委任契約を結んでいても、発注者が複業エンジニア個人に対して直接的な指揮命令を及ぼすと、偽装請負と判断されるリスクが生じます。偽装請負に該当するのは、発注者が受注者（やその従業員）に対して直接指揮命令を行うなど、労働者派遣に近いコントロールを及ぼす場合で、その判断基準は厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）に示されています（37号告示関係 疑義応答集／厚生労働省）。

稼働がバラバラな複業相手だと、つい「今夜これをやって」「明日までにこの順番でやり直して」と、その場その場で細かく指示したくなります。しかし、これは作業の進め方や時間配分まで会社側がコントロールしている状態に近づき、危険です。具体的なNG/OKを対比すると次のようになります。

ポイントは、「何を・いつまでに（成果と期限）」は依頼してよいが、「いつ・どの順番で・どうやって（時間・順序・手順）」を会社側が管理しないという線引きです。

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

上記の線引きを、日々の運用に落とし込む現場ルールとして3つにまとめます。複業エンジニアを受け入れるチーム全体で共有しておくと安全です。

1. 指示はチケット/バックログに一本化する: 個人へのDMや口頭で「今すぐこれを」と指示するのではなく、依頼はすべてチケットやバックログ項目として記録し、優先順位として渡します。これにより、指示が「個人への直接命令」ではなく「業務の依頼」として整理されます。先ほどのタスクの渡し方（1人日以下・仕様の完成度・Done の定義）も、この一本化と自然につながります。
2. 稼働時間や作業順序を会社側が管理しない: いつ作業するか、どのタスクからどう進めるかは本人の裁量に委ねます。会社が管理するのは「契約上の稼働量の範囲で、依頼したタスクが期限内に完了するか」という成果の側だけです。
3. 日々の進め方の判断は本人に委ねる: 技術的な進め方や手順を逐一指示せず、受け入れ条件を満たす方法は本人に任せます。困ったときの相談に応じることと、手順を命じることは別物です。

この3つを守れば、複業エンジニアの稼働がバラバラであっても、業務委託（準委任）として適切な距離感を保てます。指揮命令と業務委託の線引きをより体系的に確認したい場合は、業務委託エンジニアのKPI評価もあわせて参照すると、評価と指示の整合が取りやすくなります。

限られた稼働の成果をどう評価し契約継続を判断するか

最後の論点は、稼働が少ない複業エンジニアの成果をどう測り、契約を続けるか・単価を見直すかをどう判断するかです。ここで埋めるのは、3つのギャップのうち「稼働がバラバラで成果が見えず、評価が手探りになる」というギャップです。

複業の成果は「稼働あたりの貢献」で見る

複業エンジニアの評価で最も陥りやすいのが、正社員と同じ絶対量の物差しで測ってしまうことです。週10〜16時間しか動けない人の消化量を、フルタイムのメンバーと同じ絶対値で比べれば、当然見劣りします。この物差しで判断すると、優秀な複業メンバーであっても「成果が少ない」と過小評価し、早々に契約を切ってしまいかねません。

複業の成果は、絶対量ではなく**「限られた稼働に対してどれだけ貢献したか」という稼働あたりの貢献度**で見ます。「週16時間でこれだけのタスクを確実に閉じてくれた」「少ない稼働の中で、難易度の高い部分を任せられた」という観点で評価すれば、低稼働であっても正当に成果を捉えられます。

スプリント単位で見る軽量な観点

評価のために重いKPI設計を最初から作り込む必要はありません。複業エンジニアの成果は、スプリントごとに以下の3つの軽量な観点で確認すれば、感覚評価を避けつつ実態を捉えられます。

• ベロシティ寄与: そのスプリントで、複業メンバーが担当して完了させたタスク（ストーリーポイント）はどれだけか。稼働時間に対して妥当な量を閉じられているかを見ます。
• PR/レビューの質: 提出されたプルリクエストが、レビューで大きな手戻りなく通っているか。コードの品質や、受け入れ条件を満たした実装になっているかを確認します。差し戻し回数が多すぎないかも目安になります。
• 自走度: 質問の量や粒度が適切か、仕様の曖昧な部分を自分で埋めて進められているか。自走度が高いほど、発注者側のフォロー工数が減り、限られた稼働がそのまま成果につながります。

これらは数値化しすぎず、「スプリントごとに簡単にチェックする観点」として運用するのがコツです。本格的なKPI設計や目標設定まで踏み込みたい場合は、業務委託エンジニアのKPI目標設定で発注前の合意形成も含めて整理しているため、評価制度として固めたい段階でそちらを参照してください。本記事では、契約継続・単価見直しを判断するための軽量な見方にとどめます。

契約継続・単価見直しの判断タイミングと進め方

軽量な観点で見えてきた成果をもとに、契約継続や単価をどう判断するかを整理します。

判断のタイミングは、立ち上がりのスプリント（おおむね最初の1〜2スプリント）と、その後の定期的な区切り（四半期や契約更新時期）の2つを基本にします。立ち上がり期はベロシティが安定しないため、ここでの数値だけで早急に判断せず、「自走度」「コミュニケーションの非同期適応」といった定性的な兆候を重視します。非同期のテキストコミュニケーションにうまく適応できているか、チームの文脈をキャッチアップできているかは、低稼働・非同期で続けられるかの重要なシグナルです。

数スプリントを経て、稼働あたりの貢献が安定して高ければ、稼働を増やせるか相談したり、難易度の高いタスクを任せたりと、関係を深める方向で進めます。逆に、稼働あたりの貢献が継続的に低い、あるいは非同期での連携が噛み合わない場合は、タスクの渡し方や仕様の完成度に発注者側の改善余地がないかをまず見直し、それでも改善しなければ契約条件の見直しを検討します。いきなり契約終了を判断するのではなく、「運用の改善で解決できるギャップか、人材とのミスマッチか」を切り分けるのが、限られた稼働の成果を正しく扱うコツです。

自社のスクラムに合わせた複業エンジニア組み込み設計のまとめ

ここまでの内容を、複業エンジニアをスクラムに組み込むための意思決定の流れとして再整理します。この順番でひとつずつ自社に当てはめれば、冒頭で挙げた「うちのスクラムに低稼働の人を入れて本当に回るのか」という不安に、自分なりの設計図で答えられるはずです。

複業エンジニア組み込み設計の意思決定フロー

1. 稼働実態を把握する: 複業エンジニアの稼働（週1日/週2日/週末のみ・主な稼働時間帯）を確認し、設計の前提を固める。
2. 参加範囲を同期/非同期で振り分ける: プランニングは同期で同席を基本に、デイリーは非同期テキスト＋週1ハドル、レビュー・レトロは録画や非同期コメントで代替する。稼働パターン別の早見表を出発点にする。
3. タスクの渡し方を設計する: タスクを1人日以下に割り、仕様の完成度を上げ（DoR）、完了の定義（Done）を明文化して渡す。最初のスプリントは小さく渡して立ち上がりを見極める。
4. 契約と指示を設計する: 準委任契約を基本にし、「何を・いつまでに」は依頼するが「いつ・どの順番で・どうやって」は本人に委ねる。指示はチケット/バックログに一本化し、偽装請負を避ける。
5. 成果を軽量に評価する: ベロシティ寄与・PR/レビューの質・自走度を稼働あたりの貢献として見て、契約継続・単価見直しを判断する。

このフローは、各ステップが前のステップの判断結果を引き継ぐ構造になっています。稼働実態が参加範囲を決め、参加範囲とタスク粒度が契約・指示の形を決め、それらの運用結果が成果評価の材料になります。バラバラの施策の寄せ集めではなく、一本の設計としてつながっていることが、複業エンジニアをスクラムで破綻させない要点です。

組み込んだ後に継続して見るべきポイント

複業エンジニアを組み込んだ後も、初期設計のまま固定するのではなく、いくつかのポイントを継続的に観察して調整していくことが大切です。

最初のスプリントで設計した同期/非同期の比率は、運用しながら微調整します。複業メンバーが文脈から取り残されていないか、非同期デイリーで疑問がきちんと解消されているか、手戻りが増えていないかを定期的に確認し、必要なら週1ハドルの頻度や時間を見直します。タスクの粒度や仕様の完成度も、立ち上がりの実績を踏まえて最適化していきます。

複業を含む外部エンジニアの受け入れは、一度設計して終わりではなく、継続的なマネジメントの中で精度が上がっていくものです。低稼働・非同期の人材を含めたチーム運営の進め方を、契約・評価・コミュニケーション設計まで含めて体系的に押さえておくと、複業エンジニアを安定した戦力として活かしやすくなります。本記事の設計図を出発点に、自社のスクラムに合った複業エンジニアの組み込み方を、ぜひチームで具体化してみてください。