こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、株式会社ACCESSの梅田雅士さんです。

梅田さんのセッション「TV・車・ゲームに搭載されているブラウザってどうなってるの？」に関するスライド資料は、こちらで公開されています。

組み込みブラウザって…なに？

白石:では、まずは簡単に自己紹介をお願いできますか？

梅田:株式会社ACCESS IoT事業本部課長の梅田 雅士です。 もともとはエンジニアでして、ブラウザ開発からWebサービスまで、組み込みからフロントエンドまで開発していました。

白石:すごく幅広い経歴をお持ちですね！今回はPCやスマートフォン「以外」の環境におけるブラウザのお話を伺えると聞いています。

梅田:はい、今やブラウザはテレビにも、自動車にも、ゲームにも搭載されています。それらを総じて「組み込みブラウザ」と呼んでいます。

白石:組み込みブラウザと言うのは、PCやスマートフォンのブラウザとどう違うんでしょうか？

梅田:Webを閲覧できると言うのは、ブラウザの基本的な機能ですので、組み込みブラウザであっても変わりません。違うのはまず動作環境ですね。例えばOSも、LinuxからiTronまで、様々な環境があります。中にはタッチ操作やマウス操作が存在しない環境でも動作することが求められることもあります。

白石:ACCESSさんの組み込みブラウザは、今は主にChromiumやWebKitをベースにして開発してらっしゃるんですよね。組み込み向けに機能を追加したり、ということもあるんでしょうか？

梅田:はい、例えばテレビのリモコンとか、ゲームのコントローラーとかでブラウジングを可能にすると言った機能の追加は一般的にありますね。ブラウザの操作に関しては、「組み込みならでは」という部分は多いです。

テレビとブラウザ

白石:では、テレビ、クルマ、ゲームに搭載されているブラウザの状況について、詳しく教えてください。

梅田:ではテレビからいきましょう。実はテレビには昔から身近にありまして、テレビのdボタンを押して立ち上がる画面は、実はブラウザなんです。

白石:dボタンはブラウザ起動ボタンでもあったわけですね。

梅田:はい、それにテレビのメニュー選択を行うアプリもHTMLで書かれていたりしますね。

白石: ハイブリッドキャストと言うのは何でしょうか？

梅田:テレビ向けのブラウザでは、以前はBML (Bloadcast Markup Language)という、XHTMLベースの独自言語が利用されていました。ですが現在では、HTML5をベースとしたテレビ用の規格がありまして、それが「ハイブリッドキャスト」です。

ハイブリッドキャストは「放送と通信の連携」を目的として、NHKさんを中心とした標準化が行われています。単にHTML5が使えると言うだけではなく、スマートフォンとの連携（セカンドスクリーン）機能なども備えています。

白石:民放局の、ハイブリッドキャストへの対応度合いとかはいかがですか？

梅田:各社とも、現在対応を拡充している段階ですね。2020年の東京オリンピックで、テレビ放送をより楽しく観せるのが、各社共通の目標になっています。

白石:ちなみに昔聞いた話なのですが、テレビって意外にも低スペックで、重たいWebページを表示させるのは難しいと聞いたことがあります。その状況は現在では変わりましたか？

梅田:いえ、あまり変わりないです。テレビの中で一番高価な部品はやはりパネル。その他の部品、例えばCPUなどは、やはり廉価なものが使われることが多いんですね。なのでテレビ向けのWebページは、軽量であることが望まれます。

車とブラウザ

白石:では次は車とブラウザの関係について教えてください。

梅田:自動車業界では、カーナビを中心とした、操作可能な中央のスクリーンを「HMI (Human Machine Interface)」と呼びます。HMIでブラウザを利用できると、例えば自動車のマニュアルをHTMLで書いたりできます。HTMLは多言語化しやすいのでメリットは大きいですね。

