FUJITSUAdvent Calendar 2023

スクラム未経験者がスクラムについてまとめてみた

Last updated at 2023-12-24Posted at 2023-12-24

まえがき

FUJITSU Advent Calendar 2023の25日目の記事です。

2023年12月に、Scrum Alliance®のCertified ScrumMaster®（CSM®） 資格の研修を受けました。
本記事では、その復習もかねて、スクラムについてまとめてみます。

本記事の内容は、私が研修受講以前に読んだ以下の書籍、また、研修の講師を担当いただいたMichael James（MJ） 氏のホームページ中記事の内容を参考にしています。

なお、筆者は本記事の執筆時点（2023/12）で、本格的なスクラムによる開発を経験したことはありません。
筆者がこれまで所属してきた職場では、ウォーターフォール開発が長く、ウォーターフォールに一部のスクラム要素を取り入れたなんちゃってアジャイル、が実施されている程度です。

備考
スクラムマスターの資格は、代表的なものとして以下3種類の資格があります。
それぞれ内容は似ていますが、主催する団体が異なります。

Scrum Alliance® のCertified ScrumMaster®（CSM®）
- 今回私が受けたものはこれ
Scrum.org の Professional Scrum Master™ (PSM)
Scrum Inc. の Registered Scrum Master™ Training（RSM）
それぞれの具体的な違いについては、本記事の主題ではないので割愛します。
気になる方は、以下の記事などが参考になると思います。

スクラムの基本要素

スクラムは、アジャイル開発手法の１つです。
アジャイル開発の公式な定義は、アジャイルマニフェスト（アジャイルソフトウェア開発宣言）に記載されています。
スクラムのルールは、Scrum Guides で定義されており、定期的に更新されています。

2020年11月版におけるスクラムの定義は以下です。

スクラムガイド（日本語版）より引用

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。

プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。

スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。

スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。

繰り返す。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。

ルールセット

スクラムのルールセットは、3つのロール、3つの作成物、5つのスクラムイベントです。
これはスクラムで定義されている最小限のルールセットなので、スクラムをやる以上、これらには則る必要があります。

ロール

プロダクトオーナー（PO）

プロダクトに1人のみ存在する
- 大規模スクラム（LeSS）でも1人
プロダクトのWhatを担当する
プロダクトのビジョンを共有する
プロダクトバックログの管理者
- 項目の並び順を最終決定する
- 完成度合いを定期的に確認する
おおよそのリリース計画を作る
予算を管理する

開発チーム

適切な人数は、3人～8人
プロダクトのHowを担当する
メンバーは、肩書きや決まった役割を持たない
- 役割は、管理職などチーム外から与えられるのではなく、その時々の状況に応じて自分たちで決める
機能横断的である（開発に必要な全ての作業を行う）
- 要求分析、設計、コーディング、テスト、ドキュメント、リリース作業など

スクラムマスター

開発チームにつき1人
- 大規模スクラムなどで、開発チームが複数になる場合、スクラムマスターもチーム分の人数が必要
スクラムの仕組みがうまく回るようにする
チームがスクラムに慣れていない段階では
- 会議ファシリテーターやスクラムコーチとして振る舞う
チームがスクラムに慣れてきたら
- POや開発チームの作業を手助けする
- 外部からの作業妨害を阻止する
マネージャー・リーダーではない
- タスクアサインや進捗管理の役割はない

作成物

プロダクトバックログ

実現したいことをリストにする
- 1つ1つの項目は、ユーザーストーリーという形で書かれることが多い
  - ユーザーは誰で、どういう時に何のために使う機能か？
  - ユーザー目線で、その項目が必要な理由は何か？
プロダクトにつき1つだけ存在する
- 大規模スクラムでも1つだけ
誰でもいつでも参照・更新してよい
- ただし、リストの順番はPOが責任を持つ
上位の項目は詳細化された状態にする
- １スプリント内に完了できるサイズである
- デモ手順などが明確になっている

スプリントバックログ

スプリントごとに存在する
- 大規模スクラムでは、開発チームごとにも存在する
スプリントで実施するプロダクトバックログアイテムを選択し、具体的な作業に分割する
作業は、スプリント中に後から増えても良い

インクリメント

スプリントごとに完成させる成果物
動くソフトウェアとして完成させる
何をもって完成とするか、完成の定義を決めておく
- 例えば
  - コードレビューが終わっている
  - ユニットテストが終わっている
  - テストカバレッジ〇〇%以上
  - ドキュメントが作られている
  - 性能測定が終わっている
  - セキュリティ要件をクリアしている

スクラムイベント

スプリント

1週間～1か月の同じ期間に区切って繰り返す
他4つのイベントは、スプリント中に実施する
スプリントごとに動く成果物（インクリメント） を作成する
作業が残っていても、スプリントを延長してはいけない

