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会議いかがですか? :-)


2018.05.24 (Thu)

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

毎月恒例の上場企業の常時SSL化対応レポート2018年5月版をお送りします。今回で6回目。早いものでもう半年続けていることになります。継続は力なりなのか、レポートを見ましたよ〜と問い合わせを頂く事もあって、今後常時SSL化関連で新しいことを始めれそうな予感です。

例によって調査の内容は以下の通り。

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

というルールです。上場会社は毎月増えていってます。調査日が少しブレるのは弊社都合ですが、いずれ完全自動化して毎月3営業日目とかにする予定です。

さて、前回はめでたく常時SSL化対応が50%を越えましたが、今回はどれぐらい増えたでしょうか。

20180522_sslreport201805.png

今月は上記の通り。先月から1.4ポイント増えています。先月の1.7ポイント増につぐ増加率で、なかなか良い感じです。あと、対応企業が1900社 を越えました。素晴らしい。是非この勢いが収まることなく、いやむしろ加速する勢いで!、各社様におかれましては進めて頂きたいと思います。

次のマイルストーンは2000社越えですかね。あと95社なので2,3ヶ月後ぐらいには達成でしょう。

 

崖っぷちに追い詰められる前に

ネット界隈をwatchしてますと、常時SSL化のニュースを見ることが増えてきました。時間ないですからね、もうホントに。

かねてより2018年7月から、ブラウザシェア3,4割を占める Chrome では、常時SSL化対応していなければ「Not Secure」と表示されるようになるとしていましあが、更に2018年10月のChrome70では、「Not Secure」が赤色表示になることも明らかになっています。

20180525_httpinput
(Marking HTTP As Non-Secureより引用)

パスワード欄とかに限らず、chromeで http ページの入力欄に何かを入力すると、問答無用に赤色で Not Secure と表示されるようになります。日本語だと赤色で 保護されていない通信 です。

20180525_chromenotsecure

こんな感じ。入力欄であれば全部該当しますので、特にTOPページに検索窓を置いているサイトは早々に常時SSL化したほうが良いですね。もっと見たいなぁと思ってキーワード入力した閲覧者に、ウチは不信なサイトですと言っちゃうようなものですから。

そしていずれ、httpサイトであれば無条件に上図のような表示になるそうです。詳しい計画はこちらのリンク先をご覧頂ければと。

 

という訳で常時SSL化の5月度レポートでした。また来月もレポート致します。


2018.05.06 (Sun)

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

先日のエントリでリモートワーク主体に切り替えることついて書きました。4月は取り組みを更に加速させ、21営業日中の10日をリモート日としました。47%なのでほぼ半分のリモート率です。

変化が急過ぎるかなと思いましたが、やってみると全然問題なく仕事はまわってます。むしろまだリモート率上げられるなという感じなので近々逆転させる予定。思ったより速くリモート主体に移行できそうです。

20180507_remotework.jpg
(Thanks! the photo on flickr by Citrix Online / CC BY-NC-ND 2.0)

特別な準備もなくリモート主体に転換できてる訳ですが、要(かなめ)になってるのはチケット管理(タスク管理)を徹底してることにあると感じてます。チケット管理しっかりできてるな〜という実感がある会社は、すぐにでもリモートメインに切り替えれるんじゃないでしょうか。

今回は、急なリモート主体への切り替えに耐えれている、弊社のチケット管理について少し書いてみようと思います。主に、マネジメント側の不安についてです。

 

弊社のチケット管理

チケット管理、タスク管理、TODO管理、バグ管理….色々と呼び方はありますが、やらなくちゃいけないことを管理するシステムは、自分が雇われエンジニアだった時から結構触ってきました。

  • Bugzilla
  • Excel
  • 影舞
  • Google Spread Sheet
  • Redmine
  • Backlog
  • Trac
  • Trello
  • JIRA
  • GitHub Issue

懐かしいものもちらほらありますね。弊社のチケット管理の歴史はシンプルで、

時期 ツール 適用範囲
2006年〜2010年 Trac 社内案件
2010年〜 Redmine 社内案件
2011年〜 Backlog 社外パートナーが絡む案件

って感じです。10年以上前からチケット管理をやってますので、結構早い頃から社内タスクの見える化ができてたのではないかなと。

今でもまだ運用の仕方に洗練の余地がありますが、チケット管理の徹底が、リモートワークあるあるの「誰が何をやってるか分からない」というマネジメント側の不安を解消しているなと感じてます。

マネジメント側と言っても弊社の規模だと社長である僕だけですが(笑)、まぁ不安は皆無と言って良いです。信頼関係もありますが、チケットに情報が集約されてることが不安の解消に寄与しているのは間違いありません。

20180507_ticketmanagement.jpg
(Thanks! the photo on flickr by Pete Tschudy / CC BY-NC-ND 2.0)

