アジャイル開発の発注/外注/依頼/委託方法について

アジャイル開発の外注は、発注前の準備、契約形態の選択、発注後の関与の順で進めます。欠かせないのは、発注側が優先順位や受入条件を継続して判断する体制です。

アジャイルは一括請負型と進め方が違うため、発注側にも準備と関与が求められます。適切な知識がないまま進めると、成果が期待に届かず、コストが予算を超えるおそれがあります。

アジャイル開発を外注する前の確認事項

まず、発注側が社内で担える役割と不足している専門性を整理します。そうすると、外注の必要性を判断しやすくなります。

外注と内製が向くケース

社内にアジャイルの経験者がいない場合や、短期リリースを目指す場合は、外注が有力な選択肢になります。反対に、社内に経験者がいて仕様変更にも対応できるなら、内製が向いています。

  • 外注:人材不足や専門技術の確保が必要で、短期リリースを優先する場合。
  • 内製:仕様変更が多く、社内にアジャイル経験のある組織がある場合。

外注は専門人材を補い、社内にチームを作る時間と費用を抑える方法です。また、スタートアップや中小企業、短期リリースを目指す場合にも、外注は有効です。

アジャイルは、事業側と開発側が連携して価値を生み出す進め方です。そのため、外注先を共同のプロダクトパートナーと位置づけ、協働の体制を整えます。

発注先の種類と特徴

発注先は主に3種類あります。支援の範囲と自社のプロジェクト管理能力を踏まえて選びましょう。

  • 1つ目:受託開発会社:開発とアジャイル運営を一括で支援する。
  • 2つ目:SES企業:常駐人材を活用し、発注側が進行を担う。
  • 3つ目:フリーランス:専門スキルを柔軟に補い、小規模案件にも対応する。

受託開発会社は、経験があればスクラムマスターやプロダクトオーナーの役割も支援できます。特に、初めてのアジャイル開発では、知見を持つ会社が候補になります。

SESは成果物を完成させる義務がないため、発注側に進行管理が必要です。一方で、フリーランスは柔軟ですが、複数人を束ねる管理コストも見込んでおきます。

ポイント

外注か内製かは、社内の経験者の有無、仕様変更の多さ、短期リリースの必要性で決めます。外注するなら、どこまで支援してもらうかと、自社で進行を回せるかを合わせて見ます。

アジャイル開発の発注・外注の手順

アジャイル開発の発注準備を、価値と範囲、準備資料、RFP、発注先の選定と比較に分けた図。
準備内容を整理してから候補企業を比べます。

アジャイル開発の外注は、ウォーターフォール型と比べると、発注の準備段階から進め方が大きく異なります。成功の前提は、発注側がプロダクトビジョンや優先課題を明確に持つことです。

「仕様が決まっていないからアジャイルにする」という考え方は誤りです。発注から開発開始までの手順は、要件整理とRFP作成、発注先の選定と比較の順に説明します。

要件整理とRFP作成

アジャイルでも、発注前の要件整理は欠かせません。発注側は、詳細仕様を固定するより、実現したい価値と初期範囲を明確にしましょう。

  • 価値と範囲:背景・目的、解決する課題、初期機能を整理する。
  • 準備資料:ビジョン、スコープ記述書、ユーザーストーリーの一式。
  • RFP:体制、期間、予算、技術、連絡頻度を候補企業に伝える。

RFP(提案依頼書)には、背景・目的・ビジネス成果と、初期スコープのユーザーストーリーを記載します。また、スクラムチームの構成も伝えます。

スプリント期間は1週間・2週間などの希望を示し、概算予算や開発言語・技術スタック、連絡頻度も盛り込みます。そのうえで、価値とゴールを軸に、各社の支援の仕方を比べます。

発注先の選定と比較

発注先は、アジャイルの実績、技術力、協働のしやすさを軸に比べます。提案の内容に加えて、実際の進め方も確かめます。

  • アジャイルの実績:スクラム・カンバン、スプリント運営の経験を確かめる。
  • 技術力:技術スタック、CI/CD、クラウドの経験の有無。
  • 協働と検証:対話の質と、PoCの必要性を評価する。

スクラムマスターやアジャイルコーチが在籍しているかも確認します。なお、経験の乏しい会社では、名目上はアジャイルでも、実態はウォーターフォールになる場合があります。

レビューやデイリースタンドアップでは、担当者との相性、返答の速さ、日本語での対話が重要です。さらに、大規模・長期の案件なら、有償のフィジビリティスタディ(PoC)も検討できます。

ポイント

発注前は、プロダクトビジョンと初期範囲を明確にし、詳細な仕様を固めすぎないことが基本です。発注先は、アジャイルの実績、技術力、協働のしやすさを軸に、提案内容と実際の進め方の両方で比べます。

アジャイル開発の契約時に押さえるべき点

アジャイル開発の契約書で決める、スプリントの定義、支払いのサイクル、成果物の確認と承認の方法を示す図。
運用時の認識違いを防ぐため、契約時に確認します。

アジャイル開発の契約は、従来のシステム開発契約と大きく異なります。適切な契約形態を選ばないと、プロジェクト途中での仕様変更や追加要件に対応できなくなるリスクがあります。

2020年にIPA(情報処理推進機構)が公開した「情報システム・モデル取引・契約書(アジャイル開発版)」は、アジャイル契約の標準的な考え方を示しています。契約を検討する際は、参考にすることをお勧めします。

