見出し画像

設計コンペでVRシステムの作成を要求されたときの論点&問題点まとめ~丸亀市の事例より

このnoteは、丸亀市が行っている「丸亀市(仮称)みんなの劇場基本設計・実施設計業務委託」の公募型プロポーザルにおいて、設計業務の一環として求められたVRシステムの作成について、問題点と論点を整理しています。

こうしたケーススタディをしながら、

今後も見据えてさまざまな設計コンペでVRシステムの作成と提出が用いられたときに「どういうことを検討すればよいのか?」「どういう解決策があるか?」をまとめています。

資料や図版はこちらから引用しています。

コンペの概要とこのnoteの基本的な考え方

丸亀市の劇場のコンペでは、基本設計、実施設計において、業務の一環として模型や透視図の提出に加え、VRを用いた設計ツールの作成と提出が求められています。

画像1

基本設計と実施設計でVRシステムの作成と提出が求められています。

基本設計要件

下のは実施設計の要求。

実施設計要件

このnoteでは、この仕様書を細かく読んで問題点を整理しつつ、プロポーザル内での解決案を提示します。

細かい仕様書は以下です。

vrsiyousho1_ページ_1

vrsiyousho1_ページ_2

vrsiyousho1_ページ_3

こうしたVRの活用を設計で行うのは、行政が行う取り組みとして、とっても面白いと思うし、価値があると思います。それでも、これが設計業務に入ってくれば大変なことは間違いありません。

Twitterでは、「設計者の負担が増すよ~つらいよ~ぴえん」みたいな反応が書いてありました。でもよく読むと、このVRプログラムの要件がそんな軽いレベルを超えてとっても厳しいかんじなんですね。

もしこれを何も考えずに受けたら設計者の方はとんでもないことになるかもしれないと思うので、そのことについて少し書きたいと思います。うっかり契約不履行とかいって揉めたりしても最悪だと思う。

僕は、東京大学大学院で建築設計を学びつつ、設計でいかにVRやMRを使えるか?という研究をしています。

VRやMRの開発も自分で行って研究を進めていて、研究成果では大学院で賞をとったり全文査読の論文を通したりもしました。また、システム会社で仕事もしています。

研究をしている身からしても、僕は行政や建築設計においてVRやMRを活用する流れに対してもいいなとおもっています。

ですが、逆に黎明期だからこそ設計者と施主の間で揉めたりすれば「VRってまじでめんどいし設計者の業務のさらなる追加でしかない」と思われる可能性もあると感じています。

なので僕は、この丸亀市の要項を断罪したいのでもなく、ただこのnoteでは、要項を読みながら、システム開発などの観点から問題点とリスクのポイントを整理しつつ追っていけたらと思っています。

設計者の方には、今後VRを求められることも見据えつつ、リスク管理の参考にしてもらえればと思っています。

3つの問題点

この要項は、ちょっと問題のあるように思える箇所が大きく分けて3つあります。

まず一つ目は、「そもそもVRの概念が多くの人が思っているVRではない可能性があること」。

2つ目は、「機能を実装することとユーザーが使えるプログラムを作成することが根本的に違う作業だということがあまり意識されていないように感じること」。

3つ目は、「VRのアプリの構築要件が明らかに今回の利用想定と合っていないように思えること」です。

要項を順番に読みながら問題点について確認していきます。

問題点①:VRの概念についてのミスリードの可能性

はじめに、要項を上から順番に読んでいきます。

VR仕様書では、まずVRシステム作成の業務目的が書かれています。

画像5

ここは特に問題ないと思われます。VRを活用していくのは素晴らしいことだと思うし可能性も広がると思う。行政の取り組みとしては価値があることだと思っています。

ただ、VRシステムの追加更新が想定されているとあって、ここがやや「誰が継続してやるの?」と気になります。そこは提案の範疇でもあるかもしれませんが、要注意ポイントではあります。

次に業務仕様書のパートに入ります。

まずは基本となる3Dモデルデータなどを作りなさいよ、ということが書いてあります。

画像6

次にやっと、VRデータ変換及びアプリケーションの構築です。よくわからなくなってくるのがここのパートですね。

画像7

3つの大まかな性能の要件に入る前に、大前提として簡単な操作としてマウスをあげています。

ここはすでに少し注意が必要かもしれません。

そもそもですが、VR空間内で使うツールと、VRプログラムを立ち上げるために使うツールはそもそもかなり違います。

HMDをかぶりながらマウスを使って歩くのって結構大変ですよね(というか無理だと思います)。というかあんまりみたことないです。

こういう要項を見ながら思ったのですが、VRの概念が、いわゆる没入型のVRと異なるものである可能性があります。