全ての仕事はチケットに紐付く

弊社内でのチケット管理ルールは、

  • 業務時間中の作業が常にチケットに紐付いていること
  • チケットに記録をできるだけ細かく残すこと

の2点。一日の終わりに「◯◯さん、今日は何をして、その状況はどんな感じ?」と尋ねた時に、◯◯番のチケットです。というやりとりだけで基本済むようになってます。チケットに紐付かない仕事はありません。(社外の方とやりとりするBacklogはここまで…ではありません)

実際、弊社では一日の終わりに slack で日報投稿するようにしてますが、だいたいこんな感じになります。

20180507_slack.png

f#XXXXXと書いてる番号がチケット番号。自動的に対応するURLを投稿するhubotが稼働してますので、チケット詳細がワンクリックですぐ見れるようになってます。

slackで一日単位のタスクの動きが把握できるほか、プロジェクト全体のフィードを見てれば、

20180507_vienna.png
(モザイクでほとんど何書いてるか分かりませんが…笑)

誰がどのタスクを終えたのか、日中でもどんどん情報が集まってくるようになっています。ってチケット管理に慣れてる方なら当たり前だと思いますので、どちらかというとチケットの種類や中身のほうに特徴があるかもです。

 

チケットに時系列の記録を細かく残す

弊社がTrelloやカンバン方式をメインにしない理由でもあるんですが、時間軸の記録を結構大事にしてます。時系列に、何した、あれした、どうなった…と結構細かくチケットに書くんですね。

ちょっと極端な例ですが、一例をあげるとこんな感じ。「KUSANAGI for さくらVPSへの移行」というWordPress環境の引越し作業のタスクです。

20180507_redmineticket17218

だいぶ長いですね。印刷するとA4で10ページぐらいになります。

Redmineをご存じの方は見慣れた画面ですが、最上部の黄色いところがタスクの内容、その後に時系列コメントが並びます。移行作業で、サーバで何をしたのか、設定ファイルをどう変えたのか、パフォーマンスはどうなったか等など、ガンガン書いていきます。

会社によっては「もっとチケットを分割すべきだ」となりますが、このタスクについては最小粒度です。「公開鍵を置く」「NGiNXを設定する」「KUSANAGIのプロビジョンを設定する」「MariaDBの設定をする」「DBにdumpをimportする」てな感じまで分割するのかって話なので、そこまでは必要なかろうと。

ま、そのへんは臨機応変に僕がチケット分けて〜と言ったり僕が分けちゃう場合もあります。あと、設定情報等は別途wikiに転記して整理するとか、gitのコミットが連動しているとか、+αな連携もさせてます。

他には、こんなチケットもありますね。「◎◎様に提案する為の Dropbox Business Advanced についての調査」という題目。これはちょっと短め。

20180507_redmineticket17233.png

商流をどうするか、販社はどこを使うか、パートナー制度の調査情報などガンガン書きます。これは僕が担当したタスク。コメントは5,6個ですかね。

この種の情報は、ひょっとしたらSFA(営業支援)やCRM(顧客管理)の範疇かも知れません。が、弊社では、何らかのタスクであって時系列つまり事の経過が重要なものは全部 Redmine や Backlog に集約してます。情報は一つのシステムに集約されてる方が良いですから。

ここまで書くのはちょっと…という方もいます。正直面倒かも知れません。でも、会社の生産性って突き詰めると、情報共有のスピードや共通認識の形成スピードなので、生産性を求める僕的には譲れないところなんですよね。そうじゃないと残業ゼロを促進できません。

だから、なるべく多くの情報を非同期的に共有できるよう、チケット管理システムを使ってガンガン書くことを是としています。あ、別にチケットの更新頻度が査定に関係する…みたいなことはしてないです。

一見面倒に見えるんですけど、社内で「共有」とか「報告」の名の下に開かれる会議や書類作成の無駄に比べたら楽なもんです。エンジニア的には、コマンドやその標準出力、設定ファイルの一部をコピペして見解を書く、とか、gitのリポジトリのコミットログが連動しててそれだけで済む場合もありますから。

20180507_collect.jpg
(Thanks! the photo on flickr by kiwamuk / CC CC-BY 2.0)

チケットに記録が集約されることのメリット

既に前述してるものもありますが、

  1. 報告のための会議や書類作成に要する無駄な時間を無くせる
  2. 過去を遡れるので、有事の時の思い起こしコストが最小化できる
  3. 誰が何をやっていてどこまで進捗しているか具体的に分かるので管理側は安心できる

あたりでしょうか。

チケットに書く記録の粒度は人にもよりますし、一挙手一投足を捉えられる訳ではない(それはそもそも必要ない)ので、情報共有具合が常に100%って訳じゃないです。体感でせいぜい90%ぐらいでしょうか。

