Certified ScrumMaster®（CSM®）資格を取り、特に学びになったこと

# 初めに
私はAGILE BUSINESS INSTITUTEでスクラムマスター資格を取得するための研修を受講しました。元々、3年間ほどスクラムを実践していましたが、研修を通じて新たな知識や個人的に重要だと感じた内容について記述してみたいと思います。

# ワーキングアグリーメントの作成
## ワーキングアグリーメントとは？
チームの約束事を明確にした文書で、チーム全体の合意が必要です。

## 実施の意義
- チーム内でメンバーやプロダクトに対する価値観や判断基準を明確にできること。
- ルールを定めることで自発的に行動しやすくなり、メンバー間の衝突がスムーズに解決できること。

## 具体例
- デイリースクラムは進捗共有に限らず、困っている内容についても共有します。
- 雑談を頻繁に行い、心理的安全性を高めます。
- マージするためには、原則2名以上の承認が必要です。

# スクラムとウォーターフォールの選択
基本的にはスクラムが推奨されます。
- 変更される仕様が4%未満の場合はウォーターフォールを、4%以上の場合はスクラムを採用します。

ウォーターフォール開発はもともと製造業や建設業で生まれました。物理的な環境では、後からの変更が大変なためです。

昨今のソフトウェア開発において、スクラム開発で柔軟に対応することは重要になっています。複数の理由がありますが、私が感じたウォータフォール開発のデメリットは以下の通りです。

- 前の段階に戻って変更を加えることができない。
- プロダクト全体は最後にのみテストされる。

# チームのスピードの秘訣
1. フルスタックで、他のチームを待たないこと。
2. チームサイズを小さくし、理想的には6人以下にすること。
   2. 2枚のピザで足りなかった会議はない
3. モノタスクで、全員が一つのプロジェクトに取り組むこと。


## スクラムイベントについて

研修を通して再認識したことや学びを記載します。

### リファイメント

- **目的**:
   - プロダクトバックログアイテムの要件を明確にすることが目的です。
- **ステップ**:
   - 要件の明確化
   - PBI(プロダクトバックログアイテム)の優先順位付け
   - 見積もり
- **担当者**:
    - プロダクトバックログリファインメントは、プロダクトオーナーと開発者が協力して行う取り組みであり、必要に応じてスクラムマスターが支援します。
    - 参考：[プロダクトバックログリファインメントはいつ何をするのか](https://www.ryuzee.com/contents/blog/14584#:~:text=%E3%83%97%E3%83%AD%E3%83%80%E3%83%88%E3%83%90%E3%83%83%E3%82%AF%E3%83%AD%E3%82%B0%E3%83%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%B3%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AF%E8%AA%B0%E3%81%8C%E3%82%84%E3%82%8B%E3%81%AE%E3%81%8B)

### スプリントプランニング

- **ステップ**:
   - PBIを選択し、タスクに分解する
- **PO**:
   - 優先順位を明確化する
   - ビジョンと方向性を提供する
   - 開発者からの質問に答える
- **SM（スクラムマスター）**:
   - 円滑に進む様に進行する
   - 全員が合意できる様に働きかける
- **開発者**:
   - 計画を立てる
   - PBIを分解する

### デイリー

- **PO**:
   - 参加必須ではない
   - チームの進捗を把握する
- **SM**:
   - タイムボックス（通常15分）内で完了させる
   - 障害があれば問題を解決するためのサポートやリソースを提供する
- **開発者**:
   - 進捗、計画、障害を共有する

### スプリントレビュー

- **目的**:
   - ステークホルダーにデモし、成功を **祝う**
   - 参考： [スペースXでのスプリントレビュー](https://www.youtube.com/watch?v=eLSGZQ6k2PA)
     - （めっちゃ祝ってる！）

### レトロスペクティブ

- **目的**:
   - チームのパフォーマンスを最適化する
   - 悪かった点だけでなく、 **良かった点も共有する**

# 見積もりに関して

驚くことに「No Estimate」と見積もりはしないことを推奨されていました。見積もり通りに作業を完了しようとすることは、不健康な圧力を与えたり、生産性の低下、進捗の低下につながる可能性があります。

それでも、現実的に見積もらないのは難しいでしょう。となるので、下に続きます。。

# 現在の見積もりは本当に有用？

100%正確な見積もりを行うことはできません。
アジャイルの見積もりは不確実性を認め、正しい見積もりを提供することを目指します。
バックログのすべての細かいアイテムを全て見積もる必要はありません。実際、チームが作業に取り掛かるまでに、要件が変更される可能性があります。したがって、以前の見積もりは不確かなものになり、作業の見積もりは不要なものになります。

![スクリーンショット 2024-01-28 15.02.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/637828/c73b5688-21a8-26a6-2458-da5385784d7c.png)

引用：[日経Xtech](https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/)

# プロジェクトに関しても相対見積もりを実施する

各タスクをフィボナッチ数列で見積もることはよく知られていますが、プロジェクトに関しても相対見積もりを実施した方が良いです。時間で見積もるよりも340%以上正確になります。

# 小さなPJが成功する傾向にある

三ヶ月以上かかる大規模PJで、オンタイムかつ予算に収まるのは3%です。一ヶ月未満の小規模PJが最も成功している傾向にあるため、PJは一ヶ月ほどの粒度にするのが良いです。

# モブ

フロー効率の考え方に添い、モブ作業が推奨されます。モブとは、チーム全員が同じことを同時に、同じスペースで、同じ環境で作業することです。

期待できる効果は以下の通りです。

1. チームが持つ問題を軽減できる
2. チームで知見を共有しクロクファンクショナルなチームの育成
3. スピードの向上
4. 迅速なフィードバックの形成

研修ではこれにAIをプラスし、モブAIという名称で紹介されていました。（自分＋チームメンバー＋AI）

テスラでもモブが実施されている様です。
参考:[「イーロン・マスクに社員が直接質問」「プロジェクトは自分で選ぶ」テスラが開発チームにあえてリーダーを置かない理由](https://logmi.jp/tech/articles/327164)

# 心理的安全性

心理的安全性が高いチームの方が生産効率が高いことが研究結果から明らかになっています。低い心理的安全性は、恐怖反応を引き出し、メンバーが萎縮して質問ができなくなったり、失敗を恐れたりすることで、生産効率が落ちてしまいます。

やはり、心理的安全性が保たれているチームが一番大切ですね。

# 最後に

資格料金としては高額な方だと思いますが、色々な知識を得ることができてとても良かったです。また、研修自体も、先生が明るく進めていただけるので心理的安全性が保たれている楽しい研修でした。

迷われている方は受講していることをお勧めします！

参考：[AGILE BUSINESS INSTITUTE](https://abi-agile.com/%E8%AA%8D%E5%AE%9A%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC/)