📝

最もシンプルな記事の書き方・考え方紹介

2023/08/29に公開

お詫び

Qiitaの元記事にて、区切り線を「---」で書いている場所があり、これがZennの記法に干渉して一部うまく表示できない記事がある事を認識しています。
全ての記事を精査しきれていないため、お手数ですがお見かけの際は教えていただけると大変喜びます。

はじめに

本稿はアウトプットの仕方の話です。
アウトプットする内容については、既に決まっているか書きながら考えるかしているという前提なので、本稿では触れません。
なお、トンチを利かせるなら

アカウントを作る
投稿するボタンを押す
必須項目を埋める
Qiitaに投稿

とすると記事を書いて投稿したことになります。
本稿ではこういう話はしません。

プログラミングに関係ない記事なのでは？

エンジニアのスキルアップの方法の一つ

記事をどうやって書くか？

まずはクオリティを気にせず、書きたいことだけを書いてしまいましょう。
といっても、書きたい事とは？というところから始めるべきだと思ったので、最もシンプルなアウトプットを記事っぽくする方法を見ていきます。

最もシンプルなアウトプット

一番初めに言ってしまいますが、学びをアウトプットするのに一番手っ取り早いのは箇条書きです。
たとえば座学など勉強会で参加していた時に、テキストがあればテキストから書き出したり、登壇者（スピーカー）の発言や要約を書き取っていると思います。
これをある程度フォーマットを整備してはめ込んでいくイメージです。

最もシンプルな記事の書き方

箇条書きにした内容に意見や考察を交えて、口語体または文語文で締めてみましょう。
それっぽい感じになっていくと思います。

どんな記事を書くか

再度言及しますが、記事の内容の話は本稿では触れません。
書くことは決めているけど、どんな記事にするか（育てるか）というお話です。

が、例がないと分かりにくいので、本稿ではこの記事を使っていきます。
具体的には、ライブライティングしていきます。リアルタイムに考えている事を無編集で書いていくのですが、その様子をお見せできないのが残念です。
ライブ動画で配信した方が良かったかな、とも思いますが、これやるとしたら別記事で来年になりますね…。

記事を書く目的を考える

備忘録を残したいとか、オンラインストレージの要領で使っていくなら深く考える必要もないです。
思いのままに書いてみてください。
タイトルの付け方は、ご自身のラベリングに合わせて設定すると良いでしょう。

問題は、読んでほしい記事を書く場合。
率直に言えば、記事の内容よりタイトルや宣伝を吟味した方が良いです。
極端に言えば、本文ナシの記事をいくつか作ってタイトルだけ変えてアクセス数の多かった記事から書きます。
これが最も効率よく記事を読ませる方法です。

なので、記事を読んでほしい場合は記事の内容を考える必要はありません。
そのため、以降では除外します。

読んでほしい記事を読ませる書き方、を考える前に

ようやく本題です。
が、実はここにも罠が潜んでいますので、解剖していきましょう。
大事なことなので繰り返しになりますが、良いコンテンツを書くのは、タイトルや宣伝で手堅く集客できる方法を見つけてから本文を書くことです。
記事を読んでほしい、ファンを獲得したいという部分にフォーカスしてお話していきます。

「ファンを獲得する」という点に絞ると、実はこれも記事を書く必要はありません。
今の御時世、記事を書くよりは動画サイトに投稿した方がよっぽどマシです。
乱暴に言えば、動かない絵と聞こえない音、音声への字幕が存在しない無名の人の発信には価値はありません。
つまり、私のこれらの発言は「読ませる」という観点においてほとんど価値がないことになります。

ただし、これは「ファンを獲得する」という点に絞った場合の話です。
獲得したファンにより主張や意見を丁寧に伝える事を目的にした場合は、ようやく文字で書く利点がでてきます。

なぜ記事を読んでほしいのか？

記事を書く時に「なぜ記事を読んでほしいのか？」と考えて記事を書いていますか？
最もシンプルに記事を書く事を考えた時に、なぜか抜け落ちている事が多い観点でした（私調べ）
これが無いことには方針を立てられません。記事を完成させることはできますが、結局のところ何を言っているか分からなくなります。
私も、１日寝かせて脳を休ませた後にセルフレビューを挟まないと支離滅裂だったり主張が行方不明になったりしがちです。
すなわち、品質の低い記事になってしまいます。

