Code Climateで借金返済計画（と半年間の軌跡）

こんにちは！SmartHRで組織図機能の開発を担当している、エンジニアのmuranoです。半年ぶり2回目の記事投稿になります。
今回は私が所属している組織図機能の開発チームで取り組んだ技術的負債の可視化と解消について紹介しますっ🐶 （タイトルにある借金返済が何なのかっていうのは後にでてきます）

そもそもなぜ技術的負債を可視化・解消したいのか？

この活動は昨年の5月頃から開始したものですが、当時新機能の開発を活発に行なっていて、仮説検証の目的で暫定的にコードを書くこともあり、負債が増えている懸念を感じたことが始まりになります。

技術的負債が積み上がっていくと、実装速度の低下やレビューサイクルの悪化・テストがしづらくなるなど、開発効率に大きな影響を与えると思います。

チームで取り組むにあたり、負債が増えているという感覚やそもそも負債とはどのレベルのものかということも、人によって基準が異なるため、ツールを使って一定の基準で判断し・共通理解を得たいと考えました。

そこで、私が以前利用したことがあって使い勝手が良かった、Code Climateを導入・運用していくことにしました。

Code Climateとは

Code Climateは自動コードレビューのツールの1つで、GitHubと連携して10個の指標を基準に技術的負債を検出・可視化してくれます。 Code Climateには複数のプロダクトがありますが、今回はQuality（技術的負債を検出・可視化するもの）のみ利用しています。他には開発サイクルを計測するプロダクトなどがあります。

https://codeclimate.com/quality

利用者4人までは無料で使えるので導入しやすいかと思います。
人数が多い場合でも、現状でどのくらい負債があるか無料で確認する方法として、利用者を自分だけに設定して既存のリポジトリをチェックするような使い方もできるので、気になったら気軽にチェックできるのも良いところです。（Code Climateの閲覧やPull Requestごとにチェックをかけるときに課金が必要になります）

半年間の軌跡がこちら

先に結果を紹介します。結果はこちら！

紆余曲折を経て、技術的負債（Technical Debt）が20% → 23% → 12% という結果になりました。

以降、大まかに3つのフェーズに分けて、やったことを説明していきます。

導入期

まずはCode Climateを導入し、現状認識と可視化をしました。（余談ですが、RuboCopのようなチェックツールだと全体でOK/NGしかわからないので、今どのくらい警告があるのかを定量的に捉えづらいという課題を感じていたため、その点でCode Climateにメリットがあると思っています）

手順としては、Code Climateのドキュメントに従って、リポジトリの連携設定やConfiguration（検出項目の設定や除外ファイルの設定）を行いました。最初のチェック結果がこちら。（テストカバレッジは今回の活動からは除外することにしたため、未計測）

レートがDで、負債改修の時間が6ヶ月となりました。この画面には表示されていませんが、負債の割合は19%でした。
改修時間はCode Climateが独自に計算しているもので、警告の数やリポジトリサイズから算出しているものになります。詳細は How are maintainability ratings calculated? の「remediation time」の箇所を読んでみてください。

この段階で負債が結構多いことが分かりました。そこで、Code Climateの主なチェック項目である保守性（Maintainability）に注力して改善していくことに決めました。ちなみに、上記キャプチャの「OTHER ISSUES」はRubocopやReekなどの追加のチェック項目の警告数を表しています。これらのチェックはCode Climate上でプラグインとして実行可能なため、便利そうな印象でチェックしてみたのですが、数が膨大だったためしばらくは除外することにしました。

保守性についての詳細： https://docs.codeclimate.com/docs/maintainability

また、保守性のチェック項目の中でも、特に件数が多く負債の割合に影響が大きそうな複雑度（Complex logic, Method complexity）と重複コード（Identical blocks of code , Similar blocks of code）を意識して改善することにしました。

複雑度や重複コードについては上記保守性についての詳細に詳しく記載があります。

ここまでで、現状の認識とCode Climateでチェックする環境の構築までを導入期とし、以降はオンボ期に移っていきます。

オンボ期（オンボーディング期）

オンボ期では、負債を減らす活動を定着させていくことにしました。

技術的負債を改善する際に重要なことは、

負債を増やさないこと
負債を減らすこと

