2010年6月アーカイブ

Twitterの連携アプリを「許可する」ボタンのリスク

| コメント(0) | トラックバック(0) |

TwitterのDM(ダイレクト・メッセージ)機能はメールよりも気軽で便利な連絡手段です。ただし、気をつけてください。DMが盗み見られる可能性は、おそらくあなたが考えている以上です。あなたが技術者のようにTwitterの仕様を理解しているのでもなければ。

〔注:本稿はなるべく多くの人に読んで頂けるように、易しく書きました。このように「注」欄で詳しい説明を書いていますが、詳しく知りたい人向けですので、読み飛ばして頂いても構いません〕

「DMで大事な話をすることがある」というツイートを見かけたのが、本稿を書くきっかけになりました。DMの危険性を指摘しなければなりません。リスクを知った上で賢く使って頂くために。

本記事は具体的にああしろこうしろという指図はしません。考える材料を提供するだけです。「リスクがある前提での賢い使い方とは何か」を自分で考えたいという方のために書きました。

Twitterクライアント・アプリの開発者にDMが盗み見られる可能性

Twitterクライアント・アプリはご存知でしょう。すでにご利用かもしれませんね。ブラウザでtwitter.comにアクセスするより、Twitterクライアント・アプリからTwitterを利用するほうが便利だと感じる人は多いでしょう。Windows, Mac, iPhone, Android, 携帯電話のアプリやモバツイなど、様々な形態の「Twitterクライアント・アプリ」があります。

Twitterクライアント・アプリの大半にはDM送受信機能があります。原理的には(「仕組み上は」という意味)アプリ開発者が利用者のDMを盗み見ることは簡単です。倫理的にはそうしないはずですが。これだけ沢山のアプリがあり、その開発者がいるということは、一人くらい悪い奴はいるものです。そういうリスクがあります。

一つ注意すべきことがあります。あなたがSteelDMというTwitterクライアント・アプリ〔注:架空の例〕を使うと、SteelDMの開発者は、あなたのDMを盗み見ることが(原理的には)可能になります。どのアプリ(twitter.comも含む)で送受信したDMであるかは関係ありません。例えば「軽い気持ちでインストールしてみたけれど、一度使っただけで、すぐに削除した」といった場合でも、そのたった一度の使用時に、それ以前のDMまで遡って盗まれる可能性があります。

安心と信頼

通信の秘密は、倫理的・法的には守られていますが、原理的・技術的に守られているとは限りません。Twitterクライアント・アプリ利用者の通信の秘密は守られていません。アプリ開発者が悪意を持っていれば、あなたの通信は容易に盗み見られます。

Twitterクライアント・アプリの開発者は、無名ながら才能溢れる個人だったりするわけですが、見方を変えれば、どこの馬の骨とも分からない個人だったりします。素性が分からなければ、悪人かもしれません。何も考えずに安心して利用するのは無防備です。自分の判断で信頼できるアプリを利用してください。みんなが使っている、というのも一つの判断基準ではあるでしょう。

あなたはTwitterクライアント・アプリ開発者がダイレクト・メッセージを盗み見たりしないと信頼してアプリを利用しているでしょうか。もしあなたが信頼の必要性に無自覚だったなら、いま使っているアプリの開発者が信頼に足るかどうか、考えてみてはいかがでしょうか。

Twitterクライアント・アプリを利用するなら、安心はできません。自分なりの利用ルールを作るのもよいでしょう。例えば、「TwitterのDMでやりとりする情報は、Twitterクライアント・アプリ開発者に知られてもいい情報だけにする」といった具合に。

「安心」と「信頼」は山岸氏の研究でキーとなる概念で、「安心」は、道ゆく人が社会から暗黙の規制を受けていると思うことで、「信頼」とは、規制されてなくても人間というものは普通悪いことはしないと思うこと。

安心社会から信頼社会への移行をグーグルが強制している - アンカテ

ここまでは易しい話でした。次の話に比べれば、直感的に分かる程度の易しさです。次は少しややこしくなります。なるべく易しく説明します。

Twitterの連携アプリ

あなたのTwitterアカウントにアクセスするアプリケーション(連携アプリ)は、Twitterクライアント・アプリだけではありません。様々なアプリケーションが、あなたのアカウントにアクセスします。例えば、Twitterのつぶやきをブログ形式で保存してくれるTwilogや、誰でも簡単に診断ゲームを作れるツイッター診断メーカーなどの「連携アプリ」です。

