エンジニアリングのダークパターン

はじめに

デザインのダークサイドという表現をついこの間耳にしました。

意図的に誰かを騙して害を与える一方、別の誰かに利益をもたらしている。

こういった現象をデザイナーはデザインのダークパターンと呼びます。
いわゆるテックプロダクトのようなアンテナで、ユーザーをネガティブな選択肢へとそそのかしている現象をデザインしたもののことを表しています。

エンジニアリングでもこのダークパターンは当てはまると思い、どういったことがダークパターンなのかを考えてみようと思いました。

自動化、自動売買、自動トレードなど様々なタスクが自動化に移行されていく中で、自動化に貢献しているエンジニアでもダークパターンを活用しているものが少なからずもいるといった事実に気づきました。

私自身も、ユーザーをネガティブな方向へ導く設計を無意識に結果としてしてしまったこともあります。
今は改善してサービス提供をしていますが、当時は技術の未熟さ故にそういった現象が発生してしまうことが多々ありました。

自動化といった魅力的な言葉は、自動扉からすでに始まっています。だって、楽だもの。といった理由から自動化といった言葉はいつの時代も魅力を発揮しています。

しかし、実際に現時点でそのタスクを自動化することはできるのか？といった疑問と懐疑心は常に持ち続ける必要があります。

ダークパターンを使うと、ビジネスが反映する＝プロダクトを使ってユーザーをネガティブな方向へ持っていけばマネタイズがしやすい、といった場面も多々現れてきます。

例えば、情報は収集しませんといったUXデザインを施したプロダクトやスクリプトに実は収集できるトリガーが潜んでいて、そのトリガーを起動するキーや権限を与えることによって、マネタイズされるのであればそれは典型的なダークパターンですよね。

エンジニアがそういったレイアウトやシステムを構築することによりそういったダークパターンを再現することも出来ます。
実際私自身も考えてみれば様々なパターンを考えられますし、実際実装しようかと思うレベルでマネタイズは良いです。

しかし、そこに正義はあるのか？といった問いをした上で、社会貢献活動ではない場合はおすすめはしません。
一歩間違えれば犯罪になってしまう可能性も無きにしもあらずです。

ホワイトパターンって当たり前が一番難しいと同じでとても難しい実装だと考えています。

ホワイトパターンをテンプレート化していくと限られてくる部分が増加するからです。
グレーな部分をどうホワイトに持っていくかよりも、ホワイトな部分をどうやって広げるかを考えたほうが良いよね、って話だと考えています。

ダーク、グレー、ホワイトどれも染めていけばすべて黒になります。
ホワイトな部分をどれだけ増やしていくかを考えられるように日々脳みそも鍛えていきたいですね。