Qiitaで技術系の記事を書く時に気をつけていることという記事が大変参考になったので、便乗してこの記事では僕が面白いと思ったQiitaの記事の内容をパターン分けして書いてみたいと思います。
面白いと思った記事は、長くても興味を持って集中して読むことができたり、読んだあとで勉強になったと思えるものが多い印象です。この記事では僕が今まで読んで「面白い」と思った記事を振り返りながら、なぜそれが面白いのかを考えつつまとめてみたいと思います。
注１：あくまで僕の主観による内容ですので、記事はこう書くべき、というものではありません。
注２：面白い記事がイコール「ストックされる記事」ではありません。ストックされるためのテクニック的な記事ではありませんのでご注意ください。
詳しくは後述しますが、面白い記事にするにはそれなりにいろいろ考えた上で書く必要がありますので、書く側としてもこの記事で紹介するパターンを意識することでより多くのことを調べたりより深く考えたりすることになり、結果として記事を書いて公開すること自体がスキルアップにつながるようになるのではないかと思います。
というわけで本文です。
パターン１：思考や作業の過程が書かれている
単純な「この時はこうするのが正解！」という内容の記事よりは、多少曖昧な部分があっても考えたことや試したこと、そこから分かったことなど、筆者の経験が流れで書かれていると、より共感しながら、または具体的にイメージしながら読むことができます。
人間の頭は箇条書きより文章の方が頭に入りやすいということをどこかで聞いたことがあるのですが、このパターンがまさにこれかな、と思います。
例えば、以下のような記事です。
「この場合はこれが正解！」系の記事も簡潔で良いのですが（そして何かでハマった時にだいぶお世話になっていますが）、この類の情報はちょっとでも条件が変わってそれが正解ではなくなった時に「じゃあどうしようか」という次の手に結びつけることが難しくなってしまうのが難点です。
一方で、「こんなことやってみて、こんなことが分かって、ここが謎でした」という記事は、自分も何か壁にぶつかったときにその記事を参考にしながら「じゃあ次はこんなことを試してみよう」という思考に結びつけることができます。
ハマって、調べて、解決したことを書く記事は数多くありますが、そのほとんどが結果的に発見した解決方法のみを淡々と書いて終わっている気がします。それよりもどうハマって、どう調べて、どう解決したのか、という過程が読める方が個人的には好きです。
パターン２：ひとつの技術に対して、とても深く書かれている
何かひとつの技術に精通されている方が、知っていることや思いのたけをひたすら書いている文章は読んでいてとても面白く、勉強になります。
例えば、以下のような記事です。
このような詳しく長々と書かれている記事は、最初はその分量に圧倒されてしまって読むのが大変になってしまうのですが、はじめて知ることが次々と出てくると、次第に読んで新しいことを知ること自体が楽しくなってしまい、夢中で読んでしまいます。
当然はじめて聞く内容で理解できない部分もあるのですが、そこは読みながらググりながら、少しずつ内容を理解していくように読み進めています。
お行儀よくまとまった書籍やウェブサイトとはまた違った切り口からその技術に対して知ることができるところが、ブログの性質の良い部分なのではないかと思います。
パターン３：変わった試みで面白い
例えば以下のような記事です。
このパターンは文字通り「面白い」記事です。
自分を含め、他の開発者がやろうと思わなかったことを実用性抜きにやってみて、得られた知見を書いているパターンです。
とはいえ、ただ単に面白そうだからやってみる、という記事ではなく、何か既存のプロダクトでは解決できない悩みや不満（「プロンプトがかわいくない」とか）から始まって、それを解決するためにどうするかを考え、実際に作ってみる、というプロセスを知ることができる記事の方が、サービス開発の発想を広げるという意味でも面白かったりします。
やってみて、どんな技術を使ってどう実現できたかまで書かれていると、既存の技術や知識をどう理解し、どう新しい製品に応用していくか、という例を知ることができるため、ネタ記事だと思ったらとても勉強になったという場合が少なくないです。
パターン４：推測が面白い
パターン１と似てはいますが、こちらは100%推測だけで書かれている記事です。
例えば、以下のような記事です。
公開されていない（もしくは到達しづらい）情報に対して、今与えられている情報から推測してみる、という頭の使い方は実際に仕事をしていると割と頻繁に必要になります。このパターンの記事はそんな頭の使い方を鍛えるという意味でとても勉強になる記事だと思います。
当然公開されていない情報に対する推測なので結論は出ないですし、正確な情報かというとそうではないのですが、それよりも上記の「推測のしかた」の方に価値があると思っています。
パターン５：ひとつの技術について体系立ててまとめられている
例えば以下のような記事です。
Javaのファイル入出力関係のクラス/インタフェースについて整理する
一次ソースや書籍を見れば体系的にまとめられているのでそれで良いじゃん、と思われるかもしれませんが、ブログの記事には、記事の対象となる技術やその粒度、レベル感など、まとめ方を書き手が自由に決められるというメリットがあります。
どうしても公式ドキュメントだと、情報の正確性や平等性、網羅性などを考慮して誰にとっても同じように参照できる平坦なイメージのドキュメントになってしまいます。（もちろんそのような情報の方が良い場合もありますが）
一般的なサービス企画の話として、ターゲットは絞れば絞るほど、そのターゲット対するサービスの価値は高まっていきます（逆に、ターゲット以外にとっての価値は下がっていきます）。記事の内容も同じで、ターゲットを絞り、内容や書き方をより少数の読み手に向けたものに特化すれば、その記事のターゲット読者にとっての価値はどんどん高まっていきます。
体系立ててまとめる、という行為は同じですが、それを誰のどんな用途に合わせて書くのかによって、公式ドキュメントとはまた違った価値を生み出すことができ、またそのような記事のターゲットがまさに自分だった場合に「面白い！」と感じることができます。
パターン６：体験談
書き手の体験談です。たとえば最近だと、以下の記事が盛り上がっているようです。
会社で仕事をしていると、どうしても社外のエンジニアはどんなことを考え、どのような壁にぶち当たり、どのように解決しているのかが気になってきます。気になるだけでなく、自社内のメンバーであれこれと検討しているだけではなかなか良い解決策が見つからない場合が少なくありません。そんな時、社外の事例というのは新しい発想をするためにとても役に立ちます。
ただし、体験談であればなんでも良いのかというとそうではなくて、やはりどんな状況で、どんなことを考えて、どんなことをしてみて、結果どうなったのか、という具体的な状況が書かれている記事の方が面白く読めます。
実際に全く同じ条件で同じ問題に突き当たっている、というシチュエーションはまずありませんので、単に「こんなことやったらうまくいった」だけ書いてあるよりは、その状況について詳しく書いてある方が、その施策が自分の場合にどれだけ適用できるのか、どれだけ効果が見込めるのか、今の自分の状況では何を変えれば効果的か、といったことが推測できて、参考情報として取り入れやすいためです。
まとめ
いろいろなパターンを挙げましたが、共通しているのは「どんな状況で、どんなことを考え、どんなことをしたのか、その結果どうだったのか」という、書き手の体験したプロセスがしっかりと書かれていることかと思います。
読む側のスタンスとして、ブログ記事は誰でも書いて投稿できるものである以上、その記事に書かれていることだけが絶対的な正解ではなく、どんな記事でも単なる情報源の一つでしかないという前提で読んでいます。そのため、記事の内容を自分の頭で解釈するための材料となる情報が充実している記事の方がやはり面白いと感じる傾向にあるのかな、と思います。
調べて分かった結論だけを書いて投稿するのは簡単ですが、それを調べるに至った経緯や調べ方、調べる上で分かったこと、ハマったこと、最終的にやったこと、その結果、などで内容を肉付けすることで、その人にしか書けない記事になり、またその人にとっても内容を整理して理解する大きな助けになるのではないかと思います。