スクラム開発のベロシティを改善するために行ったこと

私のチームではスクラム開発でのWebアプリケーション開発をしています。
フルリモートワークかつ半分以上の人とは一度も会ったことがないという状況で最初のリリースまでこぎつけ、その後も継続してエンハンスを行っております。
そういった中で、継続してチームの運営を改善してベロシティをあげるために取り組んだことをご紹介します。

前提

• チームの状況
  • 開発者は自分を入れて6人 (プロパー社員2人、ビジネスパートナー4人)
  • 2週間1スプリントでのスクラム開発
  • フルリモートワーク
  • 半分以上の人とは一度も会ったことがない
  • 最初のリリースからリリース後1年ぐらいまでの話
• 私の状況
  • この会社には中途で入って社歴は1年半ぐらい
  • 自分はスクラムマスターやりつつ開発リードも担当
  • プロジェクト開始から1年ぐらいはスクラムガイドや書籍で学んだことを元にスクラム開発を実施
  • その後、Scrum Inc.認定スクラムマスターを取得

プロジェクト開始当初の状況

プロジェクト開始当初の状況としては、チーム内になんとなくスクラム開発をやったことメンバーはいるものの、スクラムマスターとしてチームを運営したことのあるメンバーはいない状況でした。
また、スクラム開発という名前自体は知っているものの具体的にどういったことに注意してどう進めるのかもわからないメンバーもいる状態でした。
そこで私がスクラムガイドや書籍を読んで、まずは基本通りにスクラム開発を開始しました。

• ユーザーストーリーマップ、プロダクトバックログ、スプリントバックログの作成
• 各スクラムイベントの実施(スプリントプランニング、デイリーミーティング、スプリントレトロスペクティブ、スプリントレビュー)
• ストーリーポイントを使用した見積もり、ベロシティの計測

このように実施する中でもうまくいかないということがあれば都度改善を実施しながら進めてきました。
この記事ではどういった課題が発生してどう改善してきたのかを紹介します。

取り組んだこと

①デイリーミーティングの改善

課題
デイリーミーティングでは各メンバーの進捗報告のみで、設計や開発方針をディスカッションしたい場合は関連するメンバーのみを集めて別でミーティングを実施するという運用にしておりました。
ただ、だいたいの相談先が開発リードをしている私なのですが他の業務も兼務しており、なかなか別枠での相談の時間が取りづらいという状況でした。
結果、問題の解決が遅れてしまいチームとしての生産性があがらない状況となっておりました。

改善前の状態

• デイリーミーティングは15分
• 各メンバーが進捗報告のみを実施

改善後の状態

• デイリーミーティングの時間枠としては60分を全員あらかじめ確保
• 進捗報告の時間はこれまで通りに15分
• 相談したいことがある場合は関係するメンバーだけが残って残りの45分で実施
• 何も相談事がない場合は15分で終了

成果

• ミーティング時間の調整という面倒な作業が不要になりました。
• 重要で急ぎの相談であればこれまでは私は日中帯でも優先して対応していて他の業務にしわ寄せが来ていましたが、そういった事がなくなりました

②テストの実施タイミング

課題
スプリントでは開発者自身が機能としての試験を実施し、リリース前にリリーススプリントを設けて総合テストを実施するという方法をとっておりました。
開発者自身の試験では要件の認識齟齬により一部の実装が漏れていたり、コーナーケースでの実装が漏れていたりということが発生しておりました。
そういった問題がリリース前の総合テストで見つかっており、リリース前の作業が逼迫してしまうという状態でした。

改善前の状態

• スプリントでの試験は開発者のみが実施
• 開発者の試験が完了したらそのチケットを完了とする

改善後の状態

• スプリント期間中に開発リーダーである私も試験を実施
• 開発リーダーでの試験を実施することもチケットの完了の条件に含める

成果

• リリース前の総合テストで見つかる試験が2~3割ほど減少しました。

※ちなみに開発リーダーがである私が試験を実施することにしたのは、プロダクトオーナーとのやり取りが多く最も要件を理解しているという点と、第三者の観点でチェックするため

③ミーティング形式でのPull requestのコードレビュー

