3ヶ月かかる大規模リファクタリングをなぜ実行に踏み切れたのか？
こんにちは、すべての開発組織の生産性を上げたいhamです。
私の所属する開発チームでは、今年1月からフロントエンドのアーキテクチャを変更する大規模なリファクタリングを行いました。
アーキテクチャ変更の詳細についてはこの記事では触れませんが、以前SaaSにおけるフロントエンドの技術戦略 | SaaS.tech #6というイベントでLTを行いました。
このリファクタリングは5人で3ヶ月ほどかかる大規模なもので、1〜3月にエンジニア5名にほぼフルコミットしてもらい実施しました。
その間、施策開発も並行して行いましたが、施策開発を担当するフロントエンドエンジニアは2名に対してリファクタリングには5名アサインしたので、リソースの7割をリファクタリングに割いたことになります。
前述の通り施策開発はSTOPしていないものの、1〜3月は開発リソースの7割が施策開発に使えない状態になりました。
それにも関わらず、なぜ大規模リファクタリングの実行に踏み切れたのか？
この記事では、この経緯を紹介したいと思います。
大規模リファクタリングのきっかけ
2022年11月、開発をより加速するために別プロダクトを開発していたテックリードが開発チームに加わりました。
そのテックリードの定性・定量評価が大規模リファクタリングのきっかけになりました。
定性評価
「フロント開発はキャッチアップがつらい。疲労度が全然違う！」
この時点のフロントエンドコードは、機能開発に全力だった影響もあり技術的負債が溜まっている状態でした。
ただし、慣れているとそれなりに開発でき、この状態が当たり前になっているため、開発チーム内のエンジニアだけでは負債に気付きにくかったのかなと思います。
定期的に開発チームに新しい風を吹き込むことの大事さがわかります。
ただ、この定性評価だけで前述した大規模リファクタリングに踏み切ることは難しいです。
定量評価
下記はテックリードのアクティビティ(プルリク作成数)です。
11月から明らかに減少していることがわかります。
このデータから開発パフォーマンスのネックになっているところを取り除くことで、他のプロダクトと同等の開発パフォーマンス(約1.5〜2倍)まで高めることができると予測できます。
開発パフォーマンスのネックを議論した結果、アーキテクチャが現在のチーム状況やプロダクトに合っていないと結論づけ、今回の大規模なアーキテクチャ変更を計画しました。
ただ、アーキテクチャ変更はコード全域に及ぶため、5名アサインしても3ヶ月ほどかかる見込みでした。
なぜ実行に踏み切れたのか？
前述した通り、開発メンバーの7割である5名をリファクタリングにアサインすると、3ヶ月間は施策開発が通常の3割のパフォーマンスになってしまいます。
この意思決定を定性的な面だけで判断しようとするとかなり難しいと思いますが、定量的なデータがあればデータドリブンに判断することができます。
テックリードのアクティビティから見積もりの時点でリファクタリング後は開発パフォーマンスが1.5〜2倍になると予測できます。
開発パフォーマンスが上がることの効果を可視化できるように「リファクタリングなし」「リファクタリング後1.5倍」「リファクタリング後2倍」の施策開発の累積アクティビティをグラフにします。
計算しやすいように下記条件で計算しました。
リファクタ前は1人当たり月に10アクティビティ開発できる
リファクタしない場合
全期間7名全員が施策開発を行う
リファクタする場合
リファクタ中(1〜3月)
2名のみ施策開発を行う
リファクタ前と同じアクティビティ数(10)で計算
リファクタ後(4月〜)
アクティビティが1.5倍 | 2倍になる
リファクタしていたメンバーも施策開発を行う(合計7名)
グラフを見ると一目瞭然ですが、3ヶ月リファクタリングしたとしても、その後開発パフォーマンスが1.5倍になれば、8月には累積アクティビティがリファクタリングしなかった場合を上回ります。
2倍になった場合はさらに早く5月に上回ります。
このグラフを見たら、リファクタリングしないという判断をする方が難しいと思います。
リファクタリングの結果
下記は大規模リファクタリングを行ったフロントエンドの10月〜3月の1人あたりのプルリク作成数の推移です。
グラフを見ると、リファクタリングを開始した1月くらいから徐々に増加しており、3月時点ではリファクタリング前の約2倍まで上がっていることがわかります。
プルリク作成数が2倍になったから開発パフォーマンスも2倍だ！と言えるわけではないですが、テンポよく開発できるようになっており、開発パフォーマンスが上がっていると定性的にも定量的にも実感しています。
まとめ
近年、大規模なリファクタリングなどを行って技術的負債を返済していくことの重要性について語られることが増えてきましたが、まだまだ意思決定が難しい組織が多いのではないでしょうか？
意思決定はデータドリブンに行うことが重要です。
ジェフ・ベゾスも下記のように言っています。
「意見で決めるなら私の意見が常に勝つ。しかし、データは意見に勝つ。だからデータを持ってこい」
この記事が技術的負債を返済する意思決定の参考になれば幸いです。
なお、開発パフォーマンスの可視化にお困りの方はぜひFindy Team+をご検討ください 🙏
この記事に添付したグラフもFindy Team+を使って可視化したものです。
フリートライアルもございますので、ぜひお気軽にご連絡ください。
おまけ
こういう話をすると経営陣の理解がなくて技術的負債の返済の意思決定ができないという話をよく聞きますが、ファインディでは経営陣も技術的負債の返済の重要性を理解しているのでスムーズに推進することができました。
この記事でもCEOの山田さんが下記のように語っています。
リファクタリングやテストのカバレッジ向上など、短期的な利益や機能開発につながらない開発をどれだけ許容できるかが挙げられます。こうした作業は数ヶ月ほどかかりますが、完了後には開発生産性の大幅な向上が期待できます。
ファインディはエンジニア領域をターゲットにしている企業ということもあり、エンジニア以外の方々のエンジニア理解が半端ないです！
このような環境で開発したいという方がいたらお気軽にお問い合わせください〜 🙏
この記事が気に入ったらサポートをしてみませんか？