株式会社ブックリスタ プロダクト開発部の開発・運用を担当している片山と申します。
今回は、弊社が包括的なパートナーシップを結び開発を行なっている「auブックパス （運営：KDDI株式会社）」のストア開発におけるスクラムについて記載させていただきます。
本記事はauブックパスのストア開発でのスクラムについての説明であり、純粋なスクラムとしては正しくない内容が含まれている可能性がありますので、ご注意ください。
また、本記事は筆者が開発者であるため、開発者が参加するイベントのみに絞り込んで記載しており、開発者が参加しないイベントについては記載しておりません。
開発に集中できる仕組み
auブックパスのストア開発におけるスクラムは、開発者が開発に集中できる仕組みとなっています。
以下は、1スプリントの開発者の大まかな時間割です。
図を見ていただいて分かる通り、開発者は自分の時間の大部分を開発に使用することが出来ます。
また、スクラムとしては当然なのですが、開発者は2週間のスプリントで実施する作業をスプリントプランニングで明確にします。作業の優先度も必ず決めます。そのため、自分が何をすればよいか迷うことはありません。
メンバー紹介
スクラムチームのメンバーは以下のようになっております。（通常のスクラムとは違うメンバー構成です）
- プロダクトマネージャー
- マーケティング戦略に則ったプロダクト改善の立案
- プロジェクトマネージャーと連携した各ステークスホルダーとの調整
- リリース後の効果検証のリード
- プロジェクトマネージャー
- プロダクトとチームを管理
- プロダクトマネージャーと連携した各ステークスホルダーとの調整
- 参考 https://techblog.booklista.co.jp/entry/2023/02/15/103822
- 開発者
- ブロダクトゴールを実現するたための開発（設計・実装・テスト）
- プロダクトの運用
- インフラ担当者
- AWSにおけるインフラの設計・構築
- プロダクトの運用
- QA担当者
- テストの計画・実施
- 開発者に対する品質面のレビュー
- スクラムマスター
- MTGのファシリテート
- プロセスの監視・改善
スクラムの内容
朝会
毎朝10時30分から30分間だけ朝会を実施します。 朝会にはプロジェクトマネージャー、開発者、インフラ担当者、QA担当者、スクラムマスターが参加します。
プロジェクトマネージャーを除く参加者全員が前日やったこと、本日やること、今問題になっていることを報告し、情報共有します。
報告はだいたいいつも15分程度で完了し、残り15分は雑談をしています。趣味の話など仕事には関係のない会話が多いです。auブックパスのチームは全員がリモートで仕事していることが多いため、朝会の雑談は、チームワークを維持するための貴重な時間となっています。
スプリントプランニング
スプリントプランニングは、次回スプリントで各担当者が実施する作業を決める MTG です。 プロジェクトマネージャー、開発者、インフラ担当者、QA担当者、スクラムマスターが参加します。
スプリントプランニングを始める前までに、以下の作業を実施しておきます。
- バックログの優先順位付
- チケット管理ツール Jira を使用
- プロジェクトを要求管理用と開発用に分けており、プロダクトマネージャーが要求管理用プロジェクトで付けた優先順位を元に、プロジェクトマネージャーが開発用プロジェクトの優先順位を決める
- ストーリーポイントの算定
- プランニングポーカーを用いて、開発者全員で見積もる
auブックパスのスプリントプランニングは2回に分けて実施します。スプリントを開始する4日前の月曜日にスプリントプランニング1を実施します。2日前の木曜日にスプリントプランニング2を実施します。
スプリントプランニング1では、優先度の高い順番にチケットの担当を決めます。チケットの優先度が付いていることは非常に重要で、開発者は自分が担当している未完了のチケットの中で一番優先度が高いチケットを集中して作業できるようになります。
また、チケットの担当者の割り当ては、できる限り希望者を優先して割り当てるようにしています。自分が希望したチケットを作業する方が、誰かが決めたチケットの作業をするよりもモチベーションが上がります。
スプリントプランニング1と2の間で開発者は、自分が担当となったチケットをサブタスクに分割し、作業時間を見積もります。ここで重要なのは、各チケットに対するサブタスクの洗い出しになります。出来る限り粒度の細かいサブタスクに分割することで、見積もりが正確になり、かつ、作業進捗も分かりやすくなります。
スプリントプランニング2では、各担当者のチケットにおける見積もり時間を確認し、次回スプリントで実施可能かどうかを判断します。見積もり時間が多い場合は、チケットを分割したり、チケットをバックログへ戻すなどして調整します。見積もり時間が少ない場合は、バックログにあるチケットを新たに割り当てます。
開発
ある程度の規模の開発であれば、設計、テスト仕様書作成、実装、テスト実施の順番に作業します。１スプリントで収まらない開発である場合は、それぞれの工程を別々のスプリントで実施することもあります。
設計
設計書は Confluence と Google Sheets で記載することが多いです。
書き方は決めておらず、各開発者が好きな書き方で設計書を書いています。
そして、設計書は必ず他メンバーがレビューします。レビューすることで、担当者が気づかない問題を実装前に気づくことがよくあり、手戻りを防ぐことが出来ています。
テスト仕様書作成
テスト仕様書を実装前に記載することで、実装するプログラムのインプットとアウトプットを明確化します。
設計書と同様にテスト仕様書もレビューすることで、手戻りを防ぐことが出来ています。
以前は、テスト内容が十分でなく、不具合をリリースしてしまうことがありました。そこで、どの画面・機能で何を確認するべきかのテスト観点を資料化することで、全ての開発者が十分な品質を保証できるテスト仕様書を作成できるようになりました。
実装
テストファースト
可能な限りテストファーストで、Unit テストを実装するルールとしています。ただ、UI 部分など Unit テストが十分に実装できていない箇所があり、今後の課題となっています。
Linter、Formatter
Linter にて事前に分かる問題は自動で検出するようにし、Formatter にてコードのスタイルは自動で統一するようにしています。
CI/CD
GitHub でプルリクを作成したときに、 ビルド、Unit テスト、Linter を実行し、問題がない場合のみマージできるようにしています。これがあるおかげで、コードレビューの手間がかなり削減されています。
GitHub のプルリクをマージすると、AWS CodePipeline にて、自動で開発環境・ステージング環境にリリースされ、ステークホルダーがすぐに確認できるようになっています。
コードレビュー
GitHub のプルリクでは、最低一人の reviewer から approve が出ないとマージ出来ないルールとしています。
reviewer の選択は、GitHub の Code review assignment を使用し、各開発者が均等にレビュー担当となります。これにより、実装内容がバランスよく情報共有されています。
テスト実施
事前に作成しておいたテスト仕様書に従ってテストを実施します。
開発規模がある程度大きい場合は、開発者がテストを実施した後に、QA 担当者がさらにテストを実施することで、品質を保証するようにしています。
リリース
リリースは master ブランチにマージして、 AWS CodePipeline にて承認ボタンをクリックするだけで出来るように単純化されています。
ただし、一部のサービスは Jenkins を使用したリリースとなっております。Jenkins でも画面からいくつかの項目を入力して実行するだけなので、難しくはありません。
スプリントレトロスペクティブ
スプリントレトロスペクティブは終了したスプリントの反省会のようなものです。 スプリントレトロスペクティブには、プロジェクトマネージャー、開発者、インフラ担当者、QA担当者、スクラムマスターが参加します。
スプリントレトロスペクティブでは以下について、話し合います。
- 各自の振り返り
- ベロシティの推移の確認
- 次回スプリントの改善目標
各自の振り返りでは、各自が個人、相互作用、プロセス、ツールに関して検査し、うまくいったこと・うまくいかなかったことを発表します。そして、うまくいかなかったことに関しては改善点をみんなで考え、うまくいったことに関してはみんなが真似できるように情報共有します。
ベロシティの推移の確認では、過去6回のスプリントと今回のスプリントのコミットメント1と完了2比較し、今回のベロシティが過去に比べてどうだったかを確認します。ベロシティの結果が過去と大きく異なる場合は、原因と対策を話合います。
スプリントレトロスペクティブの最後に、次回スプリントの改善目標をまとめます。
ナレッジ共有会
ナレッジ共有会はスクラムには関係のないイベントです。
参加は任意参加として、時間に余裕のあるメンバーのみが参加します。
開発者各自がauブックパスサービスに関わる知識、もしくは、システム開発に関わる知識を共有するための MTG です。
例えば、最近のナレッジ共有会では、以下のような知識を共有しました。
- RDS のバックアップ
- RDS の認証方法
- Lambda の Layer
- OpenVPN
- トイルについて
- jest の spyOn
- 冪等性について
- 書籍「はじめて学ぶソフトウェアのテスト技法」
- auブックパスのアクセスログについて
用意する資料は箇条書きの簡単な文章程度で、資料作成など事前準備に時間をかけることはありません。
まとめ
以上は、2023年3月末時点のauブックパスのストア開発におけるスクラムです。
auブックパスのストア開発の今の体制が出来て2年半が経過しました。2年半の間に色々試行錯誤することで、記載したような開発方法となりました。この方法は、開発者中心の方法となっており、開発者が開発に集中出来る環境であると自負しています。