課題
コードレビューはGitHubのPull requestのコメント機能を使用して実施しておりました。
コメントの意図がわかりづらく、内容を理解するだけでやり取りが2~3往復かかってしまい1日や2日を無駄にしてしまうということが発生していました。
レビューする側、レビューされる側のそれぞれに以下のような課題がありました。

• レビューする側
  • どういう方針で修正したのかがわからない
  • 要件を正しく理解した上で修正しているのかがわからない
  • コメントした意図が伝わっているかわからない
• レビューされる側
  • 既存コードの制約で仕方がなくこの修正にしているのにその意図が伝えづらい
  • レビューアーからコメントされた内容の意味がわからない

改善前の状態

• コードレビューはPull requestを出してGitHub上で確認するのみ

改善後の状態

• 改善前の状態に加えて、デイリーミーティングの後半の時間で口頭でもPull requestの内容を確認するように変更
• すべてのコードをその場で確認するのではなく、ポイントを絞っての確認を実施
• 前日までにコメント済みのPull request
  • コメントの内容を見て開発者側がコメントの意図がわからないものがあれば確認をする
  • レビューアー側は意図が伝わりづらいポイントに絞って解説を実施
• 前日までにコメントされていないPull request
  • 要件・期待動作、修正方針を開発者側からざっと説明をする

成果

• コメントの内容を確認するだけで無駄に何往復もやり取りがされるということがなくなりました。
• 開発者側の実感としても全員から開発スピードがあがったという声がありました。

④開発の標準ルールの作成

課題
コードレビューは主に開発リーダーである私が担当しておりましたが、毎回同じような問題に対してコメントをするという状況がありました。
また、コメントをする時にも、「なぜそのように修正する必要があるのか」ということを合わせて説明をしており手間がかかっておりました。

改善前の状態

• プロジェクトとしての設計方針や規約などはレビューアーの中にはあるが、文書として書かれている内容は一部にとどまっている

改善後の状態

• プロジェクトとしての設計方針や規約をドキュメント化
• LinterやFormatterなどで自動でチェックできるものはコードのコミット時に自動でチェックするように変更

成果

• 1つのPull requestに対するコメント数が半分ほどに減少しました。
• レビューアーがコメントを記述する際にかかる時間が減少しました。

⑤バックログリファインメントでの準備状況の確認

課題
スプリントで開発に着手したものの、要望や仕様が決まっていなかったり、デザインが一部未確定の箇所があったことで、スプリント中に開発が終わらないという状態でした。

改善前の状態

• スプリントで対応するチケットの仕様やデザインが決まっていないことがある
• デザイナーはプロジェクトチームに専属でいるわけではないため、スプリント計画を意識してくれているわけではない(そのためいつまでにデザインをしてほしいかは開発側から能動的に働きかけが必要)

改善後の状態

• バックログリファインメントの中で次の1~2スプリントで実施するチケットの準備状況を確認
• 仕様やデザインが決まっていないチケットには[未決定]というラベルを付けておいてひと目でわかるようにした
• 未決定のものはデザイナーに相談をしてどのようにすべきかをスプリント開始までに決定

成果

• 仕様未決定による開発の遅れが減りました。
• 仕様が決まっていないとタスクの順番を入れ替えて急いで仕様を決めるように調整するか、別のタスクを先にするかなどの調整が必要でしたが、そういった調整業務が減りました。

⑥ナレッジ共有会の実施

課題
ライブラリのAPIの使用方法やパフォーマンスのチューニング方法など、各開発者が工夫して取り組んだ内容がその開発者だけのノウハウにとどまっている状況でした。

改善前の状態

• 開発に取り組む中で得られたナレッジはその人だけの気付きになってしまっていた

改善後の状態

• 隔週でのナレッジ共有会を実施
• ナレッジ共有会で取り上げるものは自薦の他に、スプリントレトロスペクティブで出てきたもののうち、それはチーム内で共有した方が良いとなったものをピックアップして共有

成果

• チーム内でのナレッジ共有が進みました
• これまでは気づいた人だけが共有するという状態でしたがナレッジ共有会の場以外でも積極的に共有するという文化ができました