2018.08.14 (Tue)

毎月恒例となりました。上場企業の常時SSL化レポート、2018年8月版をお送りいたします。7月下旬のchrome68の影響で確実に増えています。

20180814_sslreport201808
(ついに6割の域に)

対応率がついに6割目前。というか、もう6割対応済みサイトですと言っても良いですねコレは。6割はもう少し先かな…と思っていたのですが想像より早かったです。

10月のchrome70が出る前後ではまた更に増えるのでしょうね。今や常時SSL化しない理由は何もありませんので、この勢いで増えていって貰いたいなーと思います。

 

目指すは常時SSL化100%

本レポート、Let’s Encrypt のスポンサー、自社の espar というCMS静的化製品。弊社は、これらすべての常時SSL化推進活動の先に 上場企業の常時SSL化対応率100% という目標を勝手に置いています。

先月のレポートでも書いた通り新規上場企業は毎月のようにチェックしてますが、未だに常時SSL化対応しないまま新規上場している会社がちょいちょいあるんですよね。まだまだ啓蒙が足りません。個人的には、この会社の株だけは買わないでおこうと思ってしまいますね。ウチは身元を明らかにしませんと宣言してるようなものですから。

上場企業が全てEV証明書による常時SSL化が理想と考えていますが、こっちはなかなか難しいでしょうね。証明書関連のベンダー様も巻き込みながら、引き続き啓蒙をしていきたいと思います。

 

以上、8月のレポートでした。また9月もレポート致します。


2018.08.10 (Fri)

弊社では、昨年末から毎月のように上場企業約3600社の常時SSL化対応状況を調査しています。一つ一つ目視するってのはさすがに非現実的なので、当然ながら自動化してまして…

20180810_sslcheck.png
(自動実行している様子。Go言語で内製したもの)

こんな感じで調査プログラムを毎月実行しています。実装言語はGoogleのGo言語。

上場企業約3600社分のURLを渡してやると

  • 使用している証明書の種類は何か(DV/OV/EV)
  • 認証局情報等を含む証明書の詳細情報あ

などの情報がだいたい30分ぐらいで返ってくるようになってます。で、突然なのですが、この常時SSL化対応調査プログラムのソースコード公開することにしました。

20180810_github
(名前は厳密にはcertcheckかも知れないけど作り始めた時の名前そのまま。ライセンスはGPLv3)

リポジトリはこちら

GitHub - feedtailor/SSLCheck: SSLCheck is a simple command line tool to verify ssl certificate written in golang.

最初のひな形を僕がGo言語で書いて、それを@t0shiyaがブラッシュアップした非常にシンプルなプログラムです。実質1ファイルですしね。弊社で作る上場会社レポートではもちろん、先日リリースのあったJIPDECさんとの共同調査でも基本的に同じものを使っています。

 

オープンソースによるアウトプット

先日、GitHubのGo言語リポジトリのGoUsersのWikiに弊社もエントリさせて貰いました。

が、ふとGo言語的なアウトプット余りしてないな〜ということに気が付きまして。今回は、そんなGo言語アウトプットの一環でもあります。

常時SSL化対応を啓蒙しているポジションなので、色んなURL一覧を持ってる企業さんがこれを使って同じようにレポート出してくれたら良いなーとか思ってます。常時SSL化の促進に寄与できたら良いですね。

今から2年前、アプリ開発を内製でやっていた頃、こんなエントリを書いたことがありました。

「インターネット」とか「ネット」とかでマルっと表現される全てのものにどこかしらオープンソースの恩恵を受けている所は必ずあって、多くのベンチャーよろしく弊社も何かしら貢献したいと考えてきました。()弊社の github グループを作りました。ソースを公開していきます)

社内資産であったiOS用ライブラリをオープンソース化した時に書いたものでしたが、アプリ開発部門を内部に持たないようになってから、オープンソースな取り組みが余りできてなかったんですよね。

何かしら…という思いは常にあってもどかしかったんですが、規模にこだわらなければネタは社内に色々あることが分かったので、今回公開することにした次第です。Go言語なモノに限らずオープンソースなスタンスでこれからもアウトプットしていきたいと思います。

 

という訳で常時SSL化に絡むオープンソース化についてでした〜。

あ、ちなみに弊社は今、Go言語ファーストでやってます。この種の社内ツール類もほぼGoで書くのが基本にしてて、プロダクトやサービスも含めてGo言語をフル活用させて貰っている昨今です。

Go言語を採用した経緯は2年近く前に WP Guard(espar) の開発にGo言語を選んだ理由 なんてエントリを書いてますので宜しければ御覧下さい。Go言語、良いですね。


2018.08.08 (Wed)

(所要時間:約2〜3分)

パブリックコメントとは、行政機関が国民に広く意見を求める仕組みのこと。よく耳にする言葉で存在は知っていましたが、自分には無縁なものでした。日々の忙しさを言い訳に行政に無関心ではいけないのですけどね。

が、最近お付き合いさせて頂いてるJIPDECさん(PマークISMSの関係者なら知らない人はいないでしょう。正式名称は一般財団法人日本情報経済社会推進協会)の方に、セキュリティに関して意見する機会があると紹介頂きまして、これも何かの縁かもと人生初のパブリックコメントを出してみました。

対象はこれ。

総務省|「地方公共団体における情報セキュリティポリシーに関するガイドライン(案)」等に対する意見募集

20180809_soumupubliccomment

自治体の情報セキュリティはこうしていこうよっていうガイドラインですね。PCの扱いとかネットワークとかサーバとかメールとか、そのへんのルール集です。見直しを定期的に行ってるみたい。

個人的にいつも思うんですが、行政の方って専門家じゃないからセキュリティ系ベンダーに恐怖心煽られるだけ煽られて製品かわされてると思うんですよね。強迫観念訴求型ビジネスに事実上の公金注入になってる可能性が高い。よくよく考えたら不要で、恐らく結構な税金の無駄遣いをしてる。

そのへんの持論を展開しました。ベンダー批判は趣旨じゃないので、ガイドラインとしてこうするのが一番税金の無駄遣いにならないよって感じですけど。

が、所定の方法で送っては見たものの何の反応もなく今に至ります。長すぎたのかも(笑) で、折角書いたので、自分が総務省にどんなコメントをしたのか公開してみようと思いました。長いですが本エントリ最後に全文掲載します。

意見の趣旨は、大きく

  • 行政機関でメール添付ファイルの扱いを全面禁止した方が良い(その理由)
  • 行政機関の情報発信用Webサイトは全て静的化した方が良い(その理由)

の2点。

後者は、その主張を弊社は espar という自社事業として発信してるので、宣伝色がなるべく入らないように書いたつもりです。参考情報として過去のブログエントリのURLも書きましたけど。(募集要項に参考情報あれば添付するよう記載があった)

だだだーと思うままに書いてみて、募集要項で指定されてるタイトルで指定のメアドに Gmail から送信しました。

20180809_application
(誰が書いたかの身元も明らかにする。法人代表として書いたので公開情報そのまま記載)

メールサーバからエラーが返ってきている訳ではないので多分受信箱には入ってるのでしょう。関係者の誰かの目にとまると良いですね。ひょっとしたら e-Gov とかに載ったりするのかも知れませんが、そもそも受理されたか不明なのでよく分かりません。

まぁ何はどうあれ、今回自分の考えも改めて整理できたのでいい機会でした。ご紹介頂いたJIPDECさんに感謝です。

