ただのにっき

■ 「DevLOVE HangarFlight Experiences」を読んで考えた「良い技術系エッセイ」のパターン

先日購入した「DevLOVE HangarFlight Experiences」、まだβ版ということなのでざっと流し読み。正式版になったらちゃんと読む(かも)。

DevLOVE HangarFlight Experiences
DevLOVE Pub
760円+税

ソフトウェア系技術者によるエッセイ集という体裁なんだけど、DevLOVEの活動からのスピンアウトということもあって、彼らが運営しているイベントを基盤に置いた文章が、良くも悪くも雑多な感じで詰め込まれている。冒頭の数本がちょっとポエミーな感じだったので「うわー、大丈夫かな」と心配になったりしたが、中盤以降はわりとしっかりした文章も増えてきて安心した。

著者順に並んでいるせいかテーマもランダムで、頭から読むとかなり混乱する。文体も(これは悪い意味で)ブログ風味で、「書籍」の読者を想定していないっぽいものも多いけど、正式リリースに向けてこれらは整理されるのだろう(と期待しているのでβの状態で感想を書いているわけだが)。

で、通して読んでみて、上手い人の技術系エッセイにはパターンがあるなぁ、と思った。例外はあるけどこんな感じのスタイルだと読後に納得感が高い:

タイトル - 単独で意味をなす

タイトルで失敗する書き手は多い。タイトルは読み手にとって最初の「手がかり」なのだから、何が書いてあるのかそれだけで独立して意味をなすようにする。本文まで読まないと何が書いてあるのか推測できないのは(よほどキャッチーなタイトルでない限り)失敗だ。

導入 - 「私」の課題

自分が抱えている(いた)課題や、それに出会った経緯の説明で始める。ここは読者を選別するフェーズだ。読者はエッセイのテーマを推し量り、自分が求めている話かどうか、最後まで読む価値があるかどうかを判断する。同じ課題を抱えている、興味を持っているテーマであれば続きを読もうという気になるものだ。

ここで気をつけたいのは「私(書き手)」を主語にすること。「あなた(読者)」に対する呼びかけスタイルは高等技術なので避けたほうが良い。知らない人から突然「あなた××ではありませんか?」と呼びかけられたら普通は引く。導入はあくまで「自分」を主体にして話す。そもそも「HangarFlight」というのはそういうものだと思うのだが、ついつい読者を仲間に引き込もうという誘惑に負ける書き手は多い(そして失敗する)。

本論 - 私が感じたこと、考えたこと、行動したこと

実際に自分の体験をベースに、実際にやったことを書く。導入抜きでいきなりここから書き始める書き手がいるが、メソッドを未定義のままで呼び出してmethod_missingでトラップするようなものなのでやめた方がいい。

本題なのだから基本的には好きなように書けばいい。読者は導入を読んで最後まで付き合うきになっているのだから、脱線しないで自分の言葉で語れば良い。逆に「自分」を排除して抽象的な一般論にしてしまうのも良くない。それは「まとめ」にとっておく。読み手の多くは現実の事例のない一般論は信用しない。

まとめ - 一般化

DevLOVEのようなイベントで参加者同士の対話があるなら、つまり本来の「HangarFlight」では、本論で終わってもその後の展開は参加者同士で進められるが、書籍ではそうはいかない。自分の体験を語った後は、そこから導出される法則やTIPSを一般化して誰にでも応用できるようにまとめると、エッセイとしてのシメはカンペキである。これがないと、読み手によっては「だから何?」という置いてけぼり感を抱くことになる。

もちろん、経験豊富なエッセイストの手になる文章はこんな定石を踏まずとも読者を引き込んで熱い読後感を残すのだが、そうでない大多数の人は、まずはこういうパターンに沿って書くように心がければ、読み手も書き手も得をすると思う。

というわけで、「DevLOVE HangarFlight Experiences」が良い書籍になることを願って。