相談する
MVP開発・PoC

アジャイル開発の進め方と発注側の役割：スプリントごとに何をするか

読了目安 約8分

この記事のテーマで進めたい事業がある方へ：お問い合わせ →

アジャイル開発は、1〜4週間ほどの短い期間で「動くもの」を作ることを繰り返し、その都度、次に何を作るかを決め直す進め方です。新規事業のように何が求められているかが途中でわかっていく開発に向いていますが、発注側がプロダクトオーナーとして毎回の判断に関わり続けることが前提になります。発注側が関与できないと、アジャイル開発は機能しません。

アジャイル開発の基本の流れ

IPA（情報処理推進機構）の「アジャイル開発の進め方」（2024年5月）は、代表的な手法であるスクラムを例に、次の流れを説明しています。なお同資料は、アジャイル開発の進め方に厳格な決まりごとはなく、組織やプロジェクトに合わせて取捨選択・調整が必要だとしています。

プロダクトバックログ

プロダクトに追加する要求（ストーリー）の一覧です。顧客を含む関係者にわかる言葉で書き、優先順位の順に並べます。この一覧はプロダクトオーナーが管理し、開発が続く間は変化し続けます。項目の詳細化、見積もり、優先順位の入れ替えを「リファインメント」と呼び、プロダクトオーナーと開発者が協力して継続的に行います。

スプリント

開発の繰り返しの単位です。1〜4週間の時間枠で、予定した機能が完成しなくても延長されません。スプリントの終わりには、リリースするかどうかを判断できる状態の成果（インクリメント）を作ります。

スプリントの中のイベント

イベント 内容
スプリントプランニング スプリントの開始前に、プロダクトオーナーが優先順位に従って今回扱う項目を選び、チームで合意する。開発者が見積もり、今回のスプリントに入れる範囲を決め、スプリントゴールを合意する
デイリースクラム 毎日決まった時間に15分程度で、スプリントゴールに向けた作業の状況や障害を共有する
スプリントレビュー スプリントの終わりに、関係者を集めて出来上がったものを実際に動かして見せ、フィードバックを受ける
スプリントレトロスペクティブ スプリントの進め方を振り返り、次のスプリントの改善点を話し合う

3つの役割

役割 内容
プロダクトオーナー プロダクトの価値を最大にする責任を持つ。必要な機能を定義し、優先順位を付ける。バックログへの追加・削除・順位付けに最終的な責任を持ち、関係者と調整する
開発者 実際に開発する人々。スプリントバックログの項目を完了させる
スクラムマスター スクラムがうまく回るように、チームを支援し、障害を取り除く

IPAのアジャイル開発版「情報システム・モデル取引・契約書」では、外部に開発を委託する場合、ユーザ企業（発注側）がプロダクトオーナーを選任し、ベンダ企業がスクラムマスターを選任する形を前提にしています。契約の考え方は開発会社との契約の注意点（請負と準委任）で解説しています。

発注側がスプリントごとにやること

アジャイル開発の成否は、発注側のプロダクトオーナーが毎回のイベントで判断できるかにかかっています。IPAのモデル契約の解説も、ユーザ企業がアジャイル開発の利点を生かすには、プロダクトの方向性と内容を決めるための主体的かつ積極的な関与が必要で、相応の負担を伴うと指摘しています。具体的には次のことを担います。

スプリントの前：次に作るものを並べる

  • バックログの上位の項目が、開発者が見積もれる程度まで具体的になっているかを確認する
  • 顧客の反応や事業の状況を踏まえて、優先順位を見直す
  • 項目ごとに、どうなれば完成とするか（受け入れ基準）を開発者と合意する

バックログの最初の形は、MVPの要件定義で作った機能一覧です。作り方はMVPの要件定義の進め方で解説しています。

スプリント中：質問にすぐ答える

開発者から仕様や優先順位について質問が来たら、できるだけその日のうちに答えます。回答が数日止まると、スプリントの中で作れる量が大きく減ります。社内の他部署に確認が必要な事項は、プロダクトオーナーが代わりに集めて回答します。