以下、どういう目的なら何を気にしなければならないか、の例を挙げます。
ただし、全て内容についてはウソや間違っているものは書いていないと仮定します。
どういう場合でもウソは書くべきではない（特にアフィリエイトは実害が発生します）し、間違っている場合（内容的にも、誤字誤変換など）はすぐに修正できる状態にしておきます。

アフィリエイトなら記事の品質より生産性を重視するのでこれでいいです。
１記事いくらで作るので、いちいち推敲やレビューなんてやってられません。
収益化システムにユーザー導線がしっかり作られていれば、ぶっちゃけ中身なんて何でもいいです。
その代わり、収益性が高い記事の導線を徹底的に解剖・研究していく事になります。記事を書くより面倒くさいし大変です。

ファンを固定化するなら、ユーザーの感情を揺さぶる演出や表現が出来ているか、記事の構成が起承転結（序破急）をしっかりと守れているかに着目すれば良いです。
文章以外に絵を多く取り入れてユーザーの視線を動かして面白さや見ごたえが重要なので、内容より表現です。
寄稿文書を書く場合などは、これを意識するとプロフィールページ（おすすめはTwitter）に飛んでもらいやすくなります。

内容を気にしなければならないのは論文や文書などです。
エンジニアがドキュメント化・ナレッジ化を考える場合はここに該当します。
おそらく、今回のメインコンテンツになるかと思います。

内容を熟慮すべき記事の目的を考える

もう一度振り返ります。

記事を書く目的は何か？
記事を読んでほしい目的＝記事を読んで、ユーザーに何をさせたい？

これを考えておいてください。
特に読んでほしい目的です。
分かりやすいのはトラブルシューティングですね。
記事の書き出しは「何に困っているのか」を定義して、以降解決手順を書いていきます。最後のまとめで、解決しなかった場合に参考になる他のトラブルシューティングへの案内を書く事で、ユーザーの問題解決に貢献する可能性が高い記事を作ることが出来ます。
これが最も簡単なケースでしょう。

ちょっとマーケター寄りの話になります。

アプローチ
困っている人を定義	読者が記事を読むことへの満足度やマッチ度が事前に分かる
解決手順	読者が欲しがっている内容。メインコンテンツ
未解決の案内	読者の不満を低減させ、親身に相談に応じている印象を与える

特定の名前を出すと回し者っぽいんですが、マイクロソフトコミュニティのサポートチームのメッセージは上記をかなり意識しながら対応されている印象です。
あの対応はそのまま記事にも活かせます。

ここではトラブルシューティングを挙げましたが、読ませる事を目的にする記事については本質的には同じです。
論文だとアプローチが変わるぐらいで、メインコンテンツの比重や構成がより難しく体系的になる以外は細かい事を気にしなくて良かったりします。

まとめ

シンプルな記事の書き方と、シンプルな記事の考え方について触れています。
書くだけなら簡単で、読んでもらう事を考えると難しくなるというお話でした。

正直、こんな事を考えながら記事を書くのは大変なので、読んでもらわなくていいからとりあえず書いとけ、が一番安心で幸せな状態だと思います。
なので、本稿に限らずアドベントカレンダーの記事、いやQiitaで書くような記事は宣伝ツールに乗せたりしていませんし、今後も乗せないでしょう。
敢えて言うなら、人事やスカウトが読んでみて「この人は面白いことを考えるな」と思ってもらったらそれでいいです。
彼らに対する導線だけ作れれば、読んでくれた場所が自サイトだろうがQiitaだろうが、あるいは数あるポートフォリオサイトほかにYoutubeなどチャンネル、なんならSNSでもいいと思っています。

あなたは、どんな目的で記事を書いていますか？
この機会に振り返ってみてください。

本稿の思考解説

では、上記までを本文として、以下は私が本稿を書くにあたって思考した事を書いていきます。
書いている側は事実上２画面で追いかけながら見ているので結構忙しいですが、漏れないように気をつけて書いていきます。

この記事を読んでほしいユーザーを考える

