Merge pull request #1495 from future-architect/feature

コードレビューガイドライン

Author: ma91n

source/_posts/20250502a_コードレビューガイドラインを公開しました.md

@@ -0,0 +1,80 @@
+---
+title: "コードレビューガイドラインを公開しました"
+date: 2025/05/02 00:00:00
+postid: a
+tag:
+  - コードレビュー
+  - ガイドライン
+  - チーム開発
+  - コーディング規約
+category:
+  - Culture
+thumbnail: /images/20250502a/thumbnail.png
+author: 村田靖拓
+lede: "有志の社員が集まってコードレビューガイドラインを作成、公開したのでご紹介します。"
+---
+<a href="村田靖拓"><img src="/images/20250502a/image.png" alt="" width="1200" height="796" loading="lazy"></a>
+
+こんにちは、村田です。
+有志の社員が集まって[コードレビューガイドライン](https://future-architect.github.io/arch-guidelines/documents/forCodeReview/code_review.html)を作成、公開したのでご紹介します。
+
+# 本ガイドラインを読むにあたって
+
+コードレビューガイドラインは、既に公開している[Gitブランチフロー規約](https://future-architect.github.io/arch-guidelines/documents/forGitBranch/git_branch_standards.html)にて推奨されているブランチ戦略や設定が施されていることを想定して作成されています。
+
+前提条件の章を確認の上で本編をご確認ください。
+
+# ガイド作成の背景
+
+みなさんは普段どのよう心構えでレビューをしていますか？
+
+フューチャーでも当然毎日のようにたくさんのコードレビューが実施されているのですが、実際問題としてコードレビューにおける立ち振舞いはチームや人によってマチマチであることが多いです。もちろん世間でもそういうケースは多く散見されるだろうなと思います。
+
+「レビューはコミュニケーションである。コメント記載時には相手への敬意を忘れないこと」
+
+これは今回作成したガイドラインに明記したグラウンドルールです。私が一番好きなパートでもあります。改めて考えてみれば当然なのですが、この当たり前を忘れてしまっているレビューがたまに見受けられるのもまた事実。レビューのキャッチボールにおいて双方の発言や行動をあとほんの少しだけアップデートしてあげればよりスムーズなキャッチボールになるのにな...なんて場面、みなさんも多かれ少なかれ思い当たるのではないでしょうか？
+
+ゆえに今回作成したガイドラインでは、「レビュイー」および「レビュアー」それぞれの立場（役割）において推奨される行動をまとめていくスタイルをとりました。
+
+ちなみに、今回のガイドラインの中ではレビュー観点について網羅的に列挙・記載することは行っていません。開発しているプロダクトの性質・開発体制・採用技術などで観点が大きく変動するためです。
+
+# レビュイーとレビュアー双方の「推奨行動」
+
+ここからは少しガイドラインの中身をご紹介します。この記事においては焦点を絞って簡単にかいつまむ形で紹介しますが、ぜひ詳細はガイド本体をご覧いただけると幸いです。
+
+## レビュイーの推奨行動
+
+本章における記載はマインド面よりも実務的な内容が多いです。つまり読んだ直後から実践可能な内容が多く含まれています。
+
+### プルリクエストの単位を小さくする
+
+レビュアーの負荷を必要以上に高くしてしまう行動のひとつに「複数の改修内容を単一のプルリクエストに含む」ことが挙げられます。
+
+あくまでプルリクエストは小さく保つように心がけましょう。
+
+## プルリクエストのタイトルにプレフィックスを入れる
+
+プルリクエストのタイトルに命名規則をもたせることで、レビュアーの認知負荷を軽減することに繋がります。例えば新機能追加であれば `feat` など、決まった文言をつけるルールをチーム内で決めておくと良いでしょう。
+
+## レビュアーの推奨行動
+
+レビュイーの推奨行動がより具体的なアクションについての記載だったのに対し、レビュアーの推奨行動は比較的マインドセットや心構えについての記載が多めです。読んで即実践、というよりも、読んでその意図を理解しつつ日々の行動を少しずつアップデートしていく、といった使い方をしてもらえればと思います。
+
+### コメント記載時には相手への敬意を忘れないこと
+
+先の章でも触れましたが、このパートが私は一番好きです。レビューは相手を詰問する場ではありません。より良いものをチーム一丸となって作っていく、その意識を忘れないようにしましょう。
+
+### 指摘内容は具体的であればあるだけ良い
+
+時間に追われるレビュアーが簡素なコメントのみでレビューを終わらせてしまうケースがあると思います。もしレビュイーがその指摘から具体的な修正方針を読み取れなかった場合、結局追加のコミュニケーションラリーが発生してしまいますし、往々にしてそういった場面ではレビュイーがその指摘の意図を再度レビュアーへ伺うこと自体の心理的負荷が高くなってしまいがちです。
+
+指摘内容はできる限り具体的に記載されている方が建設的です。
+
+# まとめ
+
+さて、今回はコードレビューガイドラインを紹介させていただきました。このガイドラインが、皆さんのチームにおける開発体験の向上に繋がることを期待しています。ぜひご活用ください！
+
+▼ フューチャーアーキテクト コードレビューガイドラインはこちら
+https://future-architect.github.io/arch-guidelines/documents/forCodeReview/code_review.html
+
+ガイドラインに関するご意見やフィードバックも、もちろんウェルカムです。お待ちしております。