開発会社から「アジャイル開発で進めましょう」と提案を受けたとき、「具体的に自分たちは何をすればいいの？」と感じたことはありませんか。
アジャイル開発は、エンジニアだけのものではありません。むしろ、発注者側（事業会社・ビジネス担当者）の関わり方が、プロジェクトの成否を左右します。
この記事では、アジャイル開発の基本概念から、発注者として具体的にどう関わるか、どんな契約形態が適切か、スプリントレビューへの参加の仕方まで、実践的な視点で解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
アジャイル開発とは
アジャイル開発とは、「小さな単位で作っては確認を繰り返しながら、段階的に完成させていく開発手法」です。
2〜4週間の短いサイクル（スプリント）ごとに「計画→開発→確認→振り返り」を繰り返し、その都度フィードバックを取り込みながら進めます。完成形を最初に確定させるのではなく、「動くものを早く届けて、改善し続ける」というアプローチが特徴です。
アジャイル開発の考え方の根拠
アジャイル開発は「アジャイルソフトウェア開発宣言（2001年）」をベースにしており、以下の価値観を重視します。
- 手順やツールよりも、チーム内の対話
- 網羅的な仕様書よりも、実際に動くシステム
- 契約の遵守よりも、顧客との協調
- 計画に従うよりも、変化への対応
ビジネス環境が速いスピードで変化する現代において、最初に決めた仕様を1年後に届けるより、「3か月で使えるものを出して、フィードバックで改善する」ほうが価値を生み出しやすいため、広く採用されています。
ウォーターフォール開発との違い：発注者視点での比較
従来のウォーターフォール開発とは
ウォーターフォール開発は、「要件定義→設計→開発→テスト→リリース」の各フェーズを順番に進める手法です。次のフェーズに進む前に前のフェーズを完了させるため、全体の設計を最初に決める必要があります。
ウォーターフォール開発の詳細については「ウォーターフォール開発とは？アジャイル開発との違いやメリット・デメリットを解説」もあわせてご覧ください。
発注者にとっての違い
比較項目 | ウォーターフォール | アジャイル |
|---|---|---|
要件の決め方 | 最初に全て決める | 段階的に決める・変更可能 |
成果物を見るタイミング | 完成後（数か月〜1年後） | スプリントごと（2〜4週ごと） |
発注者の関与頻度 | 最初（要件定義）と最後（検収）が主 | 定期的に確認・フィードバックが必要 |
変更のしやすさ | 難しい（設計変更にコストがかかる） | 比較的しやすい（次のスプリントに反映） |
予算管理 | 総額で合意しやすい | スプリント単位での予算管理が必要 |
どちらを選ぶべきか（発注者視点）:
- ウォーターフォール向き: 要件が明確で変更が少ない場合。基幹業務システムの更改、法令対応など
- アジャイル向き: 要件が曖昧・変化しやすい場合。新規サービス開発、ユーザーニーズを探りながら進める場合
アジャイル開発の代表的なフレームワーク
スクラム（SCRUM）
最も広く使われているフレームワークです。2〜4週間の「スプリント」を単位として、計画・開発・確認・振り返りを完結させます。
発注者が最も多く接するフレームワークです。スプリント終了ごとに「スプリントレビュー」と呼ばれる成果確認の場があり、発注者（ステークホルダー）もここで成果を確認します。
カンバン（Kanban）
「やること」「進行中」「完了」のボードで進捗を可視化するフレームワークです。スプリントを設けず継続的に進めるため、運用・保守系の業務に向いています。
XP（エクストリーム・プログラミング）
品質を最重視し、テスト駆動開発やペアプログラミングを実践するフレームワークです。技術的な規律を重視するため、品質要求が高い開発に採用されます。
発注者としてのアジャイル開発への関わり方
アジャイル開発において、発注者（ビジネス側）の関与は成功の鍵です。「開発会社に任せきり」では、方向性のズレが生じやすくなります。
発注者に求められる主な関わり
1. 要件・優先度の決定
アジャイル開発では、実装する機能の優先順位を「プロダクトバックログ」という一覧で管理します。どの機能を先に作るかを決める意思決定は、発注者側の責任です。
開発会社に「何でもやってください」と丸投げすると、ビジネス価値の低い機能が先に作られたり、方向性がズレていきます。
2. スプリントレビューへの参加
スプリント（2〜4週）ごとに行われるスプリントレビューには、可能な限り参加することが推奨されます。
スプリントレビューでは、開発チームが実際に動く機能を見せてくれます。この場で「想像と違う」「こちらを先に進めてほしい」といったフィードバックを行うことが、アジャイル開発の価値を最大化します。
スプリントレビューへの参加は1〜2時間程度の工数が目安です。すべての定例会議に参加する必要はなく、スプリントレビューと優先度の確認会議（スプリントプランニング）への参加が特に重要です。
3. 素早い意思決定
アジャイル開発では「変更はいつでも歓迎」ですが、変更の意思決定が遅れると開発が止まります。担当者レベルで意思決定できる体制を整えるか、エスカレーションのルートを事前に決めておくことが大切です。
プロダクトオーナーの役割
スクラム開発では「プロダクトオーナー（PO）」という役割があります。プロダクトオーナーは、製品の価値を最大化する責任者で、要件の優先順位を決定し、開発チームの疑問に答える役割を担います。
外注でアジャイル開発を進める場合、プロダクトオーナーをどちら側に配置するかはプロジェクトによって異なります。
ケース | 推奨する配置 |
|---|---|
発注者側にアジャイル開発の経験がある | 発注者側がPOを担当する |
発注者側の担当者が業務に追われていてPOに専念できない | 開発会社側がPOを担当し、発注者はステークホルダーとして参加する |
初めてアジャイル開発を試みる | まず開発会社にPOを任せ、プロセスを学びながら段階的に引き継ぐ |
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
アジャイル開発で外注する際の契約形態
アジャイル開発を外注する場合、契約形態の選択が非常に重要です。
準委任契約が基本
アジャイル開発では、準委任契約（時間・工数単位での契約） が一般的です。
契約形態 | 特徴 | アジャイルとの相性 |
|---|---|---|
請負契約 | 完成した成果物に対して代金を払う | 不向き（仕様変更のたびに契約変更が必要） |
準委任契約 | 業務の遂行（工数・時間）に対して代金を払う | 向いている（仕様変更に柔軟に対応できる） |
準委任契約では、「何ができたか」よりも「どれだけの工数で取り組んだか」に対して支払います。これがアジャイル開発の「変化への対応」という価値観に合致しています。
準委任契約での予算管理のポイント
準委任契約での発注では、以下の点を押さえておくことが重要です。
- スプリント単位で予算を設定する: 1スプリント（2〜4週間）ごとの予算上限を決め、その範囲内で最大限の機能を実装してもらう
- バックログの優先順位が予算の使い方を決める: 予算が限られている場合は、重要度の高い機能から着手するよう優先順位をコントロールする
- 追加要件はバックログに積む: 途中で「やっぱりこれもやりたい」という要件が出たら、バックログに追加し、優先度を他の項目と比較して決定する
IPA発行のモデル契約書を活用する
情報処理推進機構（IPA）が「アジャイル開発外部委託モデル契約」を公開しています。アジャイル開発での外注を初めて検討する場合は、このモデル契約書を参考にすることで、準委任契約の基本的な構造を理解できます。
アジャイル開発のメリットとデメリット
メリット
変化に柔軟に対応できます
ビジネス環境の変化に応じて、優先度の高い機能から着手できます。市場の反応を見ながら方向転換することも可能です。
早い段階から成果を確認できます
スプリントごとに動く機能が完成するため、完成まで待たずに投資対効果を確認できます。「作ってみたら想像と違った」というリスクを早期に発見できます。
問題を早期に発見・解消できます
定期的なレビューと振り返り（レトロスペクティブ）により、課題を蓄積させず継続的に改善できます。
デメリットと対策
発注者側にも継続的な関与が必要です
スプリントレビューへの参加、優先度の意思決定など、発注者側の工数が発生します。「完成したら知らせて」というスタンスではアジャイル開発はうまくいきません。
対策: 専任の担当者を決め、週2〜4時間程度の関与時間を確保しましょう。
総費用が見えにくい点があります
準委任契約では「いくらかかるか」が最初から明確でない場合があります。
対策: スプリント単位での予算上限を設定し、定期的に進捗と費用を確認しましょう。
スコープが広がりやすい傾向があります
柔軟に変更できるため、機能追加が際限なく続くリスク（スコープクリープ）があります。
対策: バックログを定期的に棚卸しし、「やらないこと」も明確にしましょう。
アジャイル開発の失敗パターンと対策
発注者の関与不足
最も多い失敗パターンは、発注者が「お任せ」になってしまうことです。スプリントレビューに参加せず、フィードバックを返さないと、開発チームが誤った方向で進んでしまいます。
対策: スプリントレビューを必須イベントとして発注者側のカレンダーに組み込みましょう。
要件の意思決定が遅い
「上司に確認してから」「会議で決める」というプロセスが発生すると、開発のスピードが落ちます。
対策: 担当者レベルで一定範囲の意思決定ができる権限を委譲しておきましょう。
アジャイルの形だけを取り入れる
「スプリントを設けているが、フィードバックを次に活かさない」「スプリントレビューがただの報告会になっている」というケースです。
対策: アジャイルの価値観（変化への対応・協調）を発注者側も理解した上で取り組むことが大切です。
アジャイル開発はどんなプロジェクトに向いているか
以下に当てはまるプロジェクトでは、アジャイル開発の採用を検討してください。
- 新規サービス・新規事業の開発: ユーザーニーズや市場の反応が不確かで、方向転換が起きやすい
- 競合の動向が速い領域: 素早くリリースして市場の反応を得ることが優先される
- 要件が曖昧なまま着手が必要: 「まず動くものを作って、見てから決めたい」というケース
- 社内の既存システムの段階的改善: 一気にリプレイスするのではなく、優先度の高い機能から順次改善
アジャイル開発の進め方：最初の一歩
はじめてアジャイル開発に取り組む場合は、以下のステップで進めることをおすすめします。
- 小規模なPoC（概念実証）から始める: 最初から大規模なシステムをアジャイルで開発するのではなく、まず1機能・1サービスで試してみましょう
- 担当者を決める: 発注者側でスプリントレビューに参加し、意思決定できる担当者を1名以上選定します
- 開発会社とコミュニケーション設計を合意する: スプリントレビューの日程、日常的な連絡手段、意思決定の権限範囲を最初に決めておきます
- バックログ管理ツールを共有する: Jira・Trello・Backlogなどのツールで、バックログを発注者と開発会社で共有します
アジャイル開発に関するよくある質問
Q. アジャイル開発は予算が青天井になりませんか？
準委任契約であっても、スプリント単位で予算上限を設定することで管理できます。「このスプリントで○○万円以内に収める」というルールを最初に合意しておくことが大切です。
Q. 発注者側にエンジニアがいなくても大丈夫ですか？
技術的な判断は開発チームに任せ、発注者はビジネス上の優先度と意思決定を担当する形で問題ありません。「どの機能が事業にとって重要か」を決める役割は、エンジニアでなくても担えます。
Q. スプリントレビューにはどのくらい時間が必要ですか？
1〜2時間程度が一般的です。スプリントの長さ（2〜4週間）に比例します。毎日参加する必要はなく、スプリントレビューと優先度確認の場だけ参加する形でも機能します。
Q. ウォーターフォールとアジャイルを組み合わせることはできますか？
できます。大枠の要件定義はウォーターフォールで行い、実装フェーズはアジャイルで進めるハイブリッドアプローチも一般的です。重要なのは、発注者・開発会社の双方がどのフェーズでどのプロセスを採用するかを共通理解することです。
Q. アジャイル開発で失敗しないために最も重要なことは？
発注者側の継続的な関与です。「完成したら知らせて」ではなく、スプリントレビューに参加し、フィードバックを返し、優先度の意思決定を速やかに行うことが成功の鍵です。
まとめ
アジャイル開発は、発注者と開発チームが協力して進める手法です。「開発会社に任せきり」では本来の価値を発揮できません。
発注者として押さえておくべきポイントをまとめます。
- 準委任契約を基本とし、スプリント単位で予算を管理する
- スプリントレビューへの参加と素早いフィードバックが成功の鍵
- 優先度の意思決定は発注者側の責任として担当者に権限を持たせる
- プロダクトオーナーの役割（誰が担うか）を最初に合意しておく
- 初めての場合は小規模なPoCから始め、アジャイルのプロセスに慣れる
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
