この文書について
この文書は、2025年1月26日に私 @debiru_R によって記述されました。
私はいちエンジニアであり、Writer(執筆者)でも Editor(編集者)でもないので記事執筆に関する専門的な知識は有しておりません。しかしながら、Web エンジニアとして技術記事を執筆したり LT (Lightning Talk) イベント等で情報発信する機会は多くあります。
この文書の内容について不適切な箇所がありましたら、私 @debiru_R までお知らせください。
今回は、記事を執筆しようと言われてもなかなか記事を書いたり情報発信をするのが億劫な人に向けて、記事執筆や情報発信に関する考え方をお伝えし、その人に合った形での情報発信を積極的に行っていくためのノウハウについてお伝えしたいと思います。
なお、本記事の執筆にあたっては、uhyo 氏の記事「技術記事の3類型: 初心者による技術記事執筆のすすめ」を大いに参考にしています。
概要
「記事を執筆しようと言われても記事を書く気にならない」という声をよく聞きます。記事を書く気にならない要因として考えられる項目は次の通りです。
- 記事を書く時間がない
- 記事のネタが思いつかない
- 自分が記事を書いても誰の役にも立たない(価値がない)と思っている
- 記事を批判される(マサカリが飛んでくる)のが怖い
以下では、「記事執筆のプロセス」と「技術記事の類型分類」に注目し、上記の懸念事項を解消しながら記事執筆を行う方法について紹介します。
記事執筆のプロセス
記事執筆には、次のようなプロセスがあると考えます。
- 記事のネタを考える
- 記事の構成を考える
- 必要に応じて、参考文献の確認や技術調査をする
- 記事の内容を記述する
- 必要に応じて、スクリーンショットや画像データを用意する
- 内容に誤りがないかをチェックする(校閲)
- 誤字・脱字・衍字・表記揺れなど、表記上の誤りがないかをチェックする(校正)
- 記事を公開する
- 閲覧者の反応やフィードバックを確認する
- 有益なフィードバックがあれば記事に追記する
私の場合は、このような流れで記事執筆を行います。少し細かく書いたので、ステップ数が10個と多めになっていますが、概ねこのような流れで執筆作業を進めることが多いのではないでしょうか。
これだけのプロセスを一人でやろうと思ったら、それはそれなりに大変で、時間もかかってしまいます。
専門家たちの存在
職業として「執筆者 (Writer)」「編集者 (Editor)」「校正者」「校閲者」という名前を聞いたことはあるでしょうか。
- 執筆者:ステップ 1, 2, 3, 4, 5, 9, 10
- 編集者:ステップ 1, 2, 3, 5, 8, 9
- 校正者:ステップ 7
- 校閲者:ステップ 6
記事執筆は、執筆者がメインではありますが、主に作業前半のサポートを編集者が、作業後半のサポートを校正者・校閲者が行います。
編集者については、私が編集というお仕事をきちんと理解する機会がこれまでなかったので不正確なことを言っていたら恐縮ですが、執筆者と伴走して記事のネタ考察から内容の記述までをサポートしたり、場合によっては校正・校閲の作業を行ってくれる存在です。
校正者・校閲者については、その作業がそのまま職業として確立しているほど、重要かつ専門的な作業になります。プロの校正者、プロの校閲者はそれだけで職業として成り立つほど崇高なお仕事をされているということです。プロの校正者・校閲者が特に活躍されているのは、何百ページもある書籍のような分量の多い文書、あるいは執筆記事が多く何度も(異なる)文書のチェックが必要とされるような環境での校正・校閲です。(そのようなケースでは素人にはとても対応できません)
これらを一人で行うことは難しい
記事を執筆したいと思ったとき、何も考えなければ「執筆者」以外の役割である「編集者」「校正者」「校閲者」も自分一人で行う必要があります。知識と経験があればそれが可能な場合もあり、情報発信を多く行っている個人技術者は一人ですべてのステップを対応していることがあります。
しかしながら、経験の少ない「執筆者」であれば、それらを一人ですべてこなすことは難しいでしょう。これを解消する方法として、「メンター (Mentor)」を誰かにお願いする方法があります。編集者としての専門的知識がなくとも、前述の編集者の役割としてメンターを引き受けてくれる人は意外と多くいるのではないでしょうか。
メンター (Mentor) とは、対象者に対して支援・指導・助言を行う役割の人のことをいいます。語源は、ギリシア神話に登場するメントール (Mentor) であり、メントールが歴史的に行ってきた現在のメンターと言われるような役割を実践する人を指して、英語ではメンター (Mentor) と呼ばれるようになりました。また、メンターが行う役割(支援・指導・助言)のことを「メンタリング (Mentoring)」といいます。
技術記事を書いたりしてみたいけれど、時間が足りない、何から手をつけたらよいか分からないという人は、Twitter (X) や所属するコミュニティ等でその旨を発信してみてください。発信したい技術分野なども併せて記載すれば、その分野に関心のある有識者がメンターとして手伝ってくれるかもしれません。
もしこの記事を読んで、メンターが欲しいけれど誰に頼めばいいかわからないという人がいたら @debiru_R にご相談ください。サポートできる技術分野であれば私がお手伝いさせていただきます。
技術記事の類型分類
uhyo 氏の記事「技術記事の3類型: 初心者による技術記事執筆のすすめ」では、技術記事は「学習ノート」「教科書」「論文」の3類型に分類されると示されています。(下表は記事より引用)
類型 | 記事の目的・価値 |
---|---|
学習ノート | 筆者による理解の復習・確認やアウトプットの練習のために書かれる。 |
教科書 | 読者に対する知識の提供を主な価値とする。 |
論文 | 単なる知識だけでなく、アイデアや技術の新規性を提供する。 |
uhyo 氏の提唱するこの分類については、私も概ね賛成の立場です。本記事では、uhyo 氏の提唱する分類を拡張する形で私の考えを述べたいと思います。
debiru の考える技術記事の類型分類
「技術系ポエム」「学習ノート」「技術レポート」「教科書」「技術論文」の5類型を提唱します。
類型 | 記事の目的・価値 |
---|---|
技術系ポエム | 筆者の知識や感想を記録するもの。内容の正確性は問わない。 |
学習ノート | 筆者による理解の復習・確認やアウトプットの練習のために書かれるもの。 |
技術レポート | 技術情報を取りまとめたもの。手を加えることで教科書となる。 |
教科書 | 読者に対する知識の提供を主な価値とするもの。 |
技術論文 | 既知の情報だけでなく、筆者の独自のアイデアや未知の情報を提供するもの。 |
「論文」を「技術論文」としました。単に論文というと「学術論文」を連想しやすく、それとは区別されるものであるため名称を改めました。さらに「技術系ポエム」と「技術レポート」を追加しました。
類型分類とエンジニアの相性
記事を目にする可能性のあるエンジニア(技術者)である読者を初心者・中級者・上級者・専門家と4つに分類し、さらに筆者自身も含めてその相性をまとめた場合、次の表のようになるでしょう。
相性の値は、「◎(有益である)」「○(価値がある)」「△(理解できない)」「―(価値がない)」「×(害悪である)」とします。
技術系ポエム | 学習ノート | 技術レポート | 教科書 | 技術論文 | |
---|---|---|---|---|---|
筆者自身 | ◎ | ◎ | ◎ | ○ | ◎ |
初心者 | × | × | △ | ◎ | △ |
中級者 | × | × | ○ | ◎ | ○ |
上級者 | × | △ | ◎ | ― | ◎ |
専門家 | × | ○ | ◎ | ― | ◎ |
書いた記事は、筆者自身にとっては価値のあるものになります。ただし、「教科書」は自身ではなく立場の異なる他者へ向けたものであるため、自身にとっては少し読みにくいものとなる場合があります。
縦軸で見ると、「技術系ポエム」は自身以外「×(害悪である)」になっています。これは、技術系ポエムとして分類した記事は、著者の感想や思い込みによる主張が多く、技術的に正確な情報を得られる可能性が極めて低いためです。内容の正確性が著しく低い場合は、他人にとってその文書は害悪でしかないでしょう。
「学習ノート」もそういう意味では、技術的な正確性が低い可能性があります。しかしそのような文書も、専門家から見れば価値のあるものとなる場合があります。専門家は、他人に情報発信する上で、初学者をも対象読者とする文書を書くことがあります。その際に、初学者がどのような理解をしているか、どのような誤解をすることが多いかを知るためには、初学者の学習ノートというものが参考になる場合があります。
「技術レポート」は、主に中級者以上が技術的な作業をした際の作業ログであったり、技術系イベントに参加した際のブログ記事が該当します。これは「学習ノート」でもなければ「教科書」でもないため、uhyo 氏の分類に対して新規に追加したカテゴリです。
「教科書」は、文書としては「よく作られたプロダクトの公式ドキュメント」や「教材として作られた技術的記事」が該当します。教科書と一概に言ってもその実体は様々なものがありますが、主に初学者・中級者に向けて、上級者以上が書いたドキュメントが該当する場合が多いでしょう。教科書は、上級者にとって既知のことしか書かれていないことが多いため、上記の表では上級者以上には「―(価値がない)」という評価をしています。専門家にとっては、教科書は査読(批評)するものであることが多いでしょう。間違いがあれば修正を依頼します。
「技術論文」は、体系的に言語化することが容易ではない技術的内容について、それを筆者の言葉で言語化したり、その技術的内容のベストプラクティスあるいはアンチパターンを可視化したりするなど、これまで存在しなかった資料として作成される文書が該当します。
誤ったコンテキストの表明
前述の表で「×(害悪である)」という評価がありましたが、著者(発信側)が「これは学習ノートです」ということをきちんと伝えていれば、その文書が公開されたところで、読者(受信側)には悪影響はありません。問題なのは、読者が教科書だと思って読んでいる文章の中身が技術系ポエムであるような場合です。
「これは何々です」という表明を明示的にすることは少ないですが、文書の冒頭あるいは末尾にそのコンテキストを明記することや、文書の書き方を工夫することで、書かれた文書がどのカテゴリ(類型)に分類される文書であるかを示すことができます。読者はそのコンテキストを読み取って、読んでいる文書がどういうカテゴリのものであるかを解釈した上で閲覧したり、批評したりします。
このとき、誤ったコンテキストが表明されていると、書き手と読み手の間に矛盾が発生します。書き手は「技術系ポエム」「学習ノート」を書いているつもりだったのに、読み手には「技術レポート」「教科書」のように読めてしまう場合などがあります。この状況では、読み手が、書き手の意図しない批評(フィードバック)をする場合があります。
書き手が「マサカリが飛んできた」と思ってしまうような状況はこうして起こります。マサカリとはいわば、想定していない攻撃的な批判です。「これは間違っている」だとか「こんな間違ったことを書くな」だとかそういう種類のフィードバックが飛んでくるのです。フィードバックを書いている側には、無闇矢鱈に攻撃的な批判をする人もいますが、一方で建設的に(攻撃する意図がなくとも)マサカリと捉えられかねないフィードバックをする人もいます。
建設的にマサカリと捉えられかねないフィードバックをする人は、「技術レポート」「教科書」だと思って読んだ記事が間違っているからフィードバックをするのです。「技術系ポエム」や「学習ノート」だと分かっている記事に対しては「間違っている」などという指摘はわざわざしません。間違っていて当然なのですから。問題はマサカリを投げられることではなく、その記事で誤ったコンテキストの表明をしていることにあるのです。
情報発信と責任
情報発信には責任が付き纏います。誤った内容の記事、特に誤った技術記事は人々に誤解を与え、不利益を生じさせるため害悪であり淘汰されるべきであると考える有識者は多く存在しています。そのような有識者は、誤った内容の記事を見つけると、コンテキストを確認した上でマサカリを投げるべきだと判断すれば躊躇なくマサカリを投げます。
マサカリを意図せず投げられないようにするには、次のことに注意すればよいのです。
- 「技術系ポエム」は、書くことは筆者自身にとって有益だが、それを公開すべきではない。
- 「学習ノート」は、書いて公開することは結構だが、学習ノートというコンテキストであることをきちんと表明する。
- 「技術レポート」は、きちんと校閲する。
- 「教科書」は、きちんと校閲、校正する。
- 「技術論文」は、きちんと校閲、校正をした上で、その根拠や出典を適切に明記する。
「マサカリが投げられるのは怖い」という状態から「マサカリ歓迎、不適切なマサカリが飛んできたら跳ね返す」という心持ちまで変化させるのは最初は大変かもしれませんが、技術記事を何本も書いているような歴戦の猛者たちはそのような心持ちに達しています。情報発信をするからには、誤った情報を誤ったコンテキストで広めないことへの責任があるのです。その責任を果たしている以上は怖がるものはありません。
フィードバックと責任
筆者だけでなく、読者が批判(フィードバック)する際にも責任は付き纏います。マサカリと捉えられかねない振る舞いをする際には、それ相応の覚悟が必要です。間違いを指摘する際には、相手とのコミュニケーションをよく考えなければなりません。これまでコミュニケーションをしたことのない相手に向かって、丁寧でない物言いは不適切なケースが多いです。
先ほど、建設的にマサカリを投げる人もいると書きましたが、マサカリと一言に言っても、丁寧なマサカリから、攻撃的なマサカリまでいろいろあります。筆者として「マサカリが飛んできた」と感じたときも、どういう人がどういう文脈でマサカリを投げてきたのかを見極め、落ち着いて対応することが肝心です。中には不適切なマサカリを投げてくる人もいます。読者が多くなると理不尽なマサカリを投げられることもありますが、あまり心配しすぎないようにしましょう。
マサカリを怖がる必要はありません。攻撃的なマサカリが飛んできたとしたら、そのマサカリを投げている人がおかしいのです。そうでなければ、記事の内容に致命的に問題がある可能性があります。でもそれは、誤ったコンテキストを表明せず、校閲プロセスを実施していれば防げるはずです。
情報発信をしよう
この記事の冒頭で、記事を書けない要因として挙げたものは次の項目でした。
- 記事を書く時間がない
- 記事のネタが思いつかない
- 自分が記事を書いても誰の役にも立たない(価値がない)と思っている
- 記事を批判される(マサカリが飛んでくる)のが怖い
時間の確保については考え方を変えてみましょう。時間がないと感じるのは、そもそも記事を書く必要性を感じていないからです。価値のないと思うことに時間を割けないのは当然です。「こんな記事を書いて、自身のスキルアップにつなげたい」「こんな記事を書いて、読者に喜んでもらいたい」といった思いがあれば、記事を書く時間を捻出することは難しくないと思います。計画的でなくてもよいのです。眠たくなったときに仮眠するのと同じように、記事を書きたくなったときに執筆してみましょう。一度に書ききらなくてもよいのです。書きたい気持ちがあれば、時間は自然と生まれます。
記事のネタが思いつかない、という点についても考え方を変えてみましょう。記事を書くのは目的ではなく手段です。ネタがあって、それを誰か(将来の自分自身も含む)が見られるようにしておきたい、という前提があって記事を書くのです。作業ログ(技術レポート)なんかは私の場合、将来の自分自身のために書いています。「記事を書かなきゃいけないけど何を書こう」ではなく「何か伝えたいことがあるから記事を書こう」と考えられるようになってください。
自分が記事を書いても誰の役にも立たないと思っている、という話はよく聞きます。でも安心してください。あなたの発信する情報を楽しみにしている人は意外といます。あなたでないと書けない、知り得ない情報というのはたくさんあるのです。記事の執筆はナンバーワンを目指すものではありません。誰かにとってのオンリーワンでよいのです。例えば JavaScript の記事を書くのに知識が不十分だから書くのが億劫だ、と思っている人でも、JavaScript について知ったことや困ったことを記事にすることで、たまたま同じことで悩んでいる人にとっては役に立つわけです。しかもその記事はおそらく上級者には書けません。上級者には初心者を助けることは難しいのです。初心者を助けるのは初心者であるあなたなのです。
マサカリが飛んでくるのが怖い、という話もよく聞きます。これについては前述のセクションをよく読んで、自身の責任をきちんと果たすことに尽力しましょう。責任を果たしている以上は怖がることはありません。
おわりに
技術記事の執筆は、難しいとか大変だという気持ちの人もいるかもしれません。私自身もそのように感じることはしばしばあります。それでも、伝えたいことがあるから記事にしたい、という気持ちが強くなると筆を執るようになります。この文書自体もそうです。この文書は、とあるイベントで LT 発表をする予定がありそのネタとしてスライドでも作ろうかと思ったのですが、記事の方がきちんと書けそうだと思って書き始めたのがきっかけです。
最近は、Qiita や Zenn といったサービスを使えば Markdown 表記を用いて簡単に記事を書くことができます。また、記事という形でなくとも、Twitter (X) でリプライツリーを自身で作ることで情報発信するというのも有効な手段だと思います。
どのような形でもよいので、情報発信をして、関心のある技術分野についてみんなで議論したり意見交換してみてください。とても楽しいディスカッションライフが待っています!ネタがなければ、この記事の感想を URL を添えてツイートしてみましょう。それだけで、あなたの情報発信は始まります。始めよう、情報発信。
最後に、参考文献を示しておきます。