Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

モバイルアプリ開発チームのスクラムってどんな感じ?

こんにちは!モバイルアプリケーション開発部でスクラムマスターをしている折田 (@orimomo)です。

私たちの部署ではiOSエンジニア・Androidエンジニアが混在する2つのチームを作り、それぞれでスクラムによる開発をおこなっています。

私自身もともとはiOSエンジニアなのですが、現在は専任のスクラムマスターとして両チームに関わらせてもらっています。 最近では各々の継続的な改善が実を結び、スクラムチームとして少しずつ、しかし確実に成長ができているなと感じられるようになりました。 「スクラムが楽しくなってきた!」「いいチームになってきた気がする!」という話をメンバーから聞くことも増え(嬉しい🙌)、ここまで色々あったなぁ…長かったなぁ…と感慨深く思っています。

今回は、そんな私たちが具体的にどのようにスクラムを回しているのか、また以前と比べてどのように変化してきたのかについてご紹介ができればと思います。(ここでは「スクラムとは何か?」といった基本的な説明は割愛させていただきますのでご了承ください)

なお、10/7(金)に開催される弊社主催のオンラインテックカンファレンス『Chatwork Product Day 2022』の盛り上げ企画として、今月は弊社社員がほぼ毎日ブログを投稿しており、本記事もその一環となります。当日は私もスクラムの枠で登壇予定です。イベント登録がまだの方、ぜひご登録よろしくお願いします!

lp.chatwork.com

チーム構成

2022年9月時点の部署全体のメンバー数は10人(+ 業務委託3人)で、赤がトレードマークのRouge(ルージュ)チームと、黒がトレードマークのNoir(ノワール)チームに分かれています。 Rouge・Noirというのはフランス語で赤・黒を意味していて、チャットワークカラーにちなんで付けた名前です🫶

スクラムマスター1人(私)とプロダクトオーナー1人が、両方のチームを見る構成になっています。

マネージャーはどちらのチームにも属さずに見守ってくれている

ここに至るまでのチーム構成の変遷については、マネージャーの福井が書いている以下の記事をご覧ください。

creators-note.chatwork.com

スクラムイベント

スプリント期間は1週間(月曜日〜金曜日)で、各イベントは以下のようなスケジュールになっています。 スクラムマスター1人で2チームを見ている都合上、スプリント期間やイベントの開催タイミングはなるべく揃えてもらう形で設計をしました。

スプリントプランニング

毎週月曜日、各チームごとに30分でおこなっています。

参加者は開発者・プロダクトオーナー・スクラムマスターです。

流れとしては

  • 前週のふりかえりで決めたアクション事項の確認
  • キャパシティ把握のためのカレンダー確認
  • 作業内容の決定
    • 前回のスプリントから引き継いだチケットがあれば確認
    • 今回新しくスプリントに入れるチケットを確認
    • ベロシティをもとに、チケットの分量を調整
  • スプリントゴールの確定
  • 全員でコミット
  • スプリント開始

という感じになっています。

後述のバックログリファインメントが充実してきたおかげで、プランニングは大幅に時間短縮されました。 また以前はチケットの内容が何も書かれていなかったりして時間がかかっていたのですが、「プランニング開始時までにチケットをReady(=開発する準備ができている状態)にしておこう」というルールが浸透してきてからは、作業内容やDone定義も事前に埋められるようになり、とてもテンポ良く進むようになりました。

ファシリテーションに関して、初期はスクラムマスターのみでおこなっていたのですが、今では開発者全員が持ち回りでおこなうようになっています。

持ち回り制を導入する際、ファシリテーションが得意でない開発者も当然いるので、誰でも安心してできるように手順書を作って共有したのですが、その評判が上々でした。

「スプリントプランニングのやり方」

現場は常に忙しいので、普段のタスクに加えてスクラムのことまでやってほしいと丸投げされたりすると、キャパオーバーでついつい拒否反応が出てしまうこともあると思います。 その結果スクラムが嫌になって形骸化してしまう、なんてことになったらもったいないですよね。

そうならないよう、なるべく開発者の負担にならない形で寄り添いつつ、でも任せられそうなところは思い切って任せていく(そして気づいたらスクラムマスターがいなくても回るチームになっている)というのが理想だと思っているので、そのあたりのバランスには気をつけるようにしています。

ファシリテーターをやるとチケット消化への意識が高まったり、プランニングでの議論を有意義なものにしようという気持ちが芽生えたりするそうなので、持ち回り制は非常にオススメです✌

デイリースクラム

火曜日〜金曜日、各チームごとに15分でおこなっています。

参加者は開発者・スクラムマスターで、ファシリテーターは持ち回りで担当しています。

