Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

個人ベース・ビジネスドリブンのチームにスクラム導入して1年が経ったので振り返る

自己紹介

Retty Advent Calendar 22日目の記事です。

昨日の記事は、平野さんのRetty データ分析チーム 2020年の振り返り - 意思決定支援/分析民主化/データ基盤/MLでした。

Rettyの広告コンテンツ部門エンジニアの堤です。
昨年まではバックエンド開発をメインで行っていましたが、今年はチームへのスクラム導入がメインの取り組みでした。

スクラムはおろかチーム開発経験すらほとんどなかった僕が、手探りと手助けを頼りにチームにスクラムを導入した苦労話と学びを綴ります。
他の人がスクラムを導入するときの参考になれば幸いです。

対象読者

  • これからスクラムを導入する人・導入を検討している人
  • スクラム自体の説明はしないため、この記事を読んでスクラムを学ぶことはできません

TL;DR

  • 個人ごとに開発担当が分かれていたチームへのスクラム導入事例
  • ビジネスドリブンな部門でのスクラム導入の難しさ
  • 開発チーム以外のスクラム思想への巻き込みはまだまだ課題

用語説明

本文の用語について、略語や補足を簡単に書いておきます。

  • スプリント: 弊チームでは最初から最後まで1週間
  • プロダクト: 時期によるが、部門で大小5~6個のプロダクトの開発・運用を行っている
  • PBI: プロダクトバックログアイテム
  • PO: プロダクトオーナー
  • SP: ストーリーポイント。現在は3人チームで20pt/sprint前後

導入背景

スクラム導入の話にあたり、背景情報として

  • 導入を行ったチームの説明
  • 当時のチームの課題

を簡単に記します。

導入対象のチームについて

僕が所属し、今回スクラムを導入したのは、 「広告コンテンツ部門開発チーム」です。
以下、

  • 弊部門 => 広告コンテンツ部門
  • 弊チーム => 広告コンテンツ部門開発チーム

のことを指します。

弊部門は、「Retty」というメディアを開発しているプロダクト部門とは別で、toBのプロダクトによって収益を追う部門となっています。
よければ、 Rettyマネタイズを支える広告コンテンツ (2020年振り返り) もご参照ください。

弊部門の特徴として、上の記事にもありますが、

営業がクライアントに提案を行い、フィードバックを商品企画に反映し、開発が商品開発を行う、といったものです。

と、営業提案を元に商品開発を行うビジネスドリブンな性質となっています。

開発メンバーは、スクラム導入当時4人、途中6人、現在3人の小規模チームです。
弊チームが管理しているプロダクトは、規模は小さいですが複数(時期によるが5~6)あります。
スクラム導入以前は、開発メンバーのそれぞれが別々のプロダクト開発・保守・運用を担当していました。

当時の開発チームの課題

当時のチーム構成や開発フローは定着したものであり、回っていました。
ただ、当時大規模スクラムであるLeSSを導入して定着しつつあったプロダクト部門と比較したときに、下記の課題を個人的に感じていました。

  • なんとなく開発に追われて常に忙しく、余裕がない
    • 実際のキャパがわからないので、キャパオーバーの開発項目が降っている?
  • 開発項目の優先順位がわからない
    • 「これ急ぎだからやっておいて」という差し込みが良く起こり、結局全部の優先順位が最高になる
    • 各プロダクトごとビジネス側からダイレクトに依頼が来ることが多く、統括的な優先度を調整する人がいなかった
  • プロダクトごとにリソースが一人で固定化されており、他プロダクトとのリソース調整が(すぐには)難しい

スクラム導入

きっかけ・スクラムへの期待

LeSSを導入したプロダクト部門での導入成功を見て興味を持ち、スクラムについて調べると、弊チームの課題も解決できるのでは、と考えて導入する運びとなりました。
当時読んだのはこちら: アジャイルサムライ

スクラムを調査するにあたり、弊チームの下記の課題を解決してくれることを期待しました。

  • なんとなく開発に追われて常に忙しく、余裕がない
    • ストーリーポイントの導入によりチームのキャパシティを可視化し、適切な量の開発項目を開発チームが持つ
  • 開発項目の優先順位がわからない
    • プロダクトバックログの導入により、明確な優先順位のもと最優先の開発項目から順番にこなす
  • プロダクトごとにリソースが一人で固定化されており、他プロダクトとのリソース調整が(すぐには)難しい
    • 各メンバーが様々な開発内容に対応できるようになることで、必要な箇所に必要なときにメンバーを割り当てることができる

