はじめまして、4月からクラスター株式会社でSoftware Engineerをしている獏星(ばくすたー)です！
この記事では入社後3ヵ月目のエンジニア目線から、clusterでVR向けの機能・インターフェースを開発してリリースに至るまでについて、実際の開発事例をもとに紹介します。
開発過程でのメンバーとのコミュニケーションや、VR向けの機能・インターフェース開発のつまづきどころと工夫に着目した記事となっています。とくにクライアントの開発経験があるけれどVRの開発経験がまだない方や、プライベートでのVR開発経験があるものの業務として働くイメージがつかめていない方の参考になれば幸いです。
(※VRの技術詳細については軽い説明に留めています)
この記事は以前 @kurain さんが紹介した「epicという開発フロー」を踏まえた実践事例にもなっています。本記事でもepicの用語を多少使うため、未読の方はこちらの記事をぜひご覧ください！
開発事例：VR版でワールド内でもキャリブレーションできる
今回取り上げる開発事例を紹介します。
私が入社後はじめてepic owner、つまりリリースを推し進める主担当エンジニアとして携わったのは「VR版でワールド内でもキャリブレーションできる」という機能です。
clusterではキャリブレーションといって、ユーザーとアバターとの体格・体型の違いを考慮して、アバターがきれいに動くように姿勢情報をマッピングする処理が入っています。
この機能が入るまでは、clusterをVRで遊ぶ際にはアプリの開始後に1回だけキャリブレーション操作を行う仕様だったため、アバターの動きに違和感があるとき再調整が難しい、という課題がありました。この課題を解決するため、キャリブレーションをいつでもやり直せるよう改善したのが「VR版でワールド内でもキャリブレーションできる」機能です。
以下では同機能の開発フローのなかで、とくに要件チェック～開発の部分を掘り下げて紹介していきます。
要件チェック + 設計：やること、やらないこと
epicにかかわるための第一歩は要件の理解です。プロダクトマネージャー(PdM)との会話やロードマップ、Product Requirement Document (PRD)を通じて要件を把握したり、必要であれば話し合って要件を調整します。
この段階でのポイントとして、clusterではPRDとdesign doc(この記事で紹介している設計文書)の両方のテンプレートでやらないことの項目が盛り込まれており、スコープの合意形成がやりやすくなっています。
具体例を一つあげます。このepicに関連して、Unityエンジニアどうしの共通認識で「将来Unityのシーン構成を見直すことでキャリブレーション機能を含むアプリケーション全体を保守しやすくなる」というリファクタリングの見通しがありました。また、このリファクタリングはメリットと引き換えに実装がかなり大変で、影響範囲が大きいことも共通理解になっていました。
こうした前提に基づいて今すぐには取り組まないこと、つまりやらないことが規定できるので、要件の合意時に「それは将来これこれをやると解決する問題だから、今やらない」などと優先度が作れます。その結果、機能の盛り込みすぎを防いで本来やりたい機能のリリースを高速化しています。
また要件チェックと合わせて、設計でもdesign docを通じて変更することと変更しない(してはいけない)ことをエンジニア間でレビューしています。こちらでは作りすぎ(オーバーエンジニアリング)を避けることでリリースが素早くなるメリットがあります。
キャリブレーション機能の場合で言うと、ユーザー・アバターの体格データを扱うにあたって「いまの時点ではユーザーの身長や骨格をどう扱っているのか」を確認し、「ここの計算だけ直せば他は今のまま動くはず」という形で情報を整理しました。
開発 + イテレーション：VR開発で起きやすい問題とアプローチ
要件の合意とdesign docレビューが完了したらepicをkick-offして本開発のスタートです！
…が、VR向け開発はここからが本番でした。というのも、VRのUIは通常のUIに比べ、2次元的にプロトタイピングしたデザインが正解ではない事があるからです。
ここではキャリブレーション専用空間のUIに注目して掘り下げていきます。
VRの開発において、2次元的なプロトタイピング時点で把握しにくいポイントはいくつか挙げられます。その例として、VR空間内でのインターフェースの視認性、アクセス性のほか、アバターの違い、体格の違いに依存すること、ユーザーの遊び方(立っているのか、座っているのか)などがあります。
一例として、初期のUIデザインでは以下のような課題がありました。
- 横方向に細長い平面のUIはユーザーから遠すぎ・見えにくい・触りにくい
- 白服のアバターを使っていると、鏡面との組み合わせでUIが視認しづらい
こうしたUIの課題は事前検出がやや難しく、「動いている所を見て初めてわかる / いざ触ってみたら不便」という例です。
このようなとき、具体的な問題に気づいた場合はその時点で
- (事象) 何が起こっているのか
- (所感) 不便になっている場合、具体的に何に困っているか
- (原因) なぜそうなっているのか
- (提案) どうすると良くなりそうか
を、デザイナーに伝えていました。
こうしたコミュニケーションはVR以外でも基本ではありますが、デザインプロトタイプの正解率が下がり、手触りの共有も一筋縄では行かないVRにおいては特に重要です。
※これは社内での共通見解というよりも私の個人的な心得ですが、デザインの各論に精通しないエンジニアであってもニールセンのユーザビリティ原則のような原則やその具体例を抑えておくと、VRも含めたデザインの改善提案に役立ちます。ユーザビリティ原則にはスマホなどの平面UIデザイン以外でも通じる普遍性の高い表現になった記述が多く、参考になります。
情報共有の手段も重要です。エンジニア自身が不便だと感じたとき、文書、スクリーンショット、動画だけでそのことを共有するのはVR開発では不十分な事が多いです。動くアプリはここで大いに活躍する存在です。アジャイル原則に通じるものがありますね。
今回の開発ではUIを調整した開発用ビルドをデザイナーやPdMに1日1回～2回程度のペースで共有し、「これは前回に比べて良さそうか？」という検討を重ねやすいようにしていました。
とはいえ、この「1日1～2回」というペースも仕様改善のスピード感としては不十分でした。
(※1日2回という制限は実装時間に加え、CIを活用してもUnityアプリのビルドに時間がかかる事に由来します。これについては「ビルドパイプライン改善委員会」という面白い話題があるので、続報にご期待下さい！)
そこで、単にビルドの共有頻度を確保するだけでなく、次のような工夫でやりとりを効率化していました。
- UIの位置を微調整できるデバッグ機能を追加し、デザイナーから調整したパラメータを教えてもらう
- ひとつのビルドに、複数パターンのUI案を同梱して差し替えられるようにする
ちなみに、このやりとりは結局デザイナーに開発中ブランチを取得し、Unityエディタを直接見てもらう方法に着地しました。
これはスピードの重要性が合意されていた事、デバッグ機能を作るにも工数がかかる事、デザイナー側でもGitが扱えて開発環境にアクセスできたことなどの背景から実現した体制です。
clusterでは開発メンバーの作業分担の観点から、ふだんUIのデザイン作業をfigmaだけで完結できるようになっています。当初はこの分担意識が強く、デザイナーにUnity環境を整備してもらうのは申し訳ないと思っていました。しかし、最終的には分担にこだわりすぎず、最適な方法を選べた点でよいプラクティスだったと考えています。
ここまでで述べたように、VRの機能開発ではデザイナーとのコミュニケーションが極めて多く、デザインの着地点を探るうえで二人三脚で進むような形でした。繰り返しますが、VRでは動いている所を見て初めてわかることが非常に多いです。この意味ではエンジニアは単に機能を作る人ではなく、デザイナーに(エンジニア自身の所感も含めた)インプットを共有してデザインをアシストする立場である、とも言えます。
以上のようなデザイナーとの高速のイテレーションを中心として、PdMからも手触りについて何度もフィードバックを貰っています。例えばデザイン調整の終盤では、「側面にも鏡を据え付けた三面鏡のようなレイアウトは使いやすいか？」というのを検討し、良い点と悪い点についての意見を共有してもらっています。
このほかにもリリース前のバグバッシュ(bug bash)などで社内メンバーに機能を見てもらったうえで、テストケースレビュー、コードフリーズ、QAを経てリリースに至っています。
なお、最終的なUIはこのような形に落ち着きました。初期のデザインから大
幅に変わっているのが分かります。
やってみた感想
epic ownerとして一連のVR開発に携わった感想を3つ書いていきます。
まず、チームのVR開発においてepic ownerは実働の中心にありますが、独力で何でもやるというより、デザイナー/エンジニア/PdMを含む周囲とのコミュニケーションが重要な役割であると実感できました。ここまでで開発の流れを紹介してきたように、一発でよいVRインターフェースを作るのは難しいので、チームとして謙虚にノウハウを積んでいく、という姿勢が大切になってきます。このような積み重ねが好きな人なら、どの職種であってもVR開発に前向きに取り組めると思います。
また、その延長として「さらに人に頼る機会を多く持つと良かったかも」というのは次への学びになっています。clusterでは「作成中の機能やワールドを社内で触れる会」が不定期で開催されており、いわゆるVR原住民の人々も含めた多方面から意見が得られるグッドプラクティスになっています。今後は開発のイテレーションに組み込む形で、そのような機会をもっと活用したいと思いました。
最後に、これは本当に個人的な感想ですが、キャリブレーション機能はメタバースのサービスにおける重要機能なため、今回の開発は緊張感と達成感の双方が感じられる開発となりました。今後も色々と改善のしがいがある機能なので、また機会があれば学びを活かし、より良いものにしたいです。
おわりに
今回は仕事におけるVRの機能開発がどのようなものかを事例ベースで紹介しました。
VR開発は各所でノウハウが増えているとはいえ、機能開発そのもの、プロトタイピング、インターフェースデザインなどで課題の多い領域です。しかし、そこが奥深く、地力を活かしてぶつかっていける理由にもなっています。私自身、今回のような「コミュニケーションをとってモノを良くしていく」とか、原理原則に立ち返る機会が多くなる点で業務でのVR開発が好きです。
マルチプラットフォームに展開しているclusterの開発のなかでも、特にイメージしづらいであろうVRの開発風景が伝わっていれば嬉しい限りです。
ClusterではVRをはじめ、各プラットフォーム開発で活躍したいエンジニアを募集しています。この記事を読んで「仕事でVR開発をやってみたい」と思った方、それ以外でもどんな開発領域があるのか気になった方はぜひこちらもご覧下さい！
