スクラムとは？アジャイル開発の基本や進め方を初心者向けにわかりやすく解説【図解付き】

はじめに

システム開発について勉強していると、スクラムという言葉が登場します。

スクラムでは、開発する機能を小さく分け、短い期間ごとに成果を確認しながら、製品やサービスを改善していきます。

しかし、初めてスクラムを学ぶ方にとっては、

• スクラムとアジャイルは同じものなのか
• スプリントとは何をする期間なのか
• スクラムマスターはチームの上司なのか
• プロダクトオーナーとプロジェクトマネージャーは何が違うのか
• デイリースクラムは毎朝の進捗報告会なのか
• バックログ、ベロシティ、バーンダウンチャートはどのように関係するのか

といった点が分かりにくいのではないでしょうか。

スクラムを一言で表すと、

「複雑な問題に対応するため、短い期間で成果を作り、確認と改善を繰り返すフレームワーク」

です。

スクラムは、細かな作業手順をすべて決めた開発手法ではありません。

チームが短い周期で成果を作り、その結果を確認し、次の行動を調整するための枠組みです。公式のスクラムガイドでは、スクラムは複雑な問題に対して価値を生み出すための、軽量なフレームワークとして定義されています。

この記事では、スクラムの基本的な考え方、スクラムチームの責任、イベント、作成物、アジャイルやウォーターフォールとの違いについて、会話を中心に初心者向けにわかりやすく解説します。

スクラムとは？

スクラムとは、短い期間で少しずつ成果を作り、確認と改善を繰り返す仕事の進め方だよ。

最初にすべての計画を決めないの？

大きな目標や方向性は決めるけれど、遠い将来の細かな作業まで最初に固定しないんだ。実際に作って分かったことを、次の計画へ反映していくよ。

スクラムでは、スプリントと呼ばれる一定の短い期間を繰り返します。

各スプリントでは、価値のある成果を作り、利用者や関係者からの反応、開発中に判明した問題、市場や要件の変化などを確認します。

そして、確認した結果を次のスプリントへ反映します。

計画する
  ↓
作る
  ↓
確認する
  ↓
改善する
  ↓
次のスプリントへ

この短い改善サイクルを繰り返すことで、不確実性の高い開発にも対応しやすくなります。

スクラムという名前の由来

スクラムという言葉は、ラグビーのスクラムに由来します。

ラグビーでは、複数の選手が肩を組み、チームとして一体になってボールを前へ進めます。

システム開発のスクラムでも、特定の人から細かな指示を受けるだけではなく、チーム全体で協力して目標の達成を目指します。

一人の監督が全員へ細かな指示を出すというより、チームで連携して進むイメージなんだね。

そう。スクラムチームには、自己管理しながら協力することが求められるよ。

スクラムとアジャイルの違い

アジャイルは考え方、スクラムはフレームワーク

スクラムとアジャイルは同じものなの？

同じではないよ。アジャイルは価値観や考え方で、スクラムはその考え方を実践するために利用されるフレームワークの一つなんだ。

アジャイルでは、変化へ対応しながら、価値のあるものを早く継続的に提供することを重視します。

スクラムは、そのために次のような枠組みを定めています。

• スクラムチームの責任
• スプリントなどのイベント
• プロダクトバックログなどの作成物
• 透明性・検査・適応という考え方

アジャイルという大きな考え方の中に、スクラムという実践方法があるんだね。

スクラムを料理で例えてみよう

スクラムの流れを、身近な例で説明できる？

新しいレストランのコース料理を開発する場合で考えてみよう。

従来型の進め方では、最初に前菜からデザートまでをすべて考え、数か月かけて完成させてから、初めて客へ提供するかもしれません。

しかし、完成後に、

• 量が多すぎる
• 味付けが客層に合わない
• 調理時間が長すぎる
• 人気のない料理が含まれている

と判明すると、大きな手直しが必要になります。

スクラムの考え方では、まず短い期間で小さな試食コースを作ります。

