石橋秀仁(zerobase)書き散らす

まじめなブログは別にあります→ja.ishibashihideto.net

顔パスの未来

PayPal Beacon: Hands-Free Payments - YouTube

PayPal Beaconの動画を見てたら思ったんですよ、「これスマホでユーザーをアイデンティファイ *1 してるけど、もはやバイオメトリクス *2 でよくね?」って。結局フィジカル(身体的)に、その店まで行ってるわけですし。そもそも店員が顔を覚えていれば、実際に顔でアイデンティファイ&認証されてるわけですし。なんでデジタルデバイスいるの?っていう。

これを「気持ち悪い」と思う人もいるんだと思います。でもぼくはSF読者なので、こう考えるんです。

単にITで店員の「客の顔を覚える能力」を拡張してるだけです

って。この思想が普及するかどうか、っていう問題なんです。これは時間の問題。10年か100年か知らないけど、未来はこっち。速いか遅いかの問題です。

とはいえ、プライバシーは気になりますよね。だから具体的な解決策を考えることも大事です。これは専門家の仕事です。例えば「顔写真そのものは使わず、特徴量データを使う」とか「ほかのデータとの紐付けを許可無く行わせないような、プライバシーフレームワーク*3 とかいった方向で、いろいろやる必要はある。課題は山積みです。でも、まあ、なんとかなるんじゃないかなあ、と楽観的に考えています。ぼくは専門家の力を信じています。

「究極のパーソナライゼーションと利便性を、どうやってプライバシーと両立させていくか」について、これから専門家たちが知恵を絞って考えていかないといけないんだろうと思います。

補足:

あくまでオプトインなのであって、顔パスの仕組みを使いたい人が、「店に対して顔パスの利用を許可する」という話をしています。こういう仕組みを使わない自由は担保される前提です。 *4

*1:「アイデンティファイ」は「同定」と訳される言葉です。ここでは「事前に予約したユーザーが、目の前のこの人と同一である」という同一性の確認のことです。ここでは「認証」も兼ねてます。「認証」とは「何らかの資格を有するかどうか」の確認です。ここでは「この品物を受け取る資格を有するかどうか」の確認ですね。

*2:バイオメトリクス」は「生体認証」と訳される言葉です。この場合は「顔パス」のことですね。暗黙的にアイデンティフィケーションも行われます。つまり「この顔の人は、この人であり、この商品を受取る資格がある」という確認プロセスを「バイオメトリクス」(生体認証)と呼んでます。

