Qiitaでズルく「いいね」を稼ぐ方法またはQiita駆動開発者の戯言的な何か

いいねくれ～～ (直球)

おまけゲーム承認欲求dino(記事と関係あったりなかったり): https://rec-dino.namnium.work/

とてつもなく誇大なタイトルを戯言という言葉で薄め普通にしたつもりですが結果的にタイトル詐欺でしたらごめんなさい

この記事はQiita史上最多記録をつくろう！アウトプットはいいぞカレンダー Advent Calendar 2022 2 25日目の記事です！

Qiitaで記事投稿を始めてから結構経ち、私なりの記事作成パターンができたので、意識していることをまとめました！

分析したとかではなく完全な経験則なので全く何も保証等はできませんし、当たり前なことも書いていますが、参考になれば幸いです。

0. 自己紹介

Rust大好き大学院生のnamniumと申します！自己満足アプリを作ってQiitaに制作過程記事を挙げるのが趣味です。

アプリを作るためにQiitaに記事を挙げるのを目標にしたり、記事を挙げるためにアプリを作ったり...という「Qiita駆動開発」をしています()

2022年ではTauri記事(読んでいただけると恐悦至極です)を書いたり就活したりしていました

• React + Rust + Tauriで動画プレイヤーを作るハンズオンまたは業務でRustを書きたい就活生の嘆き的な何か - Qiita
• Tauri + windows-rsでオーディオスイッチャーを作った話またはMicrosoftのRustへの本気度をCOM対応から見る的な何か - Qiita

0.1. 対象読者・記事の目的

万人受けすれば幸いですが、私と似たQiitaで作品を紹介したいQiita駆動開発者の参考になるよう意識して書きました。つまり、Qiitaをうまく活用して作品を公開し承認欲求をコントロールしたりモチベーションを維持したい人を対象としています。

そして本記事を通して、良記事の書き方及びタイトルにある「いいねを稼ぐ方法」を提供するのが目的です。

ノウハウ記事は初めて書くので不安ではありますが、早速中身に入っていきましょう！

1. 最も意識したいこと「"いいね"させる説得力」

Qiitaのいいねは実は2種類あります¹。

• [LGTMいいね] 技術的に素晴らしいことが書かれていてすごい！ためになった！ LGTM (Looks Good to Me)だ！ ないいね
• [努力賞いいね] なんかよくわからんけどすごいことしててすごい！ 頑張ってるね！ のいいね

技術者ならLGTMいいねを狙っていきたいですが、モチベ維持のためには努力賞いいねも狙いたいです。

またいいねを稼ぎトレンドに載ることで

• さらなるいいねを誘発する効果
• 「その分野に興味がなかった人」をコミュニティに引き込める効果
• より多くの人に記事の正しさを検証してもらえる効果

も期待できるので、努力賞いいねを稼ぐことは結果的に記事やコミュニティにメリットをもたらします。

以上より両種類のいいねを貰える工夫を盛り込むのが良記事作成のコツになります。

そしていいねを貰うにはいいねにふさわしい説得力が必要です。簡単な因果関係ですね。

いいねをたくさん貰うという目的だけに注目すると 宣伝 が最も大切です。しかし本記事は記事の書き方をテーマとするので深く触れません。

私はTwitterコミュニティ機能を活用しています。その他、自分が所属する組織や団体の力を借りると良さそうです。

以降本記事では両種類のいいねをもらえる説得力を出すためのポイントをまとめます。ただ、即効性があるので努力賞いいねの話が多いです。

2. 「これだけは伝えたい」順で書く

残念なお知らせですが、あなたが書いた記事は(本記事を含め)基本的に最後まで読んでもらえることは滅多にありません。スクロール不要な短い記事は別ですが、たくさんのいいねが目標の記事では長さがネックになります。

「絶対にこれだけは見てほしい・ここがすごいんだ」という順番で記事を書くことで、途中まで読んだ読者からもいいねをもらうことを目指します。

大切なことはもったいぶらず最初に書いてしまいましょう。興味を持ってもらえれば最後まで読まれる可能性も高くなります。正確な長い説明が要る内容の中にも、「最も伝えたいこと」は必ずあるでしょうから、簡単にしてでも冒頭に書くことを意識します。

