プルリクエストを使う３つの理由について
こんにちは、システム開発部のうのです。 新参システムエンジニアとして仕事をしています。
つい最近、システムエンジニアになり、 システムエンジニアとしてプロジェクトの進行管理をしています。 さらに最近の出来事ですが、プロジェクトで 「プルリクエスト」 を使い始めました。 これが中々に良い効果を生んでいるので、どのように使っているか、紹介しようと思います。
チーム開発には欠かせない「プルリクエスト」という概念ですが、 個人開発をしているときには中々出会わないので、なじみがない人も多いでしょう。
「なんかプルリクエストを使うって言われたけど、しっくりこない…… 面倒そうなのに、なんで使うんだろう？」
という疑問が解消されるはずです。 早速行きましょう！
目次
プルリクエストを使っている、もしくは使うことになったけど、その価値や使う理由が分からない
プルリクエスト（プルリク）とは何か、という記事はたくさんあるので、プルリク自体の説明はそちらに任せるとして、 この記事ではプルリクを使う理由を説明していきます。
とはいえ「調べろ」と突き放すのもなんですから……ウェブネーションでは「Backlog」というツールを使ってプルリクをしていますので、Backlogの記事を紹介しておきます。
プルリクを使う理由は３点用意しました。
それぞれ見ていきましょう。
1. 変更点と課題が見えやすくなる
まず、主に管理側の意見ですが、マネジメントがやりやすくなります。 プルリクはソースコードの変更をまとめて確認できるので、ただ単に「変更しました」とソースコードを渡されるよりも変更点が分かりやすいです。
さらに、変更点が分かりやすいということは、課題が見えやすくなるということで、 追加のタスクとしてそれを登録することも簡単になります。
2. コードレビューをする文化がつく
プルリクを使って作業をマージしていくということは、 コードレビューをする文化がつくということです。
コードレビューを支援する機能がたくさんついているので、 不安に思っていることや保留にしていることが相談しやすく、 コードを書くときに迷う必要がなくなります。
もちろん、書くときに「怪しいな」と思った箇所、 もっといい実装があるはずと思った箇所については、 プルリクをする際に報告することが必要です。
3. コードについて議論ができる
コードレビューをする文化がつくと、 コードの実装方法などについて議論の機会が生まれます。 そのため、悪いコードが生成されにくくなります。
議論をする場としても、プルリクは適しています。 コードに直接コメントを書き込むことができるので、どこについてコメントをしているのか分かりやすいです。
コードの複数箇所にコメントが必要な場合でも、 別の箇所でのコメントに気を使う必要はありません。
プルリクエストを具体的にどう使えばよいのか
使う理由がわかったところで、 「けど、実際どう使っているの？」 という疑問にも答えたいと思います。
試行錯誤の途中ですが、 プルリクをどう使っているかと、その理由を紹介します。
プルリクに書く6項目
早速、プルリクをどのように使うか見ていきましょう。 プルリクに書く内容は、現在6項目で試しています。 その内容は、
- 1. プルリクの目的
- 2. 目的の達成条件
- 3. 作業内容の概要
- 4. レビューして欲しいところ
- 5. 不安に思っていること
- 6. 保留していること
です。
それぞれ見ていきましょう。
1. プルリクの目的
プルリクの目的は、 何のために作業をしたか 、です。 例えば
- 「ログインユーザーが、投稿一覧画面で投稿を検索できるようにしたい」
- 「ログイン画面で、【あなたはロボットではありませんか？】のチェックを要求するようにしたい」
- 「お問い合わせフォームを作成する」
などです。 関連するタスクやプルリクがあれば貼り付けておくと、 「これは何の作業なのか」が分かりやすくなります。
2. 目的の達成条件
目的を達成するために、必要だと思われること、必要だったこと を列挙します。
例えば、初期に想定されていた作業が
- 新規のページとして「お問い合わせ」を作成・サイトマップに登録
- 他のページの流用でフォームを実装する
くらいの内容だったにもかかわらず、 作り始めたらすごく多くのことをやらないといけなかった…… という場合に、ここでそれを伝えます。
作業項目が想定内だったか、そうでなかったか をチームメンバーに知らせましょう。 これがわかると、素早くレビューができます。 想定外の項目が多い場合、プロジェクトを軌道修正する必要もあるかもしれません。
ここに書く項目が多い場合は段階分けをしたリストにするとよいでしょう。 例えば、
- 新規のページとして「お問い合わせ」を作成・サイトマップに登録
- 他のページの流用でフォームを実装する
- メールアドレスのチェックを実装する
- フォームに項目欄を追加
- 項目を決定
- カテゴリを選んでから項目を絞りこんで表示するよう、フォームを実装
- お問い合わせ用にメールの設定
- メールアドレスを発行
- 設定ファイルにメールアドレスを追記
のような感じです。
3. 作業内容の概要
目的の達成条件を受けて、どのような作業をしたか を書きます。 目的の達成条件がシンプルならば、省略されることもあるかもしれません。
ソースコードやドキュメントの変更を見る前に、 「何をしたか」がわかるように書きます。
お問い合わせフォームの例でいうならば、
-
「お問い合わせフォームに、何についてのお問い合わせか、を指定する項目を追加することになったので、 そのためのデータベース変更や部品の開発をしました。項目の一覧はドキュメントに追加しています。」
-
「メールアドレスを分ける仕様だったため、ドキュメントと設定ファイルを変更しています。」
などです。 コミットメッセージをまとめた内容となるとよいでしょう。
4. レビューして欲しいところ
もしコードを書いていて
- 「変数や関数名、この命名でいいのかな」
- 「長いコードになってしまったけど、もっといい書き方はないかな」
- 「動くけど、なんとなく引っかかる」
という部分があれば、 積極的にプルリクエストに書きましょう。
プルリクエストには コードにコメントをする機能がある ので、 コメントを積極的に使用すると、 該当する箇所が分かって良い です。
5. 不安に思っていること
仕様やコードの構造、今後の作業に不安があれば、これも積極的に書きましょう。 レビューしてほしいところと同じく、コメントを駆使するとわかりやすいです。
- 「現時点では動くけど、仕様が変更されたら対応が難しいかもしれない」
- 「今後追加される予定の機能と相性が良くないかもしれない」
- 「ユーザーにとってあまり良くないUIだから、あとで見直す必要がある」
- 「使い方が直感的に分かりにくいので、○○のプラグインを追加したほうがよさそう」
などです。
6. 保留していること
他タスクとの兼ね合いなどで、 実装を保留した点があれば 、これも列挙しておきましょう。
「○○って作ってないの？」「××が未実装なので実装できませんでした、保留しています」
などのやり取りはあまりしたくないものです。
これは例えば、
- ○○へのリンクは、○○が未実装のため現在はプレーンテキストで仮置きしています。
- ××はタスク「△△」で対応する予定です。
のように書くことになるでしょう。
プロジェクトについて
プルリク自体の使い方も大事ですが、プロジェクトの体制や文化も大事な要素です。
プロジェクト単位でプルリクを使うための体制を整えておけば、 さらにスムーズに作業が進むでしょう。
例えば、
- 一人、マージ担当の人を置く
- 作業者に、なるべく細かく（タスクごとなど）プルリクを作成してもらう
- ブランチごとに環境が変わっても、切り変え時に環境構成をする手間がなるべく必要ない状況にしておく
- dockerを使うと環境の構成設定を管理できて便利
- 複数人でレビューをする
- 担当者じゃなくてもコメントをする
のようなことが出来れば、よりプルリクの恩恵を受けることができます。
初心者システムエンジニアとしてプロジェクトを進めることができています
冒頭でも言いましたが、最近、システムエンジニアとして プルリクを使ってプロジェクトをまとめることを始めました。
ありがたいことに、ウェブネーションで働き始めてからで言うと長い間、 システムエンジニアとしてプロジェクトを取りまとめています。 業務経験としては1年に満たないのですけどね。
その経験の中で、プルリクの威力をひしひしと感じています。 非常に便利な仕組みです。 今は最初動かしていたプロジェクトよりも数倍大きな規模の新規プロジェクトを 数倍の人数で動かしています。 ですが、確実に進んでいるし、前に進むことができています。 プルリクを使っていない以前のやりかたでやっていたら、パンクしていたと思います。
もっと良いプロジェクトの運営ができるよう、 さらに探求していきたいものです。
ではまた次回お会いしましょう。 うのでした。
