こんにちは。STORES ブランドアプリ のバックエンドエンジニアをしているotariidaeです。2024年4月に新卒入社して初めてブログを書きます。
リモートワーク環境下でのスクラムイベントの課題
みなさんはスクラムをやっていますか?透明性・検査・適応を日々実践していますか?
私が所属するチームでも開発プロセスとしてスクラムを採用しています。 また STORES ではリモートワーク中心の働き方になっており、社内の多くの会議はオンラインで行われています。スクラムイベントも例外ではありません。
スクラムイベントをオンラインで実施する上で重要なことは何でしょうか?
そうですね、わいわいスレですね。
オンラインミーティングはともすれば発言が少なくなりがちで、いきいきさが不足しがちです。わいわいスレは雑にわいわいと投稿できるSlackのスレッドのことで、適度なインタラクションを促すことでチームにハリと潤いをもたらす重要な仕組みです。
ただし、このわいわいスレにも課題があります。たまにうっかりスレを立て忘れたり、スレ立てが特定の人に偏っていませんか? わいわいするハードルはできるだけ下げたいものです。 いっそのこと人間ではない者が定時にスレを立てるのが良いかもしれません。
そこでわいわいスレの作成を自動化することにしました。
わいわいスレ建立ワークフローの構築
構築は簡単でした。Slackワークフローで、スケジュールに基づいて定期的に所定の文面を投稿するように設定するだけです。
イベント開始の3分前に設定しているのはささやかな理由があります。わいわいを暖機するためです。ミーティングが始まる前にあらかじめわいわいしておくと、その後の投稿の心理的ハードルが下がります。
デイリースクラムにはさらに工夫があります。 10:30開始ですが、スレは8:30に始まります。デイリースクラムが始まるまでの2時間のうちに各々が発言内容を事前に準備して書き留めておくためです。
私たちのチームにはバックエンド・モバイル・QAでギリギリ両手に納まる人数ほどの開発者がおり、スクラムチームとしては上限ギリギリの大所帯です。しかし、話す内容が事前準備されることで15分のタイムボックス内に納めることができ、また以前よりスプリントゴールのアンブロッキングに焦点を当てられるようになりました。実際に良い効果があったと感じています。
スプリントの進捗管理の課題
デイリースクラムがタイムボックスに納まったとしても、機能不全に陥る要因は他にもあります。例えば、実は進捗が芳しくないのに開発者がそれを認識できていないかもしれません。カンバンボードを一見しただけでは、進度が順調なのか遅れているのかわかりづらいからです。なにか対処方法があるでしょうか?
そうですね、スプリントバーンダウンチャートですね。
バーンダウンチャートでは残作業量が定量的かつ図示されるので一目瞭然です。私たちのチームではカンバンボードにGitHub Projectsを使っていて、Insightsのバーンアップチャート機能を活用できます。デイリースクラムのアジェンダにチャートの確認を加えることで開発者全員がスプリントの現在地を把握できます。
しかし進捗状況をいちいち確認されるのは意図的ではないにせよ地味にプレッシャーになりえます。そうするとますますいきいきさが失われ進捗に悪影響を及ぼしかねませんし、運用が形骸化したり継続しなくなる理由になりえます。いっそのこと人間ではない者が定時に進捗確認するのが良いかもしれません。そうすれば”嫌味”がありません。
そこでスプリントバーンダウンチャートの共有も自動化することにしました。
バーンダウン状況報告bot
GitHub Actionsを利用して毎朝Projectsを集計しSlackに投稿するワークフローを構築しました。
ワークフローのサンプル:
steps: - uses: actions/checkout@v4 - uses: actions/create-github-app-token@v1 # GitHub APIでProjectsのデータを取得するために必要なトークンを生成 id: generate-token with: app-id: ${{ vars.YOUR_GITHUB_APP_ID }} private-key: ${{ secrets.YOUR_GITHUB_APP_PRIVATE_KEY }} owner: ${{ github.repository_owner }} - uses: otariidae/iteration-burndown-status-action@bebacaf320bc63a142fa75294da9ac5a03138a3d # Projectsを集計 id: sprint-stats with: github-token: ${{ steps.generate-token.outputs.token }} login-name: YOUR_ORG_NAME project-number: YOUR_PROJECT_NUMBER # 下記はProjectsの設定値に合わせる point-field-name: Point iteration-field-name: Sprint status-field-name: Status - uses: actions/github-script@v7 # 前段のoutputsからSlackに投稿する文章を構築 id: sprint-stats-text env: REMAINING_BUSINESS_DAYS: ${{ steps.sprint-stats.outputs.remaining-business-days }} with: github-token: ${{ steps.generate-token.outputs.token }} script: | return `今スプリントは残り${process.env.REMAINING_BUSINESS_DAYS}日です。...`; result-encoding: string - uses: slackapi/slack-github-action@v2.0.0 # Slackに投稿 with: errors: true method: chat.postMessage token: ${{ secrets.YOUR_SLACK_APP_BOT_USER_OAUTH_TOKEN }} payload: | channel: YOUR_CHANNEL_ID text: "${{ steps.sprint-stats-text.outputs.result }}"
Projectsの集計には自作のカスタムアクションを使用しました。
なお、チャート画像の生成はちょっと複雑なのでいったん諦め、ひとまず残りの作業量がわかることを優先して、簡素なテキストを投稿するのみに機能を絞っています。ちなみに会社の規定する休業日はまだ考慮できていないので、例えば年末年始をはさむと「今スプリントは残りn%です」の割合がバグります。
このワークフローは始めたてですが、少なくともスプリントの進捗状況が毎日必ず共有される透明性の仕組みは確保できたと思っています。次はこれらの情報をもとにチーム全体でより効果的に今後の作業を適応させられるようにしたいと考えています。
おわりに
私のチームでの開発プロセスにおける自動化の事例を紹介しました。
でもここまで書いておいてなんですが自動化はあくまで補助です。わいわいスレもバーンダウン状況も、それを気にかける人々がいてはじめて効果を発揮できます。スクラムを駆動するのは意欲に満ちた人間です。
偶然にも今日は別チームからもスクラム関連の記事が投稿されています。ぜひこちらもご一読ください。
みなさんも健康的なスクラム生活を!