VISITS Technologiesでマネージャー兼バックエンドエンジニアをしている@ham0215です。
今年のアドベントカレンダー2つ目の記事です。よろしくおねがいします。
前回の記事では『スタートアップに転職して思ったこと +1 year』というタイトルでスタートアップに対する私見を色々書きました。
その中でも触れたのですが、私の所属している開発チームではスクラム開発Likeな開発手法を採用しています。
スクラム開発Likeと書いたのはスクラム開発をベースにしているものの、色々なスクラムイベントを端折っているためです。
当初、プロダクトメンバーはエンジニア3名、PM1名、デザイナー1名でした。
人数も少ないし、それぞれが単独で滞りなく作業を進められていたのでスクラムイベントを端折っても問題なく開発をすすめることが出来ていました。
この状況なのでスクラムの形式通り様々なイベントをしても時間の無駄でしかありませんでした。
その後、コロナが発生したことでフルリモートになったり、メンバーが入れ替わったりしたりと状況が変わったので、それに合わせてスクラム開発をアップデートしてきました。
この記事ではその軌跡を紹介したいと思います。
フルリモート前
上記に書いたプロダクトメンバーはエンジニア3名、PM1名、デザイナー1名のときです。
このときはみんな会社に出社して働いていました。
このときにやっていたスクラムイベントはプランニングとリファインメントくらいです。
1週間単位のスプリントで、週に1回プランニングとリファインメントを合わせて実施していました。
出席者はプロダクトメンバー全員です。
このときは必要なことがあったらすぐに話しかければよく、全員のタスクもほぼ把握できている状態だったためデイリースクラムもやっていません。
振り返りなども明示的にしておらず、スクラムマスターの役割もありません。
作業の優先順位がコロコロ変わるということもあり、少し先の予定を立てても予定通りに進められないことが多かったためバックログもかなりぐちゃぐちゃになっていました。
フルリモート初期
コロナの影響で2月中頃から突如としてフルリモートになりました。
フルリモートになったことで今までなんとなく感じ取れていた他のメンバーの状況が感じ取れなくなり、今まで通りでは回らないことは目に見えていたのでスクラム開発のやり方を大幅に変えました。
まず、バックログをきちんと整理。タスクの作り方を明確にしました。
弊社ではJIRAを使っているのですが、エピック / ストーリー / サブタスクを下記のように使い分けることにしました。
- エピック
- 要件の単位で作ります。例えばアカウントを管理したいという要件がある場合は「アカウント管理」のように１つのエピックを作ります。
- ストーリー
- エピックを機能単位に分けたもの。例えば「アカウント登録」「アカウント一覧」などです。
- サブタスク
- ストーリーを作業単位に分解したもの。開発タスクであれば1サブタスク＝1プルリクとしています。
明確にスクラムマスターと名乗っていたわけではないが、この頃から私がプランニングの進行をしたり、バックログの使い方を整備したりするようになりました。
このとき心がけたことはやりすぎないということです。
最初から完璧なスクラム開発を目指してしまうとやり方の変化が大きすぎてメンバーに負担がかかってしまうので、最初は開発メンバーのタスクがバックログやボードで可視化できている状態を目指しました。
会議体を増やしすぎるのもツライので特に増やさず、ベロシティも最初は考えないことにしたのでストーリーポイントもつけませんでした。
このあたりの考え方は『チームジャーニー』が参考になりました。
本に掲載されているやり方自体はあまり参考にしていないのですが、チームの状態に合わせて開発手法を適用していくという考え方が参考になりました。
また、これまではある程度機能が出来上がってからまとめてリリースする方式だったのですが、曜日と時間を決めて週次でリリースするようにしました。
これにより、1回のリリースで本番に出るソースが少なくなり障害確率が減った&障害時の原因特定が楽になりました。
フルリモート中期
フルリモートに慣れてきて、スクラム開発のやり方を変えてからも1・2ヶ月経ったところで、スクラム開発のやり方を見直しました。
1つ目は、エピック / ストーリー / サブタスクという使い分けの見直しです。
この3階層で運用していたのですが階層を分け過ぎていてうまく管理できていないということがわかってきました。
うちの場合は一番上の階層であるエピックが全く機能していませんでした。
また、これはJIRAの仕様の話なのですが、サブタスクはバックログに表示されず扱いづらいということもありました。
そこで、ゼロベースで使い方を考え直して、エピック / タスクの2階層にすることにしました。
- エピック
- 機能単位で作成。例えば「アカウント登録」「アカウント一覧」などです。これまでのストーリーとほぼ同じ単位。
- タスク
- エピックを作業単位に分解したもの。開発タスクであれば1サブタスク＝1プルリクとしています。これまでのサブタスクと同じ単位。
これによりタスク管理がシンプルになり、無駄なデータが減りました。
また、仕様の相談をするための定例を週次で設けました。
最初は仕様の相談があれば都度チャットやテレカンで話せば良いと思っていたので、定例にしてもあまり意味がないかなと思っていたのですが、捕まりにくいメンバーへ相談したいときの調整コストや優先度の低くて後回しにしていた相談などがついでに話せたりとなかなか有意義な定例になりました。
現在
さらに2ヶ月ほど経ったころ、リモートでのスクラム開発はスムーズに進むようになっていました。
このころ、開発チームで振り返りをする機会がありました。
これまで開発に直接関係するイベント以外は極力省略してきていたのですが、この振り返りで沢山の課題が上がり、チームで話し合った結果定期的に振り返りをすることに決めました。
今は隔週でKPTを使って振り返りをしています。
KPTで課題の抽出は出来ているのですが、実行までうまく回せていないのでここはもう少し工夫必要だなと感じています（今後の課題）
また、スクラム開発も安定して回るようになったのでベロシティを測定したいと思い、ストーリーポイントも導入しました。
こちらも導入しただけで振り返りなどが出来ていないので今後の課題の一つです。
スクラム開発のやり方をどうしていくかを考えるときは『エッセンシャルスクラム』を参考にしています。かなり有名な本なのでスクラム開発に興味がある方は読んでいることが多いと思いますが、スクラム開発のベストプラクティスがわかる良書です。
未来
ここまで書いてきた通り、この1年弱で大幅にスクラム開発のやり方をアップデートさせてきました。
まだまだやりたいことがたくさんあるものの日々の開発タスクと並行して実施しているのでなかなかスクラム自体の改善速度は遅いのが現状です。
ただ、スキマ時間で進めていこうと思っているので今後やりたいと思っていることを列挙しておきます。
KPTで抽出した課題の実行
前の章に書いた通り、KPTで課題が抽出できているものの上手いこと実行に移せていないのが現状です。
開発のバックログとは別にKPTで出た課題も適切に可視化して実行していけるようにしたいと思っています。
ベロシティの活用
ストーリーポイントを導入して、スプリントのベロシティが測定できるようになりましたが、まだ有効活用できていません。
毎スプリントのベロシティを確認して、振り返りを実施するようにしていきたいと思っています。
スプリントレビューを実施
スクラム開発にはスプリントレビューと呼ばれるイベントがあります。
現状では必要に応じてPMからステークホルダーに機能説明を行っているのでステークホルダーへの説明は出来ているのですが、その場に開発メンバーはいません。
そのため、開発メンバーで自分が開発していない機能の把握が把握しきれなくなってきています。
これを解消するためにスプリントごとに成果物を開発チーム全員でレビューする場を設けたいと思っています。
今のところやらないこと
スクラム開発では作業の空いたメンバーが優先度の高いタスクから消化していくことが理想です。
ただ、現状は開発メンバー内でフロントエンドエンジニア、バックエンドエンジニアなど役割が決まっていて、それにあったタスクのみを消化しています。
ここをフレキシブルに割り振ることもできるのですが、今のところ誰でもこなせるというメリットより、不慣れな作業で作業効率が落ちるデメリットのほうが大きいと判断しているので、ある程度の役割分担は残したままにしておこうと思っています。
ただし、役割が関係ないQAタスクなどは積極的に分担していけるようにしたいと思います。
最後に
最後まで読んでいただきありがとうございます 
明日はVISITSのデータサイエンティスト @muraokaz の記事です。お楽しみに！！