イベントに参加できなかった方に向けてセッションの内容を記事にまとめましたので、ぜひご覧ください。

この記事では、昨今話題に上ることが多いPWAことProgressive Webアプリケーションについて、実際の作り方を解説しながら、それがいったいどういったものであるかを詳(つまび)らかに紹介することを目的としています。

Webでは、「ネイティブアプリと同じことができる」「ネイティブアプリを置き換える」など、期待に胸を膨らませずにいられない浪漫に満ちた噂がありますが、それが本当かどうか記事をご覧いただくとご理解いただけると思います。

Progressive Web Appsの作り方を紹介する前に、簡単に概要を紹介しましょう。

Progressive Web Appsとは?

Progressive Web Apps(以下PWAと記述) は、一言でいうならば「ネイティブアプリのようなUXを提供するWebアプリの概念」といったところでしょう。2015年の11月に開催されたChrome Dev Summit 2015のキーノートで発表されて話題となりました。

もともとは、その年の10月にAlex Russell氏(Google)がブログ記事に投稿した、クライアントの性能に合わせて段階的に進歩するWebアプリケーションのコンセプトでした。

PWAというと、”ネイティブアプリのような体験”といった特徴ばかりが注目されますが、大きな特徴がもう一つあります。それは、PWAという名前にも含まれているProgressiveというところです。

これはHTML5が普及しはじめた頃にあった、「HTML5が解釈できるモダンブラウザーにはリッチな体験を、そうでないブラウザーには従来とおなじ体験を」というデザインの考え方 Progressive Enhancementに由来します。

PWAはこの思想を踏襲し、性能の低いWebブラウザーを切り捨てることなく、クライアントの性能に合わせた機能提供を行います。

PWAは、性能の低いWebブラウザーからアクセスがあった場合は従来と同じWebページとして動作し、PWAが動作する機能を備えたWebブラウザーからアクセスがあった場合は、その機能を活かし、これまでのWebアプリにはなかったネイティブアプリのような体験を提供します。

Progressive Web Appsを実現する機能

それでは、”これまでのWebアプリにはなかったネイティブアプリのような体験”というのはどのようなものがあるでしょう?

代表的なものとしては以下の4つが挙げられます。

1. オフラインサポート
2. プッシュ通知
3. バックグラウンド処理
4. デバイスへのインストール(デバイスのホーム画面から起動できる)

これらはの機能はそれぞれ以下のような新しいAPIによって実現されます。

1. オフラインサポート – Cache API
2. プッシュ通知 – Push API
3. バックグラウンド処理 – Background Sync
4. デバイスへのインストール(OSのメニューから起動できる) – Web App Manifest

そして、これらの機能を提供しているのが1～3がService Workerで、4がWeb App Manifestです。

PWAの定義に明確なものはありませんが、上記の機能の中からオフラインサポートと、インストール（アイコンをデバイスのホーム画面に追加）機能をサポートしていれば、PWAを名乗ってもそう否定されることはないでしょう。

これらの機能により、デバイスのホーム画面から、ナビゲーションバーなどのブラウザーUIがない状態でアプリケーションを起動し、オフラインの状態でも使用できる、という体験をユーザーに提供できます。これらの体験は、これまでのWebアプリケーションにはなかったネイティブアプリのならではのメリットと言えるでしょう。

それでは、逆に Web ならではのメリットとはなんでしょう?

Webのメリット

ネイティブアプリにはないWebならではのメリットを、Googleさんのイベントではよく以下のSLICEという言葉で表しています。

• Secure (安全)
• Linkable (リンク可能)
• Indexable (インデックス可能)
• Composable (再構成可能)
• Ephemeral (一時的な利用)

これら従来のWebとネイティブアプリの体験上のメリットを合わせたものが、PWAのメリットとなります。

Progressive Web Appsが提供する価値

PWAの提供する価値について、GoogleさんのイベントではよくFIREという言葉で紹介されていますが、

• Fast: パフォーマンスの良い、軽快な動作
• Integrated: OSと統合されたユーザー体験
• Reliable: オフラインでも動作する利便性と信頼性
• Engaging: Webサイトの価値向上

この記事ではもう少しかみ砕いて紹介しましょう。

発見性

PWAであれば、アプリを公開するのにアプリストアにわざわざお金を払ってアプリを提出したり、審査を通すための不自由なルールに縛られる必要はありません。これまでのWebアプリと同じようにインターネットに公開しておけば、検索エンジンがクロールして見つけてくれます。

いままでのSEOのスキルがそのまま使える上、Webはアプリストアとは比べものにならない数のユーザーが、比べものにならないくらいの回数、常に検索を行っています。この圧倒的なオポチュニティ（機会）の違いは、自分自身が今日何回Webを検索したか、アプリストアを何回検索したか、比べてみればよくわかるでしょう。

インストール可能

PWAはさまざまなデバイスにインストール可能ですが、そのためにプラットフォームごとに違う開発言語で書き直したりパッケージンクしなおしたりする必要はありません。PWAをサポートしているWebブラウザーであれば、同じアプリケーションをその全部にインストールして使うことができます。

また、”インストールしなくても使える”点もメリットです。もともとがWebページなので、ちょっとだけ使ってみるということが可能です。

サービスを試用してみようと思ったときに、”アプリのインストールが障壁になって利用を中断してしまった”、という経験は誰にでもあることでしょう。また、スマートフォンでコンテンツを閲覧中に、突然、アプリのストア画面が表示され、アプリのインストールを促されて不快な思いをしたこともあるかと思いますが、そういったことを避けられます。

PWAであれば提供者もユーザーもアプリのインストールについてのネガティブな点を回避することができます。

再エンゲージ可能

従来のWebページであれば、ユーザーがコンテンツから離脱したあとは、再び訪問してくれることを祈るくらいしかできませんでしたが PWAはサーバー側から通知をPushすることができます。

これによりユーザーに即時的な価値を提供できます。例えば、ECショップであればタイムセールの開始であるとか、オークションサイトであればオークションの開始や、最高落札額の更新などです。

通知機能を適切に利用することで、ユーザー側の機会獲得を増やし、再エンゲージを促すことができます。

逆にどうでもいいことを通知しすぎるとユーザーの心象を害するので注意が必要です。特に、初めてページを訪問したユーザーに「プッシュ通知を許可しますか?」というメッセージを表示するのは避けたいところです。

ネットワーク非依存

PWAはオフラインでの使用が可能ですので、ネットワークの状態に左右されないように作ることが可能です。また、常に使用されるアセットをローカルにキャッシュすることで表示のスピードアップや、回線の使用料を減らすことにも貢献します。

プログレッシブとレスポンシブ

PWAはきちんとその思想を理解して開発すれば、低機能なブラウザーやPWAをサポートしないデバイスにもサービスを提供できます。また、さまざまな画面サイズに対応するためのレスポンシブな機能については、WebにはMedia Queries等、そのためのナレッジもリソースも豊富に存在するため、既存のスキルを活かして機能を実装できます。

安全

PWAはWebコンテンツと同じWebブラウザーの強力なサンドボックス内で動作するため、ネイティブアプリのようにユーザーの強い権限で動作しないため、誤動作や悪意のあるコードによってシステムに深刻なダメージを与えることはありません。またhttpsによる接続でのみ動作するのでサーバーとのやりとりを安全に行うことができます。

リンク可能

PWAはインターネット上でユニークな URL をもっており、ハイパーリンクのあるさまざまなところからサービスに接続することができます。PWAを使用するのにアプリ ストアは必要なく、面倒なインストールプロセスも必要ありません。

PWAのメリットは、Webとネイティブ アプリのメリットを合わせたということだけでなく、それらを状況に合わせて取捨選択できることです。

Progressive Web Appsを実現するAPI

ここからはPWAを実現するためのAPIと、それらをどのように使ってアプリケーションを構築していくかについて紹介します。

Service Worker

PWAを実現する上で中心となる機能を提供するのが、Service Workerです。

Service Workerとは何か？ 端的に言うと、「バックグラウンドで動作する“プログラミング可能な”ネットワークプロキシ」です。

Service WorkerはWeb Workerの一つで、Webページのスクリプトとは独立して動作しており、DOMにアクセスしたりすることはできませんが、Webページのネットワークリクエストすべてをインターセプトできます。

つまり、Webページからのリクエストを横取りしてキャッシュしたものを返したり、改ざんしたりといったことができます。そのため localhost、127.0.0.1接続以外はhttpsの使用が必須となります。

Service Workerが提供する機能

Service Workerが提供する機能は主に以下の4つです。

• キャッシュ
• リクエストのハンドリング
• Push通知
• バックグラウンド同期

これらの機能を図で紹介します。

キャッシュとリクエストのハンドリング

Service WorkerはWebページからのリクエストの中に、自分のキャッシュリストに含まれるアセットを見つけると、レスポンスからこれを取得してキャッシュします。

それ以降、Webページからリクエストされたアセットがキャッシュ内に存在する場合は、そのキャッシュされたアセットを返します。ネットワークから取得しないので、アセットの取得は高速に完了し、通信コストは発生しません。

Push通知

関連付けられたWebページがアクティブでなくても、サーバーからのPushを受け取り、Notification API等を使用してユーザーに通知を行えます。

バックグラウンド同期

オフライン中にユーザーが行った操作をキャッシュし、

オンライン時にその内容を同期することができます。

このように Service Worker はプログラミング可能なネットワークプロキシとして、これまでにないさまざまな機能を提供します。

これらの機能の2018年6月時点のサポート状況は以下のとおりです。

ここからは、Service Workerの具体的使い方について解説していきます。

Service Workerを使う準備

Service Workerを使った開発を行う際に用意しなければならないものがあります。

まず、Service Workerを利用するためのWebアプリケーション、もしくはWebコンテンツが必要です。これはけしてSPA(Single Page Application)のようなアプリケーション然としたものである必要はなく、既存の一般的な Web ページであってもかまいません。

このWebページ、もしくはWebアプリケーションは、htmlやcss、jsや画像に代表されるメディアといった複数のファイルで構成されていると思いますが、それとはべつにService Worker用のJavaScriptファイルをひとつ用意します。ここでは便宜上sw.jsと名付けます。

このService Worker用のJavaScriptファイルはWebコンテンツ側のJavaScriptコードから登録され稼働を開始します。

Service Workerは、自身のファイルが配置された以下のディレクトリに対しスコープを持つので、コンテンツ/アプリケーション全体をキャッシュするなど管理下におきたい場合はWebサイトのルートに配置します。

Service Workerの登録

Service Workerの登録はWebコンテンツのJavaScript から行います。

登録に必要なコードは非常にシンプルで、最低限、以下のコードで問題を発生させることなく、Service Workerの登録が行えます。

Webコンテンツ側のコードから、navigator.serviceWorker.registerメソッドにより、Service Workerの登録が行われると、Service Worker用のJavaScriptコード（ここではsw.js）ではinstallイベントが発生します。

install イベントハンドラ内では、キャッシュを開き

キャッシュにアセットのリストを登録します。

Service Workerが登録され、installイベント内の処理が無事に完了すると、次にactivateイベントが発生します。（もしinstallイベント内の処理が失敗した際にはerrorイベントが発生します）

installイベント内で”しなければいけない処理”というものは特にないのですが、一般的に古いキャッシュを削除するのに使用されます。このサンプルコードではキャッシュからキーの一覧を取り出し、

キャッシュの名前（新しく指定された）と比較し、異なるものをすべて削除しています。

上記サンプルコードの、”キーの一覧と新しく登録されたキャッシュの名前を比較して異なるものをすべて削除してしまう”、というやり方は少々乱暴かもしれませんので、実際に実装を行う際にはどのようにキャッシュの削除を行うかは十分に考慮してください。

なぜ、activateイベントでキャッシュを削除するのか？

Service Worker自体は、Service Worker用のJSファイルを更新することで再登録されますが、キャッシュが削除されるわけではありません。よって、いずれどこかのタイミングで用済みとなった古いキャッシュを削除する必要が出てきます。

例えば、キャッシュの対象となっているindex.htmlに更新があった場合は、更新前のindex.htmlを保持しているキャッシュを削除しないかぎりユーザーにはいつまでも更新前のindex.htmlが表示されることになります。

Service Worker用のJSファイルが更新されたあと、新しいService Workerはバックグラウンドでインストールされますが、まだ動作はしません。新しいService Workerに制御が移るタイミングは、古いService Workerが制御しているすべてのページが閉じた後からになります。そのためinstallイベントで古いキャッシュを削除してしまうと、まだ動作している古いService Workerはキャッシュを使用できなくなってしまいます。

一方、activateイベントではページの制御が新しいService Workerに移っているので、古いService Workerが使用していたキャッシュを削除することができます。

何をキャッシュさせるか？

Service Workerにキャッシュさせるべきは、App Shellです。App ShellはアプリケーションのUIが機能するために必要な最小限のリソースです。App Shellをローカルにキャッシュすることで、アプリケーションのUI表示と使用可能となるまでの時間を短縮することができ、オフラインでの使用も可能になります。また要件に応じて、キャッシュが有効となるアセット類を指定してもよいでしょう。

しかし、何でもキャッシュさせればよいというものでもありません。例えば、WebGLベースのゲームは、一般的に使用するアセット類のサイズが大きく、これを毎度起動する際にサーバーからダウンロードするのは時間もかかり、通信コストもかさみます。たしかに、これらをキャッシュさせておけば、通信コストを下げ、ゲーム開始までの時間も短縮できます。

しかし、キャッシュストレージの容量には制限があり、また、cacheオブジェクトの代わりに容量の大きいIndexedDBを使用したとしてもクライアントのストレージを占有することになります。

PCなどのストレージ容量の大きいデバイスではあまり問題にならないかもしれませんが、スマートフォンのようなモバイルデバイスではストレージ容量を圧迫することにつながります。よって、なにをキャッシュさせるかは十分に考慮する必要があります。

リクエストのハンドリング

Service Workerは有効化(activate)された後、アイドル状態となり、WebページからのリクエストやサーバーからのPushを待ちます。

アイドル状態のとき、制御下にあるWebページでリンクをクリックするなどしてネットワークリクエストが発生するとService Worker ではfetchイベントが発生します。

fetchイベントハンドラの引数として渡されるオブジェクトに、発生したリクエストが含まれるので、同リクエストがキャッシュ内に存在するのか調べ、

キャッシュ内にリクエストが存在すればそれを返し、存在しなければfetchメソッドを使用してネットワークにリクエストを投げます。

それぞれの処理結果をリクエスト元のWebコンテンツ側に返します。

この動作により、Webコンテンツ側ではService Workerやキャッシュを意識することなく、これまで通りの方法でページの制作を行うことができます。

また既存のWebコンテンツにService Workerの機能を追加する場合も、Service Workerを登録するためコードを追加する以外の作業は基本的に必要ありません。

de:code 2018のセッション動画でService Workerを追加するデモを行っていますので、ぜひ実際の動作をご覧ください。

Web App Manifest

Web App Manifestは、デバイスのブラウザーによって[ホーム画面に追加]される際のアイコンや、ホーム画面から起動した際のスプラッシュアイコンや背景色、アプリケーションが動作するウィンドウのスタイルを定義します。

manifestは、json形式で記述し、以下のようなlinkタグをWebコンテンツ/アプリケーション側に追加して参照させます。

Web App Manifestについては、詳しい解説がMDNにあるので、そちらを参照することをお勧めしますが、以下に簡単な説明を兼ねたサンプルを掲示します。

de:code 2018のセッション動画でWeb App Manifest を追加するデモを行っているので、ぜひ実際の動作をご覧ください。

現在のWindows 10バージョン 1803のProgressive Web Appsの動作

なお、2018年6月現在のWindows 10バージョン1803(OS ビルド 17134.112)では、残念ながらWeb App Manifestによるウィンドウの制御は有効になりません。

例えば、Windows 10のMicrosoft EdgeでProgressive Web Appsのページをタスクバーにピン留めして起動したとしてもWebブラウザーのUIを表示したまま起動してきます。

Windows 10でProgressive Web Appsにそれらしい動作をさせるにはUWP(Universal Windows Platform)アプリでラップする必要があります。

しかし、Windows 10の次のアップデートでは、Web App Manifestのdisplayの設定に対し、PWAのウィンドウは以下のような表示になるそうです。

マイクロソフトのProgressive Web Appsへの
取り組み

Windows 10の[Microsoft Store]から Progressive Web Appsとして作られたアプリを入手することができます。

Web App Manifestのところで書いたとおり、現在のWindows 10にプレーンな Progressive Web Appsをインストールしても、ネイティブアプリのような外観にはなりません。そのためMicrosoft Storeから入手できるProgressive Web AppsはUWPアプリにラップされています。

MicrosoftストアでのProgressive Web Appsの公開

MicrosoftストアでProgressive Web Appsを公開するには 2つの方法があります。

1つめがBingによる自動インデックスによる登録と、2つめがProgressive Web Appsの提供者がMicrosoftストアにProgressive Web Appsを提出するセルフパブリッシングです。

以下でこの 2つの方法について紹介します。

Bingによる自動インデックス(BETA)

現在はまだBETAの状態ですが、BingがWeb上のProgressive Web Appsを検出し、レビューを行い、自動的にMicrosoftストアに公開します。

Bingに自動インデックスされるための条件は、現在のところ以下のようなものがあります。

• HTTPS、セキュアなエンドポイント
• 高品質の manifest
• オフラインサポート
• ストアの審査をパス
  • デジタルグッズを販売しないこと
  • アダルトコンテンツを含まないこと
  • 不快なコンテンツは不可
• Windowsならではの差別化がされている

上記リストで、最後の”Windowsならではの差別化がされている”というのは、少しわかりづらいかもしれません。

Microsoft Storeで公開されるProgressive Web Appsは、UWPアプリにラップされるのでWinRT (Windows Runtime) APIを使用することができます。

つまりWinRT APIを使用することで、Windows 10で使用した際には、純粋なProgressive Web Appsからはアクセスできないプラットプラットフォームやハードウェアリソースの機能を使用することができるため、これらを利用した機能を実装することで差別化を図ることができます。

Microsoftストア向けProgressive Web Appsの検証

決して、Progressive Web Appsの検証に限ったものでなく、ましてやMicrosoftストア向けのWebコンテンツ用に限定するものではありませんが、WebサイトやProgressive Web Appsの品質をチェックするためのsonarwhalというサービスが公開されています。

sonarwhalはProgressive Web AppsがMicrosoftストア向けの準備がてきているか、だけでなく、一般的なWebサイトやアプリケーションのパフォーマンスやユーザーエクスペリエンス、セキュリティの向上の役に立つ情報を提供してくれます。

Bingに検出されないようにするには

インターネットで公開しているProgressive Web AppsをMicrosoftストアから配布されたくない場合、Progressive Web Appsが以下のいずれかの条件に合致していた場合、Bingは自動インデックスを行いません。

