スクラム開発の発注/外注/依頼/委託方法について

スクラム開発を外部に委託したいと考えているものの、「どこに頼めばいいのか」「どのように進めれば失敗しないのか」と悩んでいる担当者の方は多いのではないでしょうか。スクラム開発はウォーターフォール開発とは根本的に異なるアプローチを取るため、従来のシステム開発発注と同じ感覚で進めると、思わぬトラブルに直面することがあります。

本記事では、スクラム開発を外注・委託する際に知っておくべき基礎知識から、具体的な発注手順、契約時の注意点、そして発注後のプロジェクト管理方法まで、発注者の視点で体系的に解説します。スクラム開発の発注を成功させるために必要な情報を網羅していますので、ぜひ最後までお読みください。

なお、スクラム開発の基本的な概念や全体像については、以下の完全ガイドもあわせてご参照ください。
スクラム開発の完全ガイド

スクラム開発を外注する前に知っておくべきこと

スクラム開発の外注を検討する前に、まず自社の状況を正確に把握することが不可欠です。外注が適しているケースと内製が向いているケースを見極め、さらに発注先の種類と特徴を理解した上で判断することで、プロジェクトの成功確率が大幅に高まります。外注に踏み切る前のこの段階での判断ミスは、後々の大きなトラブルにつながりますので、時間をかけてしっかりと検討することをお勧めします。

スクラム開発を外注すべきかどうかは、自社のエンジニアリングリソースと開発内容の性質によって大きく異なります。外注が適しているケースとしては、まず社内にスクラム開発の経験を持つエンジニアが不在または少ない場合が挙げられます。スクラム開発は、スプリントと呼ばれる短期間の反復サイクルで開発を進める手法であり、スクラムマスターやプロダクトオーナーといった専門的な役割を担える人材が必要です。これらの人材を社内で育成するには相応の時間とコストがかかりますので、開発スピードを優先する場合は外注の方が合理的な判断といえます。

また、単発あるいは短期間のプロジェクトの場合も外注が有効です。正社員エンジニアを採用すると人件費が固定費として継続的に発生しますが、外注であればプロジェクト期間中のみコストが発生するため、コスト効率が高くなります。さらに、自社のコア事業とは異なる領域のシステム開発を行う場合も、その分野の専門知識を持つ外注先に依頼する方が品質と効率の両面で優れた結果が得られます。一方、内製が向いているケースとしては、継続的な改善と運用が前提のプロダクト開発、自社のノウハウやデータを活用するシステム、そして長期的にエンジニアリング能力を社内に蓄積したい場合などが代表的です。内製はランニングコストが高くなる傾向がありますが、ビジネスの変化に素早く対応できる柔軟性と、技術知識が社内に蓄積されるというメリットがあります。

スクラム開発を外注する際の発注先は大きく分けて4つの種類があります。一つ目は大手SIer（システムインテグレーター）です。NTTデータや富士通、NEC、日立製作所といった大手企業は豊富なリソースと実績を持ち、大規模なシステム開発に強みがありますが、費用が高く小規模なアジャイル開発には不向きな場合があります。二つ目は中小規模のシステム開発会社です。スクラム開発に特化した専門会社や、Web系のシステム開発会社が多く、比較的低コストで柔軟な対応が期待できます。特にスクラム開発の実績が豊富な会社を選ぶことが重要です。

三つ目はフリーランスエンジニアへの依頼です。Lancersやクラウドワークス、Workship ENTERPRISEなどのプラットフォームを通じて、スクラムマスターや開発エンジニアを個別に採用する方法です。コストを抑えられる反面、チームとしての連携やプロジェクト管理の難易度が上がります。四つ目はオフショア開発会社です。ベトナムやインド、フィリピンなどの海外開発会社に発注する方法で、コストを大幅に削減できる可能性がありますが、言語の壁やタイムゾーンの違いによるコミュニケーションコストの増加に注意が必要です。スクラム開発では密なコミュニケーションが成功の鍵となりますので、オフショア開発を選択する際は日本語対応能力と時差の小さい国を優先することをお勧めします。

スクラム開発の発注・外注の具体的な手順