また、どの記事にも共通の「冒頭に書くべき大切なこと」があります。それを3節と4節で示します。

3. 記事の軸となる内容

先述の通り、1つの記事で伝わることには限りがあります。少しでも内容を伝えるためにまず記事の軸を固めることを意識します。

記事の軸は記事と読者をマッチングさせるためにあります。軸を固め読者の意識を記事に向けさせましょう。

3.1. 「自己紹介」や「対象読者」

記事の内容を読んでもらうために重要です。次の効果があります。

• 対象読者を想定することで、伝わっているかを意識しながら書ける
• 筆者の立場や状況を伝えることで、読者の需要に合った記事である ことを示せる
  • 自分と領域が近い人に読んでもらいやすくなる
  • 記事と読者のミスマッチを防げる

同じ効果が得られる項目なら自己紹介・対象読者以外でも良いです。例えば私のこの記事では「作った動機」を代わりとしています。要は記事の前提・背景が伝わることが重要です。特に見出しが思いつかなければ「はじめに」でまとめると良いです。

とはいえ長くしすぎると肝心の本編が読んでもらえません。簡潔にまとめましょう。

3.2. 「目的」や「メリット」

記事の目的をはっきり決め、明記しましょう。作品紹介要素が強い記事に関して言えば、できれば 読むことで得られる恩恵 も提示しましょう。

例として、私の場合は「新しいフレームワーク(TauriやGodot)で〇〇を作ってみた！フレームワークの使い方説明！」というパターンを使っています。読んだ人にフレームワークの存在を知り使い方もわかるという恩恵を与えています。

記事の目的を通し「メリット」を示すことで読者の 読む動機 を増やします。

また、目的を明記することは、執筆者にとっても推敲時での 情報の取捨選択 の際に役立ちます。

4. 読者にインパクトを与える内容

研究論文は新規性が大切で、コントリビュートをアブストラクトではっきり書くものですが、同様にしてやったんだぞ感を冒頭に持ってくると興味を持ってもらいやすくなります。

多少誇大にするぐらいでちょうど良いです。私は次の3つでインパクトを出しています。

4.1. タイトル付け

記事のリンクをクリックしてもらわないことにはいいねはもらえない という当然の理由より最も意識したい部分です。他の記事でも大体「タイトルが重要」とか「タイトルで釣る」という内容が見受けられます。... タイトルで釣りましょう (笑)

インパクトを与えるには話題性や意外性のあるタイトルが良いでしょう。また内容を簡潔に表したタイトルが望ましいです。(本記事のタイトルの真似は推奨しません!!)

何とは言いませんが私も話題性を利用したことがあります → Rustのlet-else文気持ち良すぎだろ - Qiita

他の記事様からの受け売りですがSEO対策で【Python3】〇〇〇みたいに使用技術を列挙するパターンも良いようです(SEOは流動性があるので最近の事情はわからないですが)。 【SEO】Qiita記事の「view」と「いいね」数を増やす方法とは？ - Qiita

私はモチベ向上のためとトレンド入りした際に目立つことを考え、あえて「〇〇または△△的な何か」というフォーマット²の長いタイトルをつけていたりします。ブランディングの意識で自分なりに好きなタイトルパターンを作るのはアリでしょう。

4.2. アイキャッチ画像

次節の「成果物」とつながっていますが、記事にアイキャッチ画像をつけることでインパクトが出ます。

アイキャッチ画像は、記事を開いたときに最初に目が行く部分です。

アイキャッチ画像に成果物のデモを載せることで、あなたが 何か素晴らしいものを作った という事実を読者に嫌でも認識させることができます。「すごい」と思うでしょうし「先を越された！くやしい！」と思うかもしれません。どのように思わせたにせよ、興味を持ってもらえるのでいいねの可能性はぐっと大きくなります。

圧倒的オススメは本記事の最初に載せたような GIFアニメーション画像 です。ソフトのデモンストレーションにしろゲームのプレイ映像にしろ、動画とは違い自動で再生され動いている様子を強制的に読者に伝えられるので、静的画像よりインパクトが大きいです。

