プロジェクト管理手法
アジャイル開発とスクラム開発は、同じ意味で使われることがあるものの、指している範囲が異なります。アジャイル開発は変化に対応しながら価値を届ける考え方であり、スクラム開発はその考え方を実践するためのフレームワークです。
私はこれまで、ウォーターフォール開発とアジャイル開発の両方の現場でプロジェクトマネージャーを務めてきました。私が関わった現場では、この2つの言葉を区別せずに議論が進み、何を決めるべきかが曖昧になる場面が何度もありました。
この記事では、アジャイル開発とスクラム開発の関係を整理したうえで、スクラム開発の仕組み、カンバンやXPとの違い、そして自社に合う進め方を判断するポイントまで解説します。
執筆者：和田匠真
IT業界で20年以上の実務経験を持つプロジェクトマネージャー。プログラマー・SEを経てPMとなり、大手企業のシステム提案からデリバリーまで一貫して従事。PMP／認定スクラム開発マスター（CSM）保有。ウォーターフォール／アジャイル開発双方の現場経験をもとに、プロジェクト管理に関する記事を執筆。
アジャイル開発とスクラム開発の違い
アジャイル開発とスクラム開発の違いは、指している範囲にあります。アジャイル開発は価値観と原則に基づく開発の考え方を指し、スクラム開発はその考え方を実践するための具体的な枠組みを指します。
つまり、両者は同じ階層の概念ではありません。スクラム開発は、アジャイル開発の価値観・原則を実践する代表的なフレームワークの一つです。この関係を押さえておくと、社内の議論で話がかみ合わなくなる場面を減らせます。
アジャイル開発は価値観・原則に基づく開発アプローチ
アジャイル開発は、特定の手順を定めた方法ではありません。2001年に発表されたアジャイルソフトウェア開発宣言が示す価値観と原則に基づく、開発の進め方を指します。
宣言では、個人と対話、動くソフトウェア、顧客との協調、変化への対応をより重視すると示されています。計画や文書を否定するのではなく、状況に応じた判断と関係者の協働を重視する考え方です。
（出典：Agile Manifesto「アジャイルソフトウェア開発宣言」）
そのため、アジャイル開発では、何をどの順番で作るかを状況に応じて見直します。この見直しを前提にしている点が、アジャイル開発の土台となる部分です。
スクラム開発はアジャイル開発を実践するフレームワーク
スクラム開発は、アジャイル開発の考え方を実践するためのフレームワークです。公式のスクラム開発ガイドでは、複雑な問題に対応しながら価値を生み出すための軽量なフレームワークと定義されています。
（出典：Scrum Guides「スクラム開発ガイド」）
スクラム開発には、責任・イベント・成果物という具体的な構成要素があります。誰が何に責任を持ち、どのタイミングで何を確認するかが定められている点が特徴です。
アジャイル開発が方向性を示すのに対し、スクラム開発は進め方の枠組みを示します。この違いが、2つの言葉の役割の違いです。
アジャイル開発におけるスクラム開発の位置づけ
スクラム開発は、アジャイル開発を実践する代表的なフレームワークの一つです。ほかにも、カンバンやエクストリームプログラミング（XP）などの方法があります。
そのため、アジャイル開発とスクラム開発のどちらを選ぶかという問いは成り立ちません。正しくは、アジャイル開発の考え方を実践する方法として、スクラム開発を選ぶかどうかを検討します。
対象範囲を整理すると、次のようになります。
- アジャイル開発：価値観と原則に基づく開発の考え方
- スクラム開発：その考え方を実践する具体的なフレームワーク
- カンバンやXP：スクラム開発と並ぶ、ほかの実践方法
この階層を意識すると、社内で何を議論しているのかが明確になります。アジャイル開発を導入するかどうかと、スクラム開発を採用するかどうかは、別の論点として扱いましょう。
アジャイル開発の基本知識
アジャイル開発を理解する土台は、宣言に示された価値と原則です。ここを押さえておくと、スクラム開発などの実践方法を選ぶときの判断基準がはっきりします。
以下では、宣言の内容、ウォーターフォール開発との違い、そして関連する代表的な方法を解説します。
アジャイルソフトウェア開発宣言の価値と原則
アジャイル開発の出発点は、2001年に発表されたアジャイルソフトウェア開発宣言です。ここでは、次の4つの価値が示されています。
- プロセスやツールよりも個人と対話をより重視する
- 包括的なドキュメントよりも動くソフトウェアをより重視する
- 契約交渉よりも顧客との協調をより重視する
- 計画に従うことよりも変化への対応をより重視する
宣言では、左側だけを選ぶのではなく、左側により価値を置くと表現されています。ドキュメントや計画を不要とする考え方ではありません。
宣言には、この4つの価値に加えて12の原則も示されています。いずれも現在まで公式サイトで公開されています。
（出典：Agile Manifesto「アジャイルソフトウェア開発宣言」）
なお、アジャイル開発は開発期間を短くする取り組みと同じではありません。短い単位で価値を届け、そこで得た学びを次に反映する点が本質です。
ウォーターフォール開発との違い
アジャイル開発とウォーターフォール開発の違いは、計画の立て方と、変化を計画へ反映する方法にあります。
- 進め方：アジャイル開発は価値を小さな単位で届け、学びを次の計画へ反映します。ウォーターフォール開発は工程ごとの成果物を確認しながら段階的に進めます
- 仕様変更：アジャイル開発は優先順位や計画へ反映しやすく、ウォーターフォール開発は変更管理を通じて影響範囲を確認したうえで計画へ反映します
- 計画：アジャイル開発は進行に応じて詳細化し、ウォーターフォール開発は初期段階で範囲と工程を定義します
どちらが優れているという関係ではなく、案件の性質によって適性が変わります。要件が固まっており、契約上 スコープを動かしにくい案件では、ウォーターフォール開発のほうが管理しやすくなります。
アジャイル開発に関連する代表的なフレームワーク・手法
アジャイル開発に関連する方法は、同じ種類の概念ではありません。役割が異なるため、区別して捉える必要があります。
- スクラム開発：責任・イベント・成果物を定めたフレームワーク
- XP：技術プラクティスまで具体的に定めたフレームワーク
- カンバン：既存の仕事の進め方に追加できる管理手法
カンバンは、新たな役割やイベントを必須としません。そのため、現在の進め方を維持しながら取り入れられます。
一方、スクラム開発とXPは、あらかじめ定められた要素を前提に運用します。導入時に決めるべき事柄の量が異なる点を押さえておきましょう。
スクラム開発の仕組み
スクラム開発は、3つの責任、5つのイベント、3つの成果物という要素で構成されています。この構成を理解すると、導入時に何を準備すべきかが見えてきます。
ここでは、それぞれの要素と、実際の進め方を順に整理します。
スクラム開発チームの3つの責任
スクラム開発チームには、次の3つの責任があります。
- プロダクトオーナー：スクラム開発チームから生み出されるプロダクトの価値を最大化する
- スクラム開発マスター：スクラム開発を確立し、スクラム開発チームの有効性を高める
- 開発者：利用可能なインクリメントを作成し、スプリントの計画と品質に責任を持つ
スクラム開発ガイドでは、これらを役割ではなく明確な責任として示しています。スクラム開発チームは通常10人以下の規模とされ、小さなチームで密に連携する前提です。
プロダクトオーナーとスクラム開発マスターを同じ人が担う場合は、価値判断とチーム支援の責任が衝突しやすくなります。担当を決める段階で、この点を確認しておく必要があります。
スクラム開発の5つのイベント
スクラム開発には、次の5つのイベントがあります。
- スプリント：ほかの4つのイベントを含む、1か月以内の固定された期間
- スプリントプランニング：スプリントの価値、扱う項目、実行計画を検討する
- デイリースクラム：スプリントゴールへの進捗を確認し、スプリントバックログを調整する
- スプリントレビュー：スプリントの成果と環境の変化を関係者と確認し、今後の対応を検討する
- スプリントレトロスペクティブ：品質と有効性を高める改善策を検討する
スプリントは、ほかのイベントを含む枠組みとして機能します。期間を固定することで、検査と適応のリズムが生まれます。
各イベントは、進捗の報告や成果の発表を目的とする場ではありません。成果物やゴールを検査し、必要に応じて適応するための機会として設けられています。
私が関わった現場では、レトロスペクティブを省いた結果、同じ問題が繰り返し起きたことがありました。振り返りの場を確保することが、改善につながります。
スクラム開発の3つの成果物
スクラム開発では、次の3つの成果物を扱います。
- プロダクトバックログ：プロダクトの改善に必要な項目を順番に並べた一覧
- スプリントバックログ：そのスプリントで扱う項目と実行計画
- インクリメント：スプリントで完成した、利用可能な状態の成果
各成果物には、それぞれ透明性と集中を高めるためのコミットメントが設定されています。プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義が含まれます。
優先順位が曖昧なままでは、スプリントで何を作るかを決められません。プロダクトバックログの整理は、スクラム開発を運用する土台になります。
スクラム開発の反復的な進め方
スクラム開発では、プロダクトバックログから項目を選び、計画・開発・検査・適応を繰り返します。1回のスプリントの流れは次のとおりです。
- スプリントプランニングで、扱う項目とスプリントゴールを決める
- 開発を進めながら、デイリースクラムで進捗を確認し、計画を調整する
- スプリントレビューで成果と環境の変化を関係者と確認する
- スプリントレトロスペクティブで改善策を検討する
このサイクルを繰り返すことで、方向のずれを早い段階で見つけられます。工程を順番に進めるのではなく、同じ流れを何度も回す点が特徴です。
スクラム開発とカンバン・XPの違いと組み合わせ方
スクラム開発、カンバン、XPは、いずれもアジャイル開発の実践方法ですが、定めている範囲が異なります。違いを押さえると、自社の課題に合う方法を選びやすくなるでしょう。
なお、3つは組み合わせて使うこともできます。ここでは違いを整理したうえで、組み合わせる際の考え方を紹介します。
スクラム開発とカンバンの違い
スクラム開発とカンバンの大きな違いの一つは、仕事を計画・管理する単位です。スクラム開発は固定長のスプリントを用い、カンバンは固定長の反復を必須とせず、作業の流れを管理します。
- スクラム開発：スプリント内の各イベントで、成果物とゴールへの進捗を検査し、必要に応じて適応します
- カンバン：作業の流れを可視化し、仕掛かり中の作業数（WIP）を制御します
カンバンの代表的な実践は、ワークフローの定義と可視化、作業項目の管理、そしてフローの継続的な改善です。
（出典：Kanban Guides「The Kanban Guide」）
依頼が随時発生する運用・保守の業務では、固定長の反復を前提としないカンバンが選択肢になりやすいでしょう。なお、スクラム開発にカンバンの実践を取り入れる方法もあります。
スクラム開発とXPの違い
スクラム開発とXPの違いは、技術的な実践まで定めているかどうかにあります。スクラム開発は仕事の進め方を定め、XPは実装の進め方まで具体的に示すことが特徴です。
XPが定める代表的なプラクティスは次のとおりです。
- ペアプログラミング：2人1組でコードを書き、その場でレビューする
- テスト駆動開発（TDD）：失敗するテストを先に作成し、実装とリファクタリングを繰り返す
- 継続的インテグレーション：変更を頻繁に統合し、動作を確認する
スクラム開発では、規定しない技術的な実装方法をチームが決めます。案件によっては、XPのプラクティスを組み合わせて補う進め方も有効です。
複数の方法を組み合わせる考え方
複数の方法を組み合わせる場合は、解決したい課題を先に決めます。名前だけを基準に混ぜると、運用が複雑になります。
代表的な組み合わせは次のとおりです。
- スクラム開発とカンバンを併用し、スプリントのなかで仕掛かり量を管理する
- スクラム開発で進め方を整え、XPのプラクティスで技術品質を支える
ポイントは、一度に複数を導入せず、効果を確認しながら段階的に取り入れることです。取り入れた理由をチーム内で共有しておくと、複数の方法を組み合わせても運用が浸透しやすくなります。
スクラム開発のメリット・デメリット
スクラム開発を導入するかどうかは、良い面と注意点の両方を踏まえて判断します。ここではメリットを整理したうえで、デメリットについては補う進め方もあわせて紹介します。
スクラム開発を採用するメリット
スクラム開発の大きなメリットは、要件の変更を計画へ取り込みやすい点です。スプリントごとに優先順位を見直せるため、状況の変化に合わせて作る対象を調整できます。
主なメリットは次の3つです。
- 要件の変更を、次のスプリントの計画へ反映しやすい
- 早い段階で動く成果を示し、関係者の意見を受け取れる
- 責任とイベントが定義されており、透明性を確保するための共通の枠組みを持ちやすい
とくに効果が大きいのは、認識のずれを早い段階で見つけられる点です。文書だけで仕様を確認する方法と比べ、動くものを見せると具体的な指摘が集まります。
スクラム開発を採用するデメリット
一方で、スクラム開発には注意すべき点もあります。導入前に対策を用意しておけば、影響を抑えやすくなります。
主なデメリットと、それを補う進め方は次のとおりです。
- 全体の見通しを立てにくい：スプリントごとの計画とは別に、リリース時期や主要機能の目標を先に定めておく
- 関係者の継続的な関与が必要になる：レビューの参加者と頻度を事前に合意し、チームで決められる範囲を線引きする
- チームの経験や自己管理能力に結果が左右されやすい：適用範囲を1チームに絞り、振り返りで進め方を見直す
最初から全社へ広げず、小さな範囲で運用方法を確立してから対象を広げると、導入時の混乱を抑えやすくなります。私が支援した現場でも、1チームで運用方法を確立してから対象を広げる進め方が定着しました。
スクラム開発を採用するか判断するポイント
スクラム開発を採用するかどうかは、要件の変わりやすさと関係者の関与度から判断します。チームの人数だけで決めると、導入後に定着しにくくなります。
ここでは、確認する順序に沿って4つの観点を紹介します。
要件の変化とフィードバック頻度で判断する
最初に確認するのは、要件がどれくらい変わるか、そして継続的にフィードバックを得られるかという2点です。
要件が固まっており、契約上スコープを動かしにくい案件では、スプリントごとに調整する利点が出にくくなります。スクラム開発の利点を活用しにくいときは、ウォーターフォール開発や、一部にアジャイル開発の考え方を取り入れる進め方を検討します。
反対に、利用者の反応を見ながら作る対象を決めていく案件では、スクラム開発の効果が出やすくなります。新規サービスの開発や、既存機能の改善などが該当します。
チームが自己管理できる体制か確認する
次に確認するのは、チームが自ら計画し、進め方を調整できる体制かどうかです。スクラム開発は、チームが誰が何を、いつ、どのように行うかを自ら決める、自己管理を前提とした手法です。
指示を待つ働き方が定着している場合、能動的に管理する部分がチームの負担になります。責任の分担が曖昧なまま始めると、誰が判断するのか分からなくなる可能性もゼロではありません。
体制が整っていない段階では、カンバンで作業の流れを可視化し、現状の課題を把握する方法もあります。カンバンを継続して利用するか、スクラム開発を検討するかは、その後の課題に応じて判断しましょう。
プロダクトオーナーが継続的に関与できるか確認する
スクラム開発では、プロダクトオーナーが優先順位を判断します。この責任を担う人が継続的に関与できるかどうかは、スクラム開発が機能するかに大きく影響します。
判断できる人が不在の場合、優先順位や仕様の確認が滞る可能性が高いです。事業側がレビューに参加できない状況では、検査と適応が十分に機能しにくくなります。
関与が難しい場合は、判断が必要な事項とチームで決めてよい事項を、あらかじめ線引きしておきましょう。
既存の開発・運用プロセスとの相性を確認する
最後に確認するのは、現在の進め方に無理なく組み込めるかどうかです。固定長のスプリントや定期的なレビューは、既存の会議体や承認の流れと重なる場合があります。
次の観点で確認してください。
- 固定長のスプリントを設定できるかを確かめる
- レビューとレトロスペクティブの時間を確保できるかを確かめる
- カンバンによるフロー管理のほうが合う業務が含まれていないかを確かめる
- XPの技術プラクティスを取り入れる余地があるかを確かめる
すべてを一度に変えず、既存の流れと重なる部分から調整すると、現場の負担を抑えられます。
スクラム開発を実践するコツ
スクラム開発は、構成要素をそろえるだけで十分に機能するとは限りません。日々の運用で、優先順位、ゴール、進捗、改善内容を共有できる状態を作ることが重要です。
ここでは、私が現場で効果を感じた4つのコツを紹介します。
プロダクトバックログの優先順位を明確にする
最初のコツは、プロダクトバックログの優先順位を明確にすることです。優先順位が曖昧なままでは、スプリントで何を作るかを決められません。
項目を並べるだけでなく、なぜその順番なのかを言葉にしておきましょう。判断の理由が共有されていると、途中で要件が変わったときも順序を組み替えやすくなります。
私が関わった現場では、優先順位の理由を1行書き添えるだけで、スプリントプランニングにかかる時間が短くなりました。
スプリントゴールをチーム全体で共有する
2つ目のコツは、スプリントゴールを常に見える状態にすることです。項目の消化だけに集中すると、スプリントの目的を見失いやすくなります。
スプリントゴールが見えていると、判断に迷ったときの基準になります。優先度を下げる項目を決めるときにも、スプリントゴールは役立つ項目です。
デイリースクラムで必要に応じて確認する、ボードの上部に表示するなど、目に入る形にしておくとよいでしょう。
進捗と残作業を見える状態にする
3つ目のコツは、進捗と残りの作業を見える状態にすることです。誰がどの項目を進めているかが共有されていないと、支援が必要な場面に気づけません。
作業の状態を並べて表示し、同時に進める項目が増えすぎていないかを確認します。進行が止まっている項目を早く見つけられると、スプリント終盤で問題が表面化する事態を減らせます。
振り返りの結果を次のスプリントに反映する
4つ目のコツは、振り返りで出た改善点を次のスプリントに反映することです。意見を集めるだけで終わると、同じ問題が繰り返されます。
改善点は1つか2つに絞り、次のスプリントで試す行動を明確にしましょう。必要に応じて、スプリントバックログへ追加します。
次の振り返りでは結果を確認し、継続するか、修正するかを判断します。この流れを作ると、進め方を改善することが可能です。
スクラム開発を実践するならLychee Redmineがおすすめ
スクラム開発の運用を支える環境をお探しなら、当社が提供するLychee Redmineをぜひご検討ください。7,000社を超える企業にご利用いただいているプロジェクト管理ツールです。
これらのコツを実践するには、優先順位、スプリントゴール、進捗、改善内容をチームで共有できる環境が役立ちます。Lychee Redmineでは、優先順位の整理からスプリントの進捗共有までを同じ環境で扱えます。
Neoバックログでプロダクトバックログを整理する
Neoバックログでは、プロダクトバックログの優先順位づけとスプリント計画を管理できます。プロダクトオーナーの優先順位判断と、チームのスプリント計画を同じ画面で進められることが特徴です。
プロダクトバックログの順番を変更すると、チームの実績ペースに基づいてスプリントへの割り当てが再計算されます。優先順位と計画を同じ画面で見直せます。
Neoカンバンでスプリントの進捗を共有する
Neoカンバンでは、スプリントの進捗をチームで共有できます。開発者が日常的に使う画面のため、軽快な操作性を重視して開発しています。
画面上にスプリントゴールを常に表示するため、日々の作業が届けたい価値につながっているかを確認しながら進めることも可能です。誰がどの項目を担当し、どこで止まっているかも把握しやすくなります。
無料トライアルで自社の運用との相性を確認する
Lychee Redmineには、30日間の無料トライアルを用意しています。実際の運用に近い形でお試しいただき、自社の進め方に合うかをご判断ください。
ガントチャートを使うプロジェクトと、Neoバックログ・Neoカンバンを使うプロジェクトは、同じ環境で管理できます。部門ごとに進め方が異なる組織でも、情報を一つの環境に集約できます。
無料トライアルは、クレジットカード登録不要です。プロジェクト管理を効率化したいと考えている方は、まずは使用感を試すことから始めてみましょう。
アジャイル開発とスクラム開発に関するよくある質問
ここでは、アジャイル開発とスクラム開発に関するよくある質問をまとめました。導入前の疑問解消にお役立てください。
スクラム開発を使わずにアジャイル開発はできますか？
スクラム開発を使わずにアジャイル開発はできます。スクラム開発は、アジャイル開発を実践する方法の一つです。
カンバンやXPなど、ほかの方法でもアジャイル開発の考え方を実践できます。既存の進め方を大きく変えずに改善したい場合は、カンバンを取り入れる方法もあります。
スクラム開発を導入するときは何から始めればよいですか？
対象となるプロダクトと、3つの責任を担う人を決めることから始めましょう。プロダクトオーナー、スクラム開発マスター、開発者を明確にすることが必要です。
そのうえで、プロダクトゴールと初期のプロダクトバックログを用意します。最初のスプリントプランニングで、スプリントゴールを作成します。
スプリントとイテレーションは同じですか？
厳密には異なります。イテレーションは、反復開発における一般的な反復の単位を指す言葉です。
一方のスプリントは、スクラム開発で定義された1か月以内の固定長イベントです。指している範囲が違うため、スクラム開発の文脈ではスプリントと呼びます。
スクラム開発が「つらい」と言われるのはなぜですか？
関係者の継続的な関与と、チームの自己管理が求められるためです。毎スプリントで計画と振り返りを重ねる進め方は、慣れるまで負担に感じられます。
責任の分担が曖昧なまま形だけ導入すると、負担だけが増えます。適用範囲を絞り、振り返りで進め方を調整していくと、負担を抑えられます。
まとめ：アジャイル開発とスクラム開発の関係を理解し、自社に合う進め方を選ぶことが重要
アジャイル開発は価値観と原則に基づく開発の考え方であり、スクラム開発はその考え方を実践するフレームワークです。両者は同じ階層の概念ではなく、アジャイル開発の価値観・原則を実践する方法の一つが、スクラム開発です。
スクラム開発には、3つの責任、5つのイベント、3つの成果物という構成要素があります。カンバンやXPも実践方法の一つであり、組み合わせて使うことも有効です。
どの手法を採用すべきか迷うときは、要件の変わりやすさ、チームの体制、プロダクトオーナーの関与度を確認しましょう。自社の条件に合う進め方を選び、振り返りながら整えていくことが成果につながります。
スクラム開発の運用を支える環境が必要な場合は、Lychee Redmineの無料トライアルをお試しください。プロジェクト管理に欠かせない機能を備えているため、案件管理のしやすさを改善できます。
30日無料トライアルをはじめる
- 多機能ガントチャート/カンバン/バックログ/リソース管理/CCPM/レポートなど
- ・ クレジットカード登録不要
- ・ 期間終了後も自動課金なし
- ・ 法人の方のみを対象
このサイトはreCAPTCHAによって保護されており、Googleのプライバシーポリシーと利用規約が適用されます。