スプリントプランニング

スクラムチーム（PO・開発チーム・スクラムマスター）全員が参加する
- 必要に応じて、ステークホルダーを招待してもよい
スプリントバックログを作成する
- 今回のスプリントで達成する項目の選択
- 項目の具体的な作業を洗い出し
使える時間の目安
- 1か月スプリントの場合：8時間

デイリースクラム

開発チームは参加必須
- PO・スクラムマスターは必要に応じて参加
作業を阻害する問題が発生していないか確認する
- 何か問題があれば、関係者を集めて別枠で話し合う
誰かへの進捗報告が目的の場ではない
毎日、15分で実施し、延長はしない

スプリントレビュー

スクラムチーム（PO・開発チーム・スクラムマスター）に加えて、ステークホルダーにも参加してもらう
インクリメントのデモを実施し、ステークホルダーからのフィードバックを引き出す
- 完成した部分について、デモを実施する
- プレゼンのみでレビューしてはいけない（動くものを見ないと本当の進捗が分からないため）
使える時間の目安
- 1か月スプリントの場合：4時間

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

スクラムチーム（PO・開発チーム・スクラムマスター）全員が参加する
よりうまく仕事を進めるため議論
- うまくいったこと・改善すべきことを挙げる
- ここで出た改善ポイントを、少なくとも１つ次のスプリントバックログに含める
作業課題の解決ではなく、チームのパフォーマンス向上のための改善
使える時間の目安
- 1か月スプリントの場合：3時間

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

このイベントは、スクラムイベントとしては定義されていませんが、スクラムガイド中で実施が推奨されています。

プロダクトバックログの上位項目は、スプリントプランニングで選択される時点で、詳細化が終わっている必要があります。
そのため、プロダクトバックログの上位項目を事前に整理します。
- 具体的には
  - 優先度を入れ替える
  - サイズが大きければ、分割する
  - 項目の中身を具体化する
プロダクトバックログリファインメントの実施タイミングは特に決められていません。
- 例えば
  - 毎日少しずつ実施する
  - スプリントの中～後半にまとめて時間を取って実施する
使える時間の目安は、スプリントの10%以内の時間です。
- 1か月スプリントの場合：2日以内

スクラムのルールセット外のプラクティス

スクラムのルールセットには含まれていませんが、有用とされるプラクティスもあります。

インセプションデッキ

インセプションデッキは、「アジャイルサムライ」という書籍で紹介され、日本国内では比較的有名です。

インセプションデッキは、ゴールやミッションを明確にするための10個の質問です。
- テンプレートが以下で公開されています
- https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
チームで1つのプロダクトを開発する以上、プロジェクトで実現・達成したいことについて、チームメンバー間で意識が合っている必要があります。
チームのキックオフなどのタイミングで意識合わせを行うために、インセプションデッキを利用できます。

有用とされる一方で、注意点もあるプラクティス

以下もスクラムのルールセットに含まれていませんが、関連するプラクティスとして有名です。ただし、注意すべき点もあります。
これらは、MJ氏の以下記事に記載されています。

ケン・シュエーバーが意図的にスクラムから除外した項目 | scrummaster.jp
その一部を本記事でも紹介させていただきます。

見積り手法

プロダクト開発には、たいてい、リリースの期限があると思います。いつまでにどこまで出来上がるか、契約先や上層部に説明しないといけないことがあります。
そのため、プロダクトバックログの各項目について、事前に見積りを行う事例は多いです。
有名なのは、ストーリーポイントを使った相対見積りです。
- 時間やお金の量で見積もる「絶対見積り」に対し、相対見積りは、特定の作業を基準とし、それと比較してどれくらい大変か、で数値を付けます。
  - 数値（ストーリーポイント）として、フィボナッチ数（1,2,3,5,8,13,21...）を使うことが有名です。
- プランニングポーカーという手法はよく一緒に使われます。
  - ポイントが書かれたカードをチームの全員が一度に出して、なぜそのポイントにしたかを議論します。
注意点
- 「いつまでにどこまで実施するか」を約束するのは、アンチアジャイル的です。そのため、それを目的に見積りを実施するのは避けるべきです。
  - 約束をしてしまうと、後で要件が変わったり増えたりしても、より良い計画に変更することが難しくなります。
- また、見積りは、どれだけ時間をかけても正確にはなりませんので、誤差を気にせず、サクッと見積もるべきです。
  - MJ氏の記事では、フィボナッチ数よりもさらにシンプルな2の冪（べき） で事足りると言及されています。
  - どちらを使うにしろ、見積りに時間を掛けすぎないことが大切だと考えます。
- プロダクトバックログリファインメントでは、プロダクトバックログの上位項目の詳細化が目的になるので、見積りを行う際は、よりシンプルに「特大、大、中、小」のような分類で見積るのも有効です。
  - この場合、上位項目が「中、小」サイズになるように、項目を分割していきます。

