技術ネタをブログに書く上で気をつけている7つのこと | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

先月で、このブログも5周年を迎えました。

アクセスがあったり、コメントしてくれたり、はてブしてくれたり、Twitterで紹介されたり、+1されたりと色んな反応がモチベーションにつながって続けるきっかけになっているんだと思います。

ということで、少しばかり遅くはなりましたが毎年恒例?のブログに関するまとめを書いてみたいと思います。


ただ、ブログのいいところとか何でブログ書くのかとかって結構過去に書いてきて自分の中で目新しい視点もなかったりしているもんですから、エンジニアとしてのブログという観点で今回は書いてみたいと思います。



技術ネタを書くにあたって気にかけていること


自分がブログに技術ネタを書くにあたって注意していることは下記のような感じです。


  • 環境を明示する

技術ネタと一言でいっても、OSや言語、バージョン、構成などの組み合わせてみると無限にあったりしますし、「同じエラーメッセージなんだけど、俺が探しているのはこの情報じゃない」なんてことはよくありますし、ちょっと検索キーワード変えたら英語のサイトだらけみたいにもなって、ネット上でまだ情報が全然足りてないっていうのは感じたりするところです。


見る側もどんな環境で試したときにできるのかとか、自分がはまっている問題と同じ環境で解説しているのかとかは気になったりしますからね。


  • ちゃんと検証する

仕事で使う技術ネタを書くことが多いんですが、職場でブログを書くわけにもいかず、自分専用の環境を借りたりしてそこで確証を取ったものを書くようしています。

まぁ、当たり前なんですけど予想で書いたり、他人の記事を引用だけしたりしているとコメント貰ったときに反応も出来ません。


この作業がかなり面倒で、ブログを書く上で多くの時間を費やすことにもなったりするんですが、自分でやったことを明示した方が後々苦労しないで済みますし、そもそも知識を身に付けやすいですからね。


  • わからないことや対象範囲をきちんと書いておく

技術ネタって突き詰めていくとかなり深いところまで辿ることにもなりますし、ネタを書くにあたってわかっていることとわからないこととって当然入り乱れますので、わからないところはわからないってきちんと書いてた方がいいかなと。

それに反応したコメントがもらえたりしてわかることもあったりしますからね。


また、わからないことではなくても、説明したり検証する対象範囲とかを明示しておくことで読み手も自分が欲しい情報とマッチするか判りやすくなるかと思います。

検証自体も何が出来ればOKなのかってのを決めておかないと延々と繰り返す羽目になりますし、何の話をしているのかの境界がわからなくなってきますからね。


  • 途中で躓いたことを書いておく

自分自身、最初から最後まではまらずに成功するというのは結構まれなことです。

途中で環境の差異により追加のタスクが発生したり、謎のエラーに悩まされたりというのはよくあることで、ググる場合ってその躓いたところの回避方法を探すということが一番多いのではないでしょうか。

こういうのって、同じことやろうとしても同じところで自分自身はまったりもして、「あの時どうやってっけなぁ」と悩まずに済むように、書いておいたほうが助かったりします。


こうすればこんなことができるよ!って解説記事って、購読しているサイトとかから偶然拾ったりもしますけど、実際その通りにやっても自分の環境じゃうまくいかないってことが多かったりしますし、その時には自分がはまったときのエラーメッセージとか回避方法とかが有用な情報になってきたりもします。


  • カテゴライズしておく

仕事で色んな技術に触れたりもしますし、長い間別のことをしていると前につかっていた内容って頭から飛んだりもするもんなんで、「あーこういうことはできたな」ってインデックスは持っているんですけど、「どうやるんだっけ?」みたいな状態になっていて、自分のブログ内を検索して記憶を辿るといったこともよくやったりします。


その情報を探しやすくするために、カテゴリや関連するエントリを紐付けておくと自分自身もブログを情報の倉庫として利用できるようになります。

同じカテゴリなら興味を持ってくれる記事もあったりして、購読者を増やすきっかけにもなるんじゃないでしょうか。


  • 技術ネタとしてのストーリーを考えておく

やったことのログをひたすら貼り付けておくのもいいですけど、ある程度どういったネタを書いていくのか、何の操作ができる、何の情報が取り出せるのがゴールになるのかってことを考えてエントリを構成した方が、読み手としても理解しやすくなります。


インストールネタなら開始から終了までとシンプルに書けますが、○○が出来るかの検証をするというなら、検証方法とか検証結果とかその検証結果の根拠とか、順を追って説明することでストーリーが作れたりもします。


  • 外部サイトのリンクや情報源を用意しておく

ブログを見に来てくれた人って、ほぼ書き手が何者かわからないわけですよね。

なので、よくわからないやつの言っていることって信憑性がイマイチだったりもするわけです。

まぁ、その内容から信頼を得ていくことも出来ますが、自分がその記事を書くにあたって参考にしたサイトや書籍、公式のマニュアルなんかのリンクがあれば、その記事の信頼性をあげることが出来たりもします。


また、何をきっかけにそのエントリを書こうとしたのかとかを示すことで、先ほど書いたストーリーを作るって点も出来やすくなったりもします。



エンジニアブログとしての意義


ネット上でエンジニアとして有名になりたいなら、ブログでちまちま技術ネタを書いていくよりは、サービス作ってしまってユーザーかき集めた方が圧倒的に早いんだと思います。

まぁ、早いだけであって難易度は全然別なんですけどね。

こういうことができるよ!ってことをネタとして書くより、こういうことを実現できるサービスを自分の手で作りましたといってしまった方が、ユーザーも読むよりも体験できるわけで、この人スゲーって理解は一瞬でつくわけですよね。

必ずしもスゲーになるかも別ですけど。


例えスゲーという反応が多く得られても、エンジニアとしてはそこで使った技術や苦労話などをしてみたい衝動にも駆られるもんだったりもします。

ただ、Twitterでやるには文章が短すぎますし、SNS使うのはクローズ過ぎますし、勉強会で発表するのは人数が限られますし、Slide Shareでその資料を共有するにしても発表用の資料なんで読むだけではいいたいことを伝え切れなかったりもするわけで、ブログは書くのは非常に面倒なんですが自由に表現できる分、なんとでもできる受け皿としては利用価値がまだまだあるんじゃないかなと思うわけです。


ブログで技術ネタ書くのって自分用だったりすることも多いんですが、ネットに公開している以上は他の人の目にも留まる事があるわけで、その利用目的が一致してくれれば価値が高まるわけですよね。

なので、ブログで技術ネタを書くのって結構相乗効果を生み出しやすいもんじゃないのかなって思ったりします。


ということで、更新頻度は落ちているんですが、これからもゆるい感じでネタを書いていけたらと思っています。