新規事業や業務システムの開発を、アジャイル開発で外注しようと検討し始めた。けれど調べていくうちに「アジャイルは発注者も毎週関与しないと回らない」という話を目にして、急に不安になった——こうした状況に置かれている発注担当の方は少なくありません。
社内に専任のプロダクトオーナー（PO）を立てられる人員はおらず、自分が片手間で発注を担うことになりそう。準委任契約だと聞いて「スプリントごとに予算が膨らんでいくのではないか」という懸念もある。開発会社は「うちはアジャイルです」と言うけれど、その実態がウォーターフォールと変わらないものだったらどうしよう。そして経営層からは「予算を膨らませるな」「失敗するな」とプレッシャーをかけられている。
アジャイル開発の外注は、ウォーターフォールの外注とは管理の勘所がまったく異なります。要件を固めて丸投げできるウォーターフォールと違い、アジャイルは発注者が「意思決定の当事者」として関わり続ける構造になっているからです。この違いを理解しないまま契約を結ぶと、方向性のブレ・スコープの肥大化・コストの青天井化といったリスクが現実のものになります。
ただし、これらのリスクは「アジャイル外注特有の構造的なもの」として事前に整理でき、適切な体制と契約の歯止めを用意すれば十分にコントロールできます。専任POを立てられなくても、現実的に回る代替体制は存在します。
本記事では、アジャイル開発の外注で発注者が直面する5つのリスクを体系的に整理したうえで、専任POを立てられない前提でも失敗しない体制構築の3ステップ、コスト超過を防ぐ契約条項、そしてフェーズ別の実行チェックリストまでを解説します。読み終えたとき、「自社の体制で何を準備し、契約で何を確認すればよいか」が明確になり、社内や開発会社との会話を主導できる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ウォーターフォール外注との違い：なぜ発注者の関与が必要になるのか
アジャイル外注のリスクを正しく把握するには、まず「なぜ発注者の関与が必要になるのか」という構造を理解することが出発点になります。ここがウォーターフォール外注との最大の違いであり、多くの不安の根っこでもあります。
なお、アジャイル開発そのものの概念やメリット・デメリットを改めて確認したい方は、アジャイル開発とはをあわせてご覧ください。本記事では概念解説には踏み込まず、「外注時のリスク管理」に集中します。
ウォーターフォール外注は「要件確定→丸投げ」で成立する
ウォーターフォール型の開発では、プロジェクトの最初に要件定義を固め、仕様書という形で完成形を確定させます。発注者の役割は、この要件定義フェーズで「何を作るか」を漏れなく伝えることに集中します。
要件が確定したあとは、開発会社が仕様書どおりに設計・実装・テストを進めます。発注者は中間のレビューには立ち会うものの、基本的には「要件を渡したら、あとは完成を待つ」という関与の仕方が成立します。極端に言えば、要件確定後は丸投げに近い形でもプロジェクトが進む構造になっているわけです。
この「丸投げできる」感覚に慣れていると、アジャイル外注でも同じように考えてしまいがちです。しかし、ここに落とし穴があります。
アジャイル外注は発注者が「優先順位の意思決定者」になる
アジャイル開発は、最初にすべての要件を固めません。短い開発サイクル（スプリント、通常1〜2週間）を繰り返しながら、動くものを少しずつ作り、その都度フィードバックを反映して方向性を調整していきます。不確実性の高い新規事業やDX領域でアジャイルが選ばれるのは、この「作りながら正解を探せる」柔軟性があるからです。
この進め方では、「次のスプリントで何を優先して作るか」を誰かが決めなければなりません。そして、その優先順位を決める最終的な責任者は、原則として発注者側にあります。なぜなら、何にビジネス上の価値があるかを判断できるのは、その事業を持っている発注者だからです。
つまりアジャイル外注では、発注者は「要件を渡す人」ではなく「優先順位を継続的に決める意思決定者」になります。この役割を担うのが、本記事で繰り返し登場するプロダクトオーナー（PO）です。アジャイルが「発注者の関与を前提とする」と言われるのは、この意思決定者としての役割が外注先に丸投げできないものだからです。
関与の実態は「毎日」ではなく「週次の判断」が中心
ここで多くの発注担当者が抱く不安が「では毎日、開発に張り付かないといけないのか」というものです。結論から言えば、その心配は過剰です。
アジャイル外注で発注者に求められる関与の中心は、スプリントの区切りで行われる「スプリントレビュー」への参加と、そこでの優先順位の判断です。スプリントが1週間なら週1回、2週間なら隔週で、完成した成果物を確認し、次に何を作るかを判断する——これが関与の実態です。日々の開発タスクの管理や進捗の細かいコントロールは、開発会社側のスクラムマスターやリーダーが担います。
もちろん、レビューの合間にチャットツールで質問に答えたり、仕様の細かい確認に応じたりする場面はあります。しかしそれは「毎日張り付く」こととは異なります。発注者の関与の本質は、作業の指揮ではなく「判断の提供」にあります。この区別を押さえておくと、後述する偽装請負の論点や、専任POを立てられない場合の代替体制も理解しやすくなります。
アジャイル開発の外注で発注者が直面する5つのリスク
ここからが本記事の中核です。アジャイル開発の外注で発注者が直面するリスクを、ウォーターフォール外注の一般論とは切り分けて、アジャイル特有のものとして5つに整理します。それぞれ「何が起きるか」「なぜ起きるか」「どんな兆候で気づけるか」の順で見ていきます。漠然とした怖さを、特定された5つの管理対象に変換するのがこのセクションの目的です。
リスク①：プロダクトオーナー不在で方向性がブレる
何が起きるか：意思決定者が不在のまま開発が始まると、スプリントごとに「次に何を作るか」が決まらず、開発チームが指示待ちで止まる、あるいは開発会社の独断で方向性が決まっていきます。気づいたときには、ビジネス上欲しかったものとは違うものができあがっている、という事態になります。
なぜ起きるか：先ほど述べたとおり、アジャイルは優先順位を継続的に決める人を必要とします。社内に専任POを立てられず、片手間の担当者が判断を後回しにすると、判断の空白が生まれます。アジャイルは判断の連続で進むため、判断が滞ると開発全体が滞ります。
気づける兆候：「優先順位を決める会議に発注者側の決裁権を持つ人が出ていない」「スプリントレビューで質問しても社内で持ち帰りばかりになり、次のスプリントまでに回答が返せない」「開発会社から『これはどちらを優先しますか』と聞かれても即答できない場面が続く」。こうした状況が見えたら、このリスクが顕在化しかけています。
このリスクへの対処が、後述する体制構築の3ステップの中でも最重要のテーマになります。
リスク②：スプリントスコープクリープで予算が膨らむ
何が起きるか：「ついでにこの機能も」「やっぱりここはこう変えたい」という要望が毎スプリント積み上がり、当初想定していなかった作業が際限なく続きます。アジャイルの「柔軟に変更できる」という長所が、歯止めのない仕様追加（スコープクリープ）に転じ、結果として開発期間と費用が当初想定を大きく超えていきます。
なぜ起きるか：アジャイルは仕様変更を歓迎する開発手法です。この柔軟性は本来の強みですが、「追加するたびにコストと期間が増える」という当たり前の事実が、発注者側で意識されにくくなります。準委任契約の場合は作業時間に対して費用が発生するため、追加要望が増えるほど請求額も増えていきます。
気づける兆候：「当初のリリース目標日が何度も後ろにずれている」「プロダクトバックログ（やることリスト）の項目が減るどころか毎スプリント増え続けている」「『この機能を入れると何スプリント分増えるか』を誰も把握していない」。スコープが膨らんでいるのに、それがコストと納期に与える影響が可視化されていない状態が危険信号です。
リスク③：「偽装アジャイル」で実態がウォーターフォールと変わらない
何が起きるか：開発会社が「アジャイルでやります」と説明しているのに、実態はスプリント計画もレビューも形骸化していて、結局は最初に決めた仕様を黙々と作るだけ——いわゆる「名ばかりアジャイル」「偽装アジャイル」の状態です。この場合、アジャイルを選んだはずなのに柔軟性のメリットを得られず、かつウォーターフォールのような明確な完成責任もない、という最悪の組み合わせになりかねません。
なぜ起きるか：アジャイルは運用の難易度が高く、開発会社側に十分な経験がないと「アジャイルという名前だけ借りて、中身は従来型」になりがちです。発注者にアジャイルの運用経験がないと、形骸化に気づけません。
気づける兆候：「スプリントの最初に『今回のスプリントで何を作るか』を合意する場（スプリント計画）がない」「スプリント終了時に動くものを見せてもらえず、進捗報告書だけが届く」「プロダクトバックログを見せてほしいと言っても出てこない」。これらの兆候は、後述する「偽装アジャイルを見抜く」セクションで具体的なチェック観点として整理します。
リスク④：準委任契約のコスト超過と「終わらない開発」
何が起きるか：アジャイル外注で多く採用される準委任契約は、成果物の完成ではなく「業務の遂行」に対して報酬を払う契約形態です。このため、ゴールが不明確なまま進むと「いつまで経っても完成と言えず、費用を払い続ける」という構造的な問題が起きます。
なぜ起きるか：準委任契約には、請負契約のような「成果物を完成させる義務（仕事の完成責任）」がありません。これはアジャイルの柔軟性と相性が良い反面、発注者側が「どこまで作れば終わりか」のゴールを管理しないと、終わりのない開発になりやすいということでもあります。契約形態そのものの定義や違いについては、請負と準委任契約の違いで詳しく解説しています。
気づける兆候：「『このプロジェクトの完成（リリース）の定義』が契約書にも合意事項にも書かれていない」「予算の上限が決まっておらず、毎月の請求額が積み上がっていくだけになっている」「『あと何スプリントで一区切りつくのか』という見通しを誰も示せない」。ゴールと予算上限の両方が曖昧な状態が、このリスクの温床です。
リスク⑤：コミュニケーション過負荷で発注者側が疲弊する
何が起きるか：兼任の発注担当者が、本来の業務をこなしながら週次のスプリントレビューに出席し、チャットでの質問対応に追われ、優先順位の判断を求められ続けて疲弊します。疲弊した担当者は判断の質が落ち、レビューを欠席するようになり、結果としてリスク①（方向性のブレ）を引き起こす——という悪循環に陥ります。
なぜ起きるか：アジャイルは密なコミュニケーションを前提とする手法です。専任の担当者がいれば負荷を吸収できますが、片手間の兼任担当者にすべてが集中すると、容量を超えます。「アジャイルだから常時連絡が取れる体制にしてほしい」という開発会社側の善意の要求が、かえって兼任担当者を追い込むこともあります。
気づける兆候：「発注担当者が本来の業務に手が回らなくなっている」「チャットの通知が常に鳴り続け、質問への返信が遅れがちになっている」「スプリントレビューの準備が前日まで手つかずになる」。担当者個人の頑張りでなんとか回している状態は、長続きしません。この負荷をどう設計で抑えるかも、体制構築のステップで扱います。
偽装アジャイルを見抜く：発注者がチェックすべきサイン
リスク③で触れた「偽装アジャイル」は、発注者にとって最も判断が難しいリスクです。そこでこのセクションでは、発注者自身が「このアジャイルは本物か」を見分けられるチェック観点を整理します。
なお、ここで扱うチェックは主にパートナー選定フェーズと初回スプリントで行うものです。契約を結ぶ前、そして開発が始まった最初の数スプリントで「この会社のアジャイルは実態を伴っているか」を見極めるための観点として読んでください。開発が軌道に乗ってからの恒常的なチェックは、後述のチェックリストで扱います。
本物のアジャイルに必ずある4つの要素
スクラム（代表的なアジャイル開発の枠組み）で運用されているなら、以下の4つの要素が必ず存在します。発注者はこれらが実際に行われているかを確認することで、アジャイルの実態を判断できます。
- スプリント計画：各スプリントの開始時に「今回のスプリントで何を作るか」を発注者と開発チームが合意する場です。ここがないと、何を基準に開発が進むのかが不明になります。
- スプリントレビュー：各スプリントの終了時に「動くもの」を実際に見せてもらい、フィードバックする場です。資料での進捗報告ではなく、実際に触れる成果物が示されるのが本物の証です。
- プロダクトバックログ：やるべきこと（機能・要望）を優先順位順に並べたリストです。発注者がいつでも見られる状態で管理され、優先順位が更新されていることが重要です。
- ふりかえり（レトロスペクティブ）：開発チームが自分たちの進め方を見直し、改善する場です。これは開発会社内部の活動ですが、「改善のサイクルを回しているか」を尋ねることで運用の成熟度がわかります。
偽装アジャイルの危険信号
逆に、以下のような兆候が見られる場合は、アジャイルの看板を掲げていても実態が伴っていない「偽装アジャイル」の可能性を疑うべきです。
- 計画なきスプリント：スプリントの開始時に合意の場がなく、いつのまにか作業が始まっている。
- 見えないバックログ：プロダクトバックログを共有してほしいと頼んでも出てこない、あるいは更新されていない。
- 提示されない進捗：スプリントレビューで動くものが見られず、進捗報告書やガントチャートだけが届く。これは実態がウォーターフォールである典型的なサインです。
- ベロシティが示されない：「1スプリントでどれくらいの量を消化できるか（ベロシティ）」の実績を尋ねても答えが返ってこない。本物のアジャイルなら、過去スプリントの実績から今後の見通しを示せるはずです。
これらのサインは、契約前のヒアリングや初回スプリントの観察で十分に確認できます。「御社ではスプリント計画とレビューをどう運用していますか」「過去案件のバックログとベロシティの実例を見せてもらえますか」と質問するだけでも、相手の理解度は透けて見えます。
「偽装請負」と疑われないための関与の線引き
偽装アジャイルとは別に、発注者側が注意すべき法的な論点が「偽装請負」です。アジャイル開発は発注者の密な関与を前提とするため、関与の仕方を誤ると、外部委託でありながら実態として発注者が開発会社の従業員に直接指揮命令している（＝偽装請負）と判断されるリスクがあります。
この点については、厚生労働省が「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）に関する疑義応答集（第3集）」で、アジャイル型開発と契約方式の関係を整理しています（厚生労働省 疑義応答集（第3集）、2021年）。ポイントは、偽装請負とは「請負契約等の形式をとりながら、実態として発注者が受注者の雇用する労働者に対して直接具体的な指揮命令をして作業を行わせている場合」を指す、という点です。
実務上の線引きはシンプルです。発注者が行ってよいのは「何を作るか（What）」の優先順位の提示やフィードバックであり、「誰がどう作るか（How・Who）」という個々の作業者への直接的な指示は開発会社側が行う、という役割分担を守ることです。スプリントレビューで「この機能の優先度を上げてほしい」と伝えるのは適正な関与ですが、特定のエンジニアに「あなたは今日この実装をやって」と直接指示するのは指揮命令にあたり得ます。
なお、契約形態として準委任を選ぶこと自体や、請負との違いについては請負と準委任契約の違いで詳しく整理しています。アジャイル外注では「適正な関与の範囲を守る」ことが、偽装請負リスクと偽装アジャイルリスクの両方を避ける鍵になります。
リスクを最小化する発注者の体制構築3ステップ
ここまで整理してきたリスクに対する、実践的な解決策がこのセクションです。最大のポイントは「専任のプロダクトオーナーを立てられない」という前提でも現実的に回る体制を作ることです。「POが重要です」という一般論ではなく、POを専任で置けないときにどう設計するかを具体的に示します。
Step1：プロダクトオーナー代替体制を設計する
最初のステップであり、本記事で最も重要なポイントが「PO代替体制の設計」です。専任POを立てられない場合、POの役割を「一人で担う」のではなく「分担して担う」発想に切り替えます。
POの仕事を分解すると、大きく次の3つに分けられます。
POの役割 | 内容 | PO不在時の担い手 |
|---|---|---|
ビジネス上の優先順位判断 | 何にビジネス価値があるかを決める | 発注者側の兼任PO（事業を理解する社内担当者） |
バックログの整備・詳細化 | 要望を開発可能な単位に分解・整理する | 開発会社側のプロキシPO（PO代行） |
日々の細かい仕様判断 | 実装中に生じる細部の問い合わせ対応 | 兼任POが事前に決めた判断基準＋プロキシPO |
ここでの肝は2つです。
1つ目は「兼任PO」の役割を、判断に必要な最小限に絞ることです。兼任POが担うべきなのは「ビジネス上の優先順位を決める」という、社内の人間にしかできない判断だけです。バックログを開発可能な粒度に書き下す作業や、実装中の細かな技術的判断まで抱え込むと、リスク⑤の過負荷に直結します。兼任POは「週に1回、優先順位を決める意思決定者」と割り切ることで、片手間でも務まる役割になります。
2つ目は「プロキシPO（PO代行）」を開発会社側に置くことです。経験のある開発会社であれば、発注者の代わりにバックログを整備し、優先順位案を準備し、日々の仕様確認をさばく「プロキシPO」を立てられます。発注者の兼任POは、プロキシPOが用意した優先順位案に対して「これでよい／ここは順序を変えたい」と判断するだけで済みます。ゼロから考えるのではなく、用意された案に判断を下す形にすることで、発注者の負荷は大幅に下がります。
あわせて意思決定の権限範囲を明確化しておくことも欠かせません。たとえば「予算◯円・納期◯日以内に収まる仕様変更はプロキシPOの判断で進めてよい。それを超える変更は兼任POの承認を要する」というように、誰がどこまで決めてよいかの線引きを最初に合意します。これにより、些細な判断のたびに発注者へ問い合わせが集中する事態を防げます。
少人数でも回る形を一例として示すと、次のようなイメージです。
- 発注者側：兼任PO 1名（週1回のレビューで優先順位を判断。それ以外は本来業務）
- 開発会社側：プロキシPO 1名（バックログ整備・優先順位案の作成・日々の仕様確認）＋スクラムマスター＋開発メンバー
- 事前合意：仕様変更の権限範囲（金額・納期の閾値）、判断に迷う場合のエスカレーション先
実際、開発会社の中には「社内に開発部門ができたような体制」を掲げ、週次定例とリアルタイムのチャット対応で発注者の片手間運用を支える形を取るところもあります。秋霜堂株式会社が提供する開発支援も、こうした「発注者にPO専任者がいなくても回る」体制を前提に設計されています。重要なのは、PO代行を担える経験のあるパートナーを選ぶこと自体が、この代替体制を成立させる前提になるという点です。
Step2：スプリントレビューへの参加ルールを決める
体制の次に決めるのが「スプリントレビューにどう関わるか」のルールです。ここを曖昧にすると、リスク⑤の過負荷か、リスク①の関与不足のどちらかに振れてしまいます。
決めるべきは次の3点です。
- 参加頻度：スプリントの区切りに合わせ、週1回または隔週1回に固定します。
- 出席者：必ず「優先順位を決められる人（兼任PO）」が出席します。決裁権のない担当者だけが出ても、その場で判断ができず持ち帰りが発生し、リスク①につながります。
- 判断事項：レビューで何を決めるかを事前に定めます。基本は「今スプリントの成果物を受け入れるか」と「次スプリントの優先順位」の2点に絞ります。
時間は週次30〜60分を目安にします。アジャイルの密なコミュニケーションというと長時間の拘束を想像しがちですが、プロキシPOが論点を整理しておけば、発注者が判断に費やす時間は週1時間以内に収まるのが現実的なラインです。「毎日張り付く」必要がないことを、ここでルールとして明文化しておくと、社内の合意も得やすくなります。
Step3：バックログ管理と優先度決定プロセスを確立する
最後のステップは、スコープとコストの暴走（リスク②・④）を防ぐ仕組みづくりです。
まず優先順位は「誰が・いつ・どう決めるか」を明文化します。たとえば「プロキシPOが毎週のレビュー前日までに優先順位案を提示し、兼任POがレビューの場で確定する」というように、決定のプロセスと責任者を固定します。これが決まっていないと、優先順位が宙に浮き、リスク①が再燃します。
そのうえでスコープ追加時の予算ルールをセットで定義することが、コスト管理の決め手になります。具体的には、新しい要望がバックログに追加されるたびに「それを実現するのに何スプリント（＝おおよそいくらの追加費用）かかるか」を開発会社に見積もってもらい、兼任POが「追加する／見送る」を判断する流れを作ります。
この「追加には必ずコストと期間の見積もりが伴い、発注者が取捨選択する」というプロセスがあるだけで、リスク②のスコープクリープは大きく抑えられます。何でも「ついでに」追加されるのではなく、一つひとつが予算と納期への影響とセットで判断されるようになるからです。優先度決定とコスト管理を切り離さず、一体のプロセスとして設計することがポイントです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
アジャイル外注に適した契約形態と確認すべき条項
体制と並んで、リスクを契約段階で抑え込む視点も欠かせません。このセクションでは、アジャイル外注での契約の勘所を整理します。契約形態そのものの定義は請負と準委任契約の違いに譲り、ここでは「アジャイル外注で契約に何を盛り込むか」に集中します。
アジャイル外注で準委任が選ばれやすい理由
アジャイル開発では、準委任契約が選ばれやすい傾向があります。理由は、アジャイルが「最初に成果物を確定させない」開発手法だからです。
請負契約は「あらかじめ定めた成果物を完成させる」ことに対して報酬を払う契約です。しかしアジャイルは、作りながら仕様を調整していく前提なので、契約時点で完成形を確定できません。完成形が確定できないものに「完成責任」を負わせる請負契約は、アジャイルの進め方と構造的に噛み合いにくいのです。
一方、準委任契約は「業務の遂行（＝専門家としての労務の提供）」に対して報酬を払う形態なので、仕様が変わり続けるアジャイルと相性が良いとされます。ただし、リスク④で述べたとおり、準委任は完成責任がない分、ゴールと予算を発注者が管理しないと「終わらない開発」になりやすい弱点があります。だからこそ、次の契約条項による歯止めが重要になります。
コスト超過を防ぐ契約条項チェック
準委任契約のコスト超過リスクに対しては、契約段階で次のような歯止めを盛り込むことを検討します。これらは「青天井に払い続けるのが怖い」という不安への、実務的な回答です。
- スプリント単位・期間単位の予算上限：「1スプリントあたりの費用」や「四半期ごとの予算上限」を明記し、上限に達したら一度仕切り直す取り決めを入れます。準委任でも、予算の天井を契約で設けることは可能です。
- 中途終了条項：成果が期待に満たない場合や、一定の区切りでプロジェクトを終了・見直しできる条項を入れます。準委任契約は比較的柔軟に終了しやすい性質がありますが、解約の予告期間や精算方法を明確にしておくと安心です。
- 進捗報告義務：スプリントごとに「何を完成させたか」「バックログの消化状況」「次スプリントの計画」を報告する義務を定めます。これは偽装アジャイル対策（進捗の可視化）とコスト管理の両方に効きます。
- 成果物の取り扱い：開発したソースコードや成果物の著作権・利用権が発注者に帰属することを明記します。準委任では成果物の権利関係が曖昧になりやすいため、契約で明確にしておきます。
これらの条項は、いずれも「アジャイルの柔軟性を損なわずに、コストとゴールの歯止めを設ける」ためのものです。柔軟性とコントロールは二者択一ではなく、契約設計で両立できます。
発注者が実行すべきリスク管理チェックリスト（フェーズ別）
ここまでの内容を、発注者がそのまま使えるフェーズ別のチェックリストに集約します。「結局、何から手をつければいいか」という問いに、具体的なアクションで答えるのがこのセクションです。
パートナー選定時のチェック項目
開発会社を選ぶ段階で確認すべき項目です。偽装アジャイルを契約前に見抜くことが目的です。
- スプリント計画・スプリントレビュー・バックログ・ふりかえりの4要素を実際に運用しているか確認したか
- 過去案件のプロダクトバックログやベロシティの実例を見せてもらえたか
- 発注者にPO専任者がいない場合に、プロキシPO（PO代行）を立てられるか確認したか
- 「動くものを毎スプリント見せる」ことを前提に話が進むか（進捗報告書だけで済ませようとしていないか）
- アジャイル開発の実績・経験が、看板だけでなく具体的なエピソードで語られたか
契約時のチェック項目
契約を結ぶ段階で、コスト超過と「終わらない開発」を防ぐための項目です。
- スプリント単位または期間単位の予算上限を契約に明記したか
- 中途終了条項（解約の予告期間・精算方法）を定めたか
- スプリントごとの進捗報告義務を契約に盛り込んだか
- 成果物（ソースコード等）の権利が発注者に帰属することを明記したか
- このプロジェクトの「一区切り（リリース）の目安」について認識をすり合わせたか
- 仕様変更の権限範囲（金額・納期の閾値）と承認フローを合意したか
プロジェクト進行中（各スプリント）のチェック項目
開発が始まってから、各スプリントで継続的に確認する項目です。
- 兼任PO（優先順位を決められる人）がスプリントレビューに出席しているか
- スプリントレビューで「動くもの」を実際に確認できているか
- プロダクトバックログが更新され、いつでも閲覧できる状態か
- 新しい要望を追加する際、コストと期間の見積もりとセットで判断しているか
- 発注担当者が過負荷になっていないか（質問対応・判断が一人に集中していないか）
- 発注者の関与が「優先順位の提示・フィードバック」にとどまり、個々の作業者への直接指揮になっていないか（偽装請負の回避）
これらのチェックリストは、印刷するなりコピーするなりして、選定・契約・各スプリントの節目で実際に手を動かしながら使うことを想定しています。
まとめ：アジャイル外注を成功させるために発注者が担う役割
アジャイル開発の外注は、ウォーターフォールのように「丸投げ」できないからこそ難しく感じられます。しかし、本記事で見てきたとおり、その難しさは「特定された管理対象」に分解でき、適切な準備で十分にコントロールできます。
改めて要点を振り返ります。
- アジャイル外注で発注者が直面するリスクは、①PO不在による方向性のブレ ②スコープクリープによる予算膨張 ③偽装アジャイル ④準委任のコスト超過 ⑤コミュニケーション過負荷の5つに整理できます。
- 専任POを立てられなくても、兼任PO＋開発会社のプロキシPO＋権限範囲の明確化という代替体制で現実的に回せます。発注者の関与は「週1回・優先順位の判断」に絞り込めます。
- 準委任契約の弱点（終わらない開発）には、予算上限・中途終了条項・進捗報告義務・成果物の権利明記という契約上の歯止めで対処します。
- 偽装アジャイルは「スプリント計画・レビュー・バックログ・ふりかえり」の4要素の有無で見抜けます。発注者の関与は「優先順位の提示」にとどめ、個々の作業者への直接指示は避けることで偽装請負リスクも回避できます。
最も伝えたいのは、「社内にPOを専任で立てる余裕がない」ことは、アジャイル外注をあきらめる理由にはならないということです。代替体制と契約の歯止めを用意すれば、片手間の発注担当でも失敗は十分に防げます。本記事のフェーズ別チェックリストを手元に置き、まずはパートナー選定の段階で「このアジャイルは本物か」「PO代行を立てられるか」を確認することから始めてみてください。
なお、アジャイルに限らないシステム開発プロジェクト全般のリスク管理の枠組みを知りたい場合は、プロジェクトリスク管理とはもあわせて参考にしてください。一般的なリスク管理の考え方を押さえたうえで本記事のアジャイル特有のリスクを重ねると、より立体的に自社の体制を設計できるはずです。
画像指示
- アイキャッチ推奨クエリ: "agile development team meeting risk planning"
- 本文内画像1（「リスクを最小化する発注者の体制構築3ステップ」セクションの体制図の代わり）: "agile sprint planning board collaboration"
- 本文内画像2（「発注者が実行すべきリスク管理チェックリスト（フェーズ別）」セクション付近）: "project checklist document business"
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
