アジャイル開発を外注するには？契約形態・進め方・パートナー選定の全知識

アジャイル開発は社内チームで実践するものだと思われがちですが、外注パートナーとアジャイルで開発を進める企業が増えています。その背景には、エンジニア採用の困難さと、市場変化に即応するプロダクト開発のスピード要求の高まりがあります。

しかし、ウォーターフォール型の外注の進め方をそのままアジャイルに当てはめると、かえって混乱します。「仕様書を渡してお任せ」という従来型の発注スタイルは、アジャイルの前提と根本的に矛盾するからです。

本記事では、アジャイル開発を外注する際の契約形態の選び方、具体的な進め方、パートナー選定基準、失敗パターンと対策までを体系的に解説します。一般的な外注については システム開発の外注 vs 内製、プロダクト開発に特化した外注は プロダクト開発の外注ガイド を参照してください。

結論 ── アジャイル外注の成否は「発注者のコミットメント」で決まる

アジャイル開発の外注で最も重要なのは、発注側がスプリントごとに優先順位を判断し、フィードバックを返す「プロダクトオーナー（PO）」の役割を果たすことです。 ウォーターフォールのように「仕様書を渡してお任せ」では、アジャイルの利点である柔軟性とスピードが失われます。

PO が最低でも週 5〜7 時間のコミットメントを確保できない場合、アジャイル外注は機能しません。逆に言えば、PO の関与を確保し、適切な契約形態とパートナーを選べば、外注でもアジャイルの恩恵を十分に得られます。

なぜアジャイル開発を外注するのか ── 3 つのメリット

アジャイル開発を外注する企業が増えている背景には、内製では実現しにくい 3 つのメリットがあります。

即戦力チームを短期間で確保できる

アジャイル開発に必要なスキルセット（スクラムマスター、フロントエンド、バックエンド、QA）を社内で一から揃えるには、採用だけで数ヶ月以上かかることも珍しくありません。外注パートナーを活用すれば、すでにチームとして機能しているメンバーをアサインしてもらえるため、プロジェクト立ち上げまでの期間を大幅に短縮できます。

スプリント単位で成果を確認しながら進められる

ウォーターフォール外注では「完成するまで動くものが見えない」リスクがありますが、アジャイル外注では1〜2 週間ごとに動くソフトウェアが納品されます。各スプリントで成果物を確認し、方向修正できるため、「完成後に思っていたものと違う」というリスクを大幅に低減できます。

スケールアップ・ダウンが柔軟にできる

プロダクトのフェーズに応じて、開発チームの規模を柔軟に調整できるのも外注のメリットです。MVP フェーズではエンジニア 2 名でスモールスタートし、プロダクトマーケットフィット後にチームを拡大するといった戦略が取りやすくなります。社員採用と異なり、事業判断に応じたチーム規模の最適化が容易です。

ウォーターフォール外注 vs アジャイル外注 ── 6 つの根本的な違い

アジャイル外注を検討する前に、ウォーターフォール外注との違いを正確に理解しておく必要があります。両者はプロジェクト管理の前提が根本的に異なるため、発注側の関わり方も大きく変わります。

最大の違いは発注者の関与頻度です。ウォーターフォールでは「要件定義を渡して、完成を待つ」スタイルが一般的ですが、アジャイルでは毎スプリント（1〜2 週間ごと）にプランニング・デモ・振り返りに参加し、次のスプリントの優先順位を判断する必要があります。この関与コストを許容できるかどうかが、アジャイル外注を選択するかどうかの最初の判断基準になります。

アジャイル外注に適した契約形態の選び方

アジャイル開発と契約形態の相性は、プロジェクトの成否を直接左右します。契約形態を誤ると、アジャイルの柔軟性が契約上の制約で無効化されてしまいます。

準委任契約 ── アジャイル外注の基本形

準委任契約は、業務の遂行そのものに対して報酬を支払う契約形態です。成果物の完成を約束する請負契約と異なり、「善管注意義務」に基づいて業務を遂行すれば債務を履行したことになります。

アジャイル開発との相性が良い理由は以下の通りです。

• 要件変更が契約違反にならない: スプリントごとに優先順位を変更しても、契約上の問題が発生しない
• スプリント単位の成果確認が自然: 月額 × チーム規模で契約し、スプリントごとに成果物を確認・承認するフローが組みやすい
• チームの継続性を確保しやすい: 月額契約のため、同じメンバーを継続してアサインしてもらいやすい

