スクラムとは

スクラムはアジャイル開発手法の一つで、「アジャイル開発のミニマムセット」と呼ばれるコンパクトなアジャイル開発フレームワークです。アジャイル開発の中でもっとも使われている手法です。

「スクラム」は、単純化すると以下の4つの特徴を持ちます。

  • スプリントという一定の期間毎に動くソフトウェアを作る
  • 要求はプロダクトバックログという優先順位付けされた一覧表に保管される
  • 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する
  • スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行う

スクラムを適用した開発事例は「アジャイルモデリングへの道Vol.2:スクラム組んで開発しよう!」をご覧ください。

ニーズに即したプロダクトを素早く開発することを可能にしたスクラム

スクラムは、スプリントという一定の期間毎に、プロダクトバックログ項目の優先順位が高いものから動くソフトウェアを作り、作成されたソフトウェアを評価する形で開発を進めます。その結果、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発することを可能にしました。この利点がスクラムの普及の大きな原動力となりました。

変化する要求を管理するプロダクトバックログ

プロダクトバックログ項目は優先順位付けされた要求の一覧です。プロダクトバックログはプロダクトオーナーが責任をもって管理します。プロダクトバックログは、開発初期にすべてを確定して要求を固定するのではなく、開発を進める中で変化していきます。


スクラムにおける開発の流れのイメージ(スクラムの一部のイベントと成果物のみ記載)

プロダクトオーナーの役割

プロダクトオーナーは、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)に対する仮説をプロダクトバックログの項目として表現し、スプリント毎にできる動くソフトウェア(プロダクトの増分)を評価することで自らの仮設の妥当性を確認しながらプロダクトの開発を進めることができます。その結果として、開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発することができます。

プロダクトオーナーは以下のような作業を行います。

  • プロダクトバックログを管理する
  • プロダクトの機能、優先順位、リリース日とリリース内容を決める
  • プロダクト(の増加分)について受け入れるかどうかを判断する

プロダクトバックログ項目を表現するユーザーストーリー

スクラムはコンパクトなアジャイル開発フレームワークとして誕生したため、プロダクトバックログ項目の表現形式や定義プロセスについての具体的な方法は当初既定されていませんでした。スクラムが発展する過程で、XP(eXtreme Programming)というアジャイル手法の考え方を取り入れ、ユーザーストーリーを用いてプロダクトバックログ項目を定義することが今では一般的です。

ユーザーストーリーは、ユーザーと開発者の両方が理解できる言葉で、ユーザーにとってのプロダクトの価値やシステムの振る舞いを示します。ユーザーストーリーは、従来のように開発者の視点でシステムの機能を説明するものではなく、ユーザーに対する価値を重視するという点で優れています。

ユーザーストーリーは、一般的には下図に示すようなユーザーの声形式で表現します。

またユーザーストーリーを考える方法として、Ron Jefferiesにより3C (カード、会話、確認)の3段階でユーザーストーリーを定義する方法が提案されました。

  • Card(カード): 内容を記述し、計画やリマインダとして使用 する
  • Conversation(会話): 詳細化するための会話
  • Confirmation(確認): 完了しているかどうかの判断材料

さらに、ユーザーストーリーマッピングという手法が登場し、ユーザーストーリーをリリースや要求種別を軸に並べて各リリースの内容を考えることが提案されました。これらの方法により、開発者ではないプロダクトオーナーが自分の理解できる言葉で要求を表現したり、それらについて開発者と会話したり、リリース計画の計画策定に参加したりすることが可能になりました。

プロダクトバックログのライフサイクル

アジャイル開発ではスプリントを進めながら徐々に要求を明確にして確定していきます。その要求を管理するプロダクトバックログが、スプリントを進める中でどのように変化するのか、以下に説明します。

開発初期のプロダクトバックログ:開発初期のプロダクトバックログには、その時点で明確な要求が優先順位の上位に並べられます。優先順位の下位には、その時点では曖昧だがプロダクトに必要だと考えている要求が並べられます。

各スプリント:各スプリントでは、プロダクトバックログの優先順位の高いものの中から、そのスプリントで開発するバックログ項目をプロダクトオーナーと開発チームが合意して決定します。開発チームはそのスプリントで開発すると決定したバックログ項目の具体的な作業を計画し(スプリント計画、スプリントバックログ)、開発します。

このとき、スプリントで開発するバックログ項目の内容は明確でなければいけません。また、そのスプリントで何ができていれば完了とするのか、という完了条件を明確にしてから開発を進めます。

プロダクトバックログは各スプリントの5〜10%の時間を使って、1〜2回先のスプリントのためにバックログ項目の詳細、見積り、優先度を見直してプロダクトバックログを洗練します(プロダクトバックログの手入れ)。開発初期は頻繁に行い、安定したら定期的に行います。

スプリントの終わりには、プロダクトオーナーと利害関係者、開発チームが集まって、そのスプリントで開発したプロダクトの増加分をレビューします(スプリントレビュー)。開発チームはデモを行い、プロダクトオーナーは完了条件を基に完了したかどうかを判断します。プロダクトオーナーは、このスプリントレビューを判断材料の一つとして、新たな要求を発見したり、プロダクトバックログの優先順位を見直したりします。

