こんにちは。新卒でディレクターになってもうすぐ半年経ちます、りんです。2018年6月ごろに、所属のチームにScrumが導入されました。なんとなくやってきましたが、たまたま先輩が『Scrum Boot Camp The Book - スクラムチームではじめるアジャイル開発』という本を貸してくれたので、理解を深めるためにこの本に基づいてScrumの概念を整理し、チームがScrumをやっている中で実際にあったことを振り返りたいと思います。

そもそもScrumってなに？

Scrumはアジャイル（Agile）開発の手法の１つです。アジャイル開発は３つの進め方があります。

1. 関係者は目的の達成のためにお互いに協力し合いながら進める。2. 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。3. 一度にまとめてではなく、少しずつ作る。そして実際にできあがったものが求めているものと合っているかを頻繁に確認する。（p.21）

従来の開発手法はあらかじめすべての要求を抽出し、すべてのコストを見積もります。それに対して、アジャイル開発は「事前にすべてを正確に予測し、計画することができない」という前提を意識します。

そのようなアジャイル開発の手法の１つとしてのScrumは、以下の特徴があります。

1. 要求を常に順番に並べ替えて、その順にプロダクトをつくることで成果を最大化します。2. Scrumでは実現される価値やリスクや必要性を基準にします。固定の短い時間に区切って、作業を進めます。この期間のことをタイムボックスと呼びます。3. 現在の状況や問題点を常に明らかにします。これを透明性と呼びます。4. 定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます。5. やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます。（p.22）

Scrumにおけるロール、成果物、会議体

Scrumにおいて、重要なロール、成果物、会議体があります。下の図はscrum.orgから引用した図ですが、成果物と会議体の関係が示されています。

Scrumチームの中にはプロダクトオーナー（Product Owner, PO）、Scrumマスター、開発チームがいます。

・プロダクトオーナー：プロダクトの結果責任を取る。プロダクトバックログ（Product Backlog）の管理者で、並び順の最終決定権を持つ。開発チームに相談できるが、干渉はできない。（p.24）

・開発チーム：リリース判断可能なプロダクトをつくるチーム。3-9人で構成されている機能横断的なチームである。（p.26）

・スクラムマスター：このプロセスがうまくまわるようにする人。教育、ファシリテート、コーチ、推進役的な存在。（p.36）

ここで、Product Owner（PO）とProduct Manager（PM）の違いが気になる人もいるではないかと思います。私も最初うまく理解できなかったですが、このスライドによると、PMは顧客・市場寄りの役割で、POはチーム・プロダクト寄りの役割です。実際に私たちのチームでは、POはエンジニアの方が担当しています。

Scrumの成果物は、プロダクトバックログ（Product Backlog）、スプリントバックログ（Sprint Backlog）、インクリメント（Increment）があります。

・プロダクトバックログ：プロダクトへの要求の一覧が順番に並んでいるリストである。順位の高いものから開発されます。ユーザーストーリーの形式で書くことが多いです。

・スプリントバックログ：プロダクトバックログを具体的なタスクに分割したもので、今回のスプリント期間中に行うタスクのリストになります。

・インクリメント：Scrum Boot Campの中では「インクリメント」という名称が使われていないですが、本文ではscrum.orgに合わせて使用しました。インクリメントとは、リリース判断可能なプロダクトのことです。

会議体もすべて書きたいですが、記事が長くなりすぎるので割愛します…！次のセッションで私のいる現場でのScrumのやり方を紹介しながら、実際に誰がどの会議体に参加しているのか、会議体の進め方と目標について説明したいと思います。

Scrumを導入した現場の話

まず背景から説明すると、Scrumはディレクションチームと開発チームで始まりました。ディレクションチームが東京にいて、開発チームが福岡にいますので、「ちょっと聞きたいことがあるから突撃しよう」みたいなことが気軽にできない状況です。普段はslackでよくやり取りしていますが、やはり対面で会えないため難しいところもあり、POは開発チームの方が担当することになりました。

The Scrum Guideによると「POはcommittee（委員会）ではなく1人である」となっていますが、私たちの現場ではPOを完全に1人にすることはまだ難しいです。このような現場に適応するために既存の会議体以外に「Pre Product Backlog Refinement」を実施することにしました。この会議の参加者はディレクションチーム、PO、スクラムマスター、そしてQAです。この会議でバックログを確認し、優先順位を決め、順番を並べ替えたり新しい要求をバックログに追加したりします。下の図は実際のScrum会議体と参加者を示しています。

