アジャイル開発のテスト外注｜噛み合わない3つの原因と対処

スプリントを回しているのに、テストだけがいつも後ろにずれ込む。リリース直前にまとめてテストへ追われ、結局エンジニアが実装の片手間で対応している。こうした症状に心当たりのあるPMにとって、アジャイル開発のテスト外注は有力な選択肢に見えて、なかなか踏み切れないテーマではないでしょうか。

抜け漏れが不安なまま本番に出し、後からバグ対応で消耗する。この繰り返しに疲れている方も多いはずです。

外注を検討しても、今度は別の不安が立ちはだかります。「連携がうまくいくのか」「かえって手間が増えないか」「上長にどう費用対効果を説明すればいいのか」。この不安が拭えず、検討が止まってしまうケースをよく見かけます。

ここで押さえておきたいのは、原因の在り処です。アジャイル開発のテスト外注がうまく回らないのは、アジャイルに外注が向かないからではなく、ウォーターフォール前提の発注設計をそのまま持ち込んでいるからです。

変えるべきポイントは、次の3点に集約されます。

• 契約形態：固定スコープの請負をやめ、変化を前提とした契約に切り替える
• スプリントへの同期：外注先をチームのリズムに乗せる仕組みを作る
• 回帰テストの分担：スプリントごとに膨らむ回帰テストを、自動化と人手でどう配分するか決める

本記事では、この3点を軸に噛み合わない原因を整理し、外注導入前にPMが確認すべき判断チェックリストまで具体的に解説します。

なぜアジャイル開発のテスト外注はウォーターフォール型のままだと噛み合わないのか

外注そのものが悪いわけではありません。多くの場合、問題は「発注のやり方」がウォーターフォールのままだという点にあります。仕様が固まってから一括でテストを依頼する、という従来の型を反復開発にそのまま当てはめると、随所で歯車が噛み合わなくなります。

「まとめてテスト」前提が反復開発と衝突する

ウォーターフォールでは、設計・実装がひと通り終わった後に、まとまった期間をテストに充てます。この「最後にまとめてテスト」という前提で外注を組むと、アジャイルの反復サイクルと真正面から衝突します。

アジャイルでは、スプリントごとに動くソフトウェアが積み上がっていきます。テストも各スプリントの中で継続的に行う必要があり、「全部できてからまとめて」というタイミングが存在しません。

まとめてテストを前提にした外注は、渡すものが揃うのを待つ間ずっと稼働の谷が生まれ、リリース直前に一気に負荷が集中します。これでは、そもそもテストを外に出した意味が薄れてしまいます。

スコープ確定を待てない＝固定スコープ契約が破綻する

もう一つの衝突点が、スコープの扱いです。アジャイルは、開発を進めながら要件を調整していく前提で成り立っています。バックログの優先順位は変わり、スプリントごとにやることも変化します。

一方、固定スコープの請負契約は「このテストを、この範囲で、この金額で」と最初に確定させる形です。範囲が動く前提の開発と、範囲を固定する契約は、構造的に相性が悪いのです。

スコープが変わるたびに契約を結び直していては、スピードが持ち味のアジャイルが止まってしまいます。契約が開発の足かせになる、という本末転倒が起きます。

症状チェック：外注が「間に合わない・浮く・手戻る」の3パターン

発注設計が旧来のままだと、外注の稼働は典型的な3つの形で崩れます。自社の状況がどれに当てはまるか、確認してみてください。

症状	何が起きているか	根本原因
間に合わない	リリース直前にテストが集中し、消化しきれない	まとめてテスト前提で負荷が後ろに寄る
浮く	スプリント序盤は外注が手待ちになる	渡すものが揃うのを待つ設計になっている
手戻る	仕様変更のたびにテスト内容がやり直しになる	固定スコープ契約で変化に追随できない

この3つは、いずれも外注先の能力不足ではなく、発注の型が反復開発に合っていないことから生じます。原因が「設計」にあるなら、変えるべきは発注のやり方です。