流れとしては

  • カレンダーでその日の予定確認
  • その日の作業内容を各自共有
  • バーンダウンチャートでゴールに対する進捗確認
  • タスクボードで各チケットの進捗確認や相談
  • ファイブフィンガー
    • 仕事の状況について
    • 体調・プライベートについて
  • 雑談

という感じになっています。

miroでチームボードを作り、それを見ながらデイリースクラムをしていたこともあるのですが、miroの自由度の高さゆえにコンテンツが充実しすぎてしまい、15分のタイムボックスが守りずらくなっていた側面もあったので、今ではシンプルなこの形に落ち着いています。

ファイブフィンガーは、状況や気持ちを5段階で表明する手法で、問題・障害物の早めの検知と、問題を抱えている人をチームでサポートできるようにする目的でおこなっています。

以下の専用チャットにて1~5を各自が投稿し、低い数字に対しては、チームとして何かできることはないか?を話し合っています。 「昨日見た映画が楽しかったから 5」や「所有している馬が勝ったから 5」、「冷蔵庫が壊れてしまったから 1」など、メンバーのプライベートが垣間見えたり、その後の雑談のきっかけになったりもして、開発者からも「楽しい」と評判のワークです。

ファイブフィンガー専用チャット

ちなみにデイリースクラムでの私はあまりしゃべらず、基本ミュートにして観察しています👀 15分しかない貴重な時間をなるべく開発者同士のコミュニケーションに充ててほしいと思っていて、ここでの会話や雰囲気を見て、その週のふりかえりをどう設計しようか考えていたりします。

バックログリファインメント

毎週木曜日、2チーム合同で1時間でおこなっています。 合同でおこなう理由は、2チームが同じバックログを使っており、チームをまたいで作業(レビューなど)が発生するケースがあるためです。

参加者は開発者・プロダクトオーナー・スクラムマスターで、ファシリテーションはプロダクトオーナーがおこないます。

流れとしては

  • 新しく追加されたチケットの内容確認と優先順位付け
  • 次スプリントでやるチケットを優先順に並べる
    • プロダクトオーナーが次スプリントでやってほしいチケットを共有
    • 開発者が次スプリントでやりたいチケットを共有
  • 次スプリントのスプリントゴールを仮決め
  • チームの中長期計画についての認識合わせ

という感じになっています。

コンテンツが盛りだくさんなのですが、各ロールで事前にチケットの並べ替えなどをしておくことで、ギリギリ1時間で収めることができています。

リファインメント当日、自動で流れるリマインド

この会のおかげで、自分たちの来週以降の動きがイメージできるようになり、やるべきチケットや仮のスプリントゴールが出揃うことでスプリントプランニングの時間短縮にもつながっています。

プロダクトバックログに関して、実は半年前はチケットが350件以上(!)積まれており、メンバーの誰一人として全貌把握ができていないカオスな状況でした😱 そこからせっせと仕分けをおこない、今では100件ほどに収まっています(100件でも多いやん!と思われる方もいらっしゃると思いますが、2チーム合同で使っている歴史あるバックログであり、かつiOSとAndroidのチケットが混在しているので、今は一旦ここまででいいかな…と思っていたり)。

割れ窓理論じゃないですが、カオスなまま放置しておくと、どんどんカオスさは増すばかりなので、大変ではありましたが一定ドラスティックに整理をしたことは、今振り返ると良い決断だったと思います。

それと同時にプロダクトバックログの運用方法も見直し、ルールに基づいてチケットが並べられるようになったので、見通しは着実に良くなってきていると感じています。

最近ではプロダクトオーナーを中心にチケット棚卸し会を定期実施するようになっていたりもして、引き続きチケットが増えすぎないように工夫していきたい所存です。

スプリントレビュー

毎週金曜日、ふりかえりの前に、2チーム合同で1時間でおこなっています。

参加者は開発者・プロダクトオーナー・スクラムマスター、必要なステークホルダーもお呼びします。 お互いのチームをステークホルダーと見立てて、フィードバックを出し合っているのも特徴的かもしれません。 ファシリテーションは今のところスクラムマスターの私がおこなっています。

流れとしては

  • スプリントサマリーの共有
    • ゴールの達成状況
    • 完了したチケット・完了しなかったチケットの確認
  • スプリントの成果のレビュー
    • 開発者からの説明やデモ
    • 他の人からの質問やフィードバック
    • 必要があれば来週のアクションとして積む
  • 「お疲れ様でした」の拍手👏

という感じです。

実はスプリントレビューをやるようになったのはごく最近のことで、「毎週見せるものなんてあるのかな?」という不安や、導入を一度断念した過去もあったりして、これまでは実施を見送っていました。 しかし「時は満ちた!」ということで実際やってみると、参加者からのフィードバックによって新しいチケットが生まれたり、実装担当者だけでは気づかなかった見落としに気づけたりしていて、アウトプットに対する検査適応のループが回り始めたのを実感しています。

