開発の振り返り(ハコスコナビのフロントエンド開発)
3DCGでVRな人間の@blkcatmanです。
ハコスコ入社直後はアプリの開発を行っていましたが、その後サーバーサイド(特にAWSサービスとの連携)での開発を経験、フロントエンドの開発も行うようになりました。
今回はそのうち、携わったプロジェクトの中で開発に大きく関わったハコスコナビのフロントエンド開発の振り返りを記事にしました。
ハコスコナビについて
ハコスコナビは、ボイスチャットでユーザーと対話しながらイベント会場やホテル、物件、または景観など、様々なVR映像を遠隔から簡単に紹介できるサービスです。
ハコスコナビ | ハコスコ
当時の開発フェーズ
新規サービスとしてハコスコナビの開発がスタートしました。
今回はモック制作まで、開発〜内覧会まで、サービス提供開始までの3つのフェーズに分けて書きました。
それぞれのフェーズでの開発のできごとを次の項に書いています。
モック制作まで
モック制作は2018年8月からスタートしました。雛形がまったく作られていない状態からスタートしました。この時は、まだハコスコナビとは呼ばれておらず、暫定でVR体験プレゼンツールという名前で呼ばれていました。
当時の以下の要望から実現に必要なライブラリやフレームワークを探すことからスタートしました。
- ナビゲーター(オペレーター)と視聴ユーザーの二者間の非対称なシステムを構築する
- 視聴ユーザーは複数人参加できる
- ボイスチャットを実現する
- （ナビゲーターが所持している）ハコスコストアのコンテンツを視聴できる
- プラットフォームに依存しないよう、Webブラウザで動作するアプリにする
- 対象のプラットフォームはPC(windows、mac)、iOS(iPhone、iPad)、Android、OculusGo
Webブラウザ上で動作するアプリ => JavaScriptでのWebアプリ開発に決まったため、JavaScript上で簡単に動作するライブラリを探してモックを作成しました。 初期の仕様から今後の開発方法を把握するもあったので、モック制作は1ヶ月程度かかりました。
開発〜内覧会まで
モックのレビュー後、サービス化に向けて本格的な開発が2018年9月から始まりました。
モック制作時に使用していたライブラリが、本開発で不具合を招くことが懸念されたため、再度使用するライブラリを見直すことになりました。また、モックは雑に実装されたコードも多くあったため、本開発ではモック時に書いたコードはほとんど残りませんでした。ここは以降の開発での反省点になりました。
再検討の結果、信頼性と安全性の面からSkyWayをボイスチャットのライブラリに使用することになりました。 また、JavaScript上でGUI設計に管理するため、Vueのフレームワークを取り入れました。当時はVueに慣れておらず、コードの書き始めに苦労した覚えがあります。
ハコスコナビの内覧会が開催されることになり、一旦の目処として11月を目標に開発を進めていきました。
中途段階とはいえ、流石にフロントエンドの開発だけで工数がすごいことになったので、サーバーサイドの開発は@ill_hhdさんにお願いしました。
サービス提供開始まで
内覧会の後、2019年1月にサービス提供することになりました。
サービス提供に向けて、デザイナーが作成したGUIレイアウトとUIパーツのデザインに変更し、実運用で必要になる機能追加を行いました。
機能追加のうち、ボイスチャットのミュート処理を実装していましたが、ブラウザ間での動作確認が大変でした。特にSafari(macOS、iOS)が不安定で、Chromeで動作するコードがSafariで動作しないということがたびたび起こりました。
Safari 12(2018/9/17リリース)がリリースされた後のこともあり、オンラインのドキュメントやissuesがほとんど見つからず、トライアル＆エラーで試行錯誤していた時もありました。
色々な方法を試して、なんとか期間中に機能を追加することができました。
サービス提供開始後〜
無事サービス提供を開始することができました。現在もハコスコナビはサービス開始後からいくつもの修正、機能追加が行われています。
また、サービス提供前後でOculusGo本体に大幅なOSアップデートが始まり、たびたび結構なトラブルに遭遇しましたが、それはまた別の機会に・・・
終わりに
自分にとってこの開発はこれまでよりもプロジェクトのスケジュールの計画性や、工数管理の意識付けの大切さを知る機会になりました。 ハコスコは少人数開発で、なおかつ平行に走っているプロジェクトも多いのですが、この数ヶ月で非常に濃い経験をすることができました。
次回はもうちょっと軽めに、何かの技術記事にできればなぁと思います。お読みいただきありがとうございました。
エンジニアが関わるパフォーマンスアート作品での裏側
はじめまして、ハコスコリードエンジニアで必要あれば何でもやってる@rinsyan0518です。 HHKB Professional2 Type-Sが愛用で、VSCode/Vimが主な開発環境です。
今回は、基本的にエンジニアは私一人で開発している「The Mirror」、「Neighbor」について、エンジニアから見た考えなどについて簡単に触れていければと思います。 それぞれの作品はシステム的にはほぼ同じものが使用されているため、制御する機材が多い「The Mirror」のシステムを中心にシステム構成から感じたことまで書いていきます。
実装要件
基本的なシステム要件については省くと以下の4つがあります
- 各機材を手動で変更する必要がないこと
- 「初期化」と「開始」以外に操作者は考えなくて良いこと
- エンジニア以外でもパラメータが調整できること
- エンジニア以外でもシーケンスの変更が可能なこと
「各機材を手動で変更する必要がないこと」については、幸いMIDI、TCPなどで外部制御が可能な機材が多いため、機能要件に合い外部制御可能な機材を選べば問題なさそうでした。また、「「初期化」と「開始」以外に操作者は考えなくて良いこと」についても、機材すべての制御がPCから操作するようにすれば問題なく動作させられます。
それ以外については以降で書いていきたいと思います。
システム構成
まず、コンバーターなど細かいものは省き、システムとして大まかに以下のような役割を持ったものが使用されています。 具体的な機材名などが書けないのは、ほぼ毎回どこかが変わっているため決まっていないからです。
（矢印は有線、無線など何かしらでその機材と繋がっていることを示しています）
カメラ →→→→→→ Videoスイッチャー →→ モニタ
↓ ↑ ↑
遅延処理ユニット→→↑ ↑
↑ ↑
↑←←←←←← メインPC →→ 照明
↑ ↓
制御端末→→↑ HMD(+PCもしくはSP)
メインPCに作品のシーケンスがあり、必要なタイミングで各機材のプロトコルに合わせてメッセージを送るようにしています。 切り替えのタイミングがシビアであったりメッセージの送り先が多くならない限りは、すべてのステートを管理するものは1つで行ったほうが、考えることが減るので不具合等原因を追いやすいです。
Max/MSPがメインPCの中で中央に位置するソフトウェアとなっており、ステートの管理と他の機材との通信はMax Patchを中継するようになっています。 （Max/MSPっぽい使い方ではないとは思います笑）
選定した理由としては以下です。
要件にあった「エンジニア以外でもパラメータの調整ができること」、「エンジニア以外でもシーケンスの変更が可能なこと」があるため、1が主な理由で選定しています。しかし、現在はシーケンスについては修正に手間が多かったためらMax/MSPから外に出し別のソフトウェアで管理されるようになっています。
私としては、2番目の理由として5の理由が大きかったです。 私があまりMax/MSPを触ったことがないこともあり、Max Patchでオブジェクトとオブジェクトを繋ぐのが慣れることができなかったため、ラップして問題ない処理はmxjで書いてしまいます。また、複雑なことを書いていると、ラインが多くなり処理が追いにくくなるので、mxjで書くのが普段と変わらないので楽ができます。
気をつけていること
体験型の作品であるためというわけではないですが、主に気をつけていることについてです。
機材、システムが置き換えやすいこと
必ず同じ構成で毎回行えるとは限らないため、ある箇所が別のなにかに変わったとしても、他の機材やシステムに影響が無いようにする必要があります。 例えば、メインPCをmacOSからWindowsにしたり、遅延処理ユニットを専用の機材からmacOSで実現したりなど過去にあったことは様々です。その中でも、特に変更が多かった箇所としてはHMDで、「Nuxus 5」→「iPhone 6 Plus」→「iPhone 8 Plus」→「HTC VIVE」です。
このように、そもそもOSが変わることもあるため、PC/SPで扱うものはクロスプラットフォームに出力できるものを使用し、足りないものはプラグインを作るように開発をしています。 またSOLIDのOCPということではないですが、、、Max/MSP含めてソフトウェアはインターフェースさえ同じであれば中の処理を気にしなくても良いようには気をつけています。
シーケンス開始後もマニュアルで対応できるようにしておくこと
「Neighbor」で発生したことがあるのですが、センサーがドリフトして期待してた方向の映像が表示されていないことがありました。 その際は、過去の映像でないタイミングでマニュアルで調整したりすることで、ある程度正常に動いているようにしていましたが、テスト中は起きなかったことが本番では起きることはよくあることかと思います。 そのため、期間との兼ね合いもありますが、、ある程度は回避できる手段を持っておくことも大切と思っています。
システムが落ちないこと
当然といえば当然ですが、可能な限り体験中に落ちないことは目指しています。今のところ、本番でiPhoneが熱暴走で止まったこと以外はない(はず)です。 iPhoneが熱暴走をしないギリギリで、気温が高い中でも冷やすために少し水を付けてサーキュレーターにあてるなどしたのはいい思い出です。
これに対しては、基本的にはテストするしか無いと思っていまして、CPU／メモリと気になるところに差し込んでいるログを主に確認するために「展示1日あたりの時間」をテストし続けたりしてます。サービス開発しているときと、そこまで変わらないかと思います。
展示作品であるあるだと思うこと
いくつかの経験からなんとなくよく思うことです。
環境での問題
Wi-Fiに関しては可能な限り5.0GHzを使用するようにしますが、端末依存で使用できない場合などは周辺の情報を確認して調整することが必要になるかと思います。 また、HTC VIVEのときでもベースステーションに干渉するようなものが近くにないか目に見えないものに気を配るケースが多いことかと思います。 そのため、想定外の動作をしている場合は、開発したものが原因だけなく、環境が原因についても考慮に入れて、考えることが必要です。 （無駄かもしれないような知識でも何でも持っておくと意外と役に立つケースが存在するのは、こういうときなのかもしれません。）
システム起動手順
長期間での展示は、会場での動作確認など必要なことが終わると、ほとんど会場から離れてしまうため、毎日のシステム起動は現地の方にやっていただくことが多いです。 そのため、起動手順については、基本的に簡単にできるよう心がけてはいますが、複数の機材やソフトウェアを使用していると、どうしても起動順に依存関係が生まれることがあります。 それが原因で、最初のシステム起動がうまく行かずに開始できるまでに時間がかかることがありました。
このことから思うことは、手順の誤りで発生する異常系動作を把握しておくことが大切です。もちろん、それ以外の発生する可能性のあるシステム外の異常系動作は可能な限り、対処方法も含めて想定しておけると良いと思っています。
終わりに
ハコスコではこのようなパフォーマンスアート作品にも携わっております。 こういった機会がまたありましたら、ブログとして掲載していくことや、今回は触れなかった技術的なことにも今後触れていこうと思います。 それでは最後までお読みいただきありがとうございました。
ハコスコエンジニアブログはじめました
はじめまして、ハコスコ開発マネージャーでラッパーの @ill_hhd です。
かわいいダンボール製VRゴーグルで有名なハコスコは、2014年の創業以来、360度コンテンツ配信サービスのハコスコストアを基軸に数々のプロダクトやサービスを生み出してきました。
だけど、技術的にはどんな取り組みがあるんだろう？開発チームは一体何をやっているんだろう。どんな課題に直面し、解決しているのか。
今後このブログではそんな疑問にお答えし、アンダーグラウンドだったハコスコ開発のリアルをオーバーグラウンドに引き上げていきます。
今回は初回なので特定のプロジェクトや開発課題に注目せず、直近2年間(僕がハコスコにジョインしてから)で行った開発の中から独断と偏見のキュレーションをしてみました！いきなりダイジェスト！
2017年のプロジェクト(一部)
現実空間に360度動画をプカプカ表示 ハコスコ公式HoloLensアプリ『ホロスコ』 www.moguravr.com
自由視点VRコンテンツ配信 jp.techcrunch.com
3Dの360°ライブ配信「ハコスコLIVE」 hacosco.com
VRゴーグルとVRコンテンツを セットで提供「ミルマル」 www.value-press.com
- Akamai CDNの採用
- A-Frame/Vue.jsでのWebVRPlayer内製
これらはハコスコにとって大きなことだったのですが記事がなく、あしからず...(今後ブログで!!)
2017年もいろいろありましたね。R&Dの毛色が強く見えます。
では昨年、2018年はというと大小15以上のプロジェクトが走りました。 下記は特にチャレンジとなったものを箇条書きで抜粋。
2018年のプロジェクト(一部)
- Vue.jsを用いたSPA開発
- 開発のアジリティとスケーラビリティの追求に向けたインフラアーキテクチャの変更 - AWS ECS Fargateの採用
- サーバーレスアーキテクチャを採用したWebVRポータル
- StripeBillingによる定期支払の導入
- 360度カメラInsta360とのインテグレーション
- WebRTCを用いたVRコンテンツ同時視聴システム
- SR / ポータブルSR
2018年はチーム体制が整ってきたことや事業の方向性がより明確になってきたことから、持続的な開発を取り巻く環境整備の観点でのプロジェクトもいくつか立ち上がりました。 採用された技術要素も多岐に渡ります。
またその他にも映像制作の側面においてフォトグラメトリーを駆使したコンテンツの配信も行いました。
フォトグラメトリー”を駆使して現実を3Dで再現「長崎の教会群 www.moguravr.com
これだけ見てもハコスコの開発は多種多様です。R&D的な側面を強く持ちつつ、当然サービス/事業の拡張の観点での開発があり、これらがエコシステムとなり回っています。
未開拓な事業領域にチャレンジするスタートアップとして、アカデミアに起源を置くスタートアップとして、かなり特殊な少人数開発チームのなかなか世に出ないレア・グルーヴな開発風景がお届けできればと思います。プロジェクト、チーム改善、開発Tipsのクローズアップに乞うご期待。
最後に、代表藤井 の創業当時のインタビュー記事で締めたいと思います。
未来がつまらないなら自分で作ればいい～社会脳研究の第一人者が仮想現実プラットフォーム『ハコスコ』を作った理由【連載:匠たちの視点－藤井直敬】 - エンジニアtype | 転職type