ちなみに、e-Govのサイトにはパブリックコメントのページもあって、行政分野や所管府庁から意見募集要項を絞り込めたりして、色んなことで行政が意見を求めていることが分かります。

まぁ数十・数百ページに及ぶPDF資料を読み込むのは大変ですが、メールで手軽に送れたりするので自分の興味ある分野でパブリックコメント書いてみるのは如何でしょうか。自分の意見が取り入れられるかどうかは別にして、思考の整理にはなっていいと思います。

 

という訳で総務省にパブリックコメントだしたよーという話でした。以下、僕が提出した全文です。

地方公共団体における情報セキュリティポリシーに関するガイドライン(案)等に対する意見

掲題の通り、先般公開された「地方公共団体における情報セキュリティポリシーに関するガイドライン(案)」に対するコメントを以下に記します。ご査収の程を宜しくお願い申し上げます。

 

■ 提出者情報

(略)

 

■ ガイドライン全般について

貴省も地方自治体も、セキュリティベンダーやセキュリティコンサルタントに言われままに各種防衛施策を積み上げてきた結果、肥大化してしまったことが読み取れるガイドラインでした。

お言葉ではありますが、「セキュリティインシデントからどう身を守るか」に執着し過ぎており、「セキュリティインシデントをどう根絶するか」という思考が持てていないように感じます。以下にガイドラインに度々言及されている電子メールとWebサイトについて当方の意見を記します。

 

■ 行政機関におけるメールの添付ファイル使用全面禁止の提案

ページ ii-31 の (14)-⑥をはじめ各所に添付ファイルについての言及がありますが、昨今の標的型メールを例に出すまでもなく、情報漏えい事件や不正アクセス事故の多くがメールに添付されたファイルに端を発していることに着目する必要があります。なぜ、行政業務におけるメール利用で、ファイルを添付することを前提にする必要があるのでしょうか。メール添付を行わずとも情報の授受は行える筈ですから、セキュリティインシデントの根源となるメール添付ファイルの扱いは送受信の両方で全面禁止すべきと考えます。

 

□ 受信

添付ファイルを使用せずとも、メールの本文に内容を記載する、Webサイトで入力フォームを用意するなどで100%代替が可能です。また国民や都道府県民が情報を行政側にファイルを送るに際しても宅ふぁいる便やfilestorage等のファイルダウンロードを促すURLによる伝達が可能です。

そうした安価な代替手段があるにも関わらず、依然として任意のメール添付ファイルを受け付けているからこそ、ウィルスの感染、バックドア設置、不正アクセス等のリスクが生まれ、その防衛に高額なウィルス対策やMTU・ファイアウォール・IDS/IPSを導入することになります。それは正しい税金の使い方でしょうか。(運用をする為の職員の人件費、外部委託費も含む)

「添付ファイルを禁止しても行政業務が回るようにできないか?」という視点で行政業務を見直すべきと考えます。

行政側のメール受け取りスタンスとして典型例とお見受けしたので、本パブリックコメントの受付方法についても言及します。意見募集要領の s14520915301.doc ファイルの「3.意見提出方法」には

件名には「地方公共団体における情報セキュリティポリシーに関するガイドライン(案)等に対する意見」と記載してください。また、 意見の内容はメール本文に直接書き込むか、添付ファイル(Microsoft Word 2013で開くことができるファイル形式)として提出してください。

とあります。これは「地方公共団体における情報セキュリティポリシーに関するガイドライン(案)等に対する意見」というタイトルをつけたメールであれば、添付したファイルを貴省が開くに違いないという推測を第三者にさせているようなものであり、お言葉ですが貴省が自らセキュリティリスク発生の入り口を作っているようなものです。だからこそ、ネットワーク分離や仮想デスクトップ環境等の各種防衛システムを導入しているものと想像しますが、本来、「添付ファイルは一切受け付けません」とすれば、本パブリックコメントの電子メール受付におけるセキュリティインシデント発生リスクは限りなくゼロになる筈です。

本例に見られるように、行政側でメールを受信する姿勢如何で、セキュリティインシデントについて、(1)発生しうるものと受容して防衛に税金を投ずるのか (2)そもそも根絶を追求するのか、が変わってくると考えます。そもそもリスクを根絶できるのであれば、発生する可能性を受容して防衛することに投ずる税金や職員の時間は格段に削減できる筈です。

少々本筋とは外れますが、メールではなく意見入力用の問い合わせフォームを用意すればなお良いと考えます。入力内容をデータベース等に集約するための転記作業の工数削減になる筈ですし、転記担当者の無駄な労働削減分を別の価値創出の時間に当てられるに違いありません。本来、第三者からの意見を集約するには収集後の業務円滑化を見据えWebのフォームを使って収集すべきです。

国や地方自治体は、本当にメールの添付ファイルを受け付ける必要があるのか?を考えるべきであると思います。

 

□ 送信

ファイルを誰かに送る方法には、メールに添付するという方法を使わずとも、Google社のGSuiteやDropboxなどファイルを安全に保管した上で、権限を有する人物にのみ渡す手段が既に沢山あります。メールの送信時にファイルを添付する手法に頼る必要は全くありません。(外資系のサービスを国や地方自治体が使う是非はありますが、それを言うならそもそもWindowsそのものも使用をやめるべきです。)

メールに添付してファイル送信することを避けることで、機密情報を含むメールを職員が誤送信するリスクもゼロ化できるメリットがあります。本来ファイルを誰かに渡す場合、

  • ファイル共有システム等に機密情報を職員が登録する
  • 当該のファイルにのみ一時的にアクセスできる権限をファイルを渡すべき人物に付与する(期間限定、認証付き)
  • ファイルを渡すべき人物にその旨をメールのテキスト本文で伝える
  • ファイルを受け取るべき人物は当該のシステムから期限内に別途教わった認証を通りファイルをダウンロード入手する

という手順がリスクを限りなくゼロにできる正しい方法であると考えます。

以上、添付ファイル使用の禁止についての提案を述べました。添付ファイルは全てのセキュリティインシデントの起点といっても過言ではありません。そして昨今では、添付ファイルに頼らずとも情報の授受ができる環境が整っています。使い慣れた添付ファイルという手段を使う「楽さ」はありますが、その手段を使い続けることによる事故を防ぐために余計な時間と税金を投入することが果たして国民や都道府県民の為になるのかを考えて頂きたいと思います。

貴省や各地方自治体が全面的にメール添付を廃止することで行政におけるセキュリティインシデントの多くが防げる筈です。

 

 

■ DDoS攻撃対策やWebサイトの改ざん対策について

国や地方自治体が提供するWebサイトを、悪意ある第三者から守るための仕組みにも無駄な時間と税金をかけすぎであると考えます。ガイドラインにも言及がありますが、高額なファイアウォール・WAF・MTU等が本当に必要かどうか吟味すべきであると思います。DDoS攻撃やWebサイトの改ざんの技術的な原理を理解していれば、それらを防止する高額なものは基本的に不要だからです(または安心の為に極めて安価なものに抑えることができる)

□ 行政が対外的に発信するWebサイトは全て「静的化」する 情報提供を目的としたWebサイトを静的化して公開することを前提にすることを提案します。

Webサイトの改ざんをはじめとする、昨今のサーバ側セキュリティインシデントの発生理由は、プログラムやデータベース等が動作するシステムを「そのまま」インターネットの世界に「晒す」ことにあります。アクセスの度にプログラムが動作するシステムを「晒す」ことにより、誰もが当該システムにアクセスできるようになり、結果、悪意ある第三者がしかける攻撃で「システムが想定しない形でプログラムが動作」して事故発生となります。

