機能開発と技術的負債の返済を両立させるシステム改善Dayのすすめ

自己紹介

こんにちは。関西開発拠点でエンジニアをしている辻です。

季節の変わり目でお芋が美味しいシーズンになってきました。最近は芋味のアイスやケーキばかり食べてて体重が右肩上がりです。

今回は、マネーフォワードクラウド会計Plus（以下、会計Plus）の開発チームで行った「システム改善デー」について書かせて頂こうかなと思います。

会計Plusが抱えていた課題

リリースから機能開発を優先してきた結果、技術的負債が溜まってきていた点
その技術的負債の解消を行うにしてもリソースの確保が難しい点

会計Plusは2020年2月26日にリリースしたサービスで、開発開始となると更に半年以上遡ることになり現在で約3年ちょっと開発・運用をしてきました。おかげさまで導入企業様も順調に増えておりますが、同様に増えて来ているのが技術的負債です。これまではユーザに価値を届けるための機能開発にリソースを集中的に投資してきましたが、今後10年価値を届け続けられるプロダクトにしていくためにはそのリソース配分を徐々に保守運用、いわゆる技術的負債の解消という側面にも配分していくというフェーズになってきたと感じている今日このごろです。とはいえ、まだまだユーザーに届けたい価値は山積みで決して機能開発の手を緩めて良いという時期でも無いのも事実だったりします。こういった技術的負債解消をしなければ破綻する未来が見えてるにも関わらず、新規の機能開発要望はどんどん上がってくるというジレンマは世に存在する多くのサービス・技術者が抱えてると思います。結局の所、どうリソースを配分するべきなのか・・・という悩みにつきますね。

改善に向けて試した事と結果

1スプリント内のリソースの内数十%を負債解消に充ててみる
スプリントチームを分断して技術的負債解消だけを目的にしたチームを作成してみる

取り敢えず試してみたことは、恐らく最も理想的な手法と思われる、使えるリソースの数十%を技術的負債の解消というタスクを消化することに費やすという取り決めを行う、というものです。

1週間のスプリントの中でどのプロダクトバックログアイテム（以下、PBI）を積むか議論する際、予めこの数十%を見込んで負債解消のPBIを積んでおきます。リソースの一定割合を負債の解消に充てるということをプロダクトオーナーと合意が取れているので理論上は問題なく開発も進み、技術的負債も徐々に解消されていくはずでした。

しかし、実際にこのような運用を経験された方はわかると思いますが、はじめこそ上手く運用できていたとしても、リリース日が近づいた新規の機能開発等の開発遅れなどが生じた際には、そちらへのリソース配分を増やさざるを得なくなくなります。結果的に負債解消への投資が後回しになり、最終的には機能開発一辺倒になってしまいがちです。実際私達のチームでもこのような状態に陥ってしまいました。

他にも改善チームと言う名の新規機能開発には携わらない、技術的負債の解消を目的にしたチームを編成するということも試しました。

チームを明確に分けたことによって最初は負債解消にコミットできていました。しかし、機能開発側のチームのリソース不足を招いてしまい、機能開発を進捗させるために改善チームを機能開発側に再度合流させるしかない状況になってしまいました。

システム改善DAYの開催

こういった失敗を踏まえてチームメンバーでどうすれば現実的なリソースで効果的に技術的負債を解消できるのかを改めて話し合いました。

まずはどれだけの技術的負債が認知され放置されているのかを明確化するため、チームメンバー各々が感じている技術的負債を列挙してみました。

当初の予想としては、パフォーマンスの悪い機能の速度改善やバージョンの古いライブラリの更新といった物が大半を占め、メンバー間でも意見が被るかなと思っていました。しかし、実際に列挙してみるとその粒度は非常に多種多様でほとんどメンバー間で被りがないものでした。(規模の大きい物だとMySQLのバージョンアップ等、規模の小さい物だと不要になったファイルの削除等) このワークショップを経て感じたことは、自分が想像していた以上に技術的負債と認識されているものが多岐に渡っているという点と大した投資をしなくても解消できる、例えば「不要なAPIコールを減らす」といったローリスクミドルリターンな負債が非常に多そうという点でした。つまり、実装・修正に1日もかからない物が多数存在していたということに改めて気付かされました。

そうとなれば話は早いと言うことで1日中、技術的負債の解消のみに集中する「システム改善Day」なるものを開催してみることにしました。

ただ、単純に黙々と作業するだけではマネーフォワードで掲げているFunのカルチャーに反すると言うことでゲーム形式とする事にしました。

具体的には、以下のような要項で実施しました。

開催要項

ルール
- 自身が行いたい改善内容を宣言しチケットを起票する
- 1つ目の改善が完了した者は2つ目の内容を宣言し着手することができる
- ユーザ問い合わせ・他部署からの問い合わせはシャットアウトする
- 最終的に完了した改善に対して「いい改善」と思ったものに全員で投票し「改善王」を決める

チケット起票時に内容被りが起きないよう宣言と共有をしたり、改善対象はユーザインターフェースに影響しないものに限定するなど工夫しています。

