こんにちは、プロダクトマネージャー（PM）のいかりです。今回の記事では、プロダクトに対しての社内からの不具合報告のフローを改善した話について紹介します。「社内からプロダクト改善のために色々な声をもらっているけどどう対応しよう……」と困っているような方は何かの参考になるかもしれないので、ぜひ読んでみてください！プロダクトを安心して使ってもらうための「不具合対応」社内からの不具合報告の既存の課題【改善】Slackのワークフローを使って不具合報告フォームを制作結果、良くなったところ社内の多くの人に不具合報告フローの存在を周知できた数ヶ月で50件近くのバグ報告があり、1〜2割はその週に解決連絡の往復回数が減った後からのキャッチアップがしやすくなったまとめプロダクトを安心して使ってもらうための「不具合対応」プロダクトの成長のためには新しい機能の提供や操作性を良くしたり、といった継続的な改善が必要ですが、一方で、快適さを脅かす「不具合」への細やかな対応も必要となります。特に、ユーザーが長い時間を過ごすプラットフォームである「cluster」では、特に重要な要素です。clusterはPC・スマホ・VR機器など複数のプラットフォームに関わっていることや、3D空間、アバターに音声周り、ストア機能、ユーザー自身が3D空間を制作できるUGCツールなど多岐に渡る機能を提供する複雑なプロダクトです。その影響なのか、clusterには多くの不具合が確認されていますが、対応できるものはなるべくスピーディーに対応できるよう日々改善を進めています。clusterには複数人のPMが関わっていますが、私はそうした不具合情報をキャッチアップしたり、プロダクトに関してのコミュニケーションが良くなるように活動しています。最近では、前任者の育休に伴い、clusterの最新情報を伝える公式バーチャルイベント「Hello Cluster」に毎週出演して、ユーザーの皆さんとコミュニケーションを取っています。ユーザーの方々からの不具合報告もこまめに確認しながら対応していますが、今回の記事では直近で取り組んだ「社内からの不具合報告から対応までのフロー」の改善について紹介します。社内からの不具合報告の既存の課題クラスター社では、エンジニアがチームのミーティングをcluster内で行ったり、全社員が集まる「WinSessio

こんにちは、クラスター株式会社でソフトウェアエンジニアをしているMito Memelです。clusterでは、3D空間内でアバターモーションや音声を同期するためのリアルタイム通信サーバーをAmazon EC2上で動作させています。昨年から今年にかけて、このリアルタイム通信サーバーのリソース割り当て方法を改善し、結果として稼働しているEC2インスタンス台数を半分程度に削減することに成功しました。本記事では、clusterのリアルタイム通信サーバーが抱えていたリソース割り当て効率の課題とその改善手法をご紹介します。背景改善手法まとめ背景アバターモーションや音声の同期のようなリアルタイム性の高い双方向通信を行う、いわゆるリアルタイム通信サーバーをスケールアウトする方法には、よくあるやり方としては2種類あります。1つ目は、Webサーバなどと同じようにアプリケーションサーバをステートレスになるように設計し、バックエンドのPubSubサーバーやKey-Valueストアを用いてサーバー間の状態同期を行う方式です。この方式のメリットはスケールアウトの仕組みがシンプルなことで、Elastic Load BalancingやAWS Auto ScalingといったWebでよく使われているマネージドサービスも比較的利用しやすいです。一方デメリットとしては、複数のサーバーにまたがって状態を同期する必要があるため、部分的にサーバーがダウンした場合にも適切に復旧できるようにしたり、特定の処理を正確に1回だけ行うために実行するサーバーを選出したりなど、状態同期の実装が複雑になりがちです。例えば手で掴めるオブジェクトの所有権を扱う場合などは問題になりやすいですね。2つ目は、状態同期を行う1つの空間(いわゆるゲームセッション)ごとに新たにアプリケーションサーバーを起動して固定で割り当てる方式です。この方式のメリットは、アプリケーションサーバーのインメモリに状態を持つことができ、分散システム特有の難しさを持ち込まずに状態同期を実装できることです。対戦型FPSなどセッション型のゲームではこちらの方式がよく採用されています。clusterでもこちらの方式を採用しています。しかし、clusterは対戦型FPSなどのセッション型ゲームとは違う点があります。それは、1つの空間にどのくらいの人数が同時接続するかが

はじめにRenovateとは？依存関係をPackageに切り出すGitHub ActionsでPackage.resolvedを更新するおわりにはじめにこんにちは。クラスター株式会社でソフトウェアエンジニアをしているTAATです。今回はクラスターで導入しているRenovateというパッケージの自動更新ツールをSwift Package Managerで利用する上での問題点やその解決策について紹介します。Renovateとは？Renovateとは、パッケージの自動更新を行うツールで、利用するパッケージに新しいバージョンがリリースされると、自動でアップデートのPull Requestを作成してくれて、リリースノートや変更内容も記載してくれます。しかし、Swift Package Managerには対応しているものの、以下の問題点がありました。Package.swift内のパッケージは更新するが、Xcodeプロジェクトから入れたパッケージは更新してくれないPackage.swiftは更新するが、Package.resolvedは更新してくれないissueはあるものの、まだ対応中のようです自分で追いコミットをする必要があり、設定によっては別のレビュアーに承認してもらう必要がある依存関係をPackageに切り出す問題点1を解決するために、Xcodeプロジェクトからパッケージを入れるのではなく、依存するパッケージを管理するためのパッケージを作成してプロジェクトに取り込みます。まずはXcodeメニューのFile > New > Packageから新しいパッケージを追加して（今回はClusterPackage）、配置したいディレクトリでAdd Files to “ターゲット名”から追加したパッケージを選択して取り込みます。新しいパッケージをアプリターゲットのFrameworks, Libraries, and Embedded Contentに追加することで、新しいパッケージで指定したパッケージを利用することができます。テストでも利用する場合は、テストターゲットにも追加する必要があります。次に新しいパッケージのPackage.swiftを編集していきますが、targetsのdependenciesを指定する際のタイポを防ぐために、以下のようにextensionを定義すると良さそうで

