はじめに
こんにちは。KDDIアジャイル開発センター株式会社（KAG）の高橋です。
私は2023年12月現在、8名のエンジニアが所属するチームでスクラムマスターをしています。
普段チームと仕事を進める中で疑問や悩みが生じた際には、書籍を読んだり他チームのスクラムマスターに相談したりすることが多いのですが、
「これって他のスクラムチームではどうやって解決しているんだろう...？」というのが結局のところ最も知りたい情報だと感じます。
おそらく同様に感じている方も多いのではないでしょうか？
そこで今回は同じような要望を持つ方の参考に少しでもなればと思い、私のチームの一日の業務の流れをご紹介したいと思います。
皆さまの所属チームや所属組織でスクラムを実践する上での参考となれば幸いです。
この記事はこのような方々に向けて書いております
- 最近スクラム開発を始めてみたけれど、具体的な一日の流れがイメージできないスクラムチームのメンバー
- スクラム開発をある程度継続しているが、独自進化してしまっていたり行き当たりばったりな形で進めており、適切に運用できているか自信のない方
- 周囲にスクラム開発を運用しているチームや同僚がおらず、スクラムについて相談しづらい環境にいる方
- スクラム開発ってよく聞くけど実際のところどうやって仕事を進めているんだろう、と疑問に思っている方
得られる知識
- 実際に運用されているスクラムチームがどのようにスクラム開発を進めているのか
- 1日の具体的な業務の流れ
- どういう経緯で現在のスタイルにたどり着いたか
前提情報
今回ご紹介するチームの概要は以下の通りです。
- 2015年からスクラム開発を実践中
- 途中メンバーの入れ替えもあり、メンバーの平均年齢は28歳くらい
- 各メンバーのスクラム経験は1年~8年くらい（ほとんどのメンバーがスクラム開発未経験の状態で私のチームにジョイン）
- プロダクト全体でスクラム開発をしているため、大規模スクラム向けのフレームワーク（LeSS）を採用している
- 1スプリント2週間のスパンで回している
- ほぼ完全リモートワークで普段の開発業務を進めている
- 業務時間中はDiscordで音声通話をしながら同期的にコミュニケーションを取れる状態にしている
- 非同期コミュニケーションにはSlackを利用している
1日の業務の流れ（スクラムイベントの無い日の場合）
- 10:00 - 10:20 始業。デイリースクラム（以下DS）に参加
- 10:20 - 10:30 運用担当およびチームの代表者は運用朝会に参加
- 10:30 - 10:50 チームの代表者は引き続きスクラムオブスクラムズ（以下SofS）に参加
- 10:50 - 12:30 DSで決めた内容に従い、ソロやペア、モブで開発業務を実施
- 12:30 - 13:30 昼食
- 13:30 - 17:30 DSで決めた内容に従い、ソロやペア、モブで開発業務を実施
- 17:30 - 18:30 勉強会枠。バックログ関連のタスクは翌日に回し、それ以上進めてはいけない。ただし期限が間近など優先度の高い業務が残っている場合は例外的に対応する
- 18:30 終業。
1日の業務の流れ（詳細）
共通
- 業務時間中は常にDiscordのチームの部屋に入っておき、カメラとマイクはOFFの状態にしておく
- 他のメンバーから話しかけられたらすぐに対応できるようにイヤホンもしくはスピーカーはONにしておく
- Discord外での打ち合わせ中や離席中などでDiscordで話しかけられても対応できない状態の場合はスピーカーミュートにしておき、話しかけられても反応できないことが周りからわかるようにしておく
デイリースクラム(DS)
- アジェンダ（時折見直しております）
1．全体周知（当日の勤怠の確認など）
2．今スプリントのTryの取り組み状況確認
3．バーンダウンチャートの確認
4．各バックログの状況確認および本日進めるサブタスクの担当者決め
5．SofSへ持っていく情報の確認
6．クロージング(共有漏れの確認など) - リモートワーク体制になった現在はDiscordを使った音声通話形式で会議を進行
- カメラのON/OFFはメンバーの判断に一任
- 全員マイクはON
- ファシリテーターはスクラムマスターではなく、チームメンバーが日替わりで担当
- 利用ツールはCacooとJiraで、勤怠周りやバックログ外の情報確認にCacoo、バックログ関連の確認にJiraと使い分けている
運用朝会（※私のチームの独自イベント）
- 私たちの携わるプロダクトは一般のエンドユーザ向けに提供しているアプリケーションである
- このため、運用朝会の中でGAのSorry数やアクティブユーザ数と言ったメトリクスの確認や、バッチ処理でエラーが起きていないか、AWSからのアラートが発生していないかといった監視を行なっている
- チームの作業よりも優先すべき障害や事象が発生している場合はPOに相談の上、そちらの対応を優先する
- なお、運用担当は弊社社員および商用環境での作業権限を持つ特定メンバーにて構成（※詳細は割愛）
スクラムオブスクラムズ(SofS)
- 私たちの開発チームは4チームのスクラムチーム（＋POチーム）により構成されている
- 各チームのDSで上がった課題や相談事項はSofSに集約され、チーム間での解決が図られる
- 上記のほか、各チームのリリーススケジュールおよびブランチ操作、当日の開発環境の利用予定などが調整される
- チームを跨いだPRやドキュメントのレビュー依頼もSofSの中で調整される
開発業務の進め方
- DSにおいて、最も優先度の高いバックログからどのメンバーがサブタスクを取るか話し合って決めていく
- サブタスクの内容に応じてソロ／ペア／モブいずれかの形態で進める
- ペアやモブで進める場合はDSの中で担当者をバイネームで決めておき、別の部屋に移動して音声通話をしながら作業を進める
- ソロで進める場合はチームの部屋にとどまり、話しかけられたら反応できるようにイヤホンやスピーカーはつけておき、自分のタスクを進める
- 私のチームではフロントエンドエンジニアやバックエンドエンジニアといったロールを取っ払い、全員がそのとき最も優先度の高いバックログのサブタスクを進めるようにしている
- 現状、メンバー全員がフルスタックエンジニアを名乗れるほど全ての分野に熟達しているとまでは言えないため、各自のスキルが足りないサブタスクを担当する場合は他のメンバーとペアを組んで進めるようにしている
- サブタスクは3hで完了できるくらいの粒度となっており、1時間に10分程度の小休憩を挟むようにする
勉強会
- 先述の通り、私のチームでは各分野の専任のエンジニアがいるわけではなく、バックエンドだろうとフロントエンドだろうと、全てのメンバーが対応することとしている
- 各自に足りない／身につけたいスキルがあることは全員が認識しているため、これを解消するための施策として17:30以降の時間をチームメンバーがスキルアップをするための枠として割り当てている
- 勉強会への参加や企画は任意であり、AWSなどインフラ周りの知識を確認する回であったり、当日行なったサブタスクの解説をする回であったりと使い方はメンバーに一任されている
- もちろん一人でドキュメントを読んだり、新しい技術トレンドを追いかけてもよいことにしている（そこで得た知見はチーム内やプロダクト全体に還元することを強く推奨している）
今のスタイルにたどり着いた経緯について
Discordの利用
私のチームでは2020年からリモートワーク主体の体制に移行しました。
当時はZoomをはじめとするDiscord以外の様々なオンラインコミュニケーションツールを利用しましたが、最終的にDiscordに定着しました。個人的見解ですが以下が主な要因かなと思います。
- 音声通話の部屋を自由に立てることができる
- 実用的な解像度のある画面共有ができる
- 業務利用に耐えうる程度に安定している
- 社内のセキュリティ規定をクリアしている
- 無料で使える（導入検討段階で気軽に試すことができた）
- チーム内で知っている人がいた
なお、Discordに参加していない外部の方と音声通話をする場合や上司と1on1をする場合など、TeamsやZoomを使うケースもあります。
マイクやカメラのON/OFFについて
カメラのON/OFFについてはかなりのトライアンドエラーを繰り返しました。
朝会くらいはチームメンバーの顔を見ながら進めたいという想いもある反面、
女性はそのためだけに化粧をする必要が出て時間がもったいないという意見があったり、
男性も同じように寝癖を直したり髭を剃る時間がもったいないという意見が出ました。
私個人としては別にすっぴんや寝癖のままカメラに写ってもいいのでは？と思っている派ですが、
私の意見を押し付けるのは違うなと思っておりますし、カメラをONにしなくてもチームが健全にスクラム開発を進めることができるのであれば別にそこにこだわることはないか、と考えました。
こちらについては様々な意見があるかと思いますが、チームやメンバーの状況によって最適解が異なるように思います。
その分、音声通話に関しては全員が常にオンコールであることにこだわっています。
チャットによる非同期コミュニケーションだけでは開発速度に大きな影響が出るのは自明かと思いますが、
一度でも特定の相手に話しかけて応答がなかった場合、次回以降の心理的ハードルが大きく上がります。
そうなると、まずはチャットで「この後話せます？」のような形で相手に確認を取ってから話しかけるようになり、開発速度が低下します。
少し話せば解決するような内容がすぐに解決できないと、今できる他のタスクに着手しようとしてスイッチングコストが発生します。
相手から応答があって元の確認に戻ろうとしたときにまたスイッチングコストが発生します。
最悪の場合、確認したかったことが漏れてしまって後々面倒なことが起きたりします。
上記の流れから、勤務時間中のマイクやカメラの運用については現在の通りとなりました。
運用朝会について
スクラムで定義されているイベントではないため、いったい何だろうと思われた方も多いかと思います。
リモートワーク体制に移行する前は、チームの執務室内の大きなモニターにダッシュボードが常時表示されており、運用に関する状況はそちらとSlackに通知しているジョブ実行結果を監視することで運用していました。
ところがリモートワークに移行しダッシュボードで常時表示しながら確認ということができなくなったこともあり、毎朝運用担当が明示的に集まってメトリクスを確認することとなりました。
さいごに
最後まで目を通していただき、ありがとうございました。
今回は私のチームの一日の業務フローをご紹介しましたが、参考になる情報はありましたでしょうか？
私なりに「外部の方からすると、ここは気になるのでは？」という点を中心に解説も入れたつもりですが、何かご不明な点がありましたらコメントをいただければ幸いです。