ベロシティ

ベロシティは、チームが１スプリントで完了できるポイント数です。
- 原則、実測値から求めます。
見積りとベロシティの情報があれば、リリースに向けた予測ができます。
- 必要なスプリント数 = 必要な項目の合計ポイント / ベロシティ
- 実現できるポイント数 = ベロシティ × 期間内に実施できるスプリント数
注意点
- ベロシティが「チームの生産性」を測る指標として使われることがあります。この場合、ベロシティ向上が組織や管理職の内部ノルマになる事例があるそうです。
  - 内部ノルマの達成が目的になると、本来のビジネスゴールの達成とはズレた行動が取られやすくなります。
    - 例えば、項目の見積りを少し多めに見積もっておくだけで、ベロシティを向上できてしまいます。
  - そういった風土や体制がある組織では、ベロシティの計測をやめた方が良いかもしれません。

（大まかに）各タイミングですべきこと

スクラムの基本要素が理解できても、実務で本格的なスクラムを経験していない私のような者にとっては、スクラムを実務に適用するのは簡単ではありません。
新たにプロジェクトが始まったタイミングで、スクラムをやっていく場合、まず何をしたら良いのかが分からないという壁に当たりそうです。
そのため、開発の各タイミングですべきことを、私の考え(※)も含めてまとめてみます。

※「SCRUM BOOT CAMP THE BOOK」の内容を参考にしています。

プロジェクトの開始タイミング

キックオフ

ロール決め
- PO・スクラムマスター・開発チームの各ロールを誰が担当するか決めます。
- まず、スクラムの知識がある人の中からスクラムマスターを選択し、PO・開発チームはスクラムマスターが中心になって決めるのが良さそうに感じます。
  - 特に、POについては、単に役職・立場やスキルで決めるのではなく、「製品をより良くしたい」というマインドを持った人を選びたいところです。
- スクラム知識の乏しい管理職が勝手にロールを決めるのは良くないと思います。もし、そのようなことになったら、スクラム知識のある人が声を上げるべきかと思います。
自己紹介
- チームとして一緒に仕事をしていく以上、やはり自己紹介は必要かと思います。
- スクラムチームのメンバーがお互いに、人となりや得意・不得意について理解しておくことは、今後の仕事をうまく進める上で重要になるかと思います。
インセプションデッキ
- スクラムチームで何を作るのか、最初に意識を合わせる必要があるので、インセプションデッキを作成します。
- インセプションデッキは、何を作るか（What）に責任を持つPOが作るべきですが、POがスクラムに慣れていない場合は、スクラムマスターがサポートして一緒に作成すると良いと考えます。
- その後、たたき台を元に、開発チームも一緒になって議論し、意識を合わせます。

プロダクトバックログの作成

プロダクトバックログは、POの持ち物ですが、最初にプロダクトバックログを作成する際は、スクラムチーム全員（PO・スクラムマスター・開発チーム）が集まって作るのが良いと思います。
何を作るのかイメージできる資料（インセプションデッキなど）を元に、それを作るために必要なことを挙げていきます。
- 重要な項目が漏れないよう、チームメンバー全員でできるだけ多くの項目を挙げます。
項目は、優先度・重要度の順に並べ替えますが、これも最初はチームメンバー全員で議論して考え、最後にPOが承認します。
- 順番を決める上で、個人的に注意したいと思う点は、ビジネス的な優先度と開発者目線の優先度を両方とも考慮する、ということです。
- 経営層やPOがリーンを学んでいる場合、顧客価値（製品のコンセプト）となる部分を最短で作って評価したいと考えるでしょう。
  - コンセプトの評価が遅れれば、作った製品が実は顧客に求めれていなかった場合の手戻りが大きくなります。
- 一方、開発者目線だと、製品のコンセプトとは関係が無くても、製品の基盤となる部分や絶対に必要と分かっている管理機能は、先に作っておきたいと思うかもしれません。
  - もし基盤となる部分を後から作った場合、開発の効率が落ちたり、基盤機能の質が落ちて製品全体の品質も低下する可能性があります。
- そのため、POと開発者がそれぞれの目線で意見を出し、相談して優先度を決めること大切だと思います。

開発中のタイミング

スプリントプランニング

スプリントの初日に、PO・開発チームが集まって実施します。
- チームがスクラムに慣れていないうちは、スクラムマスターが司会役となります。
話し合うことは以下です。
- プロダクトバックログの中から、今回のスプリントで実施する項目を決める。
- 実施する項目の詳細タスクを洗い出す。
- 各項目のデモ手順や完成の定義を決める。
- 項目の担当者決めは、必須ではありません。
以下について意識を合っているか確認します。
- スプリントのゴール
  - （ビジネス観点やユーザー目線で）項目を達成すると何が得られるか