また、これまではチーム間でやっていることを共有するためのミーティングが毎週入っていたのですが、スプリントレビューをやるようになってからは、そのミーティングは不要となり廃止されました。 スクラムガイドに以下のような文言があるのですが、

スクラムにおけるイベントは、(中略)スクラムで定義されていない会議の必要性を最小限に抑えるために用いられる

まさに廃止された共有ミーティングはスプリントレビューがなかったために存在していた副産物のようなものだったんだなぁ...と今では思っています。

なお、スプリントレビュー導入にあたっては、「なぜやるのか」「具体的にどんな準備が必要になるのか」などを私から両チーム・プロダクトオーナーに詳しく説明する時間を設けさせてもらい、質疑応答などを通じて事前にみんなの不安が解消されるよう心がけました。 レビューの場がなるべく安全で前向きなものとなり、メンバーが達成感を持って週末を迎えられるように、以下のような約束を作ったのも工夫の一つかもしれません。

スプリントレビューでのお約束

その甲斐あってか、大きな混乱が起こることもなくイベントとして定着しています。今後も様子を見つつ、みんなで改善していけたらと思っています。

レトロスペクティブ

毎週金曜日、各チームごとに30分〜1時間かけておこなっています。

参加者は開発者・スクラムマスター・プロダクトオーナー(任意参加)で、ファシリテーションはスクラムマスターがおこなっています。

流れとしては

  • スプリント結果の確認
    • バーンダウンチャート
    • コミット達成率やベロシティ推移
    • ゴールを達成できたかどうか
  • ふりかえりのワーク
  • 来週やってみるネクストアクションを決定
  • スプリント終了

という感じです。

改善のサイクルや、チームの心理的安全性を生み出す肝となるイベントなので、スクラムマスターとしては一番力を入れていたりします。

ふりかえりのワークではmiroを使っており、チームの状況に合わせて10~20種類ほどの手法を使い分けています。同じ手法を使っても、片方のチームではすごくいい感じなのに、もう片方のチームには合わなかったりして、ふりかえりは本当に奥深いです。

ふりかえりワークの一例

ふりかえりの手法については以下の記事に詳しくまとめていますので、よければこちらもご覧ください。

creators-note.chatwork.com

ちょっと前までは、せっかくネクストアクションを決めても存在が忘れられてしまったり、そもそもアクションが SMART になっていなかったりして、実行されないことが多々ありました。 しかし最近ではチームチャットの概要欄にアクションを書いて目につくようにしたり、デイリースクラムで今週のアクションの進捗をチェックするようにしたりと、地道な取り組みをチームごとにおこなうことで、毎週実行できるようになってきています。

「実験的に新しいことをやってみる」というのにみんなが慣れ、以前よりも変化に対する抵抗感が減っているように見えるのも、毎週ふりかえりを続けてきた効果だと思います。

次のステップとしては、ファシリテーターの役割をチームに移譲し、スクラムマスター抜きでも今の改善のサイクルを維持(というか更にパワーアップ?)してもらうことかなぁと考えていたりします😋

最後に

以上のように、スクラムの型はようやくできてきた印象で、ベロシティも安定し、チームとして少しずつ成熟してきているように感じています。 その上で、スクラムをやるのが目的なのではなく、スクラムを使っていかに開発しやすくするか?にフォーカスできている点も、手前味噌ながら良い点だと考えています。 (個人的には今よりも開発がしやすくみんなハッピーになるのであれば、スクラム以外のアジャイルフレームワークを採用するのも全然ありだと思っていて、最近は来たるべき時に備えてこっそりカンバンを勉強していたりします🤫)

まだまだ改善すべき点はあるものの、今後は各々が「自分のチーム」から一歩踏み出して、チーム外との「関係性」にも踏み込んでいってもらえたら、今よりも格段に強いチームになれるのではないか、とスクラムマスター視点では思っています。

今月は新しいメンバーが二人も入社してくれたり🎉、年明けにはチームの責務を明確にするためのメンバー替えを予定していたりと、チームの形は絶えず変わり、そのたびに新しい問題が出てくるはずです。 でもその都度みんなで立ち止まって考えて、最適な形を目指して改善し続けていくことができたら、何も怖いものはなく、むしろ変化を楽しめそうな気がしてきませんか? スクラムを通してそんなチームに近づけたらいいなぁと思いますし、微力ながらそのお手伝いができるよう、これからも楽しくまったりと精進していこうと思う今日この頃です。

私たちの部署ではメンバーを絶賛募集中です! 少しでも興味を持ってくださった方、お気軽にご応募いただけると嬉しいです。

meety.net

hrmos.co