2020年の年明けに、チームにスクラムを導入したい旨とそのメリットについて説明すると、マネージャーがOKしてくれたので、導入を進めることにしました。
理由さえあればチャレンジが許容されるのは、うちの部門(会社)の良い持ち味だと思います。

また、プロダクト部門へのLeSS導入を主導した常松さんにコーチとして相談に乗ってもらえることとなりました。

導入開始

初期導入にあたり、行ったのは下記でした。

  • プロダクト開発に携わる関係者への説得・理解
  • ルールの策定
  • 現状・直近の開発項目の洗い出し(ユーザーストーリーマッピング)

1月頭くらいに相談してから、これらが完了してスクラムが走り出したのは2月の頭でした。

関係者への説得・説明

まずは関係者への説得・説明を行いました。 主に行ったこととしては、

  • 1月前半: 事前告知
  • 1月中旬
    • 開発メンバーへの説明会
    • プロダクトオーナーの決定とお願い
    • ビジネスメンバーへの説明会
  • 導入成否を決める評価指標の話

となります。

依頼側・開発側ともに既存業務への変更・追加を加える負担が発生するため、

  • 今回スクラムを入れる理由
  • 各自の動きが今までとどう変わるのか

については積極的に行いました。
特にビジネスメンバーには、あるプロダクトのスケジュールが別のプロダクトのスケジュールに影響を与えるケースが増えるという大きな変更がありました。これに関しては、プロダクト単位では悪影響だが、部門全体のリソース最適化につながるというメリットをもとに説明しました。

また撤退ラインとして、1ヶ月入れて試してみて、効果がなければ今までの方式に戻すということで合意しました。
スクラムの1ヶ月の評価としては、最初はベロシティの計測も考えていました。 ただ、常松さんより「導入初期はむしろ開発速度が下がることは前提、かつ初期のベロシティの精度は安定しない」との話をもらい、1ヶ月後は定量的な指標ではなく、定性的に「開発がスムーズに回っているか・チームの健康状態」を関係者でチェックすることにしました。

ルールの策定

スクラム導入にあたって、主に2つの観点からルールを作成しました。

  • チーム固有のルール
    • 例:
      • 今取り入れるスクラムのルール・後で取り入れるルールはどうするか
      • 突然緊急の依頼が入った場合の連絡をどうするか
  • 基本的なスクラムルール
    • 例:
      • スプリントの長さ
      • スクラムイベントスケジュール
      • 各自の責任範囲の明確化
      • 役割・連絡フロー

全ての項目を想定することは難しく、ルールの抜け漏れは発生してしまうため、必要に応じて細かいルールは追加・変更するということは予め関係者に了承してもらいました。

現状・直近の開発項目洗い出し

プロダクトバックログの初版を作るため、開発・ビジネスメンバーを集めた開発項目の整理を行いました。
開発メンバーそれぞれが抱えている開発項目と、ビジネスメンバーが直近で必要な機能・商品を持ち寄り、ホワイトボードと付箋を用いて貼り出しました。

縦軸を優先度、横軸をコストとした2次元にマッピングし、その中から直近1スプリントで取り組むべき項目を選定しました。 また、定期・不定期で発生する運用項目も別軸でリストアップしました。

f:id:rettydev:20201222103336j:plain
ホワイトボードと付箋で開発項目を整理

そして、その後は優先度1次元のプロダクトバックログに落とし込み、スクラムでの取り組みが開始しました。

もちろんこの時点でのリストアップがすべて正確だったわけではありませんが、その後スクラムを進めつつ都度修正を加えることで対応しました。

これまでは、自分の担当箇所以外の開発項目が見えていなかったのはもちろん、開発者個人でも漠然と抱えていた技術負債など、明文化されていなかった項目を洗い出すことができました。

実際の導入と苦労

実際の導入にあたっては、下記の苦労がありました。

  • 今までのルール・フローとの兼ね合い
  • ルールの定期的見直し

今までのルール・フローとの兼ね合い

今までのチームのフローを一気に全部変えることは難しいため、いくつかチーム独自の許容ルールを追加しました。
特に初期は営業メンバーがPOに相当する役割を兼ねるケースもあったため、今までの依頼フローからの変更がなるべく少なく済むように調整しました。

例えば、

  • 突然優先度の高いPBIが入ること(差し込み)の許容
  • プロダクトが複数あったため、開発チームに対してPO(に相当するメンバー)が複数存在すること

といった、既存の依頼フローを汲むものです。

