BASEのCartDevチームでバックエンドエンジニアをしている遠藤(@Fendo181) です。
自分が所属しているCartDevチームは主にBASEにおける決済開発を担当しております。
購入者様が商品を購入する際の決済だったり、オーナー様が利用するカート機能周りの開発、保守運用を行ってます。
今回、この記事では自分が所属するCartDevチームの取り組みを紹介する「月刊CartDev」というドキュメントを作った経緯や、運用方法について紹介します。
また、実際に社内で共有してみてどのような反応があったかについても書きます。
月刊CartDev が作られた背景について
月刊CartDev が作られた背景には2つ理由があります。
- (1) 遠藤(@Fendo181) がそもそも入社したばかりで、CartDevでの働き方を理解したい。
- (2) CartDevチームで取り組んでいる内容をチーム内で閉じるのではなく他部署に知見を積極的に共有して、他チームでも改善できる体制に貢献したい。
(1)はそのままの理由です。 (2)の理由についてはお話する前にまずCartDevチームの成り立ちについて説明します。
CartDevチームが作られた背景について
CartDevチームはBASEの中でも 目的別組織 として作られたチームであり昨年の2022年の7月に結成しました。
BASEにおける「目的別組織」を少しだけ説明すると、特定の領域や機能に対してチーム全体が継続的に運用を行い、責任を持つ組織体制の1つになります。
CartDevチームが結成される前はカート機能の開発を行う専任チームはなく有志的に集まったメンバーが担当したり、お問い合わせ対応を行っていました。しかし、このままではスケールの面でも好ましくないということでカート機能の開発と保守運用に責任を持つ為に作られました。
CartDevチームの成り立ちについて以前テックブログで公開された以下の記事も参考になるので一部記述を抜粋します。
BASEの課題としてEOLを迎えたフレームワークからの移行を進めています。その中でもカート機能はまず初めに移行が完了した機能になります。ですが、移行して終わりではありません。サービスは成長していくので併せて機能を改修していく必要がありますが、新しいアーキテクチャを理解せずに間違った方向で改修が進むと複雑な負債を生み出してしまう可能性もあります。またアラート対応やパッケージ更新などの日々の運用もあり下記のような課題がありました。
- 新しいアーキテクチャをどう適切に開発していくのか？
- アラート対応やパッケージ更新などの運用はどうするか？
上記の課題をカート機能をリニューアルしたエンジニアが有志的に対応していましたが、スケール面において好ましくない状況だったため、カートチームとし>て組成して、開発・運用・グロースを含めて責任を持つのが望ましい形なのではないかと考えた結果、リニューアルしたエンジニアを集めてカートチームが誕生しました。
上記の背景もありCartDevチームは他のチームと違い後述するSentryの監視体制だったり、Dependabotを使ったライブラリのアップデートに関して意欲的に取り組んでおります。
そういった取り組みは仕組みだけではなく、チームメンバーによる独自の文化が根付いていると配属してから感じました。
同時に、CartDevチームで出来ている事が、事情によって他チームでは出来ていない課題も気づきました。
こういった状況がある中でCartDevチームで取り組んでいる技術トピックを共有し、他チームにもCartDevチームの良い部分を積極的に取りくめる様に情報共有したいと思い「月刊CartDev」を作成しました。
CartDevで紹介した内容について
次に「月刊CartDev」でどんな内容を共有しているか説明します。
前述したように Cart DevチームはBASEの決済領域に関わる問題に対して責任を持ち、運用しております。
具体にこれは 担当大臣（運用業務) という名目で現在4つあります。
- Dependabot担当大臣
- Dependabot を用いた追従活動。
- Dependabotによって届くライブラリアップデートの通知を確認し、定期実行や誰かが手動実行した際にも発生するPullRequestを確認し対応する。
- Sentry担当大臣
- Sentryの治安維持活動。
- SlackでSentryのアラートが流れてくるチャンネルを見たり、メール通知を確認して対応する。
- メンテナンス担当大臣
- 外部決済会社のメンテナンスエラーからの防衛活動
- メンテナンスの連絡を毎回確認し、必要と判断した場合にメンテナンスの設定および 、NewRelicアラート の ON / OFF を行う。
- cs_q担当大臣
この4つの担当大臣を1ヶ月ごとにローテーションしながら各メンバーで対応するように現在運用しています。
また上記の「担当大臣」以外にもCartDevチームのメンバーが実際にプロジェクトで行った改善や、リリースした機能のPullRequestも取り上げて共有しました。
数値を計測して共有する
上記の担当大臣（運用業務)で紹介した4つの項目については対応時の計測値を共有しています。
Dependabot担当大臣で管理するPull RequestはGitHubで管理しているのでGitHubの検索で期間やラベルでフィルタリングして、Dependabotで作られたPull Requestがどれだけマージされているか?を計測できます。
以下は2023年1月辺りのDependabotで作られたPull Requestがマージされた数が取得できます。
is:pr is:closed label:dependencies merged:2023-01-01..2023-01-31
Sentry担当大臣の場合も簡単に計測ができます。
Issuesページから日付を指定できるので、その機能を使って絞り込みを行い計測をしています。
Sentryはただ対応した数を載せるよりも いかに早くアラートを検知してすぐに対応している様子 を伝えるのが大事だと思ったので、数だけではなく実際のSlackでのやりとりのキャプチャーも載せるようにしました。
メンテナンス担当大臣は、社内のドキュメントツールで活用しているKibelaにまとめられるので対応数だったり、具体にどんなメンテナンスを行ったのか?を紹介しました。
cs_q担当大臣はAsanaの高度な検索を使って計測が可能でした。
これは自分が配属する前からユーザーから届いたお問い合わせに関しては調査が必要なものはCSチームのメンバーがAsanaで最初に管理しています。
従ってGitHub同様にAsanaでもタグや時間を指定してフィルタリングができます。
この機能を使ってメンバーがアサインされている且つ、時間を指定して1ヶ月辺りにCartDevチームが対応したお問い合わせ対応の数も計測できました。
以上より「月刊CartDev」では担当大臣（運用業務)の対応した実績数と、実績の詳細が確認できるURLを記述して社内に共有しました。
月刊CartDevを共有してからのフィードバックについて
月刊CartDevはまだ1月号と2月号しか出せてないのですが、「読者アンケート」を題して社内で読んだ人からフィードバックを頂いています。 フィードバックを一部取り上げると以下のコメントを頂きました。
- Cartチームの活動内容がよくわかった
- Sentry担当大臣は結構みんながはまるエラーの宝庫なのでどんどん共有していきたいですね
- BASEの基盤なので、色々大変だとは思いますが頑張ってください!!
今後の月刊CartDevの改善について
現在作っている「月刊CartDev」のメインコンテンツが「担当大臣」の実績で、ほとんど数値を共有して終わっています。
読者アンケートのフィードバックで頂いた意見を読むと「担当大臣」の実績や数値を載せても他チームに需要がないケースもある事がわかりました。
アンケートを読むと、どのチームもSentryやNewRelicなどの監視ツールの運用や知見を読みたい事がわかったので今後は「担当大臣」の実績や数値よりも「CartDevでのSentryを使った監視体制について」など、テーマを絞って社内で共有していければと考えています。
まとめ
同じ会社でも規模が大きくなったりメンバーが増えると他チームが何をしているのかが、わかりづらい状況は常に発生してくると考えています。
他チームで改善が出来ている事を読んだり、聞いたりするだけでもモチベーションが上がったり、他チームの取り組みを知る事で相談しやすくなると思うので今後も「月刊CartDev」を通じて社内で積極的に情報共有される環境を目指して運営して行こうと思います。