いつもはテンプレートの「対象読者」と「記事を読んでできるようになること」のどちらか、あるいは両方を採用しながら記事を書くようにしていますが、この記事では敢えて外しました。
テンプレートを使える人はいいんですが、最初は記事を書く時にテンプレートなんて用意してないですよね。
記事のテンプレートを使うのは、記事の品質を維持する事も目的ですが、オリジナリティーの表現にも貢献します。
とはいえ、ガチガチにテンプレートにしてしまうと面白みがなくなったりワンパターンになってしまうので、最初の挨拶と最後の挨拶はテンプレート化しないように心がけています。

今回は元々読ませる事よりも、アドベントカレンダーを埋めるために書いているので備忘録の面が強いです。
結局のところ、記事を読んでほしいという意識が私の中で低いのと、今更ですがライブ感を大事にしたいので、思考解説については無編集・ノーレビューで投稿しますね。

せっかく時間をかけて読んでくれるのだから、何か持って帰ってほしい

念のため、こちらでも言及しますが本稿はマルチポストしています。インデックス記事（Qiitaだと１日目）でも触れていますね。
サイト側だと、Web業界の実情とかについて補足して気付きを与えようとしてみました。
Qiita側だと、能書きよりは実務面の話が聞きたいかな、と思ったのでドキュメンテーションを厚めにしようと思いました。
この２つを一気にやらないといけないので、結構忙しいです。考えることが多くて疲れますね…。

ちょっと喋らせて

この上で、各サービスの利用規約を意識しながら書いています。サービス側でマルチポストを禁止していない（質問系だったらマルチポストはどうかな、と思いますが、本稿は質問記事ではないのと、規約削除を許容しながらコンテンツを守るための施策としてやっています）ですが、ユーザー分散が発生するのでやりすぎるのも考えものですね。
１ページ目とかさわりだけ書いて、２ページ目を自サイトに誘導するという手もなくはないですが、多くのサイトで宣伝行為を禁止しているはずです。
なので、マルチポストをしているけど宣伝はしてないです。おかげでPV数（閲覧者）が正しく計測できていません。
元々の目的がQiitaのアドベントカレンダーなので、これを重視して他はQiitaの規約に少し寄せてあげるぐらいです。

経験則から考える

ウソは書いてないんですが、いつか私の経験（本稿）も古くなるよなぁ、という危機感を持っています。
今日までの記事に【2022年版】みたいなタイトルをつけていたんですが、ほぼコレのせいです。
来年のアドベントカレンダーを書いている頃に、本稿を読み始める人が出てきた時に本稿を鵜呑みにされると、もしかしたら齟齬や不利益が出てしまうんじゃないかなぁ、という懸念があります。
古い記事は消してしまえ！という主張は同感ですが、いつかの日に誰かを救う（たとえば、最後の更新が5年前の記事だけど役に立ったりする）可能性を考えると、消すのも抵抗があります。
稼ぐのが目的なら、実は古い記事はさっさと消してしまって、同様の内容を書いている最新の記事へのリンクだけ貼り付けてしまった方が古い記事のSEOパワーを使いながら収益を維持、もしくは向上を測れます。

結局、古い記事（URL）は消されなくなるのでした。

まとめ

実はですね、私は記事の一番最後に「まとめ」とか書いてあって「いかがでしたでしょうか」とか書いている記事が好きではありません。
アフィリエイトサイトで使いまわされた文言なので「この後何か宣伝するんだな？」と疑って以降の本文は読まずにブラウザバックをします。
そのくせ、普段は「バンバン稼げ、閲覧者の嬉しいとか喜びの声がイコール売上だと思え」と指導している立場ですが、「いかがでしたでしょうか」なんて言われたら「本文に自信がないくせに収益化狙うなんて失礼だと思わないのか？」なんて毒づいてます。
我ながら心が狭いですね。

完走した感想

ないです。
明日の記事の準備とかもありますが、完走した直後は脳が疲れているのでゲームしたい！ぐらいしか考えてないです。
本格的に内容を見直して手を加えるのはいったん寝かせてから（私自身も寝てから）にしています。

記事の表現は若干変わるかも知れませんが、内容は変えないようにします。
これもいつものですね。その時に改めて何か思うところがあるかも知れません。

GitHubで編集を提案