• manifest なし
• https なし、もしくは オフラインで動作しない
• Robot.txtファイルが設定されている
• manifestのdisplay設定がbrowser

既に Microsoftストアで公開されているものを取り消したい場合は、アプリを削除するよう reportapp@microsoft.com宛にサービスリクエストを出します。

セルフパブリッシングによるMicrosoftストアでの公開

Bingの自動インデックスに期待するのではなく、明示的にMicrosoftストアでProgressive Web Appsを公開するにはdev.microsoft.comで開発者アカウントを取得し、パッケージ(appx)化してMicrosoftストアに提出します。アプリの内容がMicrosoftストアの審査をパスすればMicrosoftストアで公開されます。

Progressive Web Appsをパッケージ化するには以下の方法があります。

• Visual Studio 2018 を使用する
• PWABuilder を使用する
• pwa-builder CLI を使用する

PWABuilder

PWABuilderはインターネットにホストされているサービスで、同じくインターネットにホストされているWebアプリケーションのためのmanifestファイルやService Workerのコード、Service Workerを登録するためのコードを生成します。

また、UWPのHostedアプリのパッケージも生成できるので、Progressive Web AppsをMicrosoftストアで公開する際にはこれをストアに提出します。

PWABuilderを使用した既存のWebアプリケーション用のmanifestファイルやService Workerのコードを生成する手順については de:code 2018 の セッション動画のデモをご覧ください。

Windows ストア(UWP) アプリの価値

前述しましたが、Progressive Web AppsをUWPアプリ(Hosted Web アプリ)としてラップすることで WinRT が提供するすべての機能を利用することができます。

これは予定表やアドレス帳といったプラットフォームが提供するソフトウェア的なリソースはもちろん、USBやセンサー類といったハードウェアリソースも含まれます。

アプリケーションが通常のWebブラウザー上で動作しているのか、UWPで動作しているかは JavaScriptのif文で簡単に判断できるので、WinRT APIにアクセスするためのコードをインターネットでホストされているコンテンツに含めておくことができます。

JavaScriptで記述したUWPから,WinRT APIを使用するサンプルコードは以下に豊富に用意されているので、Windows 10限定となってしまいますが、純粋なProgressive Web Appsの機能だけでは実現できない要件がある場合は、こういった方法もあるということを覚えておくとよいかもしれません。

・コードサンプル – Windows アプリの開発

Visual Studio 2018を使用してProgressive Web AppsをUWPでラップし、WindowsRT APIを使用する方法については、de:code 2018 のセッション動画のデモをご覧ください。

その他、Progressive Web AppsをUWPとしてMicrosoftストアに公開することで、Microsoftストアの提供するマーケティングデータ (ダウンロード数、ユーザーの性別、年齢層、国、etc.)や、決済のためのストアのAPIが利用できたり、人気があればMicrosoftストアのトップページに掲示されたり、とさまざまなメリットもあります。

しかも、Hostedアプリであれば、共通のコンテンツでありながら純粋なままのProgressive Web Appsがインターネットでホストされているので、アプリストアを通さない場合のメリットも享受できます。

【参考】
・Windows デベロッパーセンター – PWAとWindows10

この記事では、UWPのHostedアプリについて紹介しましたが、Apache Cordovaでもさまざまなモバイル プラットプラットフォーム向けに Hostedアプリを開発することができます。興味のある方は以下の記事をご覧ください。

・Create a hosted web app using Apache Cordova

Progressive Web Appsの価値を高める API

ここまでWindows 10で動作するUWPアプリでラップされたProgressive Web Appsの紹介をしていましたが、ここからは再びプレーンな Progressive Web Appsについてです。

Progressive Web Appsは、ネイティブアプリのような体験を提供しますが、WebアプリケーションなのでWebブラウザーの機能を超えて動作することはできません。

例えば、表示速度や動作速度はネイティブアプリと比較するとどうしても劣ります。

しかし、Webブラウザーで新しくサポートされた以下のような機能を使用すれば、その能力的な差を縮めることができます。これまでの Webコンテンツにはなかった新しい体験をユーザーに提供したり、決済の仕組みもWeb標準のAPIを使用してこれまでよりも少ない工数で組み込むことができるので、これらを使用してアプリケーションの価値を高めることができます。

• CSS3 3D Transform関連等GPUを使用する設定があり、これを意識的に利用することで描画速度を向上させることができます。
• WebAssembly C言語などで記述し、あらかじめコンパイルしたものをWebブラウザーで動作させるため高速な計算が可能となります。
• WebVR VRデバイスの提供するAPIをサポートし、ユーザーによりImmersiveな体験を提供できます。
• Web Payments 決済画面その他、支払いに関する機能を提供します。これとPaypalやStripeなどが提供する決済用のAPIを繋げれば少ない工数で独自に決済期の機能を実装できます。自前の決済の仕組みがあれば、もう何かを販売するたびにアプリ ストアに使用料を支払う必要はありません

この他にも、最新のWebブラウザーにはこれまでできなかった機能が日々搭載されてきます。そういった新機能をいち早く利用できるのも、逆にレガシーなWebブラウザーには引き算した機能を提供できるのもProgressive Web Appsの良いところです。(もちろん、そう作れば、ですが)

Progressive Web Appsの位置づけ

PWAことProgressive Web Appsは「ネイティブアプリのような体験を提供する」という言葉が独り歩きしてしまい、まるで「ネイティブアプリを置き換える」といった印象を持っている人も多いようです。とはいえ、「ネイティブアプリを置き換えることはできない」というのも真ではないでしょう。

例えば、スマートフォンアプリには、アプリとしてインストールさせるためだけに外側をWeb Viewでラップしたいわゆる「ガワアプリ」と呼ばれるものがあります。こういったものは今後はProgressive Web Appsに置き換えられていくでしょう。

実際にイベントサイトや、カンファレンスのセッションスケジュールの部分をPWA化してユーザーが持ち歩けるようにしているサイトはすでにいくつか存在します。

• ABC 2018 Spring | 日本最大級のAndroidデベロッパーの祭典
• ng-japan – The Angular conference in Tokyo, Japan (2018/6/16)

こういったものもProgressive Web Appsが出てくる以前はWebページとは別にスマートフォン用のアプリを、場合によってはプラットフォームごとに別々の言語で開発し、それぞれのアプリストアに提出して審査を受けるといったことをしていました。

Webページとアプリの開発が共通化でき、配布の手間もかからないということは予算や時間的にも非常に大きなメリットがあります。

しかし、Webブラウザー内のJavaScriptからアクセスできないプラットフォームの機能を利用するアプリケーションや、高速な動作や描画を必要とする用途には今後もネイティブ アプリが選択されることでしょう。

Progressive Web AppsはWebアプリケーションとネイティブアプリの体験的なメリットを受け継ぎ、ちょうどその中間に位置し、その隙間を埋めるものです。

Webのページではpoorだったもの、逆にネイティブアプリではtoo muchだったものが、Progressive Web Appsには最適なのかもしれません。

少し作って試すだけの実装ならそれほど難しくありませんので、気になる人はぜひProgressive Web Appsを作ってみることをお勧めします。

HTML5 Experts.jp編集部の馬場です。
いよいよ2020年度から小学校でプログラミング教育が必修化されますね。
今回の「Webの未来を語ろう2018」は「プログラミング教育」がテーマです。

HTML5 Experts.jpの白石編集長をモデレーターに、プログラミング教育の最前線で活躍中の、みんなのコード利根川裕太さん、ライフイズテック水野雄介さん、日本マイクロソフト春日井良隆さんをお招きし、プログラミング教育の現状からプログラミング教育必修化の課題、その先に目指す未来について語っていただきました。

今回のゲストプロフィール

ライフイズテック株式会社 代表取締役CEO 水野 雄介さん
1982年生まれ。慶応義塾大学理工学部物理情報工学科、同大学院在学中に、開成高等学校物理非常勤講師を2年間勤める。卒業後、人材系コンサルティング会社に入社。教育変革を掲げ、退社後、2010年7月、ピスチャー株式会社（現ライフイズテック株式会社）設立。シリコンバレーIT教育法をモチーフとした中高生向けIT教育プログラム「Life is Tech!」を立ち上げる。現在延べ15000名の中高生がLife is Tech !に参加。

NPO法人みんなのコード 代表 利根川 裕太さん
一般社団法人みんなのコード代表。慶應義塾大学経済学部卒業後不動産デベロッパーへの勤務を経て2011年よりラクスル株式会社に立ち上げより参画。2014年Hour of Codeのボランティア実施後プログラミング教育の必要性を感じ、2015年7月一般社団法人みんなのコードを設立し代表理事に就任。2016年、文部科学省「小学校段階における論理的思考力や創造性、問題解決能力等の育成とプログラミング教育に関する有識者会議」委員。

日本マイクロソフト株式会社 プロダクトマネージャ 春日井 良隆さん
岐阜大学 教育学部を卒業後、大沢商会、アドビ システムズを経て、マイクロソフトに入社し、ExpressionとSilverlightのマーケティング戦略を担当する。その後、エバンジェリストとして、ユーザーエクスペリエンスやHTML5、プログラミング教育の普及に奔走し、Imagine CupやHour of Codeの日本での活動を主導する。2015年よりWindowsのプロダクトマネージャーとしてコンシューマ市場を、2017年より教育市場を担当。

プログラミング教育のこれまでの取り組み

白石：まずは皆さんの自己紹介と、プログラミング教育との関わりについてお聞かせください。

水野：ライフイズテック水野です。これまでプログラミング教育は重要だと言われながら、社会がなかなかついていけてなかった。プログラミングスキルは「やりたい」「好き」という気持ちがないと伸びないと考え、7年半前に中高生向けIT教育プログラム「Life is Tech!」を立ち上げました。

「Life is Tech!」は春夏冬休み中に、3～8日間のキャンプ形式でiPhoneアプリやゲームを作りながらプログラミングを学びます。1回150～200人の中高生が参加し、5～6人が1チームになり、大学生がメンターとなって中高生に教えています。これまで延べ27,000人が参加しており、世界2位の規模となりました。

Life is Tech!では、ただプログラミングのスキルをつけるだけでなく、好きな仲間と出会ったり、尊敬する大学生のメンターに学ぶことでこんな先輩になりたいと思ったり、夢中になれることを見つける体験をしてほしいので、大学や企業など、中高生にとって非日常な空間でキャンプするということを大事にしています。

▲「Life is Tech!」キャンプの様子

有料コースと無料コースがありますが、全体の1/3が無料体験会や企業とのタイアップキャンプの参加者です。最近はIoTをテーマに開催したり、NHKさんとAIを学んだりしています。ポケモンGOやUnityのコースも人気があります。参加者には勉強時間はLINEが使えなくなったり、ライバルが勉強し出すと通知が来る機能など、独創的な発想で作った勉強管理のアプリを作り、ダウンロード数が10万超えした子もいます。

子どもたちにはいつもプログラミングの力で「半径2mの世界を自分たちで変えていこう」、さらに「その半径を広げていこう」と伝えています。

▲ライフイズテック株式会社 代表取締役CEO 水野 雄介さん

利根川：僕は大学卒業後、大手の不動産会社に就職し、2011年にラクスルというベンチャーに社長の次にエンジニアとして入って、立ち上げから携わりました。それから4年経った2014年くらいに、エンジニアと非エンジニアの壁をなんとなく感じていたこともあり、アメリカの非営利活動法人Code.orgが展開している「Hour of Code」をみんなでやってみたんですね。

それをきっかけに、こうしたプログラミング教育が日本にも必要だと思うようになり、2015年1月に小学生のプログラミング教育を支援する活動準備を始めました。7月にはCode.orgの日本パートナーとなる一般社団法人みんなのコードを設立しました。

当時はプログラミング教育がこんなに盛り上がるとは思っていませんでしたが、2020年から必修化も決まり、行政・企業との連携を深めながらプログラミング教育の支援活動を広げています。

私たちみんなのコードは、「全ての子どもがプログラミングを楽しむ国にする」というミッションを掲げています。なぜ、全ての子どもなのかというと、プログラミングコンテストはある程度できる子を伸ばすのにはいいけど、全ての子どもの育成に対する取り組みってあまりないと思ったから。なので、裾野を広げるほうを頑張ろうというコンセプトでやってます。

IT人材不足や論理的思考を鍛えるという考え方も大事ではあるんですが、実際に授業でやるときは「プログラミングを楽しむ」というのを第一にして、結果的に子どもの能力が高まるとか、社会で活躍できる人材を育てたいと考えたからです。

「国にする」とした背景は、こういう活動って東京だけ先に進んでしまって、地方との格差が生まれることが多いんですよね。その差を埋めるために地方でも活動しています。とはいえ、全ての子どもに直接教えるのは無理なので学校の先生、特に小学校の先生に対しての指導を行っています。プログラミング教育についてのシンポジウムを開催したり、地方に出向いて体系的に学んでもらったり、実際の授業で使える教材を提供したりなどですね。2017年度のシンポジウムは10都市1000名超の先生に参加してもらいました。これからはさらに拡大していく予定です。

▲一般社団法人みんなのコード 代表 利根川 裕太さん

春日井：日本マイクロソフトの春日井です。Windowsのマーケティング担当として、教育市場を見ています。HTML5 Experts.jpのエキスパートに名前を連ねているように、以前はWeb系の技術のエバンジェリストをしていたのですが、後半は学生向けのエバンジェリズム活動も兼任していて、その頃に知り合ったのが水野さん。

「Life is Tech!」は大学生が中高生を教えるというスタイルで、お互いの年齢が近いから親近感があるんですよね。子どもたちを盛り上げる趣向が凝らされていて「すごい！」って毎回感動しています。しかも、経験と知見が積み重なり、どんどんバージョンアップしてる。

利根川さんとは、彼がCode.orgの日本パートナーとして、みんなのコードを立ち上げた頃に知り合いました。Code.orgはアメリカのSTEM教育（※）の普及を支援するNPO団体で、Microsoft、Apple、Google、Facebook、AWSなど大手のIT系企業が数多くサポートしています。

STEM（ステム）教育：科学（Science）、技術（Technology）、工学（Engineering）、数学（Mathematics）の教育分野を総称する、2000年代に米国で始まった教育モデル。

Microsoftは「Microsoft MakeCode」というMicrosoftが開発した学習者向けのプログラミング環境とコンピューティング教育用教材を展開しています。最近はIoTを活かしたフィジカルコンピューティングが人気で、micro:bitというマイコンと連携できる「MakeCode micro:bit」が注目されています。USBでつないだmicro:bitをビジュアルコーディングでLEDを光らせたり、温度センサーや加速度センサーを使ったモノ作りにも使えます。理科や技術なんかの教科との組み合わせの相性もいいですよね。

ほかにも、MakeCodeはMinecraft（マインクラフト）をプログラミング教材として使うこともできて、一緒に組み合わせる「Minecraft Education Edition」というマイクラの教育版があります。Minecraftは全世界の子どもがほぼ100％やっている人気のサンドボックスゲームですね。

水野：シンガポールでも大人気で、どこのコンビニでも一番目立つ場所に置いてあります。

白石：うちの小4の息子もすごくはまっていますね。いつもYouTubeの実況を見てます(笑)。

春日井：YouTubeを見て勉強する子も多いみたいですね。古い世代は先生からの一方的な詰込み型の教育が当たり前だったんですが、お互い子ども同士が学び合おうという協働学習の学習効果に注目が集まっていて、Minecraft: Education Editionにはそんなこともできるように工夫されています。

先生が黒板に「ここに集合！」と書いたり、仮想世界にいる子どもをガイダンスしたりする機能もあって、お値段もお手頃。先生が一人、1年あたり544円払えば使うことができます。

実績としておもしろいのは、立命館小学校の事例ですね。京都には、たくさんの観光施設があることはご存じの通りですが、海外の人にもっと知ってもらおうという課題を解決する学習にMinecraft: Education Editionが使われました。

ちゃんと設計図を手に入れて、誰が屋根と庭とかを作るかなどの業務分担をし、訪れた人のアングルまで徹底的に考え、議論しながら作っています。先生はあくまで手助けするだけで、子どもたちが主体的に取り組んでいるところが素晴らしいんです。

Minecraft Education Editionはプログラミング教育だけでなく、STEM教育全般をやろうとしています。例えば、私たちの世代だと元素記号を覚えるだけだったものが、仮想空間の中で水素と酸素を合成すると水を生成するようなことを体験したりします。現CEOのサティア・ナデラの理解もあり、マイクロソフトでは全世界的にかなり教育に力を入れていますね。

▲日本マイクロソフト株式会社 Windows プロダクトマネージャ 春日井 良隆さん

白石：子どものプログラミング教育を支援するのは、Microsoftにとってどういうメリットがあるんですか？

春日井：1つは社会的な責任ですね。。第4次産業革命に向けた人材育成を引き合いに出すまでもなく、ICTのスキルを持った人材の育成は急務です。日本のマイクロソフトの人間として、日本の将来に貢献をしたい。それは、偽らざる気持ちです。

商売的な話をすれば、子どもの頃からWindowsに慣れ親しめば、大人になったらSurfaceを買ってくれるだろうという期待もあります(笑)。あとはスマートフォンに対する、パソコンの意義というのも伝えていきたいと考えています。

世界のプログラミング教育はどうなっている？

白石：続いては、世界のプログラミング教育どうなっているかについて伺いたいと思います。1月にロンドンで開催された「BETT」という教育イベント、皆さん行かれてるんですよね？

利根川：私も行ってきました。

春日井：BETTは世界で一番大きい教育系のイベントで、国を挙げてブース出しているところが多く、今年の韓国は大きかったですね。でも、日本はブース出してないんですよ。遅れをとるのではないかとかなり心配しています。

利根川：僕は課題はあるけど、単純に「遅れててやばい」という論調は一面的過ぎると思っています。例えば、グローバルでもプライベートの塾はまだあまりないし、日本の小学校でも先進的な取り組みをやっている先生もいます。

春日井：正確に言うと、プログラミングができる最先端の人材を生み出す高等教育に対する取り組みが遅れているんじゃないかと思っています。

水野：そもそもプログラミング教育の前に、まずパソコンが扱えて、パソコンでものが作れることが必要なんですが、Wifiやパソコンの設備が整っていないですね。以前シンガポールに住んでいたんですが、向こうもそれほど進んでいるわけでもなくて、やはり（プログラミングができる）先生が少ない。

英語は「できない」というマイナスの状態から、「できる」というゼロにすることだけど、プログラミングはゼロをプラスにする学びなので、ほぼ横一線。日本はものを丁寧に作るとか、ソフト面では勝っているので、まだ可能性はあると思います。