あとは車載システムにアプリを追加することができるものもあります。インターネットと繋がって、例えば天気を表示したり、運転を楽しくするようなアプリがインストールできたりします。車載システムは「情報（インフォメーション）」と「娯楽（エンターテインメント）」を提供するという概念から、「インフォテインメント」とか、「IVI（In-Vehicle Infotainment：車載インフォテインメント）」と呼ばれたりします。HMIでブラウザが利用できるなら、そうしたアプリもWeb技術で開発できるようになります。

白石:車載システムにブラウザを搭載するという動きは、どれくらい進んでいるものなんでしょうか？

梅田:海外では結構進んでいます。車載システムのOSは共通化が進みつつあって、主要なものとしてはAGL (Automotive Grade Linux)やGENIVIがありますが、これらには今後ブラウザが搭載される予定があります。

ちなみにAGLって、Tizen IVIが元になっているんですよ。Tizenは一時期HTML5にも注力していましたので、白石さんはご存知じゃないかと思いますが。

白石:ええっ！Tizenって久しぶりに聞いた名前です。そうだったのか…そういう風に受け継がれていたんですね。IT業界って、思わぬところが繋がってたりするので面白い(笑)

ところでそういう車載システムとかだと、テスラの車とかは進んでるイメージありますけど、実際のところどうなんでしょう？

梅田:確かにテスラは進んでいて、WebKitを搭載した車載システムを既に積んでいますね。ただ、古いバージョンのWebKitを搭載していたため、そのセキュリティホールを突かれてハッキングが可能な状態になっていたことがあったりします。車載システムの高度化に伴って、セキュリティリスクも高まりつつあるというのが実情です。

ゲームとブラウザ

白石:ゲーム機にブラウザが搭載されているという点についてはいかがでしょう？

梅田:実は、ゲーム機にブラウザが搭載されているのは結構昔からなんです。2003年に発売されたPlayStation 2や、2004年に発売されたPlayStation Portableには、もう入っていましたからね。

白石:そんなに昔から入っていたんですね。そう言えば、ガラケーとかにもブラウザ積まれてたし、そう言えば組み込みブラウザって結構昔からあったんですよね。

梅田:そうですね。それに、ゲームソフト自体にブラウザが積まれていたこともありましたよ。

白石:ええっ！ゲームソフトがブラウザを内蔵していたんですか？

梅田:そうです。例えばモンスターハンター3には、弊社のNetFrontというブラウザが内蔵されていました。

白石:ゲームソフトにブラウザが入ってるなんて、考えたこともありませんでした。すごい世界だ。

ブラウザ開発ってどんな仕事？

白石:そもそもブラウザ作ってる会社ってあまりないですよね。そこら辺の実際をお聞きしてみたいです。ブラウザ開発って、どのように進めるものなんですか？

梅田:基本的には、W3Cの仕様を満たすように実装するというのがブラウザ開発の中心になります。ただ、今はオープンソースのブラウザをベースに開発していますので、少し仕事の範囲が変わりましたね。W3Cの仕様を満たすために開発するのは、主にChromiumやWebKitのコアチームに任せて、私たちはその移植が中心になりました。

白石:なるほど、今はブラウザエンジンそのものの開発に深く食い込んでいるわけではないと。

梅田:ただ、弊社ではEPUBのエンジンも作っていまして、そのために独自開発した部分とかは結構ありますね。例えば縦書きレイアウトとかは、W3Cに提案されている仕様を元に弊社で開発したコードを、ブラウザエンジン側にコントリビュートしたりもしています。

白石:ちなみにブラウザ開発って、どんな言語を使って行うんですか？

梅田:WebKitやChromiumはC++で書かれているので、C++ですね。C++ってメモリマネジメントが重要な言語ですが、WebKitとかってそこら辺が少しいいかげんだったりするんです(笑)。

白石:え、そうなんですか？メモリリークしたり、とかですか？

梅田:さすがに派手なメモリリークとかはめったにありませんが、メモリ確保に失敗した時の処理が甘かったり、とかですね。で、車載システムとかで利用する場合って、「動かない」って状況になるのはすごくまずいわけです。運転中は安全がなにより最優先ですから。そういう穴を潰して本家にコントリビュートする…というのもたまにありますね。