それを守るとうたうのが高額なファイアウォール・WAF・MTUですが、そもそも「システムが想定しない形でプログラムが動作する」ことのないシステムにできれば、それらは不要な筈です。それを実現する唯一の方法が、Webサイトを「静的化(htmlファイル化)」して、公開用途に限定した別の公開サーバにページ群を配備することです。

  1. 発信すべき情報(コンテンツ)を管理するシステムを職員が操作する
  2. 当該システムのページを更新の度に都度静的化(html化)する
  3. 2.で生成したファイルを公開用途の為だけに用意した公開サーバに転送する

という形態です。3.にある公開用途に別途用意するサーバには、

  • 80/443番ポート(http/https通信)のみアクセスを許可 (余談ながらhttpは即時httpsに転送。サイトは常時SSL化を前提)
  • サーバ内にはプログラムやデータベースを存在させない

という設定を施すことで、理論上第三者攻撃は一切成立しなくなります。不正アクセスも改ざんも原理的に起こりません。なぜなら、「システムが想定しない形でプログラムが動作」するということが理論上起こり得ないサーバになるからです。

一方、上記1.のコンテンツを管理するシステムは

  • IP制限
  • Basic認証
  • クライアント証明書確認
  • ホスト名には別名を付与

などの設定を組みわせる事により、悪意ある第三者がコンテンツ管理システムにたどり着くことすらできない状態にすることができます。こうしてWebサイトを静的化することと、公開用サーバを別途用意する事によって、国や地方自治体が情報発信するサイトは、改ざんされることも不正に侵入されることも理論的に発生しえない状態を作ることができます。

 

□ 「静的化」はDDoS攻撃にも有効

DDoS攻撃にあった時に障害が発生する理由は、プログラムやデータベースが動作するシステム(1つの処理に時間がかかる)が大量のアクセスに処理が追いつかなくなる為に発生します。

しかしWebサイトを静的化していれば、公開用途のサーバが処理に追いつけなくなることは原理的にありません。(通信帯域がパンクする問題が先に発生します。これはまた別の問題です)

(A) システムをそのまま晒す場合 : アクセスを受ける → プログラムが動作する → データベースが動作する → プログラムが整形する → 応答する (B) 静的化する場合 : アクセスを受ける → 予め静的化されたファイルで応答する

後者の(B)のほうが圧倒的な量のアクセスをさばくことができる為、スペックが低いサーバでも相当数のアクセスに耐えることができ、サーバ費用の削減にも繋がります。

 

□ 「静的化」はサーバダウン時の復旧にも有効

サーバダウン時の復旧が即時にできないのは、プログラムやデータベースが動作するシステムをそのまま晒しているからです。Webサイトを静的化していれば、障害時に用意する別の公開用サーバにファイル群をコピーするだけでサイトは復旧できます。10分も要さず数分で、有事の際でもサイトを元の状態に戻すことが可能になります。高負荷時の為に高額なロードバランサーを導入したり、高額なサーバを用意する必要はありませんので費用削減にもなります。

本件については、当方がブログで記述していたことがございますので宜しければご参照下さい

 

Zenlogicの障害から学ぶべきこと

https://blog.feedtailor.jp/2018/07/10/zenlogictrouble/

行政や生活インフラ系の企業や組織のサイトは、今すぐ静的化と回線上流の見直し検討をして欲しい

https://blog.feedtailor.jp/2018/06/19/osakaearthquake/

 

以上、国や地方自治体の情報公開を目的としたサイトを静的化すべきであることについて書きました。Webサイトもメールと同様、当然と思い込んでいるWebサイトの構成やあり方で発生する問題を防ぐ為に、余計な手間やお金をかけざるを得なくなっているケースが多々あります。Webサイトについても、当たり前を疑い、「守る」ことに執着するのではなく「根絶する」という視点を持って頂きたいです。

 

 

以上、長文ですが国や地方自治体の、メール・Webの2点についてガイドラインに対する意見を述べました。貴重な税金を、セキュリティベンダーやコンサルタントに言われるがまま積み上げてしまった対策に浪費して欲しくないです。

セキュリティインシデントの原因や根源を技術的な広い視点で見れば、それらの発生リスクを限りなくゼロに近づけることができるだけでなく、時間もお金も節約することが可能です。技術を理解し、最も合理的かつコストパフォーマンスの高い施策を広げて下さい。納税する個人として、また法人の代表として切に願います。国や地方自治体におかれましては、「臭いものに蓋をする」セキュリティ対策思考ではなく、業務フローも勘案した「臭いものを根絶する」セキュリティ思考を持って頂きたいと思います。

以上


2018.07.17 (Tue)

上場企業の常時SSL化レポートの2018年7月版をお送り致します。

継続的な統計を取っていると業界のイベントと連動した動きが観測できて良いですね。予想通り、今月リリースされるChrome68に備えた駆け込み対応が増えたような結果となりました。

20180718_aosslreport201807
(まだまだ増えて欲しいところ)

詳細はこちらをご覧頂くとして。今月は常時SSL化対応している上場企業がなんと 2.5ポイント増 でした。これは調査を始めた昨年12月から最高値です。だいぶ駆け込んでますよね。

とは言え、まだ全体の6割にも満たないという状況ですので、上場企業各社におかれましては次のマイルストーンである2018年10月のChrome70に備えて、どんどん駆け込んで貰いたいと思います。

Chrome70では、

20180718_chrome70

こんなふうにだいぶ残念な表示になりますので、直前の2018年9月はまた今月同様の増加率になるでしょう。その頃には全体の6割は常時SSL対応済ませておいて貰いたいですね。

 

会社四季報を買った

余談です。

毎月のように現れては消える上場企業や上場廃止企業、また社名を変更する企業を把握してるので、自然とまだ知らない上場企業に関心が向きます。

特に新規上場はURLもチェックするので、確認ついでにどんな会社かサイトを眺めたりしてると結構面白い。で、数値的なサマリもザックリ見ようってんで四季報買いました。

20180718_shikiho

久しぶりの購入です。何となく新たにEV対応した会社を数字面からザックリ見るにはやっぱり便利ですね。だからどうって訳ではないのですが。

ただ、EV証明書対応している会社は株価がどうこう…みたいな傾向が見えたりすると面白いだろうなとは思います。まぁその相関はさすがに見られないでしょうけど、何となく。

 

という訳で2018年7月のレポートでした。また来月もレポートします。


2018.07.10 (Tue)

ネット界隈騒然とした今回のZenlogicの障害ほぼ復旧したようで良かったです。復旧に全力を向けておられたエンジニアの皆さん、大変お疲れ様でした。連日ホント大変だったと思います。

20180711_serverroom.jpg

さて、今回の障害で、

  • Webサイトが見えなくなった!
  • サーバからデータを取得できない!
  • メールも使えない!

など、阿鼻叫喚の声が聞かれましたが、他社に移ってハイ終了!もうZenlogicなんて使わない!とか、今回は長かったけど次は大丈夫だろう…と言って終わりにすべきではないでしょう。

落ちたから引っ越す。復旧したから次回は無いことを祈る。それでは何の学びもありません。アプリに必ずバグがあるように、サーバは必ずトラブルものだからです。

利用者として事前にできることは無かったか

