こんにちは、LIFULL HOME'Sの売買領域でエンジニアチームのマネジメントを担当しています、長崎です。
ここ数年、LIFULL HOME'Sでは積極的に技術的負債解消に取り組んでおり、今回は私がマネジメントするチーム内でどのような取り組みをしているかをご紹介します。
技術的負債の解消はあらゆるサービスにおいて大きな問題となっており、すでに多くの事例が紹介されていますが、同じように我々の取り組みがどなたかの参考になれば幸いです。
LIFULL HOME'Sにおける技術的負債
これまでに下記エントリでも言及している通り、LIFULL HOME'Sの現行プロダクトは9年を超えて開発されています。 www.lifull.blog
上記エントリではフロントエンドに焦点を当てていますが、これだけ長く開発・保守されているプロダクトですので、技術的負債はアプリケーションレイヤー(PHP / Ruby)、インフラレイヤーと多岐・多層に渡って存在しています。
新機能の開発や既存機能の改修を行う際に、調査・テストの工数が膨らんでおり、サービス成長の大きな阻害要因、まさに負債となってしまっています。
事業開発部門における取り組み
LIFULL HOME'Sの開発部門は大きく分けて2つに分かれています。
ビジネスサイドと密接にコミュニケーションしながら、エンドユーザーが触れるプロダクトを日々開発する事業開発部門と、 LIFULL HOME'Sに限らず、プロダクト・サービス全体の基盤システムを保守・改善する技術基盤部門です。
肥大化する調査・テスト工数を削減し、開発効率の向上を図るために、私の所属する事業開発部門では工数の10%をリファクタリングに充てるというルールを作成し、組織全体として負債解消に取り組んでいます。
私のチームはアプリケーションレイヤーの開発を担当することが多く、下記のようなコードレベルでの負債に日々悩まされています。
- 使われているかわからないコード
- 依存関係が適切に分割されていないコード(デグレしやすいコード)
- 複雑度が高く、テストコードがないコード
私のチームでの取り組み
私のチームでは、上記コードレベルの負債をリファクタリングにより解消するべく、3つの取り組みを行っています。
- コードの静的解析に基づいたリファクタリング
- 日々の改修における課題を基にした大規模リファクタリング
- リファクタリングを行うべき領域の可視化・優先度付け
それぞれどんなことをしているのか、よいところと課題はなにか、をご紹介します。
コードの静的解析に基づいたリファクタリング
LIFULL HOME'Sでは、codeclimateというサービスを導入し、コードの静的解析を行っています。 この解析結果に基づいて、複雑度の高いメソッドや、重複したブロックを発見し、リファクタリングを実施します。
よいところ
- コードに対し、定量的な指標を持てる
- 一定のフィードバックを機械的に行える
課題
- メンテナンス性のために分割されたクラス・メソッドであっても重複判定されてしまう
- コードの利用頻度や、改修頻度に紐づかない分析のため、改善効果による優先度がつけられない
静的解析の結果がすべて!としない運用が求められますが、lintツールなどと同様に定常的に活用することで、コードのベースレベルの向上や複雑度に対する意識づけが行える点が良いと思います。
日々の改修における課題を基にした大規模リファクタリング
新規実装当初にその時点でのユースケースから作ったクラスが、長年多数のメンバによって、そして多くの場合デリバリーを優先したプロジェクトにおいて、適切に拡張されずにif
文まみれになってしまうことはよくあることかと思います。
このような状態のコードを放置していると、改修の際に想定外のページ・サービスにおいてバグが発生し、以降デグレチェックに悩まされ続けます。
これを改善するため、現在のユースケースに合わせた大規模なリファクタリングを行っています。
よいところ
- 普段目を背けているところに向き合う機会になる
- 改めて見直すことで、現時点では不要になったコードを消すことができる
- ビジネス要求や想定される改修の質・量が想定できる状況で設計し直せる
課題
- アーキテクチャレベルや、フレームワークの負債からは逃れられない
- リリース手順やタイミングなど、実行計画が難しい
- ステークホルダーが多くなりがちで、精神的に疲弊する
進めていると往々にして、「もはや作り直したほうが早いだろコレ」という気持ちに苛まれますが、サービスの保守をしながらできることをしていかねばと思い直す日々です。
リファクタリングを行うべき領域の可視化・優先度付け
なんとか技術的負債を定量的に表現したいと思い、コードの変更行数とテストケース数(テストコードの行数)の計測を行っています。
現時点での1サンプルですが、変更行数が数行にもかかわらず、デグレチェック目的で数十URLをテストすることになる場合があれば、変更行数が数十行でもテストケースは数ケース程度で済む場合もあります。
前者のような機能は早急にリファクタリングしなければ、毎回大きなテスト工数がかかったり、誰にも意図がわからないデグレチェックが口伝で残り続けてしまいます。
よいところ
- リファクタリングの期待効果を見定めることができる
- 非エンジニアに改修の難易度を定量的に伝えることができ、リファクタリングの重要性を理解してもらいやすい
課題
- 変更行数は計測しやすい反面、プログラミング言語やフレームワーク、設計思想に左右されやすい
- テストケース数やテストコードの行数は、作成者によりばらつく
現在取り組んでいる指標で目的を果たせるのか、そしてベストなのかどうかはわかりませんが、なんとかリファクタリングの重要性を定量的に表現するべくチャレンジしていきます。
最後に
サービス上の不要な機能を削除したり、「今」問題がないコード・システムを直すためにはステークホルダーの理解・協力が欠かせません。
一方で、「リファクタリング」や「技術的負債の解消」という非エンジニアからしたらよくわからないけどすごく大事そうな言葉を盾に、エンジニアが手段を目的化してビジネスに貢献できないことは絶対に避けなければいけません。
今回3つの取り組みを紹介させて頂きましたが、リファクタリングが「よくわからないけどすごく大事そうな言葉」じゃなくするために、ステークホルダーにしっかりと伝え続けることが一番大事な取り組みだと思います。