2017年2月11日土曜日

SlackのBOTをGoogle Apps Scriptで作って思いついたこと

SlackのBOTをGoogle Apps Scriptで作ってみた。いわゆる人工無能で大したことはしていないのだが、異なるシステムどうしが、認証トークンを通じてアクセスしあえて、決まったフォーマットで通信ができることが「体感」できるのである。 取り立てて言うことでもないが、理屈でわかっているだけというのとは違う。動作も速い。スカみたいなコードなのに、とんでもなく速い。VPSであっても、自分でサーバを立てたりというのは、時代遅れなのだろう。 そして、個々のシステムをゼロから仕様を考えて開発するのも、ペイしないという事実もある。Slackを発想して設計することは絶対にできないと、仕様を知るにつれ確信される。

2017年1月22日日曜日

ペッパーが無能な理由

Pepper

Pepper(ペッパー)というのは街でよく見かけるようになってきた、ロボットのようなアレのことである。しゃべりに合わせて手や首を動かすぐらいしか意味がないロボットなのだが、お金を持っている人や企業が、お金を使う理由になるという一点において、有能であると思っていた。
WIkipediaから
また、可愛いと思う人がいてもおかしくはないというレベルの造形ではある。対応がアスペルガー的であるとかいう悪評はあるが、それでも可愛いと言ってあげたいレベルの可愛さではある。しかし、今から説明する「無能さ」を知ると、その可愛さも腹立たしく感じられるだけになるだろう。

その無能さとは何か?

ペッパーは、頭部付近から音声が流れ、手や首が動く。音声認識のため「あなたの発言を聞いていますよ」ということを示すために耳が光るという演出もある。そして、ユーザに視覚的情報を提供するためは胸部のタブレットを使う。タブレットの内容動作を関連付けるスクリプトはたぶんペッパー内にあって、タブレット表示と動作が連携できるのだろう。

さて、問題はこのタブレットだ。胸に掲げられたタブレットに情報が表示されるまではいい。しかし、タブレットの操作を行わねばならないとき、それを誰が行うのか、である。ユーザが何もしないでとまどっているようなときに、「次に行きましょうか」とか気の効いたことを言って、ペッパー本人が行えるならいいのだが、どうやら、ペッパー本人は自分の胸にあるタブレットの操作を行える仕組みはないようなのだ。

マニピュレータを持つロボットとして、これでは残念ながら無能であると言わざるをえないではないか。









2017年1月15日日曜日

20170115時点でのHomebrewのインストール方法

MacにHomebrewをインストールするとき、検索するといろんな記事が出てくる。わざわざ追加するのも意味はないかもしれないが、インストール方法(正確には指定先のURL)がアップデートされているようなので、2017年1月15日でのインストール方法をメモしておく。

駄目な方

$ ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

行ける方 

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 
今後も変更される可能性はあるので、 http://brew.sh/の「Install Homebrew」を参照するようにしたい。


macOS(OSX)のAppStore/インストール進行状況確認/Command Line Tools for Xcode

Command Line Tools for Xcodeを使うちょっとしたことが発生し、Xcodeをインストールすることになった。2017年1月15日現在、Xcoe V8.2.1は4.55G。AppStoreでXcodeを探し、「入手」をクリックすると「インストール中」となる。


小さいサイズのアプリケーションなら気にならないが、これだけのサイズだと時間がかかる。その後の進行状況はどうやって確認したらいいのか?これが唯一のやり方ではないが、答えは「LaunchPadを立ち上げる」である。


ダウンロード状況が確認できるので、止まっているのではないかといった心配はしなくて済む。なお、LaunchPadは、デフォルト設定のままなら、トラックパッドの「親指と3本の指でピンチイン」のアクションで立ち上がる。


結局、2時間ぐらいかかってインストールは完了した。ダウンロード中がインストール中に変わってからも少し時間はかかるが、我慢である。

最終目的物であったCommand Line Tools for Xcodeは別途インストールする必要があるかと思っていたのだが、メニューのXcode→Preferences...→Locationsで確認すると同時にインストールされるようになったようだ。