利根川：僕も横と比較して嘆くより、これからどれだけ良くしていくかの方が重要で、先に進んでるところからどうやれば前に進めるのかを学べばいいんじゃないかと。アメリカが進んでたらそこからカリキュラムを学べばいいし、悲観する必要はないと思います。

▲HTML5 Experts.jp編集長 白石俊平

白石：ちなみにどこの国が進んでるところかありますか？

利根川：アメリカは進んでますね。あとはイスラエル、イギリス。特にイングランドはコンピューティングという教科があり、小中高と授業があります。時間枠、教科書、センター式みたいな試験もあって枠組みや体制が整っています。

春日井：ちょっと前に話題になった内閣府では、諸外国の若者と比較すると、日本の中学生のスマホの所有率はあまり変わらないのですが、パソコン所有率はかなり少ないという結果になっていました。

水野：普通に向こうは小学3年生からiMovieから動画作ったりしますからね。Googleドライブで宿題出したり、リテラシーの差はかなり大きい。

白石：今の子どもたちはPCがなくてもタブレットやスマホでやっちゃうことが多いですよね。

利根川：コンテンツの消費側はそれでもいいけど、制作する側になるとまだ本格的なところはPCでないとつらいと思います。

春日井：消費は間違いなくスマホ。でも何かクリエイトする時は、PC、キーボード、大きな画面がないと難しい。

白石：ではそういう話やデータから考えると、作る力は育っていかない可能性がありますか？

春日井：なんとかしないといけないですね。

利根川：個人の家庭、学校によっても差が出てくる面もあります。

白石：そういう課題が浮き彫りになり、未来に進んでいかなくてはいけないという話になってきたので、プログラミング教育のこれからの話に進みましょう。

プログラミング教育のこれから

白石：プログラミングの義務教育化の話が出ましたが、ざっくばらんにお聞きしたい。調べたところ「コーディングを覚えることが目的ではない」とか「プログラミング的思考」が大事とか、賛否両論あるらしいですね。アンプラグドコンピュータサイエンスというパワーワードもあったりして。

利根川：よくプログラミングが2020年から必修化になるってメディアに出てるので勘違いする方もいるのですが、正確にいうと小学校、中学校、高校がプログラミングを教えないといけないんですよと指導要領は出ますが、プログラミングという教科ができたり、コードの書き方そのものの授業をやるわけではないのです。その指導要領は10年に一回しか変わらなくて、そのタイミングが小学校が2020年、中学校が2021年、高校が2022年になります。

現状どのくらいプログラミングを授業に取り入れているかというと、小学校についてはほぼなくて、たまに面白いことをやりたい学校や、2020年を見据えて先行的にやる学校がまれにあるくらい。中学校は今の指導要領でも技術課程の中で、4～8時間くらいロボット制御の計測という授業があります。ただこれも問題が山積みで、教科書には入ってはいるけど、ちゃんとやらない先生もいます。

高校は情報という教科の中に、理系よりの「情報の科学」と文系よりの「社会と情報」という科目があり、プログラミングは情報の科学の中にのみ入っています。ただし、学校ごとに開設科目は決まっていて、配分は15％：85％と情報の科学が少ないという状況です。

水野：そうですね。その15％もかなり初歩的な内容が多く、僕が衝撃を受けたのは、テストの問題で「キーボードのここはAですか？Pですか？」って問題が出てたこと。キーボードの位置を覚えることに価値はないし、問題山積みな状況です。

利根川：そして、小学校は算数とか理科の中で、多角形をプログラミングで書いてみる。書くというより、プログラミング体験してコンピュータに指示する感覚をつかみましょうというかんじですね。中学校は今の指導要領にあるロボット等の制御の内容に加えて、ネットワークを使った活動が増えて、今やっていることを倍増にするイメージです。

高校は「社会と情報」と「情報の科学」を統合して情報の科学よりの「情報Ⅰ」という必履修にして、これまで15％しかやってなかったことを100％にして、教科の中に入っていくといったかんじです。プログラミングという単独の教科はありません。

白石：小中高とプログラミングという教科は出てこないと。小学校においては、現在技術課程でやっているのを2020年以降は理科とか算数で、もうちょっと厚めにやるということでしょうか？

利根川：小学校は現時点ではゼロです。ゼロの状態から算数・理科の科目で体験というかたちでやります。ただ、一斉に始められるものでもないので、去年くらいからトライアルが始まっているというかんじです。

白石：まず授業ができるのかが気になりますね。教える科目・内容は学校や先生任せだということですがそこは変わるんですか？

利根川：最低限の基準はありますが、そこは変わらないですね。

春日井：一応教育委員会の皆さんも、変えようとはしていますけどね。

白石：学習指導要領とかって全然わからないんですけど、一応ほかの理科、算数、社会などはここまでやろうよというのは決まっている？

春日井：ざっくりしたガイダンスとかは決まってますね。

白石：たとえば高校3年生の数Ⅲとかだったら微分積分といったところまではやろうとか。

利根川：そういうのは決まってますね。小学校も算数・理科は教科書には書かれるので、多角形を書くのをプログラミングでやってみましょうとか。

白石：でも今の話だと、教科書の内容もバラバラかもしれないと。

利根川：中学校の技術課程くらいになると、あまり教科書は使われなくなるんですよね。副教材中心で、教科書は参考書くらいの扱いになっていくと思います。

白石：「プログラミング教育はコーディングを覚えることが目的ではない」といった内容がブログで書かれて話題になってましたが、どう感じてますか？

利根川：文科省としては、小学校段階からちゃんとプログラミングそのものを学習のターゲットにしようとしています。しかし小学校は全国で2万校あって、40万人の先生がいますが、そのほとんどの先生がITリテラシーが高いわけではありません。その状況から数年でプログラミングを教える環境にするのは無理なんですよね。

春日井：僕が小学生の時は書道やそろばんの塾や、授業で音楽・体育・技術とかやりましたけど、みんな音楽家や書道家になるわけじゃなくて、教養として必要だからやるというかんじでしたよね。

中には体育の授業でスケートを知って、冬季オリンピックを目指すことを決意した子もいるかも知れない。プログラミングもこれから必要になる教養、あるいは未来の可能性をひらくきっかけだと思っています。

利根川：例えば環境問題って家庭科でも理科でも社会科でも、ごみ処理や温暖化などについてはいろんな教科をかいつまんで学ぼうというのは、少しでも興味を持ってもらうために文科省がよくやるやり方です。個人的にはもっとちゃんとやってほしいという思いはありますが、現実的な第一歩としてはしかたがないかもしれません。

白石：でも、そのまま10年間変わらないというのは問題なのでは？

利根川：そうなんです。そこが問題なんですよね。

白石：IT人材を増やすという直接的な影響にはならなさそうですか？

春日井：いわゆる第四次産業革命の人材を育てると国が打ち上げたので、そこに合わせて一つの指導要項が組まれたという背景はありますね。

利根川：文部科学省・経済産業省・総務省、それぞれ動きはかなり違いますね。学校の授業の中で何を教えるのかは文部科学省、総務省は学外や部活や地域であったり、基礎スキルがある人をどうやって伸ばしていくか。経産省はグローバルに発展させるための人材の輩出だったり、このEduTechというものを産業にしていこうとか。文科省だけにとどまらない動きがあります。

学校教育、特に小学校中学校は職業教育じゃなくていろんなチャンスに気づくための機会。30～40代はプログラミングに触れたことがあるのは10％いるかいないかなんですが、この世代になると100％になるんですよね。やってみたら面白いとか伸びそうという子どもの母数が増えて、未来の仕事につながればいい。学校教育としては、そうした体験をしてもらう機会を作るというのが責務になります。

Life is Tech !のような塾・クラブ活動、CoderDojo（コーダー道場）みたいなコミュニティは、よりプログラミングをやりたいという子を伸ばすところ。学校教育にプロフェッショナルな体験を期待しすぎるのはちょっと筋が違います。

ただ政府としては第四次産業革命というムーブメントを起こし、この国をAIやIoTといったテクノロジーの力で、もう一度元気にしようという動きがあります。プログラミング必修化になったのも、ある種内閣内のバズワード、必修化するときの体制を第四次産業革命に生かすため。これらの取り組みで興味が出てきた子のスキルを伸ばし、価値を提供する側に育成するという動きが経産省でも出ています。

社会はどう変わる？子どもたちにはどう教えればいい？

白石：最後は社会がどう変わるか、子どもたちにどう教えればいいんだろうというテーマについてお聞きしたいと思います。どうやったら楽しく効率よく教えることができるのでしょうか。

春日井：白石さんは、今お子さんに何かやらせてるんですか？

白石：うちの小4の息子はHour of Codeから始めました。でもHour of Codeはわりとさくさくできちゃって、次にスクラッチやらせてみたんですが、UIがイマイチいけてないかんじがして…（苦笑）。あとは「プログラミン」をずっとやってました。

最近はビジュアルプログラミング言語で、Minecraftを題材にPythonを教えてました。でも、その辺りから興味が失ってきちゃって。原因はいろいろあると思うのですが、まずプログラミングは多少英語を知ってないとできないんですよね。

例えば、英語でimportと言われてもまったく意味がわからない。すべてがおまじない。コマンドラインをたたかなくてはいけないんですが、そういう単調作業が面倒くさくなってしまってる。親が「やりなよ～」と言うと、逆に嫌になっちゃってる状況なんです。

利根川：そもそも白石さんの「教えよう」というのは、あまり筋がよくない気がします(笑)。基本的に「やりたい」と思ったときに、すっと出す方がいい。いわゆる従来の勉強が嫌いになるのと同じことをプログラミングでもやろうとしている。それであれば教えないほうがよくて、興味を持ったときに教えてあげたほうがいい。特に家庭では子どもに押し付けるとよいことがない気がします。

水野：10歳以上になってくるとだんだん自我が芽生えてくるので、まずお父さんやお母さんがめちゃくちゃ楽しそうにやってることに食いつくんですね。それができないとしたら、僕はコミュニティだと思います。楽しく効率的に学べるかはコミュニティ。

子どもはその場の雰囲気やそこにいる人たちと学ぶことが楽しいとか、ライバルに負けたくないとか、コミュニティに所属することによって子どもたちは成長する。10歳以上になって自分たちが教えられないのなら、自我に任せつつ、そういうところに行かせたほうが伸びると思います。

春日井：でも、白石さんみたいにPython書けるお父さんがいる家庭はなかなかないですよね。

白石：子どもたちも楽しくやってたし、最初はやりたがってたんですけど、そこをどううまく育てていけばいいのかなって考えちゃうんですよね。

水野：英語もそうですよね。5歳くらいのときは楽しかったけど、親が話せなくなると、だんだん楽しくなくなってくる。例えばインターナショナルスクールに行って友だちと毎日楽しく話していると、話せるようになるのと同じことだと思います。

白石：ライフイズテックさんは子どもが「プログラミングをやりたい」って、参加するんですか？それとも親が「やってみたら？」と勧めて参加させてるかんじなんですか？

水野：基本的には子どもたちが「やりたい」と言って参加してきてくれます。僕ら教育者の仕事は、子どもがやりたいって思ってくれるようなものを作る、HPの作りもそうだし、チラシもそうです。オリンピックで飛んでたドローンやPerfumeのプロジェクトマッピングみたいに、子どもたちに作ってみたいと思わせる欲求や、キャンプに参加してみたいというワクワク感を出させることが教育者側のやるべきことだと考えています。

白石：それは子どもたちに直接アプローチしないと、Life is Tech!のキャンプの情報は伝わらないと思うんですが、どうやってるんですか？親とかならいろんなメディアを見ていると思うんですけど。

水野：学校でのクチコミや、友だちの紹介が多いです。先生も自分たちでは教えられないからと、学校単位でキャンプをやったりとか。マイクロソフトさんで、品川女子学院と聖光学院でコラボキャンプをやったこともあります。

親としてはマイクロソフトを見に行けるし、品女の子は共学の雰囲気を楽しめる。きっかけは何でも、結果的に興味を持ってくれればいいんですよね。

春日井：マイクロソフトがMinecraftを教育用にカスタマイズしようとしたのはまさにそれで、子どもたちは興味を持たないとやらない。子どもはMinecraftが大好きなので、だったら教材にしましょうと。Excelでマクロ組んでみましょうっていう授業だったら、楽しくない。

白石：でも、Education Editionは先生しか使えないとのことですが、一般家庭でやるにはどうしたらいいですか。

春日井：最近は教育機関じゃないところでもできるようになってきました。ただMinecraftをパソコンで使う場合、Java版とWindows 10 Editionの2パターンあるんですね。

白石：うちの息子はJava版ですね。

春日井：Pokect Editionは、どんどん、Java版に近づいているのですが、その、Pocket EditionのWindows10版を「Minecraft Windows10 Edition」と言います。Windows10のストアから3,150円でダウンロードできるんですが、これは最初にお話したMakeCodeとつなげられるようになっています。Code Connectionという無償のツールをインストールするだけなので、ぜひやってみて下さい。大人がやっても楽しいですよ。

白石：みんなのコードでは、プログラミング教材「プログル」というツールを作られているんですよね。

利根川：プログルは小学校の算数の授業、主に小学校5年生を対象に、学校の先生が使うために作ったプログラミング教材です。多いときだと1日1000人くらいの児童が使ってくれていて、従来の多角形の学習よりは楽しいと思います。

白石：2020年以降はが爆発的に全国の小学校で使われると。

利根川：そうなるといいですね。うちでプログラミングをやるとしたら、スクラッチとかマイクラのほうが楽しいと思いますけど(笑)。

先生がちゃんと自分が楽しいと思って授業やクラブ、学校外でもやってくれればいいなと。プログルのホームページも学校の先生向けに作っています。

白石：最後に本日のディスカッションを振り返って、ひと言お願いします。

春日井：子どもの頃にピアノを習って、その後ピアノを弾くことが喜びになる人、音楽を聴くことが喜びになる人、音楽に全く興味が持てなかった人など、人それぞれだと思います。いずれにしろピアノを習うという体験をしなかったらわからなかったことですよね。

これからの社会を考えると、プログラミングもそういった機会が与えられるチャンスが増えていくと考えています。そのための支援や活動を続けていきたいと考えています。

利根川：プログラミングを勉強することで、将来ITで価値を提供する仕事に就いたり、営業やマーケッターの仕事でも少し役立てることがあると思います。でも大事なのは、やってみて合うか、合わないと知ること。やったけど自分には合わないというのを早めに知ることはメリットになります。

一方で懸念しているのは、テクノロジーで豊かになっていく東京と、そうでない地方に国が分断されていくんじゃないかという危機感があります。そうならないように、テクノロジーの教育の場を全国に広めていきたいですね。

水野：ライフイズテックは「テクノロジーを知っている」ということを普及させるために活動していますが、プログラミング教育の本質というのはクリエイティビティを伸ばすことだと考えています。業務を効率化させたり、論理的思考を身に付けたり、テクノロジーを進化させるためのツールを作るにもクリエイティビティが必要です。

クリエイティブ力を伸ばすための教育や施策は今後ますます重要になっていきます。本質となるクリエイティビティやコミュニケーションを大事にしながらやっていきたいと思います。

こんにちは、dotstudioのちゃんとくです。HTML5Experts.jpでは、昨年に引き続き新春企画として「Webの未来を語ろう 2018」を開催することになりました！

ブラウザ編に続く第2弾の今回は、2017年初頭のHoloLens発売に始まり、ARKit/ARCoreとスマートフォン対応の拡充、各地にVR Zone誕生と話題を集め、一挙にホットトピック入りしたxR技術の現在と未来について。各領域のプロフェッショナルを招き、編集長の白石氏をMCに、さまざまな立場から意見交換を行っていただきました。

広がるxR領域の現状と課題、そして未来への期待について、なかなか聞けない学会話や開発事情など、たっぷりとお楽しみください！

ゲスト紹介

諸星 一行氏（いっこう氏）

Mercari, Inc. R4D
株式会社メルカリの研究開発組織”R4D”でVR/AR/MR領域を担当するリサーチエンジニア。 業務の傍らで”xR Tech Tokyo”や”例のハッカソン”といった勉強会やハッカソンなどのコミュニティ運営を行なっている。日本バーチャルリアリティ学会認定VR技術者。

前本 知志氏

株式会社ホロラボ / システムフレンド Co-founder（取締られ役 兼 取締役）
数年前よりモーションセンサーの面白さに取りつかれKINECTを趣味で触り始め、会社にXRや医療機器開発のチームができる。 センサー系飲み会コミュニティTMCNや、HoloLensに特化した株式会社ホロラボの立ち上げメンバー。 米国MicrosoftよりMixedReality分野のMVPとして認められている。

千葉 慎二氏

日本マイクロソフト株式会社
ハドソン中央研究所でゲームのベースシステム等を開発後、Microsoftに転職。ゲーム機向けWindows OSやXbox SDKの開発などを行う。 近年はKinect、HoloLensといった新技術を啓蒙し、研究者や学生向けの支援活動を担当。

2017年に印象に残ったxR領域のトピックは？

白石: 皆さま、本日はお集まりいただきありがとうございます！まずは簡単に自己紹介と、2017年のxR界隈で1番印象に残ったことを教えてください。

いっこう: こんにちは、メルカリのいっこうです。2017年のホットトピックは、MicrosoftがxR領域に本腰を入れてきたことですね。HoloLens、immersiveと、デバイスをいろいろと出してきたのが衝撃的でした。

前本: 株式会社システムフレンドや株式会社ホロラボで取り締まられ役をしている前本です。僕にとっても、HoloLensが発売されたことは大きな出来事でした。HoloLensが出たから、ホロラボという会社もHoloMagiciansというコミュニティもできましたし。HoloMagiciansでのHoloLens日本発売直後のイベントで、80人もの購入者が一同に集まってみんなで繋げたワクワク感はすごかったです。

白石: 80人×約30万……2400万円……。お金の話になるとすぐ計算しちゃう（笑）。

▲ 発売からわずか2週間後に80人が集ったHoloMagiciansミートアップ

千葉: Microsoftの千葉です。もともとはハドソンというゲーム会社でゲームの根底となる部分のシステム開発をしていて、Microsoftに転職してからは16年くらいずっとXboxチームにいました。HoloLensはKinectから派生してできたところがあって、Xboxチームでは一部Kinectの開発にも携わっていたので私がHoloLensのプロトタイプを見たのは実はかなり前のことなんですよね。その頃から開発を続けて、ようやく世に出てきたな、という感覚です。

▲ Xboxをローンチした人にだけ配られるというジャンパーを着た千葉氏

前本: 千葉さんのことはKinect時代から尊敬しているんですよ！僕は当時からKinectで遊んでいて、それがどんどん進化してHoloLensの形になるのを目の当たりにして、感動です。

