ブログを書く理由の振り返り

2020年になって初めてのブログ記事です。 なお2018年は8件、2019年は3件しか書いておらず、徐々に減少傾向です。

今回はブログ自体に関するブログ記事、いわゆるメタ記事的なものを書いてみようと思っています。

このブログのポリシーについて

フッターより。

自分がひっかかった技術的なことをメモってインターネット上に解き放ち、忘れた頃に自分含む誰かがググったときの助けになれば、というポリシーでブログを書いています

このブログのポリシーについては、ずいぶん前から明確になっていて、 よりはっきりさせるためにも、とある時期からきちんとフッターに明記するようにもなってたりしてます。

つまりこのブログを提供することにより、何を実現したいかといえば、 目の前のエンジニアリングで困っている人の、問題解決の糸口になりたい ということが言えるかと思います。（自分含む）

ブログの種類いろいろ

実現したいことによって、ブログを書くポリシーは全然違っていいはずですし、1人でポリシーの異なるブログを運営しててもいいはずです。

エンジニアリングのブログでも、こんな種類がありそうだなーと思っています。

• 特定の分野におけるメディア系
• 流行り系のもの
• あとでググって役立つ系
• 日記系

などなど。

特定の分野におけるメディア系

分野を絞ることで、このブログを追っていけばこれ系の記事が読める！というブランディングができてるやつです。

特化した専門知識は当然いるでしょうし、それに加えてメディアとしての価値を保つために一定間隔での記事投稿が必要になりそうです。 ただブログの価値としてはすごく上がる余地があるでしょうし、時間が経っても色あせないことが多いんじゃないかと思います。

流行り系のもの

PV は稼げるんじゃないかと思います。 一方であとで振り返ってみたときに役に立たない記事も多くなりそうなので、流行を追い続ける必要はありそうですね。

あとでググって役立つ系

このブログはこの辺に入りたいです。

書いたその瞬間には見てもらわなくてもいいんだけど、 ニッチな分野を調べていたり、どこかしらのバグで悩んでいたときの原因究明のとっかかりになったりすると嬉しい系です。

日記系

やったことを書いていく形の記事が多めで、 あとで振り返る分には良いのですが、一方でそれを振り返りのためだけにオープンにする意味がどれくらいあるのだろう？という疑問もあったり。

実現したいことに応じて、どんな運営の仕方が適切か考える

僕自身は上にも書いたように 目の前のエンジニアリングで困っている人の、問題解決の糸口になりたい と思っているので、 このブログは あとでググって役立つ ようになっているとすごく良いと思っています。

ただそうじゃないブログも並行して持ってもいいと思っていて、 例えば知識が古くなりにくいような記事、足の早くないようなテーマを中心に拾っていって、 初心者・初級者向けのメディア系のブログも別に運営してもいいかもしれませんし、 IT 全然関係ない分野と IT とを掛け合わせたようなブログを新たに作ってもいいかもしれません。

今回は、このブログ記事を あとでググって役立つ 系だと思って掘り下げていきます。

ブログを通じて実現したいことをもっと掘り下げてみる

目の前のエンジニアリングで困っている人の、問題解決の糸口になる ためには、 どういったエンジニアリングのケースで困るのか、をもっと知る必要がありますね。

エンジニアリングで困るケースって？

具体的な話を掘り下げたら、様々な問題があるでしょうが、大別すると以下あたりになるのかなと思います。

1. 通常の手順、定石が分からない
2. 新しい概念が入っている
3. ニッチな分野、特殊な分野である
4. バグや再現性のない問題である

通常の手順、定石が分からない

いわゆる よく分からない 枠です。

例えば今までの記事でいうと、最後が 公式のドキュメントを読みましょう 、という結論で終わったり、 ちゃんと仕様書を読もう 、というまとめになっていたりする記事がそれにあたると思います。

（最近は減ったけど、ひと昔前はその結論で終わるのがほとんどだった・・・）

