プロダクト開発グループの高田です。
自分の所属するチームでは1年以上前からスクラムをまわしています。
本記事では運用系のタスクをメインとするチームがどのようにスクラムを回しているのか、その取り組みについて書こうと思います。
チームについて
開発サイクルの話に入る前に、どのような環境でチームが開発をしているのか簡単に触れます。
プロダクト開発部では、弊社サービスFANSHIPの機能として提供されるシステムの開発運用を行なっています。
チーム構成は、機能強化をメインに行う強化チーム、顧客データ分析プラットフォームチーム、FANSHIPの前身でもあるpush通知配信プラットフォームの刷新を行う一新チームの３つに分かれており、それぞれのやり方で日々開発をしています。
そんな中一新チームは現在エンジニア4人+プロダクトオーナー1人で1週間単位でスプリントを回しています。
スクラムを始めた経緯
もともと弊社では開発における課題を解決するために受託開発チームの方でスクラムが導入されていました。
当時そのチームで開発を行なっていたエンジニアが一新チームに異動することになったのですが、そのタイミングで当時の一新チームにあった以下の課題へのアプローチの１つとしてスクラムを導入することにしたそうです。
リリースから8年にも及ぶシステムの技術負債が溜まり続けていること
機能追加を決定をするに至ったコンテキストの共有が開発メンバーにされていないこと
機能を実装するために辿るべきロードマップとそのスケジュールが明示されていなかったこと
個々のメンバーのタスクの割当と進捗のトラッキング、遅れが生じた際のリカバリができていなかったこと
一新チームでスクラムを回し始めたのが2018年の夏頃の出来事で、それから現在まで形を変えつつ継続されています。
ちなみに私がチームに入ったのは2019年1月からなのですが、過去のドキュメントに書いてあったような上記の課題の多くはこれにより解消されているように思えます。
一新チームの1週間
一新チームでは1週間単位でスプリントを回しています。やっていることは以下です。
(木) 14:00~17:00 スプリント計画会議1部&2部
スプリント計画会議では、スプリントの開始にあたってこの期間中に着手する作業の見積もりをします。
スプリント計画会議は1部と2部に分かれています。1部では新しいタスクの確認とこの期間で行うタスクを決めます。2部では1部で選んだタスクを作業単位まで分解し、完了条件を定義します。もしこの時点で想定していた量より作業が多く、1週間で終わらないと判断されれば一部のタスクをバックログに戻す(次週以降に回す)こともします。
ちなみにタスクの担当までは決めません。以前はタスクの割り振りはインフラが得意な人はインフラ系のタスク、コーディングが得意な人はコーディング系のタスクをやることが多かったのですが、これによって以下のような問題が生じました。
- やることが偏る
- 他の人の進捗を追えなくなり、サポートや適切なレビューができなくなる
- コンポーネントが特定の人しか触れないようになってしまう
要するに属人化問題です。 これに対応するため、チームではスキルや得意領域を度外視して優先度順にタスクに着手する方式に切り替えました。 以前は1人1タスクだったものを、今では1タスクを作業単位(サブタスク)に細分化し、そのサブタスクをメンバーに順次割り当てチームで１つのタスクに取り組んでいく形です。 とりわけチームではペアプロを推奨していて、複数人でできる作業はなるべくペアで行うようにもしています。
このように定期的にチーム全体で行うタスクについて話す場が設けられることによって、他チームからの依頼など突発的なタスクに関しても、依頼を受けたメンバーだけなくチームメンバー全体にその内容やなぜそれをやることになったのかといった背景がきちんと共有されるようになりました。また誰かが必要に応じてやることを持ち寄っても、話し合いの中で実はやる必要がない事がわかったり、スコープや設計の見直しが必要なことが発覚することもあるため、結果的に個々人が各々作業するよりも手戻りするケースが少なくなります。
このスプリント計画会議を持って、スプリントが開始されます。
毎朝 10:00~10:30 デイリースクラム
通称朝会です。各メンバーが昨日やったことと今日やることを短く共有して進捗を確認します。
通常は10分以内に終わるものなのですが、私たちのチームは他のこと(※後述)もやっているため少し長めです。
(水) 13:00~14:00 バックログリファインメント
バックログリファインメントとは、バックログに積まれているタスクに関する情報の追記や整理、優先順位の見直しを行う場のことです。
スプリント計画会議が、期間中のタスクについての話をする場に対し、バックログリファインメントではタスクの優先順位をつけやすくするためにバックログの整理します。
タスクの見積もりに関しては「プランニングポーカー」と呼ばれる手法で行なっています。特定のタスクについての一通りの話し合いをした後に、各々がこのタスクを完了させるにはどのくらいの工数がかかりそうか、フィボナッチ数が書かれたカードを一斉に提示します。全員の数字が近ければ認識が揃っているということでよし、ばらけていたら多い人少ない人それぞれが何を思ってこの数字を付けたのか意見交換をして、再度カードを提示して見積もりを決めます。
個人的な感想ですが、プランニングポーカーをやる前は新出タスクの説明時に質問を挟みにくい雰囲気だったのですが、プランニングポーカーをするようになってからはカードを出す段階で「〜をするという認識で合っていますよね」といった質問が気軽に行えるようになったので良かったです。
(木) 11:30~13:00 レトロスペクティブ
所謂ふりかえりです。いくつかのアクティビティを通してこのスプリント中の良かったことや悪かったことを振り返り、次のスプリントに活かすための改善策を決めています。
チームではレトロスペクティブのファシリテーターは交代制でやっていて、現時点で全員1回以上は経験した状態になっています。
ふりかえりの手法は毎回異なっており、その回のファシリテーターが本などを参考に事前にアクティビティを決めていますが、何をやるにしても以下のようなフェーズがあります。
- データ収集: このスプリント期間中の出来事を洗い出す
- 分析: 出てきた出来事をカテゴライズしたり、因果関係を線で繋いでみたりしながらみんなで眺めて感想を出す。有名なアクティビティだとKPTなどもここで行うことがあります。
- アクションプランを出す: 前のフェースを経て出てきたものの中から残りの時間でより深掘りしたいテーマを選んで、それに対して翌スプリント以降に行う施策を出す
アクティビティを選ぶ時は以下の書籍に頼っています。
この分析フェーズからどれをアクションプランに落とし込むか決める段階がすごく難しいです。ただ、起きた出来事に対して他のメンバーどう考えているのか、それに対してどうしていきたいかといった話し合いを全員で行える貴重な場になっています。
過去のふりかえりで出てきた施策
最後に1年以上スクラムを回してきた成果物の１つとしてレトロスペクティブ内で出てきたアクションプランの一例をご紹介します。
継続されているもの
- アラート振り返り
- チームでは週1でモニタリングを確認するパフォーマンス定点観測会を行なっているのですが、その中にアラートを確認する回も追加されました。これによって、その週発砲したアラートの全体の傾向を眺めたり、閾値の見直しを定期的に行うようになりました。
- 毎朝のCost Explorerのモニタリング
- ほとんどのインフラがAWS上で動いているのですが、より変化に気付きやすくするための施策として導入されました。本番と開発環境をそれぞれ確認するということをチームの朝会で行い、1日で大幅に上がっているリソースがあったら都度調査するといったことをしています。
- BLT
- BLTとは便利LTの略です(※チーム内だけの呼称)。ある日の振り返りでナレッジの共有がテーマになったときに、LTだとスライド準備するが大変だからもっと気軽にできるものがいいよねということで生まれました。毎朝誰かのパソコンもしくはホワイトボードの前に集まって、3~5分程度の発表を聞くものです。内容は業務の中で作った物や調べた物、エディタのプラグイン、Gitの便利コマンド、見に行った勉強会のスライド紹介など多岐に渡ります。
継続されなかったもの
- リファクタリングスプリント
- バックログに溜まった所謂「やる価値はあるけど優先順位が高くないためいつまでも着手されないタスク」を消化する会です。工数がかからないものであればすぐに着手することができますが、そうでないとどうしても溜まってしまいがちです。定期的にそういったタスクを片付ける期間を設けてやろう！といった話が出てきてアクションプランに入れるのですが結局定着しませんでした。ちなみに立てたアクションプランは「四半期に一回リファクタリングスプリント期間を作る」「週ごとに当番を作って、担当者がリファクタリング用バックログから１つ選んで着手する」でした。
- ペアプロチケット
- 1年ほど前の話ですが、みんな良いよねと言いつつもあまりやろうとしないペアプロを定着させるためのアクションプランでした。ペアプロチケット(付箋)をメンバーそれぞれが所持し誰かにペアプロを依頼できるというものでしたが、定着はしませんでした。ちなみに今ペアプロが普及したのは、上述した通りみんなで１つのタスクをやる体制に変わったタイミングで半ば強制される形で定着しました。
- リリースランチ
- 大きめのリリースがあった日は会社のお金でみんなでランチというものでしたが、案の定上司の承認を得られず終わりました。(それとは別にチームランチも定期開催されるようになりました)
おわりに
最近の新しい取り組みとしてJiraを導入しました。今まではホワイトボードでカンバンを作り、バックログはGitLabにタスク管理用のリポジトリを作ってそこにissueを積むということをしていたので、完了したタスクのトラッキングが疎かになっていた部分がありました。今後はツールの力を活かして成果を可視化して長期でのふりかえりに活かすといったこともできるようになればいいなと思います。
