3年目社員が始める開発者としてのレビューコミュニケーション

はじめに

NTTドコモ データプラットフォーム部（以下DP部）の3年目の福本です。 普段はクラウド設計や関連部署との調整作業をしています。

また、私は7月からデータ活用プロダクトの内製開発にも参画しており、 本プロジェクトにおいて、初めて社会人としてコーディングを含む開発作業に関わる機会がありました。 今回はこのプロジェクトでの開発についてお話させていただきます。

私のような若手の皆様は、学生の頃に個人開発やハッカソンを経験している一方で、業務での開発におけるコード管理手法については、よくわからない、という方も多いのではないでしょうか？ 特に、レビューというプロセスにおいては、「なんか偉い人に指摘を受けるもの」「形式上成果物を全体の責任にする儀式」と考えている方も多いのではないかと思います。

私もその一人でしたが、レビューを儀式的なものではなく、効率的に活用することで、 よりよいプロダクトに近づき、技術者としての知見も得られることを実感しました。

本稿では、私のような開発初心者の若手社員向けに、本プロジェクトの経験中に学んだレビュープロセスのメリット 、特に一般的なコード管理ツールであるGitHubにおける、コードレビュープロセスであるプルリクエストを書くコツについてお話しします。

プロジェクトについて

参画させていただいたプロジェクトは、当初、私の「開発作業がしたい」という希望でアサインしていただきました。 その都合もあり、通常業務のタスクに加えての開発作業になり、本プロジェクトに捻出できる稼働は業務時間の約半分程度でした。

プロジェクトの目標成果物は、Streamlitを使用して、帳票アプリを作成することが目的でした。プロジェクトメンバーは下記のとおりです。

• PG（プログラマー）：1名(筆者)
• PM（プロジェクトマネージャー）：1名
• レビュアー：2名

私が参画した時には、要件は固まっており、PMに提示していただいたビジョンを基に、コーディング作業を進めていく段階でした。 色々な調整の結果、2週間のスプリントでアジャイル開発の手法で実装を進めていく整理になりました． また、PGとして私が参画するにあたって、コードの質を確保するために、同じ技術スタックの別プロダクトの製作メンバーにレビューをお願いしました。

直面した課題

先述のように、私のような若手社員をプロジェクトにアサインする場合、先述のように外部からコードレビュアーを混ぜてコードの質を担保するというケースも多いと思います。

その際に我々若手目線で問題になるのが、プロジェクトの詳細を知らないレビュアーに対して、レビューを依頼するという作業です。

プロダクトに関するタスクは、PMから各PGに降りてくるものが多く、全ての意思決定に関して、レビュアーが同席するわけではありません。 そのため、レビューの依頼には、背景の説明も必要となり、個人開発のような何も書かないプルリクエストでマージする、というわけにはいきません。 加えて、今回は半分程度の稼働で開発作業する必要があり、また、レビューメンバーにも他のタスクがあったため、一から十まで全てを詳細にコミュニケーションを取るということもできませんでした。 そのため、簡潔で素早くレビューがもらえるような、最適化されたプルリクエストを記述する必要がありました。

プルリクエストでコミュニケーションを取るには

ここからは具体的にどんなことに注意したのかについて述べます。

1.解決する予定のissueを記載する

プルリクエストには関連するissueのIDを必ず記載しました。これにより、レビューを行う人が対象の問題を簡単に参照できるため、何に対してのPRなのか、理解が深まりやすくなります。GitHubでは、下記のように、プルリクエストにURLを添付することによって、issueにつけたタイトルが記載されます。

## チケットへのリンク
- https://github.com/[Organization_name]/[Project_name]/issues/[issue_id]

## やったこと
- 

プルリクエストにIssueのリンクを添付すると状態とタイトルが引用される

2.結果が見てわかるように画像を入れる

UIの変更や機能追加の場合、スクリーンショットやGIFを添付すると、視覚的に成果を示すことができます。これにより、変更点を直感的に理解しやすくなり、レビューがスムーズに進みました。より詳細に書く場合は、「変更前」と「変更後」の比較画像を並べて掲載することで、プルリクエストの内容をよりクリアに伝えることができます。 また、画像に印を入れて変更箇所を強調することもレビュアーに好評でした。

3.コミットメッセージをわかりやすくする

これは、自身がプルリクエストを書く際にissueの記載漏れがないか確認するのに役立っていました。コミットメッセージを英語で書くか、日本語で書くか、あるいはプレフィックス記法については、各組織において、ルールがあるかと思います。私は、add/fix/del/updateの4つのプレフィックスに加えて、メッセージを日本語で加えてコミットを実施していました。

• add ... 機能追加
• fix ... バグの修正や、文言の変更
• del ... 可視性の整理の上で不要になったコードの削除
• update ... 設定ファイルや依存性定義の更新

4.レビュアーの承認は期限を切ってお願いする

プルリクエストを作成した際には、いつまでにレビューをしてほしいかを付帯して依頼するようにしました。 自動的にslack等にプルリクエストの発行を通知する機能もありますが、こちらよりも、実際に相手にメンションして依頼する方が迅速にレビューをもらえる傾向にありました。