組み込みブラウザベンダーはつらいよ

白石:ACCESSさんはブラウザと言っても、更に「組み込みブラウザ」を作っているという数少ない存在。そういう、数少ない組み込みブラウザベンダーならではの苦労などをお聞きしたいです。

梅田:そうですね、まず先ほども申し上げたように、現在はChromiumやWebKitをベースに開発しています。以前は独自のブラウザエンジンでしたが、数年前にWebKitに切り替えたんです。ただ、WebKitはそもそも組み込み用途が主ではありませんでしたから、当初はハードのスペック的な制約との折り合いを付けるのが大変でしたね。（Webページが）メモリに乗り切らないので、数キロバイト単位に分割してメモリに載せるようにしたり…

白石:うわー、それは大変そう…。

梅田:最近はハードのスペックが向上したので、そういう苦労をすることも少なくはなってきましたけどね。あとは、レンダリングのパフォーマンスを改善するのも大変ですね。車載システムだと、最低でも60fpsは要求されるので、動画のデコードをハードウェアに行わせるようにするとか、CanvasをGPUレンダリングするとか。スクロールが滑らかになるようチューニングするのも大変でした。

白石:WebKitとChromiumは使い分けてるんですか？

梅田:お客様からのご要望や、用途に応じて使い分けています。WebKitはリリースサイクルがだいたい年一回で安定していますが、Chromiumのリリースサイクルはもっと速くて、コードもどんどん変化していきます。どちらがいいということでもなくて、それぞれにメリットがありますね。

白石:大変興味深いお話です。組み込む製品ごとに異なる苦労とかはあったりするんですか？

梅田: 車の場合とかは、製品の開発サイクルが長いのが特徴です。一つの車を作るのに5年とかかかったりすることもあるので、何回もつなぎ込みが発生するわけです。

白石:5年！Webの世界で5年と言ったら、状況はかなり変わってしまいますよね。

梅田:そうですね。ベースになっているブラウザもどんどん進化していくので、つなぎ込みを行うたびに、できるだけ最新に近づけていくようにするんです。その際に、ブラウザエンジンが持つAPIが変わってしまうことも珍しくありません。そういう事態に対応しやすいように、APIを抽象化したレイヤーを持っていたりします。

白石:いやー、ぼくみたいなフロントエンドエンジニアが全然体験したことのない苦労だ(笑)

梅田:他には、ブラウザの機能を拡張しなくてはならないこともよくあります。組み込みの場合って、HTML5が元々持っている機能だけじゃ足りないことが多いんですよ。

ゲームの場合は、ゲーム機というハードに閉じているからか、独自に拡張することが多いのが特徴です。

車載の場合は、Vehicle APIっていうAPIがW3Cで標準化されていますので、その実装を行うのも仕事の一つです。このAPIを使うと、例えばキーロックの情報を取れたりと、車載システムならではの機能を利用することができます。

PCやスマホ「じゃない」Webアプリ開発とは

白石:では最後に、PCやスマホじゃない世界でのWebアプリ開発について、どのようなものかお聞かせください。

梅田:基本的には、それほど変わるところはありません。組み込みブラウザと言っても結局WebKitやChromiumをベースとしていますし、HTML5以降はブラウザ間の互換性も高くなっていますし。

ただ、市場によって制約はありますね。例えば車載システムで動作する場合は、運転手の気を逸らさないようUIガイドラインがあったりします。

一方で、市場ごとに特有の拡張機能を使うことも求められます。

白石:先ほどおっしゃっていた、車載システム上で使えるVehicle APIなどですね。

梅田:そうです。そして、そうした標準化されたAPIと言うのは、組み込みの世界で特に重要なんです。

基本的にオープンなPC/スマホに比べて、組み込みは市場に特化しがちな世界でもあります。クローズドな世界で、クローズドな技術を使っているのでは、スキル的にもビジネス的にも拡がりにくい。

