【技術記事】Zennでひたすら記事を読みまくっていいねを付ける検証をしたのでその報告と、気が付いたことを自分なりにまとめてみるテスト
はじめに
対象
- Zennで技術記事を書いているけど、集客の宛てがない方向け。
検証内容
記事を読んでいいねを付ける
週4日稼働の午前中、1日50ユーザー前後を目安に記事を物色、大丈夫そうな記事ならいいねを付けて次のユーザーへGoという活動を行っておりました。
具体的な方法は以下の通りです。
- 新着の記事一覧を表示する。
- ユーザーのページに飛ぶ。
- 読めそうな記事・興味のある記事を探して読む。
- 大丈夫そうなら、いいねを付ける。
- これを50ユーザー分繰り返す。
- 頑張れる日・気分が乗った日は多めに付ける。
所要時間はその日の記事の長さにもよりますが、かかるときは4時間かかることもありました。1記事あたりの平均を5分と考えても、そのくらいが目安になるかと。
人力故致し方なしという言い訳
ここからスーパー言い訳タイムです。偉そうに以下の記事を書きました。
しかし当方も人間、沢山記事を読んでいるうちに短めの記事を見つけて「今日は早く終われるかもしれない」という本末転倒な喜びを得たり。またあるときはすっっっごく悩んだ上で、大丈夫なことを信じていいねを付けたり。最初のうちはAIが書いた記事なのか判別付かないこともあり。
あと数学の記事は最初は頑張ってましたが、やはり読むのに時間がかかるのでブクマといいねしております。なんか凄いことやってるのは分かるし、記事をKaTeXを駆使して書いてるし、こんな記事が書けるのすげえぇぇってことだけは。はい、精進します。
また週4稼働なので休日明けは確認が追いつかないことがあります。なので休日初日（主に土曜日）に投稿された方なんかは、そもそも閲覧するところまで辿り着いてないかもしれません。
いいねを付ける対象や基準に、多少なりともバラつきがあることをどうかお許しください。
具体的な識別方法
いいねを付けたユーザーのリンクの色を変更してマーキングします。一見さんや常連さんに昇格したら、また別の色でマーキングすると見やすいです。
/* 最終確認日 2025/10/31 */
[href="/noranuko13"] {
color: green !important;
font-weight: bold;
}
また少々厳しそうなユーザーさんについては誠に心苦しいのですが、記事一覧に表示されるアイテムの影を薄くさせていただきました。
/* 最終確認日 2025/10/31 */
article[class^="ArticleListItem_container"]:has([href="/noranuko13"])
{
opacity: 0.1;
}
あとはひたすらマークしていないユーザーのところにお邪魔して、記事を読みまくることを繰り返すだけです。
いいね・フォロー件数の集計方法
少々お行儀が悪いですが、通知欄を表示するときに呼ばれるNotifications APIからJSONを出力しました。
-
https://zenn.dev/api/me/notifications?page=22025/11/04 現在
あとはJSONをjqでCSVに加工、Googleスプレッドシートでピボットテーブルや表などを使用していい感じにします。こうした一時的なスクリプトは、AIに手伝ってもらった方が早いと思います（出力結果が合っているかは、自分でしっかり確認しましょう）。
このため自分の記事に対して自分でいいねした分は含まれません。またいいねを付けた後で外すなどの操作が行われた場合、検知のしようがないのであらかじめご了承ください。
検証結果
- A: 2025/08/27(水)-2025/09/30(火)
- 比較期間。緑🟢の縁取りで表現。
- 何もせずに投稿し続けた期間。
- B: 2025/10/01(水)-2025/11/04(火)
- 検証期間。黄🟡の縁取りで表現。
- 稼働日にいいね50活動をした期間。
アナリティクスの表示回数
活動前は1日あたりのPVが約51PVでした。
A: 08/27(水)-09/30(火) 🟢
活動後は約112PVのようですが、大谷選手ばりの外れ値が。実はこのタイミングでトップに表示されており、突発的にアクセスが増えました。トップ入り恐るべし。
B: 10/01(水)-11/04(火) 🟡
そんなこと言っている場合ではない。アナリティクス側で比較を有効にして表示してみます。
🟢 🟡
確かに微増していることは確認できるのですが、所々逆転している日も。色々期間を変えて確認してみましたが、目に見えて増えるということはなさそうです。いいねを受けて見に来るユーザーがいるとしても1日最大50人な訳ですから、その分だけ微増したと考えると妥当ではあります。
日別いいね・フォロー件数
活動前は一時的にいいねが付く記事があるものの、半分以上の期間でいいね・フォロー共に0件。悲しいかな、これが現実でございます。
A: 08/27(水)-09/30(火) 🟢
活動後は初速こそ鈍いものの、3週目くらいから安定的にいいねを獲得している様子。
B: 10/01(水)-11/04(火) 🟡
以下、期間ごとの総計。
| 期間 | いいね | フォロー |
|---|---|---|
| A: 08/27(水)-09/30(火) 🟢 | 21 | 7 |
| B: 10/01(水)-11/04(火) 🟡 | 69 | 29 |
いいね返報率
| 分類 | ユーザー数(人) | 割合(%) | 備考 |
|---|---|---|---|
| 素通りさん | 1,145 | 93.0 | - |
| 一見さん | 76 | 6.2 | ・いいねが1回返ってきた。 |
| 常連さん | 10 | 0.8 | ・読み専の方、2名を含む。 |
| 合計 | 1,231 | 100 | - |
稼働日は20日なので4.62日分ほど多めにいいねを付けてしまったようです。
いいねが返ってきたユーザーだけで見ると86人、全体の約7%です。また少々厳しそうなユーザーさんは、上記の結果には入っておりません。一応載せておくと79件でした。
気付いたこと
返報する人の割合は少ない
マーケティングの話にはなりますが、いいねを付けに行くというこの手法は確度の低い層に対して、あまりコストをかけずにリーチする方法です。だから返ってこないのが前提で、1割も返ってくれば良い方みたいな考え方をします。なので結果は妥当っちゃ妥当です。
検証にあたり仮説のようなものは考えていました。記事を書く開発者視点、通知が来たからといって、その人のページに飛んで記事を読むという行動に至るだろうかと。大多数がそうですが、「いいねが付いた！やったー！」で終わりだと思うんですよね。まず見にいかない。
開発者がいいねを付ける基準はシビアでしょうし、だからこそ返報性の原理は通用しなさそうだなぁと。いいねを複数個付けたら反応が変わる可能性はありますが、良いなと思う記事にいいねを付けるのであって、いいねを付けるのが目的ではありませんから。
そもそも相互フォローや組織票のようなものを嫌う文化もありますし。いいねという行為自体が馴れ合いや互いの数稼ぎみたいになると、それはそれで闇を感じますし。それでいいねもらって嬉しいかと問われると人によるでしょうし。
色々考えて心理的に複雑な気持ちになりました（この記事自体も好き嫌い別れるだろなと）。
絵文字とタイトルは頑張った方がいい
記事を選ぶときに参考にする情報が、絵文字とタイトルしかないんですよね。Google検索であればメタディスクリプションも出てきますが、基本的にはタイトルのみを読んで判断することになります。絵文字は割と適当みたいですからね。サムネもありませんし。
特に困ったのが短い名詞のみのタイトルです。実際、それで通じる内容の場合もあります。しかし代表的な文言だけがタイトルになっていると、その技術を勉強しながらまとめたのか、業務の具体的なTipsなのか。英語だらけのタイトルも、パッと見何の記事なのか判別付きづらく。
- 例1
- ✕ Eloquent ORM
- △ Eloquent ORMのリレーション
- ○ Laravel Eloquentの多対多のリレーションを初心者なりに調べてみた
- 例2
- ✕ RubyKaigi 2027
- ○ RubyKaigi 2027に参加してきました
- ○ RubyKaigi 2027に登壇してきました
「何を・どうした」が明確だと、とっつきやすいです。
記事一覧で見たときに、記事の内容が目に止まりづらいように感じました。できればファーストビューで表示されるタイトル部分に力を入れた方が良さそうです。
記事数は6記事以上用意したい
ある記事を読んで興味を持った人が、ユーザーのページに飛んで記事を探すとします。このときスマホであればスクロールして1画面に4~6記事程度、PCであれば9記事くらいまでは表示されます。その中の1記事でも刺されば、続けて読んでもらえる可能性が上がります。
私も例に漏れずですが、最初の1記事を書いた後にかなり間が空いてしまっています。これはもったいない。もう少し早くGit関連の記事を上げていたら。
また今回の検証のように新規投稿から流入する場合、そもそもの記事数が少ないと読める記事がないということも。私にとっての数学・統計がそれですが、門外漢の分野で数記事だと「なんか凄いこと書いてあるけど、分からないから良記事か判断がつかない」という。
しかし初心者向けや門外漢向けの記事を出すのも違うでしょうし。自分の好きなことを書いているなら、読んでる側に合わせ過ぎるのも違うし。難しいところですね。自己紹介・イベント・資格などは汎用性が高いのでおすすめかも。
誰かを支援する読者にならないか
自分の記事は読んでもらいたいのに、他人の記事を読まないのはいかがなものか。いいねが欲しい欲しいと口にする割に、いいねを付けた数は片手で数えるほどではないか。トレンドに上がった有名記事を読んでいいねを付けているだけではないか。
技術記事を書くべきと説いたその人は、どれほどの技術記事を読み、そのうちのどれほどにいいねを付けたのか。技術記事界隈を活発にしたいならば、新参者には優しくすべきなのではないか。いや辛口毒舌ばかりの私が言うのもなんなんですが。
最初から玄人開発者に称賛されるような記事なんて書けないのだから、いいねやコメントをしたり、技術記事の書き方を記事にするなりして、後進育成に務めた方が良いのではないのか。1日4時間は厳しいので、10分でも20分でも記事を読むところから始めてみてはどうか。
おわりに
もし本気で集客するのであればSEO対策、SNS活用やオフラインイベントへの参加、会社や大学など組織であればチーム内で共有するなど、いくらでも効率的な方法はありますからね。わざわざこの方法を選択しなくてもいいと思います。
とはいえZennで記事を読んでもらう機会を作るのは、投稿してるだけだと難しそうです。そもそもトップに出る記事数も限られてますし。ニコニコ動画の将棋盤みたいなものがあれば別なんでしょうが。新規の優良記事をどう引っ張り上げるかは、昔から存在する歯がゆい問題です。
実際「どうしてこんなに良い記事が埋もれてるんだ」ということもあれば、「何でこの記事にこんなにいいね付いてるんだ」と疑問に思う記事もあったりして。かといって自分がプラットフォーム側だとして、改善難しい問題ではあるよなとも思うしで。
「◯◯してみるテスト」はもう死語ですかねえ。
おまけ
通知欄が狭いので、拡大して使ってました。
/* 最終確認日 2025/10/31 */
[class^="UserNotifications_panel"] {
width: 800px;
}
[class^="UserNotifications_items"] {
max-height: 1000px;
}
また最初のうちはEasy Scraperを使用してデータ抽出してから、スプレッドシートにコピペするなども行っていました。こちらの方がお手軽に引っ張ってこれるというメリットはあります。
簡単なリストならこれでいけますが、日時が相対表示になってしまっているので。厳密に分析したい場合は、APIから直に引っ張ってくるしかないと思います。
本当はTwitterのリストやtwiccaのカラーラベルみたいな機能で管理できたらいいんでしょうけれど。一般的なユーザーに必要な機能かと言われると微妙で、コストに見合わないんでないかとも。拡張機能や自作のビュアーならありかもですね。
Discussion