はじめに
こんにちは、lenです。
現在自分はバックエンドセクションのメンバーとともにある改善プロジェクトに参画しております。
そのプロジェクトでは、スクラムを用いてプロジェクトを進めていますが、初めてのスクラムだったので困ったことや反省点についてお話していきます。
スクラムについて
スクラムをするにあたり、弊社のエンジニア研修での課題図書でもある SCRUM BOOT CAMP THE BOOK(翔泳社) をあらためて読み直しました。
そこでは、スクラムとは以下の特徴があると述べられています。
- 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化します。
- スクラムでは固定の短い時間に区切って作業を進めます。
- 現在の状況や問題点を常に明らかにします。
- 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題はないかどうかを確認します。
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。
現在自分が参画しているプロジェクトではプロダクトオーナーが1名、開発メンバーが3名(バックエンド2名、フロントエンド1名)のメンバー構成で、1週間のスプリントで区切られております。
私の所属はバックエンドセクションですが、今回新たな技術への挑戦ができる機会があり、フロントエンド開発を日々技術を学びながら進めています。
教材入稿ツールとプロジェクトについて
今回自分が参画したプロジェクトは教材入稿ツールのリプレイスを行うプロジェクトになります。
教材入稿ツールはN予備校で提供されている教材をまとめて入稿するためのツールです。
今回作成するツールでは入稿のほかに教材管理マイクロサービスから情報を取得し教材を管理できる機能も追加しています。
既存ツールはJenkinsなどで実行されるものでしたが、複雑な教材仕様の入稿の際、教材入稿者に負荷がかかっていたのでそれを改善すべくWebサービス化を図るものです。
詳しくはドワンゴ教育事業ソフトウェアエンジニア採用資料説明のサーバーサイド開発の取り組み - 開発における課題と取り組みの事例にて紹介されておりますのでこちらをご覧ください。
今プロジェクトでのスクラムの流れ
基本的な1スプリントは以下のような流れになっています。
- スプリントプランニング
- デイリースクラム
- スプリントレトロスペクティブ・スプリントレビュー
デイリースクラム以外は週1で行われるため、進捗共有も兼ねて担当のデザイナーの方を呼んで実施しています。
スプリントレトロスペクティブとスプリントレビュー、スプリントプランニングをあわせて30分で実施しています。
また、バックログリファインメントは不定期に行っています。(新しいチケットを作る必要が出てきたりしたときに適宜行う)
スプリントプランニング
バックログに積まれているチケットとストーリーポイントを確認し、どのぐらいのチケットをスプリントに載せるかを決めます。
今プロジェクトでは工数の見積もりやスケジュールなどを鑑み、一人当たり5ストーリーポイントを解消するのを目標にプランニングを行っています。
デイリースクラム
1日の進捗確認や困っていることなどを相談する時間になります。
困っていることを相談し、すぐ解決できそうな場合はこの時間内で悩みを解消します。 また、全体的な連絡・共有なども行っています。
スプリントレトロスペクティブ・スプリントレビュー
スプリントの終わりにどのぐらいスプリントを終わらせたのかの確認とスプリントの振り返りを行います。
振り返りでは開発の進め方など行動において良かったところと良くなかったところをKPTとして貼りだして共有しています。
その後、スプリントを閉じレポートをみてどのぐらいの進捗具合だったかを確認し見積もりの再確認をします。
反省点
次に、スクラムをしてもっとこうしたらよかったんじゃないかという反省点を紹介します。
スプリントレビューでの実演
スプリントレビューでは「完成した機能のデモを行い、ステークホルダーから良い点や意見のフィードバックを受ける」必要がありますが、実際に動かせるデモができるようになったのは後の方になってからでした。
その結果、納期が迫っている中、機能開発とデザイナーの方からのデザイン修正を同時進行で行う必要が発生してしまいました。
コンポーネントごとのUIの確認としてStorybookを導入していたこともあり、こちらを活用し、コンポーネント単位でデザイナーの方にレビューしてもらうことで早めにデザイン修正にとりかかれたのではと反省しております。
見積もりの甘さ
チケットを作成した時点で基準に応じてストーリーポイントをつけていくのですが、その見積もりが甘くスプリントごとに達成したベロシティにブレが多くありました。
見積もりの方法としては、基準となるチケットを2のものと5のものとで用意して、それを比較してストーリーポイントを作成していました。
その際に細かくチケットで行うべき実装内容を精査していたわけではなかった(感覚で相対見積もりしていた)ため、正しくストーリーポイントが機能していませんでした。
中には自分が担当しているチケットが1つも終わらないままスプリントが終了してしまうこともありました。
こちらの反省点についてはバックログリファインメントにて作業量に応じたストーリーポイントの修正を日々行なっていくことで改善を図っています。
また、デザイン確認や修正の工数を見積もっておらず、後からストーリーポイントを追加していく作業が何度かありました。
こちらも最初の時点でそれを踏まえたスケジュールの設定をしておくべきだったと反省しております。
教材管理マイクロサービス開発者の進捗共有
教材入稿ツールの改善をしていく上でプロジェクトメンバー外の方々の協力が必要不可欠でした。
具体的には教材管理マイクロサービスの改修をしているバックエンドメンバーです。改善をする上で新たなAPIの作成や既存APIの修正などを対応いただいております。
今プロジェクトの中には教材管理マイクロサービス開発者の修正対応が終わってから開発がスタートできるタスクが多くありましたが、私自身が教材管理マイクロサービス開発者の進捗状況をわかっておらず、1スプリントに対応待ちタスクが何個も入っている状態になってしまいました。
自身の開発優先度を把握するためにも、早いうちから教材管理マイクロサービス開発者が抱えているタスクや依頼することなどを理解する必要があったなと反省しております。
現在では、sync会という名前で教材入稿ツール開発メンバーと教材管理マイクロサービスの改善メンバーを交えて進捗共有を行っています。
やってよかったこと
次では、スクラムをよりよくするためにやってきてよかったことを紹介します。
スクラムマスターのローテーション
基本は決まった役職のままスクラムを行なっていくと思いますが、自分も含め開発メンバーのスクラムマスターの経験がなく、スクラムマスターの共通認識をもつためローテーションを行うことになりました。
メンバーは4人ですので、大体1ヶ月に1周するようなスパンで実施しています。
スクラムマスターの役割の1つとして、プロジェクトを円滑に進めることに責任を持つことがあるので、自分以外のチケット内容や疑問にも耳を傾け解決に注力する必要があります。
技術の違いなどで内容が難しかったりすることもありますが、メンバーの協力をいただきながら解決を目指していきます。
自分のチケットだけ追っていると周りの進捗状況や悩み事がわからなくなってしまうことがあるのでこのローテーションはプロジェクト全体を見渡すことができる良い施策であると感じております。
MTGの分割
メンバーが集まれる時間が限られており、スプリントレトロスペクティブ・スプリントレビューとスプリントプランニングをまとめて30分で行うことになっていました。
各々振り返りや次回スプリントの話をしたりデザイナーの方をお呼びしていることもあり30分だけでは終わらず時間が延びてしまうことが多かったです。
また毎日行うデイリーでも30分の時間を設けておりますが、メンバーの困っていることの解消に時間がかかり延びてしまうことがあります。
予定された時間を超過すると別のMTGがある方が退席され、全員が集まった状態での議論ができない時間が生まれてしまったり、開発時間を削る要因になっていました。
そこでデイリーでは悩みの相談に時間がかかりそうだと感じたらすぐに別途時間を設けるよう提案し、自身としても事前にどのぐらいの時間を要するかを常に考えた上で相談をしました。
振り返りの時間ではMTGが始まる前に振り返り内容を考えたりするなど、MTG外でもできることを事前にやっておくことで30分に収められるようにしました。
結果、共有すべき部分を時間内に話すことができ、全員の開発時間を削ることなくスプリントを進められるようになりました。
まとめ
まだまだ改善しなければいけない部分などたくさんありますが、現プロジェクトではすぐに修正できるところは直していき、次のプロジェクトでもこの反省点を生かしていきたいです。
また、プロジェクトの進め方などをあらかじめ第三者から確認いただくのも良いことだなと思いました。 (この記事を挙げる前に他セクションの方からのレビューをいただいたため)
We are hiring!
株式会社ドワンゴの教育事業では、一緒に未来の当たり前の教育をつくるメンバーを募集しています。 カジュアル面談も行っています。 お気軽にご連絡ください!
開発チームの取り組み、教育事業の今後については、他の記事や採用資料をご覧ください。