こんにちは。tech blog編集チームのFUKUDAです。今年の4月頃からクラスター社のtech blogの編集を担当することになりました（普段はclusterで活動するクリエイター向けのメディアを運営しています。そちらも振り返り記事を書いているので、ぜひ！）。今年は月に2本、年間で24本の記事を公開するという目標を一応定めていたのですが、その目標はとりあえず達成できたので一安心です。さて、クラスター社のブログは去年まではcluster公式noteで運用されていましたが、今年からこのはてなブログの方に移管しました。この移管と私が関わることになるにあたって、tech blogの運用の仕方の試行をいくつかしました。今回の記事では、その辺りを振り返りつつ、来年の抱負を綴っていきたいと思います。今年の運用で意識したこと「cluster」の技術の全体像が見えるように記事のストックができるように記事のきっかけをつくりにいく記事ネタ出し会「tech blogネタ帳投稿フォーム」をslackのカスタムレスポンスで出す来年やりたいこと記事の執筆者のバリエーションを増やすtech blogの認知度を上げるための地道な活動もする終わりに今年の運用で意識したこと関わって最初に、編集担当であるFUKUDAがこのブログがどういう目的で運営されるものなのかを言語化しました。その上で、今年は下記の試行をしました。編集担当になって最初につくったドキュメント「cluster」の技術の全体像が見えるようにまずは、記事ごとにしっかりとカテゴリを振り分け、サイドバーに表示されるようにしました。「cluster」はスマートフォン、PC、スタンドアローンVR、PCVRとさまざまなデバイスからアクセスできるサービスです。また、ワールドやイベントを検索するにはWebサイトを使用することもあります。つまり、clusterは多岐に渡る技術に支えられたサービスです。この事実は、普段サービスを触っていると気づきにくく（自分が扱っているデバイスに注意がいってしまう）、それによって社外で興味を持っている方にclusterで活躍できる分野が幅広くあることに気づいてもらえないことは機会損失ではないかと考えていました。tech blogをnoteで運用していた際は、記事をカテゴリごとに検索することができませんでした。なので、はてな

こんにちは クラスター株式会社で Engineering Manager(EM) をしている kurain です。今日は、クラスターのエンジニアが参加する会議体について紹介します。会議体の作り方について長々続くので、先にまとめを書いておくとエンジニアが自律的に開発プロセスを改善できるように、会議体を3つ定義しましたそれぞれの会議体には権限と責務が明示されていますエンジニアは自ら発案して上記の会議体を開催できるので、業務改善が上手く回っていますという話です。背景会議体を定義するWorking Group委員会勉強会定義による効果もっと効率的で楽しいリモートワークのために背景なぜこのような会議体の定義が大切なのか背景から話を始めましょう。クラスター株式会社はこの3年間で社員数が約6倍になりました（上図は2023年6月時点の資料）。エンジニアの数も6倍……とはいきませんが準ずる増え方をしています。同時に月1回の出社のみが求められるフルリモートに近い働き方が行われています。人が増え、かつ、リモートワークが前提になると何が起こるのか? それは、会議体が増えます! 人が増えているのでコミュニケーションパスは増えますし、リモートワークには立ち話のような概念がないので、つい会議体を設定して人の時間を拘束しがちです。もちろん、そんな状況が放置される訳はなく、ある時期から「〇〇デイリーとか、XX定例とか全部やめましょう！」と社長からよく言われるようになりました。(画像はイメージです)こう言われる側としては「会議体が多いのは良くないが、全部やめていい訳ではない。すると会議体を残すならば何かしらの基準が必要だな。」ということになります。そこでシニアエンジニアの:kyokomi:と一緒に会議体の棚卸しを始め、会議体の基準を作ることにしました。気をつけていたのは以下のようなことです。エンジニアが所属しているチームのデイリーミーティングは全員必須のままにしたいチームを横断した会議体は人数を絞ることができそう 新しい改善や企画を始めるのは誰でもできるようにしたいだからといってミーティングが増えるのは嬉しくない会議体を定義する上記をふまえて、会議体の役割を整理したわけですが、まずは名前を3つに絞りました。Working Group(WG), 委員会, 勉強会 の3つです。いままでは、会議体ごとにバラ

クラスター株式会社でSoftware Engineerをしている thara です。私たちは今年、clusterのシステム分割という重要なプロジェクトを完了しました。この取り組みは、私たちのメタバースプラットフォームの進化と持続可能な成長にとって欠かせないものでした。背景解決策システム分離プロジェクトにおける課題課題を解消するための実施手法Gatewayによる隔離dual writeによる段階的移行/dual readによる差分検証状態スナップショットによる差分検証諦めの局所化分離プロジェクトの結果と反省今後の展望背景clusterがリリースされて6年が経過しました。prtimes.jp当初はバーチャルイベントプラットフォームとして展開されていましたが、2020年にはスマホアプリをリリースし、フレンド機能などのSNS機能の他、常設のCGコンテンツであるワールド機能に加え、Unityで作成したマルチプレイゲームを公開できるようにもなりました。prtimes.jp2022年には、cluster上で誰でもワールドを作成できる「ワールドクラフト」がリリースされます。prtimes.jpこのように、clusterはリリースして以降、バーチャル空間上の体験を提供するという軸はそのままに、その体験を形を変えて提供してきた経緯があります。これに伴い、大きく2点の課題が出てきました。まずは、システムの複雑性の増大です。clusterはroom1 内でリアルタイムに3D空間を共有できるinroom領域と、アカウント管理やroomへの入室するまでの体験などを担うoutroom領域に大きく分かれていますが、双方ともにプロダクトの状況に応じて機能が増減しています。2 これに伴い、内部はその状況に応じた形に変わっていくのですが、ある箇所の変更の影響が他の箇所に出てincidentに繋がったり、ある箇所の変更の影響が大きくて手が出せない、みたいなことが増えてきました。2つ目として、システム理解の認知負荷の増大が無視できなくなってきた、という点があります。クラスターは年間100人以上採用するなど、急激に組織規模が拡大しています。note.comこの人数は全社スコープですが、当然所属するソフトウェアエンジニアの人数も急速に拡大し、その勢いはいまだに衰えていません。また、2024年卒の新卒採用も開始し

メタバースプラットフォーム「cluster」のインフラチームの佐藤です。今回はclusterではログをどのように扱っているかをインフラ観点からご紹介します。ログは安定したサービス提供を行うために役立つ基本的な要素です。初期の素朴な構成で発生した問題点や、プロダクトの成長に合わせて、より活用しやすいように改善を行なった結果など成果の一部を公開したいと思います。CloudWatch Logsの限界ログのインフラ構成の改善構成の説明ログのファイルへの永続化までの部分S3から検索エンジンに送る部分ログの検索、可視化の改善まとめCloudWatch Logsの限界現状のログの構成について説明する前に過去のログの運用方法とその課題点などから説明します。以前は以下のように各コンポーネントからCloud WatchLogsにログを送り、何か問題が発生した場合の調査などはCloudWatch Logsに対して直接クエリを実行して調査を行っていました。インフラ構成としては以下の図の通りです。AWSの各種サービスの代表的な用途としてはECSはAPIサーバーやバッチ処理、EC2はroom server(注1)、Lambdaはファイルのアップロードをトリガーにした処理などを行なっています。注1: clusterでは3D空間内でのクライアント間の同期に内製のroom serverというサーバーを使っています。詳細はこちらの投稿を参照ください。 https://tech-blog.cluster.mu/entry/2022/04/13/143058シンプルで信頼性の高い方法ですが一方でCloudWatch Logsはトラブル時などに参照する利用が多いため、都度ログを絞り込むためのクエリの書き方を調べる必要があったり、誰でも利用可能な状態とは言えませんでした。プロダクトを構成するコンポーネントが増え、ログの量、種類共に増加し、伴ってエンジニアも増えてきた際にこのような構成ではトラブル時の対応に時間がかかってしまう問題点が出てきました。ログのインフラ構成の改善インフラチームでは前述の課題を解決するためログ関連のインフラ構成を改善することにしました。新しい仕組みで以下の要求を満たすことを目標としました。新しいコンポーネントを追加した際のログの管理が容易であることログが検索しやすい状態になっていること前