スクラム開発の発注を成功させるためには、明確な手順を踏むことが不可欠です。ウォーターフォール開発とは異なり、スクラム開発では発注前の段階で「完全な仕様書」を作成する必要はありませんが、プロジェクトの目的と優先順位についての明確な考えを持っておくことが重要です。発注側がプロダクトの方向性を明確に示せなければ、開発チームが正しい方向に進むことができず、スプリントを重ねるごとに方向性のズレが大きくなってしまいます。

スクラム開発の発注において最初に行うべき作業は、プロジェクトの目的と達成すべきゴールを明確化することです。具体的には、「何のためにシステムを開発するのか」「誰がエンドユーザーなのか」「どのような課題を解決したいのか」「プロジェクトの成功とはどのような状態を指すのか」を言語化します。この段階では、細かい機能仕様よりもビジネス上の目標や制約条件（予算、スケジュール、技術的な制約など）を明確にすることが優先されます。

次に、RFP（提案依頼書）を作成します。スクラム開発向けのRFPには、プロジェクトの背景と目的、想定されるプロダクトバックログの概要（機能の一覧ではなく、ユーザーストーリー形式での記述が望ましい）、予算の上限と支払い条件、期間の目安と重要なマイルストーン、スクラムチームに求める体制と役割、そして発注側が担当するプロダクトオーナーについての情報が含まれると効果的です。重要なのは、スクラム開発向けのRFPでは「完璧な仕様書」を求めるのではなく、「コラボレーションの基盤となる共通理解を作ること」が目的であると認識することです。RFPはあくまでも発注先との対話のきっかけであり、提案を受けながら要件を精緻化していくという姿勢が重要です。また、RFPを作成する際は、現場部門・経営層・IT部門など複数のステークホルダーから意見を集め、多角的な視点で要件を洗い出すことで、後からの大幅な仕様変更を防ぐことができます。

発注先の選定においては、スクラム開発の実績が豊富であることが最も重要な判断基準となります。単に「アジャイル開発ができます」と謳っている会社を選ぶのではなく、実際にスクラムフレームワークを適切に運用した実績があるかどうかを確認してください。具体的には、過去に納品したプロダクトの事例、スクラムマスターの資格（CertifiedScrumMaster等）保有者の有無、スプリントレビューやレトロスペクティブをどのように実施しているかなどを確認することで、実力を判断することができます。

発注先の比較においては、3社以上から提案を受け、定量的・定性的の両面で評価することをお勧めします。定量的な評価項目としては費用の総額、スプリント期間、開発体制の規模などが挙げられます。定性的な評価項目としては、プレゼンテーションでの提案内容の質、担当者のスクラムへの理解度、コミュニケーションの取りやすさ、課題への向き合い方などが含まれます。特に注意すべき点として、相場を大きく下回る見積もりを提示する会社は、実際にはスクラム開発の経験が少なく、安請け合いしている可能性があります。スクラム開発では1スプリントあたりの費用が数十万円から数百万円になることが一般的であり、この相場を大きく下回る場合は品質面でのリスクがあると判断してください。また、実際の開発メンバーとなるエンジニアと事前に面談する機会を設けることも重要です。スクラム開発の成否は人材に大きく依存するため、担当エンジニアのスキルと人柄を直接確認することで、プロジェクト開始後のミスマッチを防ぐことができます。

スクラム開発の契約時に押さえるべきポイント

スクラム開発の契約は、従来のウォーターフォール型システム開発の契約とは本質的に異なります。変化に対応することを前提とした開発手法であるスクラムでは、契約形態の選択から個別条項の設定に至るまで、アジャイルな開発プロセスと整合する形で取り決めることが求められます。契約段階で適切な取り決めができていないと、後からトラブルが生じた際に発注者・受注者双方に不利な状況が生まれる可能性がありますので、契約の段階から慎重に対処することが重要です。