オープンで標準化されたAPIを使うことで、そうした事態を避けることができる。Web技術者も、活躍できる場がどんどん広がっていきます。

白石:なるほど。ちなみに、車載の世界とかでは、App Storeのようなアプリプラットフォームが出てくる可能性はあるのでしょうか？そして、Webで作ったアプリであればそれらのプラットフォームにどこでもデプロイできるというような可能性はありますか？

梅田:はい、そういう可能性はもちろんあります。アプリプラットフォームみたいな構想は各社持っていて、今後登場してくるのは間違いありません。 その時に、Web技術を使ってアプリを開発できる可能性も、それが複数のプラットフォームで展開できる可能性も、大いにあると思います。

そうした世界を見据えて、総務省さんと一緒に「Webとクルマのハッカソン」というイベントをここ数年開催しています。10月下旬から申し込み開始ですので、興味のある方にはどんどん参加してほしいですね。

白石:あ、そのイベント去年ぼくが審査員やったやつだ(笑)。去年もすごく盛り上がりましたよね。本日は組み込みブラウザ開発の話、そしてPC/スマホ以外のWeb開発の話など、普段あまり聞けないお話をお聞かせいただき、ありがとうございました！

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回は、「Nintendo SwitchとWeb」という講演をされていた任天堂さんに、Switch開発におけるWeb技術の活用方法や、開発秘話を伺ってきました。任天堂のお二人は京都から、リモートでの取材に応じていただきました。

HTML5 Conferenceのセッション会場は超満員（写真提供: html5j）

任天堂株式会社 企画制作部 フロントエンドエンジニア 堀川雄司氏（左）
企画制作部 ディレクター 津田 宗孝氏（右）
（写真提供: html5j）

Nintendo SwitchではWeb技術が大活躍！

白石 簡単に自己紹介をお願いできますか？

津田 企画制作部ディレクターの津田です。2011年に入社し、Switchでは、各種ネットワークサービス、コンポーネントブラウザーや本体内蔵ソフトのディレクション関係に携わってきました。

堀川 同じく企画制作部で、フロントエンドエンジニアの堀川です。私は2013年に入社し、ゲームソフトのダウンロード販売を行う、Nintendo eShopやゲーム連動サービスなどのWebサービスの開発を行っています。

白石 ぼく全然ゲームをやらないもので、ゲーム機の中身がどうなっているのか全然知らないんです。Nintendo SwitchではWeb技術がかなり使われている、というだけでも驚きでした。

津田 Nintendo Switchには、WebKitをベースとしたブラウザーコンポーネントが搭載されているんですよ。それを、スマートフォンで言うところの「WebView」のように、ゲームや本体内蔵ソフトからブラウザコンポーネントとして使うことができます。

白石 そうなんですか！そのブラウザって、どのように活用されているんですか？

津田 活用の方法としては、まずはスマートフォンとの連携ですね。

例えばいろんな情報を入力する場合など、普段使い慣れているスマートフォンで入力していただくほうがスムーズに進めていただけます。ユーザーも慣れていますし。 なので、例えば「ニンテンドーアカウント」（※）を作成するときとかは、ゲーム機で行うのはメールアドレスを入れるところまでです。 以降の入力の大半はスマホで行えるようになっています。

※ニンテンドーアカウント…任天堂が提供する各種サービスを利用するためのアカウント。インターネット対戦を行う際などに必要とされる

白石 スマホとSwitchで、得意分野を補い合っているんですね。

堀川 ほかには、Switchにはゲームの画面を撮影する機能があるのですが、撮影した画面写真と動画をSNSに投稿する場合などにも、Webの仕組みを使っています。具体的には、クラウド上の中間サーバーにテキストや画像のデータを送信するのに、ブラウザをクライアントとして用いています。

白石 なるほど、そういうクラウドのクライアントとしての処理も確かにWebのほうがやりやすそうですね。