いつもこう思うんですよね。

弊社では障害に巻き込まれた時、はらいせに解約とか、サーバ引越して完了とか、復旧まで耐えて次回がないことを祈るとか、そういう対応はやりません。何も変わらないので。そこから学びを得て手を打ちます。万が一、同じ障害がまた起こってもビクともしないように、すぐに復旧できるように。開発会社・サービス運営会社として当然です。

今回の Zenlogic 障害では、やっておけば業務停止にならなくて済んだのに…と思う点が幾つもあります。それをせず「落ちた!Zenlogic許さん!解約する!」というのはちょっと違うと思うんですね。

そこで今回、レンタルサーバにおんぶにだっこではなく、今回のような障害から受ける被害を最小限にする為の、防災・減災の策を2つ提言させて貰いたいと思います。

 

1. メールサーバは分離する

まず、Webサイトと同じサーバでメールを使うのはやめるべきです。今すぐに。

投資の格言「卵は一つの籠(かご)に盛るな」に学びましょう。1つのかご(サーバ)に卵(機能)を盛るから、障害時に道連れで全く何もできなくなるのです。役割で分けるのが良いです。

メール機能を分離する方法としてお勧めなのは以下3つ。

弊社は A) です。Gmailを会社のメールサーバとして10年以上使ってます。お客様にも御提案したり、最近は移行の御支援もしています。別にGoogleのパートナーでもなんでもなく、現時点でメールに関しては費用対効果が最も高い最高の選択肢だと思っているのでオススメしている次第。

Gmailは独自ドメインを割り当てることができ、自社のメールサーバとして使えます。何が良いかって、レンタルサーバが用意するメール機能を使うのとは桁違いに安全なこと。それは設定を見ても分かります。

$ dig feedtailor.jp MX +short
1 aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
10 aspmx2.googlemail.com.
10 aspmx3.googlemail.com.

これは、弊社の feedtailor.jp ドメインのメールサーバ設定を見ている様子ですが、小難しい説明をすっ飛ばして簡単に言うと、5重に冗長化されたgoogleのシステムに弊社宛のメールをさばいて貰っていることを意味します。メール機能を分離できるだけでなく5重に守られたメールサーバ。

これに対して、レンタルサーバのメール機能を使う場合、多くは1重です。そしてWebサイトと共存。

どちらが安心かは明白ですね。

今回、Zenlogic の障害で被害を被った有名所のひとつに歌舞伎座があります。サイトこそ Zenlogic だったため落ちてしまったようですが(障害報告)、彼らのメール環境はどうだったでしょうか。

$ dig kabuki-za.co.jp MX +short
10 aspmx.l.google.com.
30 aspmx2.googlemail.com.
20 alt2.aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 aspmx3.googlemail.com.

G suite ですね。分離されています。恐らくZenlogicのサーバにはWebサイトの機能しか持たせていません。だから、今回の障害でWebサイトこそ落ちてしまいましたが、歌舞伎座の関係者全員がメールを使えなくなるという事態は避けれていた筈です。

G Suite は1メアドあたり月額500円かかりますが、これを安いと見るか高いと見るか。G Suite から受けられる恩恵はメールだけじゃないので僕は激安だと思いますが、それでもお金をかけたくないという方には別の選択肢があります。

再掲になりますが、

のうち、BかCのいずれかが良いです。Cなら10メアドまで無料。Bならメアド無制限で月額100円切ります。

要するに、メールもWebサイトも大事なので、同じサーバに盛るのではなく、サーバ分離しましょうということです。そして、できれば分離したメールサーバは多重化されてる方が安心ですよと。

 

2. Webサイトは静的化する

3年前ぐらいから、僕は全てのWebサイトは静的化すべきという持論を持っています。今やっている静的化サービス espar もその文脈で展開しています。

静的化とは、Wordpressを始めとするCMSサーバをそのまま公開するのではなく、全ページ html に変換して公開用の別サーバにページ郡をホスティングするという技術です。1クッション置くわけですね。ミラーリングということもあります。

20180711_espar
(CMSサーバではアクセスを受け付けない。html化した先のサーバで受け付ける)

静的化されたサイトは障害に強い

静的化のメリットとして高速化セキュリティ向上はよくあがりますが、実は障害に強い・復旧を超絶楽にする、というメリットもあります。今回のような障害が発生しても恐らく復旧に15分もかかりません。

なぜなら、静的化とは、ファイルをサーバに置くだけでサイトが機能する状態にする ということを意味しているからです。なので、サーバを新たに用意してファイルコピーで復旧完了です。障害対応フローは、下図のようになりますね。

20180711_recovery

  1. Webサイトが落ちます
  2. 別のサーバを起動します
  3. 手元にあるhtml化したファイル群をコピーします
  4. DNSを新しいサーバに向けます

以上で復旧完了です。あとはDNSの伝搬を待つだけ。簡単ですね?ちなみに2.の新サーバは、例えばさくらVPSならオンライン申込みで10分かかりません。AWSのEC2だと手作業でも2,3分。

肝は3の部分。これが面倒なので、2のサーバを常時用意しておいて、CMSから静的化を行い常に予備用サーバにコピーを行っておくということをします。そうすれば、障害復旧に要する時間は実質 4. だけです。爆速。こんな感じですね。

20180711_prevention.png

余談ながら今回の zenlogic の障害では、DNSの変更もできないなんて噂もありましたが、それに備えてAWSのRuote53をネームサーバとして予め指定することで回避も可能でしょう。

静的化の技術

重要なのは、上記の復旧フローの3.にあるhtml化したファイル群。これを作らなきゃいけません。

弊社の espar は静的化を含めたややこしいことを全部やりますよ、というサービスですが、何も静的化は弊社の専売特許ではなく他の選択肢が沢山あります。自社に最適なものを選ぶのがいいと思います。

WordPress を使っているなら、無料の StaticPressSimply Static などのプラグインがありますし、Movable Type と公開用サーバを組み合わせても良いでしょう。また PowerCMSNOREN など、静的化を前提にしたシステムもあります。

問い合わせや検索は?

問い合わせフォームやサイト内検索はどうする?という声も聞こえてきそうですが、今やもう2018年です。CMSに頼らずとも静的化されたページで実現できる技術が沢山あります。

こういったものを使えば、Webサイト全体を静的化できます。つまり、公開用サーバにはPHPもDBも何にもいりません。

CMSという複雑なシステムをそのままネットに公開するから復旧が遅くなる(または出来ない)のです。新しいサーバを用意するにしても、環境を作り、設定を行い、データベースを移行する。普通はできません。

CMSはそもそも「コンテンツ管理」だけが仕事です。「公開」という役割は分離すべきです。

今回の zenlogic 障害を教訓に、是非 Web サイトの静的化を真剣に考えてみられることをオススメします。これ以上の障害時対策はありません。なんせコピーして完了ですから。少し工夫すればDNS変更だけで復旧する環境にできます。ちょっと強力なスペックのサーバを借りるより、低めのスペックのサーバを2台かりて静的化したほうがずっとコストパフォーマンスも良いので、財布にも優しいです。

無論、全てのサイトにおいて静的化が万能という訳ではありません。ただ、個人的な感触では7,8割のサイトが静的化だけで十分です。

 

という訳で、障害に強い環境づくりの提言2つご紹介しました。

