見出し画像

xR系開発プロジェクトのディレクションtips

こんにちは、お酒大好きです。
実は私、xR系の開発会社でもある株式会社ホロラボの取締役も兼務しております。それもあって、デザイニウムではホロラボと一緒にプロジェクトに取り組むことが多く、これまでプレスリリース出した範囲でも下記のようなプロジェクトをやってきました。

はじめに

今回は、これまでのプロジェクトを通してたくさん失敗を繰り返してきたので、これらxR系の開発プロジェクトにおいて気を付けておくべきことを整理してみました。殆どのプロジェクトが我々としては新しい試みでしたのでその視点、且つクライアントがいる受託での開発についてのまとめになります。

気をつけておくべきポイント

- 事前に全てのリスクを洗い出す
- 検証結果をクライアント含めて必ず共有する
- 出来るだけ早く目に見えるプロトタイプを作る
- 何回ブラッシュアップを回せるかが重要
- とにかくシミュレーションする
- 最後に時間を取れるようにする

1. 事前に全てのリスクを洗い出す

これはどんなプロジェクトでも当然のことなのですが、スタート時点で確証が持てないこと、分からないことはリスクになるため、検証項目として洗い出しが必要です。
特に新しいデバイスを扱うことが多いxR系の開発プロジェクトにおいては、技術面や運用面でリスクが多くあり、それら全てを検証項目としてリストアップし、開発の流れの中でどこでどうやって検証していくのかを計画することが大切です。時には検証だけを一つのフェーズにして契約を分けることもあります。

例えば、TECH LIVEのプロジェクトでは、ステージの環境や当日の衣装など不確定要素が多い中で、演者のポジションや動きを検出する部分について、どれくらいの精度で検出できるのかスタート時点では不明だったため、重点的に検証を行う機会を何度も設けるように、事前にその方策について協議を重ねました。

2. 検証結果をクライアント含めて必ず共有する

個人的にはxR系の開発プロジェクトにおいては、できることよりもできないことを発見していくことが大切だと思ってます。初めてのことが多いプロジェクトにおいて、できないことが出てくるのは当然です。そのため、その「できないこと」が分かった時点で直ぐにクライアントと詳細を共有します。目に見える形でしっかりと検証結果を見せれば、納得してくれない人はいません。これまでの実感としては、例えネガティブな話でも迅速且つ正直に話すことで、より信頼は得られていると思います。ただ重要なのは、その際に考えうる別のプランを全て検討テーブルに乗せて、対策としてどう進めていくかもオファーしていくことです。

例えば、これもTECH LIVEの事例について、別会場での放送用にMachine Learningベースで演者の骨格推定が必要でしたが、カメラの位置や照明の状態ごとに、どういう動きは検出できるか、検出できないかを、フレーム単位で整理しました。どういう状態がNGなのかがわかれば、ステージの演出はそのNGを考慮に入れた上で行うという方針が立てられました。

3. 出来るだけ早く目に見えるプロトタイプを作る

できないことを発見することに加えて、どういう体験になるのかを早く形にして見せることも大切です。頭では想像はできていても、実際にデバイスを用いて体験をしないと分からないことがxR系開発プロジェクトにはたくさんあります。それをいち早く行うためにプロトタイプを作り、体験をすることで、新たな発見ができます。この新たな発見がプロジェクトにとって必要な材料となり、指針となります。

そして、この体験はできるだけ早い時点で行うことが重要になります。頭の中だけで想像を重ねていくと、理想や希望もあり、やりたいことが膨らんでいきます。もちろんこれは良いことではあるのですが、それと現実とのギャップが大きければ大きいほど、それは失望に変わり、プロジェクトに対する満足度は下がってきます。そのため、できるだけ早い段階で現実についても理解してもらうことが必要です。

我々は多くのプロジェクトにおいて、キックオフの時点で何らかのそのプロジェクトのコアになりそうな部分のプロトタイプは準備しておき、できるだけ精度の高い認識合わせをスタート時点から出来るようにしています。

4. 何回ブラッシュアップを回せるかが重要

「体験しないと分からない」ということは、一度プロトタイプを作ってから完成までに何回「体験」をできるかもとても重要になります。毎回の体験において、新たな発見があり、それを踏まえてブラッシュアップ、そしてまた体験、それを繰り返すことでどんどんと洗練されていくと思うので、これを何回繰り返すことができるかが重要になります。(もちろん一度のブラッシュアップの質もとても重要です。) 理想的なのは、全くプロジェクトの経緯が分からない人にも毎回体験してもらうと、実際のユーザの声に近い声も拾えるので、効果的です。