こんにちは、メタバースプラットフォーム「cluster」を開発・運営するクラスター株式会社です。今年もクラスター社のAdvent Calendarがはじまっています！バーチャル空間やアバター、デザイン、ワールド制作、働き方、組織開発などさまざまなトピックの記事が投稿される予定なので、ぜひご覧ください！qiita.com

はじめにきっかけManaged Stripping Levelを変更する際の課題Reflection APIを使っているコードが動かなくなる既存のワールドが動作しなくなる並行開発中のコードが壊れるRoslyn Analyzerを導入するRoslyn Analyzerの運用上の問題結果とまとめはじめにこんにちは、クラスター株式会社でソフトウェアエンジニアをしているhomulerです。（入社の経緯は4コマになっているので、ぜひそちらも参照ください）clusterのアプリはUnityで作られているのですが、先日、apkのサイズ対策も兼ねて、ビルド時の設定の一つであるManaged Stripping Levelをlowからmediumに変更しました。必要なコードがstripされてしまう可能性があるため、リリース済みのアプリのManaged Stripping Levelを変更するのは怖い面もありますが、大きな問題もなく実施できました。この記事では、Roslyn Analyzerの導入など、安全に設定変更するために行ったことについて紹介します。きっかけまず、Managed Stripping Levelを変更することになった事情について触れます。クラスターは開発者が増えてきたこともあり、機能開発が加速しており、それに伴ってapkのサイズの増加ペースも加速していました。apkのサイズが150MBを超えるとgoogle playにアップロードできなくなるため、定期的にサイズ削減は行われていたのですが、近いうちにこの制限を超えてしまうことは明らかでした。したがって、抜本的な対策が必要になったのですが、開発に一定時間かかる見込みであり、一方で「apkのサイズを増加させてしまうが、できるだけ早くリリースしたい改修・機能」もあり、抜本的な対策の前に数MBのサイズ削減を行いたい需要がありました。そこで、どのような対策が有効かを調べるために、過去のバージョンでのapkのサイズの内訳を調査したところ、画像等のリソースの増加ペースとコードの増加ペースがほぼ同じぐらいであることが分かりました。libil2cpp.soのサイズを減らす方法はいくつか考えられましたが、当時のManaged Stripping Levelがlowで、不要なコードがそれなりに含まれているという状況で、かつmediumに変

はじめに通知機能の概要設計の話さまざまな通知内容に対応するための仕組み未読通知の管理通知をまとめる仕組みその他工夫したこと通知を追加する方法やポイントをドキュメント化データの有効期限を設け、データ量が爆発したときにスムーズに消し込みするための対応ができるようにしたまとめはじめにクラスター株式会社でサーバサイドエンジニアとして働いているえんじです。今回、表題にもあるように通知機能をclusterに追加したため、そのときに工夫した点などについて書いてみようと思います。通知機能は様々なサービスで作ることが多いと思うので、一つの事例として参考になればと思います。通知機能の概要まず、今回clusterに追加した通知機能がどんなものかを解説します。今回追加したのは、ユーザーがアプリ内で特定の画面を開くことで内容を確認できる機能です。執筆時点ではclusterのモバイルアプリを開いた際にタブの中に「通知」というタブがあり、そこをタップすると表示されるものが今回作った内容になります。※アイコンやワールド名はマスクしてありますこの機能は「cluster内で起きた出来事を蓄積し、ユーザーが非同期的に確認できるようにする」という体験を実現するために実装されました。最近では写真フィードを見た他ユーザーからの反応やミッションの達成履歴など、さまざまな内容がこの機能で確認できるようになっています。設計の話今回の機能の中で主要な要件は以下の3点でした。今後追加されるさまざまな通知内容に対応できるようにしておきたい既読/未読の通知をUI上出し分けたい通知内容に応じて、通知が並びすぎないようにまとめられるようにしたい (Xの通知のような挙動)他の細かな要件と合わせて設計した結果、最終的なDB設計は以下のようになりました。全体的な方針として、通知に必要な内容の収集など重たい処理は書き込み時に行い、読み取り時の処理は最小限に抑えることを前提としています。そのため、DB構造も正規化を崩してでも読み取り時にできるだけJOINが必要ないような設計になっています。また、NoSQLなどのRDB以外の利用も検討しましたが、パフォーマンス上懸念がなくコスト的にも優位だったため、RDBを利用することにしました。以降の項目で、主要な要件をどのように解決していったかを掘り下げながら解説させていただきます。さまざまな通知内容

2023年9月26日に行われた、データアナリストやデータ分析に興味がある方に向けたイベント『10X,ルーデル,cluster｜急成長ベンチャーデータ人材の「アレ」を語る会』tech-track.connpass.comクラスターからは、データアナリストの今井が登壇し「メタバースのデータ分析とはなにをやっているのか」というタイトルで発表しました。この記事では、イベントの登壇内容を要約してお伝えします。今回のイベントの登壇者今井 裕貴 プラットフォーム事業本部 ソフトウェア開発部 データアナリスト2022年4月クラスター入社。データ分析専任のメンバー1人目として参画し、主にデータ分析による意思決定の支援を行いながら、データ可視化ツールの運用や分析基盤の構築など、全社横断のデータ活用促進を広く担当。2022年以前はソーシャルゲームやライブ配信サービスといった領域でデータ分析に従事。既存の知見を十分に活かせる──メタバースのデータ分析の業務内容内製を含めたクラスターの分析用データ基盤未開拓のメタバースならではの分析を切り開いてく面白さ──「ユーザーは高いところが好き」？まとめ既存の知見を十分に活かせる──メタバースのデータ分析の業務内容今回は「メタバースでも既存の知見を活かせること」と「まだまだ未知であるメタバースならではの分析をできる魅力」というトピックに分けて、クラスターでのデータアナリストの仕事を紹介します。メタバースのデータ分析というと、3D空間なので、データがたくさんありそうそもそも機能が多くてできることが多い特別なデータ分析が必要そう特別なデータ基盤とかありそうそもそも何を分析するんだろうとの疑問を持つ方もいらっしゃるかもしれませんが……他のtoCサービスで一般的に行っている分析を行うことが多いです。もちろんメタバースならではの分析もあります。具体的には、よく行う業務として、サービスの運営や開発上必要な事業データの分析・可視化を挙げることができます。ここでの指標は、「アクティブユーザー数」「継続率」「新規ユーザー数」「利用しているプラットフォーム」などです。なので、メタバースだからといって特別目新しい指標というわけではなく、他の会社でも一般的に使われている馴染みのある指標を対象としています。もう一つ業務の例を挙げると、クラスターでは様々な施策や機能追加、法人イベ