これらの連携アプリがあなたのTwitterアカウントにアクセスするためには、もちろんあなたの許可が必要です。あなたがこれまでに許可した連携アプリはtwitter.com上の「連携アプリ」という画面で確認できます(設定メニューの中にあります)。下の写真は連携を許可するための確認画面です。見覚えがありませんか?

TwitterOAuthScreen.png

〔注:上図は架空の例です〕

アプリに連携を許可すると、一体どうなるのでしょうか。簡単に言えば「自分のTwitterのパスワードを渡したようなもの」です。あなたがTwitterに関して出来るほとんどすべての操作は、連携アプリにも出来るようになります。Twitterに関する、ほとんどすべての権限をアプリに与えたことになります。

〔注:詳しく言えば、許可にも2つのモードがあります。「読むだけ(read-only)」と「読み書き両方(read/write)」の2つです。「読むだけ(read-only)」の許可ではwrite操作ができません。write操作とは、ツイートしたり、DMを送信したり、フォローしたり、といった何らかの状態変更を伴う(twitterのサーバーに何かを書き込む=writeする)操作のことです。そのようなwrite操作を実行できないのが「読むだけ(read-only)」の許可です。一方、「読み書き両方(read/write)」の許可は、まさしくパスワードを渡したような全権委譲です。本稿ではDMを盗み見られるリスクについて考えていますから、「読むだけ(read-only)」の許可で十分です。モードに関係なく、連携アプリを許可することには、DMを盗み見られるリスクがあります〕

連携アプリも原理的にはあなたのすべてのDMを盗み見ることができます。先のSteelDMという架空のアプリで説明したのと同様です。

連携アプリのリスク

架空のシナリオです。想像しながら読んでください:あなたの友人が「コーラ占い」の診断結果をツイートしたのを見ました。そのツイートには診断用のURLが記載されていました。あなたもそれにアクセスして診断ボタンを押します。すると、下の写真のような確認画面が出てきました。

TwitterOAuthScreen.png

何かゴチャゴチャよくわからないことが書いてあります。面倒くさいので、よく考えずに「許可する」ボタンを押しました。すぐに診断結果が表示されます。あなたはその診断結果を面白いと思ったので「ツイートする」というボタンを押しました。すると、定型文にURLがついたツイートが、あなたのツイートとして送信されました。さきほどあなたが見た友人ツイートと同様のものです。

さて、このシナリオについて考察してみましょう。この架空の占いサイトは「連携アプリ」です。あなたも過去にこういう行動をしたことがあるかもしれませんね。

ここで新事実をお伝えします。この連携アプリの開発者は、悪意を持ってあなたのDMを盗み見ていました。しかし、あなたはそれに気付くことができません。あなたには見えないとこで盗み見ているからです。なんの記録も残りません。ですから、疑ったところで、確かめる方法はありません。これが連携アプリの怖さです。

危険に見えない危険

本稿の前半ではTwitterクライアント・アプリの開発者にDMを盗み見られるリスクについて考えました。それは直感的で分かりやすい話だったでしょう。しかし、連携アプリにDMを盗み見られるリスクは直感的に理解できますか? おそらく多くの人にとって反直感的だろうと思います。

「許可する」ボタンは非常に危険です。ヤバいボタンです。このように危険なボタンが、危険に見えない。このこと自体が危険です。〈危険に見えない危険なもの〉ほど危険なものはありません。

Twitter社がアプリ連携の確認画面を改良し、危険が分かるようにしてくれれば解決する問題です。しかし、それまでは利用者自身が気をつけるしかありません。

おわりに

悪い開発者がいるリスクは無視できない。連携アプリを作るのは簡単で、敷居が低い。しかも、ほとんどの利用者は危険を意識していない。悪い奴にとって格好のターゲットです。

本稿はみだりに危機感を煽る目的で書いたのではありません。Twitterクライアント・アプリ開発者の多くは、おそらくは善良な人々であって、あなたのDMを盗み見る目的でアプリを作っているわけではないと信じたいものです。

本稿はあなたに「リスクがあるから避けろ」とは言いません。そこは誤解しないで頂きたい。本稿はリスクを理解した上で、積極的に活用するための知識を身に付ける前提となる考える材料を提供するために書きました。