また別の側面としては、目に見える形で完成に近づいていく様子をクライアントと頻繁に共有することで、完成時の認識のズレはなくなりますし、意見やアドバイスを可能な限り取り入れることで満足感にも繋がります。もちろんユーザ体験にネガティブに働く意見などは議論を重ねて弾いていくことも必要ですが、ここできちんと議論することが重要だと思います。

このプロセスを実現するためには、必要な人員を確保すると共に、全体像に対して体験のサイズを限定してでも、数を増やしていきます。例えば、全体の中に要素ABCとあり、Aは1週間、Bは2週間、Cは3週間と開発に掛かるのであれば、Aをまず見せる、次にAB、最後にABC、その間はダミーの仕組みを準備して体験ができるようにするといった工夫が必要です。言い換えると、この要素をどう分けていくかが腕の見せ所かもしれません。

DOCOMO OPEN HOUSE2020のプロジェクトにおいては、全体の体験の中に8個の要素があったため、それらのビジュアルが出来上がるごとに、事前にキャプチャ映像を共有しつつ、対象デバイスであるMagic Leap、iPad、MirageSoloで、どう見えるかを実際に体験してもらい、議論を重ねていきました。

5. とにかくシミュレーションをする

おそらくディレクションする上ではこれが1番重要じゃないでしょうか?日々刻々と完成が目に見えていく中で、常に最終形態をイメージして、それに近づけるために不足していることは何か?この足りないピースを洗い出していく作業、これが重要なのかなと思ってます。

「あれって初見でわかるかな?ビジュアルを足した方がいい?」「もしこの部分のシステムが動作しなかったら?バックアップは?」「運用時に想定以上のお客さんがきたら?」「あのデータってこういう経路で通信されているけど別の経路もありそう?」「もしこの人が風邪をひいたら?」などなど、毎日可能な限りの「もし?」の仮説を立てて、それに対する対策を持っておく、もちろんそれを使わない場合もありますが、そこをどこまで繰り返しておくことができるのかが、プロジェクトが円滑に進むために必要かなと思います。

自分はその日の終わりに、関わっているプロジェクトごとに、実際にユーザに体験してもらっている姿を想像し、各フェーズでどういう動きが必要かを想像しながら、実際の想定との差分を洗い出すことやっています。そうすると、翌日にそれをチームメンバーと共有することで早めに対策が打てるようになります。また、ユーザの体験している姿も毎日アップデートされていくので、よりイメージの精度が上がっていく気もしています。

6. 最後に時間を取れるようにする

プロジェクトには期限が存在しています。そのため、全てが完成した段階で残された時間がどれくらいあるかはとても重要です。ここに至るまでにも体験を繰り返してはいますが、完成された状態での体験はやはり違った見え方がしてきます。それも当然で、これまではまだ未完成だからというバイアスがかかっているので、どうしても評価はあまくなってしまうこともあるからです。そして、その完成状態での体験で出てきた要望や課題をどこまで取り込めるかは、この残された時間がどれくらいあるか次第です。

この時間を確保するために、検証を含めた事前のスケジュール立てはもちろん重要ですし、プロジェクトの過程で体験やシミュレーションを繰り返すことで、最後に出てくること要望や課題をできるだけ少なくする努力も必要です。

またこれまでシミュレーションを重ねてきたことが、そのままテスト項目にもなってくるので、このテストを事前にどれくらい出来ているかも、最後の時間を確保するためには大切です。

編集後記

広報のマリコです!によるxR系のディレクションについてのお話いかがでしたか?普段聞くことが少ない話だと思うのでかなり貴重な記事だったのではないかと思います✨正直どんな風にディレクションしているんだろう?ディレクターの頭の中ではどれだけ色々なことを考えているんだろう?と気になっていたので私も勉強になりました❗やはりこれだけ様々なことを考えているからこそ細やかなフォローが出来ているんですね。そんな秦がディレクションしてきた数々のコンテンツは以下のサイトからもご覧になれますので、是非チェックしてみてくださいね😊

The Designium インタラクティブサイト
遊んで学んで
Facebook
Twitter


この記事が気に入ったらサポートをしてみませんか?