新年あけましておめでとうございます。
Webアプリエンジニアの大橋です。
本年もOpenWork Tech Blogをよろしくお願い申し上げます。
さて、オープンワークのほとんどの開発プロジェクトではスクラム開発を導入しています。
今回は私が所属していたプロジェクトにおける課題と、工夫や改善したことを紹介します。
課題１．期限内に複数の施策をスクラムで開発するには
私のプロジェクトでは主にリリースしたい施策を3ヶ月ごとにプロジェクト目標として設定していますが、その施策の数が多いとき、どうやったら効率よくリリースできるかを考えました。
工夫①：各施策の主担当を決める
1つの施策につきプロダクトバックログの作成からリリースまではある程度の期間が必要になります。
その為、優先度の高い施策から着手するとしても、複数の施策を同時進行で進める必要があると考えました。
そこで各施策の主担当として主に、正社員エンジニアのメンバーを割り振りました。
スクラムのメリットはチームで完成させることなので、プランニングではその時点で優先度の高い施策にエンジニアリソースを多く割り当てました。
工夫②：全体的なスケジュールをひく
スプリントプランニングとは別に、いつまでに要件が決まり開発に着手できれば期限内にリリースできるかという目安のスケジューリングをしておき、リファインメントやプランニング時に順調に進んでいるかを把握できるようにしました。
課題２．施策の優先順位が変わる/要件が決まらない
プロダクトバックログをまず準備しないとプランニングができません。
そしてプロダクトバックログを用意するには、プロダクトオーナーと要件を決める必要があります。
また、3ヶ月の中でも施策の優先順位が度々変わったり、要件がなかなか決まらないと、エンジニアが手持無沙汰になってしまいます。
工夫①：スプリント期間を2週間から1週間に
2週間分のバックログを用意するよりも、1週間分のバックログを用意するほうが楽です。
1週間ごとにリファインメントとプランニングをするので急な優先度変更にも対応しやすいのです。
また、1週間で終わらせるためにプロダクトバックログをできるだけ小さくする意識ができました。
工夫②：プランニングの3日前にリファインメントを行う
以前はリファインメントを必須としていませんでしたが、プランニングの3日前、つまり前のスプリント中にリファインメントの予定を定例で入れるようにしました。
そこでプロダクトオーナーと各施策の優先順位と、優先度の高い施策の要件を確認しました。
工夫③：プランニングポーカーにプロダクトオーナーも参加する
以前はエンジニアだけでプランニングポーカーを行っていたのですが、途中からプロダクトオーナーも参加してもらうことにしました。
その場でプロダクトオーナーと疑問点や詳細な仕様を決めたり、その場でスコープ調整を行えたのが特に良かったです。
また、どんなことが工数負荷になるのかをプロダクトオーナーにも理解してもらうきっかけにもなったと思います。
工夫④：改善タスクのバックログを用意する
エンジニアだけで対応可能な改善タスクをプロダクトバックログとして用意しておき、エンジニアのリソースが余りそうなときは、これらをプランニングして対応することができました。
課題３．効率的なスプリントレビューのやり方とは？
プロジェクトメンバー全員とステークホルダーを招待してスプリントレビューを行っていますが、スプリントレビューの内容や進め方についてステークホルダーから意見をもらうことがありました。
振り返りの議題としてもあげて少しずつ改善をしました。
改善①：プロダクトオーナーからも各施策の目的やリリース後の数値を共有
スプリントレビューではエンジニアが成果物のデモをしながら説明するのをメインにしていましたが、プロダクトオーナーからも各施策の目的を簡単に説明してもらったり、既にリリースした施策の数値を共有してもらい、効果と課題を確認するようにしました。
改善②：デモは簡潔に
エンジニア以外のメンバーからは、デモではなくスクリーンショットでもいいのでは？という意見もありましたが、スプリントレビューではやはり実際に開発したものを見せるべきだと私は思います。
そこでデモでは重要な部分を簡潔に見せ、細かいことは口頭での説明に留めるなど冗長にならないように気を付けました。
改善③：スプリントレビューも時間を短縮して毎週に
隔週で1時間とっていたスプリントレビューの時間を30分にして毎週に変更しました。
1回のレビューは簡潔に、レビューの機会は多くなったので効率がよくなりました。
改善④：フィードバックの結論を出す
スプリントレビューの中でステークホルダーからフィードバックをもらった場合、時間が余っていればその場で議論することもありますが、時間内に結論が出ずに方針が曖昧な状態で終わってしまうこともありました。
そのようなときはスプリントレビュー後にプロジェクトメンバーだけでもう一度集まり、方針ややるべきこと、リリース計画の認識合わせと決定をしました。
要望にすべて対応することでリリース予定が延びるのであれば、リリース日までにmust（やるべき）なのかmore（できたらいいな）なのかを切り分けるようにしました。
スクラム開発をして良かったこと
エンジニアが主体となってリリース計画を立てたり、開発フローを改善しやすいことです。
状況の変化に応じて軌道修正していくことができたと思います。
しかし、エンジニアだけではスクラム開発は成功しません。
プロダクトオーナーや他のメンバーも巻き込んで協力し合うことで、常に向上し続けるチームを作ることができると思います。
オープンワークでは他のチームもスクラム開発を導入しています。 techblog.openwork.co.jp techblog.openwork.co.jp
アジャイル開発、スクラム開発に興味のある方は、オープンワークの採用情報もぜひご確認してください。
www.openwork.co.jp