完了した改善チケットのコードレビュアーはルーレットでランダムに選出する仕組みを行い、レビュアーにアサインされた場合は改善作業を止めてコードレビューを優先するようにしました。

投票は1人3票まで可能とし、最終的に得票数が最も多い人が改善王の称号を得るようにしています。

また改善王だけでなく、副本部長が直接選ぶ副本部長賞も用意しました。

タイムテーブル

10:00 ~ 10:15 ルール説明
10:15 ~ 10:45 各々のテーマを決める
10:45 ~ 11:00 テーマの共有・質問
11:00 ~ 18:00 実装タイム
18:00 ~ 18:30 成果発表 & 投票
18:30 ~ 懇親会

やってみた結果

システム改善Dayを実施した結果は以下のとおりでした。

第1回

やる内容は下記のような感じで付箋出しして開始前にメンバー間で共有してました。

他の詳細は伏せますが、私がやろうとしていた内容は下記の様な感じで主に速度改善系を中心に取り組んでました。

そしてチーム全体の結果はこのような感じです。

作成されたPR数: 61件

マージされたPR数: 55件

画像はFindy -Teams+上でのアクティビティ数

普段が開発ではだいたい1日10件から15件くらいなので大体4倍くらいのアウトプットが出せた感じです。

個人的な感想としては

時間が明確に決まっているので無茶な事は行わず確実に終わらせるようにみんなが動いた
競争性をもたせた事により普段以上に集中力が高かった
外音を遮断したことによりコンテキストのスイッチがなくなり更に集中力を増せた

という感じで、敢えて1日という決められた時間内でやったことが効果をあげたのかなという印象でした。

ただ、実際にやってみて見えてきた問題もあり

レビュアーをランダムに選んだが故に偏りが生まれた
みんながどういったことをやったか把握できなかったので投票の時どれに入れるか凄く迷った
集中的に行ったため疲労感が高かった

という具合でした。

ちなみにですが、晴れて第1回改善王に選ばれたのは・・・・・・・。

なんと私でした。

選ばれた内容は付箋にもあげてありましたが、ある機能のN+1問題を解消させたというものでした。

ネタ的にN+1問題の解消というのは印象・インパクトが強いというのもあって選ばれたのかなというお気持ちがありつつも、素直にうれしかったです。

その時作ったPRがこれです。

細かい部分は伏せますがrailsあるあるというか新規機能追加で追加されたテーブルがpreloadの対象から外れてることでN+1が起きていたという問題でした・・・。

そして初代副本部長賞に選ばれたのは・・・・・・。

Goのバージョンアップを行った @uji_rb さんでした。おめでとうございます！なかなか手を付けれずに塩漬けにしてしまってたバージョンアップ対応（v1.16 → v1.19）をしゅっと対応してくれた @uji_rb には感謝です。

もちろんその他にも様々な改善がなされ、企画としては大成功となりました。

第2回

実は第2回も既に開催しました。

第2回は第1回の反省点を踏まえて以下のルールを追加することにしました。

終了時間を1時間巻いて、自身が行った改善を5分間プレゼンタイムに充て互いに行った改善を共有するようにする

第1回同様このような形で各々がやることを付箋に書き出して行いきました。

そして私は第1回で味をしめたので別の箇所で起きているN+1問題にもう一度挑戦。

そして第2回の結果は・・・

完了したタスク数35件

画像はFindy Team+上でのアクティビティ数

集計単位がPR数ではなくタスク数になった事と、時間を1時間巻いた事によってアウトプットの数字自体は下がってしまったように見えますが、それでも普段の実装量と比較すると3倍はある結果となりました。

第1回目と比較して感じた事は

プレゼンタイムを設けたので各々のやったことが明確になった
1回目程インパクトあるネタが出にくかった

と言った感じでした。1つ目に関しては純粋な改善点ですが、2つ目に関しては負債が減った結果ネタが出しづらくなってきたという事なので、ある意味よい傾向なのだとは思います。

そして、晴れて第2代改善王に選ばれたのは・・・・・・・。

通常操作では発生しない再現性のなかったエラーの調査を行い特定してくださった、 @masemashika さんでした。おめでとうございます！（防衛ならず・・・）このエラーはリリース当初から発生しており、度々Rollbarに飛んでくるエラーだったのでみんなが認知していた点、何人ものエンジニアが原因調査をしたにも関わらずわからなかった問題の原因を突き止めた点が選ばれた理由でほぼ全会一致の結果となりました。

そして第2代副本部長賞に選ばれたのは・・・・・・。

新卒1年目の田中さんでした。

内容としてはrubocopで適用できていなかったルールを適用するとともに、新しく追加されたルールを適用しやすい仕組みを構築してくれました。

今後に向けて

今回のシステム改善Dayはチームメンバーからも「改善に集中できた」「改めてソースコードを見直すことで勉強になった」「作業効率がかなり良かった」といった具合で評判も良く、短期集中的に技術的負債の返済に取り組むことで通常の3〜4倍のアウトプットが出せたことで控えめに言っても大成功だったと思います。ただ、以下のような課題もあると考えています。