【コードレビュー】プルリクエストのコメント自体を定量評価にすると低品質なコメントばかりになるので、定性評価も併用するのが賢明という話
はじめに
対象
- プルリクエストのコメントの質を向上させたいITエンジニア向け。
コメントを定性評価しないか？
定量評価と定性評価
プルリクエストのコメントにおける定量評価とはノルマ制です。1日3コメント、1プルリク1コメントなどのノルマが決まっています。ノルマを達成できない場合は、ペナルティとして追加の勉強会が実施されたり、会議で改善相談という名の吊し上げをされたり。
※営業ではないです、開発の話です。無自覚にやってるところが凄いですが汗。
定量評価のデメリットについては、以下の記事でまとめています。
プルリクエストのコメントにおける定性評価は、コメントの内容や与えた影響を評価することです。例えばあるコメントが脆弱性を発見し指摘したとしたら、セキュリティ事故を未然に防いだ功績は称えられて然るべきです。
ですが定性評価はあまりされていないのが現状です。
そもコメントの質を評価しているか
プルリクエストのコメントマナー講座は度々記事になりますが、そもそもの話、プルリクエストのコメント自体がプロジェクトの評価の外側にある状態では、品質をどれほど上げようがプロジェクトのピンチを救おうが、同じお給料・報酬になってしまう。
企業が社員やフリーランスに報いるなら福利厚生か金になるので、ボーナスを上げるなり単価を上げるなりすることになるけれど。その評価の軸にプルリクエストのコメントが入ることは、あまりないのではありませんか。
どんな機能を実装しただとか、無事故・無障害で今期を終えたとか、CIの改善でコストを何％下げただとか。定量評価に合わせる形で内容を決めていやしませんか。もし変換が必要であれば、それこそコメントの質を段階評価や点数に落とし込んでも良いのに。
逆にプルリクエストでやらかしまくってる場合も、それ相応の評価をする必要はあるでしょう。善管注意義務違反な実装をすれば良くて契約終了ですし、クソリプまがいのコメントや明らかなパワハラ・筋の通らない指摘を押し通すなどもってのほかです。
定性評価のすすめ
この機会にコメント自体を定性評価してみませんか。
- 不具合や障害を未然に防いだ。 +5
- 保守性・製品品質の向上に貢献した。 +3
- 相手の時間を奪わないコメントをした。 +3
- レビュイーからのフィードバックに悪い点がない。 +4
- ...
などなど。コメントの数ではなく、中身の質で点数を付けていく方法です。
この方法であれば、良いコメントをした開発者には報いることができ、酷いコメントをした開発者の評価は下げることができます。もちろん事実確認は必要ですし、プルリクエスト自体に問題があるのかコメントだけが問題なのか、見抜ける開発者がいることが前提ですが。
特に実装者も気付かなかった不具合を、事前に発見してもらえたら感謝しかありませんし。もしも自分が発見してもらったら「危ないところを助けていただき、ありがとうございました」と最敬礼すること間違いなしの功績ですから。
定性評価がもたらす恩恵
コメントを見直すきっかけになる
多くの場合、多少嫌に感じることがあっても、プルリクエストで直接指摘することはないです。まともな現場であればこそ「あのプルリクエストのコメントどうだった？」と聞ける機会があまりないのです。せいぜいが飲みの席や雑談のときにポロッと聞けるかどうかです。
振り返りミーティングなどで良いコメントにお礼を言うことこそあるかもしれませんが、こと悪いコメントについて伝える機会というのはありません。直接本人に伝えるのは問題があるので、1on1や評価面談などで個別に聞き取りを行い、間接的に伝えるのがいいでしょう。
フィードバックがきちんと機能するようになれば、本人がコメントを改善することもできます。社内評価や単価に響くとあれば、少なからず表面上は気を付けるようになると願いたいです。
潤滑油な人材が埋もれてたかも
プルリクエストのコメントが上手い人は尊敬に値します。コメントを受け取ってから迷うということがないですし、指摘事項も的を射ています。レビューする人の力量次第で、作業の進捗率や品質が大きく変わるといっても過言ではありません。
ことチーム開発においては、ソロで開発効率が良い開発者よりも、チーム全体の開発効率にバフをかけデバフをかけない開発者の方が遥かに優秀です。コメント上手な方はバフをかけるのが上手く、単独の戦闘力では非効率に見えても、チーム全体の効率を何倍にも高めています。
直接的な攻撃力だけを指標にしていると埋もれてしまって分かりません。プルリクエストのレビューを定性評価という角度で捉え可視化すれば、そのような潤滑油人材を発見し重用できる可能性があります。
結果的にプルリクエストの質が上がる
別記事の繰り返しになってしまいますが。定量評価だけを用い続けると、社会的手抜き、高多重度によるチェックの機能不全、低品質コメントの増加、難易度の高いプルリクエストの放置など、様々な問題が発生します。
それは単に数だけをノルマ、つまり目標として設定しているのが原因です。いくらノルマを達成できていたとしても、一つ一つの品質が伴わないのであれば困ってしまいます。採算の取れない契約を沢山取ってきても、褒められたものではないでしょう。
定性評価を併用し、きちんと中身を確認することで、このような暴走を防ぐことができます。本当に意味のあるコメント・必要なコメントかどうか考えるようになりますし、相手に伝わりやすいよう工夫して伝えることも覚えていけるかもしれません。
定性評価における課題
客観的に評価できる人材の確保
これが最も難しいと思います。プルリクエストを作成した人と、プルリクエストをレビューした人のやり取り全体を見て、各々の意見を聞いた上で、客観的に見てどちらの言い分が妥当か、定性評価を算出するとしたらどの項目が何点になるか決めないといけません。
となると順当なところで、他のチームのレビュワーをドナドナしてくるしかないでしょう。リーダーはレビュワーであることが多いでしょうし、マネージャーは普段からコードを細部まで見てはいないでしょうし。ご多忙中の潤滑油さんに負荷をかけることになりますが致し方なし。
もっと言ってしまえば、そのような人材がいない可能性もあります。いなければ生み出すしかありませんので、まずは勉強会や自己研鑽などでレビュー力を磨くことになります。
恣意性や関係性の排除
前項で他チームから人を連れてきましたが、直接関係ない第三者を連れてきて評価してもらうのが波風立ちません。
今後も共にチーム開発をしていくとなると、少なからず利害関係が発生するため、真っ直ぐな評価を下せないこともあるでしょう。また構築してきた人間関係もあります。誰かを贔屓、あるいは意図せず評価を下げてしまうこともあるかもしれません。
また定性評価は基準が曖昧になりやすく、人によって評価の軸がブレることがあります。星5レビューを付ける海外の方と、星4星3を付ける日本人の話と同じです。評価が属人化しやすいといってもいいかもしれません。
なので導入時には、先述のような評価項目のリストアップはもちろんですが、どの程度できていれば星5なのか、事前に認識合わせをしておく必要があります。
おわりに
実際のところ、プルリクエストのコメントで深刻な問題の一つは、プルリクエスト自体のフィードバックが滅多に行われないところにあると考えています。面と向かって聞けるかというと際どい内容になりますし。
理由を一緒に書きましょう、指示は具体的に。多くの記事にレビューで気を付けることが書かれていて、どんどんコメントが上手くなる方は、それらをきちんと読んでいます。我流の方はいつまでも我流で突っ走ります。
自走してコメントの質を上げられる方は、自分の中だけでもPDCAサイクルを回しているんですね。ただそれができるのはごく一部の、技術だけでなくコミュ力の重要性に気が付いた上で、現段階では評価外でも必要だと思うことに投資できる方でして。
もし定量評価でプロジェクトが上手く回っていないなら、まずはプルリクエストのコメントについて、1on1で相談するところから始めてみてはいかがでしょうか。
Discussion