ただし、準委任契約には「完成義務がない」というリスクもあります。定期的な成果確認と、期待値のすり合わせをスプリントデモで行うことが不可欠です。

請負契約 ── アジャイルとの相性が悪い理由

請負契約は「仕事の完成」を約束する契約形態であり、完成した成果物に対して報酬を支払います。要件が明確に定まっているウォーターフォール型には適していますが、アジャイル開発とは以下の点で矛盾します。

• 要件変更のたびに追加見積もりが必要: 変更のたびに契約変更の手続きが発生し、アジャイルのスピードが失われる
• 「完成」の定義が曖昧になる: アジャイルでは「完成」は反復的に進化するため、請負の「完成義務」と概念的に衝突する
• 契約不適合責任（旧・瑕疵担保責任）の適用が困難: 要件が変化し続けるアジャイルでは、何が「瑕疵」にあたるのか判断しにくい

請負契約が適するケース: アジャイルでプロトタイプを開発した後、仕様が確定した部分（例: 管理画面の CRUD 機能）を請負で切り出して発注する、といったハイブリッドな使い方は有効です。

ラボ型契約 ── 長期チーム固定

ラボ型契約は、一定期間（6 ヶ月〜1 年が一般的）にわたってチームを固定的にアサインする契約形態です。準委任契約の一種ですが、以下の特徴があります。

• チームの安定性: メンバーが固定されるため、ドメイン知識の蓄積が進み、スプリントを重ねるほど生産性が向上する
• 月額固定費: 予算管理がしやすく、長期的なロードマップに基づいた開発計画が立てやすい
• チームビルディングの効果: 長期間同じメンバーで開発するため、暗黙知の共有やコミュニケーションの質が向上する

IPA モデル契約の活用

独立行政法人情報処理推進機構（IPA）は、アジャイル開発に適した『情報システム・モデル取引・契約書（アジャイル開発版）』を公開しています（2020 年 3 月初版公開、最新版は IPA 公式サイトで確認してください）。この契約書は、スプリントごとの成果確認や、PO の役割、知的財産権の帰属などをアジャイルに適した形で定義しており、契約書のたたき台として活用できます。

特にアジャイル開発の外注が初めての企業にとっては、法務部門との交渉を円滑に進めるための有力な参考資料になります。

契約形態の選び方チェックリスト

アジャイル外注の進め方 ── 5 つのステップ

アジャイル外注を成功させるには、パートナー選定から本格稼働まで、段階的に進めることが重要です。以下の 5 ステップに沿って進めることで、リスクを最小化しながら成果を最大化できます。

Step 1: 目的とスコープの明確化

アジャイルだからといって、最初に何も決めなくてよいわけではありません。外注の目的、プロダクトのビジョン、初期のロードマップは、パートナー選定の前に整理しておく必要があります。

整理すべき項目は以下の通りです。

• なぜ外注するのか: 内製リソース不足、スピード重視、特定技術の専門性など
• 何を作るのか: プロダクトのビジョン、ターゲットユーザー、解決する課題
• 初期スコープ: 最初の 3〜6 ヶ月で達成したい目標（MVP の定義など）
• 技術要件: 使用する技術スタック、既存システムとの統合要件
• PO を誰が務めるか: 社内で PO の役割を果たせる人材の確保

Step 2: パートナー選定とトライアル

複数のパートナー候補に対して、RFP（提案依頼書）を出すか、カジュアル面談を実施します。この段階で重要なのは、アジャイル開発の実践経験を具体的に確認することです（後述の「7 つの判断基準」を参照）。

可能であれば、1〜2 スプリント（2〜4 週間）のトライアル期間を設けることを推奨します。トライアルでは以下を評価します。

• チームのコミュニケーション品質（質問の的確さ、レスポンス速度）
• スプリントデモの質（動くソフトウェアを見せられるか）
• 技術的な品質（コードレビュー、テスト、CI/CD の実践度）
• PO との協業スタイル（受け身か、提案型か）

Step 3: 契約締結とオンボーディング

トライアルの結果を踏まえて契約を締結し、本格的なオンボーディングに入ります。

オンボーディングで共有すべき情報は以下の通りです。