2017年1月9日月曜日

Webサイト簡易構築運用サービスでSSLを使う


簡易CMSという分野

Webサイト簡易構築運用サービス(以下:簡易CMS)」という分野がある。JimdoStrikinglyなどがそれにあたる。SaaS型のWebCMSを低価格(年ごと課金が主流)で使えるようにしたものである。機能や特徴の差は様々だが、Web専任の担当者がいないような、主に中小企業向けのWebサイトや、大企業でも単発的に利用する企画サイトなどに適している。変更がすぐに公開されたり、コンテンツ公開の承認ワークフローがなかったりと、大きい組織でルールを守って運用するには力不足だが、小規模組織ならは運用ルールで乗り切れるだろう。

中小企業のWebサイトもSSL対応は必要

ドメイン取得とDNSのサービスも組み込まれていることが多い。もちろん、お名前.comのようなレジストラで取得したドメインも利用可能だ。しかし、簡易CMS全般について言えるのだが、「SSL」での運用ができないという課題があった。中小企業ならWebサイトのSSL対応は不要と言い切りたいところだが、そう言い切るのは難しい理由がふたつある。

Pマーク

ひとつは、Pマークを取得している場合、問い合わせフォームに個人情報を入力する際に、暗号化されていることが望まれるからである。必須というわけではないが、そう指導されることが多い。Pマークなんて不要という考え方もあるが、業務の関係でPマーク取得を余儀なくされるケースも多い。この場合、フォーム無しで行くという選択もあれば、フォームだけ専用サービスとして外部化するという方法もある(フォーム専用サービスの場合、更に共有ドメインのケースとと専用ドメインのケースに分かれる)。しかし、身も蓋もない話をすると、簡易CMSの問合せフォームもフォーム専用サービスも、通知の際にメールが流れることが多く、そこに漏洩の可能性は残る。単に問合せがあったという通知がメールされるだけなら問題ないが、問い合わせ先の個人情報がメールに含まれるとすると、セキュリティ的な観点からはアウトということなのだが…

SEO

ふたつめは、SEO観点で常時SSL化されている状況が必要とGoogleが言い出したからである。実際のところSSL化が必要な理由は、個人情報保護だけではなく、サイト改ざん対策や、リファラー情報の受け渡しを考えるとWeb解析の精度を上げることができるなどの理由があるようだが、いずれにせよ、どこかの時点でWebサイト運用は、SSL前提が当然という時代が来たのである。

簡易CMSでもSSLは利用可能に

このような状況を受けて、業界最大手であるJimdoでは、2016年末にSSL運用対応が始まった。また、自分が愛用しているStrikinglyでも、SSL対応が可能となっている。元々、Strikinglyでは、Strikinglyでドメインを用意した場合にはSSL対応が可能であったが、他のレジストラでとったドメインでもCloudFlareを使って、SSL対応が可能になった。両サービスとも、共有でSSLを実現するためのSNIという仕組みになっているため、SSL証明書を別途購入して組み込むという作業は不要で、無料でSSL化が実現可能となっている。

CloudflareのSNIによるSSLについては、以下の記事が詳しい。
セキュリティの専門家はCloudfrareのSSLなんて危なくて使えないという意見もあるとは思うし、それはある程度正しいと思う。しかし、あまり健全ではないが、以下のような見解もあり得るだろう。

サイトをSSL化させる目的は、いろいろあって、本質的なセキュリティを実現するには無理もあるが、結局はWebサイトの訪問者を「少なくとも表面的に安心させる」ということが重要であり、Webサイトの構築運用業者の観点からは発注側に「SEOや安心させてコンバージョンを増やすというマーケティング観点でもSSL化が重要ですよ」と言えなくてはいけないのだ。それがあまり感心できないセールストークだとしても、である。たぶん、どんな種類のSSLを使っているかは訪問者はほとんど気にしないし、ほとんどの発注者もSSL化されているかどうかを気にするだけだろう。PマークのチェックのときもSSLの証明書の品質をチェックされるようなことはないと思われる。

結論