だから不足分は必要に応じて顔を合わせた会話で補います。その場合でも、関係者がチケットを事前確認して現状共有した状態で会議を始めますから、濃密かつ所要時間を最小化した会議運営ができる訳ですね。

記録を残す負荷が余りに高いと組織の生産性が落ちますが、適度に記録を残す癖は組織の生産性を確実に上げます。無駄を無くせるという意味で。

20180507_remotework2.jpg
(Thanks! the photo on flickr by Citrix Online / CC BY-NC-ND 2.0)

という訳で、チケット管理のついて書いてみました。冒頭の話に戻りますが、誰が何をやっていて今どういう状況なのかが分かるから、リモート主体にいきなり切り替えても何も困らなかったのでしょうね。

もちろん、弊社の場合は人数が極めて少ないってのも理由の一つです。でも、人数が少ないからと言って、誰が何をしてるか分からない、何をしたら良いのか分からない、という不安が無くなる訳ではありません。なので、人数や会社の規模はリモートワークを採用できない理由にはならないだろうなと今は思います。

チケット管理の徹底が、労使双方にとって不安の解消に寄与するのは間違いないです。リモート主体にするかどうかは別にして。何をすべきかチケットで把握でき、何をしているかがチケットで分かるからですね。チケット管理は奥が深いのでまた書いてみたいと思います。


2018.04.19 (Thu)

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

恒例となりました上場企業の常時SSL化対応状況調査レポート、5回目の調査となる2018年4月版をお届けします。調査は至ってシンプル。

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

というルールで統計を取ったものです。11日というのは単に弊社都合です。ホントは毎月決まった日が良いのですけどね。

さて、今回はなんと言っても!!!ででんっ。

20180419_sslratio201804.png
(遂に半分を超えた!)

上場会社の常時SSL化対応サイトが半数を超えたということでしょう。いぁ実にめでたい!

調査開始した2017年12月時点で4割台だった頃から考えると、上場企業様や制作会社様の意識も向上してきてるのだと思います。常時SSL化推進派としては純粋に嬉しい結果です。願わくば数年のうちに対応サイトが100%になりますように。上場企業なのですから、情報発信側として身元ぐらい明らかにして貰いたいものです。

レポートでは例によって、業種ごと(17分類/33分類)や、証明書の種類ごとに統計を細かく取っていますので、詳しいことはレポートページをご覧下さい。過去分も見れます。

 

20180419_browser.jpg
(Thanks! the photo on flickr by Dennis Skley / CC BY-ND 2.0)

さて、あと3ヶ月もすればChrome68の配布が始まって、ChromeでHTTPサイトを表示すると即座に注意喚起がされるようになります。こんな感じ。

20180419_warning.png
(HTTPサイトは表示するだけで、このような表示になる)

そのことを知ってか知らずか、はたまた知ってるが無視しているのか、諸事情で対応できないのか…。7月にどれぐらいの上場企業が重い腰を上げるかが気になりますね。

どうせ対応しなくちゃならないので早いほうが良いです。既存サイトの常時SSL化はホント大変ですし。

 

もし常時SSL化でお悩みのようでしたら、DNSを切り替えるだけで常時SSL化が済んでしまう弊社 espar がおすすめです。手前味噌ですが(笑) どんな選択肢よりも作業負荷が少なく且つスピーディに常時SSL化できることをお約束します。

どさくさ紛れて最後に宣伝でしたね。来月もまたレポート致します。


2018.04.05 (Thu)

最近、仕事の進め方が変わってきていて、ふと気が付きました。

案外リモートでもokじゃね?と。事務所に常にいる必要ある?と。

20180406_remotework

創業からリモートという選択肢は用意してましたが、あくまでオプションだったんです。エンジニア自身や家族の体調がすぐれない時とか、外出控えた方が良さげなインフルエンザ流行時とか自然災害とかの時ですね。

あくまでもメインは出勤、リモートはオプション

ずっとこの考えでした。でも今後、これを段階的に逆転させていこうと思います。メインはリモート、出社はオプションという就労体制に切替えていきたいなと。

リモートの適不適は人にもよるし仕事の内容やプロジェクトのフェーズにもよるので、集まることを完全に否定する訳ではありません。ただ改めてこの1,2年の自社を見てみると、集まることを前提にする意味が無いと思ったのです。小さい会社だからってのが大きいですけど。

 

図らずもリモートが増えたが困ってない

最近、取引先やパートナーさんとリアルに会わず仕事を進めることが増えました。出張も増えてるんですが、出先での社内とのやりとりは実質オフィスなしでリモートワークしているのと変わりません。

20180406_remotework_notebook

SlackやChatworkでチャット&ビデオ会話、RedmineやBacklogのチケット管理、gitでソース管理、VPNでセキュアな接続環境…。