どういうことかというと、

実は、VRは一般的に「VR」と呼称される没入型のものだけでなく、いわゆるBIMやモデリングツールなどのディスプレイで見られる3DモデルもVRと呼ぶ場合があります。こういう場合には、「非没入型VR」といったりします。

実際、日本建築学会の計画系論文集で「VR」という言葉を用いている論文の多くは、ディスプレイなどで3Dモデルを扱うプログラムを指しています。

この要項を読んでいると、どうも本当にVRがいわゆるゴーグルをして空間に入り込む「没入型VR」だけを指しているのかしら?という感じもするときがあります。

これが問題点の一つ目で、ひょっとするとVRという言葉がミスリードになって、コンペ開催者の想定と多くの人がイメージしているものが違うかもしれないような要項になってしまっています。

つまり実は、ブラウザやディスプレイ上でぐりぐり3Dモデルを動かせるシステムをVRと読んでいるのかもしれないという可能性を念頭に要項を読んでいってもらえるといいと思います。

問題点②:複数機能の実装の前にシステムの設計はめちゃ大変という視点が抜け落ちている感じがある

さて、そのうえで、VRプログラムに求める要件が3つのまとまりで書かれています。それぞれ(1)空間レビュー性能、(2)プレゼンテーション性能、(3)関係者間共有・情報公開性能です。順番に見ていきます。

ひとつめの「空間レビュー性能」から。

要件その1:要件が多すぎる空間レビュー性能。

画像8

まずこのレビュー性能をみて思うことは、機能が多すぎる、ということです。無理ではないけれど、とても大変です。それなりにきちんとしたコラボレーターに発注したら2千万は軽く超えると思う。3千万くらいはいくかもしれない。

問題の根本は、「機能の実装と、利用できるプログラムの作成は全く次元の違う作業である」ということです。

建築の設計者が、プレゼンテーション用にCGパースをつくるのとは結構根本的に違います。

どちらかというと、「CGで絵を描けるなら、一本CGでしっかりした映画作れるでしょ!」みたいな要求です。全然別物なんです。そこには脚本もあるしカメラワークもあるしそもそも建築パースと映画では土俵も何もかも違うのと同じです。

ここで挙げられているもののうち、個別の機能としては、そんなに大変なことはありません。でもそれは、あくまで単一の機能の実装としては、という意味です。

こうした複数の機能を一つにまとめてユーザーに使えるようにするのは、しっかりとしたVRアプリケーションを1から設計するのとそんなに変わりません。この大変さは、システム開発に少しでもかかわった人ならすごく共感してくれると思う。

複数の機能要件を一つのアプリにまとめ、ユーザーが使える形にし、それをきちんとバックエンドも含めて動くものにするためには、根本的にアプリの設計作業がまず必要で、そのうえでフロントもバックも実装しないといけないんです。

要するに、「UIやバックエンドも含めてシステムをまるごと設計する」という業務の鬼のような大変さが見過ごされているような感じがします。

これって、まるまるシステムの設計なので、すっごく大変ですよね。これがつくれたら普通に販売できると思います。そのくらい大変です。ちょっと絵を発注するとか、ちょっとプレゼン用の映像を発注するとかとはレベルが違うと思っていいのではないかなと思います。

これが3つの問題点のうち2つ目ですね。

「機能を実装することとユーザーが使えるプログラムを作成することが根本的に違う作業だということがあまり意識されていないように感じること」。

ただ、そもそも、空間の検討や今後のリデザインのためにデジタルモデルなどのアセットを構築するならまだしも、ゼロからVRモデルを扱うシステムを構築する必要があるのか疑問です。

これはコンペなので、費用感や運営コスト、施主が気にしているセキュリティ面などについて十分な対策を講じれば、既存のシステムを活用した提案をした方がいいのではないかと思います。

提案に使えるかもしれないので、検討できそうなサービスを貼っておきます。以下は結構話題になったNvidiaのサービスと、AutodeskのソフトでVRが使えるもののリストです。

ちなみに、僕がおすすめしたいのは、ClusterやVRchatといったVRのSNSサービスを用いて空間をシェアし検討する方法です。

こうしたサービスでは、自分で作成した空間をサーバーにアップすることで、誰でもどこからでもVR体験ができるようになります。

Unityなどの基本知識が必要になるのはなるのですが、ゼロから完全にサービスをつくるよりはかなりマシだし、うまくいけば世界中のユーザーが設計に参加してくれるかもしれません。

そういう意味でVRのSNSサービスの一部を活用するのはアイディアとしてとても可能性があると思います。

要件その2:プレゼンテーション機能はちょっと不明。

