スクラム開発完全ガイド:初心者でもわかる導入から運用まで

スクラム基礎

はじめに

スクラムって多くの情報がありますが、難しい用語が出てくる上に、難しい用語で難しい用語を説明していて意味が分かりづらいですよね。そんなときに「さらっと全体像を理解できたらいいのに」という悩みを解決したいと思い、現役アジャイルコーチのkawagoiがスクラム開発を優しく解説しました。

スクラムは、プロジェクト管理手法の一つで、特にソフトウェア開発で用いられる「アジャイル開発」の1つです。アジャイル開発では、変化に柔軟に対応し、迅速に価値を提供することを目指します。この記事では、全くの初心者でもスクラムを理解できるように、その基本概念から、実際の失敗事例と解決策まで、初めてスクラムを学ぶ人でもわかりやすいように、紹介していきます。

アジャイルとは何か?従来のウォーターフォール型との違い

アジャイル開発は、変化に迅速に対応しながら価値を提供することを重視した開発手法です。アジャイルの詳しいマインドは、アジャイルソフトウェア開発宣言をごらんください。これに対し、従来のウォーターフォール型(WF型)は、要件定義、設計、実装、テスト、リリースといったフェーズを順番に進める、固定的で計画駆動型の手法です。よくWF型と比較してアジャイル開発では計画しない、ドキュメントを作らなくて良いなどと考えられがちですが、そんなことはありません。顧客への価値提供を最優先に考え、計画を柔軟に変更したり、動くソフトウェアを優先的に作ろうと考えるのです。それぞれの開発手法をQCDS(品質、コスト、デリバリー:納期、スコープ)の観点で比較すると、次のような違いがあります。

具体的な事例

例えば、Eコマースサイトの開発プロジェクトでは、ウォーターフォール型だと全機能が揃うまでリリースができません。アジャイル開発では、常に動く機能をリリースしながら、早期にユーザーからのフィードバックを得ながら機能を追加していきます。例えば、商品検索機能だけリリースし、商品購入機能をリリースし、最後に商品詳細機能をリリースし、商品編集機能をリリースする、のような形です。

間に合わない場合の対策

プロジェクト管理をする方は、計画通りに進まない場合に何かしら手を打って対策をします。 ウォーターフォール型とアジャイルでは、このままでは「間に合わない」と気づいたときの対策で差が生まれます。ウォーターフォール型では、D(デリバリー)納期を遅らせることや、C(コスト)人員を増加することで対策しますが、アジャイルではS(スコープ)、すなわち実装する機能数を減らすことで納期までにリリースすることを目指します。

スクラムの基本フレームワーク

スクラムは「経験主義」に基づいており、実際の経験から学び、改善していくことを重視します。この経験主義を支えるのが「透明性」「検査」「適応」という三本柱の考え方です。スクラムを学ぶときはスクラムイベントとロールばかりに注目され、見落とされることが多いのが経験主義と三本柱の考え方です。この考え方ができないと、良いプロセス改善ができなくなってしまうので、気をつけてください。

  1. 透明性: チームが取り組む作業や進行状況は、全員が見える状態であることが重要です。
  2. 検査: 作業の進捗や成果を定期的に確認し、問題や改善点を早期に発見します。
  3. 適応: 検査の結果に基づき、プロセスや計画を柔軟に調整します。

透明性、検査、適応によるメリットの事例

例えば、あるソフトウェア開発チームが「ユーザー登録機能」を開発しているとします。

  • 透明性: タスクボードを使用して、進捗状況が全員に見えるようにされています。
  • 検査: デイリースクラムで、計画が順調に進んでいるか、今回のスプリントがうまくいっているか確認したところ、予定よりも進捗が遅れていることが発覚しました。
  • 適応: どうやったら進捗の遅れをカバーできるのか。もっと簡単に価値を提供することはできないかなどを話し合い、新しい作戦を立てて解決を目指します。

スクラムの主要な要素:スプリントと3つの作成物

スプリント

スプリントは、スクラムの基本的な時間枠で、通常1〜4週間の間で設定されます。スプリントは、スプリントゴールに向けて集中的に取り組む期間であり、終了時には完成したプロダクトの一部(インクリメント)が提供されます。とはいえ、実際のところは、1〜2週間を選択しているチームが多いです。チームが動くものを提供できる最低限の長さにすると、改善サイクルを回しやすいのでオススメです。

スクラムの3つの作成物

  1. プロダクトバックログ: プロダクトオーナーが管理する「やるべきこと」のリストで、優先順位が付けられています。
  2. スプリントバックログ: プロダクトバックログから選ばれた項目で、スプリントで取り組むタスクのリストです。
  3. インクリメント: スプリントを通じて完成したプロダクトの一部で、顧客やステークホルダーに価値を提供するものです。

スクラムイベント

スクラムガイド2020年版には、以下の4つの正式なスクラムイベントが記載されています。

  1. スプリントプランニング: スプリントの開始時に行い、次のスプリントで完了する作業を決定します。
  2. デイリースクラム: 毎日15分以内で進捗を確認し、スプリントゴールに向けた作業計画を調整します。
  3. スプリントレビュー: スプリントの終了時にインクリメント(成果物)を公開し、フィードバックを得ます。
  4. スプリントレトロスペクティブ: スプリント終了後にプロセスを振り返り、改善策を話し合います。

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