スクラム開発に最も適した契約形態は「準委任契約」です。IPA（独立行政法人情報処理推進機構）が公開した「情報システム・モデル取引・契約書（アジャイル開発版）」においても、スクラムをはじめとするアジャイル開発では準委任契約を前提とすることが明示されています。準委任契約は、受注者が「業務を遂行すること」に対して対価を支払う契約形態であり、成果物の完成責任を負わない代わりに、開発プロセス中の変更や調整に柔軟に対応できます。

これに対して請負契約は、受注者が「成果物を完成させること」に対して対価を支払う契約形態です。請負契約は要件が固定されている場合には適していますが、スクラム開発のように仕様変更を前提とした開発スタイルとは相性が悪く、仕様変更のたびに追加費用や納期の延長交渉が必要になる可能性があります。ただし、現実のプロジェクトでは、フェーズによって両方の契約形態を使い分けるケースもあります。たとえば、要件定義・設計フェーズは準委任契約で進め、特定の機能開発については請負契約を締結するというハイブリッド型のアプローチを取ることで、双方にとってリスクを分散させることが可能です。発注者の立場からすると、準委任契約では成果物の品質や完成に対するリスクを一定程度負うことになりますが、その分だけ開発の途中で柔軟に方向性を変えられるという大きなメリットがあります。プロジェクトの性質に応じて、最適な契約形態を発注先と相談しながら決定することが重要です。

スクラム開発の契約書で特に確認すべき重要条項として、まず「スプリントの定義と支払い条件」が挙げられます。スプリント期間（一般的には1〜4週間）、各スプリントの費用、支払いタイミングを明確に規定することで、プロジェクト全体のコスト管理がしやすくなります。また、スプリント単位での中途解約が可能かどうかも確認しておく必要があります。次に「知的財産権の帰属」は必ず確認すべき重要事項です。開発したソースコードや成果物の著作権・所有権が発注者に帰属するのか、それとも受注者が保持するのかを明確に定めてください。特にカスタム開発の場合は、開発物が自社の重要な資産となるため、知的財産権が発注者に帰属することを契約書に明記することを強くお勧めします。

「秘密保持条項（NDA）」も契約前に締結しておくべき条項です。開発過程で共有される業務情報、顧客データ、技術情報が外部に漏洩しないよう、具体的な情報の範囲と保持義務の期間を定めてください。さらに「バックログの変更プロセス」を契約書に盛り込むことも重要です。スクラム開発ではプロダクトバックログの内容が変更されることが前提ですが、変更の手続きや追加費用が発生する場合の判断基準を事前に取り決めておくことで、後からのトラブルを防ぐことができます。最後に、「瑕疵担保責任の範囲」についても明確にしておく必要があります。特に準委任契約の場合、成果物の完成責任がないため、バグや不具合が見つかった際の対応範囲と費用負担を具体的に規定しておくことが発注者の利益を守ることにつながります。

スクラム開発の発注後のプロジェクト管理

スクラム開発を外注した後の発注者の関与度は、ウォーターフォール開発の場合よりも高くなります。スクラムでは発注者側がプロダクトオーナーとしての役割を担うことが多く、スプリントごとの意思決定や優先順位の決定に積極的に参加することが求められます。「開発会社に丸投げ」というスタンスでは、スクラム開発の本来の効果を得ることができませんので、発注後もプロジェクトに能動的に関わることが重要です。

スクラム開発において発注者側が最初に行うべきことは、プロダクトオーナーを明確に決定することです。プロダクトオーナーはプロダクトバックログの管理と優先順位付けを担い、スプリントレビューで成果物を確認し承認する重要な役割を持ちます。この役割を担う人物が発注者側に存在しないと、開発チームが意思決定に迷い、開発速度が大幅に低下してしまいます。発注者側のプロダクトオーナーは、週に数時間から数十時間程度の工数をプロジェクトに割り当てられる人物を選定することが理想的です。

