🍡

スクラム開発を取り入れてみた話

2022/12/05に公開約4,700字

こちらは「Applibot Advent Calendar 2022」10日目の記事になります。

目次(クリックすると展開されます)

はじめに


本記事では私がリーダーを務めているサーバーチームにスクラム開発を取り入れたことを紹介していきます。
チーム状況などを考慮して部分的に取り入れた状態となってしまい、スクラムガイド通りではない部分やアンチパターンになってしまったこともありますのでその点をご留意ください。

きっかけ


社内のサーバーエンジニア組織で分科会と言うものがあり、そこで開発手法について学ぶ機会があり、その1つとしてスクラム開発に触れました。
スクラムに関する書籍を読んだり分科会のメンバーで議論しりたりしましたが、実際の現場に導入して知見を得たいと思ったことがきっかけでした。
しかし、既に稼働している大きな組織にいきなり導入することは難しいと考え、まずは自分のいるサーバーチームに小規模で導入してみようと考えました。
タイミングとしても 大きなメインの機能開発が落ち着いており、スケジュール調整にある程度融通が効くため進めることにしました。

実際の取り組み


では、実際にどのように進めていったのか説明していきます。

チーム構成

  • バックエンドエンジニア:6名
    社内にスクラムマスターはいなかったため、アンチパターンではありますが私自身がスクラムチームに参加しつつスクラムの説明や進行を行っていきました。

スクラムイベント

スクラムにおけるスクラムイベントについてどのような形で進めていったのか説明します。
専門用語では直感で何をするのかわかりづらかったため、チーム内ではあまり使いませんでした。
そのため、チーム内で実際に呼んでいた用語で説明していきます。

1スプリントの期間は1週間に設定しました。
スクラムイベントは以下のスケジュールで実施しています。
1スプリントのスケジュール

工数出し(概算見積もり)

  • スプリントプランニングに当たるもの
  • 週1で30m(メンバー全員の予定の合う時間で実施)

工数のすり合わせにはプランニングポーカーを用いました。
提示したポイントの理由も話し合うことで、見落としていた懸念や各々の不明点の洗い出せるようにしました。
開始時点では担当決め・作業細分化とセットで1hで行っていました。
しかし、月曜日は元々ミーティングが多く入っており1hまとめて取ること難しかったため、事前に工数出しを行っておけば担当者決めと作業細分化は実施可能なため分割することにしました。

担当者決め・作業細分化

  • スプリントプランニングに当たるもの
  • 月曜日に30m
  • 月曜日が祝日などで休みの場合は火曜日に実施
  • 参加できないメンバーがいる場合は全員が参加できる最速のタイミングに調整して実施

スプリントバックログの中から着手順の上位のものうち、自身のスケジュールを考慮しながら選択します。
担当者になったメンバーがそのissueを完了するために必要な具体的なタスクを洗い出し、そのタスクそれぞれに対して工数を見積もります。
各タスクは理想として1日以下で完結する単位で分割するようにしていきました。

朝会

  • デイリースクラムに当たるもの
  • 毎朝15m
  • メンバーが揃わなくても実施

タスクの進捗管理ははwrike使用し、wrikeの画面を全員でみながら進捗の更新などを行いました。
各メンバーから報告してもらう内容は以下の通りです。

  1. 昨日したこと
  2. 今日すること
  3. 相談したいことの頭出し(この場で深掘りせず別途時間を取り、関係者を集めて相談する)

お披露目会

  • スプリントレビューに当たるもの
  • 金曜日に30h
  • 金曜日が休みの場合は前日に実施
  • 参加できないメンバーがいる場合は全員が参加できる最速のタイミングに調整して実施

各担当者がissueの内容を簡潔に伝えつつ、実際の画面を共有しながら行うデモ形式で実施しました。
着手前の想定と異なった箇所について説明や簡単な質疑応答も行いました。
本来はプロダクトオーナーやプロダクトマネージャーも参加してもらいレビューするのですが、サーバーチーム内で閉じているissueに絞っているためレバーチームメンバーのみで行いました。

振り返り

  • スプリントレトロスペクティブに当たるもの
  • 金曜日に30m
  • 必ずお披露目会の後に行う
  • 金曜日が休みの場合は前日に実施
  • 参加できないメンバーがいる場合は全員が参加できる最速のタイミングに調整して実施

