Tech & Design LAB

15スプリントを経て行き着いたスクラムイベントの進め方

#Scrum
author icon
Posted on
tech

こんにちは、HiCustomerの肥前です。このブログの最初の記事を書いた頃からは少し立場を変え、最近ではプロダクトマネージャーとして仕事をしています。弊社では開発プロセスにスクラムを導入していますが、この記事では特にスクラムイベントに焦点を当て、実際に使用している資料などを交えてどのようなことを行っているのかを紹介します。以下についてお話しします:

以下については詳しく触れません。

想定読者

なぜスクラムを選んだか

私たちのチームでは創業から1年半ほどは開発プロセスに関する明確な意思決定はなく、関わるメンバーの経験を持ち寄った「なんとなくスクラムのような形をした何か」が暗黙的に運用されていました。これくらいのフェーズのチームではたまに聞く話ではありますが、開発に関わる人数が増えるにつれて暗黙知による運用は当然のように瓦解したため、改めて整備することにしました。これが昨年2019年の9月ごろです。

スクラムの思想が私たちのチームの求めるものに近そうだということは実感として持っていましたが、改めてスクラムガイドに目を通してみました。

すると、以下のように書かれています:
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. スクラム (名詞): 複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

私たちが事業を行うカスタマーサクセスという領域は、特に国内ではここ数年で急速に発展している状況にあり、ドメイン知識自体も日々変化します。不確実性と向き合う上で、スクラムは適したフレームワークといえそうです。

また、以下のような記述もあります:
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

これを作れば終わりという性質の領域ではなく、年単位での継続的改善が必要である私たちのプロダクトにとって反復的で漸進的な手法は有効そうです。また、チームで成果を出すことを重視している点でも経験主義的なアプローチは考え方が合致します。

思想の面では私たちのプロダクトを開発する手法として妥当そうなので、今度はスクラムガイドに沿った形に運用を整えていくことにします。スクラム以外のアジャイルの手法やその他のアプローチについての検討を十分にしたかでいうとそうではありませんが、うまくいかなければ見直す前提でまずは試してみることにしました。

スクラムの構成要素

スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。

詳細な説明は割愛しますが、経験から学び、自己組織化したチームで継続的に課題に取り組むための手法です。公式のガイドラインであるスクラムガイドの中では3つの柱となる考え方と、その実践のための4つのイベントが定義されています。

これらを、スプリントと呼ばれる一定の期間の中で実施します。短いスプリントを反復しながら、プロダクトや開発のプロセスを漸進的に改善していく、というのがスクラムの大まかな考え方です。

3つの柱

4つのイベント

利用しているツール

HiCustomer では以下のツールを使用してスクラムイベントを運用しています。

Notion
https://www.notion.so/about
ドキュメント管理のサービスです。各イベントのアジェンダ/議事録とプロダクトバックログの管理に使用しています。

GitHub
https://github.com/about
ソースコードのバージョン管理とissueの管理に使用しています。

ZenHub
https://www.zenhub.com/product
GitHub issue をアジャイルの手法に沿って運用するためのラッパーのようなものです。 issue にストーリーポイントを紐付けたり、親子関係を持たせたり(Epic)、バーンダウンチャートのような統計情報を利用するために使用しています。

スクラムイベントの進め方

このセクションでは、HiCustomerの開発チームではスクラムイベントをどのように行っているかについて紹介します。基本的には先に紹介したスクラムガイドに書かれている内容や時間配分に従っていますが、一部変えている部分もあります。

Sprint - スプリント

私たちのチームでは2週間を1スプリントとしてスクラムを運用しています。スプリントは水曜日に開始し、2週間後の火曜日に終了します。祝日によるイレギュラーなスケジュールを避けてスプリントの境界は週の半ばに設定しました。

Sprint Planning - スプリントプランニング

スプリントで行う作業の内容を計画するためのイベントです。スプリント開始日に最大2.5時間かけて行います。スクラムガイドに従うと2週間スプリントであれば最大4時間ですが、この時間の一部は後述するBacklog Refinementに割り当てることにしています。

プロダクトバックログのレビュー

スプリントバックログの作成

見積もり

スコープの調整

Daily Scrum - デイリースクラム

開発チームが次の24時間の計画を立てるためのイベントです。毎日15分行います。

Burndown Chartの確認

Boardの確認

3つの質問

Sprint Review - スプリントレビュー

スプリントレビューでは、そのスプリントの成果物を検査します。最大1.5時間かけて行います。

統計情報の確認

実際に消化できたポイント数 (=ベロシティ) と、スプリントプランニング時に見積もったキャパシティとを比較し、乖離があった場合は要因を分析します。分析には以下のようなレポートを用います。

issue の検査

issueの進行中に問題があった場合はその場で話し合ったり、翌日のデイリースクラムで会話して解決しますが、すぐに解決できなかったり仕組みを変える必要があるようなものは sprint: review というラベルをつけておき、スプリントレビューの時間で話します。

完成した機能のレビュー

本来、スプリントレビューではステークホルダーを招待して完成した成果物をレビューしますが、時間的制約の都合で私たちはこれを開発チームの参加しない別の会議体で行っています。透明性の観点で望ましくないため、スプリントレビューへの統合を検討しています。

Sprint Retrospective - レトロスペクティブ

スクラムチームやプロセスの検査のためのイベントです。最大1時間かけて行います。

振り返りのためのKPTをいうフレームワークを用います。以下の2つの質問について3分ずつ各自考え、その後それをチームで分析しながら次回以降で試すこと (=Try) を決めます。

Try については issue 化しておき、次のスプリントプラニンングの際にスプリントバックログに入れるようにしています。

まとめ

上記のような運用を15スプリントほど運用し、今のところは概ねうまくいっています。ベロシティは以下のように推移しています。まだ分散が大きいので安定させたいところです。 増加傾向にあるのはメンバーの増員とプロセスの最適化の双方によるものと見ています。ちなみに各スプリントは日本百名峠から命名しています。

この運用に至るまでに以下のような課題も見えてきましたが、長くなってしまったのでこれらは次回以降にご紹介できればと思います。

また、他のチームでどのように運用されているのかにも興味があるので、うちはこうやってるよ!というような事例があればぜひ教えてください。

最後に

HiCustomerではエンジニアを募集しています。この記事を読んで少しでも興味をお持ちいただけた方、採用サイトでチームの紹介スライドなども公開しているので、ぜひ覗いてみてください!

author icon
プロダクトマネージャ

サーバーレスやGoが好きです。最近はコードから離れ、ユーザーインタビューやプロトタイピングを通じてプロダクトの設計を行っています。週末は山を走ったりしています。