こんにちは、クラスター株式会社 メタバース研究所でリサーチエンジニアをしているElizaです。ワールドの素敵な景色を見つけるAI「PanoTree」とは？ワールドサムネイル提案システム「WorldPano 」αテスト中ですなぜAIにワールドの魅力を理解させたいのか？PanoTreeの仕組み全体の流れPanoTreeを構成するモジュールレンダリングサーバー: スクリーンショットを撮影するモジュールScoringNet: 景色の魅力を判断するモジュールHOO: ワールドの探索方法を指示するモジュールどれくらいの処理量？レンダリングサーバーの実装従来手法改善手法改善手法の実装① GPUに優しくないバージョン改善手法の実装② GPUに優しいバージョンどれくらい早くなるの？まとめワールドの素敵な景色を見つけるAI「PanoTree」とは？PanoTreeは撮影スポット自動探索AIの名称で、オープンソースソフトウェアとして公開されています。ワールドサムネイル提案システム「WorldPano 」αテスト中です現在、PanoTreeを活用したサムネイル提案システム「WorldPano」のαテストを行なっています。worldpano.cluster.muなぜAIにワールドの魅力を理解させたいのか？メタバース研究所は「人類の創造力を加速する」というクラスター全体の目標を先導するための組織です。PanoTreeの取り組みは、ワールドの魅力ある景色を探索することを通じて、人を惹きつけるワールドとはとはなにか？をAIに理解させることを目標としています。PanoTreeの仕組みPanoTreeの特徴は、広大なワールドの探索処理量を大幅に削減し、効率的に探索を行えることです。arxivも合わせてご覧ください。全体の流れ探索する範囲を決める探索を指示されたPanoTreeはまずワールド全体のコライダーが存在する領域を計算します。これは探索範囲を大まかにコライダーがある場所(=ものがある場所)に絞り込むためですワールドを2分割する例えば、ワールドを左半分と右半分に分割します。分割を繰り返すことでMinecraftのブロックのように世界が分割されていきますスクリーンショットを撮影する分割したそれぞれの領域の中心からカメラを360度ぐるりと回して12枚スクリーンショットを撮影します景色の魅力を判断する分

こんにちは、クラスターでUnityエンジニアをしているsenchaです！本記事ではUnityの内製UI Framework「shiranui」の開発と、導入について紹介いたします。clusterが抱えていたUnityでのUI開発の問題点UI Framework 「shiranui」とはshiranuiでできることshiranuiの基本的な使い方（Sample画面の表示）shiranuiの開発clusterのunityprojectへshiranuiを導入するshiranuiの運用最後にclusterが抱えていたUnityでのUI開発の問題点clusterのUnity UI開発では以下の問題点を抱えていました。UI例: メインメニュー画面画面遷移実装の複雑さ画面遷移を1つの神classが行っており、煩雑になっている遷移履歴の拡張性が乏しく、1つ前の画面までしか保存できていない画面から戻る処理を各画面のenum型で分岐処理しているため、複数の戻り先がある場合に複雑になるUI実装のコストの高さスクロールリストの実装やその他UIコンポーネントとロジックの繋ぎこみの書き方が揃っておらず、各画面・コンポーネントごとにコードを書いてるUI component はほぼ素の uGUIを使用新規画面作成時にコピペコードが多いclass設計が強制されない画面遷移のための animation を都度作成する必要があるviewのコードでアニメーションとロジックが分離できていない上記の問題を解消し「UnityでのUI開発を10倍楽にするぞ！」をコンセプトに始まったのがshiranuiです。third-partyのUI Frameworkを使う選択肢もありましたが、以下のことを理由に内製で作ることに決めました。カスタマイズ性と柔軟性clusterのクライアントアプリではDesktop/Mobile/VRと様々なプラットフォームで開発を行っており、全てのプラットフォームを見据えてUI開発を行えることが理想パフォーマンスの最適化clusterのクライアントアプリでは特にMobileでのパフォーマンスを最適化したい需要があり、パフォーマンスの計測・最適化を行いたいUI Framework 「shiranui」とは内製のUI Frameworkを開発していく上でコードネームをshiranuiと名づけまし