仕事の進め方や就労環境の考え方が、元々リモート最適化されていたんだと思います。生産性を高めるにはどうしたら良いかという追求の結果たまたま…なんですけどね。例えばこの本、

フルリモート体制の37signalsのCEOの著書ですが、これを読んだ時も共感できたし自社でやってたことも幾つかありましたから、考え方もリモート主体を元々是とするところがあったのかも知れません。

ならば37signalsのように、あるいは国内先駆けのソニックガーデンさんや近年だとIncrementsさんのように、思い切って自社をリモートを主体とする会社に衣替えしてみようと思った次第です。

でも既に当たり前の企業さんにとっては当たり前のことだし、リモートワークという言葉はもう何年も前から言われているので、何も目新しさはないのですけどね。

まぁ世間的に目新しいかどうかはともかく、どうせやるならスピードが常に正義なので、3月中旬頃にリモート主体にしようと思い至ってすぐに行動しました。

 

20180406_pollen.jpg
(Thanks! the photo on flickr by ★Kumiko★ / CC BY-SA 2.0)

1. 花粉が酷い日でもリモートワーク

一つ目は出社しない日の設定。出張の日や外出メインで僕がオフィスにいない日(最近は結構多い)と、エンジニア本人の体調が悪い日を原則リモートワークとしました。

後者は7,8年前からそうだったのですが、リモートワークの特別感がなくなるよう僕から「リモートにする?」と提案するようにしました。その効果もあり「今日ちょっと花粉が大変なのでリモートでいいすか」「了解です」ってやりとりもあったりでハードル下げるのに成功してます。

3月中旬から2週間の間に既に4日(営業日ベースで3,4割)ほど実践してますが、生産性は落ちてないという印象。経営者の僕的にも、早速リモートワークを実践したエンジニアの @t0shiya 的にも同じ感覚です。まぁこれは労使相互の信頼感あってこそですけどね。

 

2. リモート前提で自社プロジェクトをおまかせ

もう一つは、自社プロジェクトで新しい取り組み。3月下旬から岩手県に在住の @mtane0412 さん (ブログ:ニートが東京に行った話) に平日、完全リモートでお仕事して頂いてます。

20180406_tanenobu.png
(週1回の頻度のビデオmtg。ご本人の許可を取ったうえでキャプチャ/掲載しています)

弊社では、常時SSL化上場企業対応状況レポートをやってるんですが、随分前から常時SSL化促進のためにもっとWebから情報発信をしたいと思っていたのですよね。esparという自社プロダクトの一環として。

自社のものは自社内で…が僕のポリシーなので、「Webデザイナーさん雇うしかないかなぁ、社内に席は1つ空いてるけど今雇うならエンジニアだよなぁ…」ってずっと悩んでたのです。で、たまたま@mtane0412リモート前提で仕事を探しておられることを知り、速連絡。お仕事をご依頼するに至ったという訳です。

@mtane0412 さんは、Geek Office Ebisu やベビログの板羽さんとの繋がりで知り合った方。ライティングの力やWebの知見、制作力、技術的センスなど、惹かれるものがあったのですよね。実績もお持ちでした。(サルでもわかる葬儀の新常識)

20180406_sougi.png
(制作されたサイトの例。クオリティも高く1年でPVも収益も稼ぐサイトに育ったそうです)

少しお話して、僕の「あらゆるサイトの常時SSL化を促進したい」という考えにも共感して貰えたので、今、特に期限を定めることなくアルバイト的な感じでお仕事をお願いしてます。

これは会社に出勤することを主としていたらできなかったことですね。リモートワークを主とすることで仲間を増やせるということなんだろうなと実感した例でもあります。

 

とまぁそんな訳で、リモートワークを主体に切り替えていこうと思います。冒頭でも書いた通り集まることを完全否定する訳ではなく、あくまで出社かリモートかの主副の入れ替えに過ぎません。適度なバランスが探れると良いなぁと思います。

弊社は、創業来10年以上エンジニアにとって幸せな働き方とは何かを追求してきました。そうやって生まれた変な制度や変な取り組みが沢山あります。

でも、集まる前提という思考の拘束が解けた今、制度や取り組みについてアイディアが色々出てきてます。労基法を改めて読み直したり、社労士にアレはokかコレはダメかと確認しまくってるのは自分らしいかもですね。リモートを主としたらできること。遅れ馳せながらですが、追求してみたいと思います。


2018.03.20 (Tue)

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

毎月恒例となりつつある(?)上場企業の常時SSL化対応状況レポート。

昨年より始めていて今回は4回目となる2018年3月版を公開致しました。微増ではありますが着実に増えてます。詳細なデータは こちら からどうぞ。

 

ようやく半数に迫る勢い

グラフで見るとよく分かるのですが、ようやく半数に迫るか…というところまできました。

