「データの操作がイメージできればSQLはできる（仮題）」という本は、Software Design誌に連載していた「RDB性能トラブルバスターズ奮闘記」というシリーズを書籍化しようという企画によるものです。この連載はおかげ様で人気が高かったようで、当初１２ヶ月の予定が１８ヶ月に延長しただけでなく、書籍も出すことができそうです。SQLを学び直そう、という地味なテーマではあるのですが、しかし現にSQLがわからずにトラブルを起こしている開発現場がまだまだ非常に多いのも現実ですので、著者の生島さんともども開米も使命感をもって本書を世に出すべく奮闘しております。
ところで今「著者の生島さん」と書いたように、本書はジーワン・システムの生島勘富さんが著者、開米が構成・文という形で世に出ます。この種のコンテンツを世に出すにあたっては、そんなやり方もあります。つまり
「自分で文章を書かなくても連載や出版はできる」
というわけです。要するに自分で書けない（文章を書くのが苦手だったり、書く時間がなかったり）なら、それが出来る人に頼めばいいということ。そこでこの案件では開米がライター役を務めている次第です。
具体的にどんなことをしているのかというと、執筆作業の流れはこんな感じです。
原案（生島さん）
↓
構成（開米・商業誌の記事として成り立つ形にストーリーを組む）
↓
文（開米・文章と図案を書く）
↓
編集（Software Design誌編集部）
上記の構成と文のところを開米がやっています。マンガだと上の「構成」は原作、「文」は「作画」と呼ばれるところです。一方、アニメや映画の場合は「原作」という言葉は上の「原案」の位置にあたるものというケースが多いでしょう。そんなわけで、コンテンツ制作の仕事も分野が違うと同じ用語がいろいろ違う意味を表します。
この中で「構成」の部分で何をしているのかは、おそらくイメージしづらいことと思います。
商業誌の記事として成り立つ形にストーリーを組む
とは一体どういうことなのでしょうか？
個人でブログを書くときは気にしなくてもよい部分なのですが、商業誌の記事として書くからには「ツカミとオチがある形で書きたい」と私は常々考えています。
ツカミというのは、最初の数行で「あ、これは読んでおこう」と思わせること。
オチというのは、最後の数行できちんと「終わった感」を出すこと。別にお笑いじゃないのでウケを取る必要は無いのですが、尻切れトンボにならず「なるほど、わかった。やってみよう」という感想を持って読み終わってくれることが理想です。
技術解説記事といっても、本題の技術ネタを書くだけでは雑誌の記事としては物足りないので、技術ネタの周りにそんなツカミとオチが入るようなストーリーを組むわけです。ここは文章を書くのとは別な能力が必要です。おそらく構成は出来るけど文章は書けないという人、あるいはその逆パターンもいることでしょう。
もちろん、かかわる人数が増えるとその分お金はかかるしコントロールしづらくなるので、自分で全部できると便利ではあります。しかし今回は開米がそこを担当しているように、できない部分はできる人にやってもらう、ということも可能なんですね。（場合によっては編集者が構成と文もやってしまっているケースもあるとかないとか・・・）。
技術解説系の記事の場合、技術そのものに関する情報は持っている（原案の部分は出せる）けれど構成や文ができない、という人は大勢いることと思います。そこで、連載や書籍を出したい場合には、まずは構成・文というのが原案とは別な種類の仕事だということをまず知っておいてください。
コメント