ANDPADを最高のRailsアプリにするために勉強会をやっていた話

こんにちは! ソフトウェアエンジニアの金子と申します。2020年9月にアンドパッドに入社してはじめてのテックブログです。 今回は、わたしが入社直後から開始し、先日一区切りついた社内勉強会についてご紹介致します。

「となりのチームの様子がわからない」「チーム横断の会話がしたい」などの課題がある方にとってなにかヒントになるかもしれないと思ってこのお話を書いてみることにしました!もし何かの参考になれば幸いです。

勉強会の概要

開催の背景

2020年9月当時、アンドパッドにはコードベースで改良の余地がたくさんある状態でした。しかしながらその状態に対して、「Railsアプリとして標準的でない実装などよくないコードを無くしても新規で追加される」という問題、「良い書き方、考え方が広まらない」という問題がありました。 加えて機能開発やエスカレ対応など、どのチームもやることは本当に山積みで、誰かが「このような改善PRがあるのでみんなみておいてね」とSlackなどに投稿しているているだけでは限界がある状態でした。

そこで「毎週金曜日、周知したいPRついて取り上げます」というような場を設けることにしました。

開催の思い・目的

よいRailsアプリであることは、「メンテナビリティが高い」「ジョイン後まもなくから成果を出しやすい」「質が高い機能開発を速く進めることができる」など生まれる効果がたくさんあります。それがひいてはビジネス的な価値にもつながります。

そこで勉強会の目的、単なる共有だけでなく以下のように定めました。

  • アンドパッドの開発部の技術力を底上げする
  • 当たり前のことを一人一人が当たり前にできるようにする
  • そこからビジネス価値も高める

名前は「きのこたけのこ会」

当時コード改善を主にやっているのがQCDというチームのメンバーだったことから、チームのリリースノートを定期的にチーム以外の方も一緒に読み合わせるという「QCDのリリースノートを読む会」として始まりました。*1

さすがに名前がちょっと味気ないのと、良い活動をしているのがQCDチーム問わないので名前を限定的にしたくないこと、成長していく感じの名前にしたいということから「きのこたけのこ会」と正式に名前が決まり定着していきました。

f:id:neko314:20210615134056p:plain
Slack絵文字もあります!

開催形式

形式としては以下のとおりです

  • 毎週金曜日 15:00 - 16:00
  • Google meet / Zoomで開催
    • 途中から録画するようにしました
  • 話の内容はPR / issue
  • 主催者の金子がファシリテータ
    • PRについてわいわいとやっているときに話を聞きたい方に話題を振るなどしていましたがとくにスタイルはありませんでした

その週のPRは、1週間分の全てのPRではなくて、特に話題にしたいものを取り上げる方式にしました。 GitHubで「共有したい」というラベルをつけるというのが目印です。 ラベルをつけるのはPRのAuthorでも、それ以外の方でもどなたでも自由です。うまくいっていたのでとくに「ラベルをつける」以外の決まりは設けずにやっていました。*2

運用で心がけたこと

準備を何も頑張らない

毎回、オープンな台本代わりにesaを用意していました。 テンプレートすら用意することなく、前回のpostを複製し、日付を今回の日付に更新するという程度の準備でした。 準備はその程度で「今週のPRたちです!」と当日画面共有しながら話していたり、みなさんからチャットがあったら読み上げたりしていました。 時々「”これはどういうことですか?”と司会が質問してくれるので聞いてくれてためになった」というような言葉をかけられたりしたので、もしかしたらそれは進行としてよかったかもしれません。

私が体調不良などで当日突然仕事を休んだ時も何度かあったのですが、その時は別の方が進めてくださったこともあります。それくらい本当にがんばってなかったです。だから続けるのは大変でなかったです。何かを頑張る必要があったら、きっと10回くらいでやめていたでしょうね...

何も強制しない

何もというのはこのような具合です。

  • 会の参加は自由
    • 内容上「今回はこの方にいてほしい!」ということがあればお誘いしていたような気はします
  • 途中参加・途中退出OK
  • マイクオフ・カメラオフOK
  • ラジオ参加OK

参加者の発言量について、一番最初の数回は、参加している方になるべく全員が発言できた方がいいのではないかと思ったこともありましたが、話せる・話したい・話してもいいと思える方にお話しいただく感じがおさまりがよかったです。 といはいえ主催者の私がキラーパスで「ところでこのお話お願いします!」と突然ふわっと投げても受け止めてお話くださる参加者が多くてそのあたりは楽しかったです。

通知の仕組み

担当プロジェクトが佳境だったり、障害対応だったり、休暇だったり、きのこたけのこ会の毎週金曜日 15:00 - 16:00に、参加したい人が参加できるとは限りません。あるいは、会に参加するほどではないけど面白そうなものは見ておきたいという場合もあるかもしれません。なので、会以外でもラベルがついたPR / issue がそもそも全体に知られるように、GitHub Actionsを利用してラベルが貼られたらSlackに専用のチャンネルに通知するという仕組みをつくりました。*3

name: Label-base actions

