Ques#8 VR元年、QAしようゼッ! 感想とメモ
第8回Quesのレポ
イベント告知ページ 第8回Ques #ques8 : ATND
今回のテーマは「VR元年、QAしようゼッ!」ということで、VRサービスのテストや品質について。
発表は3本立てでした
- はじめてのVRQA
- Pepperアプリケーション開発で気をつけるべきこと
- GRID VRICK VRインタラクティブコンテンツ開発の話
先に感想を
ヘッドマウントディスプレイ(以下HMD)などのハードウェアも含めた品質保証をするにあたって、どんなところを大事にするか(どんなところを検証するか)、がとても興味深かった。
これから普及してくるであろうサービスなので、これにともなう「品質」も何をもってOKとしたらいいかを自分たちで考えていくところから始まっていて、産みの苦しみはあるのだろうけれど、QAとしては「俺達が作る!」みたいな意気込みになっているんだろうなと推測。楽しそうだ!
Pepperと「人工知能・機械学習」あたりは親和性が高そうだし、GRID VRICKのように「リアルと仮想が一緒になる」ようなサービスも面白い。これがどんなサービスになりそうかはイメージできていないのですが、まず最初の感情として「楽しい!」って思えるのが大事なんだろうな。
以下、資料がアップされるかもしれないけれど、私のメモと感想。 スライドすべてはメモれなかったので、私が気になったところだけ。 スライドの内容と私の感想を一緒に書いてしまいましたすみません。。。
発表1:はじめてのVRQA
グリー株式会社 WrightFlyerStudios事業本部
大塚 直英様
VRQAは非機能テストが重要
- VR酔い
- どのように解決するか、がキモ
- 実際のカラダと、感覚のズレが不快感=酔いになる
- ズレがどこで発生するかをみつける作業
- 各画面ごとのズレを主観で3段階で評価(n=10人以上)
- その結果をどう判断するか、は悩みどころ(例:8人中2人が「ちょっと酔う」)
- 対応例:1人称視点から3人称視点に変更する
- (VR体験者が少ない時代で、VR酔いを体験すると二度とVRに触れない、という状況は作りたくなかった。カジュアルVRというコンセプトがあった)
- 一方で3人称視点はVRならではの体験が減る
- ユーザーが求めているのはVRならではの体験。1人称視点
この後も「VR酔い」がフォーカスされていて、こんなところがポイントになるのかと思ったです。これを評価する方法も「複数の主観でテスト、数字で表現する」というやりかたなのですね。
VR酔いをどうテストしたか
- 要因
- 移動、加速、減速、音声の発生源、遅延、視野角など
- Oculusベストプラクティス、ってのがあるらしい
- 種類
- 吐き気、頭痛、目が疲れる、めまい
- SimulatorSickness Questionaire が参考になる
VR酔いのテスト項目
- オープニングでの酔いの有無
- 画面Aでの酔いの有無
など、それぞれの画面(およびそこで起こるアクション?)で、「酔いチェック」するらしい。
わかりやすさ
VR最大の問題 → 手元が見えない
- 手による入力操作の難易度があがる(キーボードからの入力はまず無理)
- ゲームパッドがギリギリ
- 視線で操作させる(一点を見つめると選択される)方法はある
- 説明書・攻略サイトがみえない
- プレイヤーが見ている方向で条件が変わる
- その時の向きによって、「右を向け」みたいな指示ができない。
- 対策
- 説明文を表示させる
- ゲームの演出として視線を誘導する(蝶を飛ばして、そこに視線を移動することで次の操作を教えてくれる)
わかりやすさのテスト項目
- ゲームの目的が理解できるか
- 次に何をすれば良いかわかるか
を判断するために、テスターにテストプレイしてもらう
プレイ時間
- プレイ時間が長いと疲れる
- テストすると疲れる
- 5分を超えるとつかれる、という声が出る
- 2~5分が今のところ良さそう
- 画面の切り替わりが早いと目が疲れるという意見も
- MenuやLoadingの画面、表示
- Loadingが早過ぎる(すぐ出てすぐ消える)と逆に疲れる
VR特有の機能テストが、品質特性ごとに分けられてました。
@HelloTakuyaさんのツイート
VRの機能試験 #ques8 pic.twitter.com/ljGcqtTwrI
— Takuya (@HelloTakuya) May 27, 2016
テストする環境
機材確保
- テスターの大量投入ができなかった
→ 少人数を、テスト期間長めで実施することで対応
人材の確保
- VRテスト人材で一番注意しなければならないこと → メガネ
- 必要な人材像
テストツール
- 画面キャプチャ機能は必ず用意する!
- HMDを装着したままキャプチャできるといい
- 不具合が発生したときの画面を撮るのは必須
- FPS表示機能 (flame per secconds)
- フレームがリアルタイムに表示されるような機能
- あとで見返せるようにFPSロガーがあるといい(どこでフレーム落ちが発生したか)
こゆの面白い。
今後のVRQA
VR酔いの評価方法
- どこまで許容できるか
- 定量的に判定できるか
テストする環境
- テストスペース確保
- 今後はネットワーク対応 ←そのテストを行うための人数
- イベントなどでの使用を想定したテスト
- イベント期間中の長時間動作
- デモ用のオペレーションの用意
テスト支援ツール
- HMDを装着したままバグ報告を行える機能があるとサイバー
サイバーすごいw HMD外さずにバグチケット起票できるとかね。そんなテスターが数十人いたとして、その場を見学してみたい。
まとめ
- 酔い対策 vs VRならではの体験
- 人材、機材の用意も入念に
- VRQAはまだまだ発展段階
Q&A
Q: テスターの規模は? A: 東京ゲームショウに出したのは2名で一ヶ月。製品レベルだとこれの2,3倍か
Q: エイジングのテスト(発熱とか) A: 本格的にはやってない。夜中動かしっぱなしで大丈夫か、くらい。イベント対応で8時間連続動作は担保した
発表2: Pepperアプリケーション開発で気をつけるべきこと
株式会社ネクスト HOME’S事業本部 業務支援推進部
流通ネットワークユニット
上津原 一利様
Pepperについて
人型のコミュニケーションインターフェースである。
ロボット、というといろんなことができそうな気がしちゃう。
部位 | 役割 |
---|---|
頭脳 | クラウド |
目 | デプスセンサー、カメラ |
手、頭、足元 | タッチセンサー |
胸 | タブレット アンドロイド |
耳 | 頭部マイク |
口 | 耳スピーカー |
勝手に話しかけてくる、タッチセンサー付Siriとのことw
「ユーザーが思うPepper」と開発者のギャップ
実際はロボットじゃなく、先行者
- 脳になるクラウドは公開されていない
- 都合のいい機能は無い
- コミュニケーションのシナリオも自分で作る
ユーザーは「Pepperは自分で考えている」と思っている。このギャップ。
ユーザーが期待する体験のレベルは非常に高い
↓
頑張ったけどがっかりなコンテンツになる
これをいかにすり合わせていくか、期待に答えるようにするかが課題
ロボットコンテンツの体験づくり
- 体験ストーリー
- ストーリーに必要なコンテンツ(タブレットUI、アニメーション)
- 実際に実行
- 改善を繰り返す
特有なのは「会話をする」
いろいろ省きながらユーザーを誘導する
大事なのは、最後まで体験してもらうこと
Pepperはコミュニケーションがメイン。コミュニケーションができなければ人はすぐ離れる。だからこそストーリーが大事。
円滑に話をする。話を面白くする。最後までコミュニケーションする。
QA時に考えるべきこと
- どういう場所?
- 状況に合わせた対応。銀行?家電屋さん?
- 屋外はNG
- Pepperの役割は?
- メイン?アシスタント?
- 途中で止まることもある。音声認識できないこともある
- アシスタントとして使うのがオススメ
- どんな人がくるのか?
- 大人、子供、ビジネス
- 子どもと大人で、話しかける位置が違う
- 子供は本気で殴る
- どんなものならユーザーは喜ぶのか?
- 面白い?ためになる?
- ユーザーが何を手に入れたら成功なのか?
- 好印象?商品購入?
- ユーザーの抱いているPepper像は?
- かわいい?カッコイイ?賢い?
- どんなPepperなら受け入れられるのか
- 声が変わるとユーザーは驚く(声色が変わる、しゃべり方が変わる)
- 途中でユーザーが諦めないか?
- 問いかけは正しいか?
- Pepperにしゃべりかけたいと思えるか
↑主観、だけど、コミュニケーションインターフェースなので、ここ大事。
- 肯定の選択肢
- はい、うん、そうだね、そうだよ、イエス、おっけー、いいよ、、
- 否定の選択肢
- いいえ、ちがう、だめ、嫌い、やだ、いらない、、、
など、判別しやすい回答が返ってくるような質問をするようにプログラムしておく。
展示場の例
住宅展示場のイベントスケジュールを話すだけ。要件は満たしたがユーザーはがっかり。→その場で、ユーザーが話しかけてくる単語に反応するようにした
「こんにちわ」「かわいい」「おはよう」など。
ひとこと返事して、スケジュールをアナウンスするとウケるようになって、コンテンツも読んでくれるようになった。
よりよいロボットコンテンツへ
- Pepperというだけで受けるのは今だけ
- キャラクターと立場が活きる
- コンテンツづくりが大事
Pepper(ロボット)だから許せる、かわいい、おもしろい、わかりやすい
人が聞いても答えてくれないけど、Pepperが聞くと話せちゃう。 それを収集する→ビジネスに活かす
↑確かにこれ、今のGoogleだって「知らない間に情報を取られている」ことを考えると、こういう手段での情報収集って熱いよなと思いました。これをPepperにやられると、、、なんだろう、へんな気持ちw
クオリティ=コミュニケーションデザインが問題なくできているか?
アニメーションがしょぼいとかはいい、コミュニケーションがおもしろいか
がキモ
発表3: GRID VRICK VRインタラクティブコンテンツ開発の話
株式会社ネクスト グループ経営戦略部 R&Dユニット
リッテルラボラトリーグループ
上野 哲史様
GRID VRICKのデモムービー
レゴで部屋を作ると、VRになる レゴをOpenCVで解析、UNREALでCGにしている
大事なこと
- 家造りの楽しさ
現実と同じリアリティ
楽しい体験、わかりやすい操作
- 画像解析
- リアルでインタラクティブな3Dコンテンツ
- (余談)エンジンとの戦い
楽しい体験・わかりやすい操作
- 3Dコンテンツ作成の課題
- 作るのが大変 → ブロックで簡単組み立て
- 知識が必要 → ブロックで直感的
- 一人しか操作できない → 何人でも
- 作業つらい → 触れてたのしい
ブロックとタッチディスプレイで解決!
VRの課題
- VRだとHMDしてる人しか楽しめない
- →ブロックの配置をリアルタイム反映。VRの内外で一緒に楽しめる
- 操作が難しい
- →操作を分割
- ブロック:家の構造作成
- PC画面:インテリア変更
- VR:ウォークスルー
- →操作を分割
- 様々な場所でのテストと改善
- 社内、イベント出典
- 学会、勉強会
- ユーザーの行動を観察(Occuralしながらブロック並べるとかw
- 筐体の形も改善。
画像解析
課題
- 照明環境への対応
- 影の影響
- 認識物(ブロック)以外の除外
→ブロックの色判定
対策
- キャリブレーション用のブロックを配置
- 照明安定用ライト(真上から当てると反射するので角度を持たせる)
リアルでインタラクティブな3Dコンテンツ
数人で開発。経験も少ない
パフォーマンスとの戦い
課題
- 照明が増える(太陽光、反射光、照明、、)と重い
- インタラクティブなもの→さらに重い(リアルタイムに変更する
対策:現実とは異なるが、リアルに見えるように
- 天井ライトを互いに被らないように設置
- 画面外、今いる部屋以外のライト無効化
- 反射光を下からのライトで擬似表現
- 全体光
現実の写真と見比べると違うところはある。が不自然と感じなければOK
パフォーマンス
- モデルのポリゴン削減
- オブジェクト数減らす
VRへの対応(これから)
- インタラクティブ性を重視した、ある程度のクオリティのコンテンツ
- クオリティを重視した静的コンテンツ
- そろそろ発売されるGTX1080(グラボ)に期待w
エンジンとの戦い
オブジェクトをたくさん置くと、、、オブジェクトが光るw
- エンジン側のバグ。半年後に直った。
コンパイルすると関数名が戻る
- 原因不明
- 設定ファイルで回避
テスト、QAの話
課題
- UXはトラディッショナルなテスト技術では評価が難しい
- ユーザーの「どの感覚」を計測するのかの検討が大事
- ハードウェアリソース使用量など、性能評価(合否基準の設定など)が難しい
まとめ
- アナログ多し
- 体験の質の向上は、様々な人の反応から
- 3Dコンテンツのクオリティは「リアルに見える」ように作成
- 現実と同じ構造では作っていない(省いても不自然に感じないものは無くす)