• プロダクトのビジョンとロードマップ
• 技術スタック、アーキテクチャ、開発環境のセットアップ手順
• コーディング規約、コードレビューのルール
• コミュニケーションツールとルール（Slack チャンネルの使い分け、レスポンス期待値など）
• スプリントのリズム（長さ、各イベントの曜日・時間）
• 初期バックログ（最低 2 スプリント分）

Step 4: スプリント運用の確立と成熟度の段階

最初の 2〜4 スプリントは「助走期」として、チームのリズムを確立することに集中します。この期間はベロシティが安定しないのが正常です。

助走期に重視すべきポイントは以下の通りです。

• レトロスペクティブ（振り返り）を必ず実施: チームの改善サイクルを最初から組み込む
• ベロシティの計測を開始: ただし、助走期のベロシティで長期計画を立てない
• コミュニケーションの問題を早期に解決: 言語・時差・文化の違いに起因する問題は、初期に対処するほど効果が大きい

アジャイル外注は段階的に成熟していきます。以下のモデルを参考に、現在の段階に応じた期待値を設定してください。

助走期のベロシティが低いことを理由にパートナーを早期に切り替えるのは推奨されません。チームが成熟するまでに 3〜4 スプリント（1.5〜2 ヶ月）は必要です。ベロシティではなく、プロセスの質（コミュニケーション・技術プラクティスの実施状況）で助走期を評価してください。

Step 5: 定期レビューと契約見直し

3 ヶ月ごとに、パートナーシップ全体のレビューを実施します。スプリント単位の振り返りとは別に、中長期的な視点で協業の質を評価します。

レビューの観点は以下の通りです。

• ベロシティの推移（安定しているか、改善傾向にあるか）
• 品質指標（バグ発生率、テストカバレッジ、リリース頻度）
• チームの安定性（メンバーの入れ替わりがないか）
• ROI（投資対効果が期待に見合っているか）
• 契約形態の見直し（準委任からラボ型への移行を検討するタイミング）

パートナー選定の 7 つの判断基準

アジャイル外注の成否は、パートナー選定で大きく左右されます。以下の 7 基準に基づいて評価することで、形だけのアジャイルではなく、実践的にアジャイルを回せるパートナーを見極められます。

選定時の注意点

• 「アジャイルできます」だけでは不十分: 具体的なプラクティスの実施状況を掘り下げて確認する。形だけスクラムを導入して実態はウォーターフォールという企業は少なくない
• チーム単位で評価する: 個人のスキルだけでなく、チームとしての成熟度を見る。すでにチームとして稼働した実績があるか
• リファレンスチェック: 可能であれば、過去のクライアントに協業の実態を確認する

外注チームとのスプリント運用設計

パートナーが決まったら、スプリントの運用設計を行います。スプリントの構成・イベント・役割分担を事前に合意しておくことで、最初のスプリントからスムーズに動き出せます。

スプリントの標準構成（2 週間スプリントの場合）

発注側（PO）が確保すべき時間

合計: 週 5〜7 時間の PO コミットメントが最低限必要です。この時間を確保できない場合、アジャイル外注を選択すべきではありません。ウォーターフォール外注の方が発注側の負荷は低く、要件が確定している案件では合理的な選択肢です。

バックログの書き方 ── PO の最重要スキル

アジャイル外注で PO が最も頻繁に行う作業はバックログアイテムの作成です。開発チームが「何を、なぜ作るか」を正確に理解できるバックログを書けるかどうかが、スプリントの生産性とプロダクトの品質を直接左右します。

バックログアイテムのテンプレート

タイトル: [機能の名前]

ユーザーストーリー:
  [ペルソナ]として、
  [機能/アクション]したい。
  なぜなら[理由/価値]だから。

受け入れ基準:
  - [ ] [条件1]が満たされている
  - [ ] [条件2]が満たされている
  - [ ] エッジケース:[異常系の処理]が定義されている

優先度: Must / Should / Could
見積もり: [ストーリーポイント or 時間]

良いバックログの例

タイトル: ユーザー登録フォーム

ユーザーストーリー:
  新規ユーザーとして、
  メールアドレスとパスワードでアカウントを作成したい。
  なぜなら、サービスの全機能にアクセスできるようになるから。

受け入れ基準:
  - [ ] メールアドレスのフォーマットバリデーションが動作する
  - [ ] パスワードは8文字以上、英数字混合を必須とする
  - [ ] 確認メールが送信され、リンクをクリックすると有効化される
  - [ ] 既存のメールアドレスで登録しようとするとエラーが表示される
  - [ ] 登録完了後、ダッシュボードにリダイレクトされる

