社内からの不具合報告をSlackワークフローを使って改善した話 - Cluster Tech Blog
こんにちは、プロダクトマネージャー（PM）のいかりです。 今回の記事では、プロダクトに対しての社内からの不具合報告のフローを改善した話について紹介します。 「社内からプロダクト改善のために色々な声をもらっているけどどう対応しよう……」と困っているような方は何かの参考になるかもしれないので、ぜひ読んでみてください！ プロダクトを安心して使ってもらうための「不具合対応」 社内からの不具合報告の既存の課題 【改善】Slackのワークフローを使って不具合報告フォームを制作 結果、良くなったところ 社内の多くの人に不具合報告フローの存在を周知できた 数ヶ月で50件近くのバグ報告があり、1〜2割はその週に解決 連絡の往復回数が減った 後からのキャッチアップがしやすくなった まとめ プロダクトを安心して使ってもらうための「不具合対応」 プロダクトの成長のためには新しい機能の提供や操作性を良くしたり、とい
Working Group, 委員会, それから勉強会 - Cluster Tech Blog
こんにちは クラスター株式会社で Engineering Manager(EM) をしている kurain です。 今日は、クラスターのエンジニアが参加する会議体について紹介します。会議体の作り方について長々続くので、先にまとめを書いておくと エンジニアが自律的に開発プロセスを改善できるように、会議体を3つ定義しました それぞれの会議体には権限と責務が明示されています エンジニアは自ら発案して上記の会議体を開催できるので、業務改善が上手く回っています という話です。 背景 会議体を定義する Working Group 委員会 勉強会 定義による効果 もっと効率的で楽しいリモートワークのために 背景 なぜこのような会議体の定義が大切なのか背景から話を始めましょう。 クラスター株式会社はこの3年間で社員数が約6倍になりました（上図は2023年6月時点の資料）。エンジニアの数も6倍……とはいきま
無停止で機能開発を継続した、clusterのシステム分割事例 - Cluster Tech Blog
クラスター株式会社でSoftware Engineerをしている thara です。 私たちは今年、clusterのシステム分割という重要なプロジェクトを完了しました。この取り組みは、私たちのメタバースプラットフォームの進化と持続可能な成長にとって欠かせないものでした。 本記事では、システム分割の技術的なアプローチとその過程で直面した課題とプロジェクトの結果について説明します。 背景 解決策 システム分離プロジェクトにおける課題 課題を解消するための実施手法 Gatewayによる隔離 dual writeによる段階的移行/dual readによる差分検証 状態スナップショットによる差分検証 諦めの局所化 分離プロジェクトの結果と反省 今後の展望 背景 clusterがリリースされて6年が経過しました。 prtimes.jp 当初はバーチャルイベントプラットフォームとして展開されていましたが
Managed Stripping Levelを変更する隙にRoslyn Analyzerを導入した話 - Cluster Tech Blog
はじめに きっかけ Managed Stripping Levelを変更する際の課題 Reflection APIを使っているコードが動かなくなる 既存のワールドが動作しなくなる 並行開発中のコードが壊れる Roslyn Analyzerを導入する Roslyn Analyzerの運用上の問題 結果とまとめ はじめに こんにちは、クラスター株式会社でソフトウェアエンジニアをしているhomulerです。 （入社の経緯は4コマになっているので、ぜひそちらも参照ください） clusterのアプリはUnityで作られているのですが、先日、apkのサイズ対策も兼ねて、ビルド時の設定の一つであるManaged Stripping Levelをlowからmediumに変更しました。必要なコードがstripされてしまう可能性があるため、リリース済みのアプリのManaged Stripping Levelを
Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog
はじめに こんにちは、クラスター株式会社でソフトウェアエンジニアをやっているid:shiba_yu36です。 クラスターではGoの自動テストをCircleCIで実行しています。入社して以降、この自動テストの実行時間が少し長いと感じたため、調査と改善を進めてきました。結果として速度を改善できたので、この記事でGoの自動テスト高速化のための調査と改善手法について共有したいと思います。 はじめに Goの自動テストで課題だったこと 最終的な結果 自動テスト高速化の流れ テスト実行時間のボトルネックを調査する CircleCIのTIMINGタブで大まかなボトルネックを調査する make testのボトルネックを調査する 高速化でやるべきことを決定する 1つずつ改善し結果を計測する go generateの成果物をレポジトリにcommitし自動テスト上では実行しない: 2分短縮 ビルドキャッシュを用い
メタバースプラットフォームを支えるiOS開発と運用 / iOSDC Japan 2023登壇レポート - Cluster Tech Blog
こんにちは！クラスター株式会社でソフトウェアエンジニアをやっているTAATです。 今回はiOSDC Japan 2023にスポンサーセッションで登壇させていただきましたので、久しぶりのオフライン参加の様子や発表した内容について紹介します。 iOSDC Japanとは？ iOSDC Japanは年に1回開催されるiOS関連技術をテーマとしたデベロッパーのためのカンファレンスです。コロナ禍になってからオンラインのみの開催となってしまいましたが、昨年からオフライン＋オンラインのハイブリッド開催に戻りました。オフライン会場は早稲田大学理工学部 西早稲田キャンパスで、オンラインではニコニコ生放送で配信されています。 今年は9/1〜9/3の3日間開催され、初日はday0として夕方から前夜祭とトークセッションでしたが、day1,day2ではトークセッション以外にも名物のLT大会があり、今年はとくに盛り上
クラスターの開発改善活動～Unity屋さんとコードレビュー～ - Cluster Tech Blog
序文 こんにちは、クラスター株式会社でソフトウェアエンジニアをやっている獏星(ばくすたー)です！ さっそくですが、クラスターは3D空間を扱うメタバースを開発しており、Unity Engineを基盤としています。社内には20~30人程度のUnity Engineerが在籍しています。 また、開発チームは機能ごとの職能横断チームに分かれています。 たとえばユーザーどうしがつながる機能を提供するチーム(social team)はUnity Engineerだけではなく、Server、Web、iOS、Androidネイティブの各エンジニアが所属しています。 そのような人数規模とチームの構成スタイルのもと、クラスターでは基本的に単一のコード基盤をメンテナンスしています。 Unityの場合、クライアントコードがほぼ単一のUnityプロジェクトに集約されている、とも言い換えられます。 本記事では、そうし
「はてなブログ DevBlog Meetup #1」に参加しました #HatenaDevBlog - Cluster Tech Blog
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の
サーバーサイドのリリースフローを改善したはなし - Cluster Tech Blog
はじめに ソフトウェアエンジニアの浦川です。 クラスターでは毎週のようにサービスへの機能追加や改善をおこなっています。合わせて、どのようにリリースしていくか、の改善も日々おこなわれています。この記事では、サーバーチームのリリースフロー改善の取り組みについて紹介できればと思います。 はじめに clusterの開発とリリースフロー 改善前のリリースフロー：部分最適化はされているが、全体最適化は...... リリースフローの改善方針 動作確認が難しい「バーチャル空間内の体験」のE2Eテストを開発 feature flagの自動テストを増やす AWS CodePipelineでリリースフロー自体を最適化する リリースフローの改善結果：サーバーリリース所要時間をほぼ1日→2〜3時間程度に／ツールのセットアップ等のサポートが不要に まとめ clusterの開発とリリースフロー clusterには、AW
Google Cloudを活用した、clusterのデータ収集基盤「Panama」の紹介 - Cluster Tech Blog
メタバースプラットフォーム「cluster」のプラットフォーム事業部インフラチームの佐藤です。 clusterではクリエイターの皆様が創造力を発揮できるよう、またユーザーの皆様がよりclusterでの体験を楽しんで頂けるように日々機能開発、改善を行っています。これらの開発、改善を行う際の指標としてWebやアプリでのユーザーの機能の利用状況などのデータ収集を行っています。 このデータ収集基盤は社内では「Panama」というプロジェクト名で運用されています。 様々な場所で発生した大量のデータが集まり、次にデータを必要とするアナリティクスチームなどに届けるための中継点になれるよう、物流の要所であるパナマ運河にあやかってPanamaという名前がつけられました。 今回はこのデータ収集基盤「Panama」の仕組みについて解説します。 背景とコンセプト Cloud Run tips Pub/Sub Da
技術的負債を返済しつつmocopi対応した話 - Cluster Tech Blog
こんにちは！クラスター社でUnityエンジニアをしているNatsukiです。 今回は、私が担当したmocopi対応というepicについてお話しします。 特に、技術的負債を返済しつつ対応できたのが今回のepicの個人的なハイライトなので、そのことについてお話したいと思います。 mocopi対応とは mocopi対応する上での課題について どのように解決したのか 1. デバイスを表すコンポーネントを抽象化 2. 抽象化したクラスを用いて既存実装をリファクタ 3. トラッカーの具象クラスの1つとしてmocopiを扱う 解決編まとめ 技術的負債を理解し、それを粉砕することを許してくれる環境 mocopi対応とは mocopi対応とは、clusterのVRで(OSCを経由して)mocopiが使えるようにするというepicです。 ただ、VRと一口に言っても、clusterではPCVRとQuestスタン
ProtocolBuffersスキーマ運用の改善: 手動から自動生成への移行 - Cluster Tech Blog
クラスター株式会社でSoftware Engineerをしている thara です。 cluster ではシステム間連携の一部にProtocol Buffers（以下protoと呼称）を使用しています。 protoのスキーマ定義を独立したproto管理リポジトリに配置し、そのスキーマから生成した各プラットフォーム向けのコードを複数のproto利用リポジトリで利用しています。 このprotoスキーマとそれから生成したコードを利用するまでのプロセスは、長い間運用されていましたが、問題を抱えていなかったわけではありません。 開発メンバーも増え、徐々にその問題が無視できなくなってきました。 この記事では、長年行ってきたその運用プロセスを最近改善したので、その事例を共有します。 まず、長年行ってきた「手動でコード自動生成した旧運用」とその課題について述べ、次にどのような運用に改善したかを解説します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Qiita Night～AWS vol.2～」で「Amazon Managed Service for Prometheusへ移行した話」というテーマで登壇・発表しました - Cluster Tech Blog