Webサイトやメールをお使いの企業や組織、またそういった方々を支援する制作会社さんにおかれましては、今回の障害で「Zenlogicからサーバを移転したら良い」と安直な選択で課題解決したと考えるのではなく、どうすれば障害が起こってもサービスを維持できるのかどうすれば即座に復旧できる環境を作れるのか、という視点での見直しを図ってみられることをお勧めします。

失敗から学ぶことは沢山あります。解約やサーバの引越しは問題の先送りでしかありません。トラブルから学びを得て障害に強い環境を作っていきたいものです。


2018.07.07 (Sat)

本日で会社設立から丸12年です。

早いもので干支が一周まわってしまいました。自分で言うのもなんですが、金なしコネなし実績なしの無い無い尽くしで始めたのによく続いてるなと思います。これまで弊社に関わってきて下さった皆様、今まさに関わって下さっている皆様あってこそです。改めてお礼申し上げます。ありがとうございます。

 

12年目の成果

12年目に掲げてたやりたいことはできました。以下は、昨年11周年の時に書いてたことですが

  1. B2B iOS 事業 MICSS の強化
  2. Webの静的化サービス espar の強化
  3. 新しい労使のあり方の模索や発信

1.の件はありがたいことに、新規を含めてB2BなiOSアプリ関連で色々とお手伝いさせて頂いております。注目のアプリ事例ということでMacFanにも載せて頂きました。エンタープライズ系のiOS導入/運用に関する知見は国内一の自信がありますので宜しければ御相談下さい。

20180707_globalagents
(MacFan 2018年7月号に掲載。iPod touch がチェックイン時に渡されるホテルでアプリ開発/運用の御支援)

2.のWeb静的化をするespar事業も、実績が少しずつ積み上がっていってます。

サイトのスピードが60倍になってPV増、売上増、DDoS攻撃にも耐えた、なんて具体的な成果もあったりで静的化というアプローチが間違っていないことの手応えを感じています。今、幾つかの事例インタビューをさせて頂いてまして、具体的な実績は徐々にOPENにしていく予定です。

20180707_esparpremium
(KUSANAGIの移行、静的化、冗長化、監視、バックアップ、開発環境用意などをフルセットで御提供できるようになった)

3.の働き方発信については、やはりリモートワークメインへの切り替えでしょう。素晴らしく機能しています。リモート率は60-70%ぐらい。リモートワークに関連して、Oculus Go で社内mtgするって新しい取り組みもはじめました。今は会社から会議用デバイスとして支給しています。

20180707_oculus.jpg
(リモート時の会議用に買った Oculus Go の動作検証中の図)

 

13年目に取り組みたいこと

アウトプットは今後も続けますが、新しいこともやりたいと思ってます。特にセミナーですね。

先日、自社の会議室のレイアウトを変えてみたら、ちょっとした小規模なセミナールームになることに気がついたんです。机ありなら4,5人。机なくせば10人強は余裕でいけます。

20180707_seminarroom
(案外スペースを無駄に使っていたのだなと反省)

壁にプロジェクターで120インチ相当ぐらいの投影ができそうですし、ネットワークもあるし、環境は問題なし。ちょっとしたハンズオンセミナー、座学ベースのセミナー、動画の鑑賞会とか、座談会、ゲーム大会とか、まぁ色々できそうだなと。

何より自社スペースなので、相談や打診の必要なく完全に自分たちのペースで開催できます。実験的な試みもや、少人数と割り切るからこそできることなど可能性が広がるってもんです。

で、早速手始めに、弊社のespar事業に絡んで、Web制作関係者様向けの少人数ハンズオンセミナーを無償でやってみようと思ってます。Webサイトを支える技術で普段曖昧にしてしまっている事が正しく理解できます!みたいな。

怖くないDNS、証明書の正しい選び方、公開鍵認証、FTPはなぜだめか、悪いPHPテーマとは、落ちないサイトの作り方、負荷分散、監視、CDN、静的化、リバースプロキシ…。

なぜこれをやろうと思ったかは、書くと長くなるのでまた別エントリで改めて書こうと思います。

これも、自社でセミナーができると分かったから出てきたアイディアです。物理的な空間があるってのは案外良いかも知れない。できることの幅がグンッと広がりました。13年度は遊んでいるmtgスペースを有効活用していきたいと思います。

 

そんな訳で、13年目突入です。今後ともフィードテイラーをどうぞ宜しくお願い致します。


2018.06.27 (Wed)

上場企業オフィシャルサイトにおける常時SSL化対応状況レポートの6月版をお届けまします。調査条件は以下の通りです。

  • 東京証券取引所が公開する2018年5月末時点の上場銘柄一覧から全上場企業3620社を抽出
  • 2018年6月25日時点での全企業Webサイトで常時SSL化してるかどうかを判断

条件含めて、レポートの詳細はこちらをご覧下さい。

20180627_aosslreport201806

少しずつ青色領域が増えていますので良い傾向です。今回、対応サイトは 1.6%増 となりました。ここ3ヶ月は毎月約50,60社ずつ増えていってますので、恐らく来月には2000社達成となるでしょう。

 

自治体の常時SSL化対応状況の調査

常時SSL化調査のレポートをきっかけに今月は少し動きがありました。

一般財団法人日本情報経済社会推進協会(JIPDEC)さんから地方自治体のSSL/TLSサーバ証明書利用状況の調査結果を公表しましたというプレスリリースが出ています。

一般財団法人日本情報経済社会推進協会(所在地:東京都港区、会長:杉山 秀二、以下: JIPDEC)は、株式会社フィードテイラー(所在地:大阪府大阪市、代表者:大石 裕一、以下:フィードテイラー社)との共同調査により、全国の自治体サイト(都道府県と市区町村を合わせた全1,788団体)における常時SSL/TLS(以下、「常時SSL」)化の状況を調査したので、結果を発表します。

と書かれている通り共同調査です。他社様のプレスに自社がのるのは久しぶり。

20180627_jipdecpress

昨年11月からやってる常時SSL化レポートをご覧頂いた先方様から連絡がありまして、先方の持ってる自治体URLの一覧で同様に調べてみましょうって事になりました。何ごともアウトプットすべきですね。何に繋がるか分からないものです。

それなりに反応もあったようで、ZDNetさんにも自治体サイトの「常時SSL化」率、トップは愛媛県というタイトルで取り上げられています。

20180627_zdnet

面白いのは都道府県別の対応状況。愛媛県が1位なのは、恐らく、県内で自治体サイトを担当してる制作会社様の意識が高いからではないか…との推測だそうですよ。

だとしたら、証明書関係者はやっぱり制作会社様を啓蒙するっていう活動に注力しなくちゃいけないってことなんでしょうね。弊社も何かやっていきたいと思います。レポートを出し続けるのも活動の一環なので来月もまたレポート致します。


2018.06.19 (Tue)

(所要時間:約4〜5分)

6/18の地震発生時、僕は大阪市北区のオフィスに、奥さんは同じ区内の自宅に、従業員もまだ自宅にいました。幸いオフィス内では本棚に置いてるiPadの空箱が落ちたぐらいでした。

20180619_eq_ft

停電もなく社内サーバ含むインフラはびくともせず被害は皆無。揺れが落ち着いて真っ先に、LINEで家族の安否を確認、更にslackで従業員の安否確認を行いました。

 

有事の際のオフィシャル情報

無事が確認できて安堵。次は、next action を行う為に必要な情報収集です。幸い、オフィスのiMacの前だったのでググって検索しました。