なお、アジャイルにおけるテストの全体像を体系的に押さえたい場合は、アジャイルテストの4象限を解説した記事で「いつ・何を・誰が」テストするかの枠組みを確認できます。外注の役割を位置づける前提知識として役立ちます。

変える①契約形態｜固定スコープ請負が破綻する理由と準委任・継続型

最初に変えるべきは契約形態です。ここを旧来のまま進めると、後の同期や分担をいくら工夫しても土台から噛み合いません。

請負がアジャイルで破綻するメカニズム

請負契約は、あらかじめ定めた成果物を完成させることに対して対価を払う形です。「何を作るか」が固まっている前提で成立します。

アジャイルでは、この前提が崩れます。スプリントごとに要件が調整され、テスト対象も動きます。すると請負では、変更のたびに「これは契約範囲か、追加か」という線引きの交渉が発生します。

請負契約は変化をコストとして扱うため、変化を前提とするアジャイルとは根本的に噛み合いません。交渉のたびにスピードが落ち、外注先も自社も疲弊していきます。

準委任・継続契約が向く理由と注意点

そこで選択肢になるのが、準委任契約や継続型の契約です。準委任は、特定の成果物の完成ではなく、専門的な業務の遂行そのものに対して対価を払う形です。

範囲が動いてもその都度契約を結び直す必要がなく、スプリントの変化に柔軟に追随できます。テストという「継続的に手を動かし続ける業務」との相性が良いのが特徴です。

ただし注意点もあります。準委任では成果物の完成が保証されるわけではないため、「何をもって業務を果たしたとするか」の基準を曖昧にすると、期待値がずれます。とはいえ「成果物基準がない＝品質を握れない」わけではありません。テスト観点表や網羅基準を事前に合意し、欠陥報告の粒度やテスト実施の証跡を可視化しておけば、準委任でも業務の質を確認できます。

主要な契約形態を比較すると、次のように整理できます。

契約形態	対価の対象	アジャイル適性	主な注意点
請負	成果物の完成	低い（変化がコスト化）	変更のたびに範囲交渉が発生する
準委任	業務の遂行	高い	成果物基準・報告の握りが必要
継続型・スプリント併走	期間内の継続的な業務	高い	稼働量と役割の定義、区切りの設計

契約形態ごとの違いや選び方をさらに詳しく比較したい場合は、テスト外注の契約形態を整理した記事が判断材料になります。

契約変更の社内ハードルをどう越えるか

理屈の上では「請負から準委任へ」で正しいのですが、実務では契約変更そのものが最大の壁になります。準委任への切り替えは、現場だけでは決められません。法務・購買との調整や、既存の基本契約との整合を通す必要があります。

特に注意したいのが、準委任における偽装請負リスクです。発注側が外注メンバーへ直接指揮命令を出す運用は偽装請負とみなされる恐れがあるため、指示は外注先の管理者を通す形に設計します。ここを曖昧にしたまま準委任へ切り替えると、コンプライアンス上の指摘を受けかねません。

社内ハードルの越え方は、新規発注か既存取引先の継続案件かで分けて考えると整理しやすくなります。

• 新規発注の場合：最初から準委任・継続型で契約を組めるため、比較的スムーズに始められる
• 既存取引先の継続案件の場合：現行の請負契約との関係を法務・購買と再調整する必要があり、時間がかかる

既存案件の契約をいきなり全面的に巻き直すのは負担が大きいものです。そこで現実的なのが、まず新規1案件で準委任を試すスモールスタートです。社内調整の負荷を抑えつつ、準委任運用の勘所を掴んでから広げていく道筋を取れます。

契約で最低限詰めておく条項

準委任や継続型を選ぶ場合でも、「柔軟だから何も決めなくていい」わけではありません。むしろ変化を前提とするからこそ、変化の扱い方を契約に織り込む必要があります。最低限、次の点を詰めておきましょう。

