読まれる技術記事を書くには？技術記事を書く時のポイントまとめてみた
Crieitのアドベントカレンダー３日目です。担当の渡邊がお送りいたします。
みなさん、qiitaや自分のブログ、はたまたCrieitなどに技術記事書いていますか？
せっかく技術記事投稿サイトのアドベントカレンダーなので、技術記事自体を書くことについて書きます。
ノウハウと見せかけて当たり前の事を書こうと思います。
そもそも技術記事って書くべきなのか
エンジニアじゃなくても「情報発信」は大事です。フリーランスじゃなくともそこから仕事につながることもあるでしょう。100%書かないよりは書いたほうがいい。
もちろん仕事をとってくる目的で書いてるなら立派な営業活動なので書くべき。最新情報とかの発信はブランディングになるんですよね〜mizchiさんとかすごい。
そうでない方も、エラーで困った内容とかはできるだけログとして残しておくといいでしょう。どうせ３ヶ月後に同じでエラーが出て自分が読むことになります。笑
とはいえ無理してまで書くのは微妙ではある。コードを書く時間を減らさないように、息抜きレベルにしよう。
せっかくなら読まれたいよね
そしてせっかく書いた技術記事、どうせならたくさんの人に読まれたいですよね。
まず技術記事ってどんな種類のがあるか、分類しました。翻訳記事についても内容自体は以下の感じではないでしょうか。
- トレンド発信
- 困った事をまとめた記事
- 自分で調べる必要があってついでにまとめた記事
- 作っていたものを事例として紹介した記事
- 人に聞かれた事を書く記事
- ポエム
それぞれについて、読まれるための大事なポイントを書いていきます。
読まれるトレンド記事
トレンド記事はとにかくスピードが大事！
界隈の人が「お、新しいライブラリが出てるな〜」とか、なんだなんだと言っている３日以内にさっと記事を出しましょう。
そしてトレンド記事は簡潔であることが結構大事。あくまで概要を知りたいって人が中心なので。
そのため「わかった気にさせる」ような内容を書けると「あ〜React hooksね。完全に理解した」って言ってシェアできる。
あとはブログじゃなくてもいいかも。TwitterとかYoutubeでいい場合もある。
困った事をまとめる
これはとにかくエラーログが大事！
できればタイトルにエラーで出る一番重要な文言を入れましょう。
これはそのエラーでググった人がたどり着けるようにです。つまり、書いてすぐ読まれることは期待してはいけません。
あとはそうすると、ググってヒットする必要があるので最低限のSEOが大事！teratailで回答ゼロの質問に負けたりしたら目も当てられません笑
エラーじゃないとしても「〇〇が効かない」とか、ググられそうな形のタイトルにしましょう。
とはいえニッチなエラー文言で記事書いてたら大丈夫な気もします。
自分が忘れたころに過去の自分に感謝することになったりもします。
自分で何かを調べる必要があってまとめた記事
これは網羅性が大事！
比較記事を書くとしてもリファレンス的記事を書くとして、長くなってもしっかり網羅的に書かれていることが大切です。
「これとこれで、結局速度はどっちのが早いんだ・・・？？？」ってなって離脱されるようなことは避けたい
あとこれもSEO大事かな〜そのワードで上位表示してないと読まれないので。
自分で作っていたものについて事例として紹介して書く
しっかり宣伝になるように書くのが大事！
結局その作ったものに人が来てくれないのなら、それ載せる意味ないやん。
理想は「プロダクトローンチ」→「このサービスのここどうやって作ってるんだ！？」→「うわ〜解説記事あるやんなるほどなシェアシェア」ってなること。
ただただ宣伝したいだけの記事はノイズだ〜qiitaじゃないとこに書いてくれ〜
とかこういうの気にしなきゃならないような内容がある記事は自分のブログに書いたほうがいいよ。文句いわれないでしょう。
あくまでqiitaに書きたい時にはちゃんと技術的な内容を中心に書くのよ〜（あたりまえ）
人に聞かれた事を書く
誰かに質問された内容を記事に落とし込む場合。２回も同じ事違う人に聞かれても記事のURLをシュッと出すことでありがたがられる。
これは聞かれた人が満足する内容だったのかどうかが大事。内容について聞いてきた人にチェックしてもらうとより良いかな〜
あとは、聞かれるってことは確実に需要がある記事なので、そういう機会があったらしっかり記事に書いたほうがいいよ。
ポエム
エモさが大事。なにはなくともエモ散らかしましょう。エモさがあれば、あとは何もいらない。裸になるほど読まれますよ。ザッツインターネット。
どこで書くか問題
次にどこで発信したらいいんだ〜っての結構悩みどころですね。
qiita
先程も触れましたが、qiitaはコミュニティなので、公式のコミュニティガイドラインがあります。それにそった記事を書いていれば、ランキング機能だったりSEOもよかったりして結構読まれるようになりますね。困ったらqiitaでいいかも。
自分のブログ
自分で立ち上げたブログなら何を書いても文句は言われません。「技術記事なのかどうか怪しいから」とか迷う必要もない。
ただ、ホスティングを自分でやる必要があるのは正直めんどくさい。笑
しかしそれ自体が技術アピールになったりしますので、ポートフォリオ代わりに作ってしまうのもあり。
「俺様のサイトはGatsby.jsだ。お前のサイトより早い」（これGatsbyの謳い文句ね）
そして細かいところが気になって、肝心の記事が書けないという負のスパイラルに陥らないように笑
QrunchやCrieit
そこでポエムだろうがなんだろうが書き散らかしてもいい上に無料の記事投稿サービスがありますから、この辺を使うのもいいですね。
note
SEOは強そうですね。ただ、エディタの書き心地が地獄なので私はマークダウンエディタが出たらなにかしら書こうと思います。有料にもできるし。
全体的に書くときに重要なポイント
タイトルが大事
使った技術内容とか引きになるようなものを織り込むのが大事。30字とかよりは長くならないようにしたい（google検索で文字が切れる限界そんなもんじゃなかったっけ）
記事を書いた日付がわかるようにしておく
qiitaなんかは「この記事は古いぜ〜」って勝手に出してくれるからありがたい。個人ブログはそもそも日付の表示忘れてたりするよね。古い記事は古いとちゃんと書いておかないと自分も後で困る。
動作環境などもできるだけ書いておく
そしてバージョン情報とかはできるだけ載せておこう。再現環境がcodepenとかであると最高。
短くても書いたほうがいいの？
以前はてな匿名ブログで「ゴミ記事を書くな」みたいなエントリーがありました。
るせぇぇぇぇーーーー！！！！！
どんなに短くても書かないよりも書いたほうがいいです。
エラー文言 hoge.js の３行目に fuga この１行書いたら直った
たった３行でも、価値があります！
同じエラーで困っている誰かの助けになるかもしれません。
たとえ情報が古くて微妙になってしまったとしても、その記事をググって出ないようにするのはgoogleの仕事なので、あなたは気にせずアウトプットしていいのです。
また、Qiitaには「編集リクエスト」って素敵な機能がありますよ！ミスってるのに気づいたらリクエスト送ってあげて。
あとQrunchは「ログ」って機能があって、ユーザーが執筆時にググっても出てこないようにするように設定する機能もあるので、気になったらログに設定とかもアリ。
なにはなくとも、書く余裕があるなら、書きましょう。マイナスになることはないです。
まとめ
- 書く記事によって読まれるポイントがあるので意識しよう
- まぁそもそもほとんどの記事は読まれませんので、読まれなくても気にすんな
- できるだけ親切丁寧に書いたほうがいいけど、しんどかったらさっと出してしまおう
- 場所はどういうアウトプットをしていきたいかによって変えてもいいかも
- あとはとにかく書いて徳を積みましょう
こう、色々書いたけど、まず発信するだけで偉い！もし余裕があって、気が使えたら（自分にとっても）色々読みやすい記事を書きましょうという話なので！とにかくまずは３行あればオーケー！！！
以上です。
明日はクソアプリ友達のあんどさんがいい感じの記事を書いてくれます！
