スクラムの合間 月１度に開かれるお祭りの日

背景

会社やチームの文化って会社によって本当にガラッと大きく変わりますよね。

夜遅くまで勉強会をして、技術・知識の交換をしたり・・・
会社のブランディングのために技術記事を出したり・・・
ボードゲームやテレビゲームをして進行を深めたり・・・

私のチームでは開発に困ったことに関しては業務時間内で勉強会を開くことはありますが、
基本的にはプロダクト開発に全振り。お手本のようなスクラム開発でスキマ時間等というものは存在せず、
やるものはすべてProduct Backlogに積んだItemだけに限ります。
例外は、オンコール業務(CSの問い合わせ対応、エラーログやパフォーマンスのモニタリング)とデザイナ・POとの仕様検討ぐらいに収束されます。
とにかく時間があったら効率的にプロダクトの価値創出に全力を注ぎたい！！！という人たちが集まるチームとなっています。

そうすると、こんな疑問を持つ人がいるかも知れません。ライブラリのアップデートとかインフラ環境の見直しとか、プロダクト課題ではない、「エンジニアリング課題ってどう扱ってるんだ？ 」です。これはスクラム開発では必ず起きうる課題だと思いますが、Team Product Backlogというエンジニアが自由に課題を上げるバックログが存在します。毎週リファインメント前に、来週(早いタイミング)でやるべき課題をチームで話し合い大体毎スプリント1~3割程度、POに相談(基本的には開発チームを信頼して追加させてくれます)して着手します。

しかし、ここで大事なのが来週(早いタイミング)でやるべき課題しか扱えない点にあります。厳密な基準は存在しませんが、開発時に頻繁に障害になる部分を取り除きたい・このままだと顧客のUXが損なわれる・セキュリティリスクが高いなどが説明できるものではない　かつ　ROI(投資に対するリターン)が高く無ければ、扱うことができないのです・・・！

そこで月1回のお祭り！

基本的にはプロダクト価値を出すことに脳汁を出す人たちですが、やっぱりROIが低いかもしれないけど、自動化したい。新しいことを学びたい・・・。そんな感情が高まってきます。そんな鬱憤を晴らすために生まれた日が月１度のお祭りの日です。ルールは以下そのまま転記してきました。(Draco Fest. == チームのお祭り名)

【Draco Fest. 概要】
スプリントの開発とは別で、個人的に優先度あげてやりたいもの・改善施策(プロダクトに関わるモノ)や、将来プロダクトに活かせそうな技術の調査などをやる日
【Draco Fest. ルール】
やるPBIを選択、もしくはPBIを作成して今スプリントにいれてください
Epic Linkに “Draco fest.” を設定してください
Draco Fest. で扱うPBIに関しては、本日のリリースはナシです
不具合系のものなどを取り扱う場合は、原則次のスプリント以降にテスト・リリース
QAのお二人の協力が得られる・テストがすでにある（ACを満たせる）、かつDoneの定義を満たせるならばOK
 終了は17:00、17:00〜各々どんなことやったのか発表してもらいます（カレンダー抑え済）

本当に個人のための自由時間と言うわけではありませんが、プロダクトに活かせるだろうというものならなんでも良いです。チームの状態がいつ変わるかはわかりませんが、現状ではこれぐらいの息抜きがチームにとって一番のご褒美、最適なスケジュールと感じています。

お祭りの内容

実際にお祭りではどんな内容をやっているのでしょうか？

私は今月は以下のような活動をしました。

• ファシリテーションをランダムで決めるシャッフルーレットツールの改善
  • 個人的に作ったツールで、誰がやるー？っていう時間を無くして意思決定を早くしたかったです
• masterマージしたときにリリースタグを自動生成するやつ
  • そのままです。うちのチームはバージョンを1.スプリント番号.PBIごとに0からインクリメント。のようなルールでやったり、JIRAのリンクを貼ったりする必要があるので、トイルだなーと感じて今回作りました。GitHub Actionsを初めて触って楽しかったです。
• Elmのプロジェクトをpercelからviteへ変える
  • Elmの環境をいじるのが、大好き過ぎるのでやりました。セキュリティリスクが減って満足しています。

他の方の活動は以下でした。

• 検証環境の夜間・早朝の停止バッチ作成
  • 会社の経済を考えていて、とても素晴らしい試みですね！
• E2E(Cypress)の並列実行
  • ちょっと今回はできなくて残念でしたが、リリース前に1hほど掛かるので、速度アップは生産性向上にかなり寄与しそうです!
• pre-commitの整備
  • 稀commit前のprettierが発火しない人がいるので、地味にムカつくやーつです
• タイムゾーンの都合で落ちるテストがある
  • これうごご・・・です。人類から時間と言いう概念をなくしたい
• Slack通知の改善
  • Slack通知の万人です。やはりたまにチューニングしないとノイズになったり、漏れたり大変ですからね

終わりに

チームの文化は働いている環境によって様々です。良い文化・悪い文化なんていう絶対的な指標は無いと思います。ただ、働き方に変化をもたらすことで幸福度が上がったり、生産性が上がったり効果は絶大なので、日々変えていけたらなーと思います。もし似た環境でお祭り文化を取り入れたいという組織の方は是非参考にしてください。それでは！