1. 今回試す料理を決める
2. 短期間で実際に作る
3. 試食してもらう
4. 感想や問題点を確認する
5. 次の試作へ反映する

全部完成してから評価するのではなく、途中で何度も試食してもらうんだね。

そう。早い段階で反応を得られるから、間違った方向へ進み続ける危険を減らせるんだ。

スクラムの基本となる経験主義

スクラムは、経験主義とリーン思考を基礎としています。

経験主義とは、実際に経験したことや観察できる事実をもとに判断する考え方です。

最初からすべてを正確に予測できるとは考えず、実際に作業した結果から学びます。

スクラムの経験主義は、次の3本柱によって支えられています。

• 透明性
• 検査
• 適応

透明性とは？

透明性とは、仕事の状況や判断に必要な情報が、関係者に分かる状態になっていることです。

例えば、

• 何を目指しているのか
• どの作業が残っているのか
• 何が完成しているのか
• どのような問題が起きているのか
• 完成の基準は何か

といった情報を共有します。

問題を隠したままだと、正しい判断ができないね。

そう。検査と改善を行うためには、まず実態が見える必要があるんだ。

検査とは？

検査とは、成果物や進捗状況を定期的に確認し、問題や望ましくない変化がないか調べることです。

スクラムでは、スプリントレビューやデイリースクラムなどのイベントを通じて、成果や進み方を検査します。

ただし、検査は誰かを監視して責任を追及するためのものではありません。

目標へ近づいているか、現在の方法が適切かを確認するために行います。

適応とは？

適応とは、検査によって問題や変化が見つかったとき、計画や方法を調整することです。

例えば、

• 優先順位を変更する
• 作業方法を改善する
• 不要な機能を作らないと決める
• スプリントの進め方を見直す
• 新しく分かった要望をバックログへ追加する

といった行動が適応に当たります。

見えるようにして、確認して、必要なら変えるんだね。

それがスクラムの基本的な循環だよ。

スクラムの5つの価値基準

スクラムでは、チームが次の5つの価値基準を実践することを重視します。

• 確約
• 集中
• 公開
• 尊敬
• 勇気

確約

目標を達成し、チームとして互いを支えることに責任を持ちます。

単に「決めた作業量を絶対に完了する」という意味ではなく、目標や品質、チームの成功に真剣に取り組むことです。

集中

スプリントゴールと、その達成に必要な作業へ集中します。

途中で無関係な作業を次々に追加すると、重要な成果を完成させにくくなります。

公開

作業状況、問題、学んだことを率直に共有します。

問題を隠さず、より良い方法を話し合える状態を作ります。

尊敬

チームメンバーを能力のある独立した人として尊重します。

立場や専門分野が違っても、互いの意見や仕事を大切にします。

勇気

難しい問題に向き合い、正しいと思うことを行います。

例えば、無理な要求へ問題点を伝えたり、失敗を認めて方法を変えたりすることも勇気に含まれます。

スクラムチームとは？

スクラムチームは、次の3つの責任で構成されます。

• プロダクトオーナー
• スクラムマスター
• 開発者

公式のスクラムガイドでは、これらを上下関係のある役職ではなく、スクラムチーム内の責任として整理しています。スクラムチームは小規模で、チーム内に下位チームや階層を設けず、一つのプロダクトゴールへ集中します。

プロダクトオーナーとは？

プロダクトオーナーは、スクラムチームが生み出すプロダクトの価値を最大化する責任を持つ人です。

主な責任は、プロダクトバックログを効果的に管理することです。

具体的には、次のようなことを行います。

• プロダクトゴールを明確にする
• 必要な機能や改善項目を整理する
• バックログ項目の優先順位を決める
• 関係者の要望を整理する
• チームが取り組むべき価値を明確にする

顧客から頼まれた機能を全部そのまま登録する人？

それだけではないよ。要望を集めたうえで、何を先に作れば価値が高まるかを判断するんだ。

スクラムマスターとは？

スクラムマスターは、スクラムが正しく理解され、効果的に実践されるよう支援する人です。

主な活動には、次のようなものがあります。