# PR・issueがopenになったとき時、あるいはラベルがつけれたとき、以下のjobsを実行する
on:
  pull_request:
    types: [opened, labeled] 
  issues:
    types: [opened, labeled]

jobs:
  to_slack: # '共有したい'ラベルがついていたらSlackで通知する
    name: Notificate via Slack when specific labels are attached
    runs-on: ubuntu-latest
    steps:
      - uses: 8398a7/action-slack@v3
        if: ${{ contains(github.event.pull_request.labels.*.name) || contains(github.event.pull_request.labels.*.name, '共有したい') }}
        with:
          status: custom
          fields: workflow,job,commit,repo,ref,author,took
          custom_payload: |
            {
              username: 'action-slack',
              attachments: [{
                color: '${{ job.status }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning',
                text: `${process.env.GITHUB_REPOSITORY} \n
                ${process.env.PULL_REQUEST_TITLE} \n
                ${process.env.PULL_REQUEST_URL}`
              }]
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          PULL_REQUEST_TITLE: ${{ github.event.pull_request.title }}
          PULL_REQUEST_URL: ${{ github.event.pull_request.html_url }}

こうするとこのように通知が飛んできます。

f:id:neko314:20210616104223p:plain
PRに「共有したい」ラベルが付いたことのSlack通知例

思い出のある・学びになった内容のご紹介

振り返ってみると、どうやら150以上のPRやissueをこれまで話題にしてきたようでした。 その中で「こんなPRなどを話題にしていましたよ」と読んでいる方に伝わるようなものをいくつかピックアップしてみます!

たくさんあったグローバル変数を廃止する対応

グローバル変数は私がアンドパッドの開発に加わって「あれ?グローバル変数ってこんなカジュアルにつかうものだっけ」と苦戦したものの1つです。それをなくしていこうという対応のPRがいくつかあり、きのこたけのこ会でもいくつか共有されました。

グローバル変数で定義されていた値は、RubyGemのconfigによる管理に今は改善されています。 github.com

アプリケーションのバージョンアップや設定の変更などの対応

各種変更の内容というより、その中でたびたび出てきたRails.application.eager_load!コマンド自体を知れたのがとても学びでした。 これを走らせるとクラスなど全部呼び込んで、エラーがないかを確認することができます。 configを変えてみたり、パッチを当ててみたり、バージョンを変えてみたりなど、Railsアプリ全体が壊れないかを確認したいときに活用できます。 これは今CIにも入っていて、RAILS_ENV=test bin/rails runner 'Rails.application.eager_load!'が実行されるようになっています。

Rails.application.eager_load!以外にCIに取り込まれて会で取り上げたものとしては、"schema.rbがmigrationファイルと乖離していないかチェックする"というものなどがあります。このように問題の検知の方法やそれを自動化することなどの学びが私としてはありました。

全部で150もあればもっともっとたくさん話したいことはあるんですが、あげるとキリがないのでこのあたりで我慢します。 めちゃくちゃ充実しているので過去の対応だけど今でも振り返る価値があるものは多くあります。気になる方はぜひカジュアル面談しましょう!

「きのこたけのこ会」の終わりと今後の思い

ここまで紹介してきたきのこたけのこ会ですが、29回目の開催で終了しました。 理由はいくつかありますが、PRベースで知見を共有するというアプローチが効果的な状況は一区切りついたように思われたからでした。

では、今ANDPADは「最高のRailsアプリになったか?」と問うと答えはNoです。自分が入社した当初に比べて改善は進みましたが、まだまだよくしていきたい点はたくさんあるし、新しく追加されたコードもいつの間にか古くなったりするので、ANDPADがある限り終わりはありません。

このことを踏まえ、前述した会の目的を再掲してみます。

  • アンドパッドの開発部の技術力を底上げする
  • 当たり前のことを一人一人が当たり前にできるようにする
  • そこからビジネス価値も高める

これを改めて読んでみると、勉強会問わず、日常の中でこれからも追求していきたい項目だなと感じています。これは開発部全体や他人に対して以上に、自分自身に対して求めていきたい話です。どんな形であれ一開発者として高まっていきたいと思う毎日です。

「きのこたけのこ会」は終わりを迎えたけれど、エンドユーザーにとっても開発者にとっても社内の人たちにとっても最高なサービスの開発のために、俺たちの戦いはこれからも続きます!

最後に

以上、「きのこたけのこ会」という社内勉強会のご紹介でした。最後まで読んでくださってありがとうございました。このように楽しく開発している話をもっとききたい!と思ったらいつでもご連絡ください。

engineer.andpad.co.jp

*1:今振り返ると、この名前だったら長くは続かなかったと思います。名前は大事。

*2:途中から生まれた工夫として、ラベルを貼ったときにPRコメントに「こんなところが良いと思いました」「このような観点で議論したです」など会でとりあげたい理由を記載しておくと、人の記憶に頼らなくて済むという知見がありました!

*3:https://github.com/marketplace/actions/action-slack を利用しています。とても便利だったのでラベルを貼ったというイベントをトリガーにしたいことがあればぜひ使ってみてください。