この記事は GMOアドマーケティング Advent Calendar 2022 14日目の記事です。

はじめに

こんにちは。GMOアドマーケティングのM.Nです。
私は元々TAXELのマネージャーとしてマネジメントや開発を行っていましたが、今年からGMOSSPのマネージャーを兼任することになりました。
経緯に関してはこちらの記事を参照してください。

GMOSSPのマネジメント

GMOSSPのマネジメントを行うことになりましたが、引き継いでから特に気になったのは以下の点でした。

どの機能がいつリリースできるのかわからない＆よく聞かれる
誰が何の開発をしているのかよくわからない＆よく聞かれる
差し込みが多すぎてタスクの優先順位がわからない

なぜこのような状態になっていたのでしょうか？

GMOSSPはハブ的な位置づけのプロダクトであるという性質上対応待ちというステータスになることが多く、1人で複数案件を持つことが多いなどの理由もありますが、チームを観察しているとあることに気が付きました。タスクの起票者とエンジニアの担当者間で開発が行われることが多く、プロダクトの責任者が進捗状況を把握できない状態になっていたのです。

このやり方は担当者間だけで開発が進んでいくため開発速度は早いものの、管理する側としては状況を把握しにくく、計画が立てにくい状態を招いていました。

この状況を改善するために、スクラムを導入することを決めました。

スクラムで目指すチームの形

スクラムにはプロダクトオーナー、開発チーム、スクラムマスターという3つの役割（ロール）が存在します。
プロダクトオーナーが責任を持ってどの機能を優先して作りたいかを決め、開発チームと相談して開発を進められるようなチームを目指しました。私はスクラムマスターとしてプロダクトオーナーと開発チームを支援する、サーバントリーダー的な立ち位置で関わるようにしました。

スクラムの準備

スクラムを始めるにあたり、以下のようなことを行いました。

スクラムに関する知識を身につける
プロダクトオーナーの選出
スクラムの運用方法を策定
スクラムチームへのファシリテーション

スクラムに関する知識を身につける

スクラム自体はなんとなく理解しており実践経験はあったものの、1から体系的に学び直しプロダクトに型通りに導入するようにしました。スクラムガイドにも「スクラムはシンプルである。まずはそのままの状態で試してほしい」と書いてあります。

具体的にはスクラムガイドや書籍を繰り返し読むことで

スクラムとは何か？
何のために実践するのか？
どのように実践するのか？

に対して理解を深めました。

プロダクトオーナーの選出

スクラムチームにはプロダクトオーナーが必要です。
プロダクトオーナーは要求や仕様、計画といった内容の作業を行うことができる人が適任です。

プロダクトのビジョンを伝える
タスクの優先順位を決定できる
決定したことに対して関係者と調整する

また、スクラムイベントに欠かさず出席でき開発チームからの質問に適宜答えられるよう、忙しすぎない人がよいとされています。そこで、プロダクトオーナーをメディアコンサルティング部のマネージャーではなくメンバーから選出することにしました。ただし、メンバーではGMOSSPについての理解が足りず意思決定が難しいケースもあるため、メディアコンサルティング部のマネージャーにはサポート役として入ってもらうようにしました。

スクラムの運用方法を策定

スクラムの成果物はプロダクトバックログ、スプリントバックログ、インクリメントの3つとされています。
GMOSSPでは元々Trelloを使ってタスクを切っており、一方で開発本部全体ではBacklogを使って進捗確認していました。
そこで、両方を満たすために

プロダクトバックログ : Trello
スプリントバックログ : Backlog

で管理するようにしました。

プロダクトバックログ

プロダクトバックログは常に欲しいもの順に並び替えを行っており、スプリントプランニングでプロダクトバックログの上から開発を行っていきます。

プロダクトバックログの上位アイテムはポイント見積もりを済ませておく必要がありますが、Trelloには「Planning Poker」というPower-Up（いわゆるプラグイン）があるため、Trello内で見積もりしてそのままカードにポイントを付けておくことができて便利です。

着手開始したタスクは「プロダクトバックログ」リストから「処理中」リストにカードを移動することで、zapierによってBacklogに自動連携され、Backlogに課題を作成するようにしました。

スプリントバックログ

スプリントバックログは、スプリント期間内に行う作業リストです。
Backlogに連携された課題に子課題を紐付け、それらをスプリントバックログとして扱うことにしました。

上図でいうと、1番上にある「処理中」のものが、TrelloのプロダクトバックログアイテムをBacklogに連携したものになり、2番目以降の赤枠内のものがスプリントバックログになります。
ポイントは子課題にのみマイルストーンを設定しておくことで、ボード機能をスプリントバックログとして使用できます。
ボードにある課題を全て完了＝スプリントのゴールになるため、スプリントのゴールが明確化できます。

バーンダウンチャート

スプリントの進捗状況はバーンダウンチャートで可視化しますが、ここで1点問題がありました。
Backlogにはバーンダウンチャートを表示する機能が備わっているのですが、全てのプロダクトが一つのBacklogプロジェクトに同居している都合上、GMOSSPだけのバーンダウンチャートを表示することができなかったのです。

そこで、BacklogのAPIを利用してGoogle Apps Script（GAS）でバーンダウンチャートを自作しました。
バーンダウンチャートは毎朝Slackに投稿することで誰でも簡単に状況を把握できるようにしました。
まれにスプリントバックログに期限が誤って登録されてしまうケースがありバーンダウンチャートが正しく機能しないことがあったため、合わせてスプリントバックログが正しく作られているかチェックし、スプレッドシートに表示するようにしました。

その他にもインクリメント受け入れのルールやスプリントのイベントスケジュール決めなど、スクラムを運用していく上で必要な仕組み作りを行いメンバーがスムーズにスクラムに移行できるように準備しました。

スクラムチームへのファシリテーション

ファシリテーションとは、日々の活動の場において、活動やプロセスをよくするためにサポートを行うことです。
具体的には以下のようなことを行いました。

スクラムのルール変更における意思決定のサポート
デイリースクラムの司会を開発チームのメンバーが交代で行うようにする
スプリントレトロスペクティブ（振り返り）でメンバーの意見を促す
スプリントの進捗についての相談を開発チームとプロダクトオーナーでするように促す
- スプリントの進捗がよく、追加のタスクを実施できそう
- 遅れすぎていてスプリントのゴールが達成できない　など

私は開発本部のマネージャーでありつつもプロダクトに対してはスクラムマスターという立ち位置なので、開発チームに対して指示を出すのではなく、プロダクトオーナーと開発チームで協力してプロダクトの開発を進めてもらうことを意識して行動しました。

結果

導入してからまだ数スプリントを消化したところですが、プロダクトの状況が可視化され、以前に比べて把握しやすくなりました。
まだまだ課題も多いですが、スクラムは柔軟なフレームワークでありプロセスを適応させていくのがとても重要です。
引き続きプロダクトに最適な形を目指して取り組んでいきたいと思います。

告知

明日はKONCEさんによる「エンジニアの「伝える」技術を考える」についてです。
引き続き、GMOアドマーケティング Advent Calendar 2022 をお楽しみください！
■学生インターン募集中！
https://note.gmo-ap.jp/n/nc42c8a60afaf
■エンジニア採用ページはこちら！
https://note.gmo-ap.jp/n/n02cbeb6edb0d
■GMOアドパートナーズ公式noteはこちら！
https://note.gmo-ap.jp/

M.N