• 変更前提の明記：スコープが動くことを前提に、変更を通常運用として扱う旨を記す
• 区切りの設計：スプリントや月次など、稼働と成果を振り返る区切りを定める
• 完了の合意方法：各区切りで「何をもって業務を果たしたか」を確認する手順を決める
• 役割と稼働範囲：外注が担う領域と、自社が担う領域の境界を明文化する

これらを曖昧にしたまま進めると、柔軟さが「なし崩し」に変わり、かえってトラブルの火種になります。

変える②スプリントへの同期｜窓口・報告頻度・デイリー/レトロへの関わり方

契約を整えたら、次は外注先をチームのリズムに乗せる仕組みが必要です。アジャイル開発のテスト外注で最も差が出るのがこの同期の設計で、アジャイルは短いサイクルで情報が更新されるため、ここが品質と速度をそのまま左右します。

なお、ここで前提とするスプリント・デイリースクラム・レトロスペクティブといったイベントの定義は、スクラムガイド公式に基づいています。日本語で確認したい場合はスクラムガイド2020日本語版（PDF）も参照できます。

単一窓口と情報同期

まず整えるべきは、情報の入り口を一本化することです。外注先が複数の担当者から断片的に情報を受け取る状態だと、認識のずれが積み重なります。

同期の起点として、次を共有できる状態にしておきます。

• プロダクトバックログ：何が優先され、次に何が来るか
• 受け入れ基準：各項目が「完成」と見なされる条件
• 単一窓口の設定：外注先とのやり取りを集約する担当者を1人決める

窓口を一本化すると、質問と回答の履歴が一箇所に溜まり、後から参照できます。属人的なやり取りが減り、抜け漏れの起点を潰せます。

報告頻度の設計

次に、報告のリズムを決めます。ここで陥りやすいのが、「密に連携すべき」という思いから、外注先を全てのミーティングに拘束してしまうことです。

デイリースクラムは本来、開発チームが日々の計画を同期する短い場です。外注先をどこまで巻き込むかは、目的に応じて設計します。

• デイリーへの関与範囲：毎回フル参加させるのか、進捗の共有だけ非同期で受けるのかを決める
• 非同期報告の落としどころ：チャットや共有ボードでの日次報告に切り替え、拘束時間を減らす
• エスカレーションの基準：どういう状態になったら即座に連絡すべきかを事前に合意する

報告は「頻度を上げる」ことより、「必要な情報が必要なタイミングで届く」ように設計することが重要です。過剰な会議は、外注先の稼働も自社の時間も削ります。

レトロで外注品質を改善ループに乗せる

同期の仕上げが、振り返り（レトロスペクティブ）への組み込みです。外注を「渡して終わり」にせず、改善のループに乗せることで、スプリントを重ねるごとに連携の精度が上がっていきます。

レトロで「テスト連携でうまくいかなかった点」を継続的に拾い、次スプリントの進め方に反映します。窓口の運用、報告のタイミング、受け入れ基準の粒度など、小さな摩擦を毎回削っていくイメージです。

振り返りの進め方そのものを整えたい場合は、レトロスペクティブの基本と実践を解説した記事が参考になります。外注先を含めた改善サイクルの土台として活用できます。

変える③回帰テストの分担｜外注×自動化でどう配分するか

3つ目に変えるのは、回帰テストの分担です。アジャイル開発のテスト外注でアジャイル特有の構造課題が最も表れるのがこの領域で、放置すると「テストが終わらない」状態を招きます。

スプリントごとに膨らむ回帰テストという構造課題

回帰テストとは、（修正が正しく効いたかを見る確認テストとは別に）変更の影響で既存の機能が壊れていないかを確認するテストです（用語の定義はJSTQB公式の資料などが参考になります）。この2つは目的が異なるため、分担を設計する前に区別しておくと混乱を避けられます。

