noteのエンジニアがお届けするPodcast「note tech talk」。今回は、RuboCopの運用を行っている田中さんと井上さんがゲストです。

noteでは今年の3月から本格的にRuboCopを導入し、約9万件あった警告を1万件まで減らすことができました。自動修正や手動修正を粛々と行ってきた結果が数値として顕著に現れています。リリースフローを改善することで障害もなく安定した改善を続けられています。

今回は、そんなRuboCopの運用を行っているエンジニアの2人に詳しい話をお聞きしました。

※ RuboCopとは
Rubyの静的コード解析ツール。メソッド名、改行、コードの複雑度などを検知し、自動修正を行うこともできる。

■司会 / 進行
福井 烈 / エンジニアリングマネージャー
ジークレスト、ガンホー・オンライン・エンターテイメントを経て2015年にnoteに入社。サービス黎明期からnoteの開発に携わり、データ基盤や会計などを担当。現在はエンジニアリングマネージャーとして、開発チームの統括や組織編成などを行う。note / Twitter

■ゲスト
田中 宏基 / エンジニア
フューチャーアーキテクト株式会社、株式会社トレタを経て、2021年3月にnoteに入社。前職ではサービスの開発 / 運用だけではなく、チームリーダーやPjMも経験。noteでは短期から中長期まで幅広く開発を行う。note

井上 航輝 / エンジニア
ファッション系の求人媒体のマッチング機能開発を経験した後、2021年1月にnoteへ。入社当時から様々な短期開発を担当しnoteの改善に従事。noteへのRuboCop導入を始めた第一人者。note

================================
0:00   〜 自己紹介 / オープニング
2:24   〜  RuboCopの概要説明
3:54   〜  noteに導入した経緯
6:44   〜  8万行の警告を減らした
10:44 〜 リリース方針を固めることで障害を0へ
17:20 〜 作業をすることでコード全体を俯瞰して見ることができた
20:04 〜 CIに組み込んだらチームは解散する
21:26 〜 リリースフローに参加してほしい================================

ざっくりあらすじ文字おこし

※ 本編の内容がざっくりわかるように、内容を抜粋しております。あくまで「ざっくり」なので詳しい内容は本編をお聞きください。

■1年以内に8万件の警告を修正

ー 導入した効果はどのくらいありましたか？

「導入を開始した今年の3月時点では9万2000件の警告がありましたが、12月時点で約1万件まで減らすことができました」（※ 2021年12月時点）

ー おお、すごい

「数字で見るとかなり成果がだせた実感がありますね」

「数値を減らしていくこと自体が僕らのモチベーションにもなっています（笑）」

■rubocop_challengerによる粛々としたバグ修正の日々

ー 実際にはどんな作業をして減らしていったのでしょうか？

「粛々と修正していく感じでしたね」

「RuboCopの警告には自動と手動でそれぞれ修正していくものがあります。まずは自動修正で直せるものから手をつけていきました」

「作業を定例のタスク化するために、Github Actionsとrubocop_challengerを組み合わせてPRの作成を自動化しました」

※ rubocop_challenger
自動修正が可能なRuboCopの警告からPRを作成するライブラリ。Github Actionsと連携して自動でPRを作成することで、定期的にRuboCopと向き合う機会をつくった。

「自動修正がある程度は進んだ段階で、今度は担当曜日を決めて手動修正をすることにしました」

「もちろん自動修正も引き続き進めていく形です」

ー 週にどのくらい時間を使って作業していましたか？

「最初は、2人合わせて1週間の20%くらいだったと思います。お互いが週に1日ずつ使うペースくらいかな」

「今は警告も減ってきているため、お互いに半日ずつくらい使って作業しています」

■リリース日を固定することで障害が0に

ー 作業として難しい点はありましたか？

「最初は、RuboCopの修正ルールもあまり決めずに始めてしまいました。そのため修正後の確認も曖昧でした」

「確認が甘い部分も多くあり、修正によって軽度のバグを引き起こしてしまうこともあり……」

「他チームにも迷惑をかけてしまうので、影響範囲を見極めるのは難しかったポイントと言えるかもしれません」

ー 障害が起きてしまうことを防ぐために、改善したことはありますか？

「RuboCopの修正と他機能のリリースが一緒になってしまうと、障害の発生起因がわからない問題がありました。まずは、障害発生の切り分けをすることにしました」

「RuboCopのリリース日と時間帯を決めて、その時間ではマージを禁止する運用にしました」

「社内でもリリース日の固定はだんだんと浸透してきた感じはしますね」

「ありがたいことにみなさん意識してくれています」

ー 実際にリリース日を決めた効果はどうでした？

「リリース日を固定してからは、警告の修正による不具合は1度も起きていません」

「RuboCopのリリース作業をしつつ、E2Eのテストを並行して増やしていたので、その効果もあったのかもしれません」

「E2Eテストを増やすことで手動での確認作業が減り、リリース時間もだんだんと減るようになってきました」

■コード全体を俯瞰して見ることができる

ー 作業してみてわかったことはありますか？

「note全体のコードを見ることで、改修やリファクタリングが必要な箇所がわかるようになりました」

「普段関わらないプロジェクトのコードを見るため、知らなかった機能を知れる良い機会になっています」

ー 俯瞰してコードを見ていると気づきは多そうですね

「たまに『なんだこのコードは……？』というのが見つかるときもあります（笑）」

「一度直した部分でまた同じ警告が出ているときもありますね。開発者自身が気づける仕組みを構築していかなければと感じています」

「潰した警告が再び出てくると悲しい気持ちになるので（笑）」

■CIに組み込めばチームは解散

ー これからやっていきたいことや課題は？

「CIに組み込むことが最大の課題です。RuboCopをCIに組み込むことで、開発者が警告を自分で直さないとリリースできない仕組みを作っていきます」

「それができればRuboCopチームは解散ですね」

「僕らは解散に向かって走っているチームとも言えます（笑）」

ー 人ではなく、システムに任せるのは正しい方向性ですね

▼関連記事

▼Podcast一覧

▼エンジニアの記事をもっと読みたい方はこちら

▼noteを一緒に作りませんか？

Text by megaya