これにより、ビジネス側からの既存の依頼フロー・タイミングを徐々に新しい依頼フローに持っていくことができました。

ルールの定期的見直し

今までチームに存在しなかったルールであったことや、完全にかっちりとしたルールを定めていたわけではないため、想定しない動きで苦労することもありました。 最初から完全なルールを敷くことはできないため、

  • 問題を見えやすくする
    • 例:
      • 依頼はダイレクトメッセージではなく特定のチャンネルで
      • スクラムの振り返りに
  • 必要に応じてルールを見直す

という2点を特に意識することで対応しました。

導入して良くなったこと

細かく挙げれば他にもありますが、大きくは下記の3点でした。

  • 忙しいけど、「何かよくわからない忙しさに追われている感」はなくなった
  • 何かあればチームメンバーがヘルプに入れる安心感
  • チームの現状の課題が見えやすくなったこと

忙しいけど、「何かよくわからない忙しさに追われている感」はなくなった

チームの開発内容がプロダクトバックログとして一元化されたことにより、現在予定されている開発内容が把握しやすくなりました。それによって依頼側のスケジュール調整の判断材料が増え、無理な依頼が来ることが少なくなりました。
プロダクトを越えた明確な優先順位がついたことにより、より重要・効果の高い開発に注力し、優先度の低い項目を後回しにするというコントロールが可能になりました。

また、開発チームのリソースも毎週のSP消化量によって可視化され、受け入れられる開発の量を適切にコントロールできるようになりました。

何かあればチームメンバーがヘルプに入れる安心感

元々「この人がいなくなったら止まる」がすべての人に適用されていたチームでした。
現在ではプロダクトバックログに積まれているPBIは誰でも着手できるため、詰まった箇所を尋ねたり、作業を任せて休暇を取得することも容易にできるようになりました。

チームの現状の課題が見えやすくなったこと

スプリント毎にある振り返りによってチームの課題・解決策が挙がるのはもちろん、それによって課題を挙げるハードル自体がチーム全体として下がりました。
朝会や普段のミーティングでも「ここが課題だからこう直した方が良いよね」という話が以前と比べて増え、チーム改善のサイクルが短く速く回るようになりました。

導入して得た学び・気づいたこと

とりあえず取り組んでみる、で案外うまくいく

スクラムを行う意義を伝え、それに沿った大枠のルールやスケジュール等を決めてしまえば、細かい箇所は意外と後から補強ができることがわかりました。
ルール策定やプロダクトバックログ作成の箇所でも書いたように、足りなかった部分は後から追加・変更することで対応することができました。
スプリントという短いスパンで振り返りを行うため、課題を適宜発見・修正しやすいというスクラムの長所を実感しました。

導入して一番良かった効果は「チームのあらゆる状態の可視化」

スクラムを入れたからといって、チームの開発速度が劇的に変わる、という訳ではありません。 むしろ導入初期は、慣れないフローによって開発速度は下がります。 今でこそ初期の20%~開発速度は上がっていますが、より効果を感じたのは「チームのあらゆる状態の可視化」でした。

  • 開発リソース(ストーリーポイント)
  • チームの課題(振り返り)
  • 開発スケジュール(プロダクトバックログ)

スクラムによって以前と比較して上記の状況が見えやすくなったため、スケジュール遅れの早期発見やチーム改善方法の検討が行いやすくなりました。 以前は不安を抱えながらの開発も多かったですが、可視化によってより安心しながら開発ができるようになりました。

現状の課題・今後の展望

現在、スクラム自体の改善(振り返り方式やルールの洗練)もまだまだこれからですが、チーム特有の課題もたくさんあります。
例えば、

  • 開発チームでのアジャイル的開発は意識するようになったが、ビジネスメンバーも含めたアジャイルによる継続的改善の動きには繋げられていない
  • プロダクトが複数存在するが、忙しい時期がかち合いリソース調整が難しいケースが起こる
  • toBかつ他社サービス利用を行うことも多く、他社待ちによってスプリントをまたぐPBIが多く発生する

などがあるため、今後も引き継ぎ改善を続けていく必要があります。

まとめ

ビジネスドリブンであり、個人開発の多かったチームにスクラムを導入した1年を振り返りました。
自分も含め「うちのチームでスクラムがうまくいくのか?」との声もありましたが、既存の体制との折り合いをつけつつ徐々に定着することができました。

関係者の皆さん、特にスクラム導入の相談に乗っていただいた常松さん、ビジネスメンバーとの連携を手伝っていただいたマネージャーの進藤さん、ありがとうございました。