技術ブログのネタ探しは「自分が困ったことを書く」でOK

問題

ブログに書くネタを探すにしても

そもそも何を書いたら良いか分からない
世の中に既に記事があって自分が書いても内容がかぶってしまう

ということがあるだろう。

だがプログラミング・開発では日々困ることばかりなので、探してみれば本当にネタに困るということはないと思う。というより周りにはネタだらけではないだろうか。

自分の場合は主に自分が困ったことの解決方法を書くことが多い。というよりそれが全てかも。
ここでは自分がいつもブログに書いているネタのパターンを記す。

テーマの例. Google検索で出てこない問題について新しく書く

ググっても出てこない問題を実際にプログラムで試してその結果を記事に書く。
なかなかないパターンだがたまにある。

メジャーバージョンが最近上がった言語・フレームワークだと世の中に記事がほとんどなくて困ることも多いが逆に自分が記事を書いておくチャンスでもある。
(間違ったことを書いてしまう恐れもあるが自信がない時は注記しておく。「自信がないけどとりあえず動いた」とか)

テーマの例. 古い情報を自分の記事で書き直す

世の中でググれる情報は多いが言語やフレームワークのバージョン違いでそのままじゃ動かないことも多い。
これを自分の使っているバージョンのプログラムで動かしてその結果コードを含めて記事にする。

記事のタイトルや本文にバージョンも明記しておくと良い。

テーマの例. 理解しづらかった問題を自分なりの記事として書く

たとえばいろいろな記事を読んでも理解にたどり着くまで時間がかかった時。
「自分ならこんな記事があったら分かやすかっただろうな」と思う内容を自分で書く。

厳密には内容自体は重複していても「自分あるいは自分のような人にとって分かりやすい記事」があるだけで価値がある。

例:

テーマの例. 技術やライブラリの具体的な応用例について書く

プログラミングで実現できることには無数の組み合わせがあるので、全ての技術・全てのバージョン・全ての実現例が世の中の記事になるということは決してない。

なので例えば何かライブラリを使って実現した具体例があればそれについて書いてみる。

例:

テーマの例. 世の中の分かりづらい記事を書き直す

世の中に記事はあっても自分にとってなかなか分かりにくいという場合がある。
なのでそれを整理したような記事を書いてみる。

元の記事を読んでもよく分からなかった部分、自分で理解した部分は書き足す。
自分が理解する時に必要のなかった情報は切り落とす。
コードの中でノイズになる部分は削除する。
自分が動かした環境・バージョンを明記しても良い。 (そのバージョンでも動いたという記録になる)

ほぼ記事内容が重複していたとしても書き方が分かりやすくなるだけで価値がある。

1個の記事の中に様々な情報が混在している記事もあるので、それを1記事=1テーマのミニマルな形に落とし込むのも良い。

テーマの例. Google検索結果が気に入らないので記事にする

ググってたどりつける情報ではあるのだがGoogle検索結果からたどり着くのに手間や時間がかかる場合。
「自分ならこういうタイトルでGoogle検索に出てきてくれたら嬉しかった」という記事を自分で書く。

「自分がまた後にググった時にこんな記事だったら役立つだろう。というかきっと自分でまたググるはず」というような記事を書く。
できればGoogle検索して1クリックだけで解決策が分かるような状態にしておく。もしくはタイトルを見るだけで解決できるような状態に。
(QiitaやzennならSEOに強い)

情報にたどり着くスピードを速めることにも価値がある。

テーマの例. 人が教えてくれたことを記事にする

いくらググっても全く情報が出てこないのに他のエンジニアに聞いたらさっと解決してくれるなんていうパターンもある。
いかにも需要がありそうで多くの人が困ってそうな情報なのに何故…。

そんな情報を記事にしておく。
(人の手柄を自分のものにするようで背徳感がないわけではない。そのあたりは個々で相手にちゃんと言うなり、もしくは「技術情報は誰のものでもない！」と割り切るなりして対策しよう)

テーマの例. 極めてニッチな情報について書く

あと環境やソフトウェアの組み合わせがニッチすぎるのかググっても出てこない情報というのも世の中にはたくさんある。それを記事にして記しておく。(きっと同じような問題で困っている誰かの役には立つだろうと思いつつ)

例:

テーマの例. 日本語の記事が出てこない記事を日本語で書く

StackOverFlowとかで英語の記事は出てくるが日本語の記事は出てこない問題。
これを日本語で書く。

タイトルを日本語にする
コードはStackOverFlowほぼそのまま (できれば元の記事にリンクを貼る)
実際に動かしてみて分かった問題も追記する

などとしても小さな記事が1個できる。

テーマの例. 学習内容を記事にする

世の中に既に記事があるかどうかは関係なく自分が学習用に書いたコード・理解したこと・結果などを記事にする。
はじめてチャレンジする言語・フレームワークだと分からないことばかりなので記事に書けることも多いと思う。

自分のための日記だと思うぐらいで。

例:

テーマの例. プログラミング以外のプロジェクト管理などについて書く

プロジェクト管理について (試してみたことと結果、成功例や失敗例)
開発手法について ( KPTという振り返り手法とか )
プログラミングポエム
オレオレのショートカット設定 / 開発ツール設定
愛用しているツール ( キーボードとかPCスタンドとか )

これは答えがないので世の中にまったく重複する記事があるということも少ないだろう。

例:

テーマの例. まとめ図鑑的な記事を作る

自分の場合はまずやらないが、ミニマルな記事を作るのとは真逆なやり方。
図鑑的に全てを網羅する系の記事もなかなか需要があるみたいだ。

今日Qiitaを眺めていたら600個ぐらいいいねがついてる記事があった。

書く労力はなかなか大きそうだが。

NOTE

プロジェクトのコードはそのまま記事には出来ないので差し支えのない基礎的なコードに落とし込む必要がある。なので問題が再現できる小さな環境を用意する必要がある。だがそこまでコードを落とし込む行為自体が理解を深めてくれるはず。
世の中に十分に満足のいく情報があり何も付け加えることがない場合はさすがに自分で無理に記事は書かない。記事を書くのはだいたい世の中の情報が不満な時だ。

以下雑感

この記事をここまで書いておいて何か根本の事柄に触れてないような気がした。

自分の場合は文章やブログを書くのが元々好きなので書く動機がある。単純に書いたりまとめたりということ自体がなんだか楽しいのだ。
世の中でよくブログを書く人というのはやはりシンプルに書くのが好きなんじゃないだろうか。

これは良し悪しではなく好きと嫌いとには雲泥の差がある。
好きなことをするのはだいたいたやすく嫌いなことをするのは常にハードだ。

エンジニアでも相当な必要がない限りブログなんて書かなくても生きていけるし仕事には何の問題もないはずだ。
たとえば「記事を書くのは嫌いだがプログラミングは好き」という場合はやはりプログラミングの方だけをしていたいだろう。
僕もプログラミングとは別に何か嫌いなこと(たとえば単純作業や書類仕事)をしろと言われたら嫌で仕方ないと思う。

もともと書くのが好きな人はネタなんか勝手に見つけるだろう。
もともと書くのが嫌いな人はこんな記事を提示されても全く役に立たない気がする。

ではなんのためにこの記事があるのか？
やはり自分が書くということ自体が好きなので書いたという理由が大きい。つまり自己満足だ。
自己満足上等。

チャットメンバー募集

何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。