津田 それだけじゃありません。ゲーム内のコンテンツにも、HTMLやCSSなどのWebコンテンツは入っていますよ。 まず気付くことはないと思いますが、普段のゲーム画面でも、Webブラウザで作った画面がさり気なく使われていたりします。

白石 おお、これ途中からWebに切り替わってるんですよね？すごくシームレスで、ネイティブで作られた画面とほとんど区別がつかないですね。 でも、なんでここだけWeb技術を使っているんですか？

津田 いわゆるゲームの画面と異なり、こういった文字の多いドキュメント画面で、特に多言語展開するケースにおいては、ゲームのNativeプログラムで作るより非常に早く開発することができるんですよね。

白石 なるほど、スマホとの連携、クラウドへのデータ送信、多言語コンテンツなど、Webが得意な部分についてはWebを積極的に使ってらっしゃるということですね。

津田 はい。私たちのチームでは「世界中のユーザーとゲームを繋げる」というビジョンがあるんです。その「繋げる」をこれまで以上に大きく広げるために、Webを積極的に使っているという流れです。当日のセッションではこれ以外にも、スマートフォンアプリの「Nintendo みまもりSwitch」や「Nintendo Switch Online」といったアプリでも、Webを様々な形で活用している例をご紹介しました。

Nintendo eShopはReactで作られている！

白石 今回のセッションでは、Nintendo eShopというサービスの構築に関するお話が中心だったそうですね。

津田 はい、Nintendo eShopというのは、Nintendo Switch上でゲームソフトを購入するためのオンラインショップです。Switchを持っていないときにでも、スマホなどからゲームソフトを購入できるようなサービスも提供しています。両者ともWebで作られています。

白石 そういうマルチプラットフォーム的な展開は、Webの最も得意とするところですよね。

堀川 そうです。スマートフォンやPCから見えるところはレスポンシブに作っていて、コードもかなりの部分が共有できています。ゲーム機で操作する場合はボタンでの操作になるので、多少は異なるコードが使われていますけどね。

eShopは、Webアプリとしてはかなり大規模と言って差し支えないレベルだと思いますが、アーキテクチャとしては全体的に統一されています。アーキテクチャの基盤としてはReactを使っています。

白石 おお、Reactが使われてるんですか！Nintendo Switchの中でReactが動いているって、Web技術者としてはちょっと胸が熱くなりますね。 eShopは、どういう流れで作られたんでしょうか？

堀川 プロジェクトの発足は2015年末です。Switchが発売されたのが2017年3月ですから、その1年ちょっと前からプロジェクトが始まったということになりますね。 eShopを作るにあたって私たちがよりどころにしたのは、「すぐに」というキーワードです。

Nintendo eShopを支える、3つの「すぐに」

白石 「すぐに」ですか？

堀川 はい。具体的には「すぐに出会える」「すぐに買える」「すぐに改善」の3つを満たすショップであるべき、と考えて開発に臨みました。

まず「すぐに出会える」というのは、「購入したい商品にすぐに出会える」ということです。 ゲームの魅力を少しでも正確に、多くの方に伝えて、「購入したい」と思っていただきたいということですね。

そのため、以前はショップ内に閉じていたゲームのプロモーションを、Switchの待ち受け画面で表示される「ゲームニュース」に任せることにしました。

UIに関しても全面的に見直し、欲しいゲームにすぐに出会えるようにUIポリシーを再構築しました。

「すぐに買える」というのは、「買いたい」と思ったらすぐに買えるような場所でありたいと思いました。そこで、Switch上の様々な場所からeShopに行くことができるように導線をはりめぐらしました。

堀川 また、ゲームを買おうかなと思って購入画面にいくと、全く別の印象をもった「システム画面」っぽかったりすると、ゲームを買いたいという熱が冷めてしまいます。そこでゲーム画面と購入画面をできるだけシームレスに見えるようなデザインを目指しました。

しかしゲームの数は非常に多いので、そのそれぞれに手作業で背景色を指定したりするのは、非常に骨が折れます。