Applibotでは「振り返りと計画」を習慣化するという取り組みがあり、毎週金曜日に時間が取られていたのでその時間をそのまま使用しました。
振り返りでは以下の順番で進め、必ず次週の目標を決めるようにしています。

  1. 先週立てた目標に対する振り返り
  2. 振り返りに対し、改善案の検討
  3. 改善案を受けての次週の目標設定

使用した管理ツール

スクラム開発を進めるにあたって使用したツールついて説明します。

Projectボード

プロダクトバックログはGitHubのissueに登録するようにしました。
そのissueをProjectボードを使って管理しています。
ボード形式なのでそれぞれのタスクの進捗が見やすく、直感的にステータスを変更できるのでタスクの可視化に最適でした。

GitHubのProjectBoard

Wrike

プロジェクト全体の進捗管理としてwrikeを使用していたので、スプリントバックログはwrikeで管理することにしました。
担当者にissueに細分化した作業と工数を記載してもらい、それをもとにwrikeに登録しています。

wrikeのボード機能

プランニングポーカーツール

リモートでも概算見積もりを行うこともあったため、無料で使用できるプランニングポーカーのWebツールを使用していましたが、ルームが一定時間経つと勝手に解散されてしまう等の課題がありました。
そこで、メンバーが自分たちの使い方にあったツールを作ってくれたおかげでこの問題が解決しました。

メンバー自作のツール(ポイント非表示)
全員が投稿が完了するまでポイントは非表示にしておきます。

メンバー自作のツール(ポイント表示)
全員が投稿完了したらポイントを表示し、すり合わせを行います。

出てきた課題課題


在宅ワークの日もあるため毎日顔を合わせられない

週2で在宅ワークの日があり、毎日同じ場所に集まることができない。
物理的なホワイトボードなどを使って進捗の可視化することが困難。
プロダクトバックログやスプリントバックログは、Webツールを使って可視化した。
使用したツールについては後ほど説明します。

スクラムイベントのためのまとまった時間を取れない

プロジェクト以外のミーティングに参加しているメンバーもおり、メンバー全員が揃う時間を1時間まとめて取ることが難しいことが多かった。
スプリントプランニングをストーリーポイント出しと担当決めを各30分ずつに分けてミーティングを行うようにした。
ただし、ストーリーポイント出しが済んでいないと担当決めはできないので、前後関係は守るようにした。

振り返りが長引くことがあった

スプリントレトロスペクティブで振り返り、改善を考える際に議論が盛り上がって時間が足りないことがあった。
振り返り用のフォーマット(アジェンダ)を用意してその流れに沿って行うようにした。

休暇などでミーティングに出られないメンバーがいることがある

病欠や家庭の事情などで急遽休みのメンバーが出て全員揃って開催が難しい時があった
メンバーがかけた状態で開催せずに必ず全員揃って開催するようにした。
翌日などで調整。
その場合、スプリントの開始が遅くなる(1日分工数が減る)がメンバー全員で進めることを優先とした。

導入してよかったこと


各メンバーが今日何をして、どんなステータスなのかがわかりやすくなった

それぞれが担当しているタスクのステータスをみんながいる前で更新するため、メンバーからも他のメンバーの進捗把握がしやすくなったということも挙がっています。

対応内容の認識合わせをする場ができた

スプリントプランニングでの工数出しの際にそのissueはどんな作業が発生し、どんなことに気をつけなければいけないのかをメンバー全員ですり合わせを行うことで、経験の浅いメンバーでも対応をスムーズに進めルことができました。

属人化が薄まった

プランニングポーカーやお披露目会などを行ったことでどのような対応をし、最終的にどのように落とし込まれたのか全員で共有できたことで、担当者以外も対応内容と結果を正しく把握することができました。

まとめ


スクラムガイド通りの導入とはいかず、部分的にスクラム開発を取り入れる形となってしまいました。
しかしながら、スクラム開発を進める上で障害になりそうなことや得られるメリットの一部については経験できたのは良い学びになりました。
社内ではまだまだスクラム開発に対する知見がなく、なかなかスクラムを導入するのは難しいですが引き続き、開発効率向上に務めていきたいと思います。

最後まで読んでいただき、ありがとうございました。

以上、「Applibot Advent Calendar 2022」 10日目の記事でした。

GitHubで編集を提案

Discussion

ログインするとコメントできます