Qiitaのユーザーページリニューアルに感じた違和感の話
2020年3月25日に、プログラミングに関する知識を記録・共有するためのサービスである Qiita のユーザーページがリニューアルされました。
しかし、 Twitter を見ている限りでは好意的に受け入れている人が少なく、 Qiita 自体を退会してしまう人や、データ利用を拒否（オプトアウト）する人も多く見受けられます。
なぜこのようなズレが起こってしまったのか、私が感じた違和感について書いてみたいと思います。
リニューアルの概要とその意図
今回のユーザーページリニューアルについては、以下の運営ブログにその意図も含めて詳しく書かれています。
リニューアルでいくつか機能が追加されていますが、このうち「投稿した記事」「読んだ記事」「LGTMした記事」についていたタグのうち、出現割合がもっとも多かったものから順に5つを表示するという機能、とりわけ「読んだ記事」のタグ表示がかなり物議を醸しているように思います。
Qiita のユーザーページはエンジニアの名刺になるか
上記のブログ記事には、リニューアルの目的として以下のような記載があります。
Qiitaは現在「エンジニアとしてのアイデンティティを確立し、表現ができるプラットフォーム」を目指しています。
今回のユーザーページを用いて、エンジニアとしてのアイデンティティの確立をより行えるようになれれば幸いです。
「エンジニアとしての名刺」のように使っていただけるととても嬉しいです。
エンジニアとしての活動をする中で、確かに Qiita にはよくお世話になっていますし、記事を書いたこともありますが、Qiita でエンジニアとしての自己表現をしようとは考えたことがありませんでした。しかし確かに、個人ブログがエンジニアとしてのアピールポイントになるのであれば、Qiita がそのような役割を担ってもおかしくありません。
エンジニアの活動や嗜好の様子をうかがい知れるものとしては GitHub がよく見られていると思いますが、例えば勤務先が使っているリポジトリが GitHub かそれ以外かで芝の見栄えは全然違いますし、 OSS への取り組みはエンジニアとして大きいポイントですが、取り組んでいないとエンジニア失格というわけではありません。要は、GitHub をあまり使っていないエンジニアにとっては、 Qiita の方が名刺代わりになる可能性は高いと思います。
だとするならば、そこを理解した上でなお残るこの違和感は何でしょうか。
エンジニアの名刺に読んだ記事の情報は必要か
そもそも自分がどのように行動したかという情報は（少なくとも個人的には）そこまで公にしたいものではありません。ではなぜ Qiita ではその一部である記事の傾向を公開するという判断に至ったのか、想像してみたいと思います。
ユーザーページがエンジニアの名刺になるならば、そこに欲しい情報はなんでしょうか。あるいは企業の採用担当者が、エンジニアとしての資質を見る上で知りたい情報はなんでしょうか。
連絡先やアイコン、現在の所属などはもちろんですが、その人がどのような分野に強いのか、また興味を持っているのか、という部分はとても重要になってくると思います。
今回ユーザーページで公開された情報の中で「読んだ記事」という項目はユーザーのハードルが一番低い行動です。 LGTM はそれこそタイトルが残りますし、そもそも記事内容に満足しないと押さないボタンです。ユーザー登録だけして、ストックや LGTM はぼちぼち、くらいのライトユーザーの嗜好をあぶり出すには、ユーザーの閲覧履歴というのはとても貴重な情報源になると思います。
幸いにして (?) 私は多少記事を書き、そこそこ LGTM もしているので見栄えの良い結果になっていて、だからこそ「読んだ記事」に違和感を感じたのだと思います。もしかしたら、逆に「投稿した記事」「LGTMした記事」の傾向だけではどんなエンジニアかわからないようなユーザーがたくさんいたということなのかもしれません。
個人的に考える落とし所
今回のリニューアルはユーザーページの名刺化、あるいは単なるナレッジベースのサイトから変わるための第一歩だったのだと思います。ただ、Qiita の考える理想と今の使用感のギャップが大きかった（ユーザーがついてこれなかった）こと、またその変化のために使ったデータが、あまり公開を前提として考えていなかった閲覧履歴だったことがあまり良くなかったのかなと思います。
例えば、業務で触れている技術のタグや興味のある技術タグをユーザーページで見せる機能を公開し、そのタグの入力サジェストで閲覧データを使ったり、閲覧傾向とタグが乖離してきたら技術タグの編集を勧めるなど、間接的に利用する分には、受け入れてもらいやすかったのではないでしょうか。
直接的に使うにしても、自分自身だけが見れて気づきに使えるツールになるとか、 Qiita Jobs に登録している採用担当の人が参考にできる情報として提供するとか、不特定多数の人に自分の内面が見られるという漠然とした嫌悪感をなくせると良かったように思います。
時期的なものもあるのか、 Twitter での反応もすごくピリピリした文章に見えてしまい、思わず長文を書いてしまいました。今回公開されている情報は統計処理されていて個人情報にはあたらないはずなのに、見せ方一つで受け取る印象が変わってしまうという点は、肝に銘じておきたいところです。
余談: 「読んだ記事」機能と Treasure Data
Qiita では、ユーザーの閲覧履歴を保持・活用するために、Treasure Data というサービスを利用しています。
Treasure Data (TD) はざっくり言うと大規模データ向けのデータベースサービスです。今回のような閲覧履歴やユーザーの行動ログをビッグデータとして保持し、またクエリを使って効率よく抽出・活用をすることができます。
TD へのデータの格納は通常 API 経由で行いますが、 Web 解析用途で利用するブラウザ JavaScript 用の SDK も公開されています。SDK を読み込み、トラッキングメソッドを叩くだけで、ページの情報や JavaScript で取得した各種情報を TD に送信することができるため、非常に便利です。
Qiita ではこの SDK を使って、記事閲覧時にユーザー ID と記事 ID を TD に送信しているようでしたので、おそらくその閲覧データ（直近3ヶ月分）と記事のタグデータをくっつけてごにょごにょして、前述の解析データを生成するようなバッチ処理が回っているのだと思います。
余談ですが、私が（素人目で）読んだ限りだと、ブログに記載されている Treasure Data のオプトアウトに関するリンク先は今回の用途向けではないように思います（おそらく、Treasure Data 自体の Web サイトや企業活動に関する情報の取り扱いに関するポリシー）。
Qiita など企業から送信されたデータの取り扱いに関しては別途ポリシーが存在します（英語）。こちらは企業がユーザー情報を TD に格納・処理する際の、TD としてのポリシー（第三者に渡さないよ、等）が書いてあります。オプトアウトについては「情報の開示や変更は企業名（Qiita や Increments 社）を添えてメールアドレスまで連絡してね、企業と協力して対応するよ」と書いてあります。格納されたデータを安全に保管し続けるのが TD の役割であり、データを活用したり、また削除したりするのは企業の責任ですから、Qiita 側で機能を用意するのがあるべき姿だと思います。
なお、 JavaScript SDK にはオプトアウト用に「今後（多分そのブラウザからは）一切 TD にイベントを送信しない」というメソッドが存在します。TD を使っていて、データ活用の拒否を選択できるサービスを提供している場合はぜひ活用しましょう。
この記事が気に入ったらサポートをしてみませんか？