LINEヤフー Tech Blog

LINEヤフー株式会社のサービスを支える、技術・開発文化を発信しています。

LINEのアプリ開発を支えるコードオーナー管理・評価編 〜 PRのコードオーナー不足を90%削減!

はじめに

こんにちは、iOSアプリエンジニアの羽柴です。
本記事では、プルリクエストにおけるコードオーナー不足を防ぐために導入したGitHub Actionsの効果測定を行った話を紹介します。

コードオーナー不足を検出するGitHub Actions: Codemap Checker

2024年12月、LINEアプリレポジトリのGitHub Actionsに"Codemap Checker"を導入しました。これはプルリクエスト(以下PR)におけるコードオーナー不足を検出するワークフローです。PRで追加・変更されたファイルにコードオーナーが設定されていない場合はこのワークフローが失敗し、コードオーナーが不足しているファイル一覧が出力されます。

コードオーナー不足により失敗したワークフロー

コードオーナーが不足しているファイルの一覧

導入経緯や実装などについての詳細は、以前のブログ記事であるLINEのアプリ開発を支えるコードオーナー管理をご覧ください。

Always Data-driven: Codemap Checkerに対するPDCAサイクル

LINEヤフー株式会社が掲げるバリューのひとつが「User Rule: ユーザーファースト」であり、それを体現する具体的な行動様式の中に「Always Data-driven: データを基に俯瞰で判断」があります。これは自分の熱量と市場との差分を避けるため、常にデータに基づいた判断を重視する姿勢です。LINEアプリ開発チームでもこの考え方を大切にしており、施策を導入して終わりにせず、数値を算出して効果を評価することを推奨しています。いわゆるPDCA サイクルを継続的に回すことで、ユーザーにとって本当に価値のあるサービスの提供を目指します。

「コードオーナー設定率を向上させる」という目標に対して、前回の記事ではPlanおよびDoまで完了しました。Codemap Checkerが導入されてから数カ月がたちましたので、今回はその効果を評価(Check)し次に取るべき行動(Action)を検討します。

評価方法

導入前・後それぞれ以下の期間のPRを解析します(Codemap Checkerの導入は2024年12月):

  • 導入前: 2024年01月01日~07月31日
  • 導入後: 2025年01月01日~07月31日

算出する値は以下の通りです:

  • 期間中にマージされたPRの数
  • そのうち、コードオーナー不足が検出されたPRの数(Codemap Checker導入後のみ)
  • そのうち、コードオーナー不足のままマージされたPRの数

コードオーナー不足が検出されたPRに関して、導入前のbotはその仕様上チェック履歴を取得できないため、導入後のみこの値を算出します。Codemap Checkerの導入後にコードオーナー不足のままマージされたPRの数が減っていれば、本施策がコードオーナー設定率の向上に寄与していると評価できます。

結果

以下は、期間中にマージされたPRのうちコードオーナー不足のままマージされたPRの割合です。

コードオーナーが不足したままマージされたPRの割合

コードオーナーが不足したままマージされたPRの割合が 19.6% → 1.6%と大きく減少しています。

月毎の推移

続いて、コードオーナーが不足したままマージされたPRの月毎の推移を棒グラフにしました。

コードオーナー不足のまま�マージされたPRの推移

導入前は一定量のPRがコードオーナー不足のままマージされていますが、導入後にはその数が減少していることがわかります。

次に、導入後にコードオーナー不足が検出されたPRの推移と、その修正率の変化を見てみましょう。

コードオーナー不足が検出されたPR数と修正率の推移

導入直後の1月は修正率が約30%にとどまっていましたが、時間が経過するにつれて向上し、4月以降は80%以上を維持しています。コードオーナー不足の検出数自体にも減少傾向が見られますが、3月以降は30件程度を維持しています。

評価

以上の結果を踏まえ、Codemap Checkerの効果を評価します。

コードオーナー不足のままマージされたPRの減少