20180316_sslreport201803
(やっと50%越えが見えてきた)

あと0.4ポイントですね。ホントあともう少し。これまでの調査レポートを振り返ると、前月に対する増分はだいたい1.0ポイント弱ですので、来月は確実に50%を越えるでしょう。

祝!常時SSL化対応上場企業半数超え!

ですね。パチパチパチ…

 

対応サイト半数越えの見込みは喜ばしいけど…

半数超えは確かに喜ぶべきことなのですが、手放しに祝える状況とは言えません。

2018年7月にはブラウザシェア5割(国内では4割弱)の Google Chrome で「安全でないサイトです」と表示されるのが分かっているのにも関わらず…まだ半分が未対応ってことですから。

まぁそれを言いだすと、実は中央省庁Webサイトもほぼ全て未だに常時SSL化できてないってこともあって、そもそも国全体が結構恥ずかしい水準ではあるんですけどね。

今もって常時SSL化対応できていないのは、

  • A) そもそも知らない
  • B) 知っているが対応できない
  • C) 知っているが対応しない

の3パターンに分けられるのですが、実は B が多いんじゃないかなぁと思う昨今です。色々理由は考えられますが、もしできないなら無理に自分でやる必要はなくて誰かにやらせるって判断もあり…だと思うんですよね。弊社は最近、そこに役割を見出してます。

 

役割分担で楽しよう

サイトの規模が大きかったり、CMSを使っていたりすると、ひとことで常時SSL化といってもなかなか難しいのが実情です。リダイレクトとか絶対パスとか外部参照とか…考えてたらキリがない。

常時SSL化の作業は、サイトの制作会社様もエンドユーザ様も本業ではない筈なんですよ。そこを気にして時間や精神が蝕まれるのって勿体無い。だから全部外出ししましょうよ…というのが、espar事業を通して最近発信しているメッセージの1つです。

20180320_aossl.png
(サイトに何の変更も加えずにhttps化できる)

DNSを切り替えるだけで気がかりがなくなるならそのほうが良いですよねとご提案していて、事例も増えてきて好評も頂いてます。

面白いと思うのは、常時SSL化できたという事実が嬉しいというよりも、頭の片隅に引っかかってた常時SSL化のことを一切考えなくて良くなったと評価して頂くことがあるって点ですね。

そうなんです。今の web は制作会社様やエンドユーザ様に色々求め過ぎ。まぁ仕方ない側面もあるのですけどね。ただまぁそれだけに、考えなくちゃいけないことを減らせるに越したことないんです。

餅は餅屋で作業分担し、各々が得意分野や本業に全力投球すること。それが関係者皆にとって幸せなんじゃないかなと思う昨今です。楽できるところは楽するのが一番です。

 

という訳で2018年3月の常時SSL化対応状況レポートでした。何か後半は思いをぶつけてた感ありますが…。さて、来月は遂に半分超えが見込まれます。また来月もレポートいたします。


2018.03.16 (Fri)

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

3月12日、東京は飯田橋で開催された daab Developers Summit 2018 で登壇させて頂きました。

20180316_daabdevsummit2018

スマホ向けのビジネスチャットサービスである direct の開発者向けイベントです。direct の開発元 LisB さんが daab 発表3周年を記念して主催されました。

daab とは direct agent assist bot の略で direct というビジネスチャットをプラットフォームとした、チャットボットを提供する為の仕組みのようなものです。slack 向けボットでも使われる Hubot がベースになってます。

 

弊社とdirect

directを提供されてるLisBさんと弊社との関係は実は結構長く、それこそdirectがローンチする前からのお付き合いです。社長の横井さんとのご縁がきっかけで、そこからはや10年近く…になるでしょうか。

20180316_businesschat
(Thanks! the photo on flickr by William Hook / CC BY-SA 2.0)

directがまだクローズド版だった時に使わせて貰いました。ビジネスチャットという着眼点は素晴らしいなぁと LisB さんを羨ましく思ったものです。

当時、弊社のファイル共有サービスSYNCNELが思うように拡販できてなかった時期だからかも知れませんが(笑)、自社ビジネスを持つ会社あるあるの隣の芝は青い心境で、スマホ向けビジネスチャットの国内黎明期を羨ましく見てました。これは絶対盛り上がるでしょと。

その後、前述の daab を2014年末に発表されます。チャットツールをサードベンダーがボットを作って拡張できるというんです。LINEの BOT API の発表が2016年4月ですから、如何に早いかが分かりますね。

20180316_daab

リリース前に構想をお聞きして、軌道に乗り始めていた自社のSYNCNELと連携させようという流れで、daab の開発パートナーにならせて貰いました。SYNCNELのロゴも載せて貰ってましたかね。

1年半後の2016年2月、弊社はSYNCNELを富士ソフトさんに事業譲渡しますが、その橋渡しをして下さったのが LisB さんです。何がどう繋がるか分かりませんよねホント。

