技術系ブログの書き方
勉強と結びつけながらブログを続けていくためのプラクティスについて整理する。
はじめに
先日、『DDD（Domain-Driven Design）』の日本語版が出版されました。謝辞でも触れましたが、この本を翻訳するということは私にとっては目標かつ夢であり、それが実現できたことは自分にとっての１つのマイルストーンとなります。私がそこにたどり着けたのは、間違いなく多くの方々の助けによるものです。ただ、「自分では何をしたのか？」と考えてみると、継続的に勉強を続けつつ自分の立ち位置を考えていく上で、ブログを書き続けることの意味はとても大きかったように思います。
ブログを書く際には、「その記事を書く意味」をそれなりに意識してきたつもりです。そこで今回は、自分がこれまで意図的に採用してきたスタイルを整理してみます。これまで、このブログには技術ネタだけを極力客観的に粛々と書くようにしてきました。しかし、ブログを書く際に自分が考えてきたことを整理するという、ある意味舞台裏をさらすような記事も、これからブログを書こうとしている方、書き方に悩んでいる方にとっては、もしかしたら何かの役に立つかもしれないと思い、これを機にふりかえってみることにします。なお、一言補足します。「ブログの書き方」というタイトルにしてはいますが、ここにあるのは、あくまで「私が」採用しているスタイルです。「ブログたるものこのように書かなければならない」というものでは断じてありませんし、私自身も他の方の書いたものをこうした観点に照らして"評価"したことはありません。ただ、「私はこうしていますよ」という話です。
点
過去ログを見て頂ければわかる通り、私がブログを書き始めたのは、2005年のことでした*1。思想研究というバリバリの文系からソフトウェア開発に転向したということもあり、最初はとにかく体系的な知識を身につけなければと思っていました。そのために手っ取り早かったのが資格の勉強であり、ブログにも資格を取得した際にそのフィードバックを書いていました。「後から受ける人のために」と言えば聞こえはいいですが、自慢したかっただけかもしれません・・・。ということで、ブログの形式その１は「レポート」です。
レポート
試験、カンファレンス、セミナーの内容をまとめる。自分にとってのふりかえりになると同時に、そのカンファレンスに行けなかった人、あるいは試験であればこれから受ける人にとって、有益な情報源になります。カンファレンスやセミナーであれば、内容の要約だけでなく、自分の感想を、試験であれば、自分の使った参考書などを挙げて、「自分がどう捉えたか」を書くことで、情報は独自の価値を持つようになります。
ずっと受験報告だけを書いていた私が、記事っぽいものを書くようになったのは、2009年の1月からです。ただ、技術については勉強を始めたばかりでしたので、必然的に書くことよりも読むことが中心でした。RSSリーダに面白そうなブログのフィードを設定し、なるべく定期的に読むようにしました。そして、特に興味をひかれたものについて、最低でも月一で記事を書くようにしました・・・。ということで、ブログの形式その２は「要約・書評」です。
要約・書評
オリジナルのテキストを短くまとめ、コメントをつける。「元の記事が長い」あるいは「元の記事が英語である」、「本を一冊読む程時間が取れない」という方に対して、内容がコンパクトにまとまっていることは１つの価値になります。その際、著者の考え方と自分の考え方を明確に区別し、「こういうことが書いてある」「それについて自分はこう考える」をまとめることで、読む人にとってもわかりやすく、また単に短くしただけではない価値が生まれます。
いくつかの記事を読んでいるうちに、要約ではなくオリジナルをそのまま紹介したい、と思うものに出会うことがあります。元が日本語であれば、特にやるべきことはありませんが、元が英語であれば、それを日本語にすることにも価値があります・・・。ということで、ブログの形式その３は「翻訳」です。
翻訳
外国語で書かれた記事を日本語に翻訳する。著者に翻訳および公開の許可を得た上で、記事中で翻訳であることを明記し、オリジナルへのリンクを貼ることが必須です。最初はメールを送るのは怖いですが、たいていの相手はよろこんで承諾してくれます*2。
この翻訳という行為は、やがて自分の中でかなり重要な位置を占めるようになってきました。
別の記事や書籍などで紹介されている技術を実際に動かしてみせるのも、情報としての価値があります。私の場合は、概念的なパラダイムを実装に落とすケースが多いですが、要素技術が得意な方であれば、新しい技術や製品を使って何かを作ってみるということも考えられるでしょう・・・。ということで、ブログの形式その４は「実装」です。
実装
実際に作ってみる。ただコードだけを公開するよりは、ある程度考え方なども合わせて紹介する方が、読む人が実際に手を動かす際の助けになりやすいと思われます。
線
ここまでは、ある特定の記事なり本なりを「１つ読んで１つ書く」というスタイルでした。そういうことを積み重ねていくうちに、同じことを別の視点から語っている人の存在に気づくようになりはじめます。ある題材に基づき、複数の記事を比較することで、その情報が立体的に浮かび上がってきます・・・。ということでブログの形式その５は「比較・列挙」です。
比較・列挙
ある題材について、複数の記事を並べることで、立体的に説明する。実は、私自身は意識してこのスタイルをとったことがありません。サンプルを挙げると、InfoQの記事はこのパターンが多いですね。
面
こうしたことを繰り返していると、なんとなく自分の立ち位置というか、自分の属する「クラスタ」のようなものがわかってきます。そうした領域においては、あるパラダイムなり考え方なりを自分なりの視点でとらえなおしてみたいと思うようになってきます・・・。ということで、ブログの形式その６は「解説」です。
解説
特定のパラダイムや考え方を自分の視点からとらえなおす。要約との違いは、著者の提示する枠組みをなぞるのではなく、別の視点も取り込みながら「再構成」する点にあると考えられます。
最近になってようやく、分野によってはこの種の語りができるようになってきました。
解説できるような分野に対する知見が深まるにつれて、既存のパラダイムに対する疑問が生まれて来ると思います。その疑問はやがて、新しい考え方へと結晶します。この考え方を人に語るためには、これまでに論じられてきたことを批判的に継承しつつ、新しい考え方を１つずつ立証していく作業が必要になります・・・。ということで、ブログの形式その７は「論証」です。
論証
自分の意見を立証する。すでに過去に語られていないことを証明するだけでも、いわゆる「先行研究調査」を膨大に行う必要があります。先人の偉業を１つ１つ整理した上で、その上に１つ石を積み上げるような作業と考えるべきです。いわゆる論文。
残念ながら、まだ私はこの段階には到達していません。
まとめ
すべての情報には、なんらかのかたちでその元となる情報があります。したがって情報の価値とは、その元となる情報との「距離」であると言えます。短くする、日本語にする、実装する、再構築する、そうやって、元となる情報との距離が生まれてくるわけです。「勉強はしたいけれど、どこから手をつけていいかわからない」という方は、「要約」から入るのがいいでしょう。私は英語の勉強を兼ねて、対象を英語のブログに限定していましたが、そうしなければならないものでもありません。技術書の読み方の記事でも5〜10冊と書きましたが、要約記事も5本〜10本くらい書き溜めるうちに、なんとなく自分がどういうものに興味を持っているのかが見えてくると思います。
もう１つ、これはブログに限らず色々な場面に当てはまると思うのですが、「間違いを犯すことを恐れない」ことは重要です。何かを言って「間違っている」と指摘された場合、そのやり取りも、それを知らなかった人にとっては情報としての価値を持ちます。そこで得られるのは、「こう考えるのが正しい」あるいは「こういう方向に考えるのは正しくない」という、ある意味間違えない限り得られないフィードバックです。また、こうしたフィードバックに情報としての価値を持たせるためには、「正しく訂正すること」も重要です。間違いを消して、なかったことにしてしまいたくなりますが、元の文は残した上で訂正するべきです*3。
最後に、大切なのは続けること。これは、ゆっくりでもいいので、一定のペースを保つということです。そして何より、読んでくださる方々への感謝ですね。どうもありがとうございます。
*2:「あんたの記事超クールだよ、他の人にも紹介したいんだけど、翻訳していいかな？」と聞かれて、嫌な気持ちになる人はそういないでしょう。
*3:私もブログ上でちょいちょいやらかしています。最近ですと「関数型Scala（２）：関数 - Mario Gleichmann - Digital Romanticism」の脚注など。
