2年間でプロダクトのコードを半減させた話 #チーム開発

概要

私の担当するサービスは2010年にガラケー向けサイトとしてリリースされて現在はスマートフォンアプリとして運営しています。

そのプロダクトの一部の機能群は利用率の低い機能や利用されていないコードなどが存在し、メンテナンス性が良くない状態となっていました。

2年前の時点で今後の事業の変化に迅速に開発していくためには、コードの整理が必要であると判断しました。

我々は、不要なコードの削除に取り組んできて、コードを半減させることができました。

今回は、どのように不要コードの削除に取り組んできたかをお話します。

まずは、システムの全体像を明確にするため、どんな機能が存在し、どんなファイルが存在しているかを確認しました。

これを行うことで取り組みやすい箇所を発見したり、全体のうちの進捗がどれくらいになっているかが見える化されました。

不要コードの削除というのは利用者への価値提供をできる業務ではありません。
また、なくなったからといってすぐに開発体験が変わるものでもありません。

そのため、我々はシンプルにファイル数とコード数が減っていくことをKPIとして実施しました。

計測については AlDanial/cloc というツールを利用しています。

週次でレポーティングすることにより、今週の取り組みの可視化やモチベーションの維持していました。

過去の施策で導入したが効果が高くなかった機能やだんだんと時流に沿わなくなって衰退してしまった機能が残っていました。

機能moduleごとにPVとMAUを出力して下位の機能については事業全体で機能の継続判断を行いました。

結果的にいくつかの機能は削除によるユーザー影響よりもメンテナンスや保守コストのほうが高いという判断の元削除を実施しました。

エンジニア以外の職種を巻き込むことで取り組みへの理解も得られやすく、大きな改善もやりやすくなります。

今回の取り組みのような事業施策と直接関わりのないものを進めていくには、ある程度の時間確保が必要です。

幸い我々のチームでは週の20％を保守に当てるという運用をしているので、その時間にこの取組みを行うようにしました。

全員で同じ時間に同じ取り組みをすることで下にもあげるペアプロやモブプロも実施しやすいです。

また毎週実施することで週ごとの変化にも気づきやすくなります。

メンバーの事業の関わっていた時間もバラバラだったため、事業背景やシステムへの理解度も異なっている状況でした。

単純な削除の作業にならないように、削除するコードに対しての議論や影響範囲の確認などもペアプロやモブプロの時間を通して共有するようにしました。

判断に迷う部分も複数人ですすめることができ、迅速に削除を進めることにつながりました。

上記の取り組みを通して、ファイル数で44％、コード行数で58％の削減に成功しました。

我々のチームでこの取り組みを経て、プロダクトのコードを半減させることに成功しました。

減少させた数字については、プロダクトの状況により異なりますが、レガシーなシステムへの対応と初期段階として不要コードの削除を進めていくことはリプレイスの可能性なども含めて有効なアプローチとなります。

レガシーなシステムと戦っている方の参考になれば幸いです。