日常的なコミュニケーションツールについても、プロジェクト開始前に合意しておく必要があります。多くのスクラム開発チームではSlackやMicrosoftTeamsなどのチャットツール、JiraやTrello、Notionなどのプロジェクト管理ツール、そしてZoomやGoogle Meetなどのビデオ会議ツールを組み合わせて使用します。発注者側もこれらのツールにアクセスできる環境を整え、開発の透明性を確保することが重要です。スクラム開発では「透明性・検査・適応」の3本柱が基本原則であり、開発の状況が常に可視化されている状態を維持することで、問題の早期発見と迅速な対処が可能になります。具体的には、スプリントバックログや完了したタスクの一覧、バグの発生状況などが常に発注者から確認できる状態にしておくことをお勧めします。さらに、スプリントの区切りごとに行われるスプリントレビューには、発注者側の関係者が可能な限り参加することが重要です。レビューでは実際に動くシステムのデモを確認し、フィードバックを提供します。このフィードバックが次のスプリントの優先順位に反映されることで、開発が正しい方向に進んでいることを確認できます。

スクラム開発の進捗管理は、ウォーターフォール開発のガントチャートとは異なるアプローチを取ります。スクラムではバーンダウンチャートやベロシティといった指標を使って進捗を可視化します。バーンダウンチャートはスプリント内の残作業量の推移を示すグラフで、計画通りに開発が進んでいるかを一目で把握することができます。ベロシティはスプリントごとに完了したストーリーポイントの量を示す指標で、チームの開発スピードの安定性を測る基準となります。発注者はこれらの指標を定期的に確認することで、プロジェクトの健康状態を把握することができます。

品質保証の観点からは、スプリントレビューでの成果物確認に加えて、テストの自動化状況と定期的なコードレビューについても確認しておくことが重要です。優れた開発会社は継続的インテグレーション（CI）・継続的デリバリー（CD）のパイプラインを整備しており、コードの変更が自動的にテストされる仕組みを持っています。これにより、バグの早期発見と品質の維持が実現されます。発注者として品質管理で特に注意すべき点は、スプリントを重ねるごとにバグの累積が増加していないか確認することです。スクラムの3本柱の一つである「検査」を怠ると、後のスプリントで大量の手戻りが発生し、プロジェクトのコストとスケジュールに大きな悪影響を与えます。理想的には、各スプリント終了時に「完成の定義（Definition of Done）」に基づいた成果物の検証を徹底し、未完成の機能を次のスプリントに持ち越さないことが品質維持の基本となります。また、四半期に一度程度の頻度で、プロジェクト全体を俯瞰したロードマップレビューを実施することも効果的です。個々のスプリントに集中するあまり大局観を失いやすいのがスクラム開発の落とし穴の一つですので、定期的に「このプロジェクトはビジネス目標に向けて正しく進んでいるか」という観点での評価を行うことが、発注者としての重要な役割となります。

まとめ

本記事では、スクラム開発の外注・委託方法について、発注前の判断から発注後のプロジェクト管理まで体系的に解説しました。スクラム開発の発注を成功させるためのポイントを改めて整理すると、まず外注が本当に自社のプロジェクトに適しているかを見極めることが出発点です。短期的・専門的なプロジェクトや社内にスクラム経験者が少ない場合は外注が有効な選択肢となります。次に、RFPの作成においては完全な仕様書を求めるのではなく、プロジェクトの目的と優先順位を明確に伝えることに集中することが重要です。スクラム開発では、要件は開発を進める中で精緻化されていくものであるという前提を発注者が理解しておく必要があります。

契約形態としては準委任契約が基本となり、知的財産権の帰属、秘密保持、バックログ変更プロセス、瑕疵担保責任の範囲について契約書で明確に定めることが後のトラブル防止につながります。発注後は発注者側もプロダクトオーナーとしてプロジェクトに能動的に関わり、スプリントレビューへの参加や日常的なコミュニケーションを通じて開発チームと密に連携することが成功の鍵となります。透明性を維持しながらスプリントごとに成果物を確認し、バーンダウンチャートやベロシティといった指標で進捗を管理することで、プロジェクトを健全な状態に保つことができます。スクラム開発の発注は、従来の「仕様を決めて丸投げする」アプローチとは根本的に異なります。開発チームと発注者がワンチームとなって協力することで、変化の激しいビジネス環境においても価値あるプロダクトを継続的に生み出すことが可能になります。

スクラム開発についてより詳しく知りたい方は、以下の完全ガイドもぜひご参照ください。
スクラム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。