こんにちは！

AnotherBall モバイルチームのDavideです。AnotherBallでは、私を含めて多くのクライアントエンジニアがネイティブチームに加わる前に、ゲーム業界での経験を積んでいます。

今回は、バックグラウンドの異なるメンバーが集まったチームが何をもたらすのか――その摩擦と利点、そしてAIがどのようにギャップを埋めるのかについてお話ししたいと思います。

解くべき問題の違い

そもそもエンジニアというのは、問題を解くのが好きな人たちです。しかし、多くのエンジニアが集まると、自然と「自分が一番気になる問題」に手が伸びていきます。
これは、ゲーム開発のように異なるバックグラウンドを持つメンバーがいる場合、特に顕著です。ゲームとモバイルアプリは同じ端末で動くものですが、エンジニアの意識を引っ張る方向はかなり違います:

• 伝統的に、ゲームは「体験を作ること」を目指し、アプリは「タスクを効率的に終わらせること」を目指してきました。
• 多くのゲーム――特にストーリー重視のものや競技性の高いものは、ユーザーが集中し続けることを前提に設計されていますが、ほとんどのアプリは通知やバックグラウンド、ディープリンク、中断とともに存在しています。
• クラシックなコンソールやPCタイトルは一度きり、あるいは大きなアップデートでリリースされますが、モバイルアプリやライブサービス型のゲームは継続的にリリースされていきます。

実際には境界線は曖昧ですが、それでも一見すると違いはたくさんあります！

Avvyはハイブリッド

私たちが開発している Avvy は、誰でも1分でVTuberになれるモバイルアプリです。以前の記事でも書いたように、このアプリはゲームとコミュニティアプリの境目に位置しています。つまりユーザーは、ソーシャルネットワークのような洗練された体験と、ゲームのようなエンゲージメントやパフォーマンスを同時に期待しているということです。

両方の世界にまたがるものを作るということは、どちらか一方の考え方だけに寄りかかれないということです。配信体験はゲームのように生き生きとしている必要があり、それ以外の部分は他のソーシャルアプリと同じくらい馴染みのある作りでないといけません。どちらもおろそかにできません。

バックグラウンドが違うことの強み

バックグラウンドが違うと、同じ問題に対しても違う直感が働きます。ゲーム開発者とモバイルエンジニアが同じ画面を見ても、目に入ってくるものはまったく違うことがあります――そしてAvvyのようなハイブリッドプロダクトでは、まさにそれが私たちの欲しいものです。

良い例として、Avvy体験の中核を担う、リアルタイムのフェイストラッキングを支えるパイプラインがあります。端末のカメラがユーザーの顔の動きをリアルタイムでキャプチャし、Unityに送ってアバターを動かす仕組みです。カメラとUnityは別々のフレームワークに存在するため両者の通信は遅くなりがちですが、アバターが生き生きと感じられるためには、データを安定した60fpsでUnityに届ける必要があります。

Androidでは、標準的なネイティブからUnityへのブリッジが1フレームあたり3 msかかっていました。16.6 msのフレームバジェットのうち約20%を占める計算で、これは没入感を壊すには十分なレベルです。ゲーム開発のバックグラウンドを持つ私は、Androidではメモリマップドファイル、iOSでは生のポインタに手を伸ばすのが自然でした。結果は明確でした:

ちなみに、このパイプラインはとても面白いトピックで、別の記事を書く価値があります。近いうちにまとめたいと思います！

AIがギャップを埋める

これが数年前よりもうまく機能するようになった理由はAIです。ゲームからネイティブへの移行はかつて、新しい言語・新しいフレームワーク・新しい慣習という険しい道のりでした。今では、AIが機械的な翻訳の部分を引き受けてくれるので、アーキテクチャやベストプラクティスといった本質的な部分に集中できます。

例えば、Avvyのライブ配信中のエールポイントカウンターを実装したときのこと。私たちのイメージははっきりしていました――サーバーイベントに応じて、オドメーターのように数字がロールし、スクワッシュ・アンド・ストレッチするような動きです。Claude Codeに渡したプロンプトはこちらです:

Disneyの12のアニメーション原則(スクワッシュ・アンド・ストレッチ)を使い、Textをオドメーター風にアニメーションさせて。

この語彙はゲーム開発における基本中の基本です。Disneyの12のアニメーション原則（スクワッシュ・アンド・ストレッチ、アンティシペーション、フォロースルーなどを含む、動きに関する古典的なルール）も、ゲーム開発者なら馴染みのあるものです。

Claude Codeはほぼ一発でSwiftUIのコードに翻訳してくれました。スクワッシュ・アンド・ストレッチは、下端を基点とした縦方向のスケール変形をバウンス系のスプリングでアニメーションさせる形で実装されていました:

1
2
3
4
5
6
7
8
9
10

Text(String(character))
    .offset(y: offsetY)
    .scaleEffect(x: 1, y: scaleY, anchor: .bottom)
    .opacity(opacity)

withAnimation(.spring(duration: 0.6, bounce: 0.5).delay(delay)) {
    offsetY = 0
    scaleY = 1.0
    opacity = 1.0
}

オドメーター的な雰囲気は、各文字を少しずつずらして順番にアニメーションさせることで生まれていました:

1
2

let delay = Double(index) * staggerDelay
withAnimation(.spring(duration: 0.6, bounce: 0.5).delay(delay)) { ... }

数時間の調整とパラメータのチューニングを経て、アニメーションは完成しました。AIなしだったら、まずSwiftUIのアニメーションドキュメントを半日かけて読むところから始まっていたと思います。

まとめ

バックグラウンドの違いはチームに独自のダイナミクスを生み出しますが、最終的にはチームがより広く問題をカバーできるようにしてくれます。Avvyのようなプロダクトでは特にそうです。そして実際のところ、AIは私たち一人ひとりが持ち込むものを置き換えるものではありません――それは増幅装置のように働き、ドメインを横断する際の摩擦を減らしてくれます。残るのは、AIには任せられない部分――人間の感性、判断力、細部へのこだわり、そして「なんとなくおかしい」と感じたときにそれを掘り下げる姿勢です。

私個人にとっては、ゲームからネイティブへ移った理由は二つに集約されます。ひとつは、もっと頻繁にリリースして実際のユーザーと一緒にイテレートしたかったこと――ゲームではリリースサイクルが数年単位になることも珍しくなく、なかなかできないことです。もうひとつは、新しい挑戦をしてみたかったから（もちろんゲーム作りは今でも大好きですが！）。意外だったのは、思っていた以上に多くのことが持ち越せたという点です。特定のスタック固有のテクニックよりも、しっかりとした原則のほうが長く効きますし、丁寧に使えばAIがその間のギャップを埋めてくれます。経験の幅を広げるかどうか迷っている方がいるなら、今はその一歩を踏み出すには絶好のタイミングだと思います。

We’re Hiring

AnotherBallでは、Swift・Kotlin・Unity・AIを活用したアプリ開発に興味のあるクライアントエンジニアを募集しています。技術力に加えて、細部への注意・好奇心・強いオーナーシップは、AI時代のエンジニアにとってますます重要なスキルになっています。共感していただけたら、ぜひ一度お話ししましょう！

AnotherBall採用情報