(1)空間レビュー性能についてみてきました。次に(2)プレゼンテーション性能です。

プレゼンテーション性能については、①はちょっと意味が解りません。

画像9

パワポをVR空間で使えるようにしたいか、あるいはやはりVRという概念がそもそもディスプレイ内で用いる非没入型のVRであるかのどちらかだと思います。

こうした①をのぞいた4つの機能を実装するなら、Unreal Engine 4というゲームエンジンをつかうのがいいと思います。ある程度使え方さえわかれば実現できます。

ゲームエンジンについては以下の記事をご参照ください。

(1)空間レビュー性能、(2)プレゼンテーション性能の観点をまとめると、コンペのプロポーザルの枠組みとしては、

①ユーザーのVR体験:既存のVRを用いたデザインツール or VR SNSを利用することを提案
②プレゼンテーション:Unreal Engine 4の活用を提案

という2本立てがいいのではないかな、と思います。

問題点③要件3~利用想定とあっていない機能要件

(1)空間レビュー性能、(2)プレゼンテーション性能、(3)関係者間共有・情報公開性能、のうち、3つ目です。

特に理解が難しいのが(3)関係者間共有・情報公開性能のところです。

改めてみてみましょう。なかなかすごいです。

画像10

まずいろいろと突っ込みたいところがあるのですが、細かいところはいってもしょうがないので、厳密なことは置いときます。

まず、この要項では「ネットワークに非接続」かつ「PCにファイル保存不可」と書かれています。ここが結構問題になります。

画像14

こうした状態でVRを用いるので、

「ネットワークに非接続」かつ「PCにファイル保存不可」かつ「PCにHMDを接続」

という条件で考えてみます。

その解決策としては、

「USBやSSDにプログラムファイルをいれてそこにPCをつなぎプログラムを起動する」

くらいしかない気がします。

ただ、セキュリティをよくわからない角度で考えすぎてしまってかなり矛盾した要項になってしまっているように思えますし、無理やりさがよくわからないです。

もしもなるべく多くの人に設計案を検討してもらいたいなら、①VR readyのPCを用意してHMDでVR体験ができる場を用意するとともに、②コメントなどは泥臭く映像をとったり人が付き添ってメモしていったりするのが現実的です。

最後にPC性能がかかれています。これはなかなか難しい性能です。

当たり前ですが、基本的にVRシステムを動かすにはVR readyのPCが必要です。

そう考えると、コンペの提案書にそうしたPCのスペックについても提案したほうがいいかもしれません。

20万くらいあればノートPCで十分な性能のものが1台買えると思うので、それを5台×HMDも5台くらいを提案書のなかには入れとくとか。

要件その3の別の読み解き方とスタンドアロン

ただ、少し別の角度からこの要項を読み解いてみることも可能ではないか、という気持ちにも少しなりました。

どういうことかというと、

こうした要項を書いた人があまりVRにあかるくないとして、この要項を書いた人のイメージは

「Oculus Questだとゲームをダウンロードすればオンラインじゃなくても使えるでしょ!スマホでもできるじゃん!その感じで!」

ということだと理解してみました。

前提として、VRでスタンドアロンというのはネットワークに非接続というよりは、PCに非接続かどうかを指すことが多いです。強力なPCにケーブルでリンクされているか、HMD単体で動いているか。

そのうえでなんですが、実はVRプログラムをスタンドアロンで動かすことは結構大変です。

なぜかというと、当然ですけどVR readyのPCで動かすプログラムと同じものをOculus Questで動かすわけにはいかないからです。そもそもCPUもGPUも性能が違い過ぎます。

なので、プログラムを作成することも大変なんですが、それがQuestでスムーズに動くように処理を簡略化したり、ポリゴン数を減らしたり、レンダリングの質を落とすチューニングの作業が必要になってきます。これがとっても大変な作業です。

ちなみに、VRをスマホとかにいれて、別のビューワーでみれたりしますが、あれってeacっていってYouTubeの360動画みたいなものと同じで、eacとVRアプリは別ものです。

弱いPCに接続するにしても、Oculus Questなどで動かすにしても、建築空間を多くの人に検討してもらい、かつ更新していくことを前提とする行政のシステムの要件としてはいささか不適格な感じがします。

これがおおよそ3つ目の問題ですね。どちらにしても利用想定と機能要件がずれすぎているんです。

僕の提案はやはり、オンラインで公開するか、もしくはVRでみんなの劇場を考えよう!みたいな会を開催することです。

コンペに参加するならばひとつのリスク管理として、開発体制だけでなく

①ソフトウェアの提案
②HMDの提案
③PCの提案

まではいれといたほうがいいのではないかな、という気がします。

また、