例えば ワールドルールテトリスの作り方またはRust入門した感想的な何か - Qiita という私の記事ではワールドルールを適用させたDT砲を打つGIF画像を設置しています。このGIF画像によって「ワールドルール」テトリスを作れていることを最初に伝えられています。

とは言うものの、GIF画像は重くなりがちで作成が難しかったりもするので、無理に載せる必要はないです。

GIF作成オススメのツール: https://www.screentogif.com/

4.3. 成果物とそのリンク

成果物を閲覧できるリンクがあるとより記事の説得力が上がります。

「アプリを作った」と言っても作り方しか書かれていなければ「本当に作れるの？」と疑われてしまいます。最初にアプリの存在を示し読者を納得させましょう。

GitHubのリポジトリリンクを載せるだけで説得力があります。以下、加えて私がよくやる公開方法です。

GitHub Pages

作品をこれから作るという人は圧倒的に公開しやすい フロントエンドWebアプリ (JavaScript作品) にすることをオススメします。静的WebサイトならばGitHub Pagesで簡単に公開できるためです。

JavaScript書けない/書きたくないという人はクロスコンパイルする方法やWebAssemblyにする方法を模索しましょう。Rustはwasmを楽に書ける言語なのでオススメです。(隙有Rust宣伝)

GitHub Actions及びReleases

Windowsアプリみたいなプラットフォーム特有の成果物だと当然GitHub Pagesを使ったデプロイはできません。リポジトリのリンクのみでは、実際に試してもらうには環境構築やビルドを読者に任せることとなり、使ってもらえる可能性は皆無です。かといってビルドしたアプリをGoogleドライブや自前のサーバーでリリースしても、信じてもらえずダウンロードしてもらえる可能性は低いままです。

少しでも信頼度を上げたい時に使えるのがGitHub Actionsを利用したアプリのリリースです。

GitHub Actionsはプッシュ時やプルリクのマージ時にGitHub側で仮想環境を建て自動的にテストやリリース、デプロイ等をやってくれるCI/CD機能です。次の記事様が詳しいです。

いくつかのアクションを組み合わせてYAML自動化スクリプトを組んで使用します。

action-gh-releaseというアクションを使うことでバージョンタグごとにアプリのリリースを作成してくれます。使い方は次の記事様が詳しいです。

action-gh-releaseを使ったアクションが実行されると、リポジトリの右の方にReleasesという項目が現れ、いい感じにリリースページを作ってくれます！

リポジトリ内容がそのままビルドされてリリースされるので、Googleドライブ等で配布するよりは信頼度が高いリリースができます。

5. 記事作成

以降、作品制作を絡めた記事作成の流れについてまとめます。ここまではいかにインパクトを与え努力賞いいねを貰うかという話でしたが、ここからはLGTMいいねにつながるような、技術的信頼を得るための話もしていきます。

制作開始前から 最終的に記事にすることを意識 して取り組むと最後に記事にまとめやすくなります。制作過程及び執筆で意識したいことをまとめます。

5.1. ゴール・締め切りの設定

皆さん締め切りは好きですか？私は嫌いです。しかしながら、記事を完成させるには 妥協点 として締め切りやゴールを設けることが大切です。

なぜ妥協点が必要かというと、原理的に アプリは完成しないもの だからです。アプリの改善点は消えることがないからです。

実際にアプリを作るシーンを想像してみましょう。他人から見れば十分に完成していても、例えば「セーブ機能がない！」や、「コードの整理ができてない！」など、アプリ制作に取り憑かれた開発者本人の目の前には永遠にチケットが湧いてきます。

一方、具体的に「いつまでに、どこまでの機能を実現する」と予め決め、開発する機能の順序を含めて設計すると、完成していなくても妥協点ができ「α版」をデプロイできます。

技術記事を締め切りまでに実装しなければならないため、 実装順序が決定され機能策定が具体的になります 。さらにゴールがあることで 記事構成の大まかなイメージができ、モチベアップにもつながります 。

「締め切り」、嫌な響きですが、この青鬼のお陰で素晴らしい記事が完成するんですね。自分で用意した締め切りは破られがちなので、アドカレのようなコミュニティに依存した締め切りを用意しましょう。

