GMOペパボ EC Advent Calenderの2日目は、yammerから、私の所属するチームについての話題を紹介します。
1日目の記事は、@kenchanの『「炭鉱のカナリア」になる』でした。自分が今年、消防車を呼べたとき、呼べなかった時はいつだっただろうか？と思い出しながら読みました。3日目の記事は@tatsumi000の、「開発環境.nvim 2023」です。Vimmerでありながら就業時間中はVSCodeのVimプラグインに甘んじている身として「1週間くらいNeoVimだけで生活してみようかな」と心が揺さぶられるトピックでした。1
私が今いるチームは2023年の年初に発足し、はじまってからおよそ1年が経ちました。1年の中ではさまざまなことがありましたが、チームの中で違和感を感じるたびに、問題を発見し、解決策を見出し、一つずつ変化が加わっていったと感じています。今回は、そういった変化の中で一つ、コードレビューに関する変化を紹介します。
半年ほど前、Pull Requestのコードレビューが溜まりがちだったあるとき、チームに「良い環境で働く大切さ、良い環境を作り出すためには」という記事が持ち込まれました。 課題感と、その参照としてこの記事のURLがチームのSlackチャンネルに投稿されたことは、コードレビューに各々が課題間を抱えていることが言語化され、共通認識となるきっかけになりました。課題にチームが気づき、変化した瞬間でした。
その投稿の後、コードレビューの速度を上げるために、別のドキュメントなども参考に、いくつかの点が整理されました。
- コードレビューは素早く行われる必要があること。少なくとも1営業日以内に返答すること。
- コードレビューが難しい時には、コメントを返す以外のアクションをとると良いこと。たとえば「コードレビューが難しい状態であることを伝える」「Pull Requestの内容や周辺領域の知識について口頭で説明を受ける」「ペアプログラミングをする」など。
こういった整理と認識合わせが行われてから、コードレビューレビューの速度が改善し、滞留することが少なくなったと感じています2。レビュワーが早く返答するだけでなく、レビューのしやすいPull Requestや開発手順にするといった変化を含めて、半年経った今も、上記に示された速度の基準を満たし、ボトルネックになることが少ない状態を維持できていると考えています。
この変化の重要な点は、チームのSlackチャンネルに、課題に対する呟きがあったことです。チームが問題に気づいて改善するためには、まず、誰かが違和感を感じ、それを共有することが必要です。コードレビューの他にも、たとえば実際にあった以下のような変化も、誰かが課題を共有したからこそ起こったものです。
- スプリントゴールの定め方を見直す
- 見積もり会を定期開催にする
- ふりかえりの進め方を変える
チームが発足して時間が経ち、成熟してきましたが、これからも、違和感に気づき、仕事の進め方に変化をもたらせるチームでありたい/あってほしいと思っています。今日までのチームはメンバー全員がつくってきたもの3で、明日からのチームもメンバー全員が作り出すものです。
チームのみんな、そして一緒に働いてきたパートナーの皆さん、2023年もお世話になりました。ありがとうございました。来年もどうぞよろしくお願いします。
古い記事