契約形態の選び方

アジャイル開発の契約形態は、請負契約と準委任契約の2種類です。柔軟な仕様変更が必要か、完成責任を明確にしたいかで選びます。

  • 請負契約:成果物の完成を約束し、完成後に報酬が発生する。
  • 準委任契約:専門業務の遂行そのものに対して報酬を支払う。

請負は完成責任が明確な一方、仕様変更のたびに契約変更が必要になり、検収の範囲も曖昧になりがちです。そのため、スプリントごとに要件を調整するアジャイルとは、相性の面で注意が必要です。

IPA(情報処理推進機構)は、アジャイル開発では準委任契約が適切だと示しています。費用は1ヶ月または1スプリントごとに発生します。さらに、方向転換やスコープの縮小、中止にも対応しやすくなります。

ただし、準委任では成果物の完成義務がありません。期待する成果を得るには、発注側がプロダクトオーナーとして継続的に関与する必要があります。

契約書の重要条項

契約書では、スプリントの定義、支払いのサイクル、成果物の確認と承認の方法を具体化します。準委任では納品の概念がないため、とくに重要になります。

  • レビュー:スプリント終了時の成果確認と承認方法を決める。
  • 権利と引き渡し:コード・設計・テスト資料の帰属を定める。
  • 変更・中止と役割:精算、引き渡し、発注側の関与範囲を明記する。

スプリントレビューで発注側が成果を確認し、承認した内容を次のスプリントの起点にする流れも、契約に書いておきます。

他社へ保守を依頼する可能性も踏まえて、権利と成果物の引き渡しを先に決めておきます。中止時の費用精算に加えて、直接の指揮命令を避ける関与範囲も定めます。関与範囲の例は、プランニングへの参加やバックログの優先順位付けです。

ポイント

完成責任を重く見るなら請負、仕様変更を前提にするなら準委任が候補になります。準委任では発注側の継続的な関与が前提で、契約書で承認方法や中止時の精算を具体化します。

アジャイル開発の発注後のプロジェクト管理

プロダクトオーナー(PO)を中心に、ビジネス判断、バックログの優先順位、スプリントレビューを結んだ図。
POの判断とレビュー参加が、開発の方向を支えます。

アジャイル開発では、発注後も発注側が継続して関わります。納品まで任せきりにせず、優先順位や成果をチームと確かめていきます。

コミュニケーション体制の構築

まず、発注側からプロダクトオーナー(PO)を任命します。役割と連絡の場を決めておくと、判断の遅れを防げます。

  • PO:ビジネス判断とバックログの優先順位を担う。
  • セレモニー:スクラムの定例の場にPOが参加する。
  • ツール:日常連絡と進捗管理の場を分けて共有する。

POは、バックログの優先順位を開発チームと直接調整する役割です。そのため、POには現場の担当者だけでなく、価値判断と意思決定ができる人を選びます。

スクラムでは、スプリントプランニング、スプリントレビュー、レトロスペクティブの3つにPOが参加します。特に、レビューでデモを見て意見を伝えれば、次のスプリントの方向性を定められます。

日常連絡にはSlackやMicrosoft Teams、バックログと進捗の管理にはJira・Asana・Notionなどを使う方法があります。

進捗管理と品質保証の方法

進捗と品質は、スプリントごとに実際の成果を見ながら管理します。指標とテストの運用は、発注前から確かめておきます。

  • 進捗:バーンダウンチャートとスプリントベロシティで見る。
  • テスト:TDDやCI/CDを使い、テストを後回しにしない。
  • 完成基準:Definition of Doneを双方で合意する。

バーンダウンチャートは、スプリント内の残タスクを示し、計画との差を把握できます。ベロシティは1スプリントで完了できる作業量の平均で、継続して見ると全体の予測に役立ちます。

指標が低下した場合は、発注側も開発チームと原因を探ります。また、動くソフトウェアを毎スプリントで確認し、レビュー時にデモとフィードバックを行えば、品質低下や仕様の認識違いを早く見つけられます。さらに、Definition of Done(完成の定義)についても、事前に中身を確かめておきます。

ポイント

発注側はPOを任命し、スプリントレビューなどで成果と優先順位を確かめます。進捗はバーンダウンチャートとスプリントベロシティで見て、完成の基準は双方で合意しておきます。

まとめ

アジャイル開発の外注には、発注前の準備、契約形態の選択、発注後の継続的な関与が欠かせません。プロダクトビジョンとユーザーストーリーを軸にRFPを作り、アジャイルの実績がある複数のベンダーを比べます。

契約形態を選ぶ際は、IPA(情報処理推進機構)が2020年に公開したアジャイル開発版のモデル取引・契約書も参考になります。そのうえで、スプリントごとの支払い、知的財産権、中止時の精算を明記し、偽装請負を避けるため双方の役割分担も定めてください。

発注後はプロダクトオーナーがスプリントレビューなどのセレモニーに参加し、成果と品質を継続して確認します。また、バーンダウンチャートやスプリントベロシティで進捗を見れば、変化に応じて価値を高める開発につながります。

まずは小さなスコープから試し、信頼できるパートナーを見つける方法もあります。ripla(リプラ)はコンサルティングから開発まで一貫して支援しています。外注・発注でお悩みの方はご相談ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。