【ITニュース解説】Seven posts on DEV, 74 views, and the one comment I never answered
2026年10月02日に「Dev.to」が公開したITニュース「Seven posts on DEV, 74 views, and the one comment I never answered」について初心者にもわかりやすく解説しています。
ITニュース概要
DEVに技術記事を7つ投稿したが、ビュー数が伸び悩む。著者は原因を分析。人気記事は個人的体験や議論喚起、カバー画像があるものが多く、自身の記事は専門的なタイトルと画像不足が原因と推測。読者の意見を求めつつ、この記事で改善策を試している。
ITニュース解説
技術系の記事を投稿できるプラットフォームDEV.toで、あるエンジニアが直面した現実と、そこから得られた学びについて解説する。システムエンジニアを目指す初心者が、技術力を高めるだけでなく、それをどのように発信し、コミュニティと交流していくべきかという点において、非常に参考になる体験談だ。
著者はDEV.toに登録してから19日間で、自身が開発した技術に関する7つの記事を投稿した。例えば、「静的計算機サイトがロードするもの(16リクエスト)」や「Shopifyアプリのルールがどのようにチェックアウト内で動くか」といった具体的なテーマだ。しかし、これらの記事の閲覧数は非常に少なく、合計で74回だった。特に、後半に投稿された2つの記事は閲覧数が「ゼロ」という厳しい結果に終わっている。リアクション(いわゆる「いいね」のようなもの)も合計で3回と、読者からの反応はほとんどなかった。
記事のタイトルは全て、彼が開発した「もの」についてのもので、技術的な内容を正確に表していた。また、記事にはカバー画像(サムネイル画像)が一切設定されていなかった。コメントは3つ寄せられたが、そのうち2つは商品宣伝目的のスパムコメントだった。唯一、投稿内容に関する建設的なコメントがあったものの、著者はそのコメントに18日間も返信しないまま、別の記事を投稿し続けていた。これは、技術情報を発信する上でのコミュニティとの交流の重要性を見落としていたことを示している。
なぜ自分の記事が読まれないのか、著者はただ悩むのではなく、DEV.toの公開API(プログラムを使って記事のデータなどを取得できる仕組み)を活用して、自身の記事や他の記事のデータを収集し、客観的に分析を始めた。これは、システムエンジニアが問題解決のためにデータを収集し、仮説を立てて検証するプロセスと全く同じアプローチだ。
まず、彼は「投稿時間」が原因ではないかと推測した。7つの記事のうち6つは米国東部時間の午前8時に投稿されたが、最も閲覧数の多かった最初の記事は午前2時という不規則な時間に投稿されていたため、投稿時間が主要な原因ではないと結論付けた。次に、「記事が非表示になっているのではないか」という仮説を立て、実際に公開APIを使って、閲覧数ゼロの記事がそれぞれのタグ(#shopify、#showdevなど)のフィードに表示されていることを確認した。これにより、記事は確かに公開されており、ただ単に誰もクリックしなかっただけだと判明した。
これらの分析から著者は、読者がDEV.toの忙しいフィードの中で、長くて専門的なタイトルで、かつ写真もない自身の記事を見ても、関心を引かれずに次の記事へと移ってしまった可能性が高いと考えるに至った。
さらに深い洞察を得るため、著者は同時期に投稿された他の記事の傾向も分析した。特に「#showdev」(自分が開発した技術を披露する際に使うタグ)が付いた200件以上の記事を調べたところ、これらの記事のリアクションの中央値も0であり、5リアクション以上に達したものはわずか3%だった。これは、#showdevタグが、特にフォロワーがまだ少ない初心者にとっては、すぐには効果が出にくい傾向があることを示唆している。#beginners(初心者向け)や#javascriptといったタグでも同様の傾向が見られた。
しかし、サイト全体の「今週のトップ30記事」を分析すると、全く異なる傾向が見えてきた。これらの人気記事の約半分(13記事)は、「私、燃え尽きたんです」「23回の不採用を経て、複数の内定を勝ち取った」のように、投稿者自身の個人的な経験や感情に焦点を当てた「一人称」のタイトルを持っていた。また、これらの記事の多くが「#discuss」(議論を促すタグ)を使用しており、驚くべきことに25記事がカバー画像を設定していた。コメント数も中央値で26と非常に多かった。
この比較から著者は、自分の記事タイトルが「変更履歴の項目」のように見え、読者にクリックする動機を与えていなかったと痛感した。読者は具体的な技術の詳細よりも、投稿者の人間的な側面や、共感を呼ぶストーリー、そして視覚的に魅力的な要素(カバー画像)に引かれる傾向があるのだ。
これらの反省と分析を踏まえ、著者は今回の分析記事自体を「実験」と位置付けた。これまでの投稿パターン(一人称ではない、#showdevタグ、長いタイトル、製品名入り、カバー画像なし)を意図的に破り、一人称での語り口、#discussタグの使用、短く簡潔なタイトル、そして製品名を含まない形で記事を投稿している。投稿時間とカバー画像なしは維持し、何が影響するのかをより明確にしようとしている。そして、以前に怠ったコメントへの返信については、「今回の記事ではすべてのコメントに1日以内に返信する」と宣言し、読者とのコミュニケーションを重視する姿勢に転換した。
このエンジニアの体験談は、システムエンジニアを目指す初心者にとって多くの教訓を含んでいる。単に優れた技術を開発するだけでなく、それをいかに効果的に人々に伝え、関心を持ってもらうかという「情報発信力」の重要性だ。また、データに基づいて自分の活動を分析し、改善策を考え、新しいアプローチを試みるという一連のプロセスは、システム開発におけるPDCAサイクル(計画・実行・評価・改善)そのものであり、エンジニアとして不可欠な思考法である。そして、技術コミュニティにおいては、一方的な情報提供だけでなく、読者からのコメントに真摯に耳を傾け、対話を通じて関係性を築いていくことが、自身の成長と情報の影響力を高める上で極めて重要であることを示している。