なので私たちは独自のアルゴリズムで、ゲームの画面イメージから色を自動で抽出し、背景色に指定するという処理を行っています。 私たちはこの処理で抽出したカラーパレットを自動的に生成できるように開発し、ゲームの魅力や個性を尊重しつつ、開発の効率を向上させることに成功しました。

白石 これ、画像の中で一番使われている色を選んでいるというわけでもなさそうですね。ちゃんとゲームの特徴を捉えた色が選ばれている。どうやってるんですか…？

堀川 そこは企業秘密です(笑)。

そしてWebとReactが選ばれた

堀川 最後は「すぐに改善」です。eShopは長期に渡って運営し、成長させていくプロジェクト。

eShopは、数多くの言語や国と地域に対応させていく必要がありますので、言語だけでなく、税率や通貨などの国際化も必要です。 それらの地域で例えば税率が変更されたりしたら、すぐに修正していけるような開発環境を構築していく必要がありました。

そういう改善のしやすさと、長期的な成長の土台を作るために開発環境の選定を行いまして、2015年末に「Webしかない」という決定を下したんです。

白石 確かに、そういう変更と反映のしやすさはWebの利点ですね。

堀川 Webで行くと決まってからは、改善しやすい設計とパフォーマンスを両立させるために、ライブラリの選定を行いました。

使い勝手の面を考えるとシングル・ページ・アプリケーションが望ましかった。 また、Nintendo Switchは「サクサク動く」ことも大事にしていますので、パフォーマンスが良いことも重要です。 そうして、結局私たちが選んだのはReactとReduxの組み合わせでした。

白石 2015年末くらいにそれを選ばれたというのは、かなり新しめの取り組みでしたよね、きっと。

堀川 はい、私たちはその時点で最善と思われる手法を、積極的に採用しています。 Reactを使う場合は、いろんなライブラリを組み合わせて使うのが普通です。以下が、私たちが使っているライブラリの一例です。

白石 Reactを徹底して使われたということがわかります。大規模なWebアプリを作るのに、Reactを使ってみていかがでしたか？

堀川 やはり、コンポーネント指向での開発は、様々な利点があると感じました。コンポーネント単位でのテストは容易ですし、再利用性も向上します。 CSS Modulesを使ったおかげで、大規模サイトにもかかわらずCSS設計が破綻しなかったのも良かったですね。

Nintendo eShop開発秘話（1）: デザイナーとエンジニアの間に溝が！

白石 eShopの開発を行うにあたって、いろんな課題にぶつかったんじゃないかと思うのですが、実際にはいかがでしたか？

堀川 まず開発初期の段階で、コンポーネント指向を巡って、デザイナーとエンジニアの間で溝ができてしまったのは頭を悩ませました。

白石 コンポーネント指向で溝、ですか。

堀川 はい。コンポーネント開発を進める上で何を共通化するのかで、デザイナーとエンジニアの間で感覚が全然違ったんですね。ぼくらは最初、それに気づいていませんでした。

デザイナーはコンポーネントに分割することで、「見た目」「体験」を共通化できるものと考えます。だから、見た目が異なる場合は違うコンポーネントになると考える。

一方エンジニアは、「内部」「機能」を共通化するものだと考えがちです。なので、「価格を表示する」というコンポーネントがあるとすると、それをできるだけ再利用しようとする。

だから例えば、デザイナーが「画面によっては価格を目立たせたいから、違うデザインにしたい」と伝えても、エンジニアは「価格を表示するという機能が共通なのだから、同じコンポーネントで」と考えてしまい、コミュニケーションに溝ができてしまうんです。

白石 「共通化」と言っても、それぞれの立場で重視するものが違うから、「何を共通化するか」の感覚も違ったと。

堀川 そうしたコミュニケーションの溝を埋めるために試行錯誤した結果、結局、全体のモックアップを先に開発することにしました。 このときはReactも使わずに、デザイナーが作ったデザインカンプを元に、プレーンなHTMLとCSSを使って作りました。

