こんにちは、LIFULL HOME'Sの技術基盤部門に所属している戸野です。
LIFULL HOME'Sのエンジニア組織は大きく分けて2つに分かれています。
LIFULL HOME'Sに限らず、プロダクト・サービス全体の基盤システムを保守・改善する技術基盤部門と、ビジネスサイドと密接にコミュニケーションしながら、エンドユーザーが触れるプロダクトを日々開発する事業開発部門です。
下記のエントリでは、事業開発部門における技術的負債解消の取り組みが紹介されています。
一方、技術基盤部門でも各PJでLIFULL HOME'Sの技術的負債解消に取り組んでいます。
そこで、今回は技術基盤部門での技術的負債解消の取り組みをご紹介したいと思います。大規模サービスになると、技術的負債との戦いは避けられないでしょう。私達の取り組みが少しでもお役に立てたら幸いです。
技術基盤部門の体制と取り組み
価値提供を加速させるために技術基盤部門では、技術的負債解消の文脈でバックエンド・フロントエンドともに既存アプリケーション改修を行っています
フロントエンドの既存アプリケーション改修についてはこちらの記事で紹介されています。
私がアサインされているPJでは、バックエンドの既存アプリケーション改修を、現在2名体制で取り組んでいます。 具体的にどのような技術的負債があったかと言いますと、
設計レベル
- 何重にもなっているクラスの継承関係
- 処理の流れがとても分かりづらい複雑な依存関係
実装レベル
- マジックメソッドがあらゆるところで使われているためデバッグしづらい
- 動的に呼ばれるクラス、メソッドが多くデバッグしづらい
- ビジネスロジックがテンプレートエンジンに記載されている
などがあってそれぞれに対応していきました。
PJを進める上での制約
このような技術的負債に立ち向かっていくわけですが、技術基盤部門と事業開発部門が並行して開発を進めるため、当然制約がある中での開発でした。そして、具体的には次のような制約がありました。
制約💁♂️
- 事業開発部門の人数の方が多く、並行開発による衝突のリスクが常にあるので、事業開発部門の変更をウォッチしコミュニケーションを適宜取り調整する必要があった。
- 事業開発部門の人数の方が多く、速度的に技術的負債の「増大スピード > 解消スピード」であるため、手当たり次第にリファクタリングを行うのではなく、効果の高い部分から対処する必要があった。
- 事業開発部門の開発を停止させることはできないため、バグが確実に出ないようにQCDのQ重視でテストを厚くし、後方互換性を維持したAPI設計の必要があった
技術的負債解消のために講じた具体的な取り組み
これらの制約の中で私達は技術的負債の解消を進めていきました。そこで、設計実装レベル両方で技術的負債を解消するための取り組みを3つ紹介します。それぞれの取り組みの説明、メリットと大変だったことを具体的に説明しています。
全体を俯瞰して分析し本質的な問題点と解決策の洗い出し
技術基盤部門がLIFULL HOME'Sの技術的負債を解消することに取り組むメリットは、 事業開発部門が工数的にできないような、広い範囲での根本的なリファクタリングを行えることだと思います。
広い範囲での改修になるので、部分最適な設計実装にならないようにする必要があります。そこで、UMLを駆使してリバースエンジニアリングを行い、全体的にクラスの依存関係、継承関係、API呼び出しなどを調査し現状の本質的な問題と解決策を分析しました。
メリット🙆♂️
- そもそもの設計レベルから見直すことができ、できるだけ理想に近い形の設計をすることができた
大変だったこと🤷♂️
- 継承関係と依存関係が複雑すぎて現状のソースを理解、分析するのにかなり苦労した
古いAPIをやめて新しいAPIを呼び出すように改修
LIFULL HOME'Sでは複数のAPIが使われていて、中には古いAPIが使われている箇所があります。
古いAPIはアーキテクチャの技術的負債があったりして利用しづらいので、 できるだけ古いAPIの呼び出しをやめて、新しいAPIを呼び出す実装に修正していきました。
新しいAPIはテストコードが完備されているのとアーキテクチャの面で分かりやすいので、以前よりも保守性可読性が上がったと考えています。
メリット🙆♂️
- (廃止予定の)古いAPIを廃止するのに1歩近づいた
大変だったこと🤷♂️
- 古いAPIのアーキテクチャが複雑で、調査分析の工数がかなりかかった
ビジネスロジックと表示ロジックの適切な分割
ビジネスロジックと表示ロジックがフロント側のシステムに混在していて、 フロント側のコードが肥大化し、かなりメンテナンスしづらい状況でした。
そこで、他PJが考えていたビジネスロジックと表示ロジックの切り分けのルールを参考にしながら、 ビジネスロジックをAPI側、表示ロジックをフロント側に実装するように切り分けていきました。
メリット🙆♂️
- フロント側のコードのボリュームが小さくなり、以前よりも調査しやすくなった
- 各システムの責務が明確になり、以前よりも凝集度の高いメンテナンスしやすいコードになった
大変だったこと🤷♂️
- 単位やprefixのような文字列をドメインとして扱うかどうかの判定で悩み、ビジネスロジックか表示ロジックかの切り分けが難しかった
最後に
技術基盤部門での技術的負債解消の取り組みを紹介させていただきました。技術的負債解消は、直接的にビジネスの価値提供をするわけではないので、どうしても優先順位を高くつけづらいところがあると思います。
しかし、技術的負債が積み重なるとビジネスの価値提供も鈍化するので、かなり重要なことだと考えています。
技術基盤部門という立場で、今後も技術的負債解消に立ち向かい、長期的に価値提供ができるシステムを構築していきたいです。
