はじめに

開発者体験:DXをめちゃくちゃ改善した話 Advent Calendar 2021の21日目の記事です。

この記事では、PRレビューを利用して自分の学びをチームの学びに繋げた取り組みについて紹介します。

※会社ブログで書いた内容をQiita向けにリライトしました。

他にアドベントカレンダー向けに書いた記事

背景

自分が働いている会社では、DXCriteriaを利用した開発組織の状態の可視化にトライしており、自分のチームでも確認する機会がありました。

確認項目の中には、継続的な学習機会を設けているか？という質問もあり、個人としてはPRレビューなどで学習機会がある実感はあったのですが、チームとして学習機会を作れているか？と問われると、たまに気になる書籍があれば輪読会を開くくらいで、継続的な機会作りはできてないように感じました。そのため、チームでもっと学習機会を作っていきたいなと思いました。

学習機会の仕様検討

最初は週1などで時間をとって、勉強会を開催することを考えましたが、これまでの経験から下記のような課題が出てくるだろうなと感じていました。

トピック持ち寄りの場合、ローテーションなどにしないと発表者が偏る。
発表者の準備負荷が高い。
業務が忙しくなるとまとまった時間を確保するのが難しくなる。

DXCriteria上にも記載があるように、継続的に機会があることが重要です。その点、上記のような方法だと途中で疲弊して開催が滞ってしまいそうです。そのため、今回の取り組みではもっと発表者の準備コストを下げてラフに開催できる学習機会を作りたいなと思いました。

その具体を考える中で、前述のように自分はPRレビューが学びにつながっていたり、たまに他のメンバーが朝会でPRレビューで得られた知見などをシェアしていたのが良いなと思っていたので、それをもっと仕組み化して推進していけると良いのではと考えました。
継続的な機会作りという観点でも、PRレビューをしてれば学習につながるコンテンツは作っていけるので準備負荷を抑えられて良さそうです。

実装

上記を実現するためのフローは下記のような感じです。

指定のPRレビューのコメントをbotがslackの指定チャンネルに投稿。
slackにシェアされた内容を朝会で確認。

上記を実現するため、簡単なGitHub Actionsを作りました。

作ったGitHub Actionsは、下記のように/shareのような情報を追加すると、botがそのコメントをSlackに投稿してくれるというものです。

Slackにはこんな感じで投稿されます。

それでは具体的にどういう実装をしたのかを説明していきます。

GitHubのコメントをフックする

GitHubのコメントをフックするために、GitHub Actionで下記のようなイベントをフックしました。
PRReviewのコメントは、PR自体に残したコメントなのか、PRに含まれるコードに対して残したコメントなのかによってフックする対象が異なるので注意が必要です。

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

[https://docs.github.com/ja/actions/learn-github-actions/events-that-trigger-workflows:embed]

botにSlack投稿させる

投稿はchat.postMessageを利用します。

PRレビューには、ドキュメントや他のコメントへのリンクを貼られることが多々あるのでURL展開もできるようにする必要があります。PublicなURLの場合はOptionalな引数であるunfurl_linksをtrueにしてメッセージを投稿してあげれば展開できます。しかし、GitHubなど外部向けに閲覧制限のあるURLの場合は、明示的に展開してやる必要があります。

URL展開させる際にはchat.unfurlで追加設定する必要があります。これはSlackのpostMessageのeventをsubscribeして、展開する必要のあるURLであれば展開するというようなものです。

今回の要件に関しては、postMessageのeventをsubscribeしなくても、GitHub Actions経由で展開したいURLが含まれているメッセージの投稿が行われるタイミングは分かっているので、chat.postMessageする際にBlock Kitを利用して、URL展開に含めたい内容を自前で展開する方針にしました。

Block Kitを利用する際は、Block Kit Builderを使うと簡単にプロトタイプでき、そのままコードに組み込むことができるJSONも作れるので便利です。

自前のGitHub Actionsとしてまとめる

最終的に書いたコードがプロジェクトの中のworkflow内にまとめるには大きくなってしまったので、自前のGitHub Actionsとしてまとめました。

GitHub Actionsを作る際に、Runner machine上で直接実行できるJavaScriptか、Docker Containerを選択します。
今回はGitHubコメントをフックするという都合上、イベントが呼ばれる数が多くなることが予想されます。そのためGitHub Actionsの実行時間をおさえるためにJavaScriptで作りました。

コードの置き場所

導入してみて

前述のように、これまでもPRで学びのあった内容は朝会などでシェアされることはあったのですが、今回の仕組み化を行ったことでその総量が増え、チームの学習機会を増やすことができました。

今後は朝会での会話だけでなく、シェアされた内容で盛り上がったものは深掘るための勉強会も別途設定できるといいのではと思っています。

最後に

DXCriteriaに記載があるように、継続的な学習機会を意識して作っていくことは、チーム/システムの健全な成長を促すことにもつながります。

今後もチームで学習してチームで強くなっていける方法を考えていきたいですね。