こうして、開発するもののイメージを先に合わせておくことで、デザイナーとエンジニアの認識のズレを抑えることができました。

白石 なるほど、ゴールイメージの共有を行うことで、認識のズレが解消されたわけだ。

堀川 そうです。特にeShopは、既存のサービスも既にありましたので、ゴールイメージは共有できているものと何となく思っていたんですよね。問題の原因にはそうした思い込みもあったと思います。

ほかにチーム内の意識を共有するためにやったこととしては、コンポーネントのカタログを作ることですね。Storybookを使用すると、アプリケーション外で動作するReactコンポーネントのカタログを作れます。コンポーネントの動作を簡単に確認できるので、非常に便利でした。

白石 Storybookって初めて知りました。便利そうですねーこれ。

Nintendo eShop開発秘話（2）: 仕様が複雑すぎる！

堀川 次に、eShopを設計するにあたっては、ユーザーストーリー（※）を中心としました。例えばこういうユーザーストーリーです。

※ユーザーストーリー…ユーザーがシステムを通じて達成できることを書き下した文章

白石 なるほど、結構粒度細かいですね。この粒度だと、ユーザーストーリーの数がかなり多くなったのではないでしょうか？

堀川 はい、かなりの数です。ユーザーストーリーはスプレッドシートで一覧にして管理していたのですが、実際にはこんな感じです。

白石 おー、すごい！実際の開発に使われていたスプレッドシートとか見ると、テンション上がりますね(笑) ストーリー以外にも、いろんな情報が書き込まれていますね。

堀川 はい、テストケースや品質目標も、全部ユーザーストーリーを中心に組み立てていったので。

品質目標というのは、「Never（あってはならない）」「Must（できなければいけない）」「Want（あったらいいな）」という項目をストーリーに付与できるようにしたものです。これで、ストーリーに基づくユーザー体験を一定品質で保証できるようにしました。

白石 モックも作って、設計も入念に…って、設計段階で品質を上げようとする努力がすごいですね。

堀川 いえ、まだあります。テスターに早くから協力してもらったのも、eShopの品質の上では重要でした。

eShopは先ほども申し上げた通り、数多くの国と言語を扱わなければなりません。実際にはそれに加えて法律や通貨、決済方法なども考慮に入れて仕様を作っていく必要があります。だから仕様がどうしても複雑になってしまうんですよね。

なので、テストのプロが仕様を決める段階でチェックをするようにして、早い段階で重大な考慮漏れに気付けるようにしたわけです。

白石 このスライドにあるような事柄を、全部エンジニアが一人で考えて仕様に落とすのはさすがに難しいですもんね。

Nintendo eShop開発秘話（3）: 最後は「お祭り」！そして任天堂がWebに期待すること

堀川 リリースまであと半年っていう段階で、大変なことが判明しまして。Switch上で、OSからWebまで統合して動かしてみたら、全然期待するパフォーマンスが出ないし、尋常なく不安定で遅かったんですよ。起動も遅いし、不安定だし。

白石 えー！それはゾッとする話ですね…

堀川 大問題だったので、全チームに呼びかけて助けを求めました。SDK/OSプログラマ、本体アプリプログラマ、ブラウザーエンジニア、サーバエンジニア、デザイナー…。弊社は、多くの関係者が一つの建物にいるので課題の共有が早くできるため、結果的に改善も早くできるのがすごくいいところです。

全員が1つの目標に向かってアイデアを出し合いました。エンジニアは最適化のアイデアを。デザイナーは起動アニメを工夫して、起動待ちのストレスを軽減しました。 まさにこれは「お祭り」という感じでしたね。誤解のないようにお伝えしておくと、お祭りとは「炎上」ではありません。力の結集なんです。