• スクラムの考え方をチームへ伝える
• チームの自己管理を支援する
• チームの進行を妨げる問題の解消を支援する
• イベントが目的に沿って行われるよう支援する
• 組織全体のスクラム導入を支援する

チームメンバーへ命令する管理職なの？

違うよ。スクラムマスターは、メンバーへ作業を割り当てる上司ではないんだ。

スクラムマスターは、チームが自分たちで考えて改善できるように支援します。

会議の司会だけをする人でもありません。

開発者とは？

開発者は、各スプリントで利用可能なインクリメントを作る責任を持つ人たちです。

「開発者」という名称ですが、プログラマーだけを意味するわけではありません。

プロダクトによっては、次のような専門家も含まれます。

• プログラマー
• デザイナー
• テスター
• インフラエンジニア
• データ分析担当者
• 業務知識を持つ専門家

開発者は、スプリント中の作業計画を作り、品質を守り、スプリントゴールの達成へ向けて日々計画を調整します。

スクラムチームの責任比較

プロダクトオーナーが何を重視するかを決め、開発者が作り、スクラムマスターがチームの進め方を支えるんだね。

大まかにはその理解でいいよ。ただし、全員が同じスクラムチームとして一つの目標を目指すことが大切だよ。

スクラムのイベント

スクラムには、次の5つのイベントがあります。

1. スプリント
2. スプリントプランニング
3. デイリースクラム
4. スプリントレビュー
5. スプリントレトロスペクティブ

スプリントは、ほかのすべてのイベントを含む入れ物です。各イベントは、作成物を検査し、必要に応じて適応するための正式な機会として位置付けられています。

スプリントとは？

スプリントとは、価値のあるインクリメントを作るための一定期間です。

スプリントの長さは、1か月以内と定められています。

一つのスプリントが終わると、次のスプリントがすぐに始まります。

スプリント中には、次の活動が含まれます。

• スプリントプランニング
• デイリースクラム
• 開発作業
• スプリントレビュー
• スプリントレトロスペクティブ

スプリントは開発作業だけをする期間ではないんだね。

そう。計画、開発、確認、改善を含む一つのサイクル全体だよ。

スプリントプランニングとは？

スプリントプランニングは、スプリントの開始時に行う計画です。

主に次の3点を話し合います。

1. このスプリントには、なぜ価値があるのか
2. このスプリントで、何を完成させるのか
3. 選んだ作業を、どのように完成させるのか

ここで、スプリントの目的となるスプリントゴールを決めます。

また、プロダクトバックログから今回取り組む項目を選び、実現方法を計画します。

デイリースクラムとは？

デイリースクラムは、開発者がスプリントゴールへ向けた進捗を確認し、今後の作業計画を調整するためのイベントです。

毎日15分で行います。

メンバーが上司へ昨日の作業を報告する会議？

それはよくある誤解だよ。デイリースクラムは、開発者が自分たちの計画を調整するために行うんだ。

デイリースクラムでは、次のような点を確認します。

• スプリントゴールへ近づいているか
• 予定どおりに進んでいるか
• 問題や障害があるか
• 今日の作業をどう調整するか

以前は「昨日したこと・今日すること・障害」の3点を話す形式が広く知られていましたが、現在のスクラムガイドでは固定の質問形式は指定されていません。

目的を達成できるなら、チームに合った進め方を選べます。

スプリントレビューとは？

スプリントレビューでは、スプリントで作った成果を確認し、今後何をするかを関係者と話し合います。

主な内容は次のとおりです。

• 完成したインクリメントを確認する
• 関係者から意見を得る
• 市場や利用状況の変化を確認する
• 今後の方向性を話し合う
• 必要に応じてプロダクトバックログを調整する

完成した機能を発表する会議？

発表だけではないよ。成果を材料に、今後の方向性を一緒に検討するイベントなんだ。

スプリントレビューは、開発チームだけで反省する場ではありません。

利用者、顧客、経営層などのステークホルダーと、プロダクトを検査する機会です。

スプリントレトロスペクティブとは？