はじめにこんにちは、クラスター株式会社でソフトウェアエンジニアをやっているid:shiba_yu36です。クラスターではGoの自動テストをCircleCIで実行しています。入社して以降、この自動テストの実行時間が少し長いと感じたため、調査と改善を進めてきました。結果として速度を改善できたので、この記事でGoの自動テスト高速化のための調査と改善手法について共有したいと思います。はじめにGoの自動テストで課題だったこと最終的な結果自動テスト高速化の流れテスト実行時間のボトルネックを調査するCircleCIのTIMINGタブで大まかなボトルネックを調査するmake testのボトルネックを調査する高速化でやるべきことを決定する1つずつ改善し結果を計測するgo generateの成果物をレポジトリにcommitし自動テスト上では実行しない: 2分短縮ビルドキャッシュを用いて高速化する: 改善ならずテストの並列化によって高速化する: 2分〜2分半短縮最終的な結果のまとめおわりにGoの自動テストで課題だったことクラスターではGoの自動テストは全てのPullRequestで実行し、自動テストが通らないとマージしてはいけないというルールになっています。その時の自動テストの実行時間がそろそろ10分を超えそうになっていました。これまでの自分の経験上、10分を超え始めると「テストの実行が遅いな」と感じることが多かったです。またテスト実行時間の長さは、PullRequestマージまでの時間やリリース実行時間に大きく影響を与え、結果として開発生産性の重要な指標である変更のリードタイムとサービス復元時間に悪影響を与えてしまいます。さらにサービス拡大/組織拡大に伴って、自動テストの数もかなりの勢いで増えていました。そのため今後もテスト実行時間が伸び続けると予想していました。以上の理由から、開発生産性を維持するためにもテスト実行を高速に保ちたいと考えました。しかし自分は、テスト実行時間を速めるためにテストの書き方を工夫したり必要最低限のテストのみに制限したりといった対策はやりたくありませんでした。なぜならテスト自体を工夫しなければならないと開発に余計な時間がかかりますし、また必要最低限のテストに留めると品質水準を損なう危険があるためです。そこでできる限りテストの実行の仕方の工夫だけで、自動テストの

はじめにこんにちは！今年の1月からクラスター社でソフトウェアエンジニアとして働いているryomaです。はじめに背景移行前のMainActivityの設計(as-is)移行後のMainActivityの設計(to-be)具体的な移行の進め方詳細な移行対象の洗い出し移行作業の依存関係を整理FeatureFlagで移行前後の状態を切り替えられるように制御進め方のポイントまとめ苦労した箇所（おまけ）HorizontalPagerの切り替えとドロワー開閉のジェスチャー操作がコンフリクトするおわりに背景具体的な話に入る前に、Compose移行対象としてMainActivityが最後まで残っていた理由とこのタイミングで移行するに至った背景を簡単に紹介します。まず、移行対象として残っていた理由ですが、大きく以下の要因が挙げられます。MainActivity（モバイルアプリのトップ画面）は、長らくUIの更新の入らない状況が続いていたBottom NavigationやDrawer Navigationなど、単体でのJetpack Compose移行が難しいUI要素が多数含まれていたので、移行実施に際してはこれらも含めて一度に大量の要素を移行する必要があった上記のような状況を踏まえつつも、このタイミングでのCompose移行を実施することにした理由として、次のような理由が挙げられます。写真フィードやスペース機能の開発が本格的に始まり、直近でアプリトップに大きな更新が入る予定がある継続的なアプリのメンテナンスという観点から、XML Layoutの画面が残っていると開発のボトルネックになってしまう特に後者に関しては、MainActivity以外の画面でJetpack Composeへの移行が済んでいたこともあり、「MainActivityのコードに修正を加える ＝ 普段と異なる記述のコードベースに触れる必要があるので心理的負荷が上がる」という状況を是正する観点も含んでいます。移行前のMainActivityの設計(as-is)UIの開発方針: XML Layout & View Binding、inflateはFragment毎に実行する移行前のMainActivityの構成は上記のようなBottom Navigation + 複数Fragmentのよくある構成になっていました。移行後のM

こんにちは！クラスター株式会社でソフトウェアエンジニアをやっているTAATです。今回はiOSDC Japan 2023にスポンサーセッションで登壇させていただきましたので、久しぶりのオフライン参加の様子や発表した内容について紹介します。iOSDC Japanとは？iOSDC Japanは年に1回開催されるiOS関連技術をテーマとしたデベロッパーのためのカンファレンスです。コロナ禍になってからオンラインのみの開催となってしまいましたが、昨年からオフライン＋オンラインのハイブリッド開催に戻りました。オフライン会場は早稲田大学理工学部 西早稲田キャンパスで、オンラインではニコニコ生放送で配信されています。今年は9/1〜9/3の3日間開催され、初日はday0として夕方から前夜祭とトークセッションでしたが、day1,day2ではトークセッション以外にも名物のLT大会があり、今年はとくに盛り上がりました！その様子は後ほど紹介します。オフライン参加オフライン参加は去年から復活しましたが、今年は完全にコロナ前の勢いが戻り、フルスペックのiOSDCが戻ってきた感じがしました！今年の参加者数は過去最高だったようで、オフライン参加者の割合もかなり大きく、人気のトークセッションは満席で入れないほどでした。また、スポンサーブースも賑わっていて、採用しているアーキテククチャやSwift Concurrencyの導入などについてのアンケートやクイズ、面白いものではSwiftUIのコードを脳内でコンパイルしてどのような表示になるかを当てるなどのクイズもありました。今年のLT大会は例年以上の盛り上がりを見せ、入場時にペンライトを渡され、登壇者の好きな色のライトを振って応援するというライブさながらのスタイルでした。5分で強制終了するLTは、緊張感を高めるBGMもあってか勢いがあり、聴いている方もドキドキでしたが、各LTの内容は完成度が高く、会場全体を巻き込んで盛り上がっていました！他にもオープニングパーティや懇親会など、オフラインならではの他のデベロッパーとの交流の場が用意されていて、久しぶりに会う人と話したり新しい繋がりを作ったり、コミュニティとしての盛り上がりも実感しました。スポンサーセッションday2のスポンサーセッションでは、「メタバースプラットフォームを支えるiOS開発と運用」というテーマで