冒頭に書いたように、具体的にああしろこうしろと指図するつもりはありません。考える材料は提供しましたので、あとはご自身で考えてください。ぜひ考えたことを共有して頂ければと思います。(私だけでなく他の読者の方のためにも)

とはいえ、具体的な方針の例さえ示さないのは不親切だと思いましたので、あくまで「一つの例」として参考にして頂く前提で:「盗み見られても問題ないように気をつけてDMを使う」という方針なら、積極的に連携アプリを活用してもリスクは小さいでしょう。これが普遍的で、誰にとっても良い方針だ、などとは言いません。あくまで「一つの例」です。考える材料にしてください。

本稿はTwitterに関して一部のリスクを取り上げた記事です。ただ、このようなリスクはどのような情報通信技術にも存在します。それは本稿の範囲を超えますので別の機会に論じたいと思いますが、一つだけ強調しておきたいことがあります。リスクは悪ではありません。リスクを避けるか、リスクを取るか、あなた自身が判断することです。情報通信技術を賢く活用するために、リスクと賢くつきあってください。私の考えでは、「取れる範囲のリスクを取って、積極的に活用する」ことが、リスクとの賢い付き合い方です。

専門的な余談

〈危険に見えない危険なもの〉は警戒されず、不用意に扱われ、事故になる。物体の世界よりも情報通信の世界で起こりやすい。情報通信技術におけるアフォーダンスとデザイン。不可視な危険性の可視化。悪玉ユーザーエクスペリエンスとアーキテクチャ支配の不可視性に通じます。

創造のプロセス:建前と実際

| コメント(0) | トラックバック(0) |

デザイン思考の仕事の進め方(デザイン・プロセス)は、デザイナーがクライアントへ提案する資料や、公の場でのスピーチ、書籍などで語る「建前」と、その「実際」とでは大きく異なります。

建前(公式の説明):

201006231615.jpg

実際(実感):

201006231628.jpg

via the design process: official versus how it feels

創造の過程には混乱が伴います。ビジネス・エリートの中には、プロセスの混乱を恐れ、整然とした予定調和のプロセスを好む人もいます。しかし、そういう安心の外に出なければ、創造的な仕事は難しい。分からないことを恐れず、予定調和の外に出ましょう。

生産性(productivity)の時代に形成された仕事の流儀は、創造性(creativity)の領域でそのまま通用するとは限りません。創造に携わる人は、身に付けた仕事の方法を脱学習(unlearn; 学びの自己批判)し、創造のための仕事術を学び直す必要があるかもしれません。

電子書籍の「ページをめくるという時代錯誤」

| コメント(0) | トラックバック(0) |

電子書籍を作るなら、電子メディアのための書籍をデザインしたいものです。紙の書籍を模した、名ばかりの電子書籍が多い。残念だと思いませんか?

 私自身iPadを使ってみて気づいたのだが、新聞や雑誌を読むのに気の利いたアプリケーションなど必要ない。画面が小さいiPhoneの場合は、アプリで利便性が格段に高まる。だがiPadの画面は十分大きくて明るい。ネットへの接続環境さえ良好なら、どんな出版物もアップルのブラウザ「サファリ」で読むのが一番だろう。

 バニティ・フェアやタイムのiPad向け電子雑誌は、ページをめくるという時代錯誤を復活させようとしているだけだ。

iPadは新聞も雑誌も救わない | ニューズウィーク日本版

ページをめくる

「ページをめくる」という行為について考えてみましょう。

下の3枚の写真は、ページめくり中の写真です。8-9ページの見開きをめくって、次の10-11ページに移る過程です。紙の本では、見開きの左側(下の写真では9ページ目)の最終行と、次ページの最初行が、同時に視野に入りません。ですが、その2つの行は連続しています。本来は、同時に視野に入るほうが望ましいでしょう。

FlippingPage-1.jpg

FlippingPage-2.jpg

FlippingPage-3.jpg

ページをまたぐ長文を理解するために、何度も右へ左へとめくり直した経験はありませんか? この不自由は、両面印刷という紙メディアの制約によるものです。ある文字を境として、連続した文章が、紙の表と裏に分断されているからです。

「ページをめくる」という行為には、改善の余地があるのではないでしょうか。紙メディアの制約とは関係がない電子メディアで、なぜ「ページをめくる」ような設計をするのでしょうか? 妥当な理由があるのかもしれません。しかし、とくに無いのであれば、よりよい設計を模索することもできます。