また、Product Backlogでは要件定義と仕様書が完成したものしか入れませんので、要件がまだ固まっていない企画（私たちは「アイデア段階」と呼びます）をどのように管理すれば良いのかという課題がありました。そこでスクラムマスターのアドバイスに基づいて、Product Backlog以外に「Portfolio Backlog」というバックログを運用し始めました。企画の要件が固まって、機能仕様のレビューが終わったら、Portfolio BacklogからProduct Backlogに昇格させます。これらのバックログはJIRAのKANBANで管理していて、ボールは誰が持っているのかを見れるのがすごく良いと思います。

その他に、QA側からあがったQA issueと開発側からあがったTech issueもそれぞれのバックログで管理されています。つまり４つのバックログを運用しています。それぞれのバックログの関係性は下の図に示されています。（スクラムマスターが描いてくれた図をお借りしました）

また、POと開発チームだけで行っているSprint Reviewに、９月後半からディレクションチームも参加することになりました。１スプリントは１週間なので、毎週Sprint Reviewでプロダクトを実際に操作しながら確認します。これは結構大きいな一歩ではないかと思います。実際に動作するプロダクトを見れるのが純粋に感動ですし、実装上の問題もオープンで議論されて、リリース前に効率よく解決されることが可能です。

まとめ：Scrumやってよかったこと、課題と感じること

長文になりましたが、最後にディレクターの観点からScrumやってよかったこととまだ改善する余地があることをまとめたいと思います。

よかったこと：

・仕様レビューが活発になった：Scrumを実施することで、企画と仕様を早い段階で開発チーム、PO、QAに共有することができた。それで仕様レビューが早い段階で行われるため、仕様改善も早くできます。また、レビューされる側として個人的には大変勉強になりました。

・優先度の議論が一緒にできるようになった：Scrumが実施される前に、優先度を決めるのは主にビジネスサイド（企画など）でした。Scrumはじまってから、毎週の会議で優先度を決めていますが、ビジネスサイドだけでなく開発もQAもそれぞれの観点から意見を述べてくれるのがすごく助かります。

・開発の進捗が可視化された：スプリントバックログの運用で、このスプリントで開発された項目と開発中の項目が一目瞭然になります。

・成果物を頻繁にチェックできるようになった：Sprint Reviewで現時点の成果物を確認することができ、即時的な軌道修正もできます。こうすることで開発の手戻りも減少したのではないかと思います。何より、皆で成果物を一緒に確認するときのワクワク感がすごいです！（笑）

改善する余地があること：

・差し込み案件の対応：スプリントがきっちり決まっている分、差し込み案件の対応は週一回の会議でしか議論されないことになります。だいたいそんなにcriticalではないので、まずslackで頭出しして、会議のときまで待つことにしています。（本当は差し込み案件がないのが一番理想的ですが）

・issueのバックログ間移動：アイデア段階の企画の話ですが、どのような基準を持ってissueをPortfolio BacklogからProduct Backlogに移動させるか？というのが少し難しいと感じています。一応「仕様レビュー完了」という条件を設けていますが、そもそも「仕様レビュー完了」の定義も曖昧ですので、ディレクターが仕様完了と、POが仕様完了していないと認識して、企画がずっとそのまま放置されることも時々あります。これについてはまだ模索中ですね。

・Portfolio Backlogの管理：これは完全に企画側の課題ですが、JIRAのPortfolio Backlogでは優先度の管理ができていないです。企画の優先度は別途wikiで管理されていて、つまり二重管理になっています。全部JIRAに統一すればいいのではとは思っていますが、すぐに移行するのちょっと難しいみたいです。関係者全員が進捗把握できるようにするための工夫が必要ですね。

以上、Scrum Boot Camp The Bookを読みながらScrum導入した現場を振り返ってみました。Scrumで定められたルールに従いながらも現場の状況に合わせて色々アレンジした実践でした。

はじめてのnoteですが思った以上に長文になりました。Scrumについての知識と理解がまだまだ足りないのでもし間違ったところがあればご指摘ください。日本語が変なところもご指摘ください。

ではまた！🍎