スクラム未経験がスクラムマスターやってみた
こんにちは！ドクターメイト株式会社でプロダクト開発グループの ホリ です。 僕は2023年10月入社で、主に介護施設向けサービス全般の開発を担当しています。
ドクターメイトではスクラム開発を採用しており、スプリント期間は2週間です。
エンジニア歴10年目を迎える自分ですが、実はスクラム開発は未経験で、聞きなれない単語が多かった事を覚えています。
そんな中、入社1ヶ月を過ぎてドクターメイトに馴染み始めた11月頃「話の整理が上手いので向いていそう」という理由でスクラムマスターを押しつけ任されました！
今回は、そんなスクラム未経験のホリが、スクラムマスターになってやった事、上手くいった事、モヤモヤした事を振り返ってみたいと思います。
※ スクラム開発についての説明は省かせていただきます🙏
やったこと
1. スクラム開発の知識をつける
とにもかくにも、最低限の知識をつけようと思い、本を買いました。
買った本はこちら。初心者にはとても読みやすかったです。
2. みんなお待たせ。スクラムマスター動きます
本を読み準備万端と思いきや、僕は逆に混乱しました。
スクラムマスターの仕事って分かりにくくないですか？
ホリが見聞きした言葉
- スクラムマスターが仕事をしない状態が良い状態
- スクラムマスターは保育園の保母さんみたいな感じ
- スクラムマスターの仕事 ≠ スクラムイベントの司会進行
んで何するんだっけ・・・？」
スクラムマスターがやるべき仕事は、僕は以下だと思っていますが、これに気づくのに幾らか時間がかかりました。
ホリが思うスクラムマスターの仕事
- スクラム開発で上手くいっていないことや障害を見つけること
- 見つけた障害を解決すること
3. 様子を見る
スクラムマスターとして仕事しようと能動的に動くより、ひとまず純粋にスクラムイベントに参加して、上手くいってない部分や違和感を感じるまで、流れに身を任せることにしました。
当然？ですが、障害はたくさん見つかります笑
見つけた障害（一部）
- プランニング当日に明らかになるデザインや仕様
- デザイナーがスクラム開発に上手くハマっていない
- 非エンジニアが置いてけぼりになりがちなレトロスペクティブ
4. スクラム改善ボードの作成
せっかく見つけた障害や感じた違和感ですが、どこかに書いておかないと忘れてしまいます。だって人間だもの。
ドクターメイトでは社内wikiに Notion を利用しています。Notionにカンバン形式でページを作り、そこに溜めることとしました。
そうすれば、タスクにメモをとったり、スクラムマスターが変わったとしても受け継ぐことができると考えたからです。
5. 四半期の目標に、全スプリントゴールの達成を明記
スクラムマスターとして働くからには、スプリントゴールを達成することに責任を持つべきではないかと考えました。
ドクターメイトでは四半期ごとに目標を設定するのですが、僕はスクラムマスターとして、以下を明記することにしました。
＿人人人人人人人人人人人人人＿
＞ 全スプリントゴールの達成 ＜
￣Y^Y^ Y^Y^Y^Y^Y^Y^Y^Y^Y￣
ちなみにこちら、結果としては未達成に終わります笑
ですが、スプリントゴール達成のために、プランニング内容についてPOとのすり合わせを深掘りしたり、タスク分割の余地がもっとないか考えたりと、意識的に取り組むことができてとても良いアプローチでした。おそらく次の四半期目標も同じ内容で設定すると思います。
そしてようやく、ホリはスクラムマスターとしての仕事に漕ぎ出したのです。
スクラムマスターとして仕事したこと
最初に言っておくのですが、スクラム開発の問題解決に簡単なことは1つもなく、ほとんどが現在進行中で試行錯誤の真っ最中です。
そんな中、いくつか上手くハマったものもあり、今回はそれを紹介して終わろうと思います。
[改善できた] 非エンジニアが置いてけぼりになりがちなレトロスペクティブ
障害内容
- レトロスペクティブ（50分）のうち、冒頭30分程度において非エンジニアが置いてけぼりになりがち
打ち手
- エンジニアだけで行う 開発レトロ を事前に実施（30分間）
- 実施内容の要約を、通常レトロへ共有
スプリントの振り返りを行うイベント 「レトロスペクティブ」。
ドクターメイトでは50分の枠をとって開催していました。
が...
冒頭の約30分は技術的な話が中心となり、POやデザイナー、ステークホルダー（他部署）などの非エンジニアが置いてけぼりになっていました。
これはどうしてかと言うと、いつも冒頭に行っている、スプリントで消化したタスクの予定時間と実績時間において、特に大きな時間差が発生したタスクについての振り返りが、どうしても技術的な話に寄るからです。
これを受けて、レトロスペクティブ直前の30分枠で 開発レトロ を実施することにしました。いくつかメリットとデメリットが発生しています。
メリット
- 開発レトロの時間は、技術的な振り返りを気兼ねなく行える
- 通常レトロの時間で、エンジニアと非エンジニアのコミュニケーションがより活発・濃厚になる
- 通常レトロが、短い時間で終わる（50分 -> 35分前後）
デメリット
- エンジニアは、開発レトロ30分と通常レトロ50分で、予定上は合わせて80分も枠が押さえられてしまう
デメリットについてですが、通常レトロの時間短縮のメリットもあるため、実際はそこまで負担は増えていません。開発レトロはやって良かったと思えた施策でした。
振り返ってみて
スクラムマスターをやってみて、個人的に思うところもいくつかあります。
スクラム開発についてホリのモヤモヤ
- エンジニアとスクラムマスターの掛け持ちはキツくない？
- スクラムマスターが司会進行しないとグダるスクラムイベント
- デザイナーって、スクラム開発だとエンジニア側？PO側？それともどちらでもない側？一体なんなの？
こちらのモヤモヤについては、また今度記事を書いて進捗を共有しようと思います。もし同じモヤモヤを抱えている方いれば是非お話しさせてください🙏
We are Hiring!!
そんなドクターメイトですが、実際の組織ってどんなもんだろ？と思われた方がいたらぜひ、カジュアルにお話しましょう！
この記事が気に入ったらサポートをしてみませんか？