5.2. 正しい情報を残す

あなたの想いに反し、読者は記事を様々な視点で疑って読みます。

• 日付は新しいか？out-of-dateではないか？
• 自分と同じ環境か？おま環ではないか？
• 実は実行して確かめていないのではないか？テキトーに書かれたソースコードではないか？
• ...etc...

なぜ疑うかというとそれだけ裏切られた経験があるからです。皆様も心当たりがあるのではないでしょうか？

読者を安心させるため、適切で正しい情報を載せることが大切です。

5.2.1. リンクを貼る

お手軽に信頼を得る方法は参考にしたリンクをなるべく貼ることです。

アプリ制作中に参考にしたサイトのURLはブックマークしたりメモしたりしてなるべく残しましょう。私は記事からコピペしたコードがあれば、直接ソースコードにコメントでURLを残すようにし、記事作成時にも掲載しています。

リンクによって次の効果が得られます。

• 1次ソース・公式リンク : 公式に従ったことが示せます。最も残すべき重要なリンクです。2次ソースを参考にした場合でもなるべく1次ソースに沿っているかを確認し1次ソースのリンクを貼りましょう。
• 2次ソース・個人ブログなどの第三者のリンク: とりあえずリンク先に真正性を責任転嫁できます。別な人も確認した情報であることを示す効果もあります。ただリンクを貼るだけではなく、どのようなことが書かれており、従った結果どうなったか(一部間違っていた・方法が変わっていたなど)まで書いておくと信じてもらいやすくなります。

リンクが多すぎると読みにくくなるので乱用は厳禁です。多い時は記事の最後に引用・参考文献として載せることをオススメします。

5.2.2. 再現性を意識して取り組む

「記事通りに実行して同じ結果になるか、再現できるか」は記事の真正性そのものに直結しています。

実行結果は環境から様々な副作用を受けます。読者が再現できるように、前提となる情報はなるべく明記しましょう。

• パソコンに関する情報
  • OSのバージョン
  • (例えばベンチマークの記事ならば)CPUやメモリ等のハードウェア情報
• ソフトウェアに関する情報
  • 言語・フレームワークのバージョン

ソースコードだけではなく実行・再現手順もしっかり残しましょう。リンクを残すのと同様にアプリ制作時から意識すると良いです。記事にしない場合でも備忘録となり未来の自分が救われます。

• 環境構築手順を書き残す
• 実行手順・ビルド手順・コマンドを書き残す

実は上記を簡単にまとめられる最強備忘録ツールがあります。 Docker です。

• Dockerとは一体何なんだ？【初心者向け】 - RAKUS Developers Blog | ラクス エンジニアブログ

Dockerファイルならば環境構築・依存追加・コマンドの実行・ビルド全てをまとめることができます。さらにDockerファイルを公開すれば誰でも簡単にあなたの記事の再現ができます。

例えば私の記事では環境構築を省略できるようにDockerファイルを用意しています。

上記はGodotというゲームエンジンで使う動的ライブラリを生成するための環境構築Dockerファイルです。Dockerはバックエンドだけではなく環境構築が絡む様々な場面で活用できます。

しっかり実行できるDockerファイルを残せると、記事の不明点があってもDockerファイルを確認すれば良くなり、真正性はかなり高いものになります。

無理にDockerファイルとして残す必要はないですが、Dockerファイルが書ける程度にはコマンド類を書き残しましょう。

またここまでDockerファイルを推してきましたが、Dockerの実行はそれはそれで面倒なため、記事には具体的な環境構築・実行手順の方を書き残しましょう。

特に環境構築は煩雑になりがちで、ブラウザバックを誘発する諸刃の剣でもあります。必要十分な量に留めるよう注意を払いましょう。

5.3. Markdown記法を活用する

これもタイトルと同様に色々な記事で言及されていることですが、Markdown記法を積極的に活用しましょう。有名なチートシートを参考にすると良いです。

次の効果があります。

• 読みやすくなる効果
• 執筆のモチベーションが上がる効果

効果は次節から解説します。ちなみに、他人のMarkdown表現が気になった時は記事左の・・・から「Markdownで本文を見る」を選ぶことで表現方法を確認できます。

