みなさん、はじめまして。はまです。
今回はスクラム開発初心者の私が、スクラム開発を体験して学んだことについてお話します。
プロダクトの詳細については記載ができませんが、業務をリモートにて実施できる社内開発のプロジェクトです。
そのプロジェクトはスクラム開発にて進めることになり、スクラム開発未経験の私が、スキル向上と経験を積む目的として、QAエンジニア兼スクラムマスターとしてアサインして頂くことになりました。
チーム構成は、アジャイルコーチ含めて9名でした。
スクラムマスターとしてプロジェクトを進める中で実施してきたこと、使用したツールなどを交えたお話も合わせてできればと思います。
スクラム開発、スクラムマスターとは
スクラム開発はどういうものなのか、スクラムマスターとは何なのか、簡単にではありますが説明致します。
もっと詳細を知りたいという方は、SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 を是非読んでみてください。
この本は私が以前におススメで紹介して頂いた本で、マンガ形式になっていて初心者向けの本となっています。
記載内容は、上記本を参照しています。
スクラム開発
スクラム開発とは、アジャイル開発手法の1つです。
ラグビーのスクラムが語源となっているそうで、ラグビー選手がスクラムを組むようにして、チーム一丸となって開発に取り組むという、コミュニケーションを重視した手法となります。
スクラムには以下の特徴があります。
- 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化します。
- スクラムでは固定の短い時間に区切って作業を進めます。固定の時間のことをタイムボックスと呼びます。
- 現在の状況や問題点を常に明らかにします。これを透明性と呼びます。
- 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます。
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます。
スクラムは分かっていることよりも分からないことが多いような複雑な問題を扱うのに適しており、5つのイベント(会議など)、3つのロール(人の役割)、3つの作成物など最低限のルールのセットで構成されています。
あくまで最低限のルールのみ用意されているので、そのルールを実際にどのように適用していくのかは自分たちで考えなければなりません。また、スクラムで決まっていない部分(※コードの書き方やテストのやり方)等プロダクトを作るうえで必要な点についても、自分たちの状況を踏まえて取り組んでいく必要があります。
スクラムマスター
スクラムマスターは、スクラムのルールや作成物、進め方をプロダクトオーナーや開発チームに理解させ、効率的な実践を促し、スクラムの外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守ります。
したがって、まだスクラムに慣れていない段階では、スクラムマスターはプロダクトオーナーや開発チームにスクラムのやり方を教えたり、イベントの司会進行を行ったりするような先生役やトレーナーとして振る舞うことが多くなります。このような振る舞いに慣れてきたら、よりうまく仕事が進められるようなヒントを与えたりする活動にシフトしていきます。
スクラムマスターとして実施していたこと
1.スプリントプランニング (またはスプリント計画)
スプリント開始前またはスプリントレトロスペクティブ後に、次回のスプリントのゴールや方針を決めます。
ここでスクラムマスターがファシリテートします。
ZenHub Sprintsのツールを使用して画面を共有しながらファシリテートしました。
スプリントプランニングにて確認していく項目は以下です。
- スプリントプランニングを実施する前の事前準備
→プロダクトオーナーより優先順位を確認。
→プロダクトバックログ項目の中身を具体的にしたり、疑問点を解決したり、受け入れ基準を明確にしたり、各担当者が実施可能なサイズに分割し見積り等をスクラムチーム全員で決める。
→上記対応後、過去の実績(ベロシティ)などを踏まえて次回スプリントでどこまでをゴールとするか事前に方針を決める。
- 次回スプリントの対応内容の認識合わせ
→事前準備にて決めた方針をプロダクトオーナー含めた関係者に報告。
→達成したい目的に相違がないかや詳細な部分の認識等を協議し合意を得る。
※スプリント：スクラムでは最長1か月までの固定の期間に区切って、繰り返し開発を行います。この固定期間のことをスプリントと呼びます。本プロジェクトは2週間で対応しました。
※プロダクトバックログ：スクラムでは、機能や要求、要望、修正などのプロダクトに必要なものを抽出し順番に並び替えたプロダクトバックログと呼ばれるリストを作成します。
2.デイリースクラム
デイリースクラムの目的としては、コミュニケーションを通して進捗、質問、課題を共有する場となります。
課題がある場合は、課題解決に向けてどのように行動するかを確認し開発の手助けを行います。
ZenHub Sprintsというツールを使用して画面を共有しながら話していました。
デイリースクラムは、15分間で終わせられるのがベストです。
※延長したとしても30分以内
スクラムマスターがファシリテートして、各担当者を指名して報告してもらう形で進めます。
デイリースクラムにて確認していた項目は以下です。
- 各担当者の前日のデイリースクラムから、当日のデイリースクラムまでに実施した作業内容
- 各担当者の当日のデイリースクラムから次回のデイリースクラムまでの実施予定の作業内容
- 質問や課題内容
- 上記以外で共有する内容
質問や課題については、以下のことを意識して対応するようにしていました。
- 質問や課題が全体に共有するべきものか、チーム全員の意見を聞きたいものであるか
→全体に共有する内容の場合は、デイリースクラムにて確認。
→個々の質問や他の人に影響のないものは別途確認。
- 質問や課題がすぐに解決する場合
→デイリースクラムにて確認。
→チーム全体で認識を合わせる。
- 質問や課題が時間内に終わりそうにない場合
→質問や課題の確認を一旦打ち切り。
→別途打ち合わせを組んで確認。
- 質問や課題がチーム内で解決しない場合
→確認内容の整理。
→問い合わせ先をチーム内で認識を合わせる。
3.スプリントレビュー
スプリント終了時にスクラムチームと関係者が集まり、成果物(インクリメント)を報告しレビューして頂きます。
スクラムマスターがファシリテートして、ZenHub Sprintsのツールを使用して画面を共有しながら話していました。
スプリントレビューにて報告する内容は以下となります。
- 開発及びテストが完了したインクリメント
→実際の画面を操作し機能の説明。
→実際に触って頂き、フィードバックを引き出す。
- 開発が完了してテストが未完了なインクリメント
→未完了理由、進捗状況、完了予定を提示し合意を得る。
- 開発中のインクリメント
→事前に開発の進捗状況、完了予定を確認。
→状況を報告。
- 保留になったインクリメント
→事前に保留理由、完了予定を確認
→状況を報告。
- 開発未着手のインクリメント
→事前に状況を確認。
→次回のスプリントで対応予定なのか等を含めて報告。
※インクリメント：完成の定義を満たしており、動作して評価可能なプロダクトのこと
4.スプリントレトロスペクティブ
スプリントレビュー後に、直近のスプリントでのプロダクトの開発に関わる活動の振り返りを行います。
スクラムマスターがファシリテートします。
スプリントレトロスペクティブ実施時は、Miro(またはGoogle Jamboard)のツールを使用していました。
スプリントが2週間の場合、スプリントレトロスペクティブは1時間半～2時間が理想となりますので時間も意識して進めるのが良いです。
スプリントレトロスペクティブにて確認していた項目(KPT)は以下です。
- よかったこと/感謝の気持ち(Keep)
→3分～5分の時間を設定し、各担当者に付箋でコメントを記載。
→記載後、各担当者を順々に指名し発表。
→内容が他の人に向けられているものであれば、その方の意見を頂く。
- 改善点/課題点(Problem)から新しいチャレンジ(Try)
→5分前後で時間を設定し、各担当者に付箋でコメントを記載。
→記載後各担当者を順々に指名し、発表。
→一旦は全てのコメントの説明を一通り行い、内容の優先順位を付ける。
→優先順位順に参加者全員で意見を出し合う。
→原因/解決策/改善策の特定をしていき、次回のスプリントで実施していくこと(新しいチャレンジ)を記載。
→皆さんの合意を得て付箋を置いていく。
→2回目以降のスプリントレトロスペクティブでは、前回の新しいチャレンジの内容を振り返り、トライできたのか、それとも継続中なのかを確認。
その他の作業(QAエンジニア)
1.フロントエンドのテスト
フロントエンドの受け入れ基準を確認し、テスト観点を作成したうえで開発完了後にテストを実施します。
仕様で不明な点があった場合や、観点の漏れ、追加で必要な観点が発生した場合は、チャットツールで共有し更新/観点追加等を実施していました。
観点については、開発視点とQAエンジニア視点で意見を出し合い双方の合意を得て作り上げていました。
2.バックエンドのテスト
バックエンドの受け入れ基準を確認し、開発が完了したらテストを実施します。
確認方法は、mablでの実施(自動化)とSwaggerでの実施(手動)にて各APIのResponse(200、401、422等)を確認します。
その他の作業(スクラムマスター)
1.資料作成
本プロジェクトを進めるうえで、当初はフローや実施方針やルールが決まっていなかったのでプロジェクトがうまく進まないことが多々ありました。
課題に直面したときに打ち合わせやチャットツールでのやりとりを重ねて資料化を行いました。
詳細については省略致しますが、作成した一覧は以下です。Notionを使用していました。
- チケット運用ルール
→ZenHub Sprintsにてチケットを管理しており、チケットを配置する各ラインのステータスの説明、ルール、チケットの記載方法、完了までの流れ等を資料化したものとなります。
- QAチームのテスト実施方法
→QAチームで作業するうえで、テストの実施方針、mablでのテスト実施について、テスト観点シートの運用等の資料化をしました。
- 不具合検出時フロー
→不具合発見時の流れについて資料化したものとなります。
不具合を発見した際は、まずはチャットツールで共有を行いフローに記載の記載方法等を参照しバグチケット化します。そしてスプリントゴールを前提に、優先度を決め対応可能かを含めてスクラムチームで協議し、スケジュールに影響があったりする場合はエスカレーションをするようにしておりました。
- API手動実行について
→API手動にて実行する際の手順を資料化したものとなります。
- トラブル時の確認方法と復旧方法
→トラブルが起きた際の対応について資料化したものとなります。
動作確認をするうえで、物理的な問題や内部的な問題が発生しておりました。
当初は、開発チームに依頼をし調査や復旧の対応をして頂いていましたが、開発のタスクを阻害したり進捗に影響があったりもしましたので作業を巻き取れないかを検討しました。
調査方法や復旧方法をヒアリングし、手順化することで開発チームのタスクを少しでも軽減するようにしていました。
初めてのスクラムで出た問題
初めてのスクラム開発、初めてのスクラムマスターは、最初は、不明な点が多くルールが決まってなかったり、課題があったり、チームがバラバラだったりとうまくいかないことばかりでした。
その点について少しお話してみようと思います。
1.コミュニケーション
スクラム開発では、メンバー間のコミュニケーションを密に取ることが非常に大切です。
本プロジェクトではコロナ渦ということもあり、リモートワークにて業務を行っておりました。
コミュニケーションはチャットツールを使用しておりましたが、対面ではないコミュニケーションは当初難しさを感じました。
対面だと直接資料を見せながら話したり、画面を操作しながら話したりなどをして確認を行いますが、リモートワークだとチャットのやりとりがベースとなります。
リモートワークでのコミュニケーションをどのように取り組んでいったかについて、事例をもとにお話します。
- ・バックエンドテストの実施方法
→バックエンドテストの実施方法が、当初把握できておりませんでした。
そこで、実施方法をまずは開発チームとチャットツールの通話機能を使用し画面共有をしながら質疑応答を交えて確認しました。そして実施方法を把握したうえで、どのような観点で確認をしていくかや開発フェーズからQAフェーズのフローを協議し、スプリントを進めるようにしていきました。
実施方法や観点等については資料化(Notion)やチケットに記載し、見える化を行いました。
- 不具合
→不具合発生時の扱いが当初決まっていませんでした。
こちらについてもチャットツールの通話機能を使って打ち合わせの場を設けて、不具合発生から改修確認までのフロー、不具合報告に必要な情報、不具合チケットの記載方法を協議しスプリントを進めるようにしていきました。
不具合についても、資料化(Notion)し見える化を行いました。
上記に記載したようにチャットだけではなく通話機能や見える化等を組み込むことで、リモートワークでのコミュニケーションのやり方を学び、取り組んでいくことができました。
2.受け入れ基準漏れ
開発チーム側とQAチーム側で連携がうまく取れておらず、QAフェーズで受け入れ基準の漏れが発生し、当初のスプリントは計画通りに進まない状態でした。
理由としては、開発フェーズでは開発チームの視点のみの受け入れ基準となっており、QAフェーズでQAチームの視点を追加して受け入れ基準を確認しておりましたので、開発の手戻りが発生し進捗が遅れる状況になってしまいました。
そこを改善するために、開発フェーズもしくはそれまでに開発チームとQAチームで積極的にコミュニケーションを行い意見を出し、それぞれの受け入れ基準をチケットに盛り込んで確認していくようにしていきました。
その結果、進捗の改善に繋がることができました。
3.スクラムマスターとして工夫したこと
上記ではコミュニケーションやスプリントを進める上での取り組みについてお話しました。
次にスプリント対応中に発生した事例を1つお話します。
とあるデイリースクラムで、想定外のエラーの報告がありました。
デイリースクラム内で開発メンバーと話し合ったのですが原因が分からず、また、開発者に伝えるべき内容を整理した方がいいと判断しました。
そこで一旦デイリースクラムではこの件について打ち切り、QAメンバーへ個別でヒアリングを実施し別途報告をする方針で進めることにしました。
担当者からヒアリングをし、調査を行った結果、要件を満たさなくなるようなクリティカルな仕様の考慮漏れだということがわかったのです。
ちょっと厄介な不具合でしたが、その後対応方針を決め、以降のスプリントで対応を行い想定外のエラーの解決に繋がりました。
この時、各会議の時間を意識したり、課題解決に向けた最適なアプローチを考えることもスクラムマスターとして意識していくことなのだと感じました。
最後に
記載した内容は一部ではありますが、このようにチーム全体で密にコミュニケーションを取りながら、コーチからのサポートやアドバイスを頂きつつスプリントを重ねることで、様々な問題を解決していきました。
徐々にではありますが良いチームで作業をしていくことができ楽しく業務/勉強をさせて頂いておりました。
まだまだ、経験としては浅いですがこの経験をチャンスに次に繋げたいと思います。
スクラムに興味がある方！まずは、冒頭で紹介した本を手に取ってみては如何でしょうか。
最後までお読み頂きありがとうございました。
