1.今日のテーマ
先日、UIのダークパターンについてのガイドライン、Dark patterns in social media platform interfaces（以下、本ガイドライン）が公表されてpublic consultationに付されました。
ダークパターンという言葉、最近たまに目にするようになりましたが皆さんご存じでしょうか。読んでみたところ結構面白かったので記事にまとめます。なお”in social media platform"となっていますが、SNSに限らずおよそwebのUI一般で参考になると感じました。
2.ダークパターンとは
(1)定義
世の中的には「ユーザーに害なす、UIのべからず集」みたいな意味で用いられることが多いですかね。本ガイドラインでは以下のように定義されています。
In the context of these Guidelines, “dark patterns” are considered as interfaces and user experiences implemented on social media platforms that lead users into making unintended, unwilling and potentially harmful decisions regarding the processing of their personal data.
(2)使い道
適法/違法のレベルで問題があれば法務が指摘をすると思うのですが、妥当/不当のレベルだと責任を持つ部署がはっきりしません。「リスク」としての具体化も（中の人に知見が無かったり、テーマとしての成熟度が低かったりして）不十分だったりすると、どうしても各人の倫理観に任されがちですよね。
（本ガイドラインの本来のスコープである）GDPRでは本ガイドラインの制定でもってダークパターンの話も適法/違法の問題になるのだと思いますが、日本にいる我々は本ガイドラインを妥当/不当の判断に用いる参考資料として使えそうです。法務とデザイナーとのコミュニケーションにおいても、一定の基準があるとやはり納得感が増しますよね。
3.本ガイドラインの概要
本ガイドラインでは、ダークパターンを大きく以下の6つに分類しています。
なお（）の中は、私が普段出会う実例を思い浮かべながら書いてみた簡単な解説です。正確な定義は原文を参照ください。
- Overloading（情報量で圧倒してユーザーを不適切な判断に誘導するパターン）
- Skipping（見落としを誘ってこっそり同意や提示義務を履行するパターン）
- Stirring（デザインの力で強引に特定の選択を誘導するパターン）
- Hindering（本来必要な情報へのアクセスを妨害するパターン）
- Fickle（一貫性のないUIでユーザーの誤解を誘うパターン）
- Left in the dark（Hinderingとほぼ同じかな…こっちはより「そんなのどうしたら良いんだ」っていうユーザーの声が聞こえてきそうなパターン）
そして、social media platformのライフサイクルを以下の5つに分けて、それぞれのフェーズでありがちなUIのダークパターンを説明してくれています。
- Opening a social media account（利用開始時）
- Staying informed on social media（利用中1）
- Staying protected on social media（利用中2）
- Staying right on social media: Data subject rights（利用中3）
- So long and farewell: leaving a social media account（利用終了時）
4.本ガイドラインの感想
本ガイドラインの記載について、気になった部分・面白かった部分について引用しながらコメントします。この章はやや細かい＆長いのでガイドライン未読の方は読み飛ばして「5.まとめ」に飛んでいただいても大丈夫です。
------------------------
2.2 Transparency（P.9）
GDPRでは、以下の通りユーザー（データ主体）への透明性が法的な義務として規定されています。
他方、日本だとこの辺りはまだまだnice to have的に扱われることも多いし、この観点で提案をすると「意識高いね笑」的な態度をとる人も多いですよね。しかし「ユーザーとの間に信頼関係を構築して、どれだけ意味のあるデータを引き出せるか」がより重要になっていることを踏まえると、
- 違法でないなら、と毎回ギリギリを狙う方法
- 自社の基準に基づいて、ユーザーとの間で一貫した関係構築を狙う方法
のどちらがより攻めたスマートな方法なのかは考えてみても良い気がします。
i. Consent provided at the sign-up process stage（P.12）
サービス利用登録時に求められる同意についての話です。
「お知らせメールを受信しますか」のチェックボックスにことごとくデフォルトでチェックを入れてくる（チェックを外しても、次のページでまたチェックボックス出てきたりして）という企業態度に嫌気がさして、そのサービスの使用頻度下げるようなことは自分でもよくあります。
GDPRでは個人データの取り扱い根拠を明確にすることが求められています（第6条）。取り扱い根拠を同意にすることも可能ですが、同意が適法であると判断されるためのルールはそれなりに厳しく、詳しいガイドラインも出ています。
日本だと個人情報保護法上この辺りが明確になっている訳ではありませんが、電気通信事業法上の通秘同意についてはかなりこれを意識したような攻めたガイドラインが出されています。
直近の個人情報保護法改正においても、
- なかなか荒っぽい再同意取得
- 従前から同意をとっていたが、それを明確化しただけだから再同意は取得しない
みたいな「赤信号 みんなで渡れば…」的事例がかなりみられましたよね。そろそろこの同意についてのフィクションに白々しく乗っかるのは辞めて、「同意とは何で、何のためにするものなのか」の議論をした方がいいと思っています。
Skipping – Deceptive snugness （P.19）
- 全体公開
- 友達にのみ公開
- 非公開
みたいにユーザーが複数の選択をできる場合に、デフォルトで設定する選択肢をどこにするかという話です。同じようなことは、位置情報の取得なんかでも問題になりましたかね。アプリがバックグラウンドにいても位置情報を取得し続けていたりとかで。
ここは「企業側の利害」と「ユーザーの利害」が真正面から対立しうる所なので、企業としてはなかなか抗い難い所だし、まさに企業態度が試される所だよなと思います。
Example 11（P.21）
ユーザーのデータ保護に関して記載された情報は、再度アクセスできるようにしておきましょう、検索でヒットするようにしておきましょうみたいな話です。
類似の事例として思いつくのは、インシデント発生時のお知らせや謝罪を、画像形式にして検索に引っかからないようにしたり、一時的にしか表示されない場所に掲載したりする話があります。
この辺りも企業態度が試されていると思っています。表から見える所でさえそのような行動をとる企業に、自分の機微なデータを安心して渡すことができるでしょうか。
d. Best practices - Change spotting and comparison（P.22）
規約のサイレント修正はやめましょうという話です。
ここで記載されている通り旧ver.にアクセスできるようにしておくことも一つの方法ですし（外国ではこれが法的な義務の国もあります…韓国だったかな）、少なくとも新旧対応表は用意しておきたいところ。
そういえば以前、企業法務マンサバイバルさんがどこかの企業の旧版の規約を保持していて、独自に新旧比較をした記事があった記憶がありますね。見ている人は見ているということで。
Use case 2a: A layered privacy notice（P.23）
プライバシーの教科書的な本では、以前から「プライバシーポリシーはサマリ表示（layered）をしまょう」といったことが言われており、最近では日本の官公庁が出すガイドラインでもよく言及されるようになりました。
本ガイドラインではlayered noticeを（外部的な）透明性の問題と捉えていて、「もはやnoticeはベタ書きではユーザーは理解できない」と考えていそうで面白いです。
internal transparency is the requirement to keep a record of processing activities under Article 30 GDPR. For external transparency, social media providers can provide a layered privacy notice to users,
本ガイドラインではこの辺りのお作法について、それなりに具体的に言及されているのでlayered noticeについて検討したい方には参考になると思います。
Fickle – Lacking Hierarchy（P.24）
適用される規約類が複数ある場合には、並列的に適用される場合、重畳的に適用される場合があります。この全体像がちゃんとわかるようにしましょうというやつですね。
- ユーザー全体に適用される規約
- 特定のプロダクトのユーザーに適用される規約
なんかが入り乱れていると、ユーザーはもとより内部の人でも十分に整理しきれいないこともあります。この辺りは規約の制定までに各所の利害調整が絡んでいたりするので、本当に頭の痛い所です。
Skipping – Look over there（P.32）
インシデント発生時に、被害を実際よりも少なく申告してしまう様なケースです。
もっとも、自分の印象ではこれは意図的というより「ある時点ではその程度の被害だと認識しており先走って発表してしまったが、その後より深刻な被害だと分かった」様なケースも多い印象があります。
責任者レベルとしてはどうしても「XXXは無かった」みたいなことを発表したがる傾向がありますが、それは後々覆らないのか、言い切ることができる話なのかには常に敏感でいたいものです。法律上の個人情報の定義の誤解から「個人情報は漏洩していなかった」と言ってしまうのはよくある凡ミスなので絶対に回避したいところですよね。
Hindering – Misleading information（P.34）
記事を読ませるようなサイトに設置された広告で、「続きを読む」から何も関係ない外部サイトへ飛ばす様なやつですよね。意図的で本当ダメだと思います。
Example 36
位置情報などについて、ユーザーが同意を撤回したら新規の情報取得を止めるのは当然なのですが。
- 取得済みの位置情報利用をいつまでに止めるか、あるいはやめないのか
- 2次精製データの利用はどうするか
はなかなかに難しい問題ですよね。利用を継続する部分があるのであれば、そこは小さな脚注で開示するのではなく、きちんと理解できるようにユーザーに表示したいものです。
------------------------
5.まとめ 〜あるべき分担？〜
本ガイドラインを踏まえて…という訳ではないのですが、ちょうど先日「デザイナー」と「法務・セキュリティ」との役割分担・関係性について
- 私の上司
- 社内で最も信用しているPdM
- 社内で最も信用している法務
- わたし
で議論した内容が面白かったので共有します。
(1)議論テーマ
以下のどちらが良いのか*1
- 【方向性1】
ユーザー目線だけを貫いて全力でUI/UXを検討し、致命的なリスクについてはリーガルやセキュリティで捕る - 【方向性2】
UI/UXを検討する人もいくばくかはリーガルセキュリティに関する感度を持つ
(2)議論内容
- 結局、良いものができるのは【方向性1】じゃないかというのは多くの人が感覚的に持っている答え
- 企画者としてリスクを考慮しながら作るとやっぱりクリエイティビティの高いものは生まれにくい
- 何も知らない新卒とかのほうが柔らかい頭で面白い企画を考えたりできるが、 周りにメタメタに叩かれたりぶん殴られながら経験を積んでリスクを考慮するようになり、おとなしめの企画をそつなくこなす大人な企画者が誕生する
- 一方で、【方向性1】は「組織の規模」や「組織への（社会からの）期待」が一定のレベルを超えると回らなくなってくる
- 法律やセキュリティの知識とそれに反する冒険心や怒られてもめげないドM力のバランスが大事なのでは
(3)現時点の答え
現時点で明確な答えが出ている訳では全然ないのですが
- 【方向性1】
ユーザー目線だけを貫いて全力でUI/UXを検討し、致命的なリスクについてはリーガルやセキュリティで捕る
の太字下線部分さえ担保できているんであれば、もうこちらとしては全力を尽くし、落ちた部分はリスク受容の対価と考えるのが良いのかな。。。なんて考えています。
双方の関係性的にも「お互い全力を尽くしつつも、相手の専門性を尊重・信頼しながらバチバチやる」というのが健全な気がしますしね。
*1:程度問題だ、という大人の立場から発言しないのが議論を面白くするコツだと思っています。