5.3.1. 読みやすくなる効果

平坦な文章ばかりの記事は言うまでもなく、箇条書きばかりの記事(本記事かな？)や表ばっかりの記事はとても読みにくくなります。

Markdown記法を練習し記事に合った適切な表現を用いましょう。

読みやすくなる効果が期待できる個人的に好きな機能を紹介します。

リスト

• ハイフンスペースで始める箇条書きです。
  • ネストのご利用は計画的に
  • 本記事はリスト率が高いですね

表

単語	効果
表	は複数の情報をアラインメントしてまとめたい時に便利です
リスト	が煩雑になった時の代わりに使えます

コードスパン・コードブロック

ソースコード掲載御用達の機能です。コードスパンというのはバッククォート2つで囲むとハイライトされるこういうやつです 。

bash

$ echo "コードブロックはこういうやつです"
コードブロックはこういうやつです
$ PS1=""
echo "コピペのしやすさを考慮して書くと良いです。つまり$はできるだけ消しましょう。"
コピペのしやすさを考慮して書くと良いです。つまり$はできるだけ消しましょう。

リンク

[見出し](URL)と書くことでこんな感じにリンクになります

ちなみにURLをそのまま書くと今のQiitaではリンクカードになって見栄えが良いです。

https://qiita.com/Qiita/items/c686397e4a0f4f11683d

↓

Detailsタグ

とても長い内容がある時に

Detailsタグ

<details><summary>折りたたんでます</summary>

折りたたみたい内容
</details>

みたいに書くことで折りたたんだ状態で内容を掲載できます。記事としては残したい情報だけど長すぎるので読者の目には入れたくない時に便利です。

折りたたんでます

折りたたみたい内容

The Zen of Python

The Zen of Python

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

5.3.2. 執筆のモチベーションが上がる効果

例えば こうやって太字にしたり とか、 独り言みたいに薄い文字にしたり等、Markdownの機能のお陰で、記事にアクセントをつけ、楽しく記事を書くことができます！

言うまでもないですが乱用厳禁です！！！

記事制作を楽しくする個人的に好きな機能を紹介します。

太字

**太字** と書くと 太字 になります。本記事で使いまくっていますね

打ち消し

~~間違い~~ と書くと 間違い になります。情報の修正に使うのが主ですが、たまに煽ったりする冗談を言うのに使えます(使うな)。

Note

補足機能です。本筋に関係ないことや注意点をまとめたりするのに使えます。次のように書きます。

:::note info
Information
ちなみに私はEmacs派です
:::

Information
ちなみに私はEmacs派です

infoの他にもwarnやalertがあります。infoのみ省略可能です

脚注

footnoteと呼ばれるもので、私はツッコミが来そうだけど記事には書きたくない情報³を載せるのに使っています。

[^1]や[^aaaa]みたいに挿入したい箇所に入れ、下辺りに

[^1]: 本筋とは関係ない情報

みたいに書くことで脚注になります。

全く記事に関係ないお気持ちを書く時にも活用しています⁴。

6. 推敲

画竜点睛にあたる重要な作業です。推敲の方針を決めずウンウン悩んでも記事が完成しませんので、ある程度機械的で良いです。

誤字脱字や内容の誤りを修正する他、私がやっていることを書きます。

6.1. 思い切って削る

文章を短くして読みやすくします。要らない言葉はじゃんじゃん削りましょう！

削ってはいけない部分は執筆者本人なら直感的にわかります。ジェンガのイメージでどんどん抜きます！

例:

• くどい表現
  • したりしています → しています
  • してしまって → して
  • わかると思います → わかります
• 倒置
  • 「〇〇するためには△△する必要があります。」→「△△することで〇〇できます。」
• 「これは」などの指示語: 省略できる場合が多いです。
• など、等: 勢いで書くと使いがちですが消せます。
• 接続詞周り: 「〇〇ですが、△△です」→「〇〇です。しかし△△です」のように2文に切れる時は切りましょう。

特に記事の目的と関係ない部分は内容ごと消せます！...というと過激過ぎますね。どうしても残したい余談やユーモアは脚注等に移動すると良いです。