早々に直面した問題が、一部のサイトはトラブっててほぼ使いものにならなかったってこと。サイトが激重状態ならまだしも 503 エラーでサイトが落ちてるサイトもあり、情報を得られないもどかしさに当事者として大変困惑しました。緊急時にこそオフィシャルの情報が必要なのに…と。

行政、鉄道、バス、ガス、電気、水道、消防、

有事の際は、様々な種類のオフィシャル情報が欲しくなります。しかし、肝心のWebサイトが不調な所がちょいちょいありました。僕は仕方なく、Twitterの断片的情報を元に判断。(大阪メトロがもう復旧したという嘘の情報もありました)

結局、このあと臨時休業に切り替え、更に今週はリモートワークのみとすることを決めました。3月から働き方をリモート主体に切り替えていたのも奏功し、業務の停止は基本的にありません。

それはともかく、やはり有事にオフィシャル情報をサイトから得られない・得にくい状況はなんとかして欲しいと思います。以下に紹介するのは、当日10時〜11時頃の行政・インフラ系サイトの状態。地震発生から約2,3時間後の記録です。開発者向けツール等で詳細を見ましたが、改善できそうなポイントは各社それぞれですが幾つか見えました。

大阪市

直後から 軽量版 なるページに切り替わっていて、対応が素晴らしかった大阪市のサイト。

20180619_eq_osakacity1
(地震直後の大阪市サイトの軽量版。TOPにアクセスしようとするとこちらに誘導される)

しかし「軽量」とはいえ、体感で普通に遅かったです。5秒とか。10秒とか。

何が原因かと Chrome の Developer Tools を使って見たところ、htmlの生成に3,4秒を要してしまっていました。「このページくれ!」とサーバに伝わってから「あいよ!」とページを返してくれるまでの時間(専門用語でTTFBと言います。参考)に、3,4秒は待たせてるってことですね。

正直、Webの世界ではだいぶ遅いです。サクサク感とはほど遠い。

軽量版と言うぐらいだから、静的ページ(htmlファイル直置き)なのかな?とも思いましたが、TTFBに3,4秒を要するのは明らかにおかしい。静的ページなら普通は100〜500ミリ秒とかで余裕で返ってきますから。

大阪市は平成28年に新たなCMSを使ってサイトリニューアルをしていて、恐らく当該のCMSで転送容量が小さくなるページを用意、CMSサーバが頑張っていたのだとは思います。それか、静的な配信だけどサーバの設定がおかしいか…ですね。

軽量版という発想は素晴らしいと思いますが、転送容量が小さいだけでは負荷対策として不十分です。有事の時こそ最低でもTTFBは100ミリ秒以下であって欲しい。ページ全体でも1,2秒で返して欲しいところです。市のサイトは消防や水道のページも内包してますから尚更ですね。ですから、サイトの静的化を検討するか、既にしているなら明らかに遅いのでサーバの設定等を見直すべきだと思いました。

大阪メトロ

時間も時間だっただけに多くの人が殺到したであろうサイト。

20180619_eq_osakametro1
(画像の取得に失敗してメニュー部分がロゴしか出ていない)

ページのhtml取得に20秒近くかかってました。こちらは大阪市のTTFBが長いのとは違い、接続すらままならない状況。Initial Connetion(画面下部のバーのオレンジ色部分)の値が大きく、接続確立にまず時間がかかっていました。

大阪メトロのサイトは、サーバからネットに抜ける上流回線に余りお金をかけてなさそうに見えます。今回の事態を教訓に是非とも回線/帯域をしっかり検討して貰いたいと思いました。だいぶ改善される筈ですから。

同じことを思ってたようで、さくらインターネットの田中社長が地震直後にこんなtweetをしてました。

だそうなので、さくらのクラウドにサーバを設置してネットワークは回線太めの契約をされると良いかと。国内で有事のトラフィックに加えお金も気になる場合、さくらさんは良いチョイスだと思います。弊社も使わせて貰ってますが、従量課金のAWSとは安心感の次元が違います。

ちなみに他の大阪府内主要私鉄、阪急阪神近鉄南海京阪の各サイトはいずれもビクともしてませんでした。至って平常運転、さすがです。

大阪メトロはこの4月に民営化されたばかりってのもあり、webサイトへの投資はまだまだこれからなのかも知れません。Web関連に投資する時は、まず上流回線の見直しをお願いします。

大阪ガス

ほぼほぼガスが停止されていたこともあり、メトロ以上のアクセスが長時間続いた可能性もあります。想像以上のアクセスにCMSサーバが耐えられなくなったのか、

20180619_eq_osakagas1

このようにダウンしちゃってました。ただ、リロードしたら表示されて、また上図のエラー画面に戻って…と特徴的な表示切り替えも発生してました。表示された瞬間はこんな感じで。

20180619_eq_osakagas2
(表示されることもあったが、CSSが読めずに崩れてしまっていた。この表示でさえ数十秒かかっていた)

見えたり見えなかったり。恐らく複数台でロードバランスして運用しているうちの1台が死んでいるような状況だったのでしょう。

ロードバランスして複数台CMS運用するぐらいなら、アクセス集中しやすいページだけを静的化してロードバランスしたフロントに配備、それ以外をバックに控えたCMSにプロキシするってのが良いでしょうね。きちんと構成すれば、ある程度の攻撃対策にもなるので一石二鳥です。

関西電力

恐らく問題ないだろうと思いながら確認したのが、関西電力のページ。

20180619_eq_kanden

ちょっとしたご縁で、関電のサイトが少し前から(?) 静的化 に特徴を持つ専用CMSを導入しているのは知っていました(かなり高いですが…)。導入事例として公開もされてます。

弊社もWebサイトは静的化推進派で、実際、静的化による爆速化と負荷対策をさせて貰ってますので静的化の効果を日々実感してる立場です。だから、同じ静的化という意味で、関西電力のサイトは相当アクセスがあっても(一時17万戸が停電していた)、絶対に落ちてないし遅くもなってないと確信してました。

案の定、ビクともしておらずTTFBは常に数十ミリ秒の高水準。今回、電気関係のオフィシャル情報を求めてサイト閲覧で困った人は皆無だった筈です。当事者であった僕もその一人。

 

20180619_eq_public

止まってはいけないWebサイト

今回、当事者となって改めて感じましたが、公的インフラを支える企業のサイトは、有事の時こそ止まってはいけないWebサイトなのだと思います。

この業界で仕事をさせて貰ってるので、止めないことが如何に難しいかは重々承知の上です。それを承知の上で…ですが、やっぱり止めてはいけないです。遅くなってもいけません。そして万が一、そのような状態になってもすぐに復旧できるようにしておくべきです。

なぜなら、有事にオフィシャルな情報を最短で得られれば、地域住民の安心感は少なからず高まるし、人々の行動は最短で最適化されるからです。それが、本当に困った人向けに公的リソースが配分されることにも繋がる筈です。

弊社は最近、Webサイトの高速化・負荷分散・可用性確保という課題に、静的化という切り口でお応えする事業をしているだけに、今回の体験は非常に考えさせられました。

国内の地震は活動期に入っている、誰もがそう思ってます。全国例外なく今回の大阪と全く同じ状況になりえます。例外はありません。

したがって、全国の都道府県市区町村や、各地域のインフラを支える企業におかれましては、「地域住民のため」を言うのであれば、Webサイトの静的化と上流回線見直しを検討し、止まらないサイト作りを目指されることを強く推奨します。一人一台スマホ時代。有事にWebサイトへ膨大なアクセスが集中しない訳がないからです。できれば物理的な位置でも冗長化をする Disaster Recovery も検討されると良いのではないかと思います。

 