千葉: お二人がHoloLensをトピックに挙げてくださったように、私にとっては多くの人にHoloLensを使っていただいているということが2017年最も印象深いことです。それとMicrosoftに勤めながら、東京女子医科大学で学生としてHoloLensを使った医療の研究をしています。業務でも研究でもHoloLensを使っています。

白石: えーっ、じゃあ千葉さんは女子大生？周りは女子ばっかりですか？

千葉: 私がいるのは大学院なので、おじさんばかりですよ（笑）。

白石: ちなみに私はHTML5Experts.jpの編集長と、TechFeedというエンジニア向けのキュレーションサイトを作っています。私自身はWeb領域の人間でxRについては素人なので、今日はバンバン質問させていただきます！

VR/AR/MRとは何か？デモで見る各領域の現在

現実と仮想が複合するMRの世界観

白石: 2017年のホットトピックはお三方とも「HoloLens」に関することで一致しましたね。まずはMRについて、現在の様子を伺っていきたいと思います。

千葉: まず伺ってみたいんですが、「Mixed Reality（MR）」という言葉について正しく理解している自信があるという方？

（会場、手が挙がらない）

千葉: なかなかいないですよね。それが一つ、現状の課題なんです。簡単に言うと、MRは現実の世界と仮想の世界が融合しているという形です。どう融合するかにも、現実世界の中に仮想世界を入れ込むとか、逆に仮想世界に現実世界を入れ込むとか、いろいろな考え方があります。MRは、テレビの中に入り込んで、仮想のつくられた世界を見渡すことができ、そこから現実の世界も覗くことができる、というような考え方です。

白石: 仮想と現実がMixする、という意味合いなんですね。HoloLensのデモでは、現実世界をキャラクターが動いたり、現実の壁を割っていたり、というのを見ますが、それはどちらなんですか？

前本: その捉え方は宗教論争に近いものがあるんですよ。

いっこう: Microsoftさんの提唱するMRと、もともと日本バーチャルリアリティ学会が学問として20年以上研究している考え方とで違う部分があるんです「VimかEmacsか」という話に近いです（笑）。

白石: あー、よくわかりました。それは大変だ（笑）。どういう部分でお互いに違うなと思っているんですか？

千葉: デバイスを主体で見るか、現実世界を主体で見るかなど……考え方の違いですね。揉めているわけではなく、「そういう考え方もあるよね」という感じなんですが。

白石: なるほど。話の抽象度が高まってきたので、HoloLensの現在がわかるデモがあるといいんですが。

▲ DNP「AR/VR/MRを活用した体感型デジタルショールーム」（動画リンク）

前本: これはHoroLensだけでなく他のデバイスや技術を組み合わせたデジタルコンテンツエキスポでの展示なんですが、シェアリングという技術を使って同じ空間を共有する仕組みです。

白石: これはHoloLensと、スマートフォン？

前本: そうです。HoloLensとGoogle Tangoの技術を使って、デバイス同士がお互いの位置を認識し、他の人が操作したことを他のデバイスでも検知できるようになっています。「いま隣の人がこの商品をいいねした」とか、「この商品を買った」とか、デバイスを介して共有できる仕組みです。

千葉: 複数の人が同じ世界をそれぞれ見ることができる、というのがシェアリングですね。

前本: 実はtoBの事例も増えてきて、製造業とかデザインの現場とかで活用が進んでいるんですよ。 ▲ ホロラボ「AR CAD Cloud」（動画リンク）

前本: AR CAD Cloudは、CADデータをHoloLensにダウンロードしてその場ですぐに見られるサービスです。モノを作る前に、作ったらどうなるかが確認できる時代になっています。

千葉: 日本で一番最初に業務にHoloLensを取り入れた事例は、日本航空さんですね。1つはパイロットの訓練向け、もう1つは整備士の訓練向けシミュレーションです。飛行機は飛ばしていないと利益効率があがらないので実機での練習は難しく、シミュレータも好きな時に使えるわけではなかった。新人の方なんかは、机の上に印刷した紙を広げて手を置いて、ということをしていたらしいです。

VRでもいいんじゃないかと思うかもしれないですが、訓練では自分の手が認識できることが重要だそうで、外の世界をシースルーで見ることができるHoloLensが向いていたようです。

白石: MRとVRは似たようなことができそうだけど、確実な違いがあるんですね。MRのいいところは「現実世界も見えている」というところですかね。

千葉: そうですね。VRにも現実世界を取り込むことはできるんですが、結局カメラであって目で見る現実とは違うものなんですよね。

白石: Windows MRというのがありますけど、どういうものなんですか？

千葉: 最初のデバイスとしてHoloLensが発売されたんですが、やはりコンシューマー向けとしては高額じゃないですか。裾野を広げたいという意図で、Windows MRと名前を変えて、HoloLensはその一つということになりました。

白石: HoloLensはハイエンドなWindows MR対応デバイスの一つ、というところでしょうか。

千葉: 開発者視点でいうと、HoloLensの開発ノウハウでWindows MRが開発でき、逆も然りと。デバイスも複数社から出ていて、4〜5万円程度とそれほど高額ではないので手軽さは広がったかと思います。

被るだけではないVRの領域

白石: 続いてVRについても伺っていきたいです。

いっこう: 実はVRの歴史は長く、日本バーチャルリアリティ学会は25年ほど、研究分野としてのVRは50年ほど前からあります。ちなみに学会的にはVRを「仮想現実」と訳すのは少しNGで、アカデミア的には「人工現実感」を推していきたいです。……細かいんですが、一応（笑）

白石: 訳にも違いが出るんですか。いまVRではどんなことが実現できるんですか？

いっこう: バーチャルというのは「仮想」ではなく、「姿形はそのままだけど実際にはないもの」なんです。VRというとヘッドマウントディスプレイのイメージですが、実際には被らなくてもそこにあるという捉え方です。例えばドームスクリーンとか、匂い系のデバイスとかもVRですし、舌に電気を流して味を感じるのもVRです。頭に電気を流して、幼女にビンタされる感覚を味わうというのもVRです（笑）。

白石: 世界はそんなところまで行っているんですか（笑）！？

いっこう: 開発者レベルなんですけどね。学術としてのVRとコミュニティのVRはやや溝があり、もう少しうまく繋がったらいいなと思っています。VRはMRに比べてデバイスが多いので、一般のガジェット好きが手軽に楽しめるのがいいところかなと思います。

白石: 先ほどMRはシースルーなところが利点という話がありましたけど、VRの利点はやはり没入するというところですかね？

いっこう: 被るタイプのものだと完全没入型というメリットは1つ大きいですね。あとは学会的な見方ですが、VRは「3C/3E」のための道具なんです。3CはCreation（創造）、Control（制御）、Communication（通信）。3Eは、Elucidation（解明）、Education（教育）、Entertainment（娯楽）です。

Control（制御）はいわゆるロボット制御だけでなく、例えば人が入れない原発などを遠隔で見る、というもVRの領域です。

Communication（通信）というと、最近だとVirtual YouTuber（VTuber）やVRChatが流行っていますよね。VTuberではキヅナアイちゃんがいて、去年くらいから他のVTuberがどんどん出てきてかなり盛り上がっています。アイちゃんを知っている人？

（会場、ほとんどが挙手）

白石: VTuber、VR Chat、初耳です……！流行っているんですね。

いっこう: アイちゃんに関しては既にかなり稼いでいて、スタイルとして確立しているかなと。加えて、最近は割と簡単にVTuberになれる仕組みが整ってきたと思います。ちょうど先日UnityとWindows MR（Lenovo Explorer）を使って、ほぼコードを書かずにVTuberになるという記事が上がっていました。

⇒ 参考: windowsMRでバーチャル生放送をするためのセットアップ

白石: これは、配信をする側がデバイスを被っているということなんですか？

いっこう: そうです。鏡を置いて、ボイスチェンジャーを使って。最近はあえて声はおっさんのままというVTuberが流行っていますが（笑）。

白石: うーん、すごいですね。VR Chatというのは？

いっこう: VR Chatはここ最近でグッとユーザが伸びているんですが、セカンドライフのようなイメージで、自分のアバターを使ってワールドワイドにコミュニケーションできるものです。まだ高いんですが、一般人でも自分の身体を3Dスキャンしてアバターに使う人も出てきました。

⇒ 参考: 3Dスキャンした実写アバターで「VRオフ会」する猛者が登場　これもうオフかオンかわかんねぇな……

白石: これはどうやって移動するんですか？実際に歩いて動く？

いっこう: 手に持ったコントローラが紐付いて手の動きを自然に見せてくれ、足の動きは補完されます。

白石: なるほど。3Eの方だとどのような具体例があるんでしょうか？

いっこう: Entertainment（娯楽）ではVR ZoneやVR PARK TOKYOなどが流行っていますし、開発者もエンタメ系の用途で使っている人が多いですよね。HoloLensでもエンタメはできるんですけど、広く受けているのは没入感の違いかなと思います。

千葉: 現実世界から離れたいこと、ありますもんね（笑）。

各OS対応で盛り上がるAR領域

白石: AR領域でいうと、ARKit、ARCoreがすごく盛り上がりましたよね。

千葉: GoogleのハイエンドなARプラットホームTangoは終了が決まってしまいましたね……。後続でマス向けのARCoreが発表されました。

いっこう: ARKitの方はアップデートで、これまで水平だけだったのが垂直も検出できるようになり、できることが増えましたね。

白石: スマートフォンの普及率からいうと、xRの中では一般普及するのはARが早いんでしょうか？

千葉: 手軽に使えるという意味ではそうでしょうね。

前本: VR、MRの課題は、手軽じゃないという部分がありますからね。買わないと、被らないといけない。最近のARはARKit/ARCoreの登場で、すごく現実感が出てきました。10cm動かすと10cm動くように精度が上がって、一つ上のステージに上がったなと思います。

▲ AR World Sharing Demo（動画リンク）

いっこう: Web技術の文脈では、WebVR、WebARが有用ですね。これまでアプリでしかARが実現できなかったのが、ブラウザがgetUserMediaに対応して、Webベースでカメラ情報を取得して実現できるようになったのが大きいです。MozillaさんがWebVRとWebARを統合したWebXRを推していて、W3CではWebVRは既にAPIが用意されていますが、次のバージョンアップではWebXRにしようということになっています。

⇒ 参考: WebXR Device API Specification

いっこう: 簡単にVRアプリケーションを開発できる、WebVRフレームワークのA-Frameもかなり盛り上がっていて、コミュニティが成熟してきていますね。

⇒ 参考: A-Frame

さらなる発展へ向けて技術的課題の解決が必要

白石: ここまではそれぞれの技術の現状を伺ってきましたが、さらなる進歩へのボトルネックや技術的な課題といった部分も聞いてみたいですね。

千葉: デバイスの制約は一つ大きな課題ですね。例えばデバイスを被らないといけないし、デバイスの処理能力がそれほど高くないし、バッテリーの持ちの問題もある。VRでもバッテリーとは逆にケーブル接続の制約があるかと思います。

白石: HoloLensって、実際には電池はどれくらい持つものですか？

千葉: 通常の使い方だと3〜4時間、積極的に使っていると2時間ほどです。技術の進歩で、将来的には解決されていく課題だとは思いますが。

白石: 逆に2012年頃に作っていたプロトタイプから考えるとどうですか？

千葉: 当時はいろいろ剥き出しで、サイズも大きくケーブルも多く、本当に最終製品になるんだろうか？と不安でした。でもやっぱり技術の進歩があって、5年経ってわずか579グラムです。今の課題も5年後、10年後と解決されていくはずですね。

前本: 2017年後半は開発環境の課題が多かったですね。HoloLensのアプリケーションはまずUnityで開発して、Visual Studioに書き出して、HoloLensにデプロイするという流れなんですが、それぞれのバージョンの違いで整合性が取れないようなことがあってかなりバッドノウハウが蓄積していました。

白石: 開発環境の問題があったんですね。

前本: いまはだいぶ落ち着いて、初めての人でも開発しやすくなりました。発売当初に初めてHoloLensを触ったときは、こんなことが生きている間にあるんだ！と思ったのに、すぐに視野が狭いとか腕が疲れるとか、思うところがでてきて、終わりがないです（笑）。

千葉: 本当ですよね。今から10年前を考えてみると、2017年にこんなデバイスがでていると想像できなかった。10年先は想像できないけど、たぶん10年後も満足していないと思います。人間の探究心って便利じゃないところを見つけてしまうので終わりはないけど、気がついたらみんな普通に使ってましたという感じになるんじゃないかと思っています。

xRで盛り上がるビジネス領域

白石: xRの技術的な側面をたくさん聞かせてもらいましたが、実際にはxR界隈ではどういうビジネスが生まれているんでしょうか？

いっこう: VRでいうと、アメリカのVR/AR専門ファンドのThe Venture Reality Fundが年に2回作成しているVRカオスマップが参考になります。

▲ The Venture Reality FundによるVRカオスマップ

いっこう: 機械、ソフト、ハードとだいぶプレイヤーが多くなっていると思います。その中で一部日本の企業も入っていて、健闘しているなあと思いますね。

白石: 大カテゴリが「Applications/Content」「Tools/Platform」「Infrastructure」。ホロラボさんはアプリケーション領域ですよね。どういうお仕事がメインですか？儲かっていますか（笑）？

前本: まあ、お陰様でぼちぼち……（笑）。受託で作る場合と、AR CAD Cloudのように自社パッケージとして作る場合とがあり、始めたばかりなのでなんでもアリ、という感じです。

いっこう: ゲームカテゴリだとバンダイナムコさんが入っていますね。もともとが大きい会社ですけど、VR Zoneもかなり盛り上がっていますし、VR領域では日本で一番じゃないかなと思います。

白石: Tools/Platformというと、去年Oculas Riftが値下げをしたじゃないですか。正直、売れてないのかな？と思ったのですが……。

いっこう: 逆に、値下げをしたことでめちゃめちゃ売れたと思います。Windows MRも手頃な値段なので、結構売れているのではと思っています。

千葉: そうですね、各社お互いの価格を意識しつつ値段をつけていると思います。

xRでどうやって「URL」にアクセスするか

白石: 会場からも質問を受け付けてみたいと思うんですが、どうでしょうか？

参加者: 現在のマウスとキーボードで扱うコンピュータのUIは、平面を前提にしているじゃないですか。xRのような3Dで見られるHPやメディアって、どういう形になっていくんでしょうか？例えばWebページにアクセスしたい時、URLの入力はどうするんだろうって想像がつかないんです。

前本: 一つあるのは、リアリティがあるからといって、リアルと同じようにしないといけないと疲れるんですよね。マウスやキーボードのように、操作性を上げる入力装置があったほうがいいだろうと思います。

いっこう: HoloLensってエアタップなど手を前に出して操作しますけど、結構腕が疲れるんですよね。VR空間の移動も、ワープ方式やコントローラを使う方式があるけど、あまりしっくり来ていなくてまだ確立していない。

千葉: これまでのUIが生きる部分と、人間の通常の行動がそのままUIになる部分とあると思います。URLでいうと声を発したら文字になって適用されるというのも いいかもしれない。

いっこう: いろいろな方法を試していかないとなあというところですよね。

2020年に向けた期待

白石: たっぷりと伺ったところで締めたいと思いますが、最後に2020年の少しだけ未来に、xRはどうなっているか想像や期待を伺わせてください。

いっこう: 2年後かあ……。VRはハード面では一体型が出てきて、画質も上がって、さらに進歩すると思うんですけど、一般普及するのは正直まだまだかなあと思っています。

白石: どうしたら一般普及するんでしょうね？キラーコンテンツの登場？

いっこう: Yahoo!BBがモデムを無料で配ってADSLが普及したように、国や機関が無料で配るくらいしないと普及しないんじゃないかと思います。

白石: 無料で！確かにそうですね。前本さんはどうでしょう？

前本: 現実的には通信が5Gになったり、視野が広がったりと、技術的な課題がクリアされていくと思います。期待でいうと、xRネイティブな世代が遊びとしてVRやARとAIを連携したりしていて、そういう遊びの中からすごいものが出てくるんじゃないかと密かに思っています。もしかしたら攻殻機動隊も実現するんじゃないかな。

千葉: 技術的な進歩はもちろんですけど、私が期待したいのは「xR盛り上がっているぞ」という一体感ですね。熱量のある人が増えて、ビジネスも増えて、私自身この領域の仕事にもっともっと関われたらいいなと期待しています。

白石: それぞれの熱いお気持ち、ありがとうございます。本日は大変勉強になりました！

HTML5 Experts.jp 副編集長兼エキスパートの吉川です。昨年好評だった「Webの未来を語ろう」企画を2018年もやります！

今回はパネルディスカッション形式で、HTML5 Experts.jp 編集長の白石が、ブラウザベンダーのGoogleのデベロッパーアドボケイトのえーじさん、 Microsoftのエバンジェリスト物江さんをお迎えして、興味深いお話を多数お聞きしました。

会場も交えたトークは、今後のWeb業界の動向を追いかける上で、重要な内容となっているので、ぜひ読んでみてください！

2017年のWebで印象に残ったことは？

白石: まずは簡単な自己紹介と、2017年のWebで印象に残ったことを教えてください。

えーじ: えーじです。Googleでデベロッパーアドボケイトをしています。もともとは、Google Chromeのアドボケイトという位置付けでしたが、最近はもっと広くなって、Web全体のアドボケイトを担当しています。 特にChromeだけの話に限らず、Web全般について話をしていますね。これには、我々のチームの理想として、Webすべてに貢献していこうという想いがあります。

2017年で印象に残ったことは、SafariがService WorkerとPayment Requestに対応すると表明したことがすごく意義深いと思っています。

物江: 物江と申します。Microsoftでエバンジェリストをしています。以前はWebに軸足を置いていたんですが、現在はWebだけに限らずISV(Individual Software Vendor)、独立してサービスや製品を提供しているパートナーさん向けに様々な技術の啓発を行なっています。Webについては、個人的なものも含めていろいろ活動しています。

2017年に印象に残ったことは、WebAssemblyやPWA（Progressive Web Apps）などについて、ブラウザベンダーがきちんと足並みを揃えて、仕様を策定するようになったということですね。非常にいい流れになってきていると思います。

▲左から、日本マイクロソフト株式会社 物江修さん、Google デベロッパーアドボケイト えーじさん

白石: 皆さん、ありがとうございます。ついでに私の2017年で印象に残ったこともお話ししておくと、個人的にはdev.toや日本経済新聞社の日経電子版が爆速だったという、そういう事例が出てきたのは印象的だったなと思います。裏側でHTML5やWebの最先端技術とか、そういったものを使って1段階上のレベルの速さを実現している。

Webプラットフォームベンダーやコミュニティの皆さんの啓蒙活動などもあって、PWAをはじめとしたWeb技術だとかパフォーマンスだとかが、ビジネス上も重要であるというところも浸透してきている。その結果として、Webプラットフォームの機能がフル活用されつつ、パフォーマンスというところに影響がでた良い例かなと。