スプリントレトロスペクティブは、チームの仕事の進め方を振り返り、改善策を考えるイベントです。

日本語では、スプリント振り返りと呼ばれることもあります。

例えば、次のような点を話し合います。

• うまくいったこと
• うまくいかなかったこと
• 作業を妨げた問題
• コミュニケーションの改善点
• 品質を高める方法
• 次のスプリントで試す改善策

スプリントレビューと何が違うの？

レビューは主にプロダクトの成果を確認し、レトロスペクティブは仕事の進め方を改善するんだ。

スクラムイベント一覧

スプリントが短い場合、各イベントも通常はそれに応じて短くなります。

スクラムの3つの作成物

スクラムには、次の3つの作成物があります。

• プロダクトバックログ
• スプリントバックログ
• インクリメント

それぞれの作成物には、進捗や価値を測るためのコミットメントが対応しています。2020年版スクラムガイドでは、プロダクトゴール、スプリントゴール、完成の定義が各作成物に対応するコミットメントとして明確に整理されました。

プロダクトバックログとは？

プロダクトバックログは、プロダクトを改善するために必要な項目を、優先順位を付けて並べた一覧です。

例えば、ECサイトでは次のような項目が考えられます。

• 商品検索機能を追加する
• クレジットカード決済へ対応する
• 画面の表示速度を改善する
• 注文履歴を表示する
• セキュリティ上の問題を修正する

最初に全部決めて、その後は変更しないの？

プロダクトバックログは継続的に変化するよ。利用者の反応や市場の変化、新しく判明した問題を反映するんだ。

プロダクトバックログは単なる要望一覧ではありません。

プロダクトの価値を高めるために、何へ取り組むべきかを整理したものです。

プロダクトゴールとは？

プロダクトゴールは、スクラムチームが目指すプロダクトの将来の状態です。

例えば、

「初めて利用する人でも、5分以内に商品を注文できるECサイトにする」

といった目標です。

プロダクトバックログの項目は、この大きな目標へ近づくための具体的な作業になります。

スプリントバックログとは？

スプリントバックログは、今回のスプリントで行う作業計画です。

次の内容で構成されます。

• スプリントゴール
• スプリントで選択したプロダクトバックログ項目
• それらを完成させるための計画

スプリントバックログは、開発者が管理します。

スプリント中に新しいことが分かれば、スプリントゴールを損なわない範囲で計画を調整できます。

スプリントゴールとは？

スプリントゴールは、そのスプリントで達成したい一つの目的です。

例えば、

「利用者が商品名から商品を検索できるようにする」

という目標を設定します。

スプリント中の細かな作業が変わっても、スプリントゴールがあれば、何を優先すべきか判断しやすくなります。

インクリメントとは？

インクリメントとは、プロダクトゴールへ近づくために作られた、利用可能な成果の積み重ねです。

単に作業途中のプログラムを指すわけではありません。

実際に利用できる品質を満たしている必要があります。

スプリントが終わるたびに、必ず利用者へ公開するの？

公開できる状態であることは重要だけれど、スプリントの終了時に必ずリリースしなければならないわけではないよ。

スプリント中に複数のインクリメントを作り、必要に応じてリリースすることもできます。

完成の定義とは？

完成の定義は、インクリメントが必要な品質を満たしているか判断するための基準です。

例えば、次のような条件を設定します。

• コードレビューが完了している
• 必要なテストに合格している
• 重大な不具合が残っていない
• セキュリティ基準を満たしている
• 利用手順が更新されている

プログラムを書き終えただけでは、完成とは限らないんだね。

そう。チーム内で完成の意味が違うと、品質や進捗を正しく判断できないからね。

プロダクトバックログリファインメントとは？

プロダクトバックログリファインメントとは、バックログ項目を継続的に見直し、今後取り組める状態へ整える活動です。

例えば、次のことを行います。

• 項目の内容を詳しくする
• 大きすぎる項目を分割する
• 優先順位を見直す
• 必要な作業量を予測する
• 不明点を確認する
• 不要になった項目を削除する