5. 作成したプルリクエストのブランチに何をもたらすのか明確にする

プルリクエストを使用してレビューする上で、当然、更なる改善や、コードの改良の話が挙がります。 迅速な開発において、時間とコードの品質はどちらかを優先するか判断する必要があります。

レビューコメントをいただいた際に選択できるアクションは、①レビューを受け入れてコードを改変する、もしくは②Issueとして起票してこのプルリクエストには含めない、のどちらかだと思います。 この判断を実施する指標の一つとして、表題の「プルリクエストにブランチに何をもたらすのか」を考慮していました。

つまり、判断として、プルリクエストの興味関心の改修内容なのか？という部分の上で、興味関心にない部分は②の方に判断を下し、 関心に含まれると客観的に判断できる場合は、原則②を考慮に入れるように判断しました。

例えば、下記の例では、プルリクエストでは、アプリの静的な文字列の改修を実施していた際のやり取りで、全体的な使用感をレビューしていただいていました。 こちらは、SQLがかかわってくるため、プルリクエストの関心の外にあるため、②の判断をしています。（素っ気なく見えますが、裏でオーラルコミュニケーションしています）

SQLの調査が必要なため、別issueにあげて対応している（「私」は筆者、「レ」はレビュアー）

他の例としては、フロントエンドで言うview部分に対して、マルチスレッド処理を実装するプルリクエストでは、下記のように変更を実施しました。（もはや当初依頼していたコード品質のレビューの域を超えてます。本当にレビュアーの皆様には御礼申し上げます。）

レビューを反映する例（「私」は筆者、「レ」はレビュアー）

6.テンプレートを活用する

最後に、1～3を早く実装する方法として、プルリクエストテンプレートを活用しました。 プルリクエストのテンプレートを用意することで、抜け漏れを防ぎ、それぞれのプルリクエストの品質を担保できます。 テンプレートに関しては、インターネットにも有用なテンプレートがいくつかあります。私のプロジェクトでは、他プロジェクトの先人の知恵をお借りして、何度かの修正を加えながら、最終的には、以下のようなフォーマットになりました。

## チケットへのリンク
[ここにURLを貼り付ける]
[ここにURLを貼り付ける]
...

## やったこと
[コードのどの部分を変更したか？（どんな手段でissueを解決しようとしているのか？）もしくはその変更によってプロダクトはどう変化するか？]

## やっていないこと
[新たに発生する懸念をissue化して、URLを貼り付けておく]
[統合テストで見るべきポイントをここに書いておく]

## 動作確認
[テストの操作の手続きを書く。]
[スクリーンショットを貼り付けておく。]

プルリクエストを最適化して良かった点

主に3つのメリットが得られました。1つめは、迅速に承認してもらえることです。レビュアーに対して迅速に内容を理解してもらえるため、結果として承認が早く得られたように思います。 これにより、タスクの消化がスムーズに進行し、プロジェクトの進捗が安定しました。

2つ目はコメントアウトが減って、コードが綺麗になる点です。個人開発の場では、TODOや、処理にまつわるコメントをどうしてもコード上に残してしまいがちになると思います。このような実装に関わる疑問や展望をコード上ではなく、プルリクエストに証跡として残しておくことで、コードを書く際に、スプリントにおいて取り扱うissueに対して集中して取り組むことができます。

3つ目は、レビュアーにプロダクトに関する議論に参加してもらえた点があります。プロジェクトの現場では、POの描いたビジョンと実際の実装との間には微妙なズレが生じることがあります。このような場合、PMとPGだけでなく、レビュアーも交えて議論することで、より客観性の高い、良いUXを提供する方法や実装の改善点が議論される機会ができていました。

プロジェクトを振り返って

今回のプロジェクトでは、上記の要点を抑えつつ開発を進めた結果、安定した速度でプロジェクト進行することができました。プロジェクトの進行メトリクスはいくつか指標はありますが、スプリントごとのコード改変量を抽出してみました。実際に、主な開発期間であったSprint 1～8においては、各スプリントごとのコードの改変量(追記行 + 削除行)を見ると、安定した数値で進行ができていることがわかります。また、統合テストや、リリース準備を実施したSprint9,10においては、ほとんどコードに手戻りや改修などが無いことが見て取れます。

Sprintごとのコード改変量(設定ファイル、画像、first commitを除く)

また、各スプリントイベントにおいて、より上質なプロダクトめざした議論ができたため、開発者体験としても大変良いものとなりました。 今後のプロジェクトにおいても、この経験を生かして、さらなる成果を目指したいと思います。

まとめ

本稿では、私の経験を交え、良質なプルリクエストを書くことによるメリットについてお伝えしました。入社して以来、希望していた開発の経験ができ、さらに、非常に高い開発者体験ができました。 この場をお借りして、本プロジェクトにかかわったいただいたメンバーに御礼申し上げます。NTTドコモでは、私のように、業務開発が未経験の新人でも、手を挙げることで、任せていただける環境が整っています。今後もNTTドコモでバリバリ頑張りたいと思います！