プロダクトバックログリファインメントは、直訳するとプロダクトバックログ(やることリスト)の精細化です。プロダクトバックログを作っただけでは認識が合ってなかったり、実現方法にイメージの差があったりするので、よりよい成果物を求めて話し合いをします。正式なイベントではありませんが、スクラムチームが継続的に行う活動です。

スクラムの役割と責任

スクラムでは、3つの主要な役割があります。

  1. プロダクトオーナー: プロダクトの方向性を示し、プロダクトバックログを管理します。
  2. スクラムマスター: スクラムの実行を支援し、プロセスの改善を促します。
  3. 開発者: プロダクトのインクリメントを作成し、自己管理型の専門家集団として作業を進めます。

スクラムのよくある課題とその解決策

事例1

課題:形だけのスクラム化

私が相談を受けたり、支援しにいく現場で最も多いのは、形だけのスクラム化です。こういったチームでは、スクラムのイベントや役割を表面的に導入しているものの、チームが本質的なアジャイルで目指している考え方に基づいた行動を取らない傾向にあります。スクラムの醍醐味である継続的な改善や、素早い価値の提供が軽視され、単に手順だけを踏んでいる状態です。

解決策: 本質的なアジャイル思考の導入

  1. アジャイルの考え方を再確認する: アジャイルの目的である「早く顧客に価値を提供する」ことができているか確認し、チーム全体で目指します。
  2. イベントの目的を意識的に確認する: スクラムマスターがイベントの目的を理解し、目的に沿ったイベントになっているか、なっていなかったら正しいあり方に導きます。

事例2

課題:一部だけスクラム採用

次に相談が多い現場は、一部だけスクラムを採用しているチームです。このチームは、既存の仕事の仕方をできるだけ崩さずに、一部のスクラムイベントだけをやっていたりします。定期的に動いているものをデモすることは難しいので、スプリントレビューはやらないであったり、スクラムマスターの工数はもったいないので開発者がスクラムイベントのファシリテーションだけやる、のような状況です。

スクラムを理解した人が近くにいて、意図的に少しずつスクラムに変えていく目的であれば、一部だけスクラムをしているのは悪いことではなく素晴らしいことです。しかし、これは少し難しい方法で、詳しい人が支援してくれる状況以外は推奨しません。

解決策: 一度、スクラムに合わせた仕事に仕方に変える

  1. 投資と思ってプロセスを変える: スクラムの良さは、一度スクラムを体験しないと理解するの難しいです。最初は生産効率がもちろん落ちますが、投資と思ってプロセスを完全に変えるのがオススメです。
  2. 少しずつスクラムに変えることの支援者を見つける: どうしても一気に変えるのが嫌だということであれば、支援者を見つけるのも1つの方法です。しかし、一気にスクラムに変える方が支援を受ける期間が短くなります。そのため、外部のコーチを雇うのであれば、この方法は割高になってしまいます。

スクラム開発ガイド:重要ポイントまとめ

基本的な考え方

  • スクラムはアジャイル開発の一手法
  • 変化に柔軟に対応しながら、迅速に価値を提供することが目的
  • 「経験主義」に基づき、以下の3つの柱を重視
    1. 透明性:進捗や製品などを把握できるように
    2. 検査:定期的な確認と問題点の発見
    3. 適応:検査結果に基づく柔軟な調整

アジャイルとウォーターフォールの主な違い

  • アジャイル
    • 機能単位での段階的なリリース
    • スコープ(機能)調整による納期遵守
    • 顧客フィードバックを随時反映
    • 計画の柔軟な変更が可能
  • ウォーターフォール
    • 全機能完成後の一括リリース
    • 納期延長や人員増加による対応
    • フィードバック反映が遅い
    • 計画変更が困難

スクラムの主要構成要素

1. 3つの役割

  • プロダクトオーナー:方向性決定、バックログ管理
  • スクラムマスター:プロセス支援と改善促進
  • 開発者:実際の製品開発を担当

2. 3つの作成物

  • プロダクトバックログ:優先順位付けされた全体タスクリスト
  • スプリントバックログ:現スプリントで取り組むタスク
  • インクリメント:完成した製品の一部

3. 4つの主要イベント

  • スプリントプランニング:作業計画の決定
  • デイリースクラム:日次の15分進捗確認
  • スプリントレビュー:成果物の確認とフィードバック
  • スプリントレトロスペクティブ:プロセス改善の振り返り

よくある課題と解決策

形式的なスクラム導入の場合

  • 問題点
    • イベントや役割を表面的にこなすのみ
    • 継続的改善や価値提供の軽視
  • 解決策
    • アジャイルの本質的な目的の再確認
    • 各イベントの目的に立ち返った運営

部分的なスクラム採用の場合

  • 問題点
    • 既存の仕事方法との混在
    • 一部のイベントのみ実施
  • 解決策
    • 完全なスクラムへの移行を投資として捉える
    • 専門家による支援の活用

成功のためのキーポイント

  1. スクラムの形式だけでなく、本質的な考え方の理解
  2. チーム全体での目的共有と協力
  3. 継続的な改善への取り組み
  4. 透明性を確保した情報共有
  5. 顧客価値を中心とした判断基準の維持
この記事を書いた人
kawagoi

SM、アジャイルコーチ歴8年
Yahoo6年間→永和SM2年→フリーSM2年
20社コンサル・講演20回以上・著書7冊
教育心理学・スクラムマスター・1on1・リーダーシップ

kawagoiをフォローする
スクラム基礎
kawagoiをフォローする

コメント

タイトルとURLをコピーしました