正しく理解しようアジャイルとスクラム 〜スクラムの概要を知ろう

前回はアジャイルやスクラムの生まれた背景や理念といった事を書かせて頂きましたが、今回はスクラムにフォーカスしてスクラムとは何なのかを簡単にご説明させて頂きます。スクラムは働き方のフレームワークだと言えます。なので、開発現場に限らずチームで働く様々な場面に適応させることが可能です。例えば、営業、学校、教会の運営などにも使われているようです。家庭でスクラムを使って家族の関係を改善されている方々もいるそうです。全体としてのイメージは下記をご参照下さい。

スクラム概要図
スクラム概要図

今回は上記の概要図をベースに解説を行って行きたいと思います。まずは役割について。

役割

役割
役割

Scrumで定義されている役割はスクラムマスター、プロダクトオーナー、チームの3つとなります。スクラムマスターはスクラムが適切に運用されるようにサポートし、障害を取り除き、チームを守りながら、コーチやファシリテーター、時には先生のように教えたり、メンターとなって相談にのったりしながらサポートします。スクラムが適さない場合はスクラム以外の選択肢を提案する事もスクラムマスターに求められます。プロダクトオーナーはプロダクトのビジョンを持ち、ステークホルダーと調整し予算やROIの最大化に責任を持つ事になりますので、ビジネス上の責任は全てプロダクトオーナーが持つ事になります。チームはプロダクトオーナーからの要求に答えられる必要があります。作りたい物を実現させる事に責任を持ちます。また、技術品質や開発スピードを高め、安定した開発ができるようにしていく事もチームの責任となります。

次にスプリント計画周りについて説明をします。

計画

計画
計画

*現在の最新のスクラムの定義ではスプリント計画パート1、パート2と分かれてはおりません。

スプリント計画ではプロダクトバックログという要求一覧の内容をPOがチームに共有し、それをどう実現するかをチームが考えてタスク化していきます。そして、スプリント内で行うタスクの一覧(計画)がスプリントバックログと呼ばれます。スプリント計画ではプロダクトバックログというインプットに対してスプリントバックログをアウトプットとして作る場というイメージをして頂ければと思います。

次にスプリント周りの説明をして行きます。

スプリント

スプリント
スプリント

スプリント計画が終わるとスプリントという期間に入ります。スプリントは1〜4週間で固定された開発サイクルで、このスプリント内で実際の開発を行って行きます。スプリントの期間中に発生するイベントとしては、日々行うディリースクラムとプロダクトバックログの手入れの時間が決まっています。ディリースクラムでは下記の3点を共有します

  • 前回のディリースクラムから今回までに行った事
  • 次回までに行う事
  • 課題の共有

また、プロダクトバックログの手入れの時間ではプロダクトバックログの見積もり、項目の分割、項目の詳細化、優先順位の入れ替え、項目追加や削除等を行って行き、プロダクトバックログを健全な状態に維持する為の時間です。特にいつやる事という定義は無いのですが、スプリントのトータル時間の5〜10%程度に設定するのが良い言われています。

なお、スプリントの最中に計画を変更する事は禁止されています。ですので、追加の要求や変更等は行えません。どうしても変更する必要が発生した場合はスプリントを停止し、再度計画し直す必要があります。

スプリントの終わりについて解説します。まずは出荷可能な製品単位の説明から始めます。

スプリント終わり

インクリメント
インクリメント

スプリントの終わりには出荷可能な製品単位で出来上がっている事が必要です。これは、動く成果物が必要だという事です。これが唯一の成果物です。スクラムでは、何パーセント出来ているというのは評価されず、作り終わった成果物のみが評価の対象となります。過去のスプリントでの成果物も合わせて現時点で出来たもが出荷可能な製品単位となります。
この図には出てないですが、出荷可能な製品単位の技術的な品質を定義しているのがDoneの定義となります。Doneの定義とは作り終わった時に何が終わっている必要があるかを定義した物です。例えばですが、ユニットテストが書かれていて初めて終わったと考えるエンジニアもいれば、そう考えないエンジニアがいる状況だと、コードの品質にむらが出来てしまいます。これを回避するのがDoneの定義です。そして、Doneの定義を拡張してい行く事が技術的な品質を高めて行く事につながります。

スプリントレビュー
スプリントレビュー

スプリントレビューはスプリントでの成果物(出荷可能な製品単位)を確認し、フィードバックをもらう場です。この時点でプロダクトオーナーが計画の際に明示した受入れ条件をクリアしてないと受入れられないという事になります。そして、プロダクトオナーを含め色々な方からフィードバックをもらい製品の改善を行うきっかけとする場です。

レトロスペクティブ
レトロスペクティブ

レビューが製品に対する改善の場であるのに対して、レトロスペクティブはチームの働き方を改善する場となります。自分たちの働き方を見直してより効率よく、より品質の高い仕事をする為には何をすべきかを考えて行きます。

以上で概要図の説明は終わりになります。駆け足でスクラムの概要図について説明をしてきましたが、文中にもあったようにこの図が作られた時点からもスクラムの改訂は行われておりますので、最新の情報についてはコアスクラム(英語)を参照して下さい。また、下記の文献を読んで頂ければさらに理解が深まるかと思います。

Scrum Primer(日本語版)

スクラムガイド(日本語版)

参照情報

【Scrum Primer(日本語版)】
http://assets.scrumfoundation.com/downloads/5/THESCRUMPRIMER_ja.pdf

【スクラム概要図】1)この記事で使っている画像は全てここの物を使っております
http://www.scrumprimer.org/overview/en_scrum_overview1.pdf

【コアスクラム】
https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

【スクラムガイド】
http://www.scrumguides.org/

脚注   [ + ]

1. この記事で使っている画像は全てここの物を使っております

榎本 明仁

Lv.
4
EXP.
1,323

ベンチャーでエンジニアから開発責任者になり、2008年ごろにスクラムに出会い会社に導入、この良さをもっと世の中に広めたい、最高のチーム作りをサポートしたいという思いから2012年にOdd-eに入社し、お客様と一緒に改善活動に取り組んでおります。Odd-eはより良い開発の為のトレーニングやコーチングを提供している会社です。

この執筆者の記事一覧

コメントはこちらのに同意の上、投稿ください。