TL;DR

SREチームでは2週間に1回「改善デー」を設けている
「改善デー」では1日で終わるようなちょっとした改善のみ取り組む

よくある課題

サービス開発を続けていると以下のような要求が出てきます。

ライブラリやツールのバージョンを上げたい
ここを修正すれば開発がちょっと楽になるので修正したい
使っているライブラリやツールの新しい機能を試してみたい
新しいライブラリやツールを検証してみたい
重要度は高くないが脆弱性の対応をしておきたい

等など。
問題はこれらをいつ対応するかです。
みなさんも経験があると思いますが、往々にしてこういった「ちょっとした改善」タスクは後回しにされます。どうしてもメインの機能開発の優先度が高くなってしまうからです。またエンジニア自身でも「やったほうがいいのは間違いないが、ROI的にメインの機能開発のほうがサービスのためになるのでは…？」という考えが頭をよぎってしまい二の足を踏んでしまうこともあるでしょう。しかしこういった「ちょっとした改善」を放っておくと技術的負債になりかねません。
後からまとめてバージョンアップをしようとして非常に工数がかかったり、廃れたライブラリやツールを使い続けてできるだけ触りたくないサービスになってしまったりと、対応を先延ばしにすればするほど対応が大変になってきます。

「ちょっとした改善」への対応パターン

では、どうやって対応していくのがよいでしょうか。以下のような案が考えられます。

気づいたときに気づいた人がやる
当番制にする
定期的に対応する日や時間を決める
開発ロードマップに入れる
どうしようもなくなったときに仕方なく対応する

それぞれに個人的な経験を元に個人的な見解を書いていきます。あくまで'個人的'です。

1. 気づいたときに気づいた人がやる

「ちょっとした改善」をどんどん進めていきたいエンジニアがいればワークすると思いますが、だいたいのケースでその人依存になりがちです。またそういうエンジニアが辞めたりメインの開発が忙しくなってきたりするとワークしなくなることが多いです。

2. 当番制にする

これがフィットする現場もあるかもしれませんが、自分が経験した中では最初はワークしていてもだんだん形骸化しがちです。「今日/今週の当番だれだっけ？」とか「あ、今日/今週は私が当番だった？でも今週中に終わらせないといけない仕事があるから無理かも…」とかなったり、そもそも当番というのがネガティブな印象です。

3. 定期的に対応する日や時間を決める

わりとワークする印象があります。ただ"対応する時間を決める"の場合、その前の時間にやっていたタスクが終わらず改善タスクをこなす時間が潰れることがよくあります。そのため、"対応する日を決める"形式のほうがよいと思います。

4. 開発ロードマップに入れる

「ちょっとした改善」は粒度が細かく数も多いのでロードマップに入れにくいです。

5. どうしようもなくなったときに仕方なく対応する

悲しいですが現実としてこのパターンになることもあります。弊チームでもあります。

SREチームは「改善デー」を採用

色々と考えた結果、SREチームでは「改善デー」を採用しました。「改善デー」とは2週間に1回、改善タスクのみをこなす日です。曜日は金曜日にしています。金曜に改善をすると気持ちよく休日を迎えられそうだからです。

しかしただ単に改善デーを設けるだけでは形骸化してしまうリスクがあります。そこで弊チームでは以下のような工夫をしています。

目標に入れる

これはかなり重要で、目標達成が評価につながる会社(ほとんどの会社がそうですが)では、目標に入っていないタスクを行うインセンティブが働きづらくなってしまいます。

改善タスクの消化は定量化しづらいので目標に入れづらいとは思いますが、なんとかして入れたほうがいいと思っています。

メンバーと目線を合わせる

一部のメンバーだけが張り切ってもうまくいきません。チームメンバー全員に改善タスクを継続的に消化することの意義をしっかり理解してもらうことが重要です。

改善デーが始まったらアナウンスをする

改善デーになったら「今日は改善デーです」とSlackでアナウンスをしています。これにより「他のタスクはしないでね」という暗黙的な周知になります。また各自「今日、私はこのタスクをやります」と宣言するのも効果的です。

改善タスクを事前に用意しておく

常日頃から「ちょっとした改善」をタスク管理ツールに登録しておくと改善デー当日スムーズに取りかかれます。
ここで重要なのは、 「1日程度で終わるタスクのみを改善タスクとして積むこと」 です。
取り掛かってみて1日で終わらないタスクが出てくることは仕方ないですが、取り掛かる前から1日で終わらないと分かるタスクであれば プロダクトバックログやロードマップ等にいれたほうがよいでしょう。 1日で終わらないタスクになると2週間後の改善デーにやることになり、どんな作業状況だったのか忘れがちです。

リーダーが強い意志を持つ

これが一番重要かもしれません。リーダーが強い意志を持ってないとどうしてもメインの開発タスクや他のチームからの依頼を優先してしまいがちです。またリーダーが率先して改善デーに取り組まないとメンバーはついてこないでしょう。

「改善デー」を続けてみてどうだったか

改善デーを実施し始めて半年以上が経過しましたが、非常に良いと感じています。 14年くらいエンジニアをやってきて改善タスクを継続的に消化する仕組みづくりができてる現場はほとんどなかったり、もしくは自分自身が仕組みを作ることができなかったりしていたのですが、初めて手応えを感じています。

特に、精神衛生上、非常に良いと感じています。
日々の開発の中で「ここを改善したい…」という部分は少なからず出てきますが、それは意外とストレスになっていたりします。気になっていたタスクを「改善デー」で消化していくことはとても気持ちが良いものです。

また、中にはちょっとした修正で時たま発生する繰り返し作業(トイル)が無くせたり、ちょっと便利になって生産性が地味に上がったりするものもあったりして、やってよかったなと思うことが少なくありません。

ちなみに現在SREチームの人数は2人ですが、2週間に1回、一人が1タスク消化したら一年間(=50週だとして)で50タスクも消化できることになります。凄いですね。

問題点

完璧な仕組みとは無いもので、問題点もあります。

1日で終わるような簡単な改善タスクは改善デーで消化できますが、1日で終わらず例えば2,3日かかるような改善タスクが溜まりがちになっています。これに関してはプロダクトバックログに入れて意識的に消化していこうと思っています。

まとめ

SREチームでの「ちょっとした改善」への取り組み方をご紹介しました。 SREチームでは「改善デー」というやり方がフィットしましたが、きっとチームごとに最適なやり方が存在すると思うので、いろいろなやり方を試していくとよいと思います。他にもうちではこういう取り組みをしているよというのがあればぜひ教えて下さい。