そんなご縁で今もお付き合いさせて頂いてるという訳です。弊社は今 direct の一販売代理店とならせて貰い、導入支援/運用支援もしています。

20180316_daabdevsummit2018_ft
(参加人数は60人弱ぐらい。ほとんどがSIerさんなどの開発関係者だったかと)

一個人として、国内スマホ向けビジネスチャットの歴史を身近に見てきましたけど、間違いなく direct はその先駆けで(当時chatworkはスマホ最適ではなかった)、今でこそ流行りのビジネスチャットボットのコンセプトを最初に打ち出したのもまた direct なんですよね。

だから応援の意味もあってお付き合いを続けさせて貰ってます。プロダクトとしても良くできてますし。(どこ目線だw)

 

ビジネスチャットの役割

僕は、情報セキュリティレベルが低い国内事情も、生産性が低いと言われて久しい日本企業の実態も、諸悪の根源は「メール」であると考えてます。

メールを廃止すれば、いわゆる働き方改革(?)をやらなくても生産性は劇的に上がりますし、国内セキュリティインシデントも半分以上は無くせるし、際限なく掛かるように思える情報セキュリティ費用も極小化できると思ってます。

20180316_businesschatrole
(発表で使ったスライドの1つ。社内で両者のためにメールを使うべき理由は皆無)

実際、directを始めとするビジネスチャットツールは、社内コミュニケーションとしてのメールを激減させました。人と人との会話はメールよりよほど効率的ですし、スパム誤判定による喪失や大量のメールに埋もれる事もありません。

社内コミュニケーションに使うメールと対比すれば、ビジネスチャットにはメリットしかないのです。

でも、社内のメールを無くすという観点で唯一 direct に欠けていると思っていたのが、社内を飛び交う通知メールをどうにかする手段でした。システムからのアラート、定期的な営業レポート、グループウェアからの通知、IoT機器からのお知らせ…。これらを、簡単に、あらゆるシステムから、あらゆる言語から direct に通知として容易に流せたら良いのにと。

でも、ボットサーバを立てるアーキテクチャではこれが面倒なんですよね。

20180316_makeallbots

LINE WORKS も同じです。ボットは作れますが、特定のチャットルームに通知を送るだけの為に別サーバを立てて環境を作る必要があります(Serverlessという手段もありますが、別に用意しないといけないという意味では一緒)。

この点、REST API を備えて手軽に通知を放り込める slack や chatwork のほうが優位です。

例えば、以下に示すのは chatwork に通知を送る GAS のコード。Google SpreadSheet の編集時にB1セルの値を通知するってなことが、

CHATWORK_WEBHOOK_API_TOKEN = '1234567890abcdef1234567890abcdef';
CHATWORK_WEBHOOK_API_ENTRY = 'https://api.chatwork.com/v2/rooms/12345/messages';
var options = {
  'method' : 'post',
  'headers' : {
    'X-ChatWorkToken' : CHATWORK_WEBHOOK_API_TOKEN,
  },
  'payload' : 'body=' + SpreadsheetApp.getActiveSpreadsheet().getSheetByName("sheet").getRange("B1").getValue()
};
UrlFetchApp.fetch(CHATWORK_WEBHOOK_API_ENTRY, options);

とたった数行で書けます。これを書くのに5分もかかりません。普段使ってて慣れてますから。サーバも特別な環境も不要です。

slackならもう少し簡単ですね。

SLACK_WEBHOOK_API_ENTRY = 'https://hooks.slack.com/services/T00000000/B99999999/123456788912345678901234';
var options = {
  'method' : 'post',
  'payload' : 'payload={"username":"webhook","text": "' + SpreadsheetApp.getActiveSpreadsheet().getSheetByName("sheet").getRange("B1").getValue() + '"}'
};
UrlFetchApp.fetch(SLACK_WEBHOOK_API_ENTRY, options);

って書くことができます。このシンプルさは通知用の REST API (webhook) があらかじめ用意されているからです。

シンプルさとセキュリティは相反するのでバランスが重要ですが、シンプルに提供できるならビジネスチャットツールで社内通知を根絶できます。実際、弊社は通知系を基本 slack に集約していて、社内でのメールも、社内システムからのメールも一切ありません。

20180316_slack

そこで、今回冒頭で言及した daab を使って、direct への通知を REST API (webhook) として実現するようなボットを作ってデモしました。

20180316_daabwebhook

やっぱ応援しているプロダクトが他の競合プロダクトに負けてるかもって思う事があると悔しいじゃないですか。で、実際に動くものを作って見せれるというのは開発者・開発会社の良いところなので作ってみた次第です。中のエンジニアの方にも面白がって貰えたようで良かったなと。

