📰

【技術記事】Zennで技術記事を書くときに最低限これだけは意識したい6つのこと

に公開

はじめに

https://zenn.dev/noranuko13/articles/b30c8ed65e8e27

対象

  • Zennで技術記事を書いている方向け。

いいねを付けて大丈夫か

どうも。新着記事一覧から投稿者の記事一覧に飛んで、読めそうな記事を読んでいいねを付けていく運動を実施中の野良ぬこです。

いいねの価値を考える日々。極論「いいねはタダ」だ。ハードルを上げようと思えばいくらでも上げることができる。下げようと思えばいくらでも下げることができる。もう記事を投稿しただけで偉い。言語化しようとしただけで偉い。もうそのくらいで付けていいんじゃないか。

自問自答しながら、しかしそうはいっても、いいねを付けるか迷う記事はある訳で。

逆に考えるんだ。迷うのには明確な理由があって、そこさえ直してくれればいいねが付けられるんだ。それを発信すれば一つ記事になるじゃあないかと。

Zennで技術記事を書くときに最低限これだけは意識したい6つのこと

マークダウンの見出しを使う

本当に初心者の方におかれましては、マークダウンという言葉を知らないということもあるのではないかと思います。Zenn公式様が記事を公開してくださっておりますので、まずはそちらに一通り目を通すのが良いかと。

https://zenn.dev/zenn/articles/markdown-guide

https://zenn.dev/zenn

どんなに記事の内容が良くても、「そんなことすら調べずに投稿している人の記事」という先入観が付いてしまいます。第一印象は大事です。清潔感です。身だしなみです。本当にただメモ書きを貼り付けただけのようなマークダウンは、文字が詰まってしまって読みづらいです。

最初から色々なものに手を出すのは大変なので、せめて見出しだけでも使いましょう。

ある程度の分量を確保する

記事の内容にもよるので一概に何文字とはいえません。無理に内容を膨らませて昔の週刊漫画雑誌のように引き伸ばす必要もありません。何か一つお土産を持って帰れる、そんな記事であれば長さは関係ないのだと思います。

リンク集やまとめ記事であれば自然とリンクが多くなり、それ以外の本文が少なくなってしまうこともあるでしょう。その記事を読んでエラーが解決するのであれば、スタックオーバーフローくらい短い文章でも記事は成立する筈です。逆に長々と書かれる方が面倒に感じることもあります。

とはいえ本当に2,3行しか書かれていないし、タイトルとほぼ同じ内容をただ繰り返されても、正直にいえば困ってしまう。いくら何でもいいねの価値がジンバブエしてしまう。そうなるとやはり、いいねを付けるのをためらってしまいます。

著作権を守っているのが分かるようにする

僕・私は守っているから大丈夫、ではないです。守っているのが第三者から見て分かるようにするということです。

自身の考えや現場経験をまとめた記事など、あくまで自身から出たアウトプットなどなど、明らかに不要なものは除外するとして。何らかのドキュメントを参照し、参考文献として書籍を用いているケースでは、出典が明記されているかどうかが問題になります。

また著作権的にグレーな画像やユーザーアイコンが使われている場合があります。様々な歴史的経緯は察しますが、ここには趣味で活動している個人だけでなく、仕事で事業として技術記事を投稿している企業や事業主もいます。ビジネスとしてコンプラ的に怪しいものを宣伝できません。

いや趣味の範囲ですらTwitterではやれパクツイだのAIだの言われて、いいねをそっと外す人もいるくらいです。もう時代は変わったんです。いつまでもニコニコ動画に無許可でMADを上げていたような頃のままの倫理観で記事を書くのは、自分を守る意味でやめましょう。

有料コンテンツの要約だけを書かない

読書レポートや勉強結果など、要約を並べるタイプの記事があります。確かに記事を読むのに必要な情報であれば、要約あるいは引用として適切に記述する必要は認めましょう。

問題はどの部分が要約で、どの部分が引用で、どこからが本人の文章か分からないような記事です。ともすれば本人のアウトプットが皆無で、ただ書籍の中身を羅列しただけ、ということもあります。引用にも作法がありますので学びましょう。

一般公開されている論文や動画なら(良くないことではあるが)ともかくとして、有料販売されている教材や書籍の中身を、自身のアウトプットを交えずにただ並べるのは、言葉を選ばずに言えば劣化版ファスト映画みたいなもので、飯の種にしている人がいる以上は問題があると思います。

https://zenn.dev/noranuko13/articles/b36cfbcc5bc77c#プロンプト1%3A-あらすじや要約を禁止する

AIではなくあなたが著者になる

AIを使うなとはいいません。私も部分的に毒抜きが必要なケースや、絵文字を選ぶのが面倒なときに相談することはあります。推敲や誤字・脱字のチェックに利用している人もいるでしょう。

しかし記事を書いている主体がAIになってしまっていると、ちょっと厳しいです。

  • 見出しやリストの先頭に絵文字が入っている。
  • 特徴的な敬語など、AIが書いたと感じる表現が随所にある。
  • 記事の8割がAIの出力結果のコピペになっている。

大抵の場合、記事の先頭に注意書きなどの記載は見受けられません。むしろ界隈周辺の騒動を知っているユーザー層の方が積極的に「この記事はAIによって〜」から始まる注意書きを載せています。恐らくそこまでリテラシーが追いついていない状態で記事にしているのでしょう。

著作権のときに第三者から見てという話をしましたが、AIでも同じです。どんなに本人が「自分で書いた」と言い張っても、今正に記事を閲覧しているユーザーには弁明のしようがありません。

一度、「AIで低品質な記事を量産する人だ」と認識されたら、そのレッテルはそのアカウント名で一生剥がれませんので、ブランディング的にもよろしくないです。AIに聞いて分かることは、記事を読まずにAIに聞けばいいので、それをコピペして周知することに大した付加価値はないです。

あくまで記事を読みに来る人は、あなたのアウトプットを見に来ています。なのであなたではなくAIが全面に出てくる記事になってしまっているのであれば、考え直す必要があるでしょう。

公開前に記事を読み返す

いつまで経っても誤字・脱字はなくならないものです。自分が過ちを犯した前提で、隅から隅まで読み返してみましょう。それでも投稿した後に気が付いて直すまでが投稿フェーズです。

明らかにマークダウンのコードブロックや表が崩れている投稿も稀に見かけます。一度でも自分の書いた記事をプレビューで確認していれば防げるミスです。書いたコードを動作確認しないでプルリク出すタイプの方でしょうか。敬遠されるのでやめましょう。

読み返すのは書いた直後ではなく、数日置いてからの方が効果的です。私の場合、接続詞が別の意味で成立してしまうことや、文章の途中から能動・受動が入れ替わるなど、読めなくはないけれど二度見になってしまうようなものを時々発見します。

ミスりがちなポイントはある程度決まっているので、把握できたらチェックリスト化して、毎回確認するのが良いと思います。

おわりに

元がAIの出力であれ書籍に書かれていることであれ、ノート代わりのテキストファイルにまとめ直すことを止めはしません。備忘録と題した上で公開することもできるでしょう。

しかし自分だけのメモなら、公開しないという選択も取れます。GitHubに別のリポジトリを作成して、Zenn CLIでもObsidianでも好きなエディタやアプリを使って、自分だけのメモ帳にするという選択肢もあります。

記事を公開するということは、画面の向こう側の誰かを相手にするということです。気を付けなければならないことも沢山あります。なのでもしその辺を考えたことがなかった方は、この機会に一度立ち止まって考えてみてはいかがでしょうか。

Discussion