技術的負債を解消して開発生産性を高める『SparkJoy Day』という取り組み

本記事は「開発生産性 Advent Calendar 2023」の24日目の記事です🎄

はじめに

本記事では、技術的負債を解消して開発生産性を高めるために弊社で実施している『SparkJoy Day』という取り組みを紹介します。

弊社では、重要度は低くないが緊急度の低い技術課題のチケットが溜まっていく状況が発生し、チリツモで開発速度や障害発生率などに影響してきていたため、それを解消する取り組みとして数年前から定期的に『SparkJoy Day』という取り組みを実施しています。

『SparkJoy Day』とは

『SparkJoy Day』とは一言で言うと、
「ときめかないものを手放すべく、エンジニアが1日集中して技術課題の対応を行う日」
になります。

日々のタスクやMTGを一切行わず、丸一日エンジニア全員で集中して技術課題の対応を行うことで、一気に技術的負債の解消を目指します。

重要度が高い技術課題の中でもタスクの大きさが大きいものについては、弊社ではEnablingチームが主導して目標と計画を立てて対応しているので、SparkJoy Dayでは主にリファクタリングや不要コードの削除、パフォーマンス改善、緊急ではない不具合解消などタスクの大きさがそこまで大きくないものの対応を行っています。

実施方法

それでは、具体的な実施方法について説明します。

頻度

頻度については現在月1で実施しています。

エンジニアがリモートの日、かつ、祝日がなくリスケの起きない毎月第2木曜日に定期的に実施しています。

ちなみに、来年は毎月第2木曜日は1日も祝日が被っていないため、リスケの心配はありません。

前日までにやること（事前準備）

1. PdMへの共有

SparkJoy Day当日はエンジニアにMTGを入れるのを控えてもらうよう予めPdMにアナウンスします。
継続して開催していくにはPdMや周りのメンバーの理解と協力が必須です。

2. チケットにSparkJoyラベルを付ける

各自SparkJoy Dayで対応したい技術課題があればJIRAのチケットを起票し、SparkJoyラベルを付けます。
技術的負債の返済や開発者体験・生産性を向上させるものであれば細かい基準は設けず各自自由に付けるようにしています。

一例として、今JIRAを見てみると以下のようなチケットに付いていました。

3. 起票したチケットの優先度を更新

ラベルを付けた後は、各自で以下の基準でチケットの優先度を更新します。

• High
  • ユーザー影響のある不具合（※緊急度の高いものはSparkJoy Dayを待たずに対応）
  • トラフィックの多いページのパフォーマンス改善
  • 多くの人がよく触る部分のリファクタリング・不要コード削除
  • 開発者体験や生産性を大きく改善するもの
• Medium
  • ユーザー影響のない不具合
  • パフォーマンス改善
  • たまに触る部分のリファクタリング
  • 開発者体験や生産性を改善するもの
  • その他、すぐ対応しなくても大きな影響はないがチリツモで開発生産性を下げているもの

4. 対応したいチケットを自分にアサイン

前日までに優先度Highのものから順に各自で以下の基準で対応したいものを自分にアサインします。

• 基準
  • 起票者 or ドメインに詳しい人 or 思い入れが強い人
  • 工数次第だが、1人1〜3チケットくらい
  • 優先度HighのものがなければMediumでもOK

当日の流れ

既にタスクは割り振っているので、当日は朝から集中して各自タスクを対応していきます。

とはいえ、黙々やるだけだと寂しいので、お祭り感を出すため＆質問しやすいようにSparkJoy Day用のSlackチャンネルを用意していて、当日はそちらで実況中継や質問し合いながら時に黙々、時にわいわいしながら作業を進めます。

着手するチケットを共有したり、

わいわいしたり、

実況中継したり、質問したり。

自身の持っているタスクが終わったら優先度の高いものから順に新しいチケットを取って行きます。

最後には、『SparkJoy Day DOYA!』という自身が対応した内容を共有する会を設けて、みんなの前で発表します。

前回の事例だと、劇的なパフォーマンス改善があったり、誰も突き止められなかったデッドロックの原因が突き止められたり、1日で大きな成果に繋がることもあります。

実施結果

所感

個人的には、日々機能開発をしていく中でチリツモで溜まっていく技術的負債を定期的に解消する仕組みがあることはとても良いことだと感じています。

もちろん負債を残さないに越したことはないですが、ユーザーに速く価値を届けるために時には負債を受け入れて機能開発をすることもあるかと思います。

そういった時にこのような仕組みがあると、負債が放置されず、開発速度や障害発生率が徐々に悪化していくといったことが一定防げます。

また、みんなでお祭り感を持って技術的負債を解消することで、システムに対する理解や愛着が深まったりすることも良い点の1つかなと思います。

アンケート結果

他のエンジニアメンバーのアンケート結果についても共有します。

一時期組織の改編に伴いSparkJoy Dayをお休みしていて今年の7月に久しぶりに再開したのですが、その際に取ったアンケートでは「またやりたい」が100%という結果となり、参加したエンジニアの満足度はとても高くなっています。

また、MTGや他のタスクの割り込みがないため、みんな集中して開発に取り組めているようです。

感想や要望も聞いてみたところ、以下のような声が寄せられました。

普段なかなか技術課題に時間が取れないのでまとまった時間が取れてよかった！

技術課題に集中して取り組める日があることでリリースまで持っていけるものはどんどん解決していけそうと感じました。またやってみたいと思います。

当日で実装はするけど、リリースまで持っていけないとつい後回しにしてしまったり、規模が大きいものや調査タスクはは1日では終わりきらなかったりするので、頭を使わない作業日に当てられると充実度高そうです。

今後の課題

SparkJoy Day当日中に終わらなかったタスクをどうするかについてはまだまだ改善の余地がありそうです。

今は普段の業務の中で続きをやるか、次のSparkJoy Dayに回すかしているのですが、どちらもメリット・デメリットがあるので、Qに1回くらいはSparkJoy Days的な感じで2〜3日取ってSparkJoy Dayをやってみるのも良いかなと思ったりしています。

まとめ

弊社で実施している『SparkJoy Day』の取り組みを紹介しました。

弊社では『SparkJoy Day』のおかげで定期的に技術的負債を解消でき、開発生産性の向上に一定の貢献をしています。

何かしら皆さまの参考になれば幸いです。