少し前（4月）に、「防御力の高い技術ブログを書こう」という記事が話題になった。
便乗というにはいささか時間が経ってしまったが、私も記事を書くときに気をつけていることを書いてみようと思う。
「記事が読まれない」という恐怖
私はどちらかというと バトル 議論上等みたいな性格なので、「防御力を高める」みたいなことにはあまり関心がない。例えば、「このプログラミング言語はこういうところがクソ！」みたいな話を書いたりする。
むしろ、私が危惧するのは、自分の書いた記事が何の波風も立てないこと、読者が少なすぎることだ。マニアックな話題を扱っているとどうしてもその懸念が頭をよぎる。魂を込めた記事が全然伸びなかったら、悲しい。
読者についてきてもらうための工夫：前提の共有
まあ、話題がマニアックだと、記事を目に留めた全ての人に読ませるのは難しいだろう。例えば、Haskellを知らない読者に「HaskellのPrimMonadとうまく付き合う その1」という記事を読ませるのは無理な話だ。だから、タイトル等で「面白そう」と思ってくれた人をいかに繋ぎ止めるか、という点に注力する。
記事で伝えたいことは簡潔に要約できることが多い。「HaskellのPrimMonadとうまく付き合う その1」なら、言いたいことは
- PrimMonadに一般化された関数をモジュールを跨いで使うと特殊化されなくて遅くなることがある
- 特殊化を起こすためにINLINABLEやSPECIALIZEプラグマを使うと良い
- モナドスタックが重なっている場合はstToPrimを使うと良い
の3行に集約されるだろう。しかし、だからと言って記事の内容を3行で済ませることはできないのだ。
ブログ等の記事というのは書き手が用意した乗り物に読者を乗せる旅のようなものだ。速度を上げる（=内容が高度になる）と読者がどこかで振り落とされるかもしれない。しかし、いずれ振り落とされるとしても、最初は静止した状態から始めないとそもそも読者が乗れないではないか。「最初は静止した状態から始める」というのは、導入部で読者に前提を共有するということだ。そして、「圧縮された3行だけの記事」というのは、最初から時速300kmで走っている乗り物に読者を乗せるような無謀な行為だ。
だから、私が記事を書くときは序文でなるべく前提を説明するようにしている。PrimMonadの記事であれば、IOやSTに触れ、モナド変換子に触れ、PrimMonadクラスに触れている。
まあ、PrimMonadの説明をしているわけではないので、PrimMonadを知らない人は結局読めないだろう。しかし、PrimMonadを知っている読者に対しては、この部分があることで読者がスムーズに本題に入れるようになると信じている。いきなり読者にとっての新知識を書くのではなく、読者が「うんうん、そうだよね」となるパートを挟んで助走とするのだ。
情報技術から離れて例えば登山の話を書くときも、登った山がどこにあるどんな山なのかは最低限説明するようにしている。全ての日本人に前提なしで伝わる山というのは富士山くらいだと私は思っているので、富士山以外の山の場合は「この山は◯◯県にある山で、日本百名山にも選ばれている」というような前置きが必要だ。富士山のような有名な山にしたって、登山口がどんなところにあってどういう登山道が通っているのかは説明が必要だろう。
動機付け
「前提の共有」と被るかもしれないが、何かやるときは動機付けの説明もしたい。内容が凄くても、読者の興味を惹きつけることができなければ無味乾燥に見えるだろう。
例えば、Haskellの書き換え規則の記事を書くときは、どういうときに書き換え規則があると便利なのか説明する。「Haskell/GHCの書き換え規則（rewrite rules）覚え書き」では書き換え規則の利用例を説明した。「覚え書き」と銘打った記事にも導入をしっかり書いてしまうのは私の性だ。
数学で何かを定義する際に動機付けをしっかりしたい、という話は以前「代数構造の「マグマ」と、定義の動機づけ」に書いた。
最近、プログラムの形式的証明の話題で「reverse (reverse xs) == xs のような実務では使わない定理」という発言を聞いた（気がする）。こういう発言が出てくるのは、定理証明の題材に reverse (reverse xs) == xs を取り上げた教材が動機付けの共有に失敗しているからだろう。実際には依存型プログラミングをやっていると（目的が定理証明じゃなくても、型検査を通すために） reverse (reverse xs) == xs が必要になることはある（実務ではないかもしれないが、私は実際に経験した）のだが、それを説明しないので「実務では使わない、演習問題だけの定理」と思われる。と言いつつ、私の書いた「Haskellでの型レベルプログラミング」では紙面の都合から reverse (reverse xs) == xs の動機付けを端折ってしまったが……。
AIの活用？
「HaskellでEDSLを作る：SIMD編」という記事にはSIMDが何かという説明を入れた。こういう説明はイントロダクションとして必要だが、説明自体はありきたりなもので、その分野に関心のある人はすでに何回も読んでいるだろう。
こういう、個性の必要ない、導入のためだけの説明は、今の時代だったらAIに生成させることもできるだろう。例えば、ChatGPTに「HaskellでSIMDを扱う記事を書くために、SIMDについての簡単な説明が必要です。書いてください。」と依頼すれば説明を書いてくれる。
前に「AIでも生成できる技術記事に価値はあるのか」という記事を書いたように私はAIに記事丸ごと生成させるのには否定的だが、「導入のための説明をAIに生成させる」という風に部分的に使うのはアリなのではないかと思う。その場合も「以下はChatGPTに生成させた説明／説明終わり」というような注釈は欲しいが。