directが標準で REST API を搭載するまで、今回作ったボットを使って社内で運用、また espar など静的化製品での活用を考えてます。

 

以上、イベント参加報告でした。他の登壇者の方も、AIやIoTやEDIやRPAなど、ボットを使って色んなことができるってことを紹介されていて、聴講者としても面白く且つ勉強になるイベントでした。

先日の MobileAct といい開発者向けイベントに登壇することが増えてます(増やしてます)。これからも機会あればアウトプットしていきたいと思います。


2018.02.20 (Tue)

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

昨年6月からはじめた静的化サービスのesparですが、おかげ様でお問い合わせやお引き合いを沢山頂いており、実績も着実に増えつつあります。

対象となるサイトは当初の想像通り、ほぼ全て WordPress です。

20180220_espararchitecture

esparの基本的な仕組みは、

  • CMS側(WordPress等)の設定を何も変えることなく
  • 弊社の静的化エンジンが外からhtm化(静的化)して必要ファイルを収集し
  • 弊社のホスティング環境でホストし
  • DNSを弊社ホスティング環境に切替えてもらう

というもので、絵にするとまさに上図のような感じで実現しています。

google bot のようなものが対象サイトの全ページをクロールする仕組みと同じですので、対象となるサイトには弊社の静的エンジンからのアクセスが必要になるのが特徴です。

 

20180220_engine
(Thanks! the photo on flickr by bark / CC BY 2.0)

静的化エンジンを内部に持ちたい

通常は外からのアクセスが普通にできるので問題ないのですが、医療機関・自治体・財団法人など公的色合いの強いWebサイトの場合、そうはいかない場合があります。

例えば、院内のプライベートネットワークに WordPress 環境があって院内から関係者が編集、全体を静的化してインターネット上の公開サーバに転送…ってことをしたい場合があります。あるいは、そもそも外からの余計なアクセスをNGとしているサーバ環境に WordPress を構築している例もあったりします。

20180220_esparonpre
(プライベートネットワークにWordPressがあると外から静的化できない)

このような環境のサイトには、従来のesparは導入できませんでした。外から静的化させて貰えませんから。そこで今回、御客様の要望にお応えする形で espar WP Plugin という新商品を開発しました。

『弊社の静的化エンジンを WordPress のプラグインにしました』

ということですね。Go言語で実装したエンジンを WordPress プラグインの仕組みでラップしています。宜しければプレスリリースも御覧下さい。

 

20180220_staticpress
(静的化プラグインでは一番有名な Static Press)

既存の静的化プラグインとの違い

実は、WordPressの静的化プラグインって幾つもあります。

国内だと Static Press が一番有名でしょうか。WordPressのプラグインではないですが、古くからあるwgetというWebサイト取得ツールもありますね。

無償のものがあるのに、今回 espar WP Plugin を出したのは何故か。何が違うのか。理由(優位性)は主に3つあります。

1. 速度

Static Press しかり Really Static しかり、wget もそうですが既存のものはとにかくスピードが出ません。

並列処理をしているかどうかが大きな差なのですが、esparのエンジンは並列処理が得意なGo言語の特性をフルに活かしているので高速です。サイトやページ構成にも依りますが普通に10倍ぐらい早いこともあります。

2. 静的化クオリティ

既存のものは静的化を巧くできないケースが散見されます。静的化って結構複雑なんですよね。

  • CSSのbackground:url()属性に指定されている画像
  • html5のsvgタグやdata-属性の中身
  • jQueryで制御された<a>タグではないタグによるリンク先
  • ページからはリンクされていない画像やPDFデータ

など、静的化においては、解釈できなければいけないこと、取得できなければならないもの、が沢山あるのです。既存のものはこれらを取得できないことが多く、それはサイトの静的化品質にそのまま繋がります。

esparは2年以上も静的化エンジンという用途に特化して進化させてますから、クオリティは圧倒的に高いんですよね。つまり再現性が高くて、そこには自信があります。

3. 設定は全部お任せ

WordPressプラグインのインストールからエンジンの設定、公開サーバの設定まで全部弊社で実施します。「このサイトを静的化したいんです〜」と丸投げして頂ければ、数日のうちにWebサイトの静的化が完了します。

動的な要素(問合せフォームや検索)などの機能と共存も可能です。

 

このようなメリットがあって、御客様もそれを期待して頂いていたので、商品としてリリースすることにしました。既に都内の某財団法人様においては導入済みで本番稼働しております。また、某金融系企業様にも導入がほぼ決まっています。

という訳で新商品のご紹介でした。

今回発表の espar WP Plugin は、WordPressサイトの運用で陥りがちな課題を一挙解決する最もコストパフォーマンスが高い商品であると自負しております。WordPressの高速化やセキュリティにお悩みの方は是非ご連絡下さい


2018.02.18 (Sun)

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