アジャイルでは、スプリントごとに機能が積み上がります。すると、確認すべき既存機能の範囲も回を重ねるたびに増えていきます。

回帰テストは放っておくと雪だるま式に膨らみ、後半のスプリントほど手動での確認が現実的でなくなります。この構造を理解した上で、分担を設計する必要があります。

自動化する領域／人手（外注）で担う領域の線引き

ポイントは、「全部を自動化する」でも「全部を人手でやる」でもなく、性質に応じて配分することです。判断軸はシンプルで、繰り返し実行され、結果が安定している領域は自動化に向き、探索的な判断が要る領域は人手が向きます。

対象	担い手	手法	理由
頻繁に繰り返す基本機能の回帰確認	自動化	自動テスト	実行回数が多く、費用対効果が高い
仕様変更の影響を受けやすい周辺機能	外注（人手）	手動テスト	変化が大きく、自動化の維持コストが高い
探索的な観点での品質確認	外注（人手）	探索的テスト	人の判断が品質を左右する
新機能の受け入れ確認	自社＋外注	手動テスト	仕様理解と第三者視点の両方が要る

この線引きは固定ではありません。変化が大きく手動に振っていた周辺機能も、仕様が落ち着いてきたら自動化候補に移す、という動的な見直しが有効です。

2点、前提として押さえておきたいことがあります。探索的テストを外注する場合は、外注先がドメイン（対象業務）を理解するための立ち上げ期間を織り込んでおく必要があります。また、自動テストは「一度作れば無料」ではなく、仕様変更に合わせてテストを直し続ける維持（メンテナンス）コストが乗る点も、配分を決める際に見込んでおきましょう。

ここでは実装の書き方には踏み込みません。PMが押さえるべきは、「どの領域を機械に任せ、どの領域に人の目を残すか」という配分の判断軸です。

CIへの組み込みと外注の役割

CI（継続的インテグレーション）とは、変更を頻繁に統合して不整合を早期に検出する実践で、その中でビルドや自動テストを回します。自動化した回帰テストをここに組み込むと、変更のたびに自動実行される状態を作れます。

ただし、すべての回帰テストを1つのタイミングで回す必要はありません。実務では、実行時間の短い高速スイートをプルリクエスト単位で回し、時間のかかる重い回帰スイートは夜間（nightly）などにまとめて回す、といった実行タイミングの分割が有効です。

この土台があると、外注の役割が明確になります。自動化でカバーしきれない探索的な確認や、変化の大きい領域の手動テストに、人手のリソースを集中できるのです。

自動化とCIの組み込みをより具体的に検討したい場合は、自動回帰テストの実装ガイドが判断の助けになります。外注と自動化の役割分担を設計する前提として押さえておくとよいでしょう。

スプリント内テストと第三者検証の二層で品質を担保する

回帰テストの分担と合わせて整理しておきたいのが、外注の関与を「スプリント内の継続的テスト」と「リリース前の横断的な第三者検証」の二層で捉えることです。ここを誤ると、冒頭で否定した「まとめてテスト前提」を小型で呼び戻してしまいます。

スプリント内テスト：受け入れ基準とDoDで担保する

各スプリントでは、その回で作った機能を継続的にテストします。ここで押さえたいのが、合否を測る基準の階層です。

• 各バックログ項目：その項目の受け入れ基準（AC）を満たすかで合否を判定する
• インクリメント全体：スプリントで積み上がった成果全体が「完成の定義（DoD）」を満たすかで担保する

受け入れ基準は個々の項目の合否を、完成の定義はインクリメント全体の品質を担保するもので、両者は階層が異なります。この階層を分けておくと、「項目は通ったのに全体としては未完成」といった見落としを防げます。

外注は、このスプリント内の継続的テストにも関与します。渡すものが揃うのを待つのではなく、各スプリントの中でテストを積み上げていく形が、前半で述べた反復開発との整合につながります。

