📖

初心者が技術記事を書くことへの所見

2021/08/05に公開1

初心者が技術記事を書くこと

https://zenn.dev/kaityo256/articles/save_the_earth

https://twitter.com/kemomimi_oukoku/status/1422637122809307140

なんだか世間で初心者が技術記事を書くのがどうだという話が盛り上がってるようですので、個人的な考えをまとめてみます。

「初心者でもどんどん技術記事を書くべき」という主張について

まず、「初心者でもどんどん技術記事を書くべき」という主張について思うことがあります。

初心者が書きがちな記事:非常に簡単な記事

この手の主張は非常に簡単な内容の記事を想定しているのかなと思います。

たとえば、Node.jsのインストール手順をまとめた記事なんかはNode.jsについての知見を知りたい人には全く不要ですが、初心者の知見としては十分ありそうですね。

実際のところ、このような記事にわざわざ邪魔だとコメントがつくことは稀なので本当に初心者が恐れているのだろうかという疑問はあります。

初心者が書きがちな記事:誤った記事

type scriptは型付きのコンパイル言語なのでjava scriptよりも高速に動作します。

たとえばこんな記述がされた記事が何かしら(ZennでもQiitaでもTwitterでもなんでもよいです)でバズったとします。このくらいの誤りがある記事がバズるのはしばしば見かけます。

ご存知のとおり、TypeScriptはJavaScriptにトランスパイルされますし、型チェックが自動挿入されるのでチューニングしたJSより速くなることはまずありません。

さて、このような記事に対して、誤りの指摘コメントが飛んできます。言語のスペルについてもTypeScript, JavaScriptだという指摘が来るかもしれません。めちゃくちゃな記事だと揶揄するツイートもされるでしょう。

冒頭の2件目のツイートはまさにQiitaでこのようなマサカリ[1]が飛んできた人のものです。

さて、「初心者でもどんどん技術記事を書くべき」論では「めちゃくちゃな記事だと揶揄する声なんか気にするな」と言われがちですが、果たして初心者が「誤りの指摘コメント」に対して対処できるのでしょうか。「誤りの指摘コメント」への対処が上手くいかず余計に揶揄されることも少なくないでしょう。

対マサカリのテクニックや心がまえも教えずに気にせず記事を書けばいいと勧めるのは無責任なのではないかと感じます。

初心者が技術記事を書くときに気をつけると良いポイント

テクニックや心がまえを教えずに書けと言うのは無責任と言った手前なのでいくつかポイントを書いておきます。

「マサカリが飛んでこないようにする」「マサカリが飛んできたときの対処」について書いておきます。

避けた方がよい内容

初心者のうちは避けた方がよい内容について列挙してみます。同じような内容の記事でも構成次第でマサカリの原因を排除できます。

コピペ記事

そもそも他のサイト・記事からのコピペは著作権侵害です。初心者以前の問題なのでやめましょう。

比較する内容

JavaScriptの日付ライブラリ dayjsdate-fns を使ってみたので比較してみた というような記事を書きたくなるかもしれません。

その記事で低評価にされたライブラリの方が好きなユーザーからマサカリが飛んでくる要因になります。

  • JavaScriptの日付ライブラリを使ってみた: dayjs編
  • JavaScriptの日付ライブラリを使ってみた: date-fns編

と2つの記事に分けて書いたほうが無難です。

特に避けるべきなのは言語の比較です。

大規模開発ではJavaやC#などの使い古された言語が使われますが、WebではモダンなGoやTypeScriptが使われます。

こんなことを書いたらマサカリが飛んできて嫌な思いをするだけです。その言語に精通した人があなたを目掛けて一斉に批判を投げつけてきかねないので絶対に避けましょう。

批判する内容

前項と通じる内容です。初心者の批判は真っ当であることよりも使い方を誤っていることの方が多いです。誤った批判はマサカリを誘発します。

「○○というライブラリは××できないからダメだ」という批判を書いて得することはまずありません。

「○○というライブラリで××できますか?」と 日本語版スタック・オーバーフロー などの質問サイトに投稿したほうが良いでしょう。

シリーズ記事

途中で飽きてしまったときに中途半端な記事になってしまいまうので、シリーズであると明示はしないほうが良いと思います。

シリーズであることをあらかじめ書かずに「前に書いた記事の続編記事を書きました」と投稿していくほうが良いです。

マサカリが来たら

気をつけていても誤った内容を書いてしまうことはあります。これは仕方のないことです。そうして指摘されたときの対処についても軽く触れておきます。

記事の修正

まず何を指摘されているか理解します。修正した方が良い指摘だったら適切に取り入れるようにしましょう。

TypeScriptは型付きのコンパイル言語なのでJavaScriptよりも高速に動作します。

に対して

ユーザー名: shitekiman
TypeScriptはJavaScriptにトランスパイルされるためJavaScriptより高速になることはありません。

というコメントがついたとします。

よく見かけるのはこのような修正です。

TypeScriptは型付きのコンパイル言語なのでJavaScriptよりも高速に動作します。

2020/02/02 20:20追記
shitekimanさんから、TypeScriptはJavaScriptにトランスパイルされるためJavaScriptより高速になることはないとの指摘がありました。

これはかなり悪い修正です。

読者にとっては矛盾している情報が提示されているだけで、どちらが正しいのか明示されていません。

なによりコメントをコピペするだけでは書き手として知識を更新する機会を失ってしまいます。

TypeScriptは型付きのコンパイル言語なのでJavaScriptよりも高速に動作します。

2020/02/02 20:20追記
shitekimanさんから、TypeScriptはJavaScriptにトランスパイルされるためJavaScriptより高速になることはないとの指摘がありました。

打ち消し線を入れるだけでも印象が違います。

議論する

コメントに納得がいかないならコメントしてきた人に返信するのも良いでしょう。読者にとってはこの議論こそが有意義な読み物になることもあります。

自分のものにする

自分が間違えた内容は他の人も間違えやすい内容かもしれません。他の人の記事で同じような誤りがあったら同様に指摘できると自分の成長にも繋がります。

気にしない

なんだかんだで気にしないことも大切でしょう。「これも追記したほうが良いのでは」というコメントをすべて対処する必要はありません。

ただし誤りを書いては放置を繰り返していると低品質な記事ばかり書いている人だと認識されてしまいます。このあたりのバランスは難しいところです。

おわり

おわりでーす。

脚注
  1. 技術的誤りへの指摘 ↩︎

GitHubで編集を提案

Discussion

Error401Error401

今日は立て続けに技術記事を書くことについての記事を読みましたが、指摘マン(笑)の主張もちょっと聞いてください。
私も初心者でもどんどん記事を書いて投稿すれば良いと思っていますが、投稿先にも気を配って欲しいと思ってます。技術記事が集まるQiitaやZennに、その記事はふさわしいのかと。個人ブログであれば何をどう投稿しようと、第三者がとやかく言うことではありません。

少し前までは、Qiitaに「学習○日目」的な記事が投稿されるのを苦々しく思っていましたが、もうあきらめました。黙って無視リスト行きです。
新着順に記事リストを見ることが多いため、ノイズは非常に困ります。まぁただ止めることはできないのでそれはもうあきらめます。

今、ひとつだけ気になっているのは、特にQiitaでなんですが、明らかに間違っているのにLGTMが数十ついてたりする記事があることです。ひょっとしたら、書かれた記事を信じてしまっている人がLGTMをつけてるのではないかと思うと、気が気ではありません(余計なお世話ですが)。

最近は、指摘する時間がもったいないのでそういう記事も見なかったことにすることにしていますが、それでも我慢できずに指摘コメントつけたりしてます(笑)。