社内有識者観点を用いたソースコードレビュー自動化の取り組み に対する速報感想 #長崎QDG

本日はこちらの8th長崎QDGに参加しています。この記事ではその中の「社内有識者観点を用いたソースコードレビュー自動化の取り組み」というセッションについての考え方について自分なりの速報感想を書いています！

少なくともこの記事発表時点では、発表資料の公表を確認できなかったのでもし公開を確認できたら、そちらへのリンクも貼りたいと思います。

技術的な側面を中心にソースコードレビューの自動化を実施されている

こちらのセッションは、京セラコミュニケーションシステム株式会社様の実際の取り組みの事例です。（武次 恭平 氏）

タイトルのとおり、コードレビューの自動化を行うにあたって「どのようなことを期待して取り組むか」という点を明らかにした上で、フィードバックと改善を繰り返されてる様子を丁寧に教えていただきました。

以下は、セッションのメモを迷惑にならない程度にまとめたものです。

• 社内のシステム開発部署の効率・品質を向上させるための活動をしている
  • AI関連技術などを活用して生産性を向上させるための技術開発を行なっている
• 背景
  • システム開発部署のコードレビューの属人化を解消したい
    • 特定の人物への負担が偏ったり
  • 最初の構想
    • これまでのソースコードを教師データにして、AI活用でコードレビューの負担を削減できないか？
    • GitHub Actionsを使ってPR作成時に自動実行を行う
• AIツールに使わせるメトリクスの例
  • サイクロマティック複雑度
  • 認知的複雑度
  • 保守容易性指数
  • など
  • この時点ではこれらのメトリクスを使ってAIが一次レビューをしてくれる
  • ちなみに指摘だけでなくて褒めてもくれる
    • 実に美しい！のような。
• この時点でのユーザーのフィードバック
  • 自然と綺麗なコードを意識するようになり見やすいコードになってきている
  • 褒められると嬉しい
  • 指標が悪いのはわかるけど、具体的な修正方法がわからない
  • など
• それを受けて、さらに具体的なレビューを追加するようにアップデート
  • ヒアリングやフィードバックの明文化を行なって、レビュー知識の暗黙知を明文化
  • これらを静的解析でルールベースでレビューされるように
  • さらにツールの指摘の結果を格納して、リンクを貼って教育資料としても活用できるようにしている
    • コメントから遷移することができる
• ここまでのレビュー自動化としての状態について
  • 技術的な側面は時間を人が見る必要がなくなった部分があったり
  • とはいえ、仕様通り実装されているかは2次レビューを行う必要がある
• （ここでは載せて良いのか迷って具体的な数字は避けましたが）定量的な削減効果
  • 1レビュワー辺りの1ヶ月の削減時間
  • レビューにより発生した修正回数

かなり具体的なレビュワー1人当たりの削減時間などの数値も示していただき、決して全てがうまく回す完璧なツールではないという点を示してくれました。

感想のまとめ

• 発表者に対する感想
  • まず理想の状態をしっかりと定義されたうえで、徐々にフィードバックを受けながら改善を進めている姿勢がとても素晴らしいと思いました
  • 社内の有識者の観点を明文化して自社内の静的解析ツールを作成すると言う取り組みもとても素晴らしいと感じました
    • 安易に生成AIの力を借りるよりも、実行コストも低いですし、ツールの適切な使いわけ感も素晴らしいと思いました
• 取りくみに対する感想
  • まずAIのレビューが指摘だけではなく、褒めてくれるのがとても良さそうでした（本当に大事だと思います）
  • さらに指摘の内容を教育資料として活用できるようにリンクを貼っているのがとても良さそうです
    • 後から「この指摘はイマイチ」とか「これはもっともだよな」と見返せるのがとても良さそう
  • 定量的な結果などを示していただき、ある種のリアルを感じました
    • レビュワー1人辺りの削減時間など非常にリアルの息吹を感じました

以上、自分なりの感想となってしまいますが、とても勉強になるセッションでしたし、発表者の方の試行錯誤をここに還元してくれて本当にありがたかったです。

以上、bun913でした。