認定スクラムマスター研修に行ってきました

昨年末にスクラムマスター研修を受けてきて、認定スクラムマスター (CSM)となりました。スクラムマスター研修で学んだこととして社内で共有した内容を本ブログでも共有してみようと思います。

Scrum vs Agile 〜歴史から学ぶ〜

• 1993年: スクラム誕生
• 2001年: アジャイルソフトウェア開発宣言
  • アジャイルマニフェスト: アジャイルソフトウェア開発宣言
  • アジャイル原則: アジャイル宣言の背後にある原則

アジャイルは「より良い開発/方法を探している」という状態のことです。状態なので原理的には「アジャイル開発をしている」という表現は正しくありません。振り返ってみて「あのプロジェクトはアジャイルだった」と評価できるもの。極端に言うといわゆるウォーターフォール型の開発も１つのアジャイルと定義することもできます。

Don’t do agile, be agile （訳: アジャイル開発をするな、アジャイルであれ）

スクラムのほうがアジャイルより歴史的には古く、アジャイルの定義が曖昧な一方、スクラムはきちんと確立された方法論で現在もアップデートされ続けているフレームワークです(年２回)。ただ出版社のマーケティング戦略的に「アジャイル」というバズワードを使わなきゃ本が売れないという理由もあってか、世の中には＜アジャイルという皮を被った何か＞が氾濫しています。「アジャイル」という魔法のコトバに惑わされてはいけないのです。

スクラムとは何か？

スクラムとは ＜現状を把握するためのフレームワーク＞。どのプロジェクトにおいても現状を把握した結果、大体において問題はあることから ＜問題を発見するフレームワーク＞ と言われることもあります。

なのでポイント（超重要！）は、スクラムをやったからといって、

• 生産性は向上しません
• 人が成長することはありません
• プロダクトが改善することはありません

あくまでもこれらは、現状を把握した結果として期待できるものであって、スクラムをやれば必ず得られる結果というわけではありません。スクラムもまた、銀の弾丸ではないのです。

逆にチームの現状を把握できていないのであれば、それはスクラムとは呼べません。そして「スクラムは優秀な人じゃなければできない」というのも間違いです。優秀じゃない人でも現状を把握してそこそこの成果を出せるようにするのがスクラムというフレームワークです。

スクラムのルール

全部で19個あります。

スクラムの三本柱

1. 透明性 – Transparency
2. 検証 – Inspect
3. 適合 (検証に基づいた適合) – Adapt

スクラムの３つの役割

1. プロダクトオーナー
   • チームのROIを最大化させる（ビジネスのROIではないということに注意）
2. スクラムマスター
   • 開発が Scrum と呼べる状態にする
   • スクラムじゃない方法を提案するのもまた、スクラムマスターの役割
3. チーム

7人±2人 が１つのスクラムチームを構成するのがのぞましいとされています。

スクラムの5つのセレモニー

1. Sprint Planning – スプリント計画
   • 短期計画
   • 何を実現しようとしているのかを明確に
   • どの順番（優先順位）で開発を進めるのか
2. Daily Scrum – デイリースクラム/朝会（朝じゃなくてもよい）
   • 15分間
   • 毎日の学習を共有
   • 議論は行わない
3. Product Backlog Refinement – プロダクトバックログ見直し
   • 中長期計画（現在のスプリントは含まれないことに注意）
   • スプリントの5-10%使って見直しを行う
4. Sprint Review – スプリントレビュー
   • 動くプロダクト・ドキュメントで成果を確認する
   • プロダクト触ってもっとプロダクトを良くする
5. Sprint Retrospective – スプリントレトロスペクティブ/振り返り
   • チームが生産性を高めるために取らなきゃいけないアクションを1つ以上決める

アーチファクト

アーティファクト、成果物とでも訳しましょうか。下記４つがそれにあたります。

1. スプリントバックログ
2. プロダクトバックログ
3. Impediment List - 障害リスト
4. Acceptance Criteria - 受け入れ条件

その他

• Sprint - スプリント
• Sprint Stop - スプリント停止
• DONE - 製品が完了する
• Potentially shippable product increment – 出荷可能な製品をリリースする

スクラムが適さないシーン

• プロダクトの生産期間が短い
  • 例) 2ヶ月で終わってしまうプロジェクト
  • スクラムはチームビルディングで最低３ヶ月かかる。そしてその３ヶ月を反復してチームを改善させていく。つまり３ヶ月以内のプロジェクトでスクラムを行うのは難しい（やれなくもないが）
• 要件・技術が単純なプロダクト
  • スクラムは要件・技術的要素が複雑な場合に適したアプローチ

自律的なチームとは

1. チームの明確なゴールがある
2. チームの明確なバウンダリー（境界線）がある

「自律的なチームかどうかの判断基準は何？」への回答は「個人がチームのゴールを達成するために何をすべきか0.1秒以内に判別し行動できる」といえます。

見積もり方法

1. 相対見積もり
   • 一番簡単なタスクのポイントが1だとしてそれに対する相対的な見積もり
   • プロダクトバックログアイテムはこちらの見積もり方法が適している
2. 絶対見積もり
   • xx時間とかの見積もり
   • スプリントバックログアイテムにはこちらの方法が適している
   • 1スプリントバックログアイテムが0.5時間〜1時間になるのが理想的な状態

ここで重要なポイントとしては スクラムマスターは絶対に計画せずにチームが進むことを許容してはいけません 。スクラムをやるなら 徹底的に計画してください。妥協は許されません ここがスクラムをやる上でのチームが持たなければならない＜覚悟＞となります。逆に言うとこの覚悟が持てないならスクラムをやるべきではありません。

DONE

DONEはDefinition of doneのことです。そしてDefinition of doneには doneとundoneの２つが含まれます。

