Tech Leadの籔下(@ybalexdp)です。MyReferではスクラム開発を導入しており、これまでスプリントプランニングでざっくり誰がこの一週間何をやるのかを決めていましたが、スプリント期間中に終わらないチケットも散見し、そもそもスプリントで予定のなかったチケットをやったり、ほぼ機能していませんでした。
一度着手したものの優先度が落ちたタスクのステータスが「進行中」から放置され、延々とスプリントバックログに残り続けるみたいな状況もあり、現在の開発がオンスケなのか、組織としてどれくらいの規模の開発を1週間にこなせるのかなどの状態が見えづらい状況でした。
また現在エンジニアチームが総勢20名弱ほどの規模になっており、この人数で全てのセレモニーをスクラムマスター1人で回すのも限界という状況でもありました。ということで、改めて組織やスクラム開発を設計し、現在どのようにスクラム開発を進めているのかをお話しします。
JIRAの導入
いきなりツールの話かよ、って感じですが、元々MyReferではpivotaltrackerというツールを導入しプロダクトバックログの管理をおこなっていました。ただ、我々の使い方もよくなかったところはあるかと思いますが、単なるチケット管理ツールとしてのみの利用にとどまりスクラム開発としてはあまり機能できていませんでした。
カンバン管理もせずチケットもとっちらかっていて、スプリントプランニングでも優先度はあるものの、誰がいつまでに何をやるかもフワっとしており、最低限のチケット管理をするだけの使い方になっていました。 pivotaltrackerをやめてJIRAを採用したのは下記理由です。
・ちゃんとスクラムをやるにあたり一度まっさらな状態に戻したかった ・細かいカスタマイズができた ・メンバーに過去JIRAを使っていたメンバーが数名いて、ポジティブな意見をもらえた
チームを分けた
上述の通り、現在エンジニアチームが20名弱ほど在籍しており、一般的なスクラムチームの規模を大きく超えてしまっていました。また、現在前回の記事にも書いた様にSPAへの移行も進めており、目的に応じたチーム構成及びセレモニーへの参加人数をコンパクトにしたいという目的からチーム制にし、プロダクト開発で2チーム・SPAへの移行で1チームの計3チームに分割しました。その内SPAへの移行は実際に新規機能を開発するとかではなく技術的負債の対応という位置付けなので、特にストーリポイントなどは追わずガッツリスクラムをやってはいません。
プロダクト開発を2チームに分けた際に色々考えたのは、2スクラムチームとしてそれぞれでベロシティを追い、JIRA上のプロジェクトもチームごとに管理するのか、それともプロジェクトも同じでベロシティとしては2チームで1つのスクラムチームとして追っていくのかというところです。
結論、現在は後者のやり方で進めています。理由としては、そもそもMyReferというサービス開発に閉じたチームなので、プロダクトバックログを分けることができなかったというのが大きな理由です。
プロダクトバックログ
MyReferにおける開発の進め方としては、事業戦略観点における新規機能のアイデアや優先度をCEOと定期的に議論し、次の開発概要を決めます。決まった要求に対して、基本エンジニア1名がプロジェクトリーダーとしてアサインされ、プロジェクトリーダー中心に仕様検討を進めます。必要に応じてカスタマーサクセス部隊などの意見も取り入れながら、CEOと議論しながら詰めていきます。この過程で発生した要求事項がストーリーチケットとしてプロダクトバックログに積まれていきます。
また日々カスタマーサクセスが獲得するVOC(Voice of the Customer：顧客の声)や日々の運用の中で内部から出てきたアイデアなども日々プロダクトバックログに積まれていきます。加えて日々の開発や運用の中でエンジニアが要改善と判断したものがプロダクトバックログに順次積まれていきます。プロダクトバックログには下記３種類のチケットタイプを設定しています。
ストーリー
ストーリーチケットには要求仕様を記載し、完了基準を記載します。またポイントを設定します。ポイントの見積もりは本来スプリントプランニングで実施するものなのですが、エンジニアメンバーの半数以上が業務委託の方で、かつフルリモートで参画しているメンバーもそのうち半数おり、直近１〜２ヶ月で新規に参画いただいた方も多く、全員でやるのが非効率と判断し、現時点では主に社員を中心に一部のメンバーのみでスプリントプランニングとは別のタイミングで事前に実施しています。
見積もりはプランニングポーカーを使って行います。本来は全員の数値が一致するまで、見積もった値の理由を議論しながら、何度も繰り返すのが自分が認識している正しいやり方なのですが、現在は過半数を占めればその値を見積もりポイントとして採用しています。値は真っ二つにわかれたり、ばらつきが見られた場合は、見積もった値の理由を各自が説明し再度ポーカーを実施しています。
タスク
開発の中で必要なツールの設定や、調査系のタスク、運用作業など、ポイントは計上しないタスクをタスクチケットとして管理しています。
バグ
開発中やエラーログ、お客様の問い合わせの中で発覚したバグ(相当)の要対応事項をバグチケットとして管理しています。
セレモニー
MyReferで導入しているセレモニーと、その実施内容を紹介します。
デイリースクラム
毎朝数分のスタンドアップミーティングで、もともと全メンバーが
・昨日やったこと ・今日やること ・その他共有事項
を口頭で報告していました。
ただ、エンジニアの数も多く、デザイナー/フロントエンド/バックエンド/iOS/Android/インフラとレイヤが分かれており、もちろん連携してお互いの状況を知っておきたい場合もあるのですが、中々他のメンバーの進捗報告に対するリアクションがでず、一方的に喋って終わりみたいな状況になっていました。加えて報告者も、あれ？何したっけなとか、結構忘れがちでグダグダ感がでてきたという状況でした。
そこで、デイリースクラムまでにslackで報告用チャンネルを作り、そこで
・前日やったこと(元々やる予定だったこととの予実) ・今日やること(何をどこまで) ・その他共有事項
を報告するようにしました。
デイリースクラムではそのレポートの内容に応じて改めてスクラムマスターが進捗の確認であったり、各メンバーから困っていることなどの相談を中心に5〜15分程度の時間で実施しています。
スプリントプランニング
毎週水曜日の午前に実施しています。 これは自分がジョインした直後くらいはたしか月曜に実施していた記憶があるのですが、それだとリリースが金曜日となり、そのまま土日突入で有事の際の対応が土日になってしまうなどのリスクを考慮し、水曜にスプリントプランニングを行い、火曜〜水曜にリリースする流れにしています。
スプリントレトロスペクティブ
毎週火曜日の夕方に実施しています。スプリント終了間近のタイミングで実施しており、基本ここまでの進捗でスプリントの消化ポイントが決まります。主に現在のスプリントで予定していたタスクが全てスプリント中に終わりそうかの確認と、終わらなさそうであれば、その要因について振り返りを行い、チームとしてどのような改善ができるかを相談する場としています。
またバグやその他問題が発生していた場合はその原因の振り返りなども行い、同様に改善について議論します。
プロダクトバックログリファインメント
毎週火曜日のスプリントレトロスペクティブ後に一部のメンバーで次回以降のスプリントで対応したい開発項目の優先順位の確認や、必要に応じてストーリーポイントの見直しを実施しています。２チーム制にしてからは、どのチームが次のスプリントでどのプロダクトバックログを実施するのかをこの場で認識合わせします。
元々はスプリントのちょうど真ん中の金曜日に実施していたのですが、水曜日朝のスプリントプランニングまで多少時間が空き、その間に次のスプリントで対応したい優先度が結構変わることがあり、直前の火曜夕方に移動しました。上述したプランニングポーカーもこのタイミングでやっています。スプリントプランニングの場では、ポーカーで設定されたポイントをベースにもし追加で実装する必要があることが判明したなどの場合に、ポイントの修正などをしています。
KPT
スクラム開発とは少しずれますが、KPT活動も行なっています。KPTとはKeep Problem Tryの略で、振り返りや改善活動のフレームワークです。レトロスペクティブでは、スプリントにおけるサービス開発での課題などを改善していく活動としており、KPTでは日々の業務で困っていることや他のメンバー及びエンジニア以外や会社にお願いしたい内容などを各メンバーがProblemとしてボードに起票し、それに対して何をするべきかを議論する場にしています。またKeepにやって良かったことなどを起票し、チーム全員に共有などを行います。
最近はどうしてもProblemへの起票に対してTryをみんなで検討する場になってしまい、Keepを疎かにしがちになっています。この辺は、改めて改善していきたいと思います。
スプリントレビュー
スプリントレビューは定期的にはやっていないです。スプリントレビューはステークホルダーの参加が必須です。MyReferの開発においてスプリントレビューに参加するべきステークホルダーはCEOであったりカスタマーサクセスのメンバーとなります。これらのメンバーを定期的に時間を確保することが難しく、不定期に必要に応じて時間を確保し、スプリントレビューをするようなやり方にしています。
現在の課題
人が増えたり、チームが増えたりしている中、色々改善はしているものの、まだまだ上手く運用できていないところがあるなと感じています。それらをまとめてみます。
一週間スプリント
現在スプリントは一週間で進めています。二週間スプリントにしてしまうと、事業戦略の中で開発優先度や要求内容が日々変動し、スプリントの途中で開発項目が変わる可能性が高くなるため、一週間としています。ただ、一週間だとスプリント期間内に収まらない開発や、テスト期間が十分にとれないなどの課題があり、現在頭を悩ませ中です。
ベロシティに基づいたプランニング
ポイントはストーリーチケットのみに設定しています。ポイントはマーケットバリューに紐づくストーリーチケットにのみ付与するので、それ以外のバグ相当のチケットや、運用タスク系のチケットには割り振りません。スプリントによってはある程度新規機能開発が落ち着き、細かいバグ改修や、たまってる運用タスクなどガッとやるスプリントがたまーに周期的にきます。その際にどうしてもポイントのつかないチケットの消化に集中してしまうと、ベロシティがぶれたり、チケット数ベースでプランニングしていまい、ベロシティやポイントを考慮したプランニングがまだうまく機能していない課題があります。done/undoneの運用はこのあたりが少しづつ機能し出したら導入しようと考えています。
チケットが詳細に記載できていない
特にストーリチケットの受け入れ条件や、細かい要求仕様までなかなか書くことができないケースが大半です。どうしても稼働がとれずコミュニケーションによる解決を図ってしまいます。
まとめ
MyReferにおけるスクラム開発についてご紹介しました。まだまだ課題はありますが、改善しながら日々の開発プロセスを回しています。一緒に開発プロセスを改善していっていただけるエンジニアの採用も積極的におこなっており、気軽にお話しに来てください。