はじめにこんにちは、2023/05 にプロダクトマネージャーとしてクラスターにジョインした Smith です！入社ブログを書こうと思ってサボってたらテックブログを書く機会を頂きました、因果応報！この記事では掲題の通り、クラスターのプロダクトマネージャー組織についてお伝えしようと思います。本記事を通じてクラスターのプロダクト開発のリアルな課題や、プロダクトマネージャーチームがどんなチームかについて少しでも伝われば幸いです。はじめにプロダクトマネージャーってなに？「cluster」というプロダクトの複雑さどうしてこうなった？ - 増えていく複雑性クラスターの PM - 個の力は強いが…クラスターの PM の課題 - “チーム”になっているのか？合宿 - 泥臭く対話してシンクロ率を高めるPM チームのコンセプト世界の中心でつくる！伝える！モテまくる！クラスターの PM - これからまとめプロダクトマネージャーってなに？読者の皆様には釈迦に説法かもしれませんが、改めてプロダクトマネージャーとは何か？について概要を示します。本記事を読み進める上での事前知識として、プロダクトマネージャー像のイメージが統一できればと思います。※ 本記事ではこれ以降「プロダクトマネージャー」を「PM」と表記します。（タイプ数が多いからね！）私にとって PM と言えば及川卓也さんというイメージがあるので、氏の書籍である「ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略」から PM についての説明書きを引用をさせて頂きます。PM とはすなわちーーユーザーの求めるプロダクトの理想を追求する役割で、「ミニCEO」とも呼ばれます。ソフトウェアの仕様や設計を決めてエンジニアやデザイナーに開発方針を伝え、プロダクト開発を主導するだけでなく、継続的な成長にも責任を負います。絵にするとこんな感じですね。全社戦略あるいは事業戦略があり、その戦略実行のためにプロダクト作りに投資するぞ、という経営上あるいは事業上の決定がなされるわけです。プロダクトを作るためには市場のニーズやペインを調査したり、そこに対するソリューションや発明を企画して開発する、開発したものがちゃんとユーザーのニーズを満たしているか観測して継続的に改善・運用していく・・・プロダクトのビジョンを掲げ、それを実現するための大きな取り組みを統括す

序文こんにちは、クラスター株式会社でソフトウェアエンジニアをやっている獏星(ばくすたー)です！さっそくですが、クラスターは3D空間を扱うメタバースを開発しており、Unity Engineを基盤としています。社内には20~30人程度のUnity Engineerが在籍しています。また、開発チームは機能ごとの職能横断チームに分かれています。たとえばユーザーどうしがつながる機能を提供するチーム(social team)はUnity Engineerだけではなく、Server、Web、iOS、Androidネイティブの各エンジニアが所属しています。そのような人数規模とチームの構成スタイルのもと、クラスターでは基本的に単一のコード基盤をメンテナンスしています。Unityの場合、クライアントコードがほぼ単一のUnityプロジェクトに集約されている、とも言い換えられます。本記事では、そうした体制のもとコードメンテナンスをするうえでの開発改善活動を紹介します。ゲームエンジン特有の話題は少ないため、チーム開発という文脈で広く参考になると思います。なお、Unityの具体的な開発・実装イメージを持ちたい方にはこちらもオススメです。tech-blog.cluster.mu序文Unity屋さんこの記事で取り上げる活動例：コードレビュー施策1: レビューしてほしいとき用のslack絵文字の導入施策2: 一部コードのレビュアー制限施策3: 「PRの様子を見る(レビューのレビュー)」という活動の文面化施策4: コード規約チェックを人力レビューからRoslyn Analyzerに移行するさいごにUnity屋さんさて、タイトルにUnity屋さんという謎のワードがありましたが序文では完全に無視していました。いったい何者でしょうか。「Unity屋さん」はUnity Engineerのなかでも少人数(4人)がメンバーのグループで、Unityコードのメンテナンス性や信頼性を維持・改善することを目標としています。正式名称は「Unity Working Group (Unity WG)」ですが「Unity屋さん」のほうが通りがよいため、もっぱらUnity屋さんと呼ばれています。Unity屋さんの主な仕事はこんな感じです。リファクタリングをやっておく需要が高いコードをリファクタリングする小規模なものから大規模なのま

Cluster Tech Blogの編集を担当しているFUKUDAです。2023年7月24日（月）に行われた「はてなブログ DevBlog Meetup #1」に参加してきたので、そこで聞いたお話を今後のCluster Tech Blogの運営にも活かせればと思い、備忘録としてまとめてみようと思います。イベントの詳細は下記hatena.connpass.comイベントの様子は #HatenaDevBlog からご覧いただけるようです。はじめに｜Cluster Tech Blogの運営は絶賛模索中……テーマ1：ブログの目的テーマ2：運用のコツ（執筆者へのインセンティブ設計、継続の仕組み…）テーマ3：企業による技術ブログの価値各社の取り組みが垣間見えるLT終わりにはじめに｜Cluster Tech Blogの運営は絶賛模索中……最初にCluster Tech Blogの現状について書いておこうと思います。「メタバースプラットフォーム」を開発するスタートアップであるクラスターは、2022年1月にtech blogを開始しました。当初はnoteを利用して、CTOとエンジニアリングマネージャーを中心にして運営していましたが、2023年4月のはてなブログへの移管に伴い、社内で別の発信業務に従事していたFUKUDAが編集担当となり、CTO、エンジニアリングマネージャーと運用を続けています。FUKUDAは、雑誌編集やwebメディアの運営の経験はありましたが、tech blogの運用ははじめてです。また、エンジニア出身というわけでもなく技術について明るいわけではないので……どのような発信を行っていくかは絶賛模索中です。（もしクラスターのtech blogでの発信に興味のある方は、SNSなどで「こんな記事を読んでみたい！」と言ってもらえれば、実現するかも……？）そんなわけで、今回のイベントではtech blogの先達のさまざまなお話を聞けるということで嬉々として足を運びました。ここからはイベント内のトークディスカッションで話された内容をサマリーしつつ、このtech blogはどうしていくか少しメモ書きしていこうかなと思います。ちなみにトークディスカッションに登壇された方は下記でした（イベントページより引用）エヌ・ティ・ティ・コミュニケーションズ株式会社 イノベーションセンター 小倉 真