スマホ見るなら本を読めと自分に言い聞かせて続けているスキマ時間活用法。

スキマの時間、思わずスマホに向かう手を本に向けて読書する毎日です。エスカレーターとかでも読書してます。(歩き読書はダメ!)

20180218_reading.jpg
(Thanks! the photo on flickr by Sebastien Wiertz / CC BY 2.0)

スキマ読書をはじめて3年目の昨年は1年間で67冊でした。1年100冊は越えたい2018年の初月はどうだったか。今年もグラフで視覚的に残していきます。

8,9冊いきたいところでしたが、初月は7冊に落ち着きました。無念…orz

そんな7冊の内訳は以下の通りです。

 

ビジネス本

趣味本

 

という感じになりました。「趣味本」というくくりは、新たなジャンルですね。最近、いわゆる DIY にハマってまして、その関係で 3D CAD を触るようになったんですよ。

20180218_sketchup.jpg
(キッチンに新たな収納スペースを作成すべくSketchUpを使って設計中の図)

どんなものを作るのか、3Dで完成イメージを見て貰うほうが奥さんに分かって貰い易いかなぁと思って始めたのがきっかけです。手書きでも良いっちゃ良いんですけどね。書き直しとか調整がやり易いのがデジタルのメリットです。

 

閑話休題。で、今月のイチオシ本は、

こちらです。非常に分かり易くまとまっている iDeCo 本です。最初の一冊として良いかと。

iDeCoでは投資信託の話を避けて通れないのですが、投資の考え方や分散投資のメリットなどいわゆる投資の基本について結構なページを割いていて、投資にそもそも抵抗があるっていう方にも分かり易く、ス~ッと頭に入る内容になってます。

「年金はもうあてにしないでね」という国からのメッセージとも言えるiDeCo。やらない理由は余りないので、本書を読めば恐らくすぐにでもiDeCo始めなきゃって思われる事でしょう。投資をしたことないって人こそ是非手にとってみて貰いたい本です。

 

という訳で2018年1月のスキマ読書の記録でした。やっぱり読書って良いですね。


2018.02.08 (Thu)

(所要時間 : 約1分)

待ったなしの常時SSL化。

メリットを体感できず面倒くさい、というのが対応進まない最大の理由です。でも周りのサイトがほぼ対応してる…ってなってくるとそうも言ってられなくなりますね。

それが狙いで、一つの指標とすべく2017年12月よりやっている、国内上場企業サイトの常時SSL化対応調査の2018年2月版をお届けします。ザックリこんな感じ。

20180208_sslratio
(もう2018年だというのに上場企業でさえ、まだ半分に届いていない…)

 

常時SSL化の対応状況 2018年2月

このレポートが初めての方の為に調査方法を改めてご紹介すると、

  • 日本取引所グループが公開する銘柄一覧を元に上場企業URL一覧を作成
  • TOPページが https 対応していれば常時SSL化対応済みとみなす

という調査です。2018年2月の上場会社数は3601社で、2018年1月より上場会社の数は少し減りました。

一方で常時SSL化をしている上場会社の割合は少し上がり、前回より0.8ポイントアップ48.7%となりました。数にして26社増

先々月から先月も似たようなものなので、だいたい1%UPぐらいで増えていってるのかも知れません。相変わらず半数にも至ってないのが残念ですが、この調子で行けば5月初旬には祝半分!になるのではないでしょうか。

2018年2月レポートの詳細を、こちらから御覧頂けますので宜しければどうぞ。

 

EV証明書対応サイトが増えた

驚いたのは、EV証明書対応サイト数の伸び。

20180208_websecurity.jpg
(Thanks! the photo on flickr by FutUndBeidl / CC BY 2.0)

前回はプラマイゼロだったのに対して、今回はグンッと増えました。

  • ETSホールディングス(1789)
  • ケアサービス(2425)
  • すかいらーく(3197)
  • Minoriソリューションズ(3822)
  • 日本碍子(5333)
  • 千趣会(8165)
  • いちよし証券(8624)

EV対応していた企業が上場廃止になったケースが今回も2社ありましたが、全体ではプラス5社。割合にしてEVだけで見ると、3%アップです。非常にいい傾向ですね。

まだ常時SSL化していない上場会社はCSR的に論外だと個人的には思っていますが、ホントは全ての上場企業がEV証明書にすべきです。投資家や対顧客への情報発信姿勢としてなぜたった年数万円が支払えないのか、webに対する意識が低いってことだろうなぁと悲しい気持ちになりますね。

 

という訳で2018年2月の常時SSL対応レポートでした。来月もまたレポート致します。

余談ですが、上場企業に限らず、何かのククリで常時SSL化対応状況を知りたいというリクエストがあれば是非ご連絡下さい。URL一覧があれば調査できるので検討させて頂きます。