VSCodeで開発環境共通化

GameWithのエンジニアはVSCodeを利用している人が多いのですが、VSCodeの推奨設定を各リポジトリに追加することで、知見の差による障壁を減らすという試みについての発表でした。

気をつけたこととしては

既存のコードや環境は尊重する。強制ではなく推奨。
新メンバーも早く環境に馴染めるようにする。
大きな変更は避けて、小さくコツコツと。

ということでした。

現在は各自で .vscode/setting.json を定義している背景もあり、リポジトリに .vscode/setting.example.json を追加しています。こちらは任意で .vscode/setting.json に取り込んでいただければとのことです。

さらに .vscode/extensions.json を追加しています。こちらではリポジトリの技術的に推奨される拡張機能が入っていて、VSCodeを利用していた場合これらの拡張を一括でインストールできます。

今後は .vscode/tasks.json で開発コマンドをいい感じに管理したり、 .vscode/settings.json 自体をpushできないかを検討したいとのことでした。

共通化は目指しつつ縛りすぎない絶妙な塩梅で、エンジニアに嬉しい環境が整っているのが実感できています！

動画投稿機能の構築

現在GameWithで開発しているAIM練習ソフトにはリプレイを動画として保存し、後から見返せる機能が実装予定となっています。

リプレイ動画自体はUnityのアセットを用いてmp4として録画できるのですが、表示までのロードが長くなってしまいます。

ロード改善のため、動画をストリーミング形式に変換する機構を作成したという内容の発表でした。

詳しい構成図は下記の通りです。

2点詳しい話がありましたので、こちらでもご紹介します。

1 録画された動画データのアップロードについて

いつでもアップロードを許容してしまうと関係の無いデータをアップロードされてしまう可能性があるので、ワンタイムで利用可能なAPIのURLを発行し、そのAPIに対してアップロードを行います。

OSはAmazonLinux2を利用していましたが、サポート期間が2025/6/30までのため、近々AmazonLinux2023に移行予定のことです。

2 S3に保存された動画データのコンバートについて

ffmpegを用いてHLS形式にコンバートします。

コンバート自体はElemental MediaConverterを用いて行う事も可能ですが、料金が大幅に高くなる試算であったため、ffmpegを利用しています。

arm版のバイナリも用意されているので、Lambdaはarm料金を適用させて費用を抑えることができたそうです。

AIM練習ソフトでは変換したHLSファイルを用いてストリーミング再生を行うようにし、ユーザー体験の向上に成功したそうです。

AIM練習ソフトについての具体的なお話はまだできませんが鋭意制作中です！お楽しみに！

slackのワークフローを使って業務改善

GameWithの数値分析チームはSlackのチャンネルを通じて他部署からの依頼や質問に対応しています。ですが、案件が重なると管理が難しくなる問題が発生していました。この問題に対処するため、Slackのワークフローを使って業務改善をした、ということについての発表でした。

課題としては以下のようなことがありました。

案件の重複と追跡の難しさ： 依頼が多くなると、進行中の案件の状態やSlackでの依頼元のスレッドの位置が分かりにくくなっていました。
作業前の相談と時間経過： 初期相談後、実際の作業までに時間がかかる場合があり、その間の状況管理が難しい状況でした。
ステータスと時間の管理： 各案件の状況やかかった時間の管理が課題でした。

課題に対して、GitHubのIssue管理を一旦検討しましたが、以下の問題がありました。

依頼内容の統一性の欠如
SlackとGitHubの情報の重複
複数リポジトリへの対応(Issueが分散する)
他部署にGitHub利用を意識させてしまう

上記の問題のため、案件が依頼されるSlack上にワークフローを導入することにしました。

導入した結果、以下の利点が得られました。

依頼内容の明確化： 依頼時に詳細な項目を設定することで、必要な情報が事前に集まります。
ステータス管理の容易化： ステータス管理がスプレッドシートで行えるようになり、効率化が図られました。
時間管理の改善： Slack上での反応時間をスプレッドシートで記録し、分析が可能になりました。

一方導入した結果の課題ですが、まずSlackワークフロー自体の反応速度が遅いです(使ってみると分かる)。また、開発などを行う必要がある場合、GithubのIssueを作成してというフローを取るのですが、この時にIssueに何を記載するか？リンクだけでいいのか？など結局情報が分散してしまう問題もまだあります。

今後の展望としては、Slackワークフローは確かに他部署との窓口としては非常に有効ですが、開発部内の作業管理にはGitHubのIssueが適している可能性があります。SlackからGitHubへの自動連携機能の利用や、問い合わせ専用のリポジトリ作成も検討できそう、とのことでした！