リリース前の第三者検証：横断シナリオの補完に限定する

一方で、スプリント内テストだけでは拾いにくい観点もあります。個々のスプリントを横断した、通しのシナリオでの確認です。ここで有効なのが、外注による第三者検証です。

ただし、この第三者検証を「リリース前にまとめてテストする工程」として設計してはいけません。リリース前の第三者検証は、スプリント内で積み上げた品質を横断的に補完する位置づけに限定し、「まとめてテスト」の言い換えにしないことが肝心です。ここを取り違えると、反復開発の中にミニ・ウォーターフォールを埋め込むことになり、冒頭で挙げた「負荷が後ろに寄る」構造を再び招きます。

第三者検証がリリース前に担うのは、あくまで横断的な補完に絞った次の観点です。

• スプリントをまたいだ機能連携の確認
• 全体を通したシナリオでの動作確認
• 開発チームが見落としやすい観点の補完

二層の境界を明文化して二重化・抜け漏れを防ぐ

二層の役割を分けたら、境界を明文化します。境界が曖昧だと、同じ確認を二重にやる無駄か、どちらもやらない抜け漏れのどちらかが起きます。

観点	スプリント内テスト	リリース前の第三者検証
目的	その回の完成（AC・DoD）を担保	横断的な品質を補完
外注の関与	継続的なテストに関与	通しシナリオの第三者検証を担う
範囲	当該スプリントの機能・回帰	スプリント横断・通しシナリオ
タイミング	スプリント内で継続的に	リリース前に横断補完として

この表のように役割を分けた上で、「どの観点はどちらでカバーするか」を事前にすり合わせておくと、二重化と抜け漏れの両方を防げます。外注はどちらの層にも関わりますが、担う目的が違う点を共有しておくことが重要です。

アジャイル開発のテスト外注を始める前に｜PMが確認する判断チェックリスト

ここまでの3点を踏まえ、外注を始める前にPMが確認すべき項目を、チェックリストにまとめます。導入前にひと通り確認しておくと、走り出してからの手戻りを減らせます。

契約・同期・分担の3点セルフチェック

まず、本記事で扱った3つの軸について、自社の準備状況を確認します。

• 契約形態：固定スコープの請負ではなく、変化を前提とした準委任・継続型を選べているか
• 社内調整：法務・購買との調整、偽装請負を避ける指揮命令の設計を織り込めているか
• 変更・区切り・完了の条項：契約に変更前提と区切り、完了の合意方法を織り込めているか
• 単一窓口：外注先とのやり取りを集約する窓口を1人決めているか
• 報告設計：報告頻度とエスカレーション基準を合意できているか
• レトロ組み込み：外注の連携を振り返りの改善ループに乗せる想定があるか
• 回帰テストの配分：自動化する領域と人手（外注）で担う領域を線引きできているか
• 二層の境界：スプリント内テストとリリース前の第三者検証の範囲を分けられているか

これらに「まだ」が多い場合は、外注を始める前に社内で詰めておく余地があります。準備段階でやるべきことを体系的に確認したい場合は、テスト代行を依頼する前の準備を整理した記事が役立ちます。

なお、上のすべてが整っていなくても外注は始められます。CIや自動化基盤、専任窓口が未整備でも、まずは手動テストを外注に出すところから段階的に進めれば十分で、最初から全部を揃える必要はありません。足りない要素は、スモールスタートで回しながら順に整えていく形が現実的です。

上長を説得する費用対効果の整理軸

外注の検討が止まる大きな要因が、上長への説明です。感覚的な「楽になる」では通りません。上長が知りたいのは「で、いくら浮くのか」「月いくらかかるのか」という金額です。

具体額を出せる統計はありませんが、自社の数字を入れれば試算はできます。次の枠に沿って計算すると、費用対効果を金額で語れるようになります。