Codemap Checkerの導入により、コードオーナー不足のままマージされたPRの割合が90%以上減少しました。導入初期はコードオーナー不足が検出されても約70%のPRが未修正のままマージされていますが、修正率は徐々に向上し、今年の4月以降は修正率80%以上を維持しています。導入してから数カ月をかけて、「Codemap Checkerが失敗したら修正する」流れが浸透したものと考えられます。

コードオーナー不足が検出されるPRの減少

Codemap Checkerの導入後、コードオーナー不足が検出されるPR自体も減っています。その理由として、並行して実施されていた「既存ファイルにコードオーナーを付与する取り組み」が挙げられます。これは、コードオーナーが設定されていない既存ファイルを列挙し、オーナーを持つべきチームを見つける取り組みです。この活動によって既存ファイルに対するコードオーナー設定率が向上し、検出回数が減ったものと考えられます。

今後の課題

Codemap Checkerによってコードオーナー不足のままマージされるPRは減少しましたが、ゼロにはなっていません。原因の一つとして、コードオーナーが付けづらいファイルが残っていることが考えられます。例えば起動処理を行うようなファイルは責務が多く、一つのチームだけがオーナーを持つのは現実的ではありません。このようなファイルのコードオーナーをどうしていくか、議論する必要があります。

またCodemap Checkerの実行履歴だけでは、どのファイルのコードオーナー不足が無視されたのかを調べることができません。GitHub Actionsのワークフローログは最大90日間しか保存されないためです。より詳細な改善案を考えるために、Codemap Checkerに「任意のPRにおけるコードオーナー不足ファイルを取得する機能」の追加を検討しています。

Claude Codeを用いた解析スクリプトの開発

今回の解析スクリプトは、Claude Codeを用いて実装を行いました。非常に効率的に開発することができたので、良かったこと苦労したことを共有します。

良かったこと

CLAUDE.mdには「GitHub Actionsの実行結果を解析するCLIツールである」とだけ書きましたが、それを実現するための環境構築を全て行ってくれました。そのおかげで解析ロジックの構築に集中することができました。また、解析途中でAPIのレート制限に引っかかってしまいましたが、対話モードでその旨を伝えると適切な回避策を追加実装してくれました。開発経験があまりない分野だったため、環境構築やレート制限対策などをすぐに解決できたのは非常に助かりました。

苦労したこと

GitHub REST APIをたたく部分では、間違った仕様で実装されることが多々ありました。例えばヘッダーへの認証情報の渡し方が間違っていたり、レスポンスパラメータの意味を誤認していたりしました。これを解決するために、まずは人力でドキュメントを参照し、手元でAPIをたたくなどして仕様を調べました。その上でCLAUDE.mdに以下のような細かい指示を書きました:

## GitHub REST API
- Base URL: `https://${hostname}/api/v3`
- Header:
  - `Accept: application/vnd.github+json`
  - `Authorization: Bearer ${GHE_TOKEN}`
  - `X-GitHub-Api-Version: 2022-11-28`
  
## スクリプトの流れ
1. Workflowのrunsを取得
  - endpoint: `/repos/${owner}/${repo}/actions/workflows/${workflowId}/runs`
  - `conclusion`が`skipped`であるrunsは除外してください

2. RunsをPRごとにグルーピング
  - このworkflowはPRイベントによって発火されるため、必ずPRが存在します
  - 各runにPRは直接ひもづいていないため、`head_repo`と`head_branch`を組み合わせた`pr_identifier`を作り、同一PRかどうか判定します
    - `identifier`: ${head_repo}:${head_branch}`
      - `head_repo`: `run.head_repository.full_name`
      - `head_branch`: `run.head_branch`

...

これにより、スクリプトを正確に実装させることができました。

おわりに

Codemap Checkerによって、コードオーナーの確認と修正が開発プロセスに定着し、コードオーナーが不足したままマージされるPRが大幅に減少しました。一方で、責務が複雑なファイルの扱いや検出結果の長期的な追跡といった課題も残されています。今後はCodemap Checkerの機能拡張やコードオーナー割り当ての再検討を進め、さらなる改善を目指します。またClaude Codeの活用により、効率的な解析を実現できた点も大きな成果でした。今回の取り組みが、同様の課題に取り組む方々の参考になれば幸いです。