はじめに
本記事では、2年目のエンジニアがデータ分析を通じてチームの文化に切り込んでみた経験を共有します。
※実際の経験に基づきますが、登場人物や具体的なデータはフィクションを含んで構成しています。（特定の個人や組織を指すものではありません）。
本記事は NSSOL Advent Calendar 2025の 10日目の記事です。
「レビューコメント」の分析をしてみた
私のチームでは、Azure DevOpsのReposというサービスを用いてプルリクエストを管理しています。
その中で、プルリクエスト(PR)についたコメントをAzure DevOpsのAPIをつかって集計し分析する取り組みを行っています。
分析の方法
同様の運用をされているところも多いと思いますが、各コメントの冒頭に「指摘カテゴリ」をつけるルールを導入しました。具体的には、PRのコメント欄に書く際、必ず[カテゴリ名]で始めるというシンプルなルールです。こうすることで、Azure DevOps APIで取得したコメントをPythonやPowershellで正規表現を使って簡単に分類でき、ExcelやPower BIで集計できるようになりました。(詳しい方法についてはまたどこかで書ければいいと思っています)
たとえば、こんな感じでコメントを付けます。
[表記ゆれ]設計書と表記を統一してください[質問/確認]ここって〇〇を想定していますか？[メモ]△△後にマージする
これを集計すると、レビュワーごとの「得意な指摘カテゴリ」やレビューイごとの「よく指摘されるカテゴリ」が可視化できますし、そこから見える課題に対して施策も打てます。
「実装ミス」が多いレビューイには、ペアプロの環境を整えたり、
全体的に「表記ゆれ」が多い場合には、Lint等のCIを強化したり。とまあそういった雰囲気です。
さらには、クォーターごとの比較で、打った施策の効果を定量的に測っています。
このように、私たちのチームでは品質分析のためにこのツールを重宝しています。
レビューコメント集計時に感じた違和感
もともと私たちのチームは以下のような指摘カテゴリを使用していました。
- 実装ミス：ロジックの不備など
- 表記ゆれ：誤字脱字など
- 提案/要望：改善のアイデアなど
- 質問/確認：不明点の確認や認識合わせ
- コメント：Javadocなどを含むコメントの不備
- メモ：備忘録など
(ほかにもいくつか)
ある日、2年目の私は分析係を任され、意気揚々とデータを集計していました。指摘分類ごとの件数をランキング形式にしたところ、以下のようになりました。
- 提案/要望 (40%)
- 表記ゆれ (35%)
- 実装ミス (20%)
- その他 (5%)
これを見た、私の正直な感想としては以下の通りでした。
- 「実装ミス、意外と少なくね？優秀じゃん！」
- 「というか、提案/要望が多すぎないか？」
分析係の私としては、「提案/要望」がはっきり言って邪魔でした。なぜなら、具体性がなく分析のノイズになるからです。
具体性がある指摘カテゴリを集計しない限り、本質的な議論はできません。
私は「提案/要望」の想定外の多さに違和感を感じていました。
「提案/要望」の中身
「提案/要望」について気になった私は、その中身を精査してみました。すると、以下のようなコメントが大量に見つかりました。
[提案/要望]不要なループなので、breakで抜けてください[提案/要望]〇〇から△△を呼び出すのはベストプラクティスではありません[提案/要望]ここは設計書通りnullチェックをしてください
全部実装ミスやんけ！！！
バグにつながるような処理や、アンチパターンさえも「提案/要望」というオブラートに包まれていることがわかりました。「提案/要望」の仮面を被った「実装ミス」が、実はたくさん潜んでいたのです。
ただ私としては、この現状を「コメントの分類、もうちょっとうまくお願いします」で終わらせたくなかったので、もう一歩踏み込んでみました。
レビュワーの本音とチームの現状
レビュワー数人に、『なんで「実装ミス」じゃなくて「提案/要望」にしちゃうんですか？』と、率直に聞いてみました。すると、以下のような答えが返ってきました。
- 「実装ミス」って書くと、厳しくいってる感じがして言いづらい
- 経験の浅いメンバーに対しては、萎縮させないよう配慮してしまう
- 「間違いだ」という指摘は、心理的な負荷が高い
ここで浮き彫りになったのは、以下の2つのチームの現状です。
- 技術的フィードバックよりも「気遣い、遠慮」が優先されてしまっている
- コードレビューをネガティブにとらえているメンバーがいる
他の方の記事で、
レビューはテストの採点じゃなくて、認識を揃えるための対話だ
とありましたが、現状のレビュー環境はそうなっていないことが判明しました。
「表面的な」心理的安全性
話は大いに飛躍するかもしれませんが、この問題はチームの心理的安全性に関わってくることだと私は感じました。
当時の私は、チームの「心理的安全性が高い」と思っていました。みんな仲がいいですし、キツイ言い方の人もいない、ブリリアントジャークもいない。
しかし、今回の件で、「仲がいい＝心理的安全性が高い」ではないのかもしれない、と思いました。
心理的安全性 最強の教科書などの書籍でも述べられていますが、心理的安全性とは、「お互いに高め合える関係を持って、建設的な意見の対立(Healthy Conflict)が奨励されること」 を指します。
この本の中では、チームの心理的安全性を高めるためには以下のようなことも必要だと述べられています。
- 「気遣って、言わない」はNG
- 人にやさしく、結果(アウトプット)に厳しく
「ミスをミスと言わない」のはやさしさではない、と学びました。その人の成長機会を奪うことにつながりかねません。
僕たちのチームは、「表面的に心理的安全性が高い」だけだったのかもしれません。
（専門用語でいうと、「Artificial Harmony(人工的な調和)」とか「Ruinous Empathy(破壊的共感)」とか言うらしいです。）
改善策：人は悪くない！悪いのは仕組みだ
とはいえ、『みんな、これからは恐れず厳しく「実装ミス」と書こう！』と精神論で呼びかけても、人は変わらないでしょう。
みんないい人で、お互いをリスペクトしていますし、チームのことを想ってこその「提案/要望」です。
私は、仕組みを変えようと考えました。そもそも、「実装ミス」 ってどやねん？
「実装ミス」というカテゴリには、2つの欠点があります。
- 攻撃性が高い：「お前は間違っている」という断定的なニュアンスがあるため、レビュワーも書きづらいしレビューイも心理的に負荷がかかる。あと主観的。
- 具体性がない：なにをどうミスをしているのか、中身を見ないとわからない。
この2つの欠点によって、私たちのチームは「提案/要望」にまみれていたわけです。
そこで私は、「実装ミス」というカテゴリを廃止しました。その代わりに、MicrosoftやGoogleのガイドラインを参考に、より客観的で具体的なカテゴリに細分化しました。
新・指摘カテゴリ (「実装ミス」を細分化)
- 可読性
- 保守性
- 命名
- エラーハンドリング
- ロジック
- テスト
…など。
そうすれば、「実装ミス」というキツイ言い方の、具体性のない指摘分類から脱して、問題の観点を明確にできますし、レビューイ側も何の話か分かりやすくなります。
※ベストプラクティスでいうと、「must (絶対直せ)」「suggest (改善提案)」「ask (質問/確認)」「nit (軽微、好み、ついで)」みたいに指摘の温度感を記載する方法もあるみたいなので、取り入れるかは要検討です
結果：いいことがたくさん
「実装ミス」という言葉をやめただけで、ポジティブな変化がたくさんありました。
1. 指摘の心理的ハードルが下がった
『これはお前の「実装ミス」だ』という人を対象としたレビュー分類から、
『ここは「可読性」の観点で修正が必要です』や
『「命名」の観点で、△△よりも〇〇のほうがいいと思います』という
コードを対象としたレビュー分類に変わったことにより、レビュー指摘側の心理的ハードルが下がりました。結果的に、「提案/要望」に内包されていたレビューも減少し、レビューで率直な意見を言えるようになっていると感じています。
2. 分析の解像度が上がった
本来の目的だったデータ分析についても、より細かい粒度での分析ができるようになり、精度がアップしました。
『Aさんは「エラーハンドリング」の指摘が多いから、例外処理についてフォローしよう』というように、具体的なネクストアクションがとれるようになりました。
3. 若手のレビューが増えた！！(一番大事)
思ってもみなかった成果でした。年長者が若手に対して「実装ミス」だというのは気が引けるように、若手も年長者に対して「あなたの実装、ミスってますよ」とは言えなかったんですよね。よく考えたら当たり前ですが…
「実装ミス」ではなく具体的な観点になったことで、(僕を含め)若手メンバーが自主的にレビューを行う頻度が向上し、議論が活発になりました。
課題もある、伸びしろもある
まだ課題もあります。指摘カテゴリを細分化したことでレビュワーの負担は上がりますし、運用も多少複雑になります。進める中で少しずつ改善していけたらいいなと思っています。
チームオリジナルの指摘カテゴリを作ってみても面白いかもしれませんね。[最高] とか。
さいごに
チームの何気ない運用ルールが心理的安全性を下げかねないと学びました。
逆に言うと、少しの仕組み作りで、劇的にチームが変わる可能性もあるということです。
今後も自分自身、小さい仕組みづくりを積み重ねて、いいチーム作りができたらいいなと思っています。