クラスターの最古参社員、エンジニアリングマネージャーのmizogucheです。クラスターも創業9周年を迎え、4名の新卒エンジニアを受け入れることになりました。*1今まで中途採用しかしておらず、勉強会はあっても未経験者向けの研修は存在していませんでした。ポテンシャルに期待して採用しているとはいえ、経験の少ない方に、いきなり「いまから仕事を始めてくださ〜い！」と言ってスムーズなタスクの遂行を期待するのは不親切なので、技術研修を設計・実施しました。そこで本記事では、私がリードして設計し、5週間にわたって実施されたエンジニア向けの職種研修についてご紹介します。多様な経験を積んでもらう2ヶ月にわたる新卒研修エンジニア向け職種研修の設計要件成長を加速するためのスキルを身につけることを重視する技術スタックを一通り経験すること実践形式での演習を行うこと演習用教材「Cluster Learning Materials」演習の実装目標や手順、習得してもらいたいスキルについてclusterの実装について学ぶ教材「Cluster Learning Materials」サポート体制Daily meeting振り返りメンターとの1on1Slackでのコミュニケーション研修を終えて多様な経験を積んでもらう2ヶ月にわたる新卒研修新卒研修は全体では2ヶ月。最初に基礎研修、各組織の紹介・社内ルール・ビジネスマナー・ソフトスキルなどの講義が行われ、次に職種毎にわかれた職種研修、最後にチームビルディング研修としてゲーム制作ブートキャンプが行われました。全職種向けの基礎研修とチームビルディング研修は、人事部にて設計・実施されました。今回紹介するのは、この中の職種研修の部分となります。エンジニア向け職種研修の設計要件研修の設計にあたって、クラスターのエンジニアとして求められることを整理し、以下の要件を定めました。成長を加速するためのスキルを身につけることを重視するポテンシャルを顕在化させるため、スキルを素早く習得して使いこなすスキル＝メタスキルを伸ばすことを重視しました。頻度を高めに振り返りをするなどして、PDCAサイクルを回すことを実践できるようにしました。技術スタックを一通り経験することclusterはスマホ・PC・VR機器など対応プラットフォームが多く、使用している技術スタックが多岐に渡っています。研修

こんにちは、クラスター株式会社でサーバーサイドをメインに開発している id:shiba_yu36 です。僕は今年の2月にclusterというサービスでウィークリーランキングの機能を担当しました。clusterではユーザーが自由にゲームやアート作品などの3Dコンテンツを作りアップロードでき、そのコンテンツを複数人ですぐ遊べます。その中から人気のコンテンツを探しやすくするため、週間ランキングを開発しました。この機能開発時に、実装をする前にPMとデータを見て試行錯誤しながら、ウィークリーランキングの目的を満たすシンプルなアルゴリズムを決めるという工夫をしました。このやり方によって、最小限の実装工数で目的を満たすランキングアルゴリズム実装を行えました。そこで今回は実装前にどのような流れでアルゴリズムを決定していったかを書いていきたいと思います。同じような機能開発を行っていてPMとどう連携するか悩んでいる人の参考になれば幸いです。ランキングなどのアルゴリズムを考える時の課題感PMと一緒にランキングのありたい姿を明確にする本番データを使って実装前に具体的なランキングの可視化をするPMと複数のアルゴリズムを比較し、初期リリースのアルゴリズムを決定するまとめランキングなどのアルゴリズムを考える時の課題感ランキングやレコメンドなどのアルゴリズムを考える系の機能開発を行う時、よくある失敗は机上の空論のままPMとエンジニアで最高のアルゴリズムを考えようとしてしまうことです。このような失敗を踏むと、実装に非常に多くの時間がかかる一方で、いざリリースしてみると想定と違うものになってしまったということがよく起こります。このような課題感を持っていたため、今回は以下の流れで初期リリースのアルゴリズムを決定していきました。PMと一緒に現在のclusterにおけるウィークリーランキングのありたい姿を明確にする実装前に本番データを使って、いろんなアルゴリズムで具体的にどのようなランキングになりそうかを可視化するPMと一緒にいくつかのアルゴリズムを比較して、ありたい姿と実装コストのバランスを見ながら、初期リリースのアルゴリズムを決定するPMと一緒にランキングのありたい姿を明確にするまず現在のclusterにとってのウィークリーランキングの目的とありたい姿を明確にします。ここがずれると不要な機能を作ってしま

