チームでスクラム開発を導入してみました / 開発者向けブログ・イベント

こんにちは。デベロッパーリレーションズチームの村上です。

今回は最近チームで取り組んでいるスクラム開発について書いていきます。
よく聞く開発手法だけど具体的にどんなものなのか、実際生産性って向上するのか等、気になる方はぜひ参考にしていただければ幸いです。

スクラムの導入

今回チームにスクラム開発を導入するとなった経緯は、上長からの指示がきっかけでした。ただ自分自身別の機会でスクラム開発のいい部分を経験していたので、ぜひ取り組みたいものでした。全員で始めるのは難しいので、まずはトライアルとして少数で始めることになりました。

https://developers.gmo.jp/5571/

https://developers.gmo.jp/14672/

体制について

スクラムマスターは私が担当し、サービスのディレクションをするディレクターにプロダクトオーナーを担当してもらってます。開発チームは新卒2～3年目のメンバーを中心に4名アサインしました。全員がスクラム開発をするのは初めてなので、（今もですが）手探りで最適なやり方を探しています。

ステークホルダーは事業部の担当者になりますが、まだまだスクラム開発の流れにうまく参加してもらえていない部分があるので、今後更にスクラム開発を進めていく上では、協力してもらうことが必須になってきそうだなと考えてます。

スクラム実践

それでは実際にどのように実践しているかを書いていこうと思います。
実践するにあたり、所謂スクラム開発の型には嵌めてまず取り組み、チームのやり方として合わないなというものを自分たちに合うように改変して行っています。なのでアンチパターンを含む部分もありますが、ご了承いただけると幸いです。

使っているツールに関して

スクラム開発を行う際に、バックログやタスクボードを管理する必要がありますが、本来であればホワイトボードに模造紙を貼り、直接書き込んだり付箋をペタペタ貼っていきます。ただ現在オフライン・オンラインでのハイブリッドな体制で日々業務を行っているので、今回はmiroを使用しています。
スクラム開発で出てきた様々な情報は、このmiroに書き込んでいってチームの全員がいつも目に入るようにしておくことで、作業効率をアップさせていきます。

スプリントの期間

テンプレートなやり方だと、スプリントの期間は最低2週間からと言われています。それに倣いうちのチームでも1スプリントを2週間と定めました。案件によっては2週間が長すぎる場合もありますが、まずはスクラム開発のリズムを掴んでもらうため、現在もそのままにしています。

デイリースクラム

デイリースクラムは朝に行っています。デイリースクラムは15分以内という制約があるので、それ以前と比べてスピーディーにMTGを終わらせることができています。ただ時間に囚われて大事な報告や相談事が漏れてしまうことがあったので、短い時間の中でしっかりと話し合う力をつけることは大事かもし行うれません。

報告を行う際は、ふんわりとした表現は使わず、あと○時間で終わりますや、こういう懸念事項があるので終わりませんと言い切った報告してもらえるとわかりやすいですね。

スプリントプランニング

スプリントプランニングは主にスプリントの開始時にやってますが、バックログがなくなってきたり新しいバックログが追加された際は都度行っていきます。最初は仕様がわかっている私がタスク作成を行っていたのですが、現在は開発チームで頑張ってやってもらってます。
タスクに関してはなるべく細かく分割するようにして、複数の改修を含まないように作ってもらってます。そうすることでタスクのコードレビューがやりやすくなり、ミスが減ったり複数人での仕様の理解が進んでいるように感じます。
タスクは開発チームでサインアップしており、自身のレベルに合わせたタスクを取ったり、やってみたいタスクを取れる環境ができています。スクラム開発の当初より積極的にサインアップを行っていたり、難しいタスクを複数人で対応しようとしたりする姿が見えて、チームも成長している実感が非常にあります。

スプリントレトロスペクティブ

振り返りに関してはまだうまく意見を出せてる感じはありません。今後もスクラム開発を継続していくことで「なぜうまくいかなかったか」「次回はどうすればうまくいくのか」を繰り返していくことが大事だと考えてます。まだまだ意見は少ないですが、慣れてくればもう少しスクラム開発についてが見えてくるようになるはずです。

これから改善する点

上記のスクラムの実践ですが、現在3ヶ月ほど経過した状況です。
その中でもこれから実践・改善に取り組まないといけないポイントを上げていきます。

スプリントの期間が長い

現状細かな案件を含めると週に2度ほどリリース作業を行っています。その状態でスプリントが2週間というのがちょっと長すぎるかなという印象があります。
アンチパターンではありますが、スプリントを1週間にして、金曜にスプリントプランニング、木曜にスプリントレビューを行うようなリズムが良さそうと考えてます。週末にプランニングしておくことで、週初めからスムーズに作業に入れるかなと考えたからです。いっそスプリントレビューも金曜にして、午前中にスプリントレビュー、午後にスプリントプランニングみたいなやり方でも良いかもしれません。

ベロシティが安定しない・測りづらい

これには色々な要因があると考えます。

1つはサービス開発における運用案件の存在です。
現在のスプリントプランニングに運用案件を入れていない為、純粋に元あるタスクが進まないという状態になります。プランニングに含めればベロシティとしては測れるようになるので、今後は含めてスクラムを回していかないといけません。

それ以外だとストーリーポイントの数値の不正確さです。
これはエンジニアのスキル差が結構あるのもあるし、そもそもプランニングポーカーの数値のイメージがチーム内で揃っていないような感じを受けてます。今後もあんまり上手く見積もれる気がしていないので、実際の時間で見積もりしようかと考えてます。通常はストーリーポイントとかでタスクの分割を意識するのですが、現在は1改修＝1タスクにしてかなり細かくしてるので、タスクに落とし込む部分はうまくできてそうです。

スプリントレビューの重要度

スプリントレビューはスプリントでのインクリメントのレビューを行うものですが、現状では開発に入った段階でかなり仕様が確定してるので、ステークホルダーにインクリメントのレビューを行ってもらうほどじゃないという状態です。ただリリース直前にステークホルダーのチェックがはいるので、それがスプリントレビューの代わりになってます。どのような形でスプリントレビューを実施するか、その形を今後は模索していくことになりそうです。

まとめ

いかがだったでしょうか。まだまだ荒削りというか試行錯誤の段階なので、色々と考える部分はあるのですが、うまくスクラム開発を回せれば生産性向上に繋がりそうな感じはあります。現在うちのチーム以外でもスクラムチームの運用が始まっており、定期的に情報共有を行ってます。

みなさんもスクラム開発は自分のチームに合わないなと最初から決めず、まずは取り組んでみて自己流にカスタマイズするのもありじゃないかなと思います。それがアンチパターンであったとしても、結果として生産性向上に繋がれば成功です。ぜひ取り組んでみてください。