id:radiocat です。9/13に東京オフィスで開催したMeetupに登壇し「終わらないスクラム」というタイトルで発表しました。今回のイベントを通じて、私たちが継続してスクラムに取り組んでいくうえでの様々な気づきを得ることができたので、それらを5つの学びとして記事にまとめてみました。ご参加頂いたみなさま、ありがとうございました。
発表の概要
発表の前半は私たちのチームが取り入れたアジャイル開発のプラクティスの説明で、今年3月の社内イベントで発表した内容がベースとなっています。それらの概要は以前のブログ記事にまとめていますのでご参照ください。
発表の中盤からは開発を少しずつアジャイルにし、やがてスクラムにチャレンジしていくために私たちが参考にした書籍やネット上の情報を紹介しました。そして後半部分では、現在のプロジェクトでも引き続きスクラムで開発を進めている中で新たに取り組んでいることを紹介しました。
5つの学び
発表後の懇親会では参加者の方々からたくさんフィードバックを頂いて、それぞれの現場で実践しているスクラムの取り組みなども教えていただき、とても有意義なイベントにすることができました。頂いたフィードバックも交えて、5つの学びをご紹介します。
1. 役割に徹することができる体制でスクラムを始める
私たちのスクラムチームではプロダクトオーナー（以下PO）をデザイン部門のメンバーが担っています。
その理由は大きく2つです。
- 開発チームは大阪、POのデザイン部門とステークホルダーの事業部門は東京が拠点
- BtoBのサービスであるため、デザイン部門はデザインの作り込みよりもUI/UXをしっかり検討することが求められる
この話をした時に、「（上記の体制を書いた）スライドを見た時にそうだと思った」というフィードバックを頂きました。
スクラムチームの中で誰がPOやスクラムマスター（以下SM）を担当するかはスクラムに取り組むうえでの最初の難題の1つです。チームの中で誰がその役割を担えばその役割に徹することができるのかをしっかり問いかけて決める必要があります。
役割に徹することができない体制でスクラムを始めていたら恐らく失敗していました。世の中的に複数拠点やリモートワークを絡めたメンバー構成は当たり前となっていますし、それぞれの現場に合わせて最適な体制を考える必要があります。
ちなみに、今回の体制の場合は開発部門におけるリーダーという立場の私がSMを担うことがもう1つの課題になりました。
開発チームが機能するために組織としての役職が邪魔になることもあれば、うまく活用してチームを支援できることもあり、それらをうまく使い分けることも役割に徹するために必要なことです。
2. スプリントの期間は1週間がおすすめ
今回の発表で取り上げた開発プロジェクトでは2週間のスプリントでスクラムを始めましたが、現在はスプリントの期間を1週間にしています。
同様に1週間でスプリントを回している人から「1週間じゃないとスプリントを回すのは無理」というフィードバックをもらいました。大きな理由は以下の2点です。
- スプリントの最初に2週間分のタスクを洗い出してプランニングするのが大変
- 2週間先の見込みを見極めるのが大変
私たちも慣れた今となっては1週間が最もやりやすく感じています。
チームの事情にもよりますが、スプリントの期間をどのくらいの長さにするかもまたスクラムに取り組む上での課題の1つです。私たちが最初にスプリントの期間を決めた当時は他のプロジェクトに稼働を使うメンバーもいたため2週間ぐらいがちょうど良いと判断しました。また、当時は1つのタスクの粒度を小さくする事に慣れておらず、1週間スプリントで大きな粒度のタスクの実行に想定外の時間がかかってしまうとあっという間にスプリントの終わりを迎えてしまう恐れも感じていました。しかし、今となっては1週間スプリントならうまくいかなくても改善して次に活かせば良いという感覚のほうが大きいです。
3. リファインメントと技術的スパイクの大切さと難しさ
次のスプリントに向けてバックログを準備するリファインメントや技術的スパイクの活動はスクラムイベントとしては定義されていませんが、非常に重要でかつチームでルールを決めるのが難しい活動です。私達のチームではリファインメント会議をイベント化して強制的に時間を取るようにしています。
これについても同様にルールを決めて時間を取っているチームもあるというフィードバックを頂きました。やりかたはチームによっていろいろあるようでしたが、いずれにしてもプランニングまでにバックログをきちんと準備できていなければ、スプリントはうまく回らないというのが共通の理解です。
ちなみに、現在私たちのチームでは1スプリントに2種類のリファインメント会議を実施しています。
その理由は主に以下の3点です。
- 現在取り組んでいるプロジェクトの特性として技術面での不確定要素が多い
- 開発チームの人数が増えてきたため全体共有や認識合わせの場があったほうが進めやすい
- POと開発チームの拠点が別れているため時間を決めて実施したほうが進めやすい
いずれも私たちのチームの事情によるものですが、これらを踏まえてリファインメントや技術的スパイクはそれぞれのチームでやりかたを考えて取り組む必要がある活動だと感じています。
4. チームの人数が増えるにつれてスクラムは難しくなる
私達のチームはメンバーが10人を超えたためスケールアウトを検討し始めています。
これに関連してチームのメンバーが9人いるという人からもフィードバックをもらいましたが、デイリースクラムを時間どおりに終わらせるだけでも難しく、人数が増えるとスクラムは難しくなると感じています。私たちのチームでも、スライドに書いてあるとおりスクラム・オブ・スクラム、LeSS、Nexusといった大規模スクラムの事例を調査して検討をしていますが、事例自体があまり多くないのでまだ具体的な判断は下せていません。
ただ、スライドの下に書いてある「若手メンバーのミニスクラム」を試す期間で、一時的にメインのプロジェクトのメンバーを5人にしたところベロシティが上がってスプリントを以前よりうまく回せるようになったので、やはり5人ぐらいがちょうど良いという感覚も得ています。
5. チームの育成と成長は熱意を持って根気強く
上記の「若手メンバーのミニスクラム」や、以前このブログでも紹介した「スクラムクイズ」に関しては良いフィードバックを頂きました。
チームのメンバーひとり一人がきちんとスクラムに向き合わなければスクラムをうまく回すことが難しくなります。フィードバックの中でその点に課題を持っているチームの話もいくつか聞くことができましたが、チームの中で熱意をもって進められるメンバーがいないとスクラムを続けていくのは難しいと感じました。
我々もまだまだ試行錯誤しながら様々な取り組みを行っているところですが、そのためにも他のチームの事例や課題はとても参考になります。そういう意味で、今回のイベントではたくさんのフィードバックを頂き、私たち自身の新たな学びを得ることができました。
この学びをまたチームに持ち帰ってさらにスクラムを前進させていきたいです。スクラムの習得はまだまだ終わりそうにありません。
今回のイベントをきっかけに当ブログに「終わらないスクラム」というカテゴリを作りました。今後もスクラムの取り組みで得たことを随時発信していきたいと考えていますので、引き続きチェックして頂けますと幸いです。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