こんにちは。ソフトウェアエンジニアのすぎしーです。ClientCI WG (Client Continuus Integration Working Group)というclusterのクライアントアプリのCI環境を社内向けに提供するWGのオーナーも務めています。clusterアプリではWindows版(VR含む)、Mac版、Android版、iOS版、MetaQuest版の5つが現在提供されていて、基本的に週次リリースを実施しているため安定したリリースフローが求められます。また、開発版アプリのビルドから検証までの迅速なイテレーションを提供することも、アプリの機能改善や品質向上において重要なポイントとなっています。今回はこれらのリリースフローや開発版アプリのビルドに欠かせないクライアントアプリのCIをJenkinsからGitHub Actionsに移行して、どのような改善を実現したかについて紹介します。用語の紹介背景: Jenkins時代の課題masterノードの障害時のリスクが大きかったリリース版と開発版で同一ジョブを無理矢理に再利用していた弊害1. リリース版と開発版のジョブのキューが同列になっていた弊害2. ビルド対象外のプラットフォームまでキューに積まれていたログ出力がジョブ全体で1つのプレーンテキストに出力されており、失敗原因の調査が大変だったその他の課題GitHub Actionsを選択した理由余談: GitHub Actions以外で候補になったCIツールJenkins + JenkinsfileCircleCIGameCIGitHub Actionsへの移行に伴う懸念事項懸念1: GitHub側の障害によるCIの停止懸念2: GitHub Actionsで発生する従量課金GitHub Actions移行で改善したことmasterノードの運用保守が不要となったワークフローのレシピがyml定義のリビジョン管理となり、コードレビューを通すフローになったReusable Workflowsの活用により、プラットフォームごとのワークフローが再利用しやすくなった実行キューが開発版とリリース版で分割されたワークフロー失敗時の調査が捗るようになったワークフローで承認フローが導入できるようになったまとめ用語の紹介CIを説明するにあたり多用することになる用語について、予め

はじめにアーキテクチャ負荷試験モードオンラインマルチプレイのテストとデバッグの難しさおわりにはじめにこんにちは、クラスター株式会社のソフトウェアエンジニアのsotanです。今回はclusterのUnityクライアント開発に使われている負荷試験環境について紹介します。clusterは、バーチャル空間で開催されるイベントに参加したり、クリエイターの方々が制作したワールド（= バーチャル空間）で遊んだりすることができるプラットフォームです。ワールドでは25人（ロビーのみ50人）、イベントでは100人が同時に1つの空間に集まることができます。負荷試験環境は「ワールド・イベント会場に多くのユーザーが集まっている状況」を再現して、そのような状況で発生する問題の再現確認・原因調査・改善結果確認などに使われているものです。アーキテクチャ一般的には負荷試験用のツール・フレームワークを活用した環境を構築するケースが多いと思いますが、clusterのUnityクライアント開発では、現状、Windows版アプリをAmazon EC2インスタンス上で実行するというシンプルな方式を採用しています。GitHub Actionsのワークフローによって、Amazon S3に存在するビルドファイルや設定ファイルの確認、新しいジョブの実行準備、EC2フリートの新規作成が実行されます。EC2インスタンスが起動すると、必要なファイルをS3からダウンロードして、clusterアプリを負荷試験モードで起動するスクリプトが自動的に実行されます。ワークフローの入力パラメーターとして与えられるワールド・イベント会場に自動入室させるクライアント数負荷試験の実行時間によって、EC2インスタンスの数や終了時刻が設定されます。また、入力パラメーターとして負荷試験用クライアントとして使われるビルドワールド・イベント会場のIDアバターの種類なども設定するようになっていて、複数の異なる条件の負荷試験を同時並行で進行することができます。特定の機能・不具合・パフォーマンス問題などに合わせた状況・条件を設定して負荷試験を進行することができます。負荷試験モードclusterの開発版ビルドでは負荷試験用クライアントとして動作するモードが有効になっています。通常モードでは、ログイン、アバター選択、ワールド・イベント会場への入室などを行うために