どういうことでしょうか。例えば「ログイン機能を作る」というタスクを考えてみましょう。ログイン機能のDONEとして何をイメージするでしょうか？「フォームに正しい値を入力して正しくログインできること」「間違った値を入力してログインできないこと」「変な値でバリデーションエラーメッセージがでること」などが簡単に思い浮かぶと思います。

ではそれで本当にログイン機能はDONEと言えるのでしょうか。違います、DONEにはログイン機能の単体テストやその結合テスト、さらにはセキュリティテスト、負荷テスト、またはその機能のドキュメンテーションも全て含まれてのDONEです。そしてDONEにはそれで完了しているdoneとそれで完了しなかった、例えばこのケースで言うと「テストは後でかこう」「セキュリティ試験は全ての機能が完成してから実施」などのundoneも含まれています。

このundoneが後回しになって積み上がった状態がプロジェクトの炎上状態であり、スクラムとして不健全な状態といえます。健全なスクラムは１スプリント毎にこのundoneを着実に消化していきます。

プロダクトバックログの書き方

研修ではユーザーストーリーとAcceptance Criteriaの２つを書いて１つのプロダクトバックログアイテムとしました。

• ユーザーストーリー: {who}として {what}がほしい なぜなら{why}だから
• Acceptance Criteria: 受け入れ条件 ユーザーストーリーが達成できたといえる 誰が見てもわかる明確な条件

ベロシティ

これらのプロダクトバックログアイテムに対して先ほどの見積もりのポイントを付けていきます。そして 1スプリント中にチームが消化できるポイント数のことをベロシティ といいます。

このベロシティは安定させるべきです。もしベロシティが安定していないのならばそれはポイントの付け方が間違っているか、チームに何かしら問題がある可能性が高いです。

スクラムが成功している状態とは？

スクラムチームとして 3ヶ月で46%生産性が向上している状態 がスクラムが成功している状態です。じゃあ46%向上している状態とはどう測ったらよいかというと、スクラム講師曰く、先ほど言及したundoneが3ヶ月というスパンで1つでも消化できていれば46%生産性が上がったと言っていいとのことでした。

しかしこれは非常に難しいことで、どんなに成功しているスクラムチームでも1年に1回でもそれが達成できていればうまくできているほうだとのことでした。

スクラムマスター役割・スキル

• 状況分析: シチュエーショニング
• ティーチング
• ファシリテーティング
• メンタリング
• コーチング

そしてスクラムマスターはこれらの行為をやるだけで満足してはいけません。やった上で 結果が出ないと意味がありません。 つまりティーチングをやったからスクラムマスターの役割を果たしたとはいえず、ティーチングをやった結果、それを受けた者の行動が変わることも含めてスクラムマスターの役割ということです。

「謙虚さ」と同時に「屈強さ」がスクラムマスターには必要です。

受講してみての感想

今回のスクラムマスター研修では「スクラムとは何か」を原理的な立場から学びました。

受講してわかったことは世の開発現場には似非スクラムが溢れているなーってことでした。スプリント回しているからスクラムですとか、カンバンでタスク管理して朝会やってスクラムですとか、リソース足りないのでうちは開発チームメンバーとスクラムマスターをの２つのロールを兼任してますとか…。

スクラムの基本原則から言うと役割の兼任はNGですし、スクラムは具体的なタスク管理手法は規定していないのでカンバンでやろうとJIRAでやろうとGithub Issueでやろうとそれはスクラムの原理原則とは関係ありません。

朝会以外にもスクラムの大事なセレモニーはあって必ずそれらはスキップしてはいけないものとなってます。スプリントを回すにしても、ちゃんとそのスプリントは計画とあっていたのかとか、ちゃんと受け入れ条件をクリアする品質でスプリントの成果物が上がってるかとか、スプリント間に差し込みタスクがなかったかとかいろいろやらなきゃいけないことや考えることはあります。

そして感じたこととしては、スタートアップのアーリーフェーズだとなかなか原理的な意味でのスクラムは難しいのではということでした。スクラムやりたくともリソースが全然足りないのでスクラムマスター、プロダクトオーナーはそもそも置けないとか、スクラムのロールを兼任せざるを得ないとか。

またアーリーフェーズだと人の出入り（特に新しいメンバーを迎えるケース）も激しいと思うのでそうなるとスクラムチームは再度チームビルディングからやり直さなければなりません（このチームビルディングで1 Sprintは消費すると言われています）。

なのでこういった開発現場で出来ることとしてはスクラムのフレームワークの中で良いと思うもの、有効だと思うものを選択して組織に有効な＜スクラムエッセンスを取り入れた開発＞を実践することではないでしょうか。

一方で上記に書いたように「スクラムじゃない別の方法を提案するのもスクラムマスターの役割」と書きました。なのでスクラムにこだわる必要は全然なくて、スクラムがチームにマッチしないと思うならスクラムマスターは別の手法を提案できなきゃダメです。例えばそれがウォーターフォールでもいいしDDDでもいいしリーンスタートアップだっていいのです。

そういう意味でスクラムマスターは(おそらく皆が)思っている以上にその役割を全うすることが難しいものだと感じました。

参考になりそうな他の人の体験記

スクラムマスター研修に行かれた他の方の体験記を紹介します。

• makopi23のブログ 認定スクラムマスター研修（CSM）を振り返る
• 認定スクラムマスター研修のメモ書き - Qiita
• 認定スクラムマスター研修に行ってきました

こちらも参考にどうぞ

• 公式スクラムガイド Japanese を選択してもらえれば日本語バージョンが閲覧できます
• スクラム導入に向けて：スクラムは救世主となるのか？
• スクラムプロジェクト開始のベストプラクティス | Ryuzee.com