![見出し画像](https://assets.st-note.com/production/uploads/images/92445465/rectangle_large_type_2_046d265d69efc4ab7a88d8c4ab416291.png?width=1200)
Backlogを用いたスクラム開発のススメ
この記事は #Backlogアドベントカレンダー2022 by #JBUG の12月13日分の記事として執筆しています。
株式会社カンリーエンジニア部の須藤です。
私の所属するCanlyホームページ開発チームでは、アジャイル開発の手法の一つであるスクラムでの開発を実施しております。私は、チームではスクラムマスターをやらせていただいています。
プロジェクト管理ツールとしてBacklogを導入しているので、本日はBacklogを使ってどのようにスクラムを運用しているかを紹介します。
こちらが完成形ではないと思いますが、スクラム開発をしているチーム、または導入予定のチームでの運用の参考になれば幸いです。
スクラムについては詳しい紹介記事が他にありますので、紹介は割愛させていただきます。ご興味のある方は、スクラムガイドから入られるのがいいかと思います。
Canlyホームページとは
![](https://assets.st-note.com/img/1669877688979-HLuVak2e84.png?width=1200)
サービスについては、こちらのページで紹介させていただいております。
簡単に説明すると、Canlyホームページとは、店舗検索ページの情報更新を簡単にできるシステムです。スクラッチで開発する場合と比べて、短期間で簡単に導入と立ち上げが可能で、Canly(弊社主サービス)と連携しているため、店舗詳細ページにおいての様々な施策打つことができるサービスとなっております。
Canlyホームページ開発チームでは、「店舗に関わる全ての人に、
最も信頼されるCMS+SEOツールとなる」をチームMissionとして掲げ、サービスの機能開発、改善に努めています。
チーム体制/スクラムルール
![](https://assets.st-note.com/img/1669878573335-nR1J0RPiXK.png?width=1200)
Canlyホームページチームの開発体制とスクラム運用ルールについて簡単に紹介します。
チーム体制
2022年12月現在は下記のチーム体制で活動しています。
PdM:1名
スクラムマスター:1名
開発リーダー(テックリード):1名
開発者:5名
QA:2名
上記が基本的にスクラムチームを構成するメンバーで、上記以外にインフラチーム、デザイナー、アーキテクトと協力しながら日々活動しています。
スクラムルール
現在は、2週間スプリントで運用しています。
2021年の11月頃からスクラムガイドをベースとしてスクラム開発を導入し、Canlyの体制や開発チームに合う形にカスタマイズしながら日々改善しています。スクラムガイドをベースにはしているものの開発リーダーがいたり、イベントも少しスクラムガイドのものとは変えていたりします。あくまでMissionを達成することを目標としているので、敢えて合わせていないものがあります。
スクラムイベント
現在のCanlyホームページで実施しているスクラムイベントは下記にあげたものになります。
スプリントプランニング
スプリントの初日に実施します。本スプリントの計画をチームで決めます。
デイリースクラム
毎日11時から15分を目安に実施しています。簡単な個人的ニュースの紹介、共有事項の連携、やったこと、今日やること、困っていること、相談などを実施しています。
リファインメント
毎週実施します。スクラムガイドにおけるリファインメントとは別で、PdMより開発チームへPBIの仕様について説明し、議論する会です。アーキテクト及びデザイナーも参加します。
プレスプリントプランニング
スクラムガイドにおけるリファインメントに当たるイベントです。現在は、PdM、スクラムマスター、テックリードの3名で議論してスプリントプランニングの叩き台を作成しています。
クオリティチェック
開発チーム内におけるスプリントレビューです。現在は、開発者の代表からPdMに向けてレビューをする会となっています。こちらにはデザイナーも参加します。
スプリントレビュー
社内向けにスプリントの成果を報告します。
レトロスペクティブ
スプリントの最後に実施しています。KPT感謝のフレームワークを利用して振り返りを行い、次のスプリントで取り組んでいく課題を設定していきます。メンバーからの提案で、Problemを提案する際には、合わせてTryも提案するという形式を導入しており、問題提起で終わらず改善案の議論ができています。
プロジェクト/チケットの運用
前段が長くなりましたが、今回はBacklogのアドベントカレンダーということなのでBacklogを用いてスクラム運用しているポイントについて紹介したいと思います。
課題管理のルール
運用の基本方針としては、細かいルールはあまり作らずチケット更新がPdMや開発者の負担にならないようにし、きちんと運用できることを目指しています。
プロジェクト
まずプロジェクトですが、自チームのもののみにしています。元々、横断的に連携しやすいように他のプロダクトチームとも同じプロジェクトを使用していたのですが、ダッシュボードにチームと関係が薄い情報が多数上がってきてしまうようになり、見づらい、使いにくいという意見がメンバーからレトロスペクティブで多数上がったため、現在は自チームのみのプロジェクトとしています。
スプリント
スプリントの管理については、「発生バージョン/マイルストーン」を利用しています。
![](https://assets.st-note.com/img/1669944731312-mCTbFW1xqC.png?width=1200)
プレプランニングの際に、チケットにマイルストーンを入れておき、プランニング内で確定する運用としています。
課題の状態について
課題の状態については以下の6種類で管理しています。
![](https://assets.st-note.com/img/1669944968929-x3suxfQ7i4.png?width=1200)
状態の定義については、以下の意味合いで運用しています。
未対応:未対応
処理中:課題の処理中。必ず担当者がついている状態。
処理済み:コードレビュー(PRレビュー)待ちの状態
コードレビュー済み:コードレビュー(PRレビュー)が終わっている状態
保留:保留
完了:リリース済みの状態
課題の作成ルール
タイトルと記載内容に漏れがないようにテンプレートを用意しています。
PBIにあたるチケットは、タイトルに【親】のPrefixをつけるようにして、FrontやAPIのタスクを分割する場合には親の子チケットとして作成するようにしています。
内容については見出しを用意しておき、記載漏れがないようにしています。完了条件=受け入れ条件となるので、現在はPdM以外のメンバーが親チケットを作成する場合はPdMがチェックし、承認する運用としています。
![](https://assets.st-note.com/img/1669946949835-wB9Z3hw4OR.png?width=1200)
Backlogの機能利用シーン例
デイリースクラム
デイリースクラムにおいてやったこと、今日やることを報告する際にBacklogのガントチャートを画面共有しながら実施しています。
他のメンバーのタスク状況がわかるようにしています。またマイルストーンでSprintを設定しているので画面上でも分かるようになっている点が嬉しいところです。
※個人情報やお客様名が入っているので画像はマスキングしています
![](https://assets.st-note.com/img/1670227763686-es5SRMKLR0.png?width=1200)
他ツールについて
ここまでBacklog中心に説明してきましたが、プロジェクト運営で使用している他の主なツールについて紹介します。
Notion
Backlogの導入前からWiki、議事録、タスク管理ツールとして利用していました。現在も引き続き利用しており、Wiki、議事録管理ツールとして利用しています。
少し別件にはなりますが、Canlyホームページでは全ての会議で議事録の準備を徹底しています。
事前にテーマを記載した議事録を参加メンバーで確認し、議事録でのやりとりで完結することで打ち合わせ自体が中止となる場合もあります。
この議事録はNotionで作成しており、管理しやすいようにページをカスタマイズしています。
Canlyホームページチームでは「Developers Summit 2022」で、GitLab社伊藤俊廷氏が発表された「GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック」内での「コミュニケーション手段の使い分け」という点を参考にしています。
GitHub
ご存知GitHubです。Canlyホームページチームでは、Backlogの導入前からGitHubでコード管理を行なっています。
BacklogとのGitHubの連携がわかりにくいという課題がレトロスペクティブで上がり、GitHub Actionsを利用して特定キーが含まれたコミットがプッシュされた際にBacklogのチケットにコメント通知する仕組みを導入しました。
まとめ
CanlyホームページでのBacklogを用いたスクラム開発について紹介させていただきましたが、いかがでしたでしょうか。
プロジェクト管理ツールは他にもありますが、Backlogの利点としてUIが直感的でエンジニアでなくても使いやすいというのが良い点だと思っています。弊社では、ディレクターやCSも使用しているのでその点マッチしていると感じています。
また弊社では、Wikiやバージョン管理は別ツールを元々導入しており、ノウハウが溜まっているので移行はしておりませんが、この辺りも全てBacklogで賄うことができるというのも大きなメリットではないかと考えています。
最後に
株式会社カンリーでは一緒に働く仲間を募集しています!
カンリーのバリューに共感できる方、ちょっと話聞いてみたいという方、ぜひご応募ください!
この記事が気に入ったらサポートをしてみませんか?