ページを滑らせる

例えば、GoodReader for iPadのDouble-Pageビューは示唆的な例です。ページをめくるのではなく、滑らせます(スライド操作)。下の3枚の写真は、ページを滑らせている最中のスクリーンショットです。8-9ページの見開きを右に滑らせて、次の10-11ページに移る過程です。

GoodReaderForIPadDoublePage-1.PNG

GoodReaderForIPadDoublePage-2.PNG

GoodReaderForIPadDoublePage-3.PNG

〔注:滑らせるにも二通りの方法があります。フリック(はじく)なら一瞬でスライドが完了します。ドラッグ(ひきずる)なら自分の指で制御できますから、時間をかけてゆっくり滑らせることもできます。本稿の考察ではドラッグ操作を前提にしています〕

GoodReader for iPadのDouble-Pageビューにおいては、ページ移動の際に、前ページ最終行と次ページ最初行の両方が同時に視野に入ります。読みが途切れず、ページをまたいで連続的に読み続けることができます。

〔注:横書きの書籍なら(後述のように)縦スクロールで読むのが適していると考えます〕

ページにより視野が分断されないのは、まるで巻物のようです。もちろん縦書きと相性が良い。千年前から日本人は知っていたというわけです。さて、現代の日本人として、電子媒体で縦書きをどう読むか、考えたいですね。西欧人頼みや、無批判な輸入ではなく。

内容(コンテンツ)に適したインタフェイス設計

GoodReader for iPadのDouble-Pageビューは、紙メディアと電子メディアの違いを考えるための一例です。このような設計が無条件に良いという主張ではありません。適材適所です。本稿では「紙メディアに縛られない発想で電子書籍をデザインすること」についての示唆が得られる例として紹介しました。

本稿の「縦書きの書籍を電子化した場合、ページをめくるよりも、滑らせるほうが読みやすい可能性がある」という考察は、文章主体の書籍を前提としています。見開きで図版のように見せる雑誌には該当しません。文章主体だからページによる分断が問題になるのであって、ページ毎に独立した図版にとって「ページによる分断」という問題はありません。

インタフェイスの設計は適材適所です。コンテンツを「どう読んで欲しいか」というユーザー体験デザインありきの適材適所です。

書籍概念の解体

ここまでは書籍の電子化を想定した考察でした。それに対して、最初から電子媒体で読まれることを想定して書かれた電子書籍もあります。以下は、それについての考察です。

最初から電子媒体を想定した文章は、ページに割り付けられている必要がありません。ページという概念が不要です。ページのない文章を連続的に滑らせて読む行為は、(冒頭の論者が挙げたように)Safariブラウザでウェブページを読む行為に近い。〔注:もちろん、縦書き文章を横に滑らせるのではなく、横書き文章を縦にスクロールして読むという行為を指しています〕

果たしてそのようなものを「書籍」と呼ぶかどうか。

 今日の若い世代、つまり未来の一般的消費者はケータイで新聞記事や小説を読むのになんのためらいもない。同様に今からそう遠くない未来にすべての書籍が電子化されたあとに生まれてくる子供たちは、紙がめくれるようなインターフェースに何の価値も認めないだろう。テキスト中心の知的生産物が電子書籍という形を取る必然性をまったく感じなくなるだろう。電子書籍のファイル形式のe-pubである必要はない。ウェブの表示言語であるHTMLでよくなる。電子書籍はウェブに同化する運命にあるのだ。

電子書籍は紙へのノスタルジア=いずれウェブに同化する【湯川】 : TechWave

ページという単位に縛られない横書き文章として、すでにウェブページがあります。そのための技術として、HTMLとブラウザがあります。すでに利用できるそれらの発展において「電子書籍」が意識されるかどうかはともかく、結果的に「電子書籍」に引導を渡す存在に発展する可能性はあるでしょう。実際にそうなるかどうかはともかく、あり得るシナリオの一つとしては。

関連記事:

いつユーザー体験を設計するか

| コメント(0) | トラックバック(0) |

グーグルはAndroidに「ユーザー体験デザイン(UXD)」を追加開発するようです。機能の開発が終わったあとで、スパイスをふりかけるように。

これまで追求してきた重要な機能に関してはそろそろ一段落した、というのが、チームの今の認識だ、と情報筋は言っている。もちろん、細部の練り上げ磨き上げは今後も続くが。今Googleが求めているのは、携帯電話のメーカーやキャリアが独自のUI...Sense、Motoblur、Ninjablurなどなど...を加えるのをやめさせたいということ。