「制作したVRデータの機能全体を誰もがフリーライセンスで利用可能なこと (閲覧可能なPCを増やした際に新たなライセンス費用が発生しないなど) 」

もなかなかとんでもない条件ですね。なんせこんなプログラムできたら、コンペなんかやらずに製品を販売して設けたらみんなの劇場を利益で建てられると思うんです。なので安売りは極限的に不毛です。

最後に:VRが面倒の種になりませんように!

これでおおよそざっくりと要項の問題点と対応策を整理しました。

ここまできて改めて思うのですが、やはりVRってゴーグル使ったVRじゃないんじゃないかな、と思ってしまいます。ただ3Dビューができるシステムがあればいいのではないかな。それでもとっても大変だと思います。

僕がこの要項を読んでいてやはり一番思うのは、機能実装だけの作業とプログラム製作は根本的に次元の違う仕事だということをしっかり認識しないといけないということだと思います。問題の2つ目ですね。

明らかにVRに限らずシステムのこと知らなさそうだなとか、VRについても全く知識なさそうだなとか、明らかにVRに過剰な期待してるな、とかはもしかしたらコンペに勝ってからごり押しして修正していってもいいかもしれない。でも明らかにモノをつくるということを全く理解していない人と協働するのって大変ですよね。

何度も言うように、TwinmotionやUnreal EngineでVRをみたり、ちょっと機能を実装してみることと、こういったアプリケーションをきちんとつくることは次元が違います。

ただ、設計料は結構あるので、ひょっとするとシステム開発もフルでできるのか?という気持ちにならないでもありません。

画像11

丸亀市がめちゃくちゃお金が余っている可能性もあります。東京の有名な会社つれてこい、みたいなことかもしれない。もしそうなら、この要項に相当修正は必要ですが、ある程度やりたいことはできるかもしれません。

ただ、ここまで述べてきたようなリスクと前提があることは、建築の人ならな、どんなVR関連の案件に関わる人でも認識できるといいかもしれません。

全体的に、このままの要項をなんとなく読んでコンペに参加してしまったら、設計者の負担が大きいとかそんなレベルじゃないです。

最初にも言ったように、建築屋さんはデザイン慣れているんだからCGで映画つくれるでしょ、みたいな感じです。しかもそれを「広告代理店って何ですか?」みたいな人たちとやらないといけない。これはちょっと大変です。

僕は、うまくVRを活用するためのアイディアもたくさん溜めているし、これから社会実装していきたいとも思っています。

要項を読みながら「他にもいくらでも有効なVRの使い方はあるのにな」と思っています。ある程度予算があるなら、ほかにいくつかより良いVRの使い方はあり得ます。VRにはたくさんの可能性があるし、建築設計の考え方をドラスティックに変えることも可能な気がしています。

このコンペの要項を通して、設計者のなかに、「VRにかかわると結構めんどいことがいっぱい」という気持ちが起こらなければいいなと思います。

下はご参考までに。

(要項の改善方針)

もし要項を改善するならば、VRに仕様書については特に以下の5つの点において改善が必要と考えます。

①既存システムの利用も可能とし、当然オンライン状態でのVRの利用も可能としないと正直大変です。セキュリティについて懸念もあるかと思いますが、正直USBなどでやりとりしてもウイルスなどの問題は発生しえます。

②VRプログラムを利用する際の具体的なイメージをきちんとかかないとプログラムは想定できません。例えば限定的な数十人程度の関係者に配布するのか、一般ユーザーも巻き込みたいのか。一般ユーザーを巻き込むならどの程度の規模を想定しているかなど。没入型か非没入型かなども書いた方がいいと思います。

③スペックは、VRではかならず、PCスペックとHMDのスペックの提示が必要です。またPCについては「VR ready」という、VRを用いるうえでの最低限のスペック基準があるのでそれを満たす条件を明記する必要があります。

④ライセンスについては、フリーライセンスではなく、買い切り条件を明記した方がいいと思います。プログラムは著作物だし知財なので、「普通の設計業務の範囲内でVRプログラムをつくってこっちが自由に使えるようにしといてね」というのはかなり横暴な状態になってしまいます。

⑤システムの更新は、無料でやる当たり前の業務ではありません。正直メンテナンスはとても大変です。なのでコンテンツを随時更新していきたいのであれば、設計業務とは別にVRシステムの開発を発注したうえで建築設計者に用いてもらう形式にするか、既存のサービスをご検討いただくのがいいと思います。ただ、前提として、VRシステムの開発は、建築設計者の一般的な業務とは大きく異なります。それを建築設計のコンペに組み込むのは少し無理があるように感じます。

終わり。

サポートは研究費に使わせていただきます。