スプリントの終わり：動くものを見て判断する

スプリントレビューでは、報告書ではなく実際に動くものを操作して確認します。受け入れ基準を満たしているか、実際の顧客に見せられる状態か、次にどこを直すべきかを判断します。可能であれば、社内の関係者や協力してくれる顧客にも参加してもらい、早い段階でフィードバックを受けます。

継続して：関係者との調整

社内の関係部署、経営陣、協力してくれる顧客など、開発チームの外の関係者との調整もプロダクトオーナーの役割です。要望をすべてバックログに入れるのではなく、検証の目的に照らして優先順位を付け、なぜその順番なのかを説明します。

予算と進み具合の管理

期間と体制を固定し、範囲で調整する

アジャイル開発では、スプリントの長さとチームの体制を固定し、作る範囲を優先順位で調整する考え方をとることが多くなります。予算は「何スプリント分の体制を確保するか」で決まり、その中で優先順位の高いものから作ります。すべての機能を作り切ってから公開するのではなく、検証に必要な分ができた時点で公開を判断します。

進み具合は「動くもの」と「残りのバックログ」で見る

進捗は、作業時間や進捗率ではなく、スプリントごとに完成した項目と、残っているバックログの量で確認します。スプリントを重ねると、チームが1回のスプリントでどの程度の量をこなせるかが見えてくるため、残りの項目にどのくらいの期間がかかりそうかの目安が立てやすくなります。

見直しの時点を決めておく

一定のスプリント数ごとに、検証の結果と残りの予算を見て、続けるか、方向を変えるか、止めるかを判断する時点を設けます。アジャイル開発は変更に柔軟な分、終わりの判断をしないと開発が続いてしまいます。判断の考え方は新規事業のKPIの置き方と撤退基準も参考にしてください。

うまくいかない場面と対処

場面 起きていること 対処
スプリントレビューに発注側が出られない 判断が遅れ、作ったものが使われない プロダクトオーナーの時間を業務として確保する。兼務なら他の業務を減らす
プロダクトオーナーに決める権限がない 毎回社内の承認待ちになる 一定の範囲の判断をプロダクトオーナーに任せることを、事前に上長と合意する
バックログが「機能の名前」だけになっている 開発者が見積もれず、作ったものが期待と違う 誰が何のために使うかと、受け入れ基準を書き足す
毎回、新しい要望が最優先になる 何も完成しない スプリント中はゴールを変えず、新しい要望は次のプランニングで順位付けする
振り返りが形だけになる 同じ問題が繰り返される 次のスプリントで試す改善を1つに絞って決める

大企業と起業家で異なる点

大企業の場合

社内の決裁や部署間の調整に時間がかかると、スプリントの速さに判断が追いつきません。プロダクトオーナーに任せる判断の範囲、経営陣への報告の頻度、予算の追加を判断する時点を、開発を始める前に決めておきます。社内の開発標準が工程ごとの成果物（設計書など）を前提にしている場合は、アジャイル開発で何を代わりの記録とするかを、品質管理や情報システムの部門と合意しておきます。

起業家の場合

創業者がプロダクトオーナーを兼ねることが多くなります。営業や資金調達で手が回らなくなると、バックログの整理やレビューが後回しになり、開発が止まります。週に一定の時間をプロダクトオーナーの仕事に充てることを決めておきます。開発者が少人数の場合でも、スプリントの区切りとレビューだけは続けると、作るものがずれにくくなります。

参考資料

執筆・運営：Otsumu株式会社
新規事業の立ち上げ支援を行う運営チームが執筆しています。ご相談は上の「お問い合わせ」からどうぞ。

同じ工程の記事

MVP開発・PoC 大企業向け

生成AIのPoCが本番化しない理由：成功基準・評価データ・運用コストの決め方

生成AIのPoCが失敗して本番化に進まない主な原因は、成功基準・評価データ・運用コストを最初に決めていないことです。確認・修正の時間まで含めて測り、本番化・修正・中止を判断できるようにするための決め方と進め方、失敗しやすい点を整理します。本番化の判断材料の作り方も扱います。