大阪では、特定の地域に限られるものの依然として地震の影響が残っています。被害にあわれた皆さまにお悔やみ・お見舞いを申し上げます。生活インフラの復旧に身骨を砕かれる関係者の皆さまに感謝すると共に、未復旧地域の一刻も早い回復を願う次第です。また、一個人として一事業主として、何ができるだろうかと考え続け行動に移していきたいと思っています。


2018.06.04 (Mon)

(所要時間 : 約2〜3分)

3月から初めているリモートワーク主体へのスイッチ。比率を少しずつ上げて試しています。5月は稼働日に対する リモート比率が57% まで上がりました。ついに半分超えです。ビジネスのスピードも全く落ちておらず、業務上何も問題は起こっていません。

リモート主体にするぞと宣言してから3ヶ月程度でリモート成分を急速に上げましたが、ここからは少し速度を落として調整フェーズに入ります。この水準(5-6割程度のリモート率)なら確実に業務は回せる自信はあるので、リモート5割前後を前提に会社のあり方も再考していきたいなと。

そこで、オフィスです。

 

20180604_remotework
(Thanks! the photo on flickr by Joe Flood / CC BY-NC-ND 2.0)

完全専有型オフィスにお金をかける価値

弊社はそんなに広くないですが、最寄り駅が大阪の中心地「梅田」から1駅の南森町で、駅から徒歩1,2分の好立地、設備も良い。光熱費込みでだいたい月に15万円前後を支払ってます。(冬は暖房費で20万弱)

ついつい忘れがちになりますが、会社経営、特にソフトウェア開発の会社経営においては、オフィス維持費が人件費に次ぐ高額なキャッシュアウトなんですよね。オフィスを動かすのは大層過ぎるぐらい大層だし、オフィスは事業拡大と共に大きくするモノなので目が向きにくい。

が、もはやリモートワーク主体となり、オフィスを実質半分しか使ってなくても生み出す価値に影響がないとなれば、そのキャッシュアウトの価値を問うても良いでしょう。

ちなみに最も大きな固定費である人件費は、創業以来ずっと「いかに上げていくか」しか考えておらず、実際ほぼ例外なくそうしてきてます。そこは上げる方向にしか思考が働きません。

で、問題のオフィス維持費です。平均して月15万円も支払う価値が果たしてあるのか?…使用率が50%程度でも問題ないのなら適正とは言えません。再考の余地があるなと思う訳です。そもそも、どんなオフィスが望ましいのか。

 

20180604_espressomachine
(Thanks! the photo on flickr by Daniel Andrade / CC BY-NC-ND 2.0)

シェアオフィス型 + テナント型 + α ?

通常、オフィスとは24時間365日自由に使える完全専有型です。通常閉じた空間で、内装は自由。各種オフィス設備は各社が買うかリースしてハコの中で用意する。

一方シェアオフィス型は、企業間の交流を促進するようなフリースペーススタイル、プリンタ等の共用設備はシェアという組み合わせ。

この中間が欲しいと思いました。

シェアオフィスにプレミアムなプランがある場合もあります。共用設備は自由に使えてフリースペースも使用可、それに加えて専有のハコを借してくれるタイプ。でもそれも結局、ハコは24時365日専有なのですよね。この専有部分を例えば、月・木だけはフィードテイラーさん専有で、ということができて欲しい。

部屋に常設されてるのは、幾つかの机と椅子、あと27inchディスプレイが1卓あたり2台ずつ、壁は全面ホワイトボード。MacBookを持ち込む前提で毎日持ち帰り。部屋内設備は以上。それ以外の設備は共用。企業専用の鍵付きラックはオプションで契約可能。

こんな感じ。

弊社は月・木だけオフィスとして使わせて貰うと。出社日に部屋に集まり終日仕事をする。それ以外の曜日は別の会社が使うのでリモートワーク。自宅でもカフェでも、共有のフリースペースでもいい。部屋に機密情報を残さないのは入居企業の責任、物理的にオフィスに保管が必要なものは別途契約する鍵付きラックの中に入れておく。

こういうオフィスって無いものでしょうかね。部屋を準占有させて貰うような契約が可能な物件。で、専有率で費用が変わってくるようなイメージです。週2の準占有で今より費用安いなら凄く良い。

 


(Thanks! the photo on flickr by David Martyn Hunt / CC BY 2.0)

僕が知らないだけかもですが、こういうオフィス向け物件は見たことがありません。責任の所在がややこしい、法律的に難しいという理由があるのかもですが、恐らく不動産オーナーが儲からない・面倒臭いってのが一番大きいのかも知れませんね。借り手に都合良すぎますから(笑)

冒頭の通りリモート率が恒常的に5割でも受託系・自社開発系ともに回せることが実証できたので、5割使用率にしかならないモノに満額のお金をかけるぐらいなら、その分で福利厚生を充実させたり、仕事で使うクラウドサービスを増やして更にリモート率を高めるとか、のほうが費用対効果が高いと思うのです。

とはいえ、完全にオフィスが不要って訳ではない。そこがまぁ難しいところなんですけどね…。

リモート主体での会社のあり方の再考、まだまだ続きます。


2018.06.03 (Sun)

(所要時間 : 約4〜5分)

ケーブルもいらない、パソコンもスマフォもいらない、ただかぶるだけでVRの世界にダイヴできる というスタンドアロンVR、今年はその元年だそうです。元々、スタンドアロン型が出てこないとVRは浸透しないと思っていたので、これまで手を出さずにいました。

ご承知の通り今年の5月、満を持してOculus GoMirage Soloが登場。まずは研究してみようと両方を即発注。5月中頃には両方とも手にしてました。

OculusGo
(この2つだけでVRの世界に入れる。他は何もいらない)

数日使ってみた感想は、OculusGoのコストパフォーマンスは半端ない。没入感は十分。かぶるだけでokという手軽さで確実にVRのハードルは下がる。エンタメ・ゲーム以外の活用例が増える筈…といったところ。

活用例、気になりますね。特にビジネス。

ちょうど弊社は3月から、原則出社ではなくリモート主体にしようと切り替えていってる最中でしたので、自ずから「VRをリモートワークで使う未来」に想像が膨らみました。そんな未来の片鱗に触れられるチャンスがあれば良いな〜と思ってたのですが…

スミヒロさんslack

そんな機会が訪れました!やりましょう、VRミーティング!

アプリ界隈では知らない人いないと思いますが、お相手は最速の人 @sumihiro さん。とある新規案件の相談で slack で会話している時に、Oculus Rooms を使ってみることになったのです。

Oculus Rooms とは、仮想空間の中で一緒に遊ぼう!がコンセプトの無料アプリ。仮想空間内の自分の部屋に友達を招待して、一緒にチェスしたり動画を観たりってことができます。これを使って、ガチに仕事の会議をしようじゃないかというわけ。

Oculus Room で仕事会議を体験した感想は…同じ場所にいる感が凄いということでした。

 

Oculus Rooms での会議の様子

Oculus Rooms アプリを立ち上げると、そこはタワーマンション高層階の一室。自分の部屋です。


(窓から見える外の景色や部屋の床の色などを設定で変えられる)

この部屋に @sumihiro さんを招待。facebookで友達になってる人を招待することができます。早速呼んでみましょう。ポチッと!