それらは、シェルのできが良くないし(HTC EVOを見よ)、それにデバイスをのろくしている場合が多い。

Googleは、そういう傾向にストップをかけるために、次のGingerbreadではユーザ体験に開発努力の多くを傾注する。Android体験をiPhoneに近いものにしたい、と彼らは考えている。

今後のAndroidはユーザ体験の向上にひたすら注力-機能面は一段落したので

201006192327.jpg

グーグルがAndroidを作るのに採用した方法(プロセス)では、システム開発の下流工程(GUI設計作業など)に「ユーザー体験の向上」という作業が含まれているのかもしれません。このプロセスでも、好ましいユーザー体験を実現できるのかもしれませんが、茨の道です。

ユーザー体験デザインはシステム開発に先立つ

もっといい方法があります。上流工程にユーザー体験デザインを位置づけることです:ユーザー体験を機能に先立って考えます。理想的なユーザー体験シナリオを描き、そこに現れるユースケース(システムの使われ方)を洗い出し、それを機能要件に整理することで、システム開発の機能要件を定めます。デザインの成果として機能要件を規定します。

リリース後の改善

ユーザー体験に焦点を合わせた開発プロセスを採用しても、好ましくない結果になることはあります。製品のリリース後に、実際のユーザー行動が予期せぬものになるといったように。

最初からユーザー体験に焦点を合わせていれば、理想と現実のギャップを特定しやすく、それゆえ問題解決も比較的容易です。なお、そのような「実際のユーザー行動にもとづく修正」を正式リリース前に行うために「プロトタイピング」という手法があります。現実のユーザー行動によって直接に検証することで、ユーザー体験デザインの精度を高めるわけです。

ユーザー体験デザイン不在の開発チーム

これに対し、好ましいユーザー体験を事前に考えていなかった場合は、そもそも何が問題なのかを特定するだけでも大変です。問題解決の前に、問題設定について、開発チームの意見が一致しない可能性があります。

リリース後にユーザー体験上の問題が発覚し、開発チームで議論して、そこで初めて認識のズレが明らかになる。じつは個々のメンバーがバラバラのユーザー体験(製品)を思い描いて開発していたというズレ。これを修復するには、実装済み機能の仕様変更や、ロードマップの変更などといった手戻りが発生します。

このような手戻りは、最初からユーザー体験デザインによって機能要件を定めていれば、ずいぶん少なくなるでしょう。

201006192337.jpg

ユーザー体験デザインをとりまく周辺事情

ユーザー体験デザインにはコストがかかります。アップルはiPhoneの開発に数年間(たしか4年ほど)かけたといいます。ハードウェアとOSと主要なアプリケーションをあわせて開発すれば、年単位の時間がかかってしまっても不思議はない。

〔注:とはいえ、ユーザー体験デザインが結果として時間の節約になるような方法を私は提案しますので、クライアントには安心して頂きたく。ユーザー体験デザインはタダではないけれど、それがシステム開発投資のムダを省く点で、けっこう相殺します〕

グーグルはiPhoneへ対抗するためにAndroidのリリースを急いだのでしょう。本稿ではそういった事業戦略全体については論じません。ユーザー体験デザインを後回しにしたツケを払うという過程に限定して、製品開発論の観点で考えました。

201006192339.jpg

まとめ

ユーザー体験デザインは、システム開発の下流工程ではなく、システム開発に先立つ上流工程に位置づけるほうが好ましい。ただし、それを可能にする経営判断、経営環境あってこそ。

関連記事:

UXDとアジャイルを融合させるハイブリッド人材

| コメント(0) | トラックバック(0) |

Adaptive Path Blogの紹介です:ユーザー体験デザイン(UXD)とアジャイルシステム開発には共通点が多い。この接近に関係しているのは、従来の「エンジニア」「デザイナー」という肩書きにとらわれない職能のハイブリッド人材が増えてきたことだ。ハイブリッド人材は、分業を前提とした方法にとらわれる必要がなく、UXDとアジャイルを自分の中で融合させる。

英語の原文はこちら:UX Design Agility


waterfall-20100616-085640.png

このアーカイブについて

このページには、2010年6月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2010年5月です。

次のアーカイブは2010年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。