はじめに
こんにちは！IDチームのkaitoです！
オンサイトで認定スクラムマスター（CSM）研修を2日間かけて受講しました。1日目はスクラムの全体像から、3つの責任（プロダクトオーナー・スクラムマスター・開発者）・イベント・作成物の位置付け、アジャイルの根っこにある価値観までを学び、2日目はそれを踏まえてチームの動き方やレビュー・見積もり・意思決定といった“実践での振る舞い”へと理解を深めていきました。実際にチームを組んでワークも実施して、より実践での学びを深めてまいりました！
ここでは学んだ内容を整理しつつ、自分なりに感じたことも書き残しておきます。スクラムについてこれから学習する方や既に学習している方に向けて少しでも参考になれば幸いです。
1日目：スクラムの全体像と価値観
スクラムの定義と3つの柱
スクラムとは、複雑な問題に対し適応的な解決策を通じて価値を生み出す軽量なフレームワークです。スクラムは、スクラムチーム・イベント・作成物と、それらの関係性・相互作用で構成されています。根底にあるのは「知識は経験から生まれる」という経験主義の考え方です。詳しい公式定義はScrum Guide 2020を参照してください。
アウトカム（成果）を実現するために、ユーザー体験を早く得て、そこからフィードバックを得て学習しながら進めていきます。あらかじめ決めた工程を反復的にデリバリーするのとは違い、最初にゴールを決めたうえで、ユーザー体験を得ながら進め方を柔軟に変えていくのがポイントです。品質そのものは、あとで触れる完成の定義を満たし続けることで作り込みます。
これを支えるのが3本柱です。
- 透明性 — 透明性があるからこそ、検査ができる
- 検査 — 検査ができるからこそ、適応ができる
- 適応 — 検査の結果を受けて調整する
スクラムの価値基準
プロダクトバックログとプロダクトオーナー
- プロダクトバックログは上のものほど詳細で具体的で、上から順に進めていく。なおこの言い方は 2013 年版のスクラムガイドに近く、現行のスクラムガイド 2020 ではプロダクトバックログを「創発的で順番に並べられた一覧」とし、リファインメントによって上位のアイテムが明確になっていくと説明しています。
- 「なぜ作るのか」を考えることが大事。プロダクトオーナーの“妄想（ビジョン）”は素晴らしいが、早め早めに作ってフィードバックを得て、より良いものにしていくのがスクラムの考え方。
- プロダクトオーナーは、プロダクトバックログアイテムの並び順を決め、プロダクトの価値を最大化することに責任を持つ（研修では「作成の順番」と表現されていました）。プロダクトバックログはプロダクトオーナーの妄想であり、間違うか間違わないかよりも早く決断することが大事。
- ただし、プロダクトオーナーには実際にタスクをアサインしたり、やり方を指定する責任も権限もない。
では、タスク管理やアサインは誰がやるのか？
→ 開発者自身がやり方を考える。それがモチベーションの向上につながる。
開発者の役割
- プロダクトオーナーの妄想を叶えるのが開発者。
- 開発者は自己管理型で、誰が何をいつどのように行うかをチームの中で決める。
- 開発者の中にリーダーがいるわけではなく、ヒエラルキーのないフラットな関係性。
- 完成の定義を満たすインクリメントを作る。完成の定義があることで「今どこまで終わっていて、何ができて何ができないか」の現状を明確にできる。
- これが透明性を生み出し、毎スプリント繰り返すことで品質を作り込む。
完成の定義と受け入れ基準
完成の定義はプロダクト全体に横断する品質基準、受け入れ基準は個別のプロダクトバックログアイテムに対する条件です。対象と目的を整理すると次のようになります。
| 比較項目 | 完成の定義 | 受け入れ基準 |
|---|---|---|
| 対象 | プロダクト全体（すべてのインクリメントに横断して適用） | 特定のプロダクトバックログアイテム 1 つ |
| 目的 | 何が完成しているのかを全員が同じ理解で判断できるようにする | そのアイテムが満たすべき条件を明確にする |
- 完成の定義は、横に常にある品質基準のようなもの。
- 受け入れ基準は、その特定のプロダクトバックログアイテムに対する要件。
- 例）「ユーザーはメールでパスワードをリセットできる」など。
リファインメント
- プロダクトバックログは下の方ほど内容が曖昧になっている。だから定期的にリファインメントが必要。
- 下の方の項目を分割したり、説明・順番・サイズといった詳細を加えたりして、より小さく正確にしていく。新しい項目が追加されたり、なくなったりすることもある。
- 理解と自信が高まると、明確なゴールが見えやすくなる。
- いつ実施する？ → いつでも行える。「以前は全体の10%ほど」という目安は2013年7月版のスクラムガイドに書かれていたもので、現行のスクラムガイド 2020では時間の目安は示されず、継続的な活動として説明されています。
スプリントとイベント
- スクラムでは、アウトプット・アウトカムを生み出すひとまとまりの期間をスプリントという。スクラムガイド 2020 の決まりは「1 か月以内の決まった長さ」で、研修ではソフトウェアならだいたい 1 週間ほどという実務上の目安が紹介されました。固定の時間を繰り返すことが重要。
- 適切な長さは開発者の自信によって決める、というのが研修での説明でした（スクラムガイドに長さの決め方の規定はありません）。現実的なものにすること。とりあえずでステークホルダーに期間を約束するのはNG。
- スプリントプランニングでは、スクラムチーム全体で協働してスプリントの計画を立てる（スプリントバックログの作成は開発者の責任）。スクラムマスターが「できる」と思っていても開発者が「できない」と言うなら、開発者の判断を尊重する。なおスクラムガイド 2020 では、スプリントに含めるアイテムは開発者がプロダクトオーナーとの話し合いを通じて選ぶとされており、スクラムマスターが仲介役として固定されるわけではありません。
- デイリースクラムでは、このままいけばスプリントゴールを達成できるかという検査を毎回行う。開発者のための 15 分のイベントなので、研修では「スクラムマスターが司会に立たず、技術的な質疑応答は別の場に送る」という運用が紹介されました。スクラムガイド 2020 上は、進め方や構造は開発者自身が選べるもので、技術的な議論を禁じるルールがあるわけではありません。
- スプリントゴールが無意味になったときはスプリントを中止できるが、その権限を持つのはプロダクトオーナーだけ。
- スプリントレトロスペクティブをもってスプリントは終了する。良いものを積み上げていく場であり、意見は常に言ってよい。
2日目：チームの動き方と実践での振る舞い
2日目はチームでワークをやりつつ、講師の方たちが「現状のスクラム概念」を踏まえながら、チームがどう動き・意思決定していくのかという、より実践的な話が中心でした。
Swarming — よってたかって課題解決
- ペアプログラミング = 二人
- モブプログラミング = 三人以上
こうした協働の形も、Swarming の考え方の延長線上にあるのだと理解しました。
職位とロールの関係（1日目からの深掘り）
- チームの中に課長クラスの人がいると、どんな状態でもヒエラルキーが出てしまうことがある。
- その人がスクラムマスターになると、普段の立場に引っ張られて言いなりになってしまう。
- 実際に、そこでスクラムマスターから外れてもらい、プロダクトオーナーに変わったら引っ張り方が変わって成功したという講師の方の経験談も共有されました。
1日目の「職位でロールを決めるのは良くない」という話が、具体的なエピソードとして腹落ちした部分でした。
提供の“順番”で考える
- まずはゴール対象の状況・状態・人間性を考える。
- プロダクトバックログは、単なる重要度順ではなく、価値最大化に向けて価値・リスク・依存関係・学習効果などを踏まえて並べ替える創発的なリスト。
- いきなり重要度の高いものを持っていっても、相手は聞いてくれない。
- → 聞いてくれるために、まず何をするかを考える。
なぜ「役割」ではなく「3つの責任」なのか
- 「役割」と言われると、どうしても分担してしまう。
- 分担すると、インクリメントとして統合するときに噛み合わず、属人化を招きやすい——だからこそ、分担できる「役割」ではなく「責任」で捉えよう、というのが研修での説明でした。これは研修での解釈であり、スクラムガイド 2020 が作業の分担そのものを禁止しているわけではありません。
- スクラムガイド 2020 は二層の構造になっていて、スクラムチーム全体がスプリントごとに価値のあるインクリメントを作成する責任を持ち、その上でチーム内にプロダクトオーナー・スクラムマスター・開発者という 3 つの明確な責任を定義しています（サブチームや階層は設けないとされています）。
レビューとステークホルダー
- スプリントレビューは成果を検査し、ステークホルダーと次に何をするかを協働で考える場です。良い点も改善点も具体的に扱います。
- 「まぁいいんじゃない？」というような曖昧なレビューはダメ。
- ステークホルダーと一緒にわちゃわちゃしていくのがスクラム。
- → これは、クラウドネイティブがお客様と“伴走”するスタイルと一致していると感じました。
- スプリントレビューで得たフィードバックや合意は、必要に応じてプロダクトバックログや今後の計画に反映されます。これは検査の結果を受けた「適応」にあたり、反映後のバックログが見える状態になっていることが「透明性」を支えます。
- レビューでは差分だけを見せるのではなく、既存のインクリメントと統合された状態やプロダクトゴールへの進捗を確認する（スクラムガイド 2020 は、スプリントの成果を提示し進捗を検査するとしており、毎回プロダクト全体を見せることを一律の要件にはしていません）。
- 1スプリントで複数のインクリメントが作られることもある。なおインクリメントはプロダクトゴールに向けた具体的な足がかりであり、過去のインクリメントに追加され、利用可能で、完成の定義を満たしている必要があります。
対立と意思決定 — 決めないことが一番の悪
- ただし、1スプリントでは取り戻せないような内容であれば、できるだけ決定を遅らせる。
- 専門性のある人の助けを呼ぶ。
- あるいは、その後に他の選択肢が取れるような選択肢を選んでおく。
チームの分け方
- 最初からフロントエンドとサーバーサイドに分ける必要はない。いきなり大きなものに分ける必要もない（Webアプリケーションの場合）。
- 「1ヶ月や1週間で成果を出さないといけないときは大きく分け、年単位のような場合は等しく色々やるチームのほうが上手くいく」というのは、講師の経験則として紹介されたものです。スクラムガイド 2020 の原則としては、必要なスキルをすべて備えた機能横断型のチームが基本とされています。
- → 人は、少し不得意なことをやっていくほうが能力が上がっていく、という補足もありました。
まとめ・2日間を受けての感想
1日目でスクラムの全体像と価値観（透明性・検査・適応の経験主義）を学び、2日目ではそれがチームの実際の動き方や意思決定にどう表れるのかを、具体的なエピソードとともに理解できました。
特に印象に残ったのは、次の3点です。
- 担当は職位ではなく、意欲で決める — 立場に引っ張られないことの大切さ
- 「役割」ではなく「責任」 — 分担が属人化を生みやすいという研修での視点
- とりあえず決めて、失敗から学ぶ — 「何も決めないことが一番の悪」という意思決定の考え方
2日間を通して、スクラムは「決められた手順をこなす手法」ではなく、経験から学び、チームの自律性を軸に品質とアウトカムを作り込んでいく考え方なのだと腹落ちしました。今後の業務でも、ここで得た視点を意識して行動していきたいと思います。
なお、同じ認定スクラムマスター（CSM）研修を昨年オンライン（3日間）で受講したメンバーの記事「認定スクラムマスターになりました！」もあります（今年はオンサイト開催だったため、同じ内容を２日間で受講しています）。研修の形式や認定試験の様子はそちらが詳しいので、よければあわせてご覧ください。
FAQ
Q. スクラムマスター研修は誰が受けるとよいですか？
A. スクラムマスターを担う方はもちろん、プロダクトオーナーや開発者にも役立ちます。職位で担当を決めない、「役割」ではなく「責任」で捉える、といった考え方はチーム運営全般に効くので、開発以外の職種でも学べることは多いです。
Q. プロダクトオーナー（PO）とスクラムマスター（SM）の違いは？
A. プロダクトオーナーはプロダクトの価値を最大化することと、プロダクトバックログの管理に責任を持ちます。スクラムマスターはスクラムを確立させることと、スクラムチームの有効性に責任を持ちます。なお、どちらも開発者にタスクを割り当てたり、やり方を指定したりはしません。
Q. デイリースクラムでは何を話しますか？
A. このままいけばスプリントゴールを達成できるかを毎回検査します。進め方や構造は開発者自身が選べるので、研修では「スクラムマスターが司会に立たず、15分に収まらない技術的な議論は別の場に送る」という運用が紹介されました。
Q. 完成の定義と受け入れ基準はどう違いますか？
A. 完成の定義はプロダクト全体に横断する品質基準です。受け入れ基準は特定のプロダクトバックログアイテムに対する個別の要件を指します。
Q. リファインメントはいつ行いますか？
A. いつでも行えます。曖昧なアイテムを分割し、説明・順番・サイズなどの詳細を加えて、より小さく正確にしていく継続的な活動です。