今回は、Webの過去・現在・そして未来を語るという構成で進めてみたいと思います。

イントロダクション:HTML5は世界を変えたのか？

白石: 2017年以前のWebを振り返ると、ブラウザ戦争などの分断化があって、そこからHTML5のムーブメントが起こり、Webの様々な仕様が生まれてブラウザに実装されました。

ただ、それら「HTML5」のムーブメントは世界を変えたんでしょうか？ これまであまり、そういう振り返りをしたことがなかったので、一度やってみたいなと思っていたんです。お二人はどうお考えですか？

物江: そうですね、一般ユーザーの目からすると、確かにあまり変わっていないかもしれません。例えば、YouTubeのプレイヤーは、FlashからHTML5になりましたけど、変わったって気がつく人はあまりいませんよね。普通の人は、きっとまったく意識せずに使っている。HTML5でできたことは、とっくにFlashでもできていたわけで。

でも、開発者にとっては大きな変化がありましたよね。結局、開発者はみなHTML5を使っています。これはなぜかというと、HTML5がシンプルだからこそだと思うんですよ。

エキスパートの竹洞さんがいいことを言っていたんですけど、Webが素晴らしく進化したのはKISSの原則(*1)のおかげといっていました。つまり、誰でも簡単に使えるからこそ普及した。わざわざFlashを使わなくても、Web標準技術だけを使えばいろんなことができるようになった。それによって作り手側の裾野が広がって、以前よりもリッチなコンテンツがたくさん出るようになってきたのかなと思います。

*1 … “Keep it simple, stupid” （シンプルにしておけ！この間抜け）、もしくは、”Keep it short and simple” （簡潔に単純にしておけ）という経験的な原則の略語。Wikipedia

えーじ: ぼくも、世界は変わったと思います。やっぱりHTML5でWebを変えようっていうムーブメントがあったこと、それ自体が良かったと思うんですよね。良い意味でのブラウザ間の競争が起きて、どんどん新しい提案がなされて、共通して使えるものがどんどん生まれていった。

ちゃんと数えたことないですが、HTML5の機能でみんな当たり前に使うようになったものっていっぱいあると思うんですよ。例えば、CSS3で角丸を使うっていうのももう当たり前にみんなやっているし、それが動かないブラウザはほぼ、ない。そういうものが当たり前に使えるようになったっていうのは、一昔前からすると全然状況は異なっている。そういう意味では、相当変わったと思います。

白石: そういえば、元Mozilla Japanの浅井智也さんに以前教えてもらったんですが、Web関連技術を全部まとめた図があるんです。これ、曼荼羅図みたいな感じなので、「Web曼荼羅」なんて呼ばれているそうです(笑)。

HTML5とその関連技術（webapi.link）

こうして考えると、HTML5のムーブメントはたくさんのものを生み出しましたねえ。一般のユーザーからはあまり変わってないように見えても、「それは時間をかけて変わっているから」という面もありそうですね。

えーじ: はい、そして、これだけのものがたくさん生み出された結果、Webはアプリケーションプラットフォームになった。それが、HTML5以前との大きな違いだと思いますね。

Webは難しすぎる─Webプラットフォームの現状と課題

白石: では、iOSやAndroidといった他のプラットフォームとWebプラットフォームとを比較すると、Webはどういう立ち位置にあるとお考えですか？

物江: Webプラットフォームは時間をかけてここまで成熟してきました。機能的な面では、他のプラットフォームにもひけをとらないというところまで来たんじゃないかと思います。

そして今、Progressive Web Apps (PWA)が浸透しつつあることが、今後のWebにとってはすごく意義のあることだと思っています。 PWAって、ある意味ひとつの理想の到達点だと思うんですよね。Javaなどが理想に掲げていた「Write Once, Run Anywhere」を、PWAは真の意味で実現するわけです。 これ、次のWindowsの大型アップデートでPWAがデスクトップアプリっぽく動いだり、Windowsストアからインストールできるようになるから言っているわけじゃないですよ(笑)。

白石: そこでいつも言われているのが、Webアプリって動作が遅いんじゃないかってことですよね。

物江: ただ、そうした問題についても、Webプラットフォームは長いこと取り組んでいて、もはやあまり問題にならないレベルじゃないかと思います。 ブラウザの実装という面でも、仕様の面でも、絶え間ない改善が続けられてきました。

仕様の面でそうした部分について期待できるのは、やはりWebAssemblyですね（筆者注: ブラウザが高速に実行可能な、ポータブルなバイナリ形式）。 昨年、モダンブラウザが同時にWebAssemblyのサポートを表明するということがありましたが、これでWebの速度はまた一段階アップすることが期待できます。

あとはやはりハードウェアの進歩が解決するものも多いでしょう。ちなみに、今のWeb技術の素晴らしいところは、ハードの性能に縛られた設計をしていないこと、どこでも同じWeb技術が動作することだとも思います。

例えば昔、貧弱だった携帯電話の機能に合わせた仕様で、HDMLやCHTMLというモバイル専門のタグがありましたが、今はもうほとんど残っていません。結局、性能に関わる問題は時間が解決してしまう部分も大きいんです。いま大切なことは、「いかに人間が作りやすいか、使いやすいか」が重要になってくるかなと思います。

えーじ: ぼくも、パフォーマンス面は既にあまり課題とは考えていません。それよりぼくが課題だと感じているのは、開発者にとってのWeb技術はかなり複雑になってしまっていることです。

例えば「Extensible Web」というのを聞いたことがある方がいらっしゃると思います。これはWebの技術設計に対する、ここ数年における指針のようなもので、具体的には「標準としては、ユースケースを規定しない低レベル（低レイヤー）なAPIを提供する」というものです。

そうすることで、そうしたAPIを使用したハイレベルなライブラリだとかベストプラクティスが、開発者の手によって作られることを期待する。こうすることで、「ハイレベルだけど使われないAPI」が標準で規定されてしまうという問題を解決しようとしています。

ただ今は過渡期なので、低レベルなAPIがどんどん増え、ライブラリも量産されていて、はっきり言って混沌としています。例えばService Workerもすごく低レベルなAPIで、実際に使うとなるとなかなか難しい。

そこにGoogleがWorkboxというライブラリを出していたりするんですが、それを使うと簡単にServiceWorkerを使える一方で、ServiceWorkerもライブラリもどちらも学ばなくてはならない。

これがWeb Componentsなんかだと、仕様そのものがどんどん変わっていて、なかなか安定しない。Polymerというライブラリを使おうにも、Polymerも仕様に合わせてどんどん変わっている。どの時点の仕様が正しいのか、検索したときにどれが最新なのかわかりづらい。そういうところが複雑で、開発者はみな苦労してるんじゃないかなと思います。

個人的には、以前Webpackにやられたことがありまして(笑) 。将来的にはES Modulesが広まれば、そういうビルドプロセスを経なくてもうまく動くようになるんだと思うんですが、今は過渡期として、やっぱりGulpなりWebpackなりRollupなりを使う必要がある。

ビルドツールも次々に生まれるし、フレームワークもそう。フレームワークとビルドツール、様々なライブラリも組み合わせなくちゃならないし、ベストプラクティスが簡単にはわからない。その辺がかなり複雑になっているなと感じています。

各ブラウザベンダーのこれからの動向は？

白石: 皆さんご自身の会社の立場からお聞きしたいなと思うんですけど、ブラウザベンダー各社がどういう想いで、どういう方向を向いて実装しているのかをお聞かせください。

えーじ: 会社（Google）としての方向性はもちろんですが、チーム内でWebに関する課題を共有して、その解決策を探ることは普段から行っています。

例えば、先ほど挙がっていたパフォーマンスを例に挙げましょう。

実はJavaScriptのパフォーマンスって、もうあまり問題にならなくなっているんです。むしろ悪いのはレンダリングの部分で、そこを速くするための努力はずっと続けています。

あと、ネットワークの遅延もすごく大きい要因なので、ServiceWorkerみたいな仕様を提供することで、スピードの課題に開発者自身が取り組みやすくする。

さらに、パフォーマンスに関するベストプラクティスを開発者の皆さんと共有するのも重要です。

このように、課題一つとってもたくさんのアプローチがある。こういう活動を、チーム一丸となって同時に取り組んでいるという状態ですね。

白石: なるほど。ちなみにGoogleの中で、「今のWebはこういう課題があるね」みたいな、そういう話し合いっていうのはよくされるんですか？どんな議論がされてるのか興味があります。

えーじ: はい、常にやってますね。世界中から集ってきた情報を、雑談ベースでやり取りするような感じです。

例えばこれからGoogleがインドでももっと使われるようにするためには、インドの市場を考えなきゃいけない。しかしインドは全然違う世界だと。

例えばネットワークにしても、今われわれが4Gは当たり前に使ってますけど、向こうの世界は2Gなんです。3Gですらない。なのに、何MBっていうファイルをダウンロードしないと見れないサイトっていうのはざらにあるわけですよ。そういったネットワーク環境の悪いところに対して、開発者の皆さんがサービスを提供しようと思った時にどうするのか。そういう課題がインドに進出しようと思っているチームから上がってきたりします。

他には例えば最近は、アクセシビリティにもかなり力を入れていたりもしますね。アクセシビリティに強く関心のある人たちがチームに入ったことで、Webのアクセシビリティをもっと良くするための話し合いや仕様の提案なども活発に行なっています。

物江: Microsoft Edgeは、相互運用性とセキュリティ、アクセシビリティとパフォーマンスの4つが何においても優先されています。

例えば相互運用性でいうと、 -webkit-text-stroke というベンダープリフィックスがあります。これ、以前はWebKit系のブラウザでしか動かなかったんですが、現在はEdgeでも開発中なんです。多くのサイトで使われているような機能については、全部同じように動くようにするというのを優先的にやっています。

アクセシビリティに関しては、画面に表示されるすべてのテキストについて、スクリーンリーダーのような外部のプログラムを呼び出せるような仕組みが、WindowsにはOSレベルで入っています。それを使って、アクセシビリティを強化するような仕組みがEdgeに入っていたりしますね。

パフォーマンスについては、Chakra（EdgeのJavaScriptエンジン）のパフォーマンスアップを継続的に行っています。特に、こないだのアップデートでようやくブラウザ内部のリファクタリングが終わったようで、Edgeが出た頃からのパフォーマンスでいうと、3～4倍速くなってます。

白石: リファクタリングっていうのは、Internet Explorerから引きずっているコードがかなりあるのを書き直すって話ですよね。それが行われているって話はだいぶ前に聞いていましたが、ついに終わったんですね。

物江: はい、ほぼ全部終わったんじゃないかと。もともとEdgeのレンダリングエンジンってTrident（IEのレンダリングエンジン）から派生したものなので、20年以上前のものということで、根っこの部分で仕様が古い部分があったんですよ。その修正がようやく終わったという感じです。これから先は、Edgeの開発はどんどん加速していくんじゃないかと期待しています。

あとは、やはり2000年代と比較すると、ユーザーの意見をより開発に取り入れようという姿勢が顕著になったかと思います。Windowsをお使いの方はわかると思うんですが、フィードバックHubというのがありまして、そこでバグの報告だとか、追加してほしい機能をリクエストできるんですよ。そのリクエストのベット数が多いと優先度があがっていって、対応されるというようになっています。

注目のWeb最新技術を一挙に解説！Web Payments、WebVR、AMP、PWA、WebAssembly…

白石: ではここからは、注目のWeb最新技術についていろいろお聞きしたいと思います。Web Payments、WebVR、AMP、PWA、WebAssemblyなどなど、仕様ごとに概要と現状をお話しください。

Web Payments

えーじ: 今までWebでお金を払うといったら、フォームを使ってクレジットカード番号を入れたりとか、どこかのサイトに飛んで、そこのサイトにあらかじめ保存してある支払い情報を使うといったことがほとんどだったと思います。Web Paymentsを使うと、ブラウザがネイティブで表示してくれるUIを使って支払いができるようになるというのが大きな特徴ですね。ちょっと見てもらうと、PolyCartというWeb Paymentsのデモサイトで確認することができます。

Web Paymentsのデモサイト（PolyCart）

ブラウザネイティブのUIを通じてクレジットカードの情報や、配送先、連絡先などの入力を促すことができます。そうして入力された情報はブラウザが記憶してくれるので、次からはクリックするだけで支払い情報を入力することができます。

もっとすごいのは、将来的には支払い方法を追加できるようになるんです。例えば、Apple PayやGoogle Payで支払うのも可能ですし、仮想通貨なども使えるようになるでしょう。

WebVR

物江: 以前から、「Web上でVRコンテンツを表示する」っていうのは、Three.jsなどを使って実現が可能でした。ではWebVRは何が違うかというとVRデバイスからのフィードバックを受けることができるんです。これによって、VRデバイスと深く連動したWebサイトを作ることができます。

それにWindows10だと、ネイティブでVRの環境をサポートしていて、WebVRに対応したWebサイトにいくと、自動的にVRゴーグル上で全画面表示してくれるようになっています。VRのビデオもそのまま見ることができるので、真の意味でシームレスにVRのコンテンツが提供できるようになっています。

個人的に楽しみなのは、VRをきっかけとして新しいUIが生まれてくることですね。既存のVRゴーグルを使ったことがある人はわかると思うんですけど、キーボードもマウスも何も使えないんです。そうすると新しいUIを考える必要があって、そこに新しい可能性を感じています。

えーじ: ちなみに最近はWebXRっていうらしいですね。VR、AR、MRをコンセプトに入れた仕様を作ろうとしているという動きもありますね。

AMP

白石: 次はAMPですが、これについては既にたくさんの方がご存知でしょうから、簡潔に。主にモバイル環境で、Webページを素早く表示できるようにするための、HTMLのサブセットですね。

えーじ: AMPの仕様自体もさることながら、AMPが基本的にWeb Componentsでできているのは興味深いです。Web Componentsの仕組みを使って独自のエレメントを定義していて、なおかつパフォーマンスも追求しているので、結果としてパフォーマンスのベストプラクティスの塊をWeb Components化したものになっている。大変面白いと思います。

Progressive Web Apps

白石: 次は、恐らく今年最大の注目キーワードProgressive Web Appsですね。これは（ずっと啓蒙してきた）えーじさんに語っていただくしかないでしょう。

えーじ: はい。とはいえPWAという言葉自体は、皆さんに意識してもらいやすくするためのマーケティング用語のようなもので、技術的な観点からはそれ自体意味がないと思っています。実際の中身はService WorkerだったりとかPush Notificationだったりとかそういう具体的な機能やAPIから構成されています。

日本でも、昨年後半くらいからPWAが注目されはじめました。さっきのdev.toとか日経電子版とかも、PWAの構成要素を利用することで高速化が実現できたと。PWAの中のひとつひとつの技術要素をうまく使うとここまで速くできるんだよ、といういい例ができたなと思っています。

白石: ちなみに、個人的にはPWAっていまいち意味がわからないな、と思ってて。なにが「プログレッシブ」なんでしょうか？プログレッシブって、「だんだん（進化する）」って意味ですよね。

えーじ: PWAにおける「プログレッシブ」には2つ意味があります。

1つは昔から言われているプログレッシブ・エンハンスメントです。古いブラウザでも見ることができる基本的なWebサイトをまずは作って、そこに、新しいブラウザで使える機能を足していくという考え方。そうすれば、クライアントの環境を最大限活かすことができます。

白石: では、Service Workerが使えるブラウザだったらオフラインという機能が使えるけど、そういう機能が使えないブラウザにも同等のものを提供する。既存のサイトにあとからその機能を提供することも割と簡単にできますよっていうそういう思いを込めたものということですね。

えーじ: そうです。もう1つが、今あるサイトに機能を付け加えていくことで、徐々にPWAに近づけていけるという意味です。PWAのためにサイトを一から作り直すとか、大幅な改修を行う必要はない。既存のサイトを徐々に拡張していけばいいんです。

白石: なるほど、そういう意味合いだったんですね。ちなみにPWAの中では、Service Workerが代表的なAPIですよね。他にはWeb App Manifestとか、Push Notificationとかでしょうか。

えーじ: そうですね。ちなみに、PWAのウリの一つに、OSのホーム画面にアイコンを追加できるというのがあるんですが、以前はただのWebアプリへのショートカットでした。でも今は違います。PWAをホーム画面に置く際、アプリのパッケージを動的に生成してインストールするので、OS上の扱いはネイティブアプリとほとんど変わりないんです。なので、プッシュ通知のオン／オフをアプリごとに設定できたり、ネイティブアプリでしかできなかったことがPWAでも同様に行えます。

WebAssembly

白石: 次はWebAssembly、物江さんご説明お願いします。

物江: WebAssemblyは、Webブラウザ上で非常に高速に動作させることができる、デバイスに依存しないバイナリ形式です。現在は用途がある程度限られていて、DOMを操作することなどはできませんが、CPU依存の計算処理などは極めて高速に動作させることができます。 Emscriptenなどのツールを使うと、C/C++で作られたものをWebAssemblyに変換できるので、C/C++で書かれたゲームなどをWebAssemblyに移植することも比較的容易です。また現在はまだ開発中ではありますが、MonoがC#からWebAssemblyをコンパイルするmono-wasmであったり、マイクロソフトも実験プロジェクトとしてWebAssemblyを介してWebブラウザー上でC#とRazorを走らせるWeb UI framework Blazorを開発していたりします。

（ここで会場からエキスパートであるあんどうやすしさんから質問）

あんどうやすし: 現在のWebAssemblyって結局計算することしかできないじゃないですか、DOMもいじれないし、JavaScriptのAPI呼び出しも直接は行えない。今後もそれは変わらないんでしょうか。特にデータの渡し方に結構制限があって、使い勝手がいいものにするには難しいなと感じています。SharedArrayBufferという仕組みで一次元配列の共有はありますが、それも使いづらいし…。

物江: それは、今の段階ではまだなんとも言えないですね。

えーじ: ちなみにSharedArrayBufferはこないだのメルトダウンとスペクター(*2)の影響で機能が停止になります。

白石: ありゃ、まさかそんなところにまで影響及ぶとは…(笑)。

*2 … CPUでの投機的実行という高速化プロセスを悪用した脆弱性

Web Share API

白石: 他には、注目のAPIとかはありますか？

えーじ: 最近追加されようとしている新しい機能にWeb Share APIというのがあります。

Androidのインテントをご存知の方だったらすぐ分かる機能ですが、例えばあるサイトを「FacebookやTwitterでシェアしたい」という場合に、Web Share APIを使うと簡単に外部アプリを呼び出すことができます。

逆に、自身のWebアプリを「シェアする先のアプリ」として使ってもらうようにすることもできます。それがWeb Share Target APIというものです。