優先度: Must

PO が避けるべきバックログの書き方

アジャイル外注で失敗する 5 つのパターンと対策

アジャイル外注の失敗は、多くの場合パターン化されています。以下の 5 つの失敗パターンを事前に認識し、対策を講じることで回避できます。

パターン 1: PO 不在 ── 丸投げ型

症状: 「お任せで」と丸投げし、PO が不在または名ばかり。優先順位が決まらず開発が停滞する。開発チームは何を作るべきか判断できず、手戻りが頻発する。

対策: 社内から PO を専任アサインする。兼務でも最低週 5 時間は確保する。PO が確保できない場合は、アジャイル外注ではなくウォーターフォール外注を検討すべき。

パターン 2: ウォーターフォール偽装

症状: 「アジャイルです」と言いつつ、最初に全要件を決めて変更不可。スプリントは形だけで、実質的にはフェーズごとの進捗報告会になっている。

対策: 契約書に「スプリントごとの優先順位変更が可能」であることを明記する。スプリントプランニングで実際に優先順位の入れ替えを行い、アジャイルの柔軟性を実践する。

パターン 3: チームの頻繁な入れ替え

症状: メンバーが頻繁に交代し、ドメイン知識とコンテキストが失われる。ベロシティが安定せず、毎回オンボーディングからやり直し。

対策: 契約でメンバー固定を条件に入れる。入れ替えが発生する場合は事前通知と引き継ぎ期間（最低 1 スプリント）を契約に盛り込む。長期的にはラボ型契約への移行を検討する。

パターン 4: コミュニケーション不全

症状: 仕様の認識齟齬が頻発し、スプリントデモで「想定と違う」が続く。質問のレスポンスが遅く、開発チームがブロックされる時間が長い。

対策: コミュニケーションルールを事前に合意する。Slack での質問には目安として半日以内に回答する、仕様が不明確な場合は開発チームの判断で進めてよい範囲を定義するなど、具体的なルールを設ける。時差がある場合はオーバーラップ時間を最低 4 時間確保する。

パターン 5: 品質の軽視

症状: スピードを優先するあまり、テストが書かれない、コードレビューが省略される、技術的負債が急速に蓄積する。後工程で品質問題が噴出し、開発速度がかえって低下する。

対策: 「完了の定義（Definition of Done）」にテスト作成、コードレビュー、CI パスを必須条件として含める。スプリントレトロスペクティブで技術的負債を可視化し、バックログに改善タスクを定期的に積む。

費用相場

アジャイル外注の費用は、チーム構成とメンバーの経験レベルによって大きく変動します。以下は複数の開発会社の公開料金・見積もり事例を元にした一般的な目安です。

費用を最適化するためのポイント

• スモールスタート: 最初は小規模チームで開始し、チームの相性と成果を確認してから拡大する
• ラボ型への移行: 6 ヶ月以上の継続が見込める場合、ラボ型契約に移行すると長期契約割引が適用されるケースがある
• オフショアの活用: 東南アジア等のオフショア拠点を活用すると、人件費の地域差によりコストを抑えられる場合がある。ただし、コミュニケーションコストと時差の考慮が必要
• 内製チームとのハイブリッド: コア機能は内製、周辺機能は外注という役割分担で、コストと品質のバランスを取る

よくある質問

まとめ

アジャイル開発の外注は、ウォーターフォールとは根本的に異なるアプローチが必要です。成功のための要点を整理します。

1. 契約は準委任 or ラボ型を基本にする ── 請負契約はアジャイルの柔軟性と矛盾するため、要件が確定した部分の切り出しに限定する
2. PO のコミットメントを確保する ── 週 5〜7 時間の関与がなければアジャイル外注は機能しない。PO を確保できない場合はウォーターフォール外注を選択する
3. チームの安定性を契約で担保する ── メンバー固定を契約条件に入れ、長期的にはラボ型契約への移行を検討する
4. 段階的に進める ── トライアル → 準委任 → ラボ型と、リスクを抑えながらパートナーシップを深化させる
5. 助走期はプロセスの質で評価する ── ベロシティの安定には 3〜4 スプリントが必要。コミュニケーションと技術プラクティスの質を見る