- 達成可能な計画であること

スプリント中

デイリースクラム

開発チームのメンバーで実施します。
- PO・スクラムマスターは必要に応じて参加します。
- チームがスクラムに慣れていないうちは、スクラムマスターが司会役となります。
毎日、15分で実施し、以下について確認します。
- 昨日やったこと
- 今日やること
- ゴール達成の妨げになる障害や問題点
問題点を見つけることが一番の目的です。
- ちょっとしたことでも1人で抱え込まないよう、チーム内の心理的安全性を確保する必要があります。
何か問題があれば、関係者を集めて別枠で話し合います

イベント外の時間

開発チームのメンバーがやること
- タスクの実施
  - その時々で実施できる項目を選びます（事前に担当者を決める必要はありません。）
- スプリントバックログ（タスクボード）のタスク追加・削除
- スプリントバックログ（タスクボード）のタスクの状態更新
- プロダクトバックログに項目の追加
スクラムマスターがやること
- スクラムがうまく回っているか、悩みを抱えている人がいないか等、チームを観察
- チームの課題をメンバーに向けて可視化
- スクラムについてのコーチング
- 開発チーム・POの作業の手伝い
- チームの作業がうまく進まない要因があれば、解決方法を考える
  - 例えば
    - 外部から割り込み作業が入らないよう調整
    - 新しいツールや仕組みの導入
    - 足りない知識を補うための勉強会の開催
POがやること
- ステークホルダーの状況把握、ニーズ変化の把握
- プロダクトバックログの定期的な確認、順序の並べ替え

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

開発チームのメンバーで実施します。
- 可能であれば、POも参加します。
できれば毎日、少なくともスプリント期間に1回は実施します。
やること
- プロダクトバックログの項目の順序見直し
  - 順序の最終決定はPOが行います
- プロダクトバックログの上位項目について、見積りを最新化

スプリントレビュー

スクラムチーム（PO・開発チーム・スクラムマスター）に加えて、ステークホルダーにも参加してもらいます。
進め方
- POが、完成したこと、完成していないことを説明する
- 開発チームがデモをを実施し、ステークホルダーからのフィードバックを引き出す
  - 完成した部分だけデモする
フィードバックを元に、今スプリントでのインクリメントを評価する
- インクリメントの良い部分は残し、良くない部分は捨てる
- 新しい項目をプロダクトバックログに追加する

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

スクラムチーム（PO・開発チーム・スクラムマスター）全員が参加します。
- チームがスクラムに慣れていないうちは、スクラムマスターが司会役となります。
よりうまく仕事を進めるために話し合います。
- うまくいったこと・改善すべきことを挙げる
  - フレームワークとしては以下が有名です。
    - KPT（ Keep, Problem, Try ）
    - YWT（やった、わかった、つぎにやること）
- ここで出た改善ポイントを、少なくとも１つ次のスプリントバックログに含める
タスクの課題解決などについては話題にしません。

リリースのタイミング

リリース作業

製品をリリースするためには、リリース基準を満たす必要があります。
- リリース基準は、たいてい組織で決められたものがあると思います。
リリース基準を満たすためにやらないといけないことは色々あります。
- 受け入れテスト
- セキュリティ、パフォーマンス確認
- ドキュメント執筆
- 社内手続き
- など
リリース作業をやるタイミング
- スクラムでは、毎スプリントの終わりに、作ったものがすべてリリース可能な状態になっているのが理想形です。
  - なので、リリース作業も毎スプリントの作業で実施すべきです。
- 現実的には、スクラムにかなり慣れたチームでないと、これは難しいと思います。
  - リリース作業までやる時間が取れない、タイミング的な制約でリリース作業は実施できない、といったことがあります。
- 毎スプリントでリリース作業を実施できなかった場合は、本来のリリース期日に間に合うタイミングで、リリーススプリントを用意します。
リリーススプリントでは
- これまでのスプリントを通して、やり残してしまったリリース作業は何か、洗い出します。
- 洗い出した作業を実施します。
- リリーススプリントは、スクラムの定義に含まれるイベントではないので、通常のスクラムの進め方をする必要はないようです。スクラムイベントを実施する必要もなく、チームが進めやすいやり方で実施します。
重ねてになりますが、毎スプリントでリリース可能な状態にするのが理想です。少しずつでも理想に近づいていけるよう、スプリントレトロスペクティブを通して、チームの仕事の進め方を改善していくべきです。

おわりに

本記事では、スクラムについてまとめてみました。
冒頭にも記載した通り、筆者は実務で本格的なスクラムを実践したことはありません。
この度、Certified ScrumMasterの研修を受け、同資格も取得する予定ですので、次は、学びを活用できる機会の獲得に励みたいと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up