前口上こんにちは。主にサーバーの開発を担当している id:Sixeight です。クラスター株式会社ではソフトウェアエンジニアはリモート勤務が基本となっていて、多くの社員が自宅から勤務しています。普段は画面越しにやり取りをしつつ、月に一度、全員がオフィスに出社することでコミュニケーションの濃度を上げています (出社の様子)。実際に私も 大分県から遠方組としてリモートワーク をしています。今回はすでに各社がやりつくしているリモートワークの様子をお伝えする記事をやっていこうと思います。いいんです。我々には我々のリモートワークがあるんです。全ソフトウェアエンジニアを対象にアンケートを行い、その中からできるだけ領域や属性がばらけるように選んだ6人のリモートワークの様子をお伝えします。それぞれのこだわりの違いを感じていただけるかと思います。皆さんのリモートワークをより加速するためのヒントが見つかれば幸いです。前口上獏星(ばくすたー) さん (主な担当領域: Unity)asukaleido さん (主な担当領域: Web)ぽけば さん (主な担当領域: Unity & サーバー)kyokomi さん (主な担当領域: サーバー)しんじゅ さん (主な担当領域: iOS / Android)thara さん (主な担当領域: サーバー)おまけ：VR・アバター出社環境について最後に 獏星(ばくすたー) さん (主な担当領域: Unity)1日の時間の使い方を教えてください9:00 起床10:00~12:30 作業12:30~14:00 買い出しに行きつつ昼食14:00~19:00 MTGもありつつ作業19:00~20:00 自炊して夕食20:00~22:00 もうちょっと粘る22:00~25:00 お風呂 / 個人開発 → 就寝仕事とプライベートの切り替えはどうしていますか始業時に必ずコーヒーを淹れてスタート終わったら早めにお風呂へ自宅で仕事に集中するときの工夫やこだわりはありますかリビングではなく自室で作業デスクにモノを置きすぎないあえてモニター1枚はSlackに専有させてしまう声に出して喋りながら考えるリモートだと独り言が多くても迷惑になりにくいのがポイントです同僚とのコミュニケーションで気を付けていることはありますかDiscord常駐週1で雑談タイムがある仕事の話じゃないS

はじめにソフトウェアエンジニアの浦川です。クラスターでは毎週のようにサービスへの機能追加や改善をおこなっています。合わせて、どのようにリリースしていくか、の改善も日々おこなわれています。この記事では、サーバーチームのリリースフロー改善の取り組みについて紹介できればと思います。はじめにclusterの開発とリリースフロー改善前のリリースフロー：部分最適化はされているが、全体最適化は......リリースフローの改善方針動作確認が難しい「バーチャル空間内の体験」のE2Eテストを開発feature flagの自動テストを増やすAWS CodePipelineでリリースフロー自体を最適化するリリースフローの改善結果：サーバーリリース所要時間をほぼ1日→2〜3時間程度に／ツールのセットアップ等のサポートが不要にまとめclusterの開発とリリースフローclusterには、AWSアカウントごと分離された開発環境(DEV)／ステージング環境(STG)／本番環境(PRD)という3つの環境が存在します。ふだんはDEVで開発をおこない、リリースの際にはSTGで動作を確認、問題なければPRDへリリース、というのが基本的なリリースフローの流れです。ソースコードはGitHub、開発タスクはJiraで管理されており、リリースフローのなかで関連するプルリクエストやチケットを集約したりステータスを更新するなど、リリースに伴う管理作業のようなものも発生します。改善前のリリースフロー：部分最適化はされているが、全体最適化は......サーバーチームではリリースを毎日おこなっているのですが、フローが必要以上に複雑化していることに課題を感じていました。当時のリリースフロー (灰色の吹き出しが概ね手作業)リリースをおこなうためのSlackのワークフローがあり、作業自体に難しいものはありません。個々の作業はスクリプト化されているものが多く指示に従って実行するだけではあるのですが、作業に必要なツール類は個々人のPCにインストールしてもらう必要がありました。そのため、いざリリースをおこなおうとすると、初回はまずセットアップをして...ということになり、セットアップがうまくいかずサポートが必要...なケースもあったり、ローカル環境の変化で動かなくなってた...ということもあったりと、なかなかスムーズにおこなうことがで

「SELECK」にclusterの開発組織づくりについて語った記事が掲載されました。弊社CTOの田中宏樹と、弊社エンジニアリングマネージャーの倉井龍太郎がclusterのリモートを駆使したバーチャルな働き方や、開発組織づくりについて語っています。ぜひご一読ください！seleck.cc

はじめにクラスター社の2023年エイプリルフール企画は「『あ～んVR』発売決定」と題し、バーチャル空間と連動して食事を食べさせてくれる物理デバイスを開発・販売する、という内容でした。◤速報 #あ～んVR 発売決定◢現実とバーチャル空間がリンクし食事ができる新商品「あ～んVR」を発表致しました。🔽特設サイトはこちらhttps://t.co/KwNHTxR5GP #cluster #エイプリルフール pic.twitter.com/xNW0EAOxtr— cluster公式∞ (@cluster_jp) 2023年3月31日 もちろん発売というのはジョークなのですが、エイプリルフールに本気で取り組むクラスター社では動画撮影のため実際にバーチャル空間と連動するハードウェアを用意しました。あいさつこんにちは、クラスターでインターンをしている滝竜三です。Cluster Creators Guideの記事執筆や、クリエイター向けイベントの会場制作などを担当しています。3DやUnityに関する制作・発信が今の仕事ですが、もともとは大学院修士までロボット制御を専攻しており、その経歴から今年のエイプリルフール企画にロボット制作担当として参加しています。僕が担当したのは主にソフトウェア側で、ロボットアームを目標位置に移動したり、clusterアプリと連動して制御したりといった部分になります。実装概要最初に全体の構成についてざっとまとめます。メインのハードウェアとしてはElephant Robotics社が販売しているアームロボット「myCobot」と専用グリッパーを利用しています。ロボット制御にはWindows Subsystem for Linux（WSL）上に構築したROSを使い、IK計算はROSパッケージの「MoveIt!」でおこなっています。ちなみにそれぞれのバージョンはUbuntu 20.04LTS + ROS noetic + Unity 2021.3.4f1です。環境構築VR空間とロボットの連動を想定して一台の端末内でVRアプリとROSが同時に使えるよう、WSL（Windows上でLinux環境を扱う機能）を使ってWindowsマシン上でROSを動かすことにしました。ROSというのはロボット制御用のフレームワークです。Linux上で動作し、C++とPythonで開発がで...