スクラムの正式なイベントなの？

重要な活動だけれど、スクラムガイドで定義された5つのイベントの一つではないよ。

リファインメントを、決まった曜日に会議として実施するチームもあります。

しかし、スクラム上は継続的に行う活動です。

スクラムの全体的な流れ

スクラムの流れを整理すると、次のようになります。

1．プロダクトゴールを定める

チームが長期的に目指すプロダクトの状態を明確にします。

2．プロダクトバックログを整理する

プロダクトゴールへ近づくために必要な機能、改善、修正などを優先順位付きで管理します。

3．スプリントプランニングを行う

今回のスプリントで達成するスプリントゴールと、取り組むバックログ項目を決めます。

4．スプリントでインクリメントを作る

開発者が協力し、完成の定義を満たす成果を作ります。

5．デイリースクラムで計画を調整する

毎日、スプリントゴールへ向けた進み方を確認し、必要に応じて計画を変えます。

6．スプリントレビューで成果を確認する

ステークホルダーと成果を確認し、次に必要なことを検討します。

7．レトロスペクティブで進め方を改善する

チームの仕事の進め方を振り返り、次のスプリントで試す改善策を決めます。

プロダクトゴール
      ↓
プロダクトバックログ
      ↓
スプリントプランニング
      ↓
スプリント
 ┌─────────────┐
 │ 開発・デイリースクラム │
 └─────────────┘
      ↓
インクリメント
      ↓
スプリントレビュー
      ↓
レトロスペクティブ
      ↓
次のスプリントへ

スクラムとウォーターフォールの違い

ウォーターフォールは、一般に工程を順番に進める開発モデルです。

例えば、

1. 要件定義
2. 設計
3. 実装
4. テスト
5. リリース

という流れで進めます。

一方、スクラムでは、短い期間の中で必要な分析、設計、実装、テストなどを行い、利用可能な成果を少しずつ増やします。

スクラムの方が必ず優れているの？

そうではないよ。要件が固定され、変更が少ない仕事では、ウォーターフォール型の計画が適する場合もあるんだ。

実際の開発では、組織や契約に合わせて両方の考え方を組み合わせることもあります。

スクラムとカンバンの違い

カンバンは、作業の流れを可視化し、同時に行う作業量を制限しながら、仕事を継続的に流す考え方です。

スクラムチームが、作業の流れを見えるようにするためにカンバンボードを利用することもあります。

スクラムとカンバンは、必ずしも排他的な関係ではありません。

スクラムで使われる関連用語

ユーザーストーリー

ユーザーストーリーは、利用者の視点から必要な機能を簡潔に表現する方法です。

例えば、次のように書きます。

購入者として、
商品名で商品を検索したい。
なぜなら、目的の商品を早く見つけたいからだ。

ただし、ユーザーストーリーはスクラムガイドで必須とされている形式ではありません。

プロダクトバックログ項目を表すためによく利用される方法の一つです。

ストーリーポイント

ストーリーポイントは、作業の大きさを相対的に見積もる方法です。

作業時間だけでなく、次の要素を含めて考える場合があります。

• 作業量
• 複雑さ
• 不確実性
• リスク

1、2、3、5、8のようなフィボナッチ数列に近い値を使うチームもあります。

ただし、ストーリーポイントもスクラムで必須のものではありません。

ベロシティ

ベロシティは、1回のスプリントで完成できた作業量を表す指標です。

ストーリーポイントを使う場合、スプリント内で完成した項目のポイント合計をベロシティとして扱うことがあります。

ベロシティは、今後どの程度の作業を完了できそうか予測する参考になります。

ただし、チーム同士を比較したり、個人を評価したりするための点数ではありません。

バーンダウンチャート

バーンダウンチャートは、残っている作業量が時間の経過とともにどのように減っているかを表すグラフです。

スプリントの進捗状況を見えるようにするために利用されます。

ただし、バーンダウンチャートもスクラムで必須の作成物ではありません。