はじめにパフォーマンス改善についての参考文献実機計測フィーチャーフラグ計測・プロファイリング効果見積効果計測おわりにはじめにこんにちは、クラスター株式会社のソフトウェアエンジニアのsotanです。今回はUnityクライアントのパフォーマンス改善の取り組みについて紹介します。ユーザーの皆さまに快適な体験を提供できるように、新機能の開発や既存機能の拡張・修正と並行して、パフォーマンス改善に取り組んでいます。具体的な改善点や改善方法を全て紹介することはできないのですが、どのような雰囲気で進めているのかを知ってもらえればと思います。パフォーマンス改善についての参考文献Unityアプリケーションのパフォーマンス改善に必要となる基礎知識やノウハウについては、【Unite 2017 Tokyo】最適化をする前に覚えておきたい技術（docswell, YouTube）Unityパフォーマンスチューニングバイブル（GitHub）などを参考にしています。実機計測clusterはマルチプラットフォームで提供されていて様々なスペックの端末で使われていますが、パフォーマンス改善点を探したり改善結果を確認したりする時は、最低動作環境のスペックの検証用端末を使って、実機で動作確認と計測を行います。現在は、特にモバイル版（Android、iOS）のパフォーマンスを優先的に見ています。Unity Editorを使っている環境と実機のスペックの違いによって計測結果が大きく異なっていたり、特定のプラットフォームの場合のみ実行される処理が比較的大きなボトルネックになっているケースがあったりするため、特別な理由がない限りは必ず実機で動作確認と計測を行います。フィーチャーフラグclusterの開発では複数の機能開発を同時並行で進めるためにフィーチャーフラグ（Feature Flag）が使われており、開発版ビルドでは、まだリリースされていない開発進行中の機能が有効になっています。パフォーマンス改善点を探す時は、リリース版と同じ状態にFeatureFlagを設定した上で計測・プロファイリングして詳細を調査していきます。開発進行中の新機能のパフォーマンスを調査・検証する場合は、その機能のFeatureFlagも有効にしておきます。計測・プロファイリングUnity ProfilerとProfiler Analyzer

昔のflag管理AWS AppConfigの導入feature flagの管理feature flagの利用まとめソフトウェアエンジニアの浦川です。clusterではサービス開発にfeature flagが活用されており、常時10+個程度のflagが並行して使われています。これまでflagはgoのコードとしてハードコードされていたのですが、AWS AppConfigを利用してコードを修正することなく動的に変更できるようにしました。昔のflag管理ハードコードされたflagは1つのstructにまとめて定義されていて// feature flagを集めたものtype FeatureFlag struct { IsAvatarXxx bool // アバターを良い感じにする IsEventXxx bool // イベントを良い感じにする // (大量のフラグ)}appが起動する環境(ENV環境変数により識別)によって適切なflagを含んだ設定情報を読みこむようになっていました。// config_dev.govar dev = Config{ Feature: FeatureFlag{ IsAvatarXxx: true, IsEventXxx: true, }}// config_stg.govar stg = Config{ Feature: FeatureFlag{ IsAvatarXxx: true, IsEventXxx: false, }}// config_prd.govar prd = Config{ Feature: FeatureFlag{ IsAvatarXxx: false, IsEventXxx: false, }}// main.govar config Configfunc main() { env = os.Getenv("ENV") switch env { case "DEV": config = dev case "STG": config = stg case "PRD": config = prd }}実装での利用イメージif config.Feature.IsEventXxx { // onの場合} else { // offの場合}長らくこの方式で開発を続けていたのですが、徐々に不便さが目立つようになってきました。まず、基本

こんにちは、プロダクトマネージャー（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やゲームエンジンのイメージがあるかと思いますが、実は