20180603_sumihiro-on-oculusroom
(自分のアバターは、髪型から肌の色から身につけるものまで相当な組み合わせから自由に作れる)

声が先に繋がって、そのすぐあとに @sumihiro さん登場!

「こんちは〜って、髪の毛、赤っ!(笑」
「ご無沙汰してま〜す。わははは、そなんです(笑」

と、和やかに始まった会議。リビングルーム内のアーチ状のソファーに2人で腰掛けて、見晴らしの良い景色を見ながらという構図になります。あぁ、何と優雅なミーティングでしょう。

音声の品質は全く問題なく、タイムラグも感じず、音については普通のビデオ会議と何ら変わりありません。申し分ない。ですが、決定的に異なるのが、異様なまでの同じ場所にいる感。声も相手のいる方向から聞こえますしね。

ありえない景色とありえない相手の出で立ちなんですが、違和感を感じません。これが不思議と会話を弾ませます。これほどまでに話がし易いとは。


(僕が相槌をうったり頬杖をついたりする動きに連動しているので、録画動画として見ると少し見にくい)

既存のビデオ会議は、「雑談がやりにくい」「ディスカッションしにくい」という欠点があります。きっとそれは空間を共有してないからです。異なる空間(例えば会社と社員の自宅)を繋げただけですから。

Oculus Rooms は違います。「繋ぐ」のではなく「集う」のですよね。お互いそれぞれの現実世界から離れて、仮想空間に集まって話をします。仮想空間でって論する。そう、文字通り会議なんですよね。会って議論することが会議なら、Oculus Rooms のユーザ体験(UX)はより会議に近いと僕は感じました。

従来のビデオ会議より話がし易いと思ったのは僕だけじゃなかったようで、@sumihiro さんもほぼ同じ感想だったのか、直後にこんなtweetをしてました。

おそらくこれは体験しないと分からない感覚かも知れません。仕事会議をガチでやってみた感想を端的に書くと、

  • 仕事会議でも普通に使える
  • 驚くほど会話がし易い

ということです。会議の議題と目的が明確で、言葉を交わすことが重要な会議なら Oculus Rooms は取りうる選択肢だと思います。共にそこにいる感が会話を弾ませますから。同じ会話をするのなら、弾む環境のほうが良いですよね。

 

Oculus Rooms での会議の様子(現実世界)

仮想世界に入って仕事会議している様子を事務所にいた @ikunee に撮って貰いました。

没入感が高いシステムですから、一度入ってしまえば、そこはもう、来社して貰った自社の会議室か、訪問させて貰った相手方の会議室なんですよね。入ってる当事者的には。ただ現実はこう。

20180603_vrmeeting-real3
(MacBookは Oculus Rooms に入る前にメモを見ていたため。仮想世界からMacBookの画面が見えている訳ではない)

リアル世界で非常に滑稽な姿になっていることに気づくこともなく、仕事の会話に没頭することができます。というかここは自社の会議スペースであったということすら忘れてたぐらい没入してました。


(右手側に実際に相手がいるかのように真剣に仕事の話。が、現実世界には誰もいない)

普通に会議室で相手と仕事の会議をしているのと全く変わらない感覚なんですよね。周りが殺伐とした白い壁なのか、高層マンションの一室なのかの違いがあるだけ。

ただ、一つ忘れてならない点があります。それは @sumihiro さんとは現実世界で既に7,8年の付き合いがあるってこと。そもそも元弊社のエンジニアでもありますから、お互いの仕事のやり方も分かってるんですよね。既にある信頼関係が重要な要素だったのは間違いありません。

Oculus Go + Oculus Rooms が優れたユーザ体験を提供してくれていることは間違いないですが、それだけでは多分お互いこういう感想にならなかっただろうなと。

全く会ったこともない人と Oculus Rooms で仕事の話ができるか…というと、それはちょっとまだ疑問符がつきます。リアル世界でまず会ってからにしたい。現実世界で実際に会っている経験はやはり大きいと今はまだ感じます。

ただ、Oculus が出てたった5年程度でここまできてるので、5年後は分かりません。従業員やパートナーの顔も見たことないまま仕事が進んでる…そんな世界は100%来ないとは誰も言えないでしょう。

 

20180603_oculusrooms-initiallinvingroom

Oculus Rooms で仕事会議をするメリット・デメリット

せっかくなので箇条書きでまとめます。勢いで書いているので漏れがあるかもですが、Oculus Go + Oculus Rooms を使ったリモート会議をやってみて思ったことです。

メリット
  1. 空間を共有している感覚があって話がし易い
  2. リアル世界の場所や自分の服装を気にしなくて良い
  3. 思いたったらすぐに会議ができる(これはビデオ会議も一緒)
デメリット
  1. 印刷物や造形物などリアルな手触り感が必要な議論は難しい
  2. ホワイトボードやプロジェクターなどの会議アイテムが使えない
  3. テキスト活用ができない(メモを書く、チャットでメッセージを送信)

メリットばかりなわけもなく、表の通りデメリットも沢山あります。が、これらは時間がある程度解決してくれそうな気がしますよね。

2の会議定番アイテムはアプリがあれば良いだけですし、業務の種類によってはブラウザアプリだけで解決することも多いでしょう。スクリーン共有もできるとベターですが、その実現に技術的な問題は余り感じません。

3はコントローラーが何らかの進化をしたり既存のペン型デバイスか何かが連動する仕組みがあっても良いかもですね。(参考 : 完成度の高いVR用スタイラス「Drawboard Pen」発表 | VR Inside, 「VR空間でデザイン」をワコムが提案 試作機でデモを披露)

今のところ、Oculus Rooms を仕事会議で使えるシーンは、議題と目的が明確で議論することが主旨である会議でしょうね…。でもよくよく考えると、課題と目的が明確でなく、且つ議論が主ではない会議ってそもそも現実世界でもやる意味あるのか?って話ですが(笑)

 

リモートワークVR、体験してみませんか?

なんと滑稽な…そんな会議があってたまるか…という意見もあるでしょう。パッと見のアバターの様相は「いかにも」でビジネスビジネスはしていませんし。

20180603_oculusrooms-temporallyoffline
(会議中に家のインターフォンが鳴って、一時的に現実世界に戻っている @sumihiro さん。アバターがグレーアウトしている)

でも、ここはひとつ疑いの目で見るのではなく、まずは多くの人に Oculus Go + Oculus Rooms を体験して貰いたいなと思いました。そこにいる感が圧倒的に違いますから。できれば仕事の会議で体験して欲しい。

各社の色んな体験とその共有が、未来の働き方を醸成していくのだと思います。新しいアプリが生まれ上述のデメリットが次々と解消されていったりもするかも知れませんね。リモートワークでVRを活用するのが珍しい事ではない未来も考えられます。

そんな訳で弊社はこれを機会に、リモートワークVRに積極的に取り組んでいきたいと思います。そこで得た課題や気づきを共有できればなと。

あ、ちなみに。VRを事業にするつもりはありません。既に専門家が沢山いらっしゃいますので。弊社にとってスタンドアロンVRは、あくまでリモートを主体とした新しい働き方を実現する為のツールです。

 

以上、Oculus Go + Oculus Rooms を仕事で使った体験記でした。弊社とお仕事ご一緒させて頂いてる方で、Oculus Go をお持ちの方、一度ガチで仕事VR会議いかがですか? :-)