Web Share APIは既に使えるんですが、Web Share Target APIは、現在限られたサービスにしか開放されていません。このように、Chrome では一部のドメインに先行してWebプラットフォームの機能を試してもらうオリジントライアルというものをやっているのですが、現在TwitterのモバイルサイトがWeb Share Target APIを使えるようになっています。mobile.twitter.comで実際に試すことができますので、TwitterのPWAをまだ試したことがない方は、AndroidのChrome betaチャネルか、devチャネルを使ってインストールしてみてください。何かシェアしようとしたときに、TwitterのPWAが候補として出てきます。

Web Authentication

白石: Web Authenticationというのもあると聞きました。

えーじ: Web Authenticationは、実はEdgeでもう使えるんです。仕様がちょっと古いので、APIが全く異なりますが、Polyfillもあります。Web Authenticationをひとことでいうと、セキュリティキーなどを用いた多要素認証を標準技術で扱えるようにするものです。顔認証や指紋認証と組み合わせれば、安全性の高いログインの敷居はぐっと下がると思います。

物江: FIDO Allianceという標準化団体があるんですけど、そこで生体認証などのもっと広い話をしています。既にWindowsだとWindows Helloという生体認証の仕組みがFIDOの標準で作られていますね。

えーじ: FIDOのWeb版がWeb Authenticationになるわけです。Web Authenticationの実装はこれからどんどん出てくるでしょう。Mozillaさんもこないだ実装を開始しましたし、Chromeもそろそろ入ってくるのかなと思います。

白石: そうすると、もしかしたら今年はWebサイトで指紋認証とか顔認証とかが一般的になってくるという可能性があるってことですかね。

えーじ: そうですね。どの認証方式を使えるようにするかっていうのは、順番に1つずつ入れていくという話らしいので、まずはセキュリティーキーから利用できるようになって、そのうちNFC、指紋認証ができるようになっていくようです。徐々にそういったものが実装されていけば、本当にパスワードを覚えなくてもいい世界っていうのが実現できるかもしれないので、すごく楽しみにしています。

ちなみに、Credential Management APIというIDとパスワード、いわゆる共通鍵認証をする仕様があるんですが、それとAPIのネームスペースが同じになるので、共通のAPIを使うことになります。まったく別々だった仕様が一緒になるというのも個人的には面白いと感じています。

エキスパートたちが見据えるWebの未来について

白石: 最後にWebの今後について感じていることをお聞かせください。

えーじ: ぼくらブラウザベンダーは、「こうなるといいな」というものをいろいろ作ってるんですけど、それはブラウザベンダーが勝手にやってるわけじゃなくて、開発者の皆さんの声とか、こういうWebがいいという声をもとにやっているので、フィードバックをできるだけいただいたほうが、より皆さんの理想としているWebができると思っています。

フィードバック方法にも今はいろいろあって、GitHub上で管理されている仕様にIssueを立てるっていうのも一つの方法ですし、一番簡単な方法です。それすらめんどくさいということであれば、ぼくに直接言っていただくとかでも構いません(笑)。そんな感じで、開発者の皆さんと一緒にWebを盛り上げていけたらいいなと思います。

物江: 個人的な思いとしては、今非常にWebって良い方向に進んでいると思っています。（お互いを傷つけ合うような）ブラウザ戦争は終わりました。今は良い意味でお互いに競争し合ったり、歩調を合わせてWebを良いものにしていこうという動きが主流になりつつ会って、とても好ましく感じています。今後もそれが続いていって、Webのテクノロジーの活用範囲が広がればいいなと思っています。

白石: 皆さん、本日は様々なお話をお聞かせいただき、ありがとうございました！

5月23・24日の二日間に渡って開催された日本マイクロソフトの開発者向けカンファレンス「de:code 2017」。その中でも定員数をはるかにオーバーし、入場規制もかかった澤円さんのセッション「これからのエンジニアに必要な『マネジメント』の考え方」が興味深かったので、レポートしたいと思います。

マネジメントは「管理職」のことだけはない

エンジニアの世界では日常茶飯事で交わされている以下のセリフ。皆さんも聞き覚えがありませんか？

「これさ、なるはやでチャチャっと作ってよ」

「とりあえずいい感じに仕上げといて」

「なんかこれ、あんまり動かないよ」

実はこれ、澤さんいわく「マネジメントが欠けている状態」なのだとか。どんなマネジメントが欠けているのかというと…、

• なるはやでチャチャっと　→　スケジュールマネジメント
• とりあえずいい感じに　→　クオリティマネジメント
• あんまり動かない　→　リスクマネジメント

このように全ての出来事にはマネジメントがからんでいます。

マネジメントという言葉からは人事管理や人事評価といった「管理職」をイメージしがちですが、必ずしもそれだけではありません。仕事をする全ての人は、上記のようになんらかの形でマネジメントを「する側」の人であるのです。こうしたマネジメントをきちんと意識して仕事をすることが「エンジニアを救う」のだと澤さんは言います。

マネジメントという言葉は、もしドラ（※もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら）でピーター・F・ドラッカー氏とともにメジャーになりましたが、セッションではそのドラッガーの名言として澤さんが紹介したのがこちら。

テクノロジーで生活は便利になる。効率化するツールが出てくることによって、幸せになることもあれば、逆に振り回されることもある。ある人に都合のいいことは、ある人には都合が悪い場合もある。それは全てのマネジメントは常に「人」にあるからであり、エンジニアも結局は「人」だから。

「テクノロジーは人を幸せにするし、人の生活を豊かにするために存在するものですが、『Visual Studioはこういうことができます』『Windows 10にはこういう機能があります』というように、技術や製品の機能に人を合わせて説明してしまうと、だいたいうまくいかなくなります。主役は人であることを常に意識し、ユーザーサイドに立ち、主語を人にして人の立場をメインに話すとわかりやすくなります。そのために大事になってくるのは、最終的にはコミュニケーションです」

では、コミュニケーションをうまくするにはどうしたらいいのでしょうか。

「ここの色を変えて」「画面遷移を逆にしといて」

要求する側にしたら簡単にできそうに思えますが、その作業の裏側には数えきれないメソッドや作業が潜んでいたりします。なぜそう誤解してしまうのかというと、要求する側は自分の都合のいい状態で頭の中でイメージしてしまうからなのです。

「それを防ぐには、何が問題なのか、何が原因なのか、何がどう見えているのかを理解し、言語化して伝えることで、お互いの合意にもっていかなくてはいけません。しかし、日本人はそうしたマネジメントが根付いていません。どちらかと言えば、曖昧なコミュニケーションを好む傾向があります」

コンピュータの世界は、0と1のみ。「なる早でちゃちゃっと」では通じません。エンジニアがコーディングするとなれば、明確な仕様、要件定義が必要です。それを伝えるためにはわかりやすい言葉に置き換える必要があるのです。

シリコンバレーは“マインドセット”の聖地

ここで澤さんは、シリコンバレーに在住する友人の言葉を紹介。

「シリコンバレーは地名ではなく、マインドセット。マインドセットは空気を共有するのに必要不可欠」だという友人の言葉に、澤さんはすごく腹落ちしたそうです。

時間と空間を共有できる価値、カッティングエッジとパッション、優秀な頭脳はもちろんですが、マインドセットが共有されている場がシリコンバレーなのだと。

そして、このマインドセットが輸出され、最も息づいているところはインドだといいます。ただ勉強や仕事をして帰ってくるだけではなく、マインドセットを吸収し、帰国して起業する人が増え、インドはシリコンバレー化しているのだそうです。

「インド人は成長力が高くて問題解決能力が抜群であり、GoogleやMicrosoftをはじめとするグローバル企業でもインド人の優れた経営者が数多くいることがそれを証明しています」

当事者全員が「理解できる」のがマネジメント

実際にMicrosoftではどのように開発フローが進められているのか、マイクロソフトディべロプメントのトップ・安達理社長にヒアリングした話を紹介してくれました。

１）カスタマープロミス

まず最初に行うのは、カスタマーに対してどんな約束ができるのか、全員で合意すること。全員というところが大事　合意しないことに対して何かすると必ずエラーになる。

２）シナリオプランニング

具体的にどんなシーンでどんな使い方をするのかなどを考えてプランニングする。例えば「最高のエクスペリエンスとエンターテインメント機能を持つコンピュータを提供する」としたら、どんなシーンで使うのかといったことをペルソナを作りながら考えていく。

３）デリバラブル定義

実現できるかどうか　デリバリできるかどうかを検討する。

４）タスク設定

誰が何を担当するかを決めてタスク設定し、アジャイルで開発していく。

ポイントは、上の人が決めたことに対して言われた通りに開発するのではなく、みんなで合意して作っていくということ。実際の作業はこのように細分化されて開発が進んでいくといいます。

それぞれのタスクにはKPIが設定され、責任範囲や実行状況などを判断していきます。このKPI設定とタスク設定がきちんとしていないとプロジェクトはうまくいかないと澤さんは言い切ります。

「タスクは降ってくるものだという意識でいると仕事はできません。自分たちで定義して作っていくもの、権利だと考えるべきです。不得意なことは人に任せるという手もあるが、タスクを自分で定義することが大事。イノベーションは言われたことをやっているだけでは絶対に生まれません。それができていないのなら、提言してみる。それでも変わらないと思うのなら転職をしほうがいいくらい重要な権利なのです」

ちなみに、Microsoftではオーナーシップという言葉がよく使われるそうです。タスク設定した人がオーナーでボスで、責任はその人にある。だからオーナーシップをとるという考え方。案件を作った瞬間にその人は一番偉い立場となり、社内はリソース化します。たとえ社長であってもリソースの一部なので、必要であれば社長を動かすこともできるのだとか。

ただし、全てのボスには説明責任があります。構築までのステップから改変作業まで可視化して説明し、リスク、コスト、スケジュール、リソースをマネジメントする責任や、場合によっては交渉や提案する責任もあります。

「当事者全員が理解できることがマネジメント。説明責任を果たすためには、言語化が必要です。技術的に詳しいことは武器ですが、それに説明スキルを持つエンジニアはさらに無敵。論理的かつ簡単に説明する能力を磨くべきだと思います。その技術や製品に対して何も知らない人に説明するといい訓練になります」

自分で案件を生み出しマネジメントするのであれば、時間も人のリソース、働く場所も自由に選べるメリットがあります。自由と責任のバランスは大事なポイントであり、責任を果たせば自由が手に入る。責任を果たせれば、さらにもっと大きな責任を任されるようになり、世の中に貢献する場が増えるでしょう。

▲通路もステージ前も受講者で埋まっていた澤さんのセッション会場

最後にシリコンバレーの友人が教えてくれたこととして、以下の3つを挙げました。

• クリエイティブであること
• リーダーシップを発揮すること
• 起業家精神をもつこと

「AIやロボットが発達していったとしても、この3つは機械にはできないこと。そうであってほしい、そうでなくてはいけない。最前線で仕事をしているのに、置き換えられるなんてもったいない、つまらないですよね。皆さんも組織の中でも起業家精神を持ちつつ、リーダーシップを発揮してクリエイティブなことをしたいと思っている人は多いはず。
僕も文系の大学でしたが、ITは大きなものを生み出せるし、世の中を変えることができるんじゃないかと思って、IT企業に入ったんです」

ITは、人の幸せを創るために存在しています。そう信じることがマネジメントの神髄であり、ITと触れていれば、仕事のやり方も変わってきます。

「どうやったら人を幸せにできるテクノロジーを生み出せるかを考える、人がどう幸せを感じるのか見てみることは本当に大事なことです。ステキな未来を一緒に創っていくために我々はここにいます。創る権利、パワー、能力、理解など、もし足りてないものがあれば、私たちからもピックアップしてください」

そんなエモーショナルなメッセージでセッションは終了。50分間があっという間でした。澤さんのセッションはMicrosoftの動画チャンネルchannel9で公開されるそうなので、動画で見たいという方はぜひチェックしてみてください。

▲セッション前の澤さん自撮りショットから拝借。参加者の皆さん、嬉しそうですね

本記事は、2017/5/23, 24に開催された「de:code 2017」の1セッション、「War is over : ブラウザエバンジェリスト達とWebの未来を語ろう」を聴講したレポートです。

GoogleやMozillaのエバンジェリストたちがマイクロソフトのセッションで仲良くお話、って光景を見るだけでも楽しいセッションでした

左からMozilla Japan 技術戦略マネージャ 浅井智也氏、Google デベロッパーアドボケート 北村英志氏、日本マイクロソフト デベロッパーエヴァンジェリズム統括本部 物江修氏

Web Payments, WebVR, Web Assembly, Progressive Web Appsについてエバンジェリストたちが語る

Web Payments

物江 まず、Web Paymentsについてお聞かせ願いたいのですが、こちら北村さんご説明をお願いできますか？

北村 まず前提として、インターネットを利用する際に私たちがクレジットカードを利用するようになってから、それなりに時間が経過しましたね。そして現在転換期が訪れているといっていいのではないかと思います。これまでのように、フォームにクレジットカードの情報を生で入れて送信するというので、本当にいいのだろうか。

そうした問題を解決すべく提案されているのが、Payment Request APIです。他のサードパーティ製アプリに遷移して戻ってくるなどのUIを通じて、決済に必要な情報を、スムーズにユーザーに対して問い合わせることができます。

（筆者注: Payment Request APIの日本語による解説記事） （筆者注: よりシンプルな Web の決済方法 : Payment Request API の紹介）

Google デベロッパーアドボケート 北村英志氏

物江 なるほど。このPayment Request APIですが、Edgeではバージョン15からサポートしていまして、Creators Updateを適用したWindows 10上ではすでに利用可能です。Firefoxでのサポートは行われる予定があるんでしょうか？

浅井 はい、時期はまだ言えないのですが、サポートするのは確定しています。

北村 Chromeは現在Android版のみ対応していて、デスクトップ版は開発中です。

物江 あと、iOS版のChromeについても教えていただけますか？

北村 iOS版Chromeは、iOSのWebViewを使っていて、iOSのWebViewはPayment Request APIに対応していません。なので、そのままだとiOS ChromeではPayment Request APIは使えないのですが、実はこれを無理やり使えるようにしてしまおうという計画がありまして。

どう実現するかというと、ChromeからWebViewに対して機能を注入してしまうんですね。WebViewで通常使えないJavaScript APIを使えるようにしてしまう。Cordovaとかでは以前から普通に行われていたことです。

これまではiOSのWebViewに対してJavaScriptをインジェクトして、新しいAPIを使えるようにするということはしてきませんでした。なので、iOS版のChromeにとっては大きな方針転換でもあります。

物江 このように、各種のプラットフォームでサポートがすでに始まっていますので、今年中か、もしくは来年の初めくらいには、一般的に使えるAPIになってそうですね。

浅井 個人的には、（Mozillaの前身である）Netscapeが切り開いた商用インターネットの世界が、ようやくここまで来たか…と感慨深いものがあります。

WebVR

物江 では次はWebVRについてお聞きしていきましょう。WebVRについては、先日のCreators Updateから、1.1のAPIをサポートしはじめました。また、Babylon.jsやA-Frameといったライブラリを使うと、WebVRを簡単に扱うことができると。

浅井さん、A-Frameについて教えていただけますか？

浅井 A-Frameは、Web上で簡単にVRを扱えるようにすることを目指すライブラリです。例えば、HTMLタグを一つぽんと置くだけで360度画像を表示できるようにするとか。

Unityだとアセットストアがあって、アセットを購入したりすることができるのですが、それと同じようなエコシステムがコミュニティ主導で進められているのも特徴です。非常に簡単に3Dコンテンツを作れて、売り買いしながら作っていけるエコシステムができていくだろうと期待しています。

Mozilla Japan技術戦略マネージャ 浅井智也氏

物江 コンテンツで思い出したんですが、意外とWeb上で3Dを扱うような仕事ってまだ少ないらしいんですよね。WebGLがモダンブラウザ全部でサポートされるようになってから結構経つのに、WebGLってどこかゲーム用途のイメージも強いみたいで。

ただWebGLって、本来ゲーム以外の用途もたくさんあるはずなんです。例えばGrimoire.jsっていうライブラリがあるんですが、これは様々な3Dコンテンツを、簡単にWeb上で扱えるようにすることを目的としていて、こういう動きが盛り上がると、WebGLってもっと活用されるんじゃないかと思う。

浅井 その点VRは、コンテンツを中心とした盛り上がりも活発で、結構未来があるんじゃないかな、と思いますね。

物江 ちなみに、VRではなくてMR (Mixed Reality) でいうとHoloJSっていうのもあって、HoloLens用のアプリを作ることもできます…すごく大変なんですけどね(笑)。

ところでChromeも、WebVRには対応済みですよね。何か最近の動きとかを教えていただけますか？

北村 そうですねー、Daydream上でChromeを立ち上げることができるようにする、というのは聞きましたね（筆者注: VR/AR空間内でChromeを立ち上げられるように、ということだと思われる。参考: Chrome is coming to augmented reality and Google Daydream (TechCrunch)）。

WebAssembly

物江 では次は、WebAssemblyのお話を聞かせてください。やはりここは、（WebAssemblyの元になったasm.jsの開発元である） Mozillaの浅井さんにお聞きしようかと。

浅井 はい、WebAssemblyの元になったのはasm.jsという技術です。 もともと、JavaScriptは動的な言語なので、パフォーマンスの向上にも限界がある。そこで、JavaScriptのサブセットとしてasm.jsが提案されたんです。 変数の型が厳密に定義されており、さらに実行に先立ってコンパイルが可能なので、相当に速かった。

WebAssemblyは、さらにそれをコンパイル済みのバイナリとして配布できるようにする技術です。そのバイナリフォーマットに関する仕様がWebAssemblyです。実行速度は相当なもので、現在でもC言語の速度まであと20%というところまで迫っています。

物江 FirefoxやChromeではすでに対応済みなんですよね。Edgeでも、フラグをONにすると使えるようになります。 個人的にはJavaScriptを置き換えるようなものではなく、高機能な計算が必要なところに使うものだと思っていますが、合ってますか？

浅井 はい、そうだと思います。WebAssemblyに出力するのも、基本的にはC/C++やRust言語で書かれたものになりますし。

物江 ちなみに、WebAssemblyへのコンパイルって具体的にはどうやるんですか？

浅井 EmscriptenとBinaryenというツールを組み合わせて、C/C++のコードをWebAssemblyに変換する…というのが一般的ですね。基本的には、LLVMの中間言語が出力できれば、そこからEmscriptenを使ってasm.jsに変換でき、更にBinaryenでWebAssembly化できます。

（筆者注: https://github.com/kripken/emscripten/wiki/WebAssembly も参考のこと）

Progressive Web Apps

物江 昨今のWebの重要キーワード、Progressive Web Appsですが、これは北村さん説明をお願いできますか？

