背景
2022年にマネーフォワードクラウド横断本部QA推進部に入りながら、スクラムマスターをしています 笑
改めて自分が何者なのかを問うという禅問答のような、我ながらよくわからん記事でも書きましたが、QAとしてアジャイル・スクラム・DevOpsを前提として、プロセス改善（プロセスという言葉はあまり使いたくないのだが）をするために、現地現物を見ようとなると、俯瞰する必要があるスクラムマスターをするのが良いという結論になりました。
目的
本音としてはLessとかデュアルトラックアジャイルとか、モダンな記事を書きたいのですが、基本とかカタとか原理原則が好きだし、基礎がないと応用はできないという考えから、基本に忠実に従い、実践したことを記事化します（いずれモダンな記事も書きたい！）。
スクラムに限らず手法の横展開や運用は難しいので、苦しんでいる方のお役に立てたら幸いです〜
超オーソドックスなスクラムのマネジメントをまとめた記事
定時で帰らせるためのスクラムマネジメント 〜スクラム定義〜
前提
- チームメンバーはほんと頼り甲斐のある人ばかりで素敵なメンバーに恵まれており、人的不安は皆無
- 初期メンバーはPO（マネーフォワードではPdMと定義している）・エンジニアリーダー・PG2名（内1名インターン）・デザイナー2名
- 自分が2022年9月に入った後に、10月からPG２名が追加、その後もPG追加予定
- 私はSM(スクラムマスター)兼QA兼タチコマにゴーストハックされた人（社内のSlackアイコンがタチコマ）
課題
- 元々スクラムマスターが不在のため、スクラムのフレームワークを導入しているが機能していない（誰も責められない）
- エンジニアがソースコードに向き合う時間が足りない（ミーティングが開発時間を圧迫）
- 上記に伴い、今後のリリース速度が懸念される
亀井のミッション
こんなに素敵なメンバーがいるのに結果が出せなかったら切なすぎるので、これはなんとしても結果を出してもらいたいなぁ
進め方
社内ブログにいろいろまとめてあるので、それをトピックごとに抜粋して展開します。
次の記事
目次（予定であり、変わるかも）
- チームに入ってまずはじめにしたこと
- デイリースクラムを改善（デイリースクラムとリファイメント）
- 最低限のドキュメント（要件・画面デザイン・BDD）
- ２０％リファクタタイム
- レトロスペクティブ
- スプリント前の動き方（PO・デザイナー）とユーザストーリーテーラリング
- プロダクトバックログ（棚卸し）
- チケット定義
- チケット運用
- 見積り
- スプリント計画
- スクラムボード（JIRA）
- 計測（ベロシティ・バーンダウンチャートなど）