メタバースの体験設計を仕事にしていると、つい「自社でもメタバース空間を一式持っておくべきだ」と考えがちだ。サーバーを立て、入口となる画面を用意し、音声や通信のしくみを整える。実際、私たちもしばらくそうしていた。けれど先日、その自社運用のメタバースをまるごと撤去した。今回はその判断の流れと、空いたサーバーをどう作り変えたかを書いておきたい。
なぜ自社のメタバースを撤去したのか
撤去を決めた一番の理由は、シンプルに「手間に対して得るものが少なくなっていた」からだ。
メタバース空間を自社で抱えると、表に見える部分だけでなく、それを支えるサーバーや通信のしくみまで自分たちで面倒を見ることになる。これは想像以上に重い。設定をひとつ変えるたびに全体への影響を確認しなければならず、本来の事業に向けるべき時間が、空間そのものの維持管理に吸われていく。
加えて、私たちは並行して別のメタバース基盤を本番運用していた。そちらはきちんと動いている本物の環境で、自分用に使いたい空間も、その中に部屋を用意すれば十分に間に合う。つまり「自社専用のメタバースをもう一つ持つ」必然性が、実態として薄れていたのだ。
さらに困ったのは、メタバースのしくみと、日々の運用を見守るための裏方のしくみが、同じ1台のサーバーに同居していたことだった。役割の異なるものが一箇所に詰め込まれていると、片方をいじるたびにもう片方が気になる。身軽に動けない。
こうした事情が重なって、「自社運用のメタバースは思い切って撤去し、サーバーは別の用途で生かそう」という結論に至った。
空いたサーバーを「裏方の業務基盤」に作り変えた
撤去といっても、サーバーごと捨てたわけではない。メタバース一式を取り払ったうえで、その同じ機械を、事業を支える裏方の基盤として作り直した。
新しく担わせた役割は、どれも地味だが効くものばかりだ。毎日・毎週決まって発生する処理を自動で回す。異常があればすぐ通知が飛ぶようにする。あちこちに散らばっていた記録を一箇所に集める。大事なデータは定期的に控えを取る。期限つきのやることリストを管理する。そして、いま読んでいただいているこのブログも、その作り変えたサーバーから配信している。
派手な機能ではない。だが、こうした「うまく回っているときは誰も気づかない」しくみこそ、少人数で事業を続けるうえでは効いてくる。見えていた空間を手放す代わりに、見えない足場を固めた、という感覚に近い。
これからどう立ち回るか
方針はむしろはっきりした。自社専用のメタバースは、本番運用中の別基盤の中で十分に間に合う。だから限られたリソースは、本業である体験の設計と事業化の支援、そしてそれを足元から支える裏方の基盤に集中させる。あれもこれもと抱え込まず、効く場所に絞る、ということだ。
もうひとつ続けたいのが、こうした運営の記録そのものを発信していくことだ。何をやめ、何を残し、なぜそう判断したのか。その積み重ねは、私たちがどんな考え方で仕事をするのかを伝える、いちばん正直な資料になる。きれいに整えた宣伝文句よりも、実際の判断の跡のほうが、たぶん伝わる。
このブログは、そういうつもりで書いていく。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。