北村 はい。その前に、Progressive Web Appsって、ご存じの方どれくらいいます？…思ったより浸透してないですね。まだまだだな。

Progressive Web Appsっていうのは、一言で言うとモバイルウェブの新しい形です。

• Webサイトがホーム画面から起動できる
• プッシュ通知
• オフラインで動く

北村 百聞は一見にしかずで、twitter.comをAndroid 版 Chromeで開いてみるというのが一番わかりやすいと思います。 これはTwitter Liteと呼ばれていて、動作も素早いし、モバイルアプリと使い勝手はほとんど変わりません。

浅井 PWAは、アプリに比べてデータ通信量も抑えめになるそうです。例えばTwitter Liteではアプリに比べて70%データが削減できるとか。なので、ブラジル、インド、インドネシアといった、ネットワークインフラの整っていない新興国では、アプリよりもユーザのコンバージョン率が高く、採用も広まっているようです。

物江 Firefoxでの、PWA対応はいかがでしょう？

浅井 現在でもホーム画面へのインストールなど基本機能は対応していますし、今後フルスクリーン起動なども順次実装を進めていくそうです

物江 モバイルといえばネイティブアプリ、という印象はいまだに根強いですが、モバイルサイトも同時に構築できてしまうので、環境が整って利点が正しく理解されさえすれば、一気に広まりそうですよね。PWA対応していないブラウザでアクセスしたとしても、通常のWebアプリとして使えますし。

ちなみにEdgeでは、今年の夏頃から開発者向けのビルドでPWAを試せるようになります。年末ぐらいまでには、メジャーブラウザでは全体的にPWAが使えるようになりそうですね。

北村 ちなみにマイクロソフトさんの検索エンジンのBingが、PWAを見つけたらWindows Storeに並べてしまうようになるというのを最近知って、すごい荒業だけどこれは面白いなと思いました。

PWAって捉えどころがないふわっとした用語ではありますが、実際には個々の技術それぞれにもすごく価値があります。オフラインやプッシュ通知がWebアプリで行えるというのは、Ajax以来の技術的な革命じゃないかと思いますね。

Web Components

物江 そろそろお時間も迫ってまいりましたので、最後のトピックです。 Web Componentsについて語りたいのですが、北村さん、Web Componentsのご説明をお願いできますか？

北村 Web Componentsっていうのは、一言で言うと、自分でHTMLタグを作れるという技術です。そして、自作したタグ（コンポーネント）を配布できる。

Web Componentsは、最近だとSafariに搭載されたのが大きいですね。iOSを含め、割とどこでも使えるメジャーな技術になりました。