*3:「ほかのデータとの紐付けを許可無く行わせないような、プライバシーフレームワーク」については、(これを提案するという意味ではなく一例としての提示ですが)例えば「OpenID Connect的なオプトインの個人情報開示フレームワーク」の方向性は有力かなと思っています。そこにオバマの消費者プライバシー権利章典 (Comsumer Privacy Bill of Rights) でいう「コンテキスト尊重の原則」 (a principle of “respect for context") を採用します。ユーザーから見れば「お店に事前注文商品をピックアップしにいく」というコンテキストのなかで自身のパーソナルデータが使われることには抵抗がないけれど、そのコンテキスト外で利用されることについては「おいおい、ちょっと待ってよ」となるので。

*4:東浩紀 情報自由論 の「存在の匿名性」に関する議論を参照のこと。

Amazonの商品紹介用iframeタグには代替テキストがないのが残念

Amazonのリンクって残念なタグだなあ:

ソース:

<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=hidetoi-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=0596527349" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>

ってなってるんですが、srcdoc (HTML5) や noframes で代替テキストを設定してほしいなあ。「テキストのみ」のリンクとして取得できるタグでいいと思うんですけどね:

Information Architecture for the World Wide Web

ソース:

<a href="http://www.amazon.co.jp/gp/product/0596527349/ref=as_li_ss_tl?ie=UTF8&camp=247&creative=7399&creativeASIN=0596527349&linkCode=as2&tag=hidetoi-22">Information Architecture for the World Wide Web</a><img src="http://ir-jp.amazon-adsystem.com/e/ir?t=hidetoi-22&l=as2&o=9&a=0596527349" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />

参考

4.7 Embedded content — HTML5

厚労省はドワンゴの「入社受験料」制度」を禁止するなら、代替となる市場設計案を提出すべきだと思います

ドワンゴの入社受験料中止求める 厚労省、16年採用から - 47NEWS(よんななニュース)

金銭的コストが時間的コストに振り替わる

"金もうけが目的ではなく本気で入社したい人に受験者を絞り込むため" なので、代替策として「何らかのコストを課す」方式が採用されるでしょうね。まあ時間的コストでしょうね。とても時間がかかることをやらせるとか。例えば、

といったこと。それによって選考企業は就職活動者に時間的コストを課すことができます。

時間的コスト以外の方法もあります。例えば精神的コスト。「マジでヤバい就活生」的なイタい自己PRサイトを作らせる、といったことが考えられるわけです。それで「本気度」を測ることはできます。しかし、それこそ人権的・プライバシー的な問題になってくるでしょう。厚労省としても、さらにNG度は高いと判断せざるをえないでしょう。

というわけで、時間的コスト系の施策が妥当かなと思います。

就職活動者のエントリー負担を減らす観点で

リクルートオープンES で就職活動者のエントリー作業負担を減らそうとしています。ドワンゴの入社受験料は、これと相性がよいと思います。

入社受験料制度は、就職活動者に受験料を支払わせることによって、「本気のエントリー」であることを顕示させます。エントリーする時点で、すでに就職活動者は本気度を示しています。ですから、エントリー自体はオープンESのような「ワンクリック」で済みます。「足切りのための本質的でない時間的コスト」をかけさせる必要はありません。

一方、入社受験料制度がなければ、どうなるでしょうか。オープンESの仕組み自体は、「下手な鉄砲も数打ちゃ当たる」式の闇雲なエントリーを増やかねません。採用企業としては、選考コストを下げるために、何らかの足切り手段が必要となります。

そこで入社受験料制度が禁止されてしまえば、ほかの足切り手段が必要になります。

これまで就職活動者は「手書きのエントリーシート」で本気度を示していましたが、「手書き」なんてまったく本質的ではないコストです。オープンESの登場は、就活エコシステムの進化として納得できます。「手書き」という非本質的なコストを取り除くので、歓迎できます。

しかし、オープンESによってエントリー負担が下がることで、採用企業の選考負担は向上します。言い換えると、就職活動者のエントリーコストが、採用企業の選考コストに転嫁されるのです。やむをえず、何らかの足切り手段が必要となります。

冒頭であげたように、

といった時間的コストの設計が考えられます。これらは「まったく本質的でない時間的コスト」ではありません。時間を有意義に使うことが出来ます。前者は「応募者をよりよく知る手段」になりますし、後者は「企業についてよりよく知ってもらう手段」になります。少なくとも「手書きのエントリーシート」よりは、はるかにマシな時間的コストの課し方です。

おわりに

この問題はミクロ経済学や市場設計のような分野に関係してきます。ぼくは情報アーキテクトなので「アーキテクチャ」の問題にも見えています。

「本気度」という情報は就職活動者の内面にしかありません。つまり情報の非対称性があります。そこで、就職活動者のシグナリング行動として「手書き」が行われていました。もし「手書き」をやめるなら、別のシグナリング手段が必要です。それが「受験料」でしたが、禁止されそうです。ならば、さらに別のシグナリング手段が必要なのです。

厚労省は、ドワンゴの入社受験料を禁止するなら、代替となる市場設計案を提出すべきだと思います。民間の創意工夫を官が潰すなんて、明確な市場制度設計目標がない限り、正当化できません。そもそもフォロアーもほとんどいないわけだし、せめて100社くらい同じことをやった段階になってはじめて規制するくらいでないと。民間の創意工夫、つまりイノベーションを、官が潰すのは承服できかねます。

Facebook上の「シェアさせて頂きました」の意味がわからない

Facebook上の「シェアさせて頂きました」の意味がわからない。以下、いくつかの意味解釈を検討していく。

パーミッション

「させて頂く」の意味がわからない。許可や承認が必要だとは思えないからだ。

そもそも投稿者がシェアされたくない場合は、シェア可能(公開 public)なパーミッションで投稿しないはずだ。例えば「友人のみ」(friends only)な設定にするだろう。

シェア可能な設定で投稿されているということが、すでにシェアの許可を意味している。「シェアしてもよい」ないしは「シェアしてほしい」といった意図があるからこそ、シェア可能な投稿にしているはずだ。

だから、わざわざ「させて頂く」という意味が分からない。敬語が過剰で、誤用だと感じる。「シェアしました」でいいだろう。

感謝の表明?

あるいは「シェアしました、ありがとうございます」ならわかる。しかし、感謝の言葉なしに「シェアさせて頂きました」と書かれていることが多い。やはり意味が分からない。

リンクさせて頂きました?

ひょっとしたら、ウェブ普及初期の「リンクさせて頂きました」の再来だろうか。

当時は「ウェブで公開するということは、自由なリンクを許可したとみなされる」という共通了解がまだできていなかった。「勝手にリンクしないでください」「リンクするまえに連絡ください」と書かれたウェブページもたくさんあったものだ。

いま考えると滑稽だが、歴史とはそういうものであって、当時は真剣に議論されたテーマなのだ。

この解釈でいくと、前述のようなFacebookパーミッション機能を知らない人が、「勝手にシェアしていいかどうか、投稿者の意図が分からないので、事後承諾にはなってしまうが、ちゃんと報告しておこう」というつもりで、「シェアさせて頂きました」と書いていることになる。

正しい知識が広まってほしいと思う。Facebook社には、正しい利用法の周知・啓蒙に取り組んでもらいたい。

根拠なき模倣の連鎖?

ひょっとして、誰もその意味を考えないまま、他人を模倣しているだけなのだろうか?

「なんとなく丁寧っぽいし、とりあえずやっておくか」という程度の軽い気持ちで。

その「とりあえず」が積み重なって、公害とまでは言わないが、ノイズになっている。

ノイズだから、やめてほしいから、こんなテキストを書いているのが、この私だ。

もし、ちゃんとした意味があるという人がいれば、その意味をぜひ教えてください。

最近は「グロースハック」というけれど、本質は10年前から変わってない

いっときPR配信サイトのフィードを購読して、ウェブ業界のあらゆるニュースリリースをウォッチしていた気持ち悪い人は私です。

10年くらい前の話です。

いろんな学びがありましたけど、端的に言えば昨今「グロースハック」と呼ばれてるような手法の重要性に気づきました。

人はウェブページを開いて1秒以内に「自分には関係ない」「理解できない」という意思決定をして去るよなあ、という当時ヤコブ・ニールセン博士が言ってたことを実感したんです。あらゆるニュースリリースを大量に読みまして。

さて、昨今「グロースハック」が流行っております。たいへん結構なのですが、問題は「10年前にウェブ業界がとっくに通り過ぎてきたノウハウ」を、またやりなおしてる感があるんですね。

まずは歴史に学んだ上で、その上に構築していったほうがいいのにね。残念です。

大橋ぜんたろう氏が開発したプロパテンション指数とか、知らんでしょ、最近のグロースハックの人。90年台の話だよ。

「スプラッシュムービー削除したらCVRが2倍に」とかね。ヤコブ・ニールセン博士が「スプラッシュは死ね」的にdisってたのは10年以上前ですよね。

なので「グロースハック」という言葉は新しいけど、10年前に書かれたウェブユーザビリティの本を読んだりするのも有意義だと思うんですよ。当時はウェブユーザビリティという言葉を使ってたけど、いまでいうグロースハック的な話もしてたわけです。

要するに昔は言葉が細かく分かれてなかったのです。だから今日のように言葉が細分化されているのは、たしかに進化です。しかし、それでタコツボ化してはダメでしょうと。

むかしに書かれたものも読みましょう。古典的な奴。

ヤコブ・ニールセンのユーザビリティの本とか、37シグナルズの『ディフェンシブ・ウェブデザインの技術―「うまくいかないとき」に備えたデザイン、「上手に」間違えるためのデザイン』とか。数年前に「EFO(エントリーフォーム最適化)」という言葉も流行ったけど、たしかその前に『ウェブ・フォーム・デザイン』という本も書かれてて、いまだに読む価値ありますし。

おわりに

GMOベンチャーパートナーズGP村松氏のブログ記事『資金が必要なわけではなかった。』で

これまでもベクトルと戦略PRを仕掛けたり、ゼロベースと共同でUXコンサルティングを提供してきたり、設立以来8年間取り組んできた。Andreessen Horowitzよりも前からやっているのだ。今後も、今回の勉強会だけではなく、実際に人を供給したり、事業提携を促進したり、現実の加速支援を行っていきたい。

と書いてあって、その勉強会のレポート記事が『グロースハック最新手法』なのですが、そういうコンテキストで、こんなことを思ったので書いてみました。我々(ゼロベース&GMOベンチャーパートナーズ)は、むかしから、その時々のバズワードとうまく付き合おうとしつつ、単にバズワードに乗っかるのではなく、その奥にある本質を希求してきたのだよなあ、という感慨。

コンテンツやサービスのマネタイズしにくさ

指輪型ウェアラブルデバイス「Ring」がKickstarterでキャンペーン開始、2014年7月出荷予定 | TechCrunch Japan

コンテンツやサービスはマネタイズしにくいのに、未来的ガジェットはマネタイズできるんだなあ、という感慨。

実際に役立つコンテンツやサービスでも、数千円で売ることが難しい。

一方、具体的な用途のよくわからない未来ガジェットが、その可能性への期待だけで、何万円かの値付で売れる。ちょっと触って楽しんだだけで「元をとった」と満足するユーザーも多い。決して数は多くないかもしれないが。

例えばウェブサービスで考えると「数万円を数百人から集めてプロトタイプをローンチ」っていうイメージがわかない。

Ghost: Just a Blogging Platform by John O'Nolan — Kickstarter

これなんかは変化の兆しですね。未来に期待は持てる。

RESTとpermalinkはアプリオリなアーキテクチャを要求するのでは? アジャイルなアーキテクチャと相性悪くない?

RESTとpermalinkってのは、アジャイルアーキテクチャと相性悪い気がしてる。端的にいうと、こういうこと。

ブログサイトで /entries というリソースコレクションを定義した。そのあとでブログ記事以外も扱うようになった。すると /blog/entries という名前に移行したい。でも移行するなら permalink 的とは呼ばないわけで。

ポイントは、こうやって後知恵で考えると「最初から /blog/entries にしとけばよかったのに」となるけど、そのサイトを立ち上げた時点では将来どうなるかわからなかった。それは担当者の能力不足ではなくて、本質的に現実は不確実なので、根本的に予測不可能だ。なので当初 /entries にしたことは、その時点の判断として妥当であっただろう。

言い換えると、RESTとpermalinkの組み合わせは、経験主義的なアジャイルの考え方と相性が悪いのではないかと。

ちなみに、HTTPでリダイレクトしても、あまり意味が無い。たとえばソーシャルプラグイン系が「名寄せ」してくれないので、せっかく集めたアクション(いいね、シェア、ツイート等)がご破算になるので。

このへんって『RESTful Webサービス』で解を提示してくれてましたっけ? むかし読んだのですが。

バズワードで言えば「リーン・スタートアップ」的に、つまりは経験から学ぶという意味での経験主義的に、アーキテクチャアジャイルに変更していく考え方をぼくは採用してます。この立場からは、RESTfulなリソースのpermalinkの定義って、アプリオリな設計を要求してくるように思うんですよね。スムーズ&シームレスにアーキテクチャを変更していけるような手法があれば知りたいなと。

教えて頂けるとありがたいです。