株式会社ブックリスタ プロダクト開発部の藤井です。 現在、2023年8月1日から始まった「コミックROLLY（運営：株式会社ソニー・ミュージックエンタテインメント）」というサービスのスクラムマスターをしております。
今回は新サービスプロジェクトを立ち上げるにあたって、スクラム開発を採用した話をさせていただきます。
近年ソフトウェア開発の現場でスクラムを採用するケースをよく聞きます。
これから採用する方・採用してるけど暗中模索してる方の参考になればと考えています。
あと、このやり方は専門のひとにはスクラムじゃないと言われるものではあるかなと自覚もしているので、その様な場合、改善の意見を私まで指摘を届けていただけたら嬉しいです。
なぜスクラムを選んだのか
今回新規プロジェクトを始めるに当たって開発手法も特にきまっておらず、 課題としては次の様なことが挙げられました。
- 初めてのZEROからプロジェクトで具体的なイメージが決まりきっていない
- 開発期間が約一年程度しかない
この状態では完全な要件定義は難しく、暫定のまま進めてユーザーテストを実施した後に再度要望を吸い上げて修正する期間を取ることも難しいと考えました。
そのため以下の様な効果が得られることを期待してスクラム開発をとり入れてみようとなりました。
- 短期間で細かな要求・要望に対してのリリース可能な成果物を作成可能
- 進捗状況の把握がしやすい
- 要求・要望が変わった場合に柔軟に対応ができる
スクラムイベントと期間について
今回私達は水曜日を始まりとした2週間スプリントで実施しました。
水曜日始まりにしたのは「月曜日と金曜日は休みな事も多いので余裕ある方が良いよね」といった考えによるものです。
参考にどんなスケジュールだったのかもあげておきます。
スクラムイベントについては参考書等に記載があるのでここでは細かく記載しません。
スクラム導入して良かったこと
スプリント完了タイミングで常に現在の完成品を見せられる
これはベストプラクティスだったなと感じました。
特にスプリント毎に機能を見せることができるため、徐々にシステムが完成していくことで業務側からのフィードバックが即時受け取れる状態を作れたのがよかったです。
実際に触って動かせる成果物があることで、「必要だった物」とのギャップを即時に確認でき新たな要望として積み上げることが容易でした。
成果物に対して褒めていただける反響もたくさんありモチベーションアップにも繋がりました。
また、ローンチ直前に外部テストベンダーを使ったアドホックテストも実施したのですがテストベンダーさんからもバグ数が少ないという評価を頂くことができました。
すべての開発サイクルに関わることができる
スクラムのスプリントでは、要件定義、設計、実装、テスト、リリースなどの一連の工程をメンバーが実行していくことになります。
そのため、経験の少ないメンバーも自ずとやったことのない工程を体験していくことになりました。
そういった経験を積むことでメンバーから「今まではサービスとしてどうすべきかをあまり考えたことがなかったが、考えることができた」という発言をもらった際はとても嬉しくなりました。
また、リファインメントでも最初期は発言するメンバーが固定化されており、どうしても経験が浅いメンバーの発言が少ない傾向にありましたが、徐々にその傾向も少なくなってきました。
発言の少なかったメンバーが率先して発言したり、質問をしてくれる様になっていきました。
スクラム導入して見えた課題
全体像の把握とスケジュール管理が難しい
そもそも開発したいことの全量が決まっていなかった初期は、プロジェクト全体としてどれくらい進んでいるのかどうかなどは把握できていませんでした。
また、全量が出てもローンチまでの期間が決まっているので開発したいもの全てが入っているプロダクトバックログのみではローンチまでの作業のみを絞り込んで管理できませんでした。
その結果、別途管理表を作成しローンチまでに消化すべきポイントのみに焦点を当てて管理をしていましたが、ローンチまでに必須なものとそうじゃないものの区別がメンバーには把握できずらいものになっていました。
数値のみの消化をメンバーに共有していたこともあり、ローンチまでに完了が本当にされるのかメンバーに不安を与えるとともにスプリント以外の期限を意識させてしまいました。
ただ実際プロジェクトローンチはお尻があるものなので、この辺りどうしたらよかったかは今後のために考えていかないとなと思っています。
スプリントレビューにステークホルダーが参加できない
これはエンジニアリングだけの問題ではないのですが、ステークホルダーの方達が専任ではないためスクラムイベント関連に出席ができてませんでした。
結果、定期的にスプリントレビューのタイミングで複数のスプリントをまとめた総合レビューを挟むことになりました。
当然そこで初めて触る方も出てくるので、色々な意見が出てきて他の優先事項を処理するため後回しになってしまった改修も発生してしまいました。
ここはスクラムを行う時にステークホルダーを含めて定期的な時間をとってもらう様にすべきであるという事を強く学べました。
チーム内、コミュニケーションの難しさ
よくあることですが、今回のチームは今まで存在していたチームではなく他チームから集められたかつ、ここ数年でエンジニアを積極採用していたのもあり特に社歴の長い人が少ない状態です。
ちなみにこの時私は入社して半年たったくらいでした。つまり、皆さんほぼ初見。
どんな人なのか、どんなスキルを持っているのかは不明の状態でした。
そこでスクラムイベントとは別に問題を解決するための会議や知識共有を目的とした会議の設定をしました。
これらの会議自体は機能しているのですが、まだまだチームとして自然な状態にはなっていないかなと感じています。
この問題は徐々に改善していっていますが、これぞといった解決策が取れていない状態です。
リファインメントがすごく難しい
リファインメントは大きな問題がたくさんありました。
分割する大きさがまちまち
プロダクトバックログアイテムがより小さく詳細になるように分割および定義していくことが必要だと考えています。
その中で、透明度が高い要望は小さく詳細なチケットができるのですが、不透明な案件は分解できずに大きなチケットのまま実施することになってしまいました。
その結果、大きなチケットに関してはスプリント期間に完了しなかったり、実作業時間が見積より小さくなることが頻発しました。
評価がどうしても絶対評価になりがち
事前にストーリーポイントで見積をし、見積数値は相対見積で求めることを決めていましたが、経験上から絶対見積をしてしまうことが多かったです。
「絶対見積＝自分ならこれぐらいでできる」というものになるため、作業する人が固定化されてしまったりすることもありました。
発言者の偏りが生じる
経験豊富なメンバーが主導して話すことがおおく、控えめなメンバーの意見が埋もれがちになっていました。
空気的にも経験者が言うなら特にないと言った雰囲気もでており、質問などの発言も初期の頃は少なかったと記憶しております。
会話が発散してしまう
チーム全員のスキルレベルが同じ状態ではないので、リファインメント対象の要件を話している際にどこまですべきかどこまで考えなければいけないかよくブレていました。
考えることや話あうこと自体は間違いではないですが、1時間のリファインメント時間で1つの要件しか見積できないということがよく発生していました。
改善について
これらの課題は解消してきているものもあれば、まだ継続して発生している課題もあります。
現在は「会話が発散してしまう」に対してスケジュールに載せているリファインメント時間以外にも個人で事前にチェックする時間を設けています。
そうすることで、一度は目を通して方向性を考えることで発散しすぎる事を解消できるのではと考えています。
ローンチが完了してみて
この度2023年8月1日にAndroid、iOSに向けてコミックROLLYは無事ローンチされました。
大体開発プロジェクト自体が2022年4月から開始、エンジニアが2022年6月ごろから徐々に集まり始めたことを考えても約1年ぐらいでの開発期間で開発できたのは驚きでした。
特に感じたことは今までのプロジェクトより終盤に向けての絶望感がかなり少なかったです。
なぜなのかと振り返ってみると、やはり常にできた成果物を第三者が確認できる状態を作れていたことが大きいのかなと。
ウォーターフォール型で開発してる場合は、開発終盤になっても第三者に見てもらうことは基本なく最終のユーザーテストや受け入れテストに入った段階で初めて意見の収集ができます。
そのため、規模が大きい場合はフィードバックによる修正の大きさがそのままプロジェクトの遅れにつながることが多く怖かったのですが今回はその心配がそこまでなかったからでした。
重ねてになりますが、1つの事例として迷えるプロジェクト管理者さんに届けば幸いです。
