スクラム開発を導入して軌道に乗せるまで

概要

この記事は ポートアドベントカレンダー 23日目の記事です

スクラム開発導入を始めてから約6ヶ月が経過したチームについて、
どうやって導入したか/軌道に乗ったかをまとめました。

下記のような状況で、スクラム開発導入に悩んでいる方向けの記事です。

• メンバーにスクラム開発の知見がない
• スクラム開発をやってみたいけど、どういう効果があるのかわからない

現在のチーム構成

何をしているチームか

現在のチームは、プロダクトの中の1領域のKPI改善を目標に据えているフィーチャーチームです。
(プロダクトには、開発チームが4チームあります。)

チーム内でKPIに関わる機能開発は一通りできる状態です。

⁠チームメンバー

下記のようなチームメンバーです。もちろん他にEMやPdMもいます。

• プロダクトオーナー: 1名 ✍️
  • 開発の要件などを作成する
  • マーケ出身の企画職のメンバー
• エンジニア
  • シニア: 1名 🐔(この記事の執筆者です)
    • スクラムマスターを兼任
    • 兼任・専任問題はあるが、リソース等の観点で今回は兼任でスタート
  • ジュニア: 3名 🐥 🐥 🐣
    • 新卒2年目2名
    • 新卒1年目1名
• デザイナー: 1名 🎨
  • ⁠他チームと兼任
• アジャイルコーチ: 1名 💪
  • EM(新人)
  • チームのアジャイルコーチを兼任してくれている

スクラム開発を始めるまでの流れ

当時のチームの状況

チームには、開発の進め方にいくつかのうまくいかない点がありました。
結果、リリース予定日に遅れるという問題が発生していました。

1. うまく回らない「スクラム開発もどき」
   • なんとなく1週間単位の開発のリズムを作って進めているが、うまく回っていない
   • すべてのイベントをきちんと導入できていないので、開発フローの振り返り・改善も難しい
2. 実装の終盤になって手戻りが起きがち
   • 要件がふわふわしたまま開発が始まる
   • 実装がある程度終わってから、レビュアーが要件と実装の大きなずれに気づく
   • 要件の再定義とソースコードの大幅な修正が必要になる
3. タスクの優先度について共通認識がない
   • チームメンバーがみんなバラバラのタスクをしている
   • 1人がいろんなタスクを同時進行していて、いつも忙しい
   • レビュー依頼が来たが、自分の実装とレビューどちらを先にすべきかわからない
   • Pull Requestはレビュー待ちのまま、新しいタスクに取り掛かる

きっかけ(6〜7月)

また、スクラム開発を始めるきっかけもありました。

1. 新しいチーム構成になった
   • 6月から新しいチームになった
   • ジュニアのエンジニアが多く、個々の力に任せて開発を進めるのは難しい
2. 新しい開発手法を試してよい状態だった
   • PdMがチームに権限移譲を進めたいと思っていた
   • チームの拡大・再編成に伴い、各チームで自律して動けるようにしてほしいという話があった
3. 新しいEMのJOIN(7月)
   • プロダクトに新しいEMが参加 🎉
   • 新しいEMが過去にスクラム開発やスクラムマスターを経験していた
4. 他の開発チームでスクラム開発を導入していた
   • 同じプロダクト内の他の開発チームでスクラム開発の導入が始まっていた
   • そちらに倣って始めやすい雰囲気になっていた

開始までの準備(7~8月)

勉強会の開催

チームメンバーがスクラム開発未経験だったため、スクラム開発について学ぶ会を開催しました。1時間程度の勉強会を、半月の間に4回実施しました。

• 勉強会 1回目
  • 下記の記事を読んでディスカッションしました
    • スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた｜ハイクラス転職・求人情報サイト AMBI（アンビ）
• 質問会 1回目
  • ↑1回目の勉強会でわからなかったことについて、主にジュニアのエンジニアメンバーからの質問に答える会
  • アジャイルコーチが、スクラムを導入した場合の開発の流れをまとめてくれました
• ⁠勉強会 2回目
  • プロダクトオーナーが、チームにどの程度かかわることができるのかをヒアリングしました
  • ヒアリングした内容をもとに、プロダクトオーナーの役割について相談しました
• 質問会 2回目
  • スクラムの各イベントについての、疑問を解消する会
  • 例: リファインメントは何をするの？

スクラム開始のやり方の検討&sprint0のバックログ作成

「どうやってスクラム開発を開始するか」 ということを考えていた際に、アジャイルコーチにsprint0の提案をもらったのでやってみました。

• 参考: 【スクラムの始め方】「スプリント０」の流れ・やるべきことの具体例 | Hello Scrum

上記のsprint 0の流れに則り、バックログ作成をしました。

• プロダクトオーナーと一緒にバックログアイテムを再度見直しました。
• 今までのもので必要十分かどうか、これは本当にやる必要があるのかなどを議論しました。
• 出てきたアイテムをバックログに載せ、優先順位の合意をしました。
• バックログはGitHub Projectで作成しました。今まで使っていたのと同じツールで作ることにしたためです。

イベントのスケジュール設定

各イベントは、下記のようなスケジュールになりました。

• プランニング
  • 毎週火曜
• デイリースクラム
  • 毎日
• リファインメント
  • 毎週月曜
• スプリントレビュー
• レトロスペクティブ
  • 毎週火曜

下記は、ある週のスクラムイベントの予定表です。
週の前半にイベント、後半は開発に時間を充てる形になっています。
(参加者のスケジュールの都合でイベントの順番は通常と少し異なります。)

