Qiitaの投稿数が1000記事になりました

概要

• 2018年11月17日からQiitaの投稿を初めて1000記事に達したので振り返りも含めてまとめてみます

ご注意

• 記載内容はあくまで筆者の主観です。
• 「こんな考え方があるんだなー」くらいの感じで読んでいただけると非常に嬉しいです！

4年弱で1000記事になったわけ

• 一時期かなりの高頻度で記事投稿をしていました。質の高い記事を投稿するよりはメモ的に小さいことでも良いので記事にすることを心がけました。
  • 2年間の毎日投稿
    • Qiitaを1年間ほぼ毎日投稿した話と転職の話
    • Qiitaに毎日2年間投稿した話
  • 年末の一人アドベントカレンダーの実施
    • miriwo毎日投稿のついで(内容はランダム) Advent Calendar 2019
    • miriwo 技術何でも Advent Calendar 2020

どんなことを思って記事を書いているか

未来の自分に向けたメモとして書く

• 詰まって困った経験は数年置きくらいにくり返されることがあります。
• その時に過去の自分がメモを残しておいてくれると問題解決がスムーズになります。
• また、自分が昔に記載した記事なので他の人が書いてくれている記事よりも圧倒的に読みやすく、当時の記憶も呼び起こされ相乗効果で問題が解決できます。
• 副産物として、当時の自分の知識量などもかなり鮮明に図ることができます！
• さらに「未来の自分に向けたメモ」として記載することで自然と内容も丁寧にわかりやすくなることがあります。

自分と同じ問題を抱えている人に向けて書く

• おそらく自分が詰まった内容というのは全世界の一人くらいは同じ経験があります。
• どんなに小さな内容でも勘違いで詰まったりすることはあります。他の人の理解の手助けに少しでもなれたらよいなとおもって記事を書いています。

チームメンバーに向けて記事を書く

• プロジェクトに加わっているとライブラリの使い方など新しい技術の調査をお願いされることがあります。セキュリティー的に書けない部分は内部のクローズなWikiに記載したほうが良いですが、汎用的な情報は記事にして第三者にも見れるようにしておくと素敵です。
• もしあなたと同じ立場でライブラリの調査を頼まれた人がいたら・・・？あなたがすでにまとめてくれている記事があったら+αの内容を更に調べられます。もしかするとあなたの記事を引用して+αの分の知見を記事にしてくれるかもしれません。
• 第三者の目線も気にすることで記事の内容がブラッシュアップされてチームメンバーも見やすいものになるかもしれません。

「同じ内容の記事が既にある」&「マサカリが飛んでくる」は気にしないで書く

• ここまで綺麗事を並べているようですがこの辺から若干リアルな内容にいきます！
• 実際、よっぽどニッチな知見でない限り書こうとしている内容はすでに先人の賢人によって記事にされています。
• じゃあ書く意味がないのかと言われればそんな事はありません。
• 果たしてその記事は今の最新バージョンの組み合わせで書かれたものでしょうか？あなたのPCやDocker環境と全く同一のものでしょうか？問題解決方法は正しいでしょうか？
• 言語・バージョン・PCのOS・Dockerのバージョンが一致していれば基本的に大きな際はありません。しかし今あなたが解決した問題はあなたの今の環境でしか再現しないかもしれません。今後のバージョンで同じもんだが発生して多くの人が困るかもしれません。
• また、記事を書いている人によって解決のアプローチが完全に変わってしまいます。Aさんの記事はわかりやすかったけどBさんの記事はちょっとレベルが高くてわかりにくいなんてこともあります。
• 記事を書く上で怖いのが「マサカリ」です。ただ安心してください。界隈で話題になるようなマサカリは基本的に飛んできません。1000記事書いていて一回もマサカリ来たことありません。（←自分の記事がしょぼいからかも）自分が誤って記載している部分を指摘してくださる方、この辺を勉強すると良いかもとアドバイスをくれる方からのコメントばかりです！この辺は気にせずどんどん記事を書いちゃいましょう！

知見は鮮度の良いうちに書く

• 「後で記事にしよう。。。」はほぼ確実に記事にしません。（まれに思い出して記事にする事があるが）
• もちろん優先順位はありますが、得た知見はなるべく早いときに記事にするほうが良いです。
• 1ヶ月遅れただけでバージョンが古くなったり、他の問題が発生したり、同じ問題で詰まっている人が困ったりするかもしれません。

記事の中の文言・記載方法・インデントをなるべく統一して書く

• 例えば「laravel」というPHPのフレームワークを記事内に記載するとき下記の種類が想定されます。
  • Laravel
  • LARAVEL
  • ララベル
  • ららべる
• 流石にひらがなはふざけましたが、一つの記事の中で上記のような表記ブレが無いようにすると読みやすくなると思います。
• 記事が増えてくると全部の記事で表記を統一することは結構難しいし大変です。1つの記事の中で文言・テーブルなどの記載方法・インデントルールを統一することだけを意識して書くと良いかもしれません。

めんどくさくならないレベルで書く

• ある程度統一して、バージョン情報なども含めて記載することはもちろん大切です。
• しかしながらガチガチにマイルールを決めすぎたせいで記事を書くことがめんどくさくなってしまっては本末転倒です。
• 記載テンプレートを決めすぎずにとにかく記事として残すことが大切かと思います！

自分が過去に書いた内容でも躊躇せず書く

• 過去に自分が記事として取り上げた内容でも躊躇せず記事にします。（まるまるコピーしてちょっと語尾を変えるとかは流石にNG）
• 過去の自分と今の自分では知識量が違うはずなので同じ内容を取り上げるにしても別の観点からになります。
• これって実は「他の人が書いた別の観点からの記事」よりかなり有力な手がかりになったりします。（書いているのは過去の自分、その時何を考えてどういう経緯で問題解決や知見を得たのかが実体験で分かるから）
• 「同じ内容の記事は過去に書いたから、、、」とは思わず可能な限り書いちゃいましょう！新しく書いた記事に過去の記事のリンクを貼るととても更に良いかもしれません！

謝辞

ありがたいことに、こんな稚拙な記事ばかりの自分ですが見てくださってる方も居るようで、LGTMやコメントをいただけます。
また、何人かの方にフォローもいただけており、本当に嬉しい限りでございます。これもひとえに記事を見ていただいている皆さんのおかげです。いつも本当にありがとうございます！これからもできるだけわかりやすい記事を書けるように試行錯誤してゆこうと思います！