• 現状の隠れコストを金額化：兼任エンジニアが月に何時間テストに取られているかを洗い出し、「時間 × 人時単価」で現状かかっている隠れコストを金額にする
• 外注見積レンジと並べる：算出した隠れコストと、外注の見積レンジを同じ土俵に並べて比較する
• 金額化しにくい効果を添える：エンジニアが実装に集中できることによる開発速度、本番バグでクライアント信頼を損なうリスクの低減を、補足として添える

「外注費」という支出だけを見せると高く映りますが、兼任で失っている時間を金額化して並べると、費用対効果が具体的な数字で見えてきます。

スモールスタートで検証する進め方

最初から全案件・全工程を外注する必要はありません。むしろ、小さく始めて連携を検証する方が、リスクを抑えられます。

• 1案件・1スプリントなど、範囲を絞って試す
• 契約・同期・分担の仕組みが機能するかを確認する
• レトロで摩擦を洗い出し、次の範囲に広げる前に改善する

スモールスタートで大切なのは、続けるか広げるかを判断する基準を先に決めておくことです。1スプリント後のレトロで、次のような変化が見えているかを確認します。

• 手戻り（差し戻し）の件数が減っているか
• 仕様に関する質問の往復回数が減り、認識合わせが速くなっているか
• 受け入れ基準の解釈のズレが小さくなっているか

外注先を選ぶ段階では、伴走型かどうかを見極めたいところです。判断材料として、「バックログの変更にどう追随してきたか、その実績を具体的に聞く」と、変化前提の運用に耐えられる相手かを見分けやすくなります。まず小さく回して手応えを掴み、そこから広げていくのが現実的です。

アジャイル案件のテスト外注を相談したい方へ

自社のスプリントに外注をどう組み込むか、契約・同期・分担のどこから整えるべきか。個別の状況に合わせて設計を詰めたい場合は、体制設計の段階からのご相談も承っています。アジャイル案件でのテスト外注の組み込み方を具体的に相談したい方は、お気軽にお問い合わせください。

よくある質問

導入検討で問い合わせが多い、次の3点にお答えします。

• 向く契約形態はどれか
• スプリントへの同期の仕方
• 回帰テストの外注と自動化の切り分け

アジャイル開発のテスト外注に向く契約形態は？

準委任や継続型が向きます。範囲が動くたびに結び直す必要がなく、スプリントの変化に追随しやすいためです。固定スコープの請負は変化がコスト化するため相性が良くありません。

スプリントに外注をどう同期させればよいですか？

単一窓口を1人決め、プロダクトバックログと受け入れ基準を共有し、報告頻度とエスカレーション基準を合意します。レトロに組み込み、連携の摩擦を毎スプリント削っていくのが有効です。

回帰テストは外注と自動化のどちらに任せるべきですか？

両方を性質で配分します。繰り返し多く結果が安定した領域は自動化、変化が大きく探索的な判断が要る領域は外注の人手が向きます。線引きは固定せず、安定した領域は自動化候補へ移します。

まとめ｜アジャイル開発のテスト外注は発注設計を変えれば回る

外注が噛み合わないのは、アジャイルに外注が向かないからではなく、ウォーターフォール前提の発注設計をそのまま持ち込んでいるからでした。変えるべきは、次の3点です。

• 契約形態：固定スコープの請負をやめ、変化を前提とした準委任・継続型へ
• スプリントへの同期：単一窓口・報告設計・レトロ組み込みでチームのリズムに乗せる
• 回帰テストの分担：自動化する領域と人手（外注）で担う領域を線引きする

発注設計をアジャイルに合わせて整え直せば、外注はスプリントのリズムを乱す存在ではなく、品質と納期を両立させる戦力になります。

まずはチェックリストで自社の準備状況を確認し、範囲を絞ったスモールスタートから検証してみてください。小さく回して手応えを掴むことが、噛み合う外注への近道です。組み込み方を具体的に詰めたい場合は、体制設計の段階からのご相談もご活用ください。