こうして、プロダクトバックログは変化します。

開発後期のプロダクトバックログ:スプリントを繰り返し、開発を進めていくと、優先順位の高いバックログ項目の中には完了するものも出てくるでしょう。開発後半のプロダクトバックログには、完了したバックログ項目が並び、優先順位が低い要求も開発初期と比べると要求が明確になって詳細化されています。

アジャイルで変化するビジネスへの適応力を高めよう

技術解説記事「アジャイルモデリングへの道」

アジャイル開発に関する技術解説記事を以下でご覧いただけます。アジャイル開発手法の基本的な概念やプラクティス、スクラムの概要などを解説しています。



スクラムを補うものとしてオージス総研がおすすめすること


アジャイル要求(DtoD)でスクラム+ユーザーストーリーを補う

プロダクトバックログを表現する形式としてユーザーストーリーをご紹介しましたが、スクラムとユーザーストーリーを組み合わせただけでは不十分な点があります。

まず、上で述べた内容はユーザーストーリーをどのように考案するのかという具体的な方法を示すものではありません。最初の発想、会話、確認のプロセスが不明確です。

また、ユーザーストーリーはユーザーにとってのプロダクトの価値を定義しますが、これは機能的な要求に偏っています。ユーザーストーリーで表すだけではデータや品質特性、環境など、機能的な要求以外のニーズを検討できません。

さらに、ユーザーストーリーの考案や優先順位付けをプロダクトオーナーが実際に行えるのか、行えたとしてもプロダクトオーナーの負担が非常に重い、という問題があります。

オージス総研では、これらの問題をアジャイル要求(DtoD)を実践することで解決することを提案します。DtoDはアジャイル開発における要求分析を行うためのフレームワークです。DtoDは3つの時間軸とプロダクトの7側面という観点を用いて、プロダクトに対するニーズとその実現スケジュールをワークショップの中で利害関係者間で話し合い、合意する、具体的な方法を示します。

DtoDを実践することで、スクラムとユーザーストーリーの組み合わせでは足りなかった以下の点を補うことができます。

  • ユーザーストーリーを定義する3C (カード、会話、確認)の具体的な実行方法の提示
  • プロダクトの7側面という観点を用いて機能的な要求だけでなく、データや品質特性、環境など多面的な要求を表現
  • ビジネス分析者がワークショップのファシリテーターやモデラーの役割を担い、プロダクトオーナーの役割を分担
>>詳しくはアジャイル要求(DtoD)の解説ページをご覧ください

企業や事業部レベルの大規模アジャイル開発にはSAFeを導入

スクラムはチーム単位のアジャイル開発を行うためのフレームワークです。企業や事業部と言った大規模なレベルでアジャイル開発を行うためには、部署を越えて一貫性のある戦略や、プロダクト(システム)の企画、大規模なプロジェクトの管理、管理職の役割など従来手法を中心に体系化されていた様々な活動を超えた新たな取り組みが必要となります。このような場合には、SAFe(Scaled Agile Framework)を導入し、企業や事業部レベルでアジャイルのプラクティスを適用することができます。

>>詳しくはSAFe(Scaled Agile Framework)の解説ページをご覧ください

アジャイル導入の移行シナリオ OGIS Scalable Agile Method

これからアジャイル開発を導入する組織はどうすればよいのか。当社では日頃よくいただく疑問に対して、アジャイル導入の移行シナリオをアジャイル開発フレームワーク「OGIS Scalable Agile Method(以降、OSAMと略します)」をベースに提案します。 OSAMはスクラム、アジャイル要求、SAFeと言ったアジャイルに関する手法やフレームワークを組み合わせたものです。アジャイル開発に対するニーズとアジャイル開発の導入障壁によって二つの移行シナリオを考案しました。

>>詳しくは、アジャイル導入の移行シナリオ / OGIS Scalable Agile Method の解説ページをご覧ください



アジャイル・スクラムに関するトレーニングのご案内

オージス総研ではアジャイル開発をこれから学びたい方、スクラムをこれから現場に取り入れたいと考えている方向けにアジャイルやスクラムに関するトレーニングを実施しています。いずれも演習を通じて理解を深めていただける内容です。

体験!アジャイル超入門(0.5日版)

アジャイル開発をこれから学びたいお客様に向けた入門トレーニングコースです。アジャイル開発で使用される用語や考え方(価値と原則)を学習し、アジャイル体験ゲームの演習によってアジャイルの概要を体験します。ソフトウェア開発者だけでなく、アジャイル開発に関連する管理者やユーザ部門の方にもおすすめできる内容です。

スクラム入門

スクラムを採用したプロジェクトの進め方を段階的に学習する入門トレーニングコースです。ブロック玩具を使った演習でスクラムの基本概念の理解を深めます。スクラムに関する知識を習得したい方、スクラムを現場に取り入れたいと考えている方を対象としたトレーニングです。

ページトップへ戻る

お問い合わせ

お問い合わせ

アジャイル開発に関するお問い合わせはこちら