あともう一つ、AMP (Accellalated Mobile Pages）も実はWeb Componentsを使っています。AMPに対応しているサイトは、現時点でもかなりの数に上りますので、実際にはWeb Componentsはすごい勢いで広まっていると言っていいんじゃないかと思います。

物江 Polymerというライブラリもあるそうですが、それとWeb Componentsの関係はどのようなものでしょうか？

日本マイクロソフト株式会社 デベロッパーエヴァンジェリズム統括本部 物江修氏

北村 Web Componentsっていうのは、W3Cで標準化が進められている技術なんです。具体的には4つの技術から構成されています。

Custom Elementは、先程申し上げたように独自のタグを作ることのできる技術です。

Shadow DOMは、DOMのカプセル化を行えるようにする技術。

Template Elementっていうのは、「テンプレートである」という意味合い以外持たないHTML要素です。

HTML Importというのは、JSやCSSのように、HTMLもインポート可能にするという技術です。

一方でPolymerというのは、Web Componentsの上に構築されたライブラリです。

Web Components標準はそれほど高いレベルのAPIを提供しません。なので、実際にコンポーネントを作ろうとすると、実装の重複が多くなります。その重複を排除して、最小限のコードでコンポーネントを作れるようにするのがPolymerです。

物江 ちなみにEdgeは、Web Componentsについては長いこと意識しているようですが、まだ詳細は未定です。Polymerを使うと、現在のEdgeでもWeb Componentsが動作したりするんでしょうか？

北村 はい、PolymerはPolyfill（対応していないブラウザ上でAPIのエミュレーションを行うライブラリ）も含んでいますので、動作しますね。実は、現在のYouTubeサイトはWeb ComponentsベースのHTMLに全て書き換えられているんです。コードを見てみると面白いと思いますよ。

あと、Polymerはライブラリだけじゃなくてコンポーネントも提供しているんです。 http://webcomponents.org/ を見てみると、すでにいろんなコンポーネントが利用できるのを確認できると思います。

まとめ

物江 では、このディスカッションの締めくくりとして、Webの今後について一言ずついただけますでしょうか？

浅井 はい、モバイル時代は長らくネイティブアプリが中心でしたが、ここに来てWebの力が盛り返してきているのを感じています。ネイティブアプリと遜色ない機能を提供できるだけではなく、ユーザーにリーチするのも、アプリストアよりもWebのほうがハードルが低い。リンクを送るだけでプロモーションできますしね。そういう点で、PWAには期待しています。

北村 PWAについては、ぼくも同じく期待しています。とりあえずTwitter Liteを触ってみてほしいですね。

あとWebの今後という点で思いついたのですが、企業の枠組みを超えた合意形成の方法としては、Webはかなり進んでいるんじゃないかと思います。ディスカッションの場作りとか、標準化を行う上で蓄積されたノウハウはかなり貴重で、他の場面や業界にも活かされていくんじゃないかな…と考えています。

物江 ではそろそろお時間ですので、本セッションを終わりとしたいと思います。みなさま、本日は大変興味深いお話を、どうもありがとうございました。

5月23・24日の二日間に渡って開催され、大盛況のうちに幕を閉じた日本マイクロソフトの開発者向けカンファレンス「de:code 2016」。その参加者アンケートの総合点数で、134セッションの中でトップのスコアを獲得したのが、2日目の最終セッションに登壇した澤円氏のセッションだ。

澤氏のセッション、「クラウド心配性な上司を説得するコツを伝授します。本当に信頼できるクラウドの構築/運用とは～マイクロソフト クラウド成長の軌跡～」の概要をレポートする。

▲日本マイクロソフト株式会社　マイクロソフトテクノロジーセンター センター長　澤円氏

クラウド心配性な上司を説得するコツを伝授

プレゼンで重要なのは、伝えたい内容をいかに伝言ゲームのように伝播させていくか。そう常日頃から断言している澤氏。今回伝えたい相手は、クラウド導入に納得してくれない上司である。どう伝えたら説得できるのか、参加者が会社に持ち帰ってそのまま話したくなるような情報とネタが満載のプレゼンスタイルでセッションは行われた。

セッションの構成は大きく「データセンター構築から運用まで」「データセンター構築中」「データセンター運用」の3つのシーンに分けて語られた。

【上司に提言】海外との通信に専用線は高すぎますよね？

Microsoftのデータセンター構築から運用まで一連のオペレーションは、Microsoft Cloud Infrastructure and Operations、略してMCIOと呼ばれる。データセンター構築の情報を漏らさないために、会議室の予約は別の部署の名前を使うなど、情報管理は徹底している。

データセンターの場所選定は、さまざまな条件を要する。まずは電源が確保できること。発電所の近くであり、さらには発電所が停電になったことも考えると二カ所に近いほうが望ましい。液体燃料の確保が必要なので、道路の選定もデータセンター設置の条件となる。

電源ケーブルは二重化するのは当然のこと、アメリカでは米国基地とネットワーク網を共有している。海底ケーブルへも大型投資を行っているという。海底ケーブル最大の敵はサメ。サメがかじっても切れないケーブルを用意しているという小ネタも披露された。

こうしたトピックをもとに、「自分だけの専用ケーブルを引いてるみたいだから、ネットワークも信用できるみたいですよ。うちの会社で海外との通信に専用線は高すぎますよね？自分の国にデータセンターを持っているし、グローバルにクラウドの話をしてくれるはず」と上司に提案するヒントを語る澤氏。

実は、日本にMicrosoftのデータセンターを置くことを決めたのはCEOのサティア・ナデラ氏だという。日本の地下ネットワーク網は世界最強と言われており、マイクロソフト専用線も複数本ある。さらにその徹底されたグローバル標準について、話を進める。

【上司に提言】ここまでの標準化ってできますか？

Microsoftは、Open Compute Projectへの参加をしている。これはFacebookやGoogle、Intel、rackspaceなども参加しているプロジェクトで、サーバーの内部設計がすべて公開されている。

組み立てられたサーバー、ラックは同じ品質・クオリティで世界に出荷され、100カ所以上、40か国以上・22リージョン以上（※現在も増加中）にラックの状態でデータセンターに納品される。徹底的な標準化で大幅なコストダウンを目指し、標準化スタイルを決めたらそれを貫く。データセンターでやることはほぼケーブル接続だけだという。

特徴的なのは、ラックが白であることだ。白にすることで明るくなるので、接続ミスを減らすことができるし、何より光の量が少なくて済む。空調も使わず、空気の流れで調節している。これらはコストカットにもつながる。そして、こうした対応は一切の例外を認めておらず、全世界共通に行われている。

「そうはいっても」とマジックワードを繰り出す上司がいたら、「うち、ここまでの標準化ってできますか？」そう上司に問いかけることを勧める澤氏。ダラダラと妥協を繰り返すことは、コストを増やすだけと指摘した。

【上司に提言】サーバールームのログ取れてます？

さらに徹底したデータセンター運用について説明する澤氏。人はミスする、機械は壊れるを大前提として、人の手を介さない「自動化」を徹底すべきだと語る。

白いラックの上には、むき出しのケーブルが設置されている。なぜなら下（地下）だと手元が見えないから。すべての行動は追跡され、不正がないように手元が見えない状態を作らない。すべてがモニタリングの対象になる。

不正があれば証拠が残るが、逆にやってなかった場合も証明になる。データが守られると同時に社員も守られているという。知っていることで事故が起こることがある。その可能性をMicrosoftは徹底的に排除している。

データセンターで働く人は情報を見る術を持っていない。サーバーの電源や物理層だけチェックしている。鍵の管理は別組織だ。壊れていたらラックごと交換する。

ハードディスクもデータセンターから生きて出ることはない。役目を終えたハードディスクは4つに分割されて、それぞれ別の国で処理される。時間と手間がかかることで、犯罪者もあきらめる。犯罪の余地を作らないのだ。

ここでの上司への質問は「誰が触ったかわからない状態ってこわくないですか？うち、サーバールームの出入りって全部ログ取れてましたっけ？」。顧客データと社員を守るため、という大義名分に反論できる上司はなかなかいないだろう。

【上司に提言】「日本の法律」に対応できるそうですよ

最近Microsoftが変わりだしたのは、CEOのサティア・ナデラ氏によるところが大きいというのはよく聞く話だ。だが、社長のBrad Smith氏が弁護士だということを知る人は少ないのではないだろうか。彼が大切だと考えているのは、セキュリティ・プライバシー・透明性・法令順守。これはMicrosoftが法を順守する会社であるということを意味すると、澤氏は言う。

さらにCOOのKevin Turner氏によるMicrosoftのコミットメントを披露。上司に「日本の法律にちゃんと対応できるそうですよ」と言える要素を紹介した。

【上司に提言】あの人たちやりすぎです

最後に澤氏は、海底に設置するデータセンター「Project Natick」を紹介。究極の水冷化とセキュリティを実現する取り組みでありつつも、「あの人たちやりすぎです」と自虐ツッコミで会場の笑いをとった。

人々を成長させるためのモバイルファースト、クラウドファーストに徹底的にコミットして世の中をよく変える。「未来を一緒に」つくるために、今できることを伝える努力を最大限やっていきたいと宣言し、セッションを終えた。

澤氏のセッションはMicrosoftの動画チャンネルchannel9で公開されている。澤氏のde:codeでのプレゼンを見たいという方はこちらからどうぞ！

• クラウド心配性な上司を説得するコツを伝授します ～本当に信頼できるクラウドの構築/運用とは？ マイクロソフト クラウド成長の軌跡～【動画公開中】

5月24日、25日の二日間にわたり開催されたMicrosoftの技術者向けイベント「de:code 2016」で、日本マイクロソフト赤間信幸氏の「エンプラ系 業務Webアプリ開発に効く！実践的SPA型モダンWebアプリ開発の選択手法」というセッションを聴講しましたので、そのレポートをお届けします。

ただタイトルにもある通り、筆者的にはちょっともやもやする内容でもあったので、HTML5 Experts.jpコントリビューターの酒巻瑞穂さんと、講演の内容をベースとした軽い対談も行いました（後日、エンタープライズWebアプリのあるべきかたちについて、もっと掘り下げた内容の記事も作る予定です。乞うご期待）。

セッションレポート

SPA(Single Page Application)とは

今、Single Page Application(以降、SPAと記載する）が業務アプリケーションでも利用できないかということが話題になっています。復習になりますが、SPAとは以下の様な特徴を持つアプリケーションです。

• 単一ページで機能を提供するWebアプリケーション
  • ページをリロードせずにJavaScriptでWebAPIと通信
  • JavaScript、CSS、HTMLを組み合わせて画面を更新
  • これにより応答性が高く、使い勝手の良いWebアプリケーションを実現する
• Web上では割とSPAは一般的だが、業務アプリケーションでもSPA型の開発ニーズが高まっている

従来型のWebアプリケーションはサーバサイドが中心でした。そのほとんどの処理をWebサーバで行い、クライアントは受け取ったHTML、CSSを使ってレンダリングを行い、若干のJavaScriptを動かすというものでした。SPA型のWebアプリケーションでは、サーバはクライアントの指示に応じてデータを返し、UIの更新等はすべてクライアントで行います

SPA型Webアプリケーション開発の難しさ

このようなSPA型アプリケーション開発は相当のスキルが必要であり時にとてもむずかしいものになります。特に、SPA型Webアプリケーション開発に関するネット上の情報は、低水準からスクラッチで開発するためのものが多い。OSSなどをフル活用して作りこむ、いわばC++開発のような「職人技」の世界であり、ハードルが高いのが現実です。

エンタープライズ系業務Web開発の場合、こうした「職人的開発」はあまり向いていないように思います。

ここでエンタープライズ系開発とオープン系開発のギャップを確認してみましょう。

このような比較から、.NETのような高水準言語での開発に慣れ親しんだ開発者が、SPA開発に取り組むのはハードルが高いといえます。まとめると次の問題が挙げられます。

• 低水準開発の必要性：HTML, CSS, JavaScriptでの開発はC#, .NETでの開発に比べて低水準
• 高すぎる開発自由度：「どう作るか」は自分でゼロから決める必要がある
• ライブラリの選択の難しさ：膨大なライブラリからどれを選べばよいか分からない

そしてSPA型開発では、利用するフロントエンドライブラリによって作り方が大きく変わります。同じ「HTML5」の開発といえど、コードの互換性はほとんどありません。このためライブラリの選択には特に慎重を期す必要があるといえます。

そこで、自分のプロジェクトに合わせた適切なライブラリの選択が必要になるのですが、実際の現場ではこれが非常に難しい。Microsoftからは、クライアントライブラリは（ほぼ）提供されていませんが、世の中にライブラリは星の数ほどあります。

ライブラリを選ぶ際に考慮すべき事項

言語拡張

ここで、ライブラリを選択する際の私なりのやり方をご紹介します。ライブラリの選択では、基本言語仕様、DOM操作、通信処理、CSSに分けて考えてみます。そうすると、DOM操作・通信部分はほぼ必須になるので、jQueryを利用すればいい。基本言語仕様とCSSに関しては、スクラッチの作り込み型Webアプリケーションでは非常に重要ですが、業務Webアプリケーション開発の場合はケースバイケースです。より具体的に言うと、CSSではLess、SASS、StylusなどのCSSプリプロセッサーの選択、altJSでは、TypeScript、CoffeeScriptの選択などが挙げられます。

UIライブラリ

UIライブラリに関しては、低水準UI部品郡と高水準UI部品郡に分けて考えます。低水準UIライブラリには無償のものが多く、高水準UIライブラリは高機能ではあるが、ほとんどの場合有償製品となっています。

設計・実装方法論、フレームワーク

進化が激しくトレンドも頻繁に変わるため、注意が必要です。フレームワークを利用すれば、ロックインも発生します。特にWebフロントエンドの世界では数年と経たずにトレンドが変化します。このため頻繁に手を入れる見込みがない場合には、むやみにフレームワークに依存させるのは危険だと考えます。

各種ツール、ユーティリティ

どのような各種ツール、ユーティリティを利用するかというような考えは、初めてSPA型開発に取り組む場合には、後回しにするとよい。より高い生産性を目指す際には欠かせないツール郡ではあるが、ここまで述べてきた、言語拡張、UIライブラリ、設計・実装方法論、フレームワークなど覚えるべき要素、考えるべき要素が山ほどあります。最初はなくてもなんとかなりますので、必要性を感じたところから段階的に導入していくことをお勧めします。

ライブラリの組み合わせに関する注意

ライブラリは安易に組み合わせないように注意しましょう。ライブラリには必ず寿命がある上、複雑に依存しあっていることも多い。古いライブラリが他のライブラリのバージョンアップの足かせになることがあります。

長期的な保守が重要になる業務Webアプリケーションでは安易にライブラリを組み合わせるべきではないと考えています。

SPAフレームワークライブラリ

商用の高水準UI部品ライブラリは高価ですが、多くはオールインワンパッケージ（=SPAフレームワーク）になっていて、ライブラリの組み合わせ方で悩む必要が少なくなります。

このため、業務Webアプリケーション開発におけるクライアントライブラリの選択は、高水準UI部品の要否で大きく方針が変わります。

OSSライブラリの組み合わせ型開発では、利用できる高水準UI部品が少なめなので、メジャーなライブラリを中心に必要最小限の組み合わせを行います。。SPAフレームワークライブラリ依存型開発では、高水準UI部品が数多く利用できるので、シェア、情報量、日本語サポート、ライセンス費用などを元に選択するとよいでしょう。

サーバ側のページ構築

個人的には完全なSPA型ではなく、うまくサーバ技術を併用した方がSPA型の業務Webアプリケーションは作りやすい。特に.NET開発者の場合、複雑な業務ロジックはサーバ側でC#を使って記述した方が作りやすいことも多いでしょう。実際のSPA型アプリケーション開発では、サーバ側で組み立てなどにASP.NET MVCを併用するといいのではないでしょうか。UI処理の中心はあくまでもクライアントだが、上手に併用しましょう。

編集後記: 講演の内容について対談してみました。

レポートは以上になります。ただ、講演の結論が結局のところ「完全なSPA型じゃないほうがいい」と言っているように思え、少し違和感が残ったのも事実。そこで、同じくセッションを聴講していたコントリビュータの酒巻瑞穂さんと、疑問に感じたところを少し話し合ってみました。私も酒巻さんも、現役でエンタープライズWebに取り組んでいるエンジニアとして、これを機にエンタープライズ×SPAについて整理しておきたいと考えたからです。以下、その対談の内容を編集後記として掲載します。

SPAはつらい？

佐川：講演を聞いて、どんな感想を持ちました？

酒巻：正直、ちょっと違和感残る内容でしたね。

佐川：結論が結局、本格的なSPAは難しいからやめとこう、と言っているようにも聞こえました。

酒巻：私も、メリットが見えないものはがっつりSPAにする必要はない。何もかもSPAにすべきとは思いません。ただ例えば、モバイルの事を考えると、SPAにしていくメリットは大きいですよね。クライアントサイドでのオフライン処理を求められることも多いので、そうなるとSPAで作るほうが自然だったりする。

SPAはセッションをクライアント上で維持できるので、Server Push型のイベントが必要なアプリケーションを作る必要がある場合にも有効ですね。

佐川：SPA開発は職人技という話がありましたけど、ここはどうですか？

酒巻：職人技…かどうかはわかりませんが、開発の自由度は確かに高いですよね。アプリケーションの品質が、プログラマ個人の力量に左右される部分はまだ大きいですね。

佐川：フレームワークがそういう問題解決を担えるはずなんですが、そのフレームワークが多すぎるという(笑) 。講演でも「ライブラリ選択が多すぎる」という問題提起をしていらっしゃいましたね。

酒巻：確かにそれは同意できます。でも、「開発時の選択肢がない」というのは言い換えると「衰退する技術」のようにも思えるので、個人的にはむしろ今の状況は歓迎しています。業務エンジニアとしては社内ルールなどを作って統制する方がいいんじゃないかと。

佐川：それにライブラリの選択も、Yeomanなどのジェネレータやいろんなスターターキットを使えば、かなりの部分楽できますよね。

SPAの設計は悩ましい

酒巻：ただ、講演でも取り上げられていましたが、設計の方法論などについては確かに難しいです。ここはまだ結論がないと言うか、個人的にも難しいところですね。というのもWebの進化がまだ当分先を見てるので「今」の最善はあっても来年の最善はもう判らない。

佐川：設計方法論は、採用するフレームワークによっても大きく変わってくるところですしね。ただ、今のトレンドとしてはUIのコンポーネント化というのは間違いない方向性なので、そこからスタイルを決めていける。ただ、設計方法論を語った書物はあまり見られないのも事実で、これはWebの進化が早すぎるためではないかと。

しかしSPA設計の話って、「サーバでやるか、クライアントでやるか」って話になりがちですよね。ただ、MVC的なものをどちらかに寄せなければならないという話ではない。基本的には、UIを更新する処理はクライアントに寄せるというほうが筋が良いと思います。

この話はSPAをどうするかという話ではなく、もう少し広くWebアプリケーションをどうやって作るかの話です。SPAでもMPAでも議論としては同じで、SPAにすべきかそうすべきではないということになる。 そういう意味でも、SPAを採用すべき勘所とか、Webアプリケーション全体の中のSPAの位置付けについて、先ほどの講演でもっと聞きたかった。

酒巻：個人的には、ちょっと古い内容でしたね。「DOM操作はjQuery」と言っていたが、個人的にもうあまりやりたくない(笑)。

佐川：そうそう、個人的には4年くらい前の感覚に思えました。その頃とはWebアプリケーション開発のやり方そのものが変わっている。もちろん（Webアプリケーションではなく）Webサイトを作るときにわざわざReact.jsとかAngularを利用しなくてもいい。そういう時はjQueryでもいいと思います。こういうものは当たり前ですが、適材適所で考える必要があって、それこそマネージャやアーキテクトの腕の見せどころなのではないでしょうか。

最後に

ここのところ、確かにエンタープライズでSPAの導入が多くなってきました。 一方でまだまだ事例が少ないこと、開発経験のあるエンジニアが少ないため導入しようとしてもなかなかプロジェクトとして進められないという現状もあります。この記事が、エンタープライズWebアプリの開発に少しでも寄与できたなら幸いです。

de:code 2016に参加中の、編集長の白石です。

今回は、編集部のメンバーそれぞれが興味あるセッションに参加してセッションレポートを書こう、ということになってまして、ぼくは「Big Data/機械学習がソフトウェア開発手法を変える! 〜静的アルゴリズム生成から動的アルゴリズム生成への道〜」というセッションを聴講しました。 スピーカーである田丸健三郎さんの語り口が心地よく、機械学習についてはかじったことくらいしかないぼくにとってはレベル感もちょうど良く、知らなかったことも数多く学べてとても満足でした。

以下に、簡単なセッションレポートを掲載します。機械学習については素人の、Webエンジニアによるレポートではありますが、何かのお役に立てば幸いです。 （ちなみに画像に沿えた文章は白石による補足文章であり、スピーカーご本人による発言ではないことをお断りしておきます）。

日本マイクロソフト株式会社 技術統括室 ナショナルテクノロジーオフィサー 田丸健三郎氏

もはやとても身近な技術、機械学習

今の時代、データソースは拡大の一途をたどっています。

そんな中、機械学習が非常に注目されています。以前は、ビッグデータの分析といえば高い専門性が必要な分野でしたが、機械学習によって安価で高品質な分析が可能になりつつあります。

従来アルゴリズムといえば、従来は職人による新規性、進歩性を競う芸術(?)の世界でした。

しかしそれでも、従来は機械学習によるデータ分析のアプローチよりは、職人によるアルゴリズム開発のほうが開発コストが低かったのです。かつてはデータ量も限られ、コンピュータリソースは非常に高価だったからです。

しかし今や、データ+機械学習のアプローチのほうが、アルゴリズムをプログラミングするよりも開発コストが安上がりになりつつあります。それは、クラウドによってほぼ無限とも言えるコンピュータリソースを手に入れられるようになったからです。

また、開発コストの面だけではありません。機械学習にとっての学習データの爆発的な増加、学習精度の大幅な向上など、機械学習を取り巻く環境も大きく進歩しています。

それにより、従来のようにアルゴリズムを静的にプログラミングするのではなく、データを分析し、アルゴリズムを動的に生成するというアプローチが採用されることが増えているのです。

機械学習とMicrosoft

例えば、Microsoftの製品においても機械学習は既に広く利用されています。意外な製品にも使われていると思われるのではないでしょうか？（白石的には、Kinectが関節の位置を特定するのに機械学習を使っているというのが少し驚きでした。まさかそんなところにも応用できるとは…）。

そして、ディープラーニングによる画像認識の精度は、人間の認識力すら超えつつあります。実際以下のグラフのように、Microsoftによる2015年の成果では、人間の認識エラー率を下回っているのです。

この進化は、ニューラルネットワークの多層化によってもたらされています。2012年には8層、2014年には19層、そして現在ではなんと152層にまで深く階層化できるようになっています。

実は、画像内のオブジェクトの認識率では、Microsoftは世界トップクラス。

動画のタグ付けなどにも実用化されています。

以下はMicrosoftにおける機械学習の歴史です。

Microsoftが今公開している対話型AIとしては、以下の２つが有名です。Cortanaは生産性の向上を目指して開発されており、女子高生AI「りんな」や、中国で大人気のXiaoIceは、人間の感情に寄り添うことを目指しています。

マイクロソフトのIoT基盤は、以下の様なビジネス上の変革を実際にもたらしています。

また、自動翻訳の分野も、機械学習が応用されている分野です。Microsoftも、Translatorというサービスを提供しており、現在50言語に対応しています。

次のバージョンであるバージョン4では、翻訳精度が大きく向上する予定だそうです。期待したいですね。

セッションを聞いての感想

はじめにも書きましたが、ぼくは機械学習の分野についてはほとんど知識がなく、軽くかじったことがあるくらいです。 そんなぼくにとっては、「機械学習による動的なアルゴリズム生成のコストが、プログラマーによる静的なアルゴリズム開発のコストを下回りつつある」というのはとても驚きました。

それが本当だとすると（実際本当なのでしょうが）、開発にあたって考えるべきはまず機械学習、データをどう収集してどう分析するかを最初に設計すべきだということになります。ぼくらプログラマーの仕事が大きく変わるかもしれない…と感じ、焦りと同時にワクワク感を感じたセッションでした。

エキスパートの佐川が、「de:code2016」のセッションレポート、日本マイクロソフトエバンジェリスト・物江修氏の「Developing on the Edge. 〜 WebプラットフォームとCordova 〜」をご紹介します。

今年の夏、MicrosoftはWindows 10の大型アップデート「Windows 10 Anniversary Update」を予定している。このアップデートで「Microsoft Edge」にも数多くのAPIが追加される。このセッションでは新しく追加されるAPIの紹介と、それらを利用したUniversal Windows Platform(以下、UWPと記載する)、Cordovaアプリケーションの開発ポイントを紹介する。

• Microsoft EdgeとWindows10のWebプラットフォーム
• EdgeHTMLの新機能とこれからの方向性
• Webプラットフォームを利用したアプリケーション開発

Microsoft EdgeとWindows10のWebプラットフォーム

初めに、Microsoft EdgeとWindows 10で「Webプラットフォーム」と呼んでいる事柄についてみていく。すでにご存じのとおり、Windows10には、2つのマイクロソフト製のブラウザが含まれている。Windows10から新しく採用された「Microsoft Edge（以降、Edgeと記載する）」と「Internet Explorer11」である。

Webブラウザが2つ入っている理由は、以下のとおり。

• Edgeは相互運用性を重視し、最新のWebコンテンツをブラウズするため
• Internet Explorer 11は過去のバージョンのIE向けに作られたコンテンツを従来どおりに見るため

この二つは物理的に完全に別なものとなっていて、レンダリングエンジンもJavaScriptエンジンも異なる。

EdgeのレンダリングエンジンとJavaScriptの組み合わせが、Windows 10用のアプリケーションを開発する際に使用されるWebプラットフォームになるが、現状、Windows 10で動作するアプリケーションのすべてがEdgeのエンジン（以降、EdgeHTMLと記載する）を利用しているわけではない。

どういう意味か。

アプリケーションとの組み合わせを見てみる。Windows 10から採用されたUWPアプリケーションは、EdgeHTMLを使用している。しかし、以前の環境で作られたWindows 8系のいわゆるWindowsストア・アプリケーションやデスクトップ・アプリケーションであるWin32アプリケーションは、以前の Tridentを使用している。

新しいSDKに含まれるWeb ViewコントロールはEdgeを使用するようになっているので、もしどちらも選択が可能である場合はEdgeHTMLを使用する。

Windows 10 Anniversary Updateまでに搭載されるEdgeの新機能

ここからは「Windows 10 Anniversary Update」までに搭載されるEdgeの新機能について紹介していく。Edgeのエンジンが、Windows 10でアプリケーションを開発する際に使用するWebプラットフォームの機能になるので、そのままアプリケーションから使用できるようになる。

Edgeの2016年の機能実装を含めた展望については、今年の2月にEdgeの開発者ブログで公開されており、その記事では優先課題とて5つ存在する。（参考までに、日本語の開発者ブログはこちらです）

1. WebテクノロジとWindowsストアによるモダン拡張機能プラットフォームを提供する
2. アクセシビリティとインクルーシブ デザインにより、Microsoft Edgeを使うすべての人の力になる
3. Microsoft Edgeの基本であるセキュリティ、パフォーマンス、効率を引き続き向上させる
4. Webの未来を見据えて開発する
5. コミュニティのフィードバックや参加を可能にするチャネルを増やす

まずは拡張機能。ネイティブ形式のアドオンとは異なるWebテクノロジを活用した、開発者になじみのある拡張機能プラットフォームを作成する。現在のInsider Previe版のEdgeでは同じくプレビュー版のアドオンを使用できるようになっている。

次にアクセシビリティ。この項目では「HTML Accessibility API Mappings」と「Core Accessibility API Mappings」への対応、「ハイコントラストのサポート」や「視覚障碍のある方にとっての読みやすさ」や、「フォーカスおよび選択の操作性の向上」などが表明されていた。

基本機能では、「JavaScript エンジンのベンチマークの向上」「さらなるセキュリティの強化」たとえばFlashを別のプロセスに分離し、不要なコンテンツ処理を保留したり、GPUレンダリングの強化などが表明されている。

Insider Preview に搭載された新機能

ここからは「Insider Preview」に搭載された新機能について紹介していく。現在、Insider Previewに実装されていて、実際に試すことができるものが約20個以上、開発中のものを含めると36個くらいあり、しかも、これは現段階のものなので、これからまだ増える可能性がある。

• Web Speech API (synthesis)
• Fetch API
• Beacon
• Web Notifications
• WebRTC
• OPUS open audio
• VP9 open video playback
• WOFF File Format 2.0
• FIDO 2.0 Password
• Canvas 2D path2D
• Ambient Light Events
• Color input type
• Element
• Default parameter (ES2015)
• Destructuring (ES2015)
• Generators (ES2015)
• SIMD (after ES2016)
• Exponentiation Operator (ES2016)
• Array.prototype.includes (ES2016)
• Async Functions (after ES2016)

Insiger Previewに新しく搭載された機能をいくつか、デモを交えながら紹介する（この記事ではデモ資料省略）。

Web Speech API

IETF標準の言語タグである「BCP 47」に対応しており、タグの指定によってさまざな言語の指定ができる。音量、音声、速度はもちろん、SSML (Speech Synthesis Markup Language) を使用して音声合成時の修飾的情報を指定したりもできる。

Fetch API

「Fetch API」は、Webサーバと通信するためのAPIで、Promise ベースで非同期処理を行える。従来の「XMLHttpRequest」の仕様のさまざまな不足分をなくし、より細かい処理ができるようになっていて、将来的に「XMLHttpRequest」は「Fetch API」に置き換わると言われている。「Fetch API」は「XMLHttpRequest」とは異なり「Service Worker」からも使用できる。参考までに「Service Worker」とは、「Progressive Web Apps」というモバイルWeb向けの新しいコンセプトだ。

Web Notifications

「Web Notifications」はユーザーへのデスクトップ通知の設定や表示のために使われるもので、EdgeではWindows 10のアクションセンターと統合される。この通知には、カスタムアイコンやタイトル、メッセージが設定可能だ。Service WorkerとPush APIを組み合わせると、サーバからのPuch通知を受け取って表示したりということが可能になるが、残念ながらこの2つはまだサポートされていない。しかし、ブラウザ上でアプリケーションが稼働状態であれば、WebSocktsやWebRTCの通知を受け取ってデスクトップ通知を表示するといったことが可能だ。

WOFF2.0フォント

WOFF2.0フォントは、従来のフォントファイルのサイズを30%以上多く減らす新しいフォーマットだ。日本語を含むアジアフォントではおよそ50%前後節減できると言われている。現在、Webページの60%以上でカスタムWebフォントが使用されていて、平均的にWebページのサイズの5.3%を占めると言われているので、これをサポートすることでページの表示速度の向上が期待できる。

WebRTC

WebRTCについて。RTCとは「Real Time Cominucation」の略で、プラグインなしでWebブラウザ間のボイスチャット、ビデオチャット、ファイル共有ができる技術がWebRTCだ。Firefox、Chromeは、Edgeに先行してWebRTC1.0をサポートしているが、EdgeはWebRTCの使い勝手を改善したORTCのみをサポートしてた。このWebRTCとORTCは互換性があるので、互いに通信を行うことができるが、さらなる相互運用性を高めるためにEdgeHTML 15では、WebRTC1.0もサポートすることになった。

RTCの相互間運用性

その他

そのほかにもオーディオ用の高い圧縮フォーマットであるOpusや動画圧縮コーデックのVP9、細かい時間の計測に使用される「High Resolution Time」のLebel2や、フォルダのドラッグ・アンド・ドロップ、Webブラウザで生体認証を行うためのFIDO(ファイド)2.0、それからBeacon、アクセシビリティ関連のエレメントなどなど多くの機能がサポートされる。

ハイブリッド・アプリケーション

説明した機能は、ハイブリッド・アプリケーション開発用の様々なフレームワークを使用することで、スマートフォンやデスクトップのアプリケーションとして利用することができる。ここからは、Webプラットフォームを利用したアプリの開発について紹介していきます。

ブラウザで動作するWebアプリケーションを、ハイブリッド・アプリケーション化するメリットは3つほどあります。

• オフライン
• アプリストアのエコシステム
• プラットフォーム/ハードウェアの機能

もう少し待っているとEdgeでもService WokerがサポートされてWebアプリケーションでもオフラインの利用が可能になるので、実際にアプリケーション化するメリットというのはアプリストアのエコシステムを使用するとか、Webブラウザでは使用できないハードウェアの機能を使用するということぐらいに差が縮まる。

このハイブリッド・アプリケーションの形式には、Packageアプリケーションと、Hotedアプリケーションがある。Packageは、オフラインで利用可能。サーバサイドのリソースががならずしも必要でない。Hostedは常に最新のコンテンツで実行でき、開発の一元化が可能だがオフラインでの使用が前提となる。ざっくり言うとコンテンツの配置場所くらいしか違いはない。

Universal Windows PlatformとCordovaを利用したHostedアプリケーション

UWPとCordovaで、どのようにHostedアプリケーションを作るか、というのを紹介する。

UWP

これがWindow 10に用意されている、アプリから使用可能なOSリソースだ。プッシュ通知や、タイルへの情報表示、予定表、アドレス帳へのアクセス、Cortana連携とWindowsランタイムを使用し、さまざまなハードウェアにもアクセスできる。作成は

1. package.appmanifestの[アプリケーション]タブで[スタート]を指定
2. [コンテンツURI]タブでWinRTへのアクセスを設定
3. 使用しないファイルを削除

Cordova

Tools for Apache Cordovaが提供する機能は

• ターゲット
• ビルド
• デバッグ
• エミュレータ
• コード補完

がありiOSアプリケーションに対するビルドにはMacが必要ではあるが、ほとんどの環境(Android系/iOS系/Windows系)で実行可能だ。CordovaにおけるHostedアプリケーションの作成は以下の３つで行っていく。

1. config.xmlの編集
2. www¥scripts¥index.jsの編集
3. index.htmlの編集

尚、Apache Cordovaを使用したホスト型Webアプリケーションの作成についてはこちらの資料を見るとよい

Visual Studioで提供されている検証環境

• Ripple
• Android
• Monaca Debugger(iOS/Android)
• Windows Phone

その他、Mac OS用、リモートエージェント、Mac in Cloud(Mac OSのホスティング)などがある。

最後に、Webプラットフォームについてということと、この夏に向けていろいろなAPIが出てくる。そして、Webではできないことができるようになると物江氏は締めくくり、Microsoft Edgeのすぐそこにある未来について熱く語ってくれた。今最も熱いブラウザは「Microsoft Edge」ではないだろうか。