スクラムガイドでは、進捗予測に使える方法としてバーンダウン、バーンアップ、累積フローなどが知られていますが、それらが経験主義の代わりになるわけではないと説明されています。

スクラム関連用語の整理

スクラムのメリット

変化へ対応しやすい

短いスプリントごとに計画を見直すため、市場や利用者の要望が変わった場合にも対応しやすくなります。

早い段階で成果を確認できる

すべてを完成させてから確認するのではなく、短期間ごとにインクリメントを作ります。

そのため、方向性の誤りや使いにくさを早く発見できます。

優先順位の高い機能から作れる

プロダクトバックログに優先順位を付けることで、価値の高い機能や、リスクの高い問題から取り組めます。

問題を早く発見しやすい

デイリースクラム、レビュー、レトロスペクティブなど、定期的に状況を確認する機会があります。

問題を長期間放置する危険を減らせます。

チームで知識を共有しやすい

スクラムチーム全体で目標や作業状況を共有するため、特定の人だけが情報を持つ状態を減らしやすくなります。

継続的に仕事の進め方を改善できる

レトロスペクティブで定期的に進め方を振り返るため、開発プロセスそのものを改善できます。

スクラムのデメリット・注意点

チームの主体性が必要

決められたイベントを実施すれば、スクラムは成功するの？

形式だけまねしても、うまくいかないことがあるよ。

スクラムでは、チームが自分たちで計画し、問題を共有し、改善する必要があります。

常に上司の指示を待つ文化では、自己管理が機能しにくくなります。

プロダクトオーナーの判断が重要

優先順位が頻繁に変わったり、プロダクトオーナーに決定権がなかったりすると、チームが何を目指すべきか分からなくなります。

関係者の協力が必要

スプリントレビューで意見を得られなければ、利用者や市場の反応を次の計画へ反映しにくくなります。

長期的な費用や納期を固定しにくい場合がある

スクラムでは、作る内容を学習しながら調整します。

そのため、最初の段階で遠い将来のすべての機能、費用、納期を完全に固定する契約とは相性が悪い場合があります。

イベントが目的を失うことがある

目的を理解せずに形式だけ実施すると、次のような状態になりがちです。

• デイリースクラムが上司への報告会になる
• レビューが完成機能の発表会だけになる
• レトロスペクティブで不満を言うだけになる
• プランニングで作業を一方的に割り当てる
• バックログが要望をためるだけの一覧になる

スクラムが向いている仕事

スクラムは、次のような仕事に向いています。

• 最初に正解が分からない
• 利用者の反応を見ながら改善したい
• 技術的な不確実性が高い
• 市場や要望が変化しやすい
• 小さな成果を継続的に提供できる
• チームで協力して進められる

代表的な例は、ソフトウェアやWebサービスの開発です。

ただし、スクラムはソフトウェア開発だけに限定されたものではありません。

新規事業、製品開発、マーケティング、組織改善など、複雑で変化の多い仕事にも応用されます。

スクラムが向いていない可能性がある仕事

次のような場合は、スクラムをそのまま適用しにくいことがあります。

• 作業手順が完全に決まっている
• 毎回同じ作業を繰り返す
• 成果を小さく分けて確認できない
• チームへ判断権限を渡せない
• 利用者や関係者から継続的な意見を得られない
• 変更を一切許容しない契約になっている

スクラムは、どんな仕事にも使えばよいわけではないんだね。

そう。仕事の不確実性や組織の状況に合わせて選ぶ必要があるよ。

ITパスポート・基本情報・応用情報の試験対策

スクラムは、アジャイル開発に関する代表的なフレームワークとして、ITパスポート、基本情報技術者試験、応用情報技術者試験で押さえておきたい用語です。

試験別に押さえたい内容

試験で覚えたい重要用語

試験問題で注目する表現

よくある誤解

スクラムはアジャイルと同じである

スクラムは、アジャイルの価値観を実践するために利用されるフレームワークの一つです。

アジャイルには、スクラム以外にもさまざまな考え方や実践方法があります。

スクラムマスターはプロジェクトの上司である