本来、よく分からない対象に対しては、公式のドキュメントを読んだり仕様書を読んだりすれば、 大抵は解決できるものばかりで、 もっと言えば対象のプログラムの挙動が分からなければ、ソースコードを読んだらいいのです。

問題解決したい当人が公式のドキュメントや仕様書をきちんと読みにいくのが正解

問題解決したい当人が公式のドキュメントや仕様書をきちんと読みにいくのが正解 、です。

公式のドキュメントや仕様書を、一定参考にしながら記事を書くのは容易なことですが、 本来であれば、問題解決したい当人が公式のドキュメントや仕様書をきちんと読みにいくのが正解のはずです。

公式のドキュメント読みましょうだとか、仕様書を読みましょうだとかって話は、 他人に言われて中々身に付くものでもないんじゃないかって思います。

• ちゃんとした指導者がついていて、正解をちゃんと経験できる環境
• 先達がおらず、痛い目を見ながら正解にたどり着く人
• （レア）勘が良くてそういった正解が自然と出来てしまう人

もしこのいずれかで正解にたどり着くことができるとすれば、 ブログ記事でいくら他人や自分に『公式のドキュメントを読みましょう』と訴えたところで意味がない、ですよね。

話を戻すと、通常の手順だったり、定石が分からないような困りごとについては、 記事の内容が公式のドキュメントや仕様書をなぞるような記事になりがち、 結論が公式ドキュメント or 仕様書を読もう！で終わりがちで、 あとでググって役立つ といったところからは徐々に逸れてしまう可能性もあります。

新しい概念が入っている

今までになかった新しい概念が入っている場合に関しては、 それを知らない・分からない人にとっては価値のあるものになりそうです。

例えば、コンテナ化の考え方（ Docker の使い方ではない）であったり、スキーマファーストの考え方であったり、 プログラミングのパラダイムの話あたりはそれにあたるんじゃないかと思います。

一方で。話が抽象的であるために中々記事を書くのが難しいという側面もあるかと思います。

ニッチな分野、特殊な分野である

ニッチな分野、あるいは特殊な分野であることで、関わっている人が極端に少なかった場合、 情報も少ないケースが多いです。

もしかすると上で書いたような公式のドキュメントや仕様書、なんてものはない可能性もありますね。

こういうケースでなら、きちんとブログ記事を書いて残しておくことで、 未来の他人もしくは自分の助けになる可能性は十分にあり得ます。

バグや再現性のない問題である

OSS であれば報告をする流れが正しいですが、 そこまで行かなかったとしても手がかりになりそうな情報をネットに残しておくだけでも誰かの助けになったりします。

こういうケースでも、書くことに一定の意味を感じます。

掘り下げてみた、ブログ記事を書く基準

結局ブログ記事を書く基準はどの辺にくるでしょうか？

1. 通常の手順、定石が分からない … ×
2. 新しい概念が入っている … ○（ただし難易度高）
3. ニッチな分野、特殊な分野である … ○
4. バグや再現性のない問題である … ○

このうち、通常の手順、定石が分からないケースについてはそれほど頑張って書く必要はなく、 それよりもニッチな分野だったり、バグや再現性のないケースで書くと、よりエンジニアリングで困っているときに効果が高そうです。

まとめ

今回はこのブログのやりたいことがこれで、こういう基準で書く、というのを明確にしたかったのでそうしましたが、 他にもブログを立ち上げるのなら、同様に

• 何を実現したいか考える
• それを実現するために、どういう形式が適しているかを考える
• 記事を書く基準を考える

このあたりを順に考えれば良さそうですね。

もちろん記事の頻度とか、どういう層にアプローチするのかとか、収益化するかどうかとか、 考えることは他にもたくさんあると思いますが、 なんのためにブログを書くのか？をしっかり中心に据えて、意味のある記事をこれから（も？）書いていければと思います。

2020年頑張ります。