ラクスルでフルリモートインターンをした話

こんにちは、22新卒内定者の灰原です。この記事では、昨年6月末から約半年続けてきた、ラクスル事業本部でのインターンについて振り返ります。

実は私は北海道に住んでおり、今回のインターンはフルリモート勤務となりました。北の大地から画面越しに感じたラクスルの雰囲気と共に、インターンを振り返っていきます！

リリース内容のレビューツール

インターンが始まって始めに取り組んだ仕事は、リリース内容のレビューツールの作成です。開発の背景として、統制の観点から、各チームのPdM (Product Manager)はリリース内容(mainブランチにマージされたPR)を定期的にレビューする必要があります。しかし、該当するPRをGitHubで一つずつ開いて確認するのは大変です。このツールを使えば、対象レポジトリ・期間を指定すると、それに該当するmainブランチにマージされたPRが一覧表示されます。またそのPRのレビューが完了した際には、このツールから各PRに「レビュー済み」のラベルを付けることができます。このラベルがレビュー完了の証跡となります。

このツールはGoで開発しました。私はもとよりGoに慣れ親しんでいたこともあり、機能開発自体はスムーズに進みました。一方で要件やユーザビリティについては熟考しました。まずは、このツールのユーザーであるラクスル事業本部の開発者について知ることが必要でした。このツールの開発を通して、ラクスル事業本部の開発体制や組織構造について理解を深められたことは、新卒入社する自分にとって大きなアドバンテージになったと思います。

現在では、このツールは実際に各チームで運用されています。これは私が初めて仕事で制作したソフトウェアということになります。「自分の手を離れて自分の書いたコードが使われる」というソフトウェアエンジニアとしての喜びを感じる瞬間でした。

生産性可視化基盤

2つ目の仕事は、生産性可視化基盤の構築です。これは開発組織の生産性を計測・可視化するシステムです。このプロジェクトは各チームがデータに基づいた意思決定ができることを目指して開始されました。

AWS CDK・Permissions Boundaryの導入

この基盤はAWS上に構築しており、Lambda・S3・Glueなどのサービスが中心になっています。また弊社ではAWSのリソースをTerraformで構築しており、このTerraformをインフラチームが管理しています。そのためAWSのリソースを変更する場合には、TerraformのレポジトリにPRを送るか、インフラチームに作業を依頼する必要があります。この運用はサーバレスアーキテクチャとの相性が悪く、開発者・インフラチーム双方の負担が大きくなってしまっていました。

この問題はAWS CDKというIaCの仕組みと、Permissions BoundaryというIAMを制限する仕組みを組み合わせることで解決しました。これについては先日のブログ「Permissions Boundaryでガードレールを設けてAWS CDKを安全に使う」でも紹介しています。

Four Keysの計測

「生産性」の指標には、Four Keysを採用しました。Four Keysとは「デプロイの頻度」「変更のリードタイム「変更障害率」「サービス復元時間」の4つの指標のことで、書籍「LeanとDevOpsの科学」やGoogle Cloudのブログ「エリート DevOps チームであることを Four Keys プロジェクトで確認する」で紹介されています。これらの指標の値は、ソースコードや障害チケットを管理しているGitHubや、プロジェクト管理ツールであるClickUpからデータを取得し、それを元に算出することにしました。

計測基盤は以下のようなアーキテクチャでAWS上に構築しました。これは大まかに以下のような流れで動作します。

CloudWatch Scheduled Eventで各種Lambdaを発火
各種LambdaはそれぞれGitHub・ClickUpのAPIを叩いてデータを取得、それをS3バケットに置く
Athenaクエリで、Glueデータカタログを通してS3バケットに置かれたデータを解析

Lambdaの実装にはGoを使いました。GoからGitHub APIを叩く際にはgoogle/go-github を使うのが定番です。一方でClickUpにはこのようなデファクトなクライアントライブラリがありませんでした。そこで、ClickUpのクライアントライブラリであるgo-clickupを先輩エンジニア達が新たに開発しました！また、このgo-clickupはOSSとして公開しており、コントリビューションもお待ちしております！

ベロシティ計測

Four Keysに加えて、各スクラムチームのスプリント毎のベロシティも計測することにしました。開発チームの生産性を測る方法として、1スプリント毎のベロシティのモニタリングは一般的に行われていることかと思います。ラクスル事業本部では、スプリントごとに計画していた実績値(ベロシティ)と、目標値(コミットメント)との誤差が小さいことを是としています。そこで、ラクスル事業本部での生産性を計測するためには、実績値に加えて目標値も必要です。

ClickUpはスプリント毎にタスクボードを作成する機能があります。つまり、このボードがクローズされた時に、ステータスがCOMPLETEになっているチケットのポイントを合計した値が実績値になります。一方で、ClickUpにはそもそも目標値を入力することができないようですので、ClickUpのAPIから目標値を取得することはできません。

そこで、スプリント毎に、各チームのメンバーからの目標値を教えてもらう必要があります。これには、各チームのメンバーにはタスクボードのDescriptionにマジックコメントを書いてもらい、その内容をClickUpから送られるWebhook経由で取得するという方法を採用しました。この方法であれば、開発者はスプリント期間内にClickUpに情報を書くだけで済みます。

アーキテクチャとしては、まずClickUpからのWebhookをAPI Gatewayで待ち受け、そのHTTPリクエストをLambdaでValidateした後、Step Functionsを起動させます。このStep Functionsの中で各種Lambdaを実行し、S3にデータを貯めていきます。このベロシティ計測機能の開発は、ClickUpのWebhookとの連帯や、Step Functionsの扱いなどで何度か試行錯誤する場面がありました。今思えば、この開発に着手する前にCDKを導入していたことで、かなりの工数を削減できたのではないかと思います。実際、CDK導入後ではインフラチームへの問い合わせはほとんどなくなりました。

可視化

さて、ここまででFour Keys・ベロシティを算出するためのrawデータを蓄積することはできました。これらのデータに対してクエリを実行して可視化するために、Redashを使いました。Redashから発行するAthenaクエリや可視化の設定は、先輩エンジニアであるIchijimaさんにやっていただきました。

そして運用へ

この生産性可視化基盤もまた、各チームの振り返り(retrospective)などで使われています。今後、運用時間が長くなるほどデータも多くなり、さらなる分析ができることが期待されます。

また、この基盤は自分がゼロから組んだシステムの中で一番大きなものでした。この先も使われることを想定した設計や、CDKを初めとした技術調査など、今後のエンジニア人生にとってプラスになるであろう経験でした。

内定者インターンを振り返って

このインターンを通して、4月からの仕事のイメージがグッと深まりました。例えば各チームのSlack channelを見たり、朝会に参加したりする中で、そのチームの雰囲気や個人個人のひととなりを感じることができました。特に開発に関わる相談や、障害対応時のやりとりなどを見ることで、ある種のケーススタディのように学びを得ることができました。

冒頭でも述べましたが、このインターンは北海道からのフルリモート勤務でした。リモート勤務ではコミュニケーションの不足などが問題視されがちです。しかし、私のtimes (Slack上の、個人的なつぶやき用のchannel)に社員の皆さんが反応してくれたり、毎週の社内勉強会で他のチーム・事業部の方と会話ができたりと、リモート故の心細さのようなものは感じずに働くことができました。

私はラクスルに対して少し堅い印象を持っていたのですが、皆さんメリハリをつけて働いていて、Slack上でも和気あいあいと話す場面もあります。下の画像は某チームのテックリードがPdMのために作った似顔絵チョコです。