我々はWebサービスを作る上で、フロントエンド、バックエンドだけではなく、ブラウザー、OS、そしてゲームソフトやハードまであらゆる関係者全員の力を結集してプラットフォーム、そしてプロダクト、サービス、コンテンツを生み出しています。非常にダイナミックな体験ができます。

無事、2017年3月、Nintendo Switchの発売にこぎつけることができたのは、こうした全員参加の「お祭り」あってこそだったんです。

白石 Nintendo Switch発売の裏側で、そんなことが起きていたとは、聞いていてちょっと感動的でもありました。もっといろいろお話を聞きたいところですが、残念ながらそろそろお時間になってしまいました。最後の質問です。HTML5Experts.jpはWeb技術者向けの媒体ですので、任天堂さんがWebに期待していることを教えていただけますか？

津田 それはやはり、最初に申し上げた「世界中のユーザーとゲームをつなげる」というビジョンに尽きます。あらゆる人々やあらゆるコンテンツを、デバイスを超えてつなぐことができるのは、Webは最適だと思っています。

堀川 そして、Webの世界は進化が速いですが、ビジョンをより高いレベルで達成するためにも、私たちも常に最善の手法を採用して、より優れたWebサービスを開発していきたいと思います。弊社ではフロントエンジニアを募集しておりますので、一緒に開発してくれる方をお待ちしてます。

白石 本日は、大変興味深いお話をどうもありがとうございました！

堀川/津田: こちらこそ取材いただきまして、ありがとうございました。

このゲームはアニメ『翠星のガルガンティア』から生まれたスカイアクションゲームで、この作品のためにシナリオを書き下ろし、アニメ本編の声優はフルボイスで出演、そして世界中のファンが楽しめるように、日本語と英語のキャプションを用意するなど、ゲームそのものに気合いが入っているだけでなく、開発者向けにはソースコードの一部と3Dモデルを公開し、WebGLの裾野を広げることも目的にしています。

Web 表現の限界に挑戦

大いに自慢したいのが、そのWebGLの表現力と応答性です。大きな入道雲や飛行ルートを邪魔する気流、すれ違うカモメの群れ。いずれもリアルタイムに美しく描画しているだけでなく、ゲームの爽快感を損なわないように滑らかに軽快にレンダリングされています。

このゲームはInternet Explorer 11のタッチ操作に最適化されていますが、マウスとキーボードでも遊ぶことができます。さらにGamepad APIにも対応。ゲームパッドコントローラでも遊べます。また、レスポンシブWebデザインを反映して、プレイできるエリアはディスプレイの解像度に合わせて自動的に調整されるようになっています。

オープンソースのTurbulenzエンジンで構築

ガルガンティアでは、開発者がより効率的に3DのWebコンテンツが作れるようなリファレンスになることも目標の一つです。今回はイギリスに本拠地を置くゲームデベロッパー、Turbulenzと連携し、オープンソースのTurbulenz Engineを使って開発しています。

Turbulenz EngineはJavaScriptとTypeScriptで実装された2D/3Dゲーム開発エンジンです。ハイパフォーマンスな物理エンジン、高品質なビジュアルエフェクト、パーティクルシミューレション、アニメーションエンジンといった豊富な機能を提供し、ゲーム技術の広い範囲をカバーしています。

Turbulenz Engineは無料でGitHubからダウンロードできます。

さらに、ゲームの一部のソースコードと3Dモデルも公開しています（アドベンチャーパート、ボイスデータ、BGMデータは含まれません）。こちらもGitHubからダウンロードできますので、読者の皆さんもぜひお試し下さい。ソースの入手とWebサーバーへの配置については、弊社のエバンジェリスト物江がブログ「ゲーム『翠星のガルガンティア』のソースの入手とIISへの配置方法」で紹介しています。

IE9で掲げた「Same Markup」と同様に、いまもIEの開発ではWeb標準への準拠をなによりも大切にしています。この『翠星のガルガンティア　～キミと届けるメッセージ～』もWebGLに対応したほかのブラウザでもお楽しみいただけます。今後、新しい面が追加されていきます。お楽しみに！