入社半年から見るクラスターでのエンジニアの仕事の様子

この記事はクラスター Advent Calendar 2023 シリーズ2の20日目の記事です。昨日はMSA_iさんのClusterの会場アップロードを楽にしたいでした。

入社エントリで書いたとおり、7月にクラスター株式会社に入社し、その後ソフトウェアエンジニアとしてサーバーサイドをメイン領域とし半年ほど仕事をしてきました。そこで今回は自分の半年の様子を振り返りつつ、クラスターでのサーバーサイドエンジニアの仕事の様子をお届けできたらと思います。

半年でやったこと

オンボーディング

最初は何はともあれオンボーディングです。入社直後は人事部から会社の規則の説明を受ける、社長の加藤さんとランチを食べながら会社のミッション・ビジョンの話を聞くというところからスタートします。

その後はエンジニア側のオンボーディングフローに入ります。エンジニア用のオンボーディングドキュメントが存在しており、そのドキュメントを見ながら、重要な資料をいくつも読んだり、開発環境を整えたりします。ドキュメントが大量にあったため、結構すぐに社内のエンジニアの開発の様子がイメージできた記憶があります。

またチーム側から用意された小さめなタスクに取り組みながらチームでの仕事の仕方を学んでいきます。必ずチームメンバーの誰か一人がメンターとしてついてくれているため、分からないことを気軽に質問できる環境にもなっていました。

中途で入ると、普通に仕事できるでしょうということでオンボーディングフローなしにいきなりタスクをやるということもあり得ると思うのですが、クラスターではちゃんと小さなタスクから進められたのは取り組みやすく良かったです。また読むべき資料がかなりまとまっていること、気軽に聞けるメンターがいることで、かなり素早く仕事の仕方を身につけられたと感じます。

epicという単位での機能開発

仕事に慣れてきたタイミングでチームでの機能開発に入っていきました。クラスターではepicという単位で機能開発を進めます。epicでは、その機能開発に必要なPM/デザイナー/エンジニアがアサインされます。またエンジニアの一人がepic ownerという進行を管理する簡易的なプロジェクトマネジャーとなり、進行管理しながら実装を進めていきます。たとえば

サーバーサイドエンジニア（兼epic owner）
Unityエンジニア
スマホアプリエンジニア
自分のチームの領域を担当するPM
デザイナー

のように、その機能に必要なスキルセットを持つメンバーが集まって開発していくイメージです。

入社した当時、自分のチームは写真フィードのリリース直前のタイミングだったため、まずはリリースに必要な機能の開発から取り組み始めました。たとえば「フレンドの新着写真投稿を閲覧できる」みたいなものを1つのepicとして担当して開発しました。

その後はサーバーサイドエンジニアとして写真フィード機能の改善を行ないました。たとえば「写真フィードのおすすめタブ」機能のepicを担当した時は、自分がepic ownerとサーバーサイドのメイン実装を担当し、PM/デザイナー/iOSエンジニア/Androidエンジニアと協働しながらリリースしました。

サーバーサイド横断の改善

epicが終わったらすぐに別のepicと必ずなるわけではなく、少し合間が空くことがあります。そういう時は所属チームとは別にリファクタリングや基盤改善など、自分で好きにサーバーサイド横断の改善タスクを取ってやっていくことができます。サーバーサイド横断のタスクリストにある中から選んでも良いですし、自分で課題を見つけてやっていくこともできます。

僕の場合はCI改善が得意かつ社内で課題に感じていたので、少し時間が空いているタイミングを見計らってクラスター内で設計の議論に使われるdesign docを書き、粛々と改善していきました。その様子は Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog で紹介しています。

他にもサービス障害やヒヤリハットな事例からポストモーテムを書き、サーバーサイドで改善できる領域を担当しました。自分はRDBMSのクエリ改善などが結構得意だったので、障害の原因になったクエリを高速にして、同じ状況で問題が起こらないようにしていくなどですね。

このように、ずっとチームでepic単位での機能開発をしているだけでなく、自ら手を挙げてサーバーサイドの横断改善を行うこともありました。ちなみに合間を見計らってやるだけでなくチームのEMと調整して横断タスクを取ることもできるため、自分の課題感を言語化して手を挙げると結構いろいろとやらせてもらえるイメージです。

bug bash委員会の立ち上げ

クラスターのエンジニア組織には、横断での改善を加速する仕組みとして委員会結成ができます。何らかの課題意識がある人が集まって、そのメンバー内で分担して改善していく仕組みです。コード上の問題を改善することもあれば、開発フローの改善をすることもあります。この仕組みの中で自分はbug bash委員会の立ち上げを行いました。

クラスターにはbug bashという「自分が参加していないepicで開発している機能に触れ、バグが発生していないかを探す」目的のイベントが存在します。このイベントについて、もう少しbug bash自体の改善をした方が良いのではないかという声があがり、自分も開発フローの改善に興味があったため、委員会のオーナーに立候補してbug bash委員会を立ち上げました。

bug bashというイベントはPM/デザイナー/QAも大きく関わるため、エンジニアだけでなく、それらの職種も含めてメンバーを集めました。立ち上げ後はbug bashというイベントの目的を明文化したり、当日に使う議事録を扱いやすくしたりなどの改善を行なっています。

このように所属チームや、自分のメイン領域のサーバーサイドの横断改善とは別軸で、何らかの課題を解決するグループを作れるというのはクラスターのおもしろい仕組みかなと思います。

感想

半年でこれらのタスクに取り組む中で、クラスターの雰囲気として感じたことを述べようと思います。

手を挙げたら取り組ませてもらいやすい

まず1つ目は、クラスターでは手を挙げたら取り組ませてもらいやすいということです。自分が半年で担当した機能開発においてはチームのロードマップに合わせて取り組んだものだったのですが、サーバーサイドの横断改善や委員会による課題解決に関しては誰かから仕事として割り振られたものではありません。この2つについては自分の中で課題感があり、自分で手を挙げたらそのまま仕事として進めることができました。

手を挙げたら何でもやっていいということではなく、もちろん課題をちゃんと言語化する・課題について解決策を提案するといったことは必要となります。しかし提案することで裁量を持ってやらせてもらえるというのは非常に楽しいです。https://recruit.cluster.mu/ でカルチャーの1つとして「一番はじめに手を挙げる勇敢な人であろう」というものが紹介されているのですが、それが体現されているなと感じます。

得意領域での横断の改善がバシバシ行われている

また上記のような改善が機能開発の合間にこぢんまり行われているというわけではなく、非常に多くの改善がバシバシ行われています。細かなリファクタリングやドキュメンテーション改善はもちろんのこと、

サーバーのモニタリング改善
クライアントのCIの改善
epicという開発フロー自体の改善
エンジニアのオンボーディングフローの改善

などの大きめなものも委員会などの仕組みを用いてどんどん改善されています。

半年眺めていた様子だと、クラスターの中では職種を問わず自分の確固たる得意領域を持っている人が多いです。その得意領域を使って自分で手を挙げて改善をバシバシ進めていっているイメージですね。自分のCI改善やbug bash委員会も、社内の課題を得意分野である開発フロー周りの知識で改善を進めていけました。社内で背中を預けながら、自分の得意領域で改善をどんどん進められるというのは非常にありがたい環境です。