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

この記事はクラスター 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委員会も、社内の課題を得意分野である開発フロー周りの知識で改善を進めていけました。社内で背中を預けながら、自分の得意領域で改善をどんどん進められるというのは非常にありがたい環境です。

おわりに

今回は自分の半年の様子を振り返りつつ、クラスターでのサーバーサイドエンジニアの仕事の様子や、社内から感じる雰囲気を書いてみました。機能開発を進めつつ、自分の得意領域ではどんどん改善し、周りも優秀な人ばかりで改善がどんどん進んでいるという環境で働けるのは楽しいですね。

こんな感じで楽しく仕事しているので、もしクラスター株式会社で働くことに興味があればぜひお声がけください！

recruit.cluster.mu

明日は、MIRINPRさんの、メタバース空間で「におわせ写真は撮れるのか」を検証しました②です。お楽しみに。

あるレポジトリを別のレポジトリのサブディレクトリへ履歴付きで移動する

あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。

あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。

この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しかしこちらは履歴的にはレポジトリルートで開発した後にgit mvでサブディレクトリに移したような履歴になってしまう。これだとgit logなどで変更を追いかけづらい。

そこで今回もgit filter-repoを使って移動する。作戦としては

• go_todo_appレポジトリ側で、go_todo_app/ディレクトリで開発しているような履歴に変更する
• go-playgroundレポジトリのremoteとしてgo_todo_appレポジトリを追加し、mergeコミットを作ってサブディレクトリ配下で開発していたような履歴を作る

ではやってみよう。まずはgit-filter-repoを入れておく。

brew install git-filter-repo

続いて、go_todo_appレポジトリ側で、go_todo_app/ディレクトリで開発しているような履歴に変更する。git filter-repoの--to-subdirectory-filterを使うと簡単にできる。

git clone git@github.com:shibayu36/go_todo_app.git
cd go_todo_app
git filter-repo --to-subdirectory-filter go_todo_app
cd ..

さらにgo-playgroundへgo_todo_appレポジトリの履歴をマージする。

git clone git@github.com:shibayu36/go-playground.git
cd go-playground
git remote add go_todo_app ../go_todo_app # localのディレクトリをremoteとして追加
git fetch go_todo_app main
# --allow-unrelated-historiesを使うことで別の履歴をマージできる
# --no-ffを使ってマージコミットを確実に作る
git merge --allow-unrelated-histories --no-ff go_todo_app/main
git push origin main

これで完了。go-playgroundレポジトリの履歴は こちらのようになり、さらにhttps://github.com/shibayu36/go-playground/commits/main/go_todo_appを見るとgo_todo_app/サブディレクトリ配下で初めから開発していたような履歴になっている。

Googleスプレッドシートで複数シートの内容を1つのシートに統合する

たとえばユーザー向け開発とリファクタリングなどの内部改善を、スプレッドシートの別シートで管理していたとする。これらを別シートに分けている理由は管理したい情報がそれぞれで違うためだ。

一方、それら進行状態については全部一覧で見たいことがあった。そうすることで、全てのタスクを含めて状況を把握しやすいためだ。

これを対応するためにGoogleスプレッドシートでいろいろ試してみたのでメモ。

シートの例

https://docs.google.com/spreadsheets/d/1IJ4qORImjfzVDodH0Z4vINRmXcqYjg9095uRVlTfSRI/edit#gid=0 にサンプルを作ってみた。シート1には機能開発一覧としてID、ステータス、タイトルという列を使って管理している。シート2にはリファクタリング一覧としてID、ステータス、名前、担当者が入っている。

QUERYと配列結合を使って統合する

QUERYと配列を使うことで、この二つのシートを結合した別シートを作れる。たとえばこの二つからIDとステータスとタスク名を取り出したいなら、見出しは手作業で書いた上で、その下に次のような式を書けば良い。

= {QUERY('シート1'!A:C, "SELECT A, C, B WHERE A != '' OFFSET 1", 0); QUERY('シート2'!A:E, "SELECT A, C, B WHERE A != '' OFFSET 1", 0) }

= { }の部分が配列の結合部分だ。;を使うことで同じ列数を持つデータを縦方向に結合ができる。

QUERY式を使うことで、別シートから柔軟に列を指定して取り出すことができる。見出し部分を除去するためにOFFSET 1と3引数目に0を指定するという工夫をしている。

あとは結合したシートでフィルタ表示を使えば、絞り込みやソートを簡単に行える。便利。

この辺りの知識があれば、さらに別のスプレッドシートからIMPORTRANGEでデータを取ってきた上でQUERYでフィルタかけて結合なども簡単に行えるようになる。

参考資料

• Google スプレッドシートで配列を使用する - Google ドキュメント エディタ ヘルプ
• QUERY - Google ドキュメント エディタ ヘルプ
• Googleスプレッドシートのクエリの統合 #GoogleSpreadSheet - Qiita
• GoogleスプレッドシートのQuery関数で結果が空になる謎仕様と回避策 #GoogleSpreadSheet - Qiita