本記事長くなりすぎてろくに推敲ができていないのは内緒です

6.2. 順番に無理がないかを確認する

節単位で話の流れが通っているかを確認します。冒頭で述べた通り「伝えたい順」になっているかも確認します。

節の親子構造や見出しを確認すると意外と改善箇所があります。

6.3. 記事を寝かせる

記事を寝かせて一旦忘れることで、

• もう一度読んだ時に違和感に気づける
• 書くべき大切なことのみ頭に残るので記事がスッキリする

という効果があります。執筆中でも定期的に寝かせてみると良いです。

記事の構想はアプリ制作が進むごとに変わるものです。柔軟に変化させていきましょう。

一気に完成させる場合に比べモチベが途切れやすいので、諸刃の剣ではあります。

6.4. 「まとめ・所感」を書く

なんで「5. 記事作成」ではなく「6. 推敲」で？と思われたかもしれませんが、ちゃんと理由があります。

「まとめ」の特徴

• 伝えたい内容は伝えきっているはず
  • 内容は、人前での発表ではなく記事なので読み返せる。概要・TL;DRなら最初に書くべき
  • まとめで簡潔にする必要があるということは、本編のほうが簡潔でない → 本編を推敲すべき
• 最後にあるので読んでもらえるのは稀

「まとめ」のメリット

• 内容の書き忘れに気づける
• メリハリを出せる

まとめは実は執筆者にとってのメリットの方が多く、推敲要素が強いのです。そのため推敲の節に記載しました。

以上より、詳しくなくて良いので 完走するためにまとめを書きましょう！

というわけで、本記事のまとめです。

7. まとめ「楽しんで書く」

とーーーっても長い記事になりましたね！！ここまで読んでくれた方が居ましたら感謝感激です！

色々書きすぎて「結局何が大切なの？？？」となっているかもしれませんが、最も大切なのは その記事を書いて/読んで楽しいか？ だと思います。結局モチベーションです。ベタですが()

私個人は本記事の通りに記事作成すると楽しいというだけで、人によって合う合わないが当然あります。楽しく記事を書いて 試行回数を増やせばいいねをもらえる勘・コツがわかるようになります 。本記事の内容に関係なく、楽しく記事を作成することがベストです。

(そして何か素晴らしいアイデアがありましたら是非コメントで教えていただけると幸いです！)

...以上、インフルエンサーでもなんでもない野良のQiita駆動開発者の戯言でした！

メリークリスマス(遅)！今年もありがとうございました！来年も楽しくQiitaに記事投稿していきたいです！

引用・参考文献

今回記事を出すきっかけに今年こそは継続的にアウトプットすると決めた方向けに語る技術発信の取り組み方というイベントの存在があったりします。このイベントで強強エンジニアの方々から教えていただいたことは、特に記事作成の節等で大いに参考にさせていただきました！それ以外のポエムもモリモリに盛りましたが()

• うさみけんたさん: 技術発信の信頼性を高める10のポイント #技術発信2022 ｜にゃんだーすわん｜pixivFANBOX
• uhyoさん: 技術記事を好き勝手に書くために
• 無職 やめ太郎さん: 「技術記事って、別に書かなくてもよくないすか？」 - Qiita

また、Qiitaの「良い記事を書くには」を改めて参考にしました。本記事より簡潔にまとめられていて車輪の再開発をしてしまった気分が少しあります()

• 良い記事を書くには

その他参考にさせていただいた記事様です。

• Qiitaで良い記事を書く技術 - Qiita
• 「技術記事を書きたい気持ちはあるけど時間が・・・」という葛藤を乗り越える - Qiita

1. Qiitaのいいねは一度LGTMに変わりそしていいねに戻るという変遷をしています。努力賞いいねの存在を考えると私は今の"いいね"が好きです。 ↩

2. 「または」で連結しているのは、私自身は読んだことはないのですがルソーの「エミール、または教育について」のパロです。 ↩

3. そもそも突っ込まれるような情報を書くなというご指摘、承りました。 ↩

4. この脚注を見た人は今日最終回だった「ぼっち・ざ・ろっく！」を観てください。最終話はまだですがdアニで11話まで観れるはず ↩