こんにちは！1月にクラスターにジョインしたTAATです。今回はExtended Tokyo - WWDC 2023というWWDCをもっと楽しむためのイベントに参加し、LTで登壇させていただきましたので、イベントの様子や発表した内容について紹介します。Extended Tokyo - WWDCとは？オフラインとオンラインのハイブリッド開催LT発表「メタバースプラットフォーム開発におけるSwiftUIの活用とTips」（資料あり）Keynoteライブビューイングおわりに参考Extended Tokyo - WWDCとは？画像提供：ヤフー株式会社様Extended Tokyo - WWDCは、Appleが毎年開催しているデベロッパー向けのカンファレンスであるWWDC (Worldwide Developers Conference)のメインセッション（Keynote）をもっと楽しむためのイベントです。Keynoteは日本時間AM2:00に行われるため、夜中に起きて視聴することが多いですが、このイベントでは実際に集まってワイワイしながらKeynoteをライブビューイングしたり、iOSエンジニアどうしの交流も兼ねています。オフラインとオンラインのハイブリッド開催画像提供：LINE株式会社様画像提供：ヤフー株式会社様今回はヤフー紀尾井町オフィスにある＜LODGE＞のオフライン会場と、弊社が運営するメタバースプラットフォームであるclusterのオンライン会場のハイブリッド開催でした。時間帯が深夜なので、オフライン会場での参加が難しい場合もオンラインで参加することができます。オフライン会場ではモニターにcluster会場の様子を映し出し、cluster会場にも発表スライドやオフライン会場の様子を映し出すことで、両会場での盛り上がりが伝わって、一体感のあるイベントでした！※clusterでは画面共有や「エモート」という機能でアバターがリアクションすることもできますLT発表「メタバースプラットフォーム開発におけるSwiftUIの活用とTips」（資料あり）画像提供：LINE株式会社様「メタバースプラットフォーム開発におけるSwiftUIの活用とTips」というテーマで発表させていただきました。メタバースプラットフォームというと、3Dやゲームエンジンのイメージがあるかと思いますが、実は

メタバースプラットフォーム「cluster」のプラットフォーム事業部インフラチームの佐藤です。clusterではクリエイターの皆様が創造力を発揮できるよう、またユーザーの皆様がよりclusterでの体験を楽しんで頂けるように日々機能開発、改善を行っています。これらの開発、改善を行う際の指標としてWebやアプリでのユーザーの機能の利用状況などのデータ収集を行っています。このデータ収集基盤は社内では「Panama」というプロジェクト名で運用されています。様々な場所で発生した大量のデータが集まり、次にデータを必要とするアナリティクスチームなどに届けるための中継点になれるよう、物流の要所であるパナマ運河にあやかってPanamaという名前がつけられました。今回はこのデータ収集基盤「Panama」の仕組みについて解説します。背景とコンセプトCloud RuntipsPub/SubDataflowCloud FunctionsBigQuerytipsまとめ背景とコンセプトclusterでは過去にUnity Analyticsを利用してデータ収集を行っていましたが、一時間あたり100イベントまでの制限や、データが参照可能になるまで数日かかる場合があるなど、ユースケースに合わない事が多かったこと、またUnity以外のブラウザでのイベントを収集し分析に活用したいなどの機運の高まりから、2023年よりGoogle Cloud上に構築した独自のデータ収集基盤を利用しています。このデータ収集基盤は次のコンセプトで作られています様々なクライアントから発生するデータを収集するため接続が容易イベントなどでスパイクする事は日常的なので急な負荷上昇にも耐えられる信頼性が高く障害時の復旧も容易以下の図を元にデータの受信からDWHとして利用しているBigQueryでデータが格納されるまでの流れを説明していきます。図1 データ収集基盤のシステム構成Cloud Runまずはデータの発生元からイベントデータをサーバーで受け取るためにエンドポイントが必要です。clusterはスマホ・PC・VR機器など様々なプラットフォームに対応したクライアントがあるため、汎用的で確実性の高いWebAPIでデータを送信する方式を採用しています。このAPIはGoogle Cloudのフルマネージドのサーバーレス実行環境であるClou

エンジニアコミュニティ「Qiita」を運営するQiita株式会社が運営するイベント「Qiita Night～AWS vol.2～」でクラスター社のソフトウェアエンジニア・浦川智洋が登壇して発表しました。increments.connpass.com当日の発表資料は下記になります。 speakerdeck.com

こんにちは！クラスター社でUnityエンジニアをしているNatsukiです。今回は、私が担当したmocopi対応というepicについてお話しします。特に、技術的負債を返済しつつ対応できたのが今回のepicの個人的なハイライトなので、そのことについてお話したいと思います。mocopi対応とはmocopi対応する上での課題についてどのように解決したのか1. デバイスを表すコンポーネントを抽象化2. 抽象化したクラスを用いて既存実装をリファクタ3. トラッカーの具象クラスの1つとしてmocopiを扱う解決編まとめ技術的負債を理解し、それを粉砕することを許してくれる環境mocopi対応とはmocopi対応とは、clusterのVRで(OSCを経由して)mocopiが使えるようにするというepicです。ただ、VRと一口に言っても、clusterではPCVRとQuestスタンドアローンの2種類があります。このepicでは、この両方でmocopiが使えるようにする必要がありました。www.youtube.com / 『mocopi』はソニーによるモバイルモーションキャプチャーmocopi対応する上での課題についてさて、clusterにおけるVRにはPCVRとQuestがあるという話をしました。PCVRとQuestでは、実装としては結構異なっている部分があります。具体的には、CameraRigと呼ばれる、トラッキングスペースにおけるHMDやコントローラ等の階層構造を表したリグがあるのですが、その周辺実装が異なっています。何故かと言うと、VRプラットフォーム(SteamVR、Quest)ごとに使用しているプラグインが異なるためです。これらのプラグインにはそれぞれのCameraRigのprefabが入っており、clusterではそれらを拡張する形で使っています。SteamVRのCameraRig(mocopi対応後)ただ、(おそらく歴史的経緯で)このあたりの実装が複雑になっており、そのままmocopi対応するのは厳しそうでした。何故なら、上述したとおりPCVRとQuestの両方で対応する必要があり、そうすると考慮すべき事項が(少しおおげさですが)組合せ爆発するためです。具体的には、既存実装は以下のような状態でした。両方のリグで共通して使っているコンポーネントが「#if地獄」になっている

こんにちは！クラスター株式会社でソフトウェアエンジニアをしているえんじです。クラスター株式会社には昨年10月頃に入社し、前職ではモバイルアプリのサーバサイドエンジニアとしてAPIの開発や社内ツールの開発などを行っていました。epic ownerとしてQuestアプリ内でアプリ内購入(以後IAP)の実装を任せていただいたのですが、その際につまづいた箇所を紹介していければと思います。QuestでのIAPについてclusterでは「クラスターコイン」を購入することで、バーチャルイベント上での投げ銭や、clusterで活動するクリエイターたちが制作した、cluster内でワールドをつくる機能「ワールドクラフト」で使えるアイテムを購入したり、自分のアバターにつけるアクセサリーを入手することができます。www.youtube.comクラスターコイン はQuest上で 購入することが可能で、その際にMeta社のOculusプラットフォームが提供しているIAPの仕組みを利用しています。このうち、今回はclusterのサーバーとOculusプラットフォーム間で通信を行っている部分の実装でつまづいたポイントを紹介していきます。アプリ内購入サーバー間API以降はサーバーがやり取りしている箇所をServer to serverの略でS2S、Oculusプラットフォーム側のAPIをS2S APIと呼称します。ポイント1 : S2S APIのデータ利用申請の審査時間にばらつきがあるまず、S2S APIを利用するためには、 データの使用状況(DUC)の確認の実施 を行う必要があります。DUCの提出はStore/AppLabの公開状況にかかわらず実施する必要があり、また毎年更新が必要です。なお、DUCの審査終了までの所要時間にはばらつきがあります。ポイント2 : S2S APIを叩く時トークンの取り扱いS2S API経由で特定ユーザーに対して操作をする場合、ユーザーを特定するためにトークンを渡す必要があります。サーバー間APIの基本 に記載はされているのですが、公式ドキュメントのサンプルとして記載されているトークンの形式が実情と異なっていてつまづきました。アプリ認証情報公式ドキュメントの こちらに記載されている方法です。公式ドキュメント の例に沿って、「consume_entitlement」のA