開始、イベントに慣れる(9月〜10月)

9月からスプリントを開始しました！

最初の方は、各イベントに慣れていくことに重きを置きつつ、少しずつみんながやりやすいように調整をしていきました。

• 途中で変更したこと
  1. リファインメントの時間を、夕方から昼に変更した
     • リファインメント〜翌日のプランニングの準備時間が少なかったため
  2. デイリースクラムでの進捗確認方法を変更した
     • 各自の進捗報告のメモではなく、バックログを見ながら進捗共有するようにした
  3. スプリントレビューが進めづらかったので、誰に向けた共有なのかを見直した
     • チーム、ステークホルダーで今の状況についての認識を揃えるためのイベント
• ⁠スクラムを始めてから変わっていったこと
  1. タスクの要件などを、プロダクトオーナー・エンジニア全員が理解できる状態になるまで詰められるようになった
     • リファインメント・プランニングが機能した
  2. スプリントゴールが明確になったので、コミュニケーションが増えた
     • ちょっとした口頭でのMTGをするようになった
     • 「⁠そのスプリントでやる」と決めたことが、予定通り終わるかどうか進捗確認できた

現在(~12月)

スプリントにも慣れてきました。
細かい部分の改善ができるようになってきました。

• 良い変化
  1. 自発的な⁠コミュニケーションがさらに増えた
     • モブプロをするようになった
     • チャットでの進捗報告が活発になっている
  2. ⁠お互いの作業状況が理解できるようになっている
     • 自分のタスク以外も「これはレビュー中で...」など説明できるようになった
     • レビュー時に、仕様の認識が揃った状態になった
  3. リリースの予定日に間に合わせる意識が上がったし、間に合うようになってきた

振り返って

チームへのスクラム開発の導入は、 「成功した 」 と言っていい結果を出せたと思います。
振り返って、

• よかったこと
• 導入がうまくいった理由
• 今後の課題

を下記にまとめました。

よかったこと

開発前に抱えていた、いくつかの問題を解決することができました。

タスクのゴールが決まってから、アサインされるようになった

• ⁠リファインメントやプランニングが機能した
• 内容を理解できないままアサインされることがなくなった
• タスクが属人化しなくなった

チームメンバーが、お互いの作業について、仕様・優先順位を理解できている

• レビュー依頼と、自分が実装中のタスクのどちらが優先度が高いのか判断できる
• モブプロできる
• ⁠リリース予定日に遅れない
• 共有できるコンテキストが増えたので、コミュニケーションしやすくなった

1人が複数のタスクを同時進行することを減らせた

• 毎週のプランニングでバックログを最新化することが機能した
• 1人が10個くらいのタスクを持ったまま、優先度に悩み続けることがなくなった
• アサイン前にタスクのゴールの認識を揃えられるようになったので、レビューの段階で仕様を検討し直すことなどがなくなった

すべての結果として...

リリース予定日に間に合うようになってきた

導入がうまくいった理由

1. みんな前向きで協力的だった

• チームメンバーが、スクラム開発の導入に対して協力的でポジティブだった
• モチベーションになったので、とてもありがたかった

2. 困ったときに相談できる相手がいた

• この試みが始まる前、半年以上EM(アジャイルコーチとは別のEM)が定期的に1on1をやってくれていたので、スクラム開発の導入について意欲的に考えてくれていることなどがわかっていた
• 上記のような下地があったので、スクラム開発の導入を進めやすかった
• アジャイルコーチがスクラムについて知見があり、NEXT ACTIONで悩んだ時に相談しやすかった

3. 準備期間を設けて導入した

• そもそも「スクラム開発とは？」というメンバーがほとんどだったので、勉強会などを設けてよかった
• 「導入するとどういう効果があるのか(エンジニアにとって、プロダクトにとって)」というイメージを共有できたので、途中で諦めずに導入まで進んで行けたと思う

今後の課題

1. 各イベントで困っていることを改善する

各イベントについて、課題感があるので改善していきたいです。

• 例:
  • MTG時間が長い→プランニングは今1時間やっているが、30分にできそう
  • デイリースクラムの時間が伸びがちだが、アジェンダをどのように変更すべきか

2. 「目的」をメンバー全員が理解できるようになる

チームメンバーがスクラム開発の型に慣れてきた&スクラム開発による恩恵も実感できていると思います。

次のステップとして、各イベントを何の目的達成のためにやっているのかを、ジュニアのエンジニアも考えられるようにしていきたいです。

• 例:
  • なぜ、デイリースクラムで昨日の作業内容を報告しているのか？
  • リファインメントとプランニングが分かれているのはなぜ？
  • スクラム開発から受けている利点は何か？

3. ベロシティのより正確な計測

Tシャツサイズ見積りはしているのでなんとなく1sprintでどのくらいのタスクをこなせるかはわかっているのですが、

• ジュニアメンバーの、プロダクトの仕様の理解度が上がってきた
• コミュニケーションの量が増えてきたので、今までより色々な待ち時間(仕様決め、レビュー待ちなど)が減った

などの要素によって、1sprintにできるタスク量が変わってきている感じがあります。

チームのベロシティをより正確に計測できるよう、体制を整えていきたいです。

おわりに

課題はまだまだあると思いつつ、始める前よりはかなり業務を進めやすくなりました。

また、「リリース予定が遅れていく」「仕様と実装のズレが出てしまう」などの課題を解決することができたので、チームとしてのスピード感やアウトプットの量も増やせるようになってきたと思います

記事の作成にご協力くださった皆さん、スクラム開発導入をサポートして見守ってくださった皆さん、ありがとうございました