スクラムマスターが、誰にどの仕事をさせるか決めるんだよね？

違うよ。開発者は自分たちで作業計画を管理するんだ。

スクラムマスターは、命令や評価を行う管理職ではありません。

スクラムの実践を支援し、チームが自己管理できるようにする役割です。

プロダクトオーナーは顧客の要望を伝えるだけである

プロダクトオーナーは、顧客や関係者から要望を集めるだけではありません。

要望、市場、費用、リスク、プロダクトゴールなどを考慮し、何へ取り組むと価値が高まるかを判断します。

デイリースクラムは上司への進捗報告会である

デイリースクラムは、開発者がスプリントゴールへ向けて自分たちの計画を調整するイベントです。

上司やプロダクトオーナーへ、個人の作業状況を報告することが目的ではありません。

スプリント中は何も変更してはいけない

スプリント中でも、新しく分かったことに応じて作業計画を調整できます。

ただし、スプリントゴールを危険にさらす変更は避けます。

プロダクトオーナーと開発者は、必要に応じてスプリントの範囲を明確にしたり、再交渉したりします。

スプリントが終わるまでリリースしてはいけない

完成の定義を満たすインクリメントは、スプリント終了前でもリリースできます。

スプリントレビューは、リリースを許可するための関門ではありません。

スプリントでは必ずすべての予定作業を完成させる

スプリントでは、スプリントゴールの達成を目指します。

最初に選んだすべての作業を絶対に完了することが、スクラムの最優先事項ではありません。

計画は予測であり、途中で新しいことが分かれば調整されます。

バーンダウンチャートはスクラムで必須である

バーンダウンチャートは、残作業を可視化する便利な方法です。

しかし、スクラムで定義された3つの作成物には含まれておらず、使用は必須ではありません。

ベロシティが高いチームほど優秀である

ベロシティは、同じチームが今後の作業量を予測するための参考値です。

チームによって見積り方やポイントの基準が異なるため、別チームとの能力比較には適していません。

ベロシティを評価指標にすると、ポイントを大きく付けるだけで数値を上げられてしまう可能性があります。

スクラムを導入すれば開発が必ず速くなる

スクラムの目的は、単純に作業速度を上げることではありません。

価値のある成果を早く確認し、間違いや変化に対応することが目的です。

スクラムを導入した直後は、問題が見えるようになり、一時的に遅くなったように感じる場合もあります。

会議を増やすのがスクラムである

スクラムのイベントには、それぞれ検査と適応の目的があります。

目的を理解せず、従来の定例会議を残したままスクラムイベントを追加すると、会議が増えるだけになります。

必要な情報をイベント内で共有し、不要な会議を減らすことも重要です。

まとめ

スクラムとは、複雑な問題へ対応するため、短い期間で成果を作り、検査と適応を繰り返すフレームワークです。

スクラムでは、1か月以内のスプリントを繰り返し、各スプリントで利用可能なインクリメントを作ります。

そして、成果や作業状況を確認し、得られた情報を次の計画へ反映します。

スクラムチームは、次の3つの責任から構成されます。

• プロダクトオーナー
• スクラムマスター
• 開発者

また、スクラムには5つのイベントと3つの作成物があります。

スクラムを成功させるには、イベントの形式をまねるだけでは不十分です。

透明性、検査、適応という3本柱と、確約、集中、公開、尊敬、勇気という5つの価値基準を理解し、チームが自ら問題を発見して改善する必要があります。

最後に要点を整理します。

スクラムは、作業を速くするための会議の仕組みではないんだね。

そう。短い期間で成果を作り、実際の結果から学んで改善するためのフレームワークだよ。

プロダクトオーナーが価値を考え、開発者が成果を作り、スクラムマスターがスクラムの実践を支えるんだね。

そして、全員が一つのスクラムチームとしてプロダクトゴールを目指すんだ。

スプリントの中で計画、開発、確認、改善を行い、それを繰り返すんだね。

そう。「短く作る、みんなで見る、すぐに直す」と覚えると、スクラムの全体像をつかみやすいよ。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。