昨年10月にクラスター社に加わったmt_blue81です。Webフロントエンドをメインに施策に加わりつつ、開発環境の改善などにも取り組んでいます。今回はWebフロントエンドの状態管理まわりの改善についてご紹介します。clusterのweb画面clusterはマルチプラットフォームですが、webからも様々な操作が行えるよう機能が搭載されています。cluster.mu大きくは以下のようなスタックでつくられています。UIはReact + Material-UI + styled-componentルーティングはreact-router状態管理はReduxバックエンドとのやり取りはOpenAPIによって定義Reduxの状態管理はre-ducksパターンで構築されており、バックエンドとのやり取りもこのoperation層で実現されていました。re-ducksパターンは対象の状態と、その状態を操作するためのoperationを近くに配置できるため、関心のある部分がまとまるというメリットがあります。(clusterではこのまとまりをmoduleと呼んでいます)チームのなかでもドキュメントを整備したり、module作成時にテンプレートからひな形を生成するようにして実装コストを下げる工夫をしており、実際自分がチームに加わったときにも、コードが整理されて理解しやすい状態が保たれていました。脱Reduxとはいえバックエンドからのデータを扱う上で、以下のようにそれぞれで似たようなコードを毎回書くという課題感がありました。operation: APIを呼び出してデータactionでdispatchするreducer: storeにデータを格納するselector: storeに格納されたデータを取得するまたこちらの記事などで言及があるように、Reactにおける状態にはいくつか種類があり、すべてを同じように管理する必要はないのではという点も社内で議論しました。zenn.dev現行のReduxでの処理がキャッシュ的な側面とselectorによるUI用データ整形にフォーカスしており、その部分は後述のdata fetchingライブラリに任せるほうが良いだろうという結論となりました。そこで、API定義からできるだけコードを自動生成させつつ、通信データを取り扱うだけの層で分離できないかと考え、いくつか

クラスター株式会社でSoftware Engineerをしている thara です。cluster ではシステム間連携の一部にProtocol Buffers（以下protoと呼称）を使用しています。protoのスキーマ定義を独立したproto管理リポジトリに配置し、そのスキーマから生成した各プラットフォーム向けのコードを複数のproto利用リポジトリで利用しています。このprotoスキーマとそれから生成したコードを利用するまでのプロセスは、長い間運用されていましたが、問題を抱えていなかったわけではありません。開発メンバーも増え、徐々にその問題が無視できなくなってきました。この記事では、長年行ってきたその運用プロセスを最近改善したので、その事例を共有します。まず、長年行ってきた「手動でコード自動生成した旧運用」とその課題について述べ、次にどのような運用に改善したかを解説します。手動でコード自動生成する旧運用旧運用の課題Gradleをインストールする必要があるWindows上でコード生成した際にSwiftのコードが生成されていないprotoc pluginのバージョンが開発者の各環境ごとに差異が生まれることを防ぐ手段がない自動生成による改善まとめ手動でコード自動生成する旧運用旧運用を採用した背景として、以下のものがありました。proto更新はそれほど頻繁に発生するタスクではなかった（月に1回あるかないか）proto更新のために開発メンバーが行う必要がある事前準備は限りなく少なくしたいそれを踏まえて改善前の運用では、protoファイルを修正する際は、protoを修正した各メンバーがそれぞれ以下のような手順を取っていました。proto管理リポジトリのスキーマ定義を変更してcommitしてPull Request(PR)作成。PR reviewが通ったらマージ。proto利用リポジトリでgit submodule updategradleタスクでコード自動生成してcommitしてPR作成。CIが通ったらマージ。4のGradleタスクでは、protobuf-gradle-pluginを使用してprotoファイルからコードを生成し、ローカルのworking treeに対して生成されたコードを再配置する、といったことを行っています。なぜGradleを使っているかというと、クロスプ

ブイキューブの「Agora Go Real」にclusterのインタビュー記事が掲載されました。弊社ソフトウェアエンジニア 倉井龍太郎がAgoraを活用したclusterの「画面共有機能」についてお話しさせていただいています。www.youtube.comぜひご一読ください！jp.vcube.com

こんにちは！クラスター株式会社でソフトウェアエンジニアとして働いている @kaznishi です！クラスターに入社するまではいわゆるWebサービスを作る会社に勤めていました。その中で私は、分類するならばサーバーサイドやバックエンドのエンジニアとしてAPIを実装する仕事に主に携わっていました。今回の記事では、メタバースプラットフォームを開発しているクラスター社で私が携わっている仕事の紹介を通して「メタバースの分野にチャレンジしたいが自分のスキルが通じるか不安だ」と感じている人達の背中を押すことができたらと思います。クラスター社での幅広いソフトウェアエンジニアの仕事Webサービスの開発経験を活かせる「API serverをつくる仕事」管理画面 API3D空間アプリ向け APIメタバースは技術の総合格闘技クラスター社での幅広いソフトウェアエンジニアの仕事クラスターの社内には多くの「ソフトウェアエンジニア」が在籍していますが、人によってやっていることは様々です。サーバーサイドのシステムをつくっている人、iOSやAndroidなどのモバイルクライアントのアプリをつくっている人、Unityでclusterの空間が動く土台をつくっている人、clusterの空間に入るまでの導線であるWebクライアント部分をつくっている人etc...専門で得意領域を担当している人もいますし、複数領域をまたがって担当している人もいます。このように、クラスター社では「ソフトウェアエンジニア」と一言にいっても幅広い仕事があります。私は現在、サーバーサイド領域のバックエンドAPIの実装を担当したり、開発プロジェクトの進行に責任を持つepic ownerを務めたりしています。epic ownerの役割については下記の記事で解説しているのでそちらをご参照ください。今回はサーバーサイド領域の仕事について紹介します。tech-blog.cluster.muWebサービスの開発経験を活かせる「API serverをつくる仕事」クラスター社のサーバーサイドの仕事は大きく2つに分類できます。room serverをつくる仕事とAPI serverをつくる仕事です。room serverとはcluster内で3Dで表現された空間を各クライアント間でリアルタイムに同期する体験の根幹を担うリアルタイム通信サーバーです。詳細につ