の2つだと思います。特に負債を増やさないこと（Pull Request時のチェック）は後追いでの対応に比べて修正時間が短く負債をさらに作り込む可能性を減らせるため、なるべく早めに行うのが王道かと思いますが、慣れないチェックによって開発スピードに大きい影響を与えそうな雰囲気があったので、今回は負債を減らすことを優先し、その中でチームでの共通認識を作っていくことにしました。

負債を減らす活動を「借金返済タイム」と名前をつけて、毎週30分チーム全員で集まってもくもく作業する時間を設定しました。（タイトルの借金返済計画はここからきています）

借金返済タイムでは、Code Climateの既存の警告をファイルごとに見て、改善するファイルをピックアップし、コードの修正・レビューまでをなるべくその時間でやりきろうという流れで進めました。Code Climateの使い方に慣れていない＆警告の内容も人によって認識がバラバラな状態だったので、このように同期的に進める時間を設けたのはとても良かったかなと思います。

この時に取り入れたちょっとしたTipsを紹介します。

Tips1 ピックアップしたファイルをスプレッドシートに記録

改善するのにピックアップしたファイルをスプレッドシートに記録するようにしました。これによって、作業の重複を避けるとともに、以前どうしたかな？というようなときにもすぐに履歴が追えて重宝しました。

記録は最終的に66行にもなり、やればやるほどこれだけやったんだという自己効力感も倍増したので、オススメできる方法でした。
（66行の記録は、66個のPull Requestを作成したという意味でファイルが重複した場合も別途記録していました）

Tips2 Pull Requestは最小単位で

こちらは、普段の開発でも当たり前に行われていることではあるのですが、実際に活動を始めたときに問題がでたので紹介します。

借金返済タイムを始めた当初は、解消する警告を4つや5つくらいまとめて解消しようと思い、Pull Requestの差分が大きく発生しがちでした。（まとめて解消したくなるのは人間本来の怠惰さによるものかもしれませんが、自然とそうなることが多かったです）
差分が大きくなってしまうと、レビューにも時間がかかり、マージするのに時間がかかってしまいます。普段の開発では毎日開発の時間があるので大きな問題にならない可能性が高いですが、1週間に1度しか活動がないため、マージを逃すと次の週に持ち越されてしまうため、長いときでは3週間から1ヶ月程度マージできないケースもありました。
借金返済タイムでは、警告の解消を行うため構造的な変更が多く、コンフリクトが発生しがちです。この状況でマージが長引いてしまうと、コンフリクトの頻度も量も多くなり、さらにマージができなくなる悪循環に陥りそうになりました。そこで、開発の原点（Pull Requestはなるべく小さく）に立ち戻り、その日にマージできるように意識して進めると、結果的に負債解消のスピードも上がったと感じました。

SmartHRの開発でも重視しているフロー効率にも寄与する部分だったので、早い段階で方向修正ができて良かったと思います。

運用期

借金返済タイムが定着してきたので、ようやく負債を増やさない活動に着手しました。具体的には、Pull Requestのマージ条件にCode Climateの警告がでていないことを必須にし、Pull RequestのタイミングでCode Climateの警告を解消するようにプロセスを変更しました。

この運用に変更して、借金返済タイムを継続した結果、負債が減るスピードが加速したように思います。

運用としては安定期に入り着実に負債を解消していたところで、重複コードの警告が多すぎるということを課題として認識しました。リファクタの余地・意味がないような関数呼び出しだけでも警告が発生してしまう状況で、手動でCode Climateで無視（「修正しない（Won't fix）」）にしていたのですが、数が多かったので重複コードのしきい値を緩和することにしました。

検出のしきい値を50に変更（デフォルトは Ruby: 18, TypeScript: 45）したところ、5割くらいは発生しなくなったと思います。（正確な件数を調べていなかったので感覚です）

ちなみに、このしきい値は言語ごとに設定することはできないのがネックでしたが、結果的には程よい動作になったように思います。

まとめ

最後に今回の活動をおさらいしていきます。
改めて、負債の変遷を時系列とともに掲載しておきます。

コード量の変化も載せておきます。

要点をざっとまとめますと、

負債は、執筆時点で12.6%まで減らすことができた。コード量の増加に対して負債の割合が減っているのでかなり改善ができていると思います。
大切なことは、継続して監視していくこと。数字は、途中で設定を変更したりすると簡単に変わってしまうので、絶対数で単純に判断はしない方が長期的に良い成果につながると思いました。

また、この活動を通して感じたこととしては、