自社で簡易CMSサービスを使っていても、業者の立場で簡易CMSサービスを使っていても、サイトSSL対応は必須であり、そしてそれは可能になってきたのである。

JimdoとStrinkingly以外の独自ドメインSSL対応状況(2017年1月)



2016年4月30日土曜日

Uberの体験とユーザーエクスペリエンス設計雑感

Uber(「ユーバ」ではなく「ウーバ」と発音するらしい)を使って、ユーザーエクスペリエンス設計とは何、初めて腑に落ちたような気がするので、それをまとめたのが以下の記事となっています。Uberが何であり、具体的にどう使うかはこちらで。

先日イギリスに行った際に、ロンドン市内のホテルからヒースロー空港までUberのタクシーを使った。

まず、Uberアプリケーションをダウンロードし、クレジットカードを登録する。次に行き先を入力(あと乗車人数も入力できたかもしれないが)。すると、近くを走っている車から連絡がくるので、運転手の名前を確認し承諾する。車のナンバーが教えられて、運賃もその時点で確定する。金額は普通のロンドン黒タクシーより安いはずだが確認したわけではない。なお、車の豪華さや大きさで運賃が異なってくるらしい。複数の車から連絡がくるので、運転手さんの評判を確認して選択するステップもあるのだろうが、今回は最初に連絡があった車にした。

3分ほどで車が到着。車が近づく様子も地図上で確認できるのでどの車か間違えることはないが、念のためナンバーも確認する。メーターなどのタクシー的な設備は一切ない普通の車だった(スマートフォンがホルダーにセットされているだけ)。あとは乗車して降りるだけである。支払いや領収書の発行もない。なお、領収書はWebサイトからダウンロード可能。降車後に運転手の評価をするが、完全安全運転だったこともあり、最高点を差し上げた。

箇条書きで書くと、
  1. 行き先入力(スマートフォン上)
  2. 車選択(スマートフォン上)
  3. 金額と車のナンバー確認(スマートフォン上)
  4. 車を確認して乗車
  5. 降車
ということになる。

せっかくなので、Uberで仕事をするというのはどんな感じなのか、運転手さんにいろいろたずねてみた。

Q1.運転手は客を選べるのか?選ぶための客の個人情報を見ることができるのか?
A1.ノー。客の人種や国籍は確認できない。

Q2.車は自分の所有物だと思うが、車の掃除やメンテはUberから指導があるのか?
A2.ない。評価につながるので自分でしっかりやる。

Q3.もうかる?
A3.昔は普通のタクシー(黒タクシー以外にも別の会社がある)で仕事をしていたが、車のメンテナンス費用などを考慮しても、取り分は大きい。黒タクシーの客待ち行列を見ろ。効率が悪すぎる。位置的に最適な客を知らせてもらえるので最高だ。これが競争原理でありキャピタリズムじゃないか!

Q4.イギリスならどの都市でも使える(オックスフォードではUber車が見つからなかった)?
A4.現時点ではロンドンを含めて5都市のみ(列挙されたが忘れた)。ただ、客を運んだ先のUber車が使えない地域で別の客をひろうことはある。

Q5.とんでもなく安全運転だがそれはどうして?
A5.事故をしたら困るのは自分なので、安全運転するしかない。

Uber、個々の要素技術は特に新しいものはないが、統合されたサービス(顧客視点からだとエクスペリエンス?)としては間違いなく「イノベーション」である。特に「評価」という「競争原理」が組み込まれているので、自然とサービス品質が向上する。あと、Uberにとっては、乗車する客だけではなく、運転手もユーザーとしてとらえて、そのエクスペリエンス設計をしているのだろうと感じた。

ここからが本題である。

ユーザーエクスペリエンス(UX)という単語をよく聞くが、今まで正直その意味合いがよくわからなかった。しかし、今回Uberを使って、なるほどこれは客と運転手の「経験」をよく「設計」してあるな、と感じたのである。そして、「設計」のポイントはどこにあるかというと、「限られた選択肢の中から選べる」ということにつきる。UXというと「快と不快」のような説明をされることもあるが、「あまり考えずに簡単な選択肢の中から選択できる」ことは、「実際には受動的な行為であってもほんの少しの能動性があることで脳が快を感じるのだろう」というのが自分の結論である。

加えて強調したいのは以下の3点である。

1.ユーザーエクスペリエンス設計は事業の設計そのものであり、ユーザが使うインターフェースの設計は一部であることを痛感したのであった。アマゾンなどの買い物体験も大胆にユーザーエクスペリエンスが再構築されているはずなのだが、あまりに慣れ過ぎてしまってもう何も感じなくなっている。Uberでユーザーエクスペリエンスを強烈に意識したのは、普段の「タクシー経験」との差と比較してずいぶん異なっていたからである。

2.ユーザーエクスペリエンス設計のいきつく先は、システムとやりとりするためにUIに接する頻度を可能な限り減らすことになるだろう。ゼロにできるならゼロにした方が良い。

3.良くも悪くも日本では「デザイン」というと「装飾的要素」が想起されてしまうことが多いので、デザインと言う言葉ではなく設計と称したほうが、誤解は減るのではないか。つまり、「ユーザーエクスペリエンスデザイン」ではなく「ユーザーエクスペリエンス設計」または日本語だけで「利用者体験設計」とした方が無用な混乱は減る。

Uberの運転手さんに車の自動運転が実現すれば仕事がなくなりませんか、という質問をしたかったのだが、質問しないほうが良さそうな気がしてやめておいた。

2015年7月4日土曜日

iPadの音楽ライブラリが母艦PCと同期されない/「復元」で復元されないものは何か?

iPadMini(初代)の画面を割ってしまったので、今さらだが新しいiPadAir2を入手した。

旧iPadMiniから復元を行って、環境やアプリケーション類はすぐに復元される。PC側のiTunesの「バックアップを復元…」メニューからの作業で、復元されないものは以下のとおり。


  • GoogleApps系アカウントのパスワード。
  • システムアカウントに近い扱いの、Facebook、Twitter、Flickr、Vimeoのアカウントとパスワード。
  • 電子書籍系のコンテンツ。Kindle、BookLive、honto、Kinoppy、koboはすべてダウンロードのやり直しが必要。
  • ログインが必要なアプリケーションは、ものによって状況が異なる。ソーシャルメディア・アカウントを使わない独自作成アカウントを使っているものは再ログインが必要。ソーシャルメディア・アカウントでログインしているものは、該当アカウントがiOSに入力しておけば、
そして、iTunesライブラリの楽曲も復元されない。今まで、数回バックアップから復元を行った際も楽曲の同期は別ステップだったのはずだが、ケーブル接続と同時に同期が行われるのでこのステップ意識することはなかったのだろう。今回、なぜ意識したかというと、iPadで選択した曲を選んで、それが開始されるまで少し時間がかかったからだ。

結局、iPadのローカルライブラリには楽曲データは一切なく、iCloudのライブラリからストリーミング再生されていたことが判明。iTunesMatchを契約していてiCloud内に全楽曲が保存されているからなのか、iTunesMatchを契約していなくても同様の状況になるのかは不明だが、iPadローカルライブラリに楽曲が入らないのは嬉しくない。最近はAppleMusicやAWAを無節操に使っているわけなので、自分の「所有」している楽曲がクラウドライブラリに置かれていて、そこから再生されていてもいいんじゃないかとも思ったりもした。が、LP/CD世代としては、まだしばらくは「所有の意味」から解放されるのは難しい。

今までなら、iPadをつないだ状態で、PCのiTunesから目的のデバイスを選び、「設定→ミュージック」から「音楽を同期」をオンにしてやるだけでよかったのだが、この「音楽を同期」がないのである。


結局、iPad側で「iCloudユージックライブラリ」をオフにしないと、「音楽を同期」が表示されないことが判明。無事に、「所有」していた楽曲を自分のローカルデバイスに保存することができた。


音楽聞き放題サービスが主流になる状況で、今後は音楽をダウンロード購入したり、ましてやCDを買って「パソコンに入れる」ということは行わないと思うので、「ローカルにブツがあること」に対するこだわりはなくなっていくだろう。