メンバー対談「レビュワーとしてレビューするときってどんな感じ?」yokota × suzuki 編(後編)


Gaji-Laboのメンバーがどんなことを考えながら日々の仕事をしているのかをお伝えするため、対談を記事にしてみようという試みシリーズ。

今回は横田と鈴木がレビュワーとしてレビューするときに考えていることや感じていることについて話してくれています。

話している人

yokota

yokota

運用やアクセシビリティに配慮したHTML/CSSの設計やコンポーネント作成、スタイルガイドの構築、コードレビュー、組み込み、要件の整理、社内進行管理、顧客とのコミュニケーションまで、ジョインしたチームが前に進むためにあれこれ担当しています。子育てと仕事のバランスを楽しめるよう、日々模索しています。

suzuki

suzuki

フロントエンドグループリード。
HTML/CSS のマークアップから始まり、現在は React や TypeScript を使ったコンポーネント実装をすることが多いです。淡々と実装するだけではなくコミュニケーションを取りながら、チームとしてプロジェクトを前に進めることを意識しています。最近は会社の成長へのコミットに関心があり、組織・チーム全体で強まるためにはどうするのだろう?ということを考えています。

レビューの際のチェックは何周かする

yokotaチェックに何周かするよね、まずは機能見て、見た目が再現されてるか見て、コード上妥当性があるものになってるか見て、みたいな。

suzukiそう。わりといろいろそういう感じで見るよね。

yokota自分もプルリク出す側になるときは、できるだけ「ここを見てね」と「ここは見ないでいいです」っていうのはちゃんと書くようにしてるよね。

suzuki見なくていいところもね、確かにね。

yokotaここはこのプルリクでは再現されてないけど、こういう理由で今はやっていません、みたいなことをちゃんと書いて、できるだけ最小のレビューでApproveされたいなって。

suzukiそうだね、うん。あとマージ先によって粗さは変えてるかな。

yokotaああ〜、どうだね、それはあるね。

suzukiもう次はデプロイっていうブランチだったらすごいしっかり見るし、まだマージしても開発用だからリリースまでは遠い、ってなれば、いざとなったら後で直すからってことで、マージ速度を優先する。

yokotaうんうんうん、そうだね、レビューが玉突きで溜まることでコンフリクトが増えたりしちゃうもんね。

suzukiそう、それが重たくなるから。

yokotaコンフリクトするとやることが重くなるもんね。特に開発初期はそうだよね。確かにどんどんマージしていきたい。

suzukiうん。

レビューをすること自体、学びが深い

yokotaでもなんか、レビューをずっとやってると、いろんな人のコードの癖とか命名の癖とかが見れるから、すごい学びがある。

suzuki確かに。

yokotaあの人がこういう実装をするときにはこういうふうに書くな、っていうのが記憶に残ってて、いざ自分が実装するときにそれを見に行けたりするから、レビューし合うのっていいよね。レビューって弊社の基礎というか、ベーシックな文化だと思うけど。

suzukiそうね、そうだね。

yokotaあとあれか、ローカルで立ち上げたときはウェブツールでコンソールは見るかな。結構キーがないよとかはよくあって。マップ回してるところの。

suzukiわかる、実装してるときには気付かないところ出てくるよね。

yokota社内の中でプルリクするときと、お客さんに見せるプルリクでは、ちょっと違うよね。

suzukiうん。そうかも。

yokotaお客さんに見てもらうプルリクは、よりていねいに出す。

suzukiそうだね、いつマージしてもらってもいいように出すかな。

yokotaあとコンテキストをしっかり書くかな。暗黙知に頼らない状態で出す。

suzukiうんうん。あとはどうかなぁ、仕様通りかってところかなぁ。仕様のドキュメントがちゃんと用意されているときは、それ通りになってるかどうかみたいなところを見るかな。

yokotaそうだね、それは重要だね。仕様を実装者が理解していることはもちろんなんだけど、レビュワーが理解してないとレビューできないもんね。

suzukiそうなの。だから意外に見るところあるかなぁ。

yokotaざっと見る箇所を挙げただけでもこんなに出てくるもんね。でもひとつのプルリクで何周かすることもあるから、小さければ小さいほどいいよね。

結局やっぱり、ものによる

suzukiあとは正直、見る相手=作業者によって粗さも変わるかな。

yokotaあるある。

suzukiまぁ全部見るってなると、今挙げたことぐらいは見るかなぁ。

yokotaなんかこう、プロジェクトの初期と中盤で乗ってきたあたりでも全然見方が違うよね。

suzukiうん、そうだね。

yokotaだからこう、メンバーでも観点が変わるけど、フェーズでもちょっと観点が変わるよね。初期はていねいに見るけど、中盤ひたすらに実装するってパターンもあるし。優先して見るところが変わるよね。

suzukiそう。でもさ、やっぱものによるよね!

yokotaそう、ものによる (笑)!

suzukiそのコンポーネントの影響範囲がどのくらいなのかによってもだいぶ違うし。

yokotaあー、それはそうよね。

suzukiかなり重要な機能だってなったら、気にするところが変わったりするから。ものによるって言っちゃったらアレだけど、でもものによる (笑)。

yokota本当そうだね。今日の話の結論は…(笑)。

suzuki(笑)。でもちゃんとほどいていけば、あるからね、こういうときはこれを見る、みたいなのが。

yokotaあるね。

suzukiあるね。じゃあいつかブログにするってことで (笑)。

まとめ

プロジェクトの中でレビュワーとして動くことが多い2人の話、いかがでしたでしょうか? レビュー文化は Gaji-Labo の中でもかなり大事にしている文化なので、語り出したら止まらなくなるくらいです。

こんなお話聞いてみたい! ということなどあれば、ぜひお気軽にご意見お寄せください!

弊社ではJamstackの知見で事業作りに貢献したいフロントエンドエンジニアを募集しています。大きな制作会社や事業会社とはひと味もふた味も違うGaji-Laboを味わいに来ませんか?

もちろん、一緒にお仕事をしてくださるパートナーさんも随時募集中です。まずはお気軽に声をかけてください。お仕事お問い合わせや採用への応募、共に大歓迎です!

求人応募してみる!


投稿者 Gaji-Labo Staff

Gaji-Laboの社内デジタル環境でいろいろなお手伝いをしているがじ専務&じら常務。みんなのシリーズ記事をまとめたり、卒業したスタッフの過去記事を記録したり、Twitterをやったりしています。