[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

書籍執筆とオンラインレビュー

結城浩

目次


はじめに

このページは、 私が書籍を執筆するときに行っている 「オンラインレビュー」について簡単にまとめたものです。 どちらかといえば、他の著者さん向けに書かれていますが、 あくまで私の個人的な執筆経験を元にして書いているものですので、 必ずしも書籍を執筆するすべての人に適用できるとは限りません。

しかし、インターネットと電子メールを活用した 書籍執筆の1つのあり方が浮かび上がっているようにも思います。


オンラインレビューとは何か

オンラインレビューとは?

私は、書籍を何冊か執筆・出版しています。 最近は執筆を行う際に、 インターネットを活用した書籍の「オンラインレビュー」というものを同時に行っています。

ここで、オンラインレビューとは、 次のようなものを指しています。

  • 著者が書いた文章やプログラムを、出版前に他の人(レビューア)に送付する。
  • レビューアさんはそれを読み、誤りの指摘や意見を著者に返す。
  • 著者とレビューアさんが直接会うことなく、主にメールやWebを使う。

オンラインレビューを行った書籍

結城が実際にオンラインレビューを行ったのは、 1998年の『Perlで作るCGI入門』応用編のプログラムレビューを皮切りに、 『Java言語で学ぶデザインパターン入門』や、 『暗号技術入門』や、 『数学ガール』シリーズなど、 ほとんどすべての著書になります。

オンラインレビューはオンラインチュートリアルではない

私は、オンラインレビューはオンラインチュートリアルではない、と考えています。 著者がレビューアさんに何かの知識を伝えることが主眼にあるのではなく、 著者が書いた文章、プログラム、図、表などを「よりよいものにする」というのが目的となっています。

オンラインレビューは共同執筆ではない

私は、オンラインレビューは共同執筆ではない、と考えています。 つまり著者とレビューアさんが一緒にゼロから何かを作り上げるのではありません。 あくまで書くのは著者であり、レビューアさんは基本的には意見を述べるだけです。

オンラインレビューはメーリングリストやフォーラムではない

私は、オンラインレビューはメーリングリストやフォーラムではない、と考えています。 著者とレビューアさんの話し合いで本の内容が決まったり、 多数決で何かを決めたりするのではありません。 レビューアさんの意見は大いに参考にしつつ、 著者が、本の内容に関する全ての決定を行い、全ての責任を負うのです。

オンラインレビューはバザール方式と似ているが、少し違う

たくさんの目玉によるレビューの重要性は、 エリック・レイモンドの「伽藍とバザール」に登場します。 そして確かに文章においてもバザール方式は有効です。 しかし、私がイメージしているオンラインレビューは、 バザール方式と似ているけれども、すこし違います。

似ているところ

  • 著者とレビューアさんのコミュニケーションが大切
  • 著者はレビューアさんがつつきまわせる「何か」を頻繁に提供すること
  • 著者はレビューアさんからのレビューを正しく評価すること

似ていないところ

  • 著者とレビューアさんとは一対一のやりとりを行う

時間順で見るオンラインレビュー

私が行っているオンラインレビューの流れを時間順で見ていきましょう。

執筆準備

レビューアさんがレビューを行うためには、 筆者が文章を書かなければなりません。 それがなければいくらレビューアさんが集まっても何の意味もありません。

私の場合には、 自分で「今度はこういう本を書こう」という企画を考え、 それを編集者に伝え、出版できそうな感触がつかめたところで執筆します。 だいたいの執筆ができ(少なくとも骨組みができ)、 ほぼ完成原稿を章単位で発送できる準備ができるところまでを準備段階と考えています。

レビューアさんの募集

私はレビューアさんを以下のメディアを使って募集します。

  • 自分のWebページ。特にWeb日記や掲示板などの、訪問者が多いページ。
  • 自分のメールマガジン。

募集要項は1つのWebページにまとめておき、 レビューアさんの募集ではそのWebページのURLを紹介するようにします。 こうすることで、レビューの主旨や要項が過不足なく読者に伝わります。

レビューの主旨はレビューアさん募集の段階でよく練っておきます。 互いの権利関係、互いがやること、報酬の有無、参加料金の有無、 (可能なら)期間、レビューアさんに求めている技能など、できるだけ具体的に示すほうが、 著者にとってもレビューアさんにとってもよいでしょう。

2009年の追記:最近はレビューアさんの公募はしなくなりました。 常連のレビューアさんと、 Webで見かけた方々に対して直接メールを送って 「レビューしていただけませんか」と声を掛けるようになりました。

はじめのあいさつ

レビューアさんが集まり、募集を〆切った後で、 レビューアさん相手に「はじめのあいさつ」を送ります。 レビューアさんは「これから楽しみ」という期待と「自分にもできるのかな」という不安の両方を持っていますので、 その気持ちを汲み、その気持ちに応えるような文章を送ります。 そしてそれと共に、事務的な連絡や注意事項を送ります。

レビューアさんに「わくわくする感じを伝える」ようにすることは大事です (それ以前に、著者がわくわくしていなければなりませんが)。 せっかくオンラインレビューを行うのだから、 あまり「仕事っぽく」「義務っぽく」しないようにします。

  • これから何が起こるのか、これから何が始まるのか、よくわかっていないけれど、でも、きっと何かは起こる
  • 何かを学ぶトリガー、何かのチャンス、何かのきっかけにしていこう
  • よく耳をすまして、柔軟な心をもって、面白い経験・機会としよう

…そのような感覚ではじめのあいさつを送りましょう。

レビューアさんへ送信する

私はレビューアさんへ原稿を章の単位で送信します。

1つの章を書き上げ、校正した段階で送ります。 これによってその章に「ひと区切り」をつける気持ちもあります。

送信するメールの形式(例えば以下のもの)は統一するのがよいでしょう。

  • 表題の形式。
  • 見出しやリスト、図版などの指定方法。
  • タブの扱い。結城はタブは使わずすべてスペースに展開して送付します。 読者の環境でタブがいくつで表示されているかわからないからです。

レビューアさんへのメール送信には、 メールのBCC機能を使うか、 メーリングリストあるいはメールマガジン発行サイトを使うのがよいでしょう。 レビューアさん全員をTOやCCで送ってしまうと、 レビューアさん全員に互いのメールアドレスが開示されてしまうので、 レビューアさんの個人情報保護の意味で好ましくありません。

レビューアさんからの報告を読む

レビューアさんからの報告は丁寧に読みます。 基本的に、1つ1つの報告に「感謝」して読むことが大切です。 レビューアさんははじめのうちは熱心にレビューしてくれますが、 最初の興奮やものめずらしさが薄れると、だんだんレビューがおっくうになってくるものです。 その中で送ってくれているメールは1つ1つ感謝して読むようにします。

レビューアさんからの報告は、こちらから送ったメールに対する「返信」の 形でやってもらうようにします。 するとメールの表題によって分類することが楽になるからです。

レビューアさんへ返信する

レビューアさんの報告には可能な限り返信するようにしています。 そのときには、 お世辞や心にもない誉め言葉は書かないようにします。 しかしレビューしてもらって「感謝」しているのだ、 という気持ちは常にはっきり全面に出します。

それから、 レビューアさんの一言一言が直接的・間接的に役に立っている、 ということも折に触れて強調します。

自分が感謝していることをきちんと言葉の形にして レビューアさんに送ることは互いにとって有益です。

名前の公開に関して

結城は「名前を公開する」ということをとても大切な(重大な)ことだと考えています。 貢献していただいたレビューアさんの名前は書籍の冒頭の謝辞に掲げますが、 名前を公開することに関してはレビューアさんの許可を得るようにしています。 具体的には「あなたの名前を公開してよいか。公開するならどのような表記がよいか」というメールをレビューアさんに送ります。

確認をとるのは、プライバシー上、あるいは仕事の関係上名前を公開されたら困るという人が少なからずいるからです。

結城は、以下のような方針としています。

  • 「公開してほしい」という返信があった方のみ、公開する。「公開しないでほしい」または無返信の場合には公開しない。
  • 結城はレビューアさんに申し込んでくださった方全員の名前をできれば掲げたいと思っている。
  • 書籍の寿命は意外と長いものだから、できれば、ハンドル名や短縮形ではなくフルネームの方がありがたいと思っている(が、最終的にはレビューアさんの意志を尊重する)。

最後のあいさつ

すべての章をレビューアさんに送り、 レビューアさんからの返信もほぼ尽き、 書籍原稿への反映もすんだところで、 レビューは一区切りとなります。 参加してもらったことに感謝し、これまでの苦労をねぎらい、今後の応援をお願いしつつ 最後のあいさつをレビューアさんに送ります。

次回のレビューにもぜひ参加してもらいたい旨も伝えます。


専用ページについて

結城は、レビューアさんへの原稿送付は基本的にメールを使いますが、 バックナンバー(過去の原稿)の読み直しがしやすいように、 レビューアさん専用のWebページを作っています。

送信したすべてのメールを専用ページで、ブラウザを使って読めるようにします。 これでレビューアさんは、自分あてにすべてのメールが来ているかを確認することも可能になります。

出版前の大事な原稿ですので、 専用ページは基本認証で守り、一般のページとは区別しています。


レビューアさんに何を求めるのか

知識ではない

結城がレビューアさんに求めることは、深い知識ではありません (主に入門書を書いているからかもしれません)。 レビューアさんに求めるものは、知識ではなく、 「感じたことをそのまま表現して返してくれること」です。

レビューアさんのは、結城の原稿の「最初の読者」です。 送られてきた原稿を読んでいくうちに、 レビューアさんの心の中にはいろんなことが浮かぶはずです。

  • 「ここ、どういう意味だろうか」
  • 「こういう題材はとりあげないのかなあ」
  • 「うん、この説明はよくわかった。こういうことなんだね」
  • 「このプログラムはバグっているんじゃないか」
  • 「ここはこうした方がいいんじゃないか」

結城が求めるのは、レビューアさんのそのような生の声です。 レビューアさんが感じたこと、考えたこと、やってみたことを 結城あてにそっくり届けていただくのが、 とても大きな助けとなるのです。

技術的な誤りを探すだけが、レビューの目的ではありません。 レビューアさんが読んで感じたことを、 気軽に、そのまま届けてもらいたいと思っています。

  • 「こんなこと書いたら気分害するんじゃないかなあ」
  • 「うまく言葉にまとまらないからいいや」
  • 「いまの話題に直接関係ないからなあ」

という気持ちでメールを出すのをためらったりせずに、 思い切ってその気持ちも丸ごと送信してほしいと思っています。 結城がレビューアさんに期待するのは、単にレビューアさんの知識だけではありません。 文章そのもの、表現、比喩、ジョーク、言い回し、難易度、全体のトーン… それら全体に対して、レビューアさんが感じることを伝えてほしいのです。

繰り返しになりますが、結城は、 「読んだ方が何を感じるか」を知りたいのであって、 改善案が必ずしもほしいわけではありません。 単純に「ここがわかりやすい」「うん、わかったよ」 「何てすばらしい素敵な文章なんだ。ワンダフルだ。感動で涙が出てきた」 などという意見も「辛口」意見に勝らずとも劣らない価値があります (最後のは冗談です)。

レビューアさんを型にはめないこと

レビューアさんは著者の考えで型にはめないほうがよいです。 レビューアさんを自分の完全なコントロールのもとにおこうとしない方がよいのです。 著者の考えをできるだけはっきりレビューアさんに伝えた後は、 レビューアさんに「はい、あとはあなたのご自由に、あなたのペースでどうぞ」とまかせるようにしています。

レビューアさんにはできるだけ「フリー」な気持ちでいてもらい(つまりは本物の本を読むときの気持ちになってもらい)、 何を感じるか、何を思うか、をできるだけそのまま語ってもらうのがよいと思います。 これは、バグ報告とも共通する部分がある。 オペレータが勝手に現象を解釈するのではなく、 起きたことをverbatimに送り返してもらったほうが役に立ちます。 それと似ています。 レビューアさんが感じたことをできるだけ生の形で著者に送り返してもらうと、とても有益なのです。

レビューアさんからの返信は、 それぞれのレビューアさんごとにトーンやスタンスが違っていることがわかります。 そのバリエーションが、文章に対する違う視点を提供してくれることになるのです。

  • 文章表現について指摘する人、
  • 厳密な用語の定義にこだわる人、
  • プラットホームごとの違いに気を配る人、
  • 自分が以前ひっかかった箇所を教えてくれる人、
  • 頑張ってくださいという励ましコメントがメインの人…

著者はバリエーション豊かなレビューを受け取り、 それを「自分」というフィルタを通して書籍に反映させます。 レビューアさんから、まったく正反対の意見がやってくる場合があります。 例えば、同じ個所をある人は「わかりやすい」と言い、 別の人は「わかりにくい」と言うこともあります。 このような状態では、 レビューアさんの返信をそのまま機械的に文章に反映させるのはできません。 だから、著者は、レビューアさんからの返信を、すべて感謝しつつ、 しかし取捨選択して反映させる必要があります。 何を取り、何を捨てるかの判断を著者がやることで、 その著者らしさ、オリジナリティが自然に出てくると考えています。


バザール方式の教訓との比較

『伽藍とバザール』の中には、 たくさんの「教訓」が登場します。 オンラインレビューの観点からこの教訓を読んでみることにします。

  • 教訓1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。

    私もそうだ。 私が書く本は、たいてい、 私がこれまで知らなくて、新しく学んだことについての本だ。

  • 教訓2. 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。

    私はすごい書き手、ではないけれど (すごい書き手になりたいとは願っているけれど)、 ベースにすべきものを見分ける嗅覚はどこかにあるみたい。 私はまったく新しい何かを創造した本を書くというよりは、 何かすばらしいこと(だけれども難解さのために敬遠されがちなこと)を わかりやすく書くのが好きみたい。

  • 教訓3. 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから(フレッド・ブルックス『人月の神話』第11章)

    これはまだよく分かっていないかもしれない。 でも、本を書いていて、 一章を完成させてからそれをまるまる捨てることはままあるなあ。

  • 教訓4. まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。

    これは言えるかも知れない。 それぞれの本を書くきっかけというのは「出会い」のような感じがする。 自分から計画して何かを書き始めるというのは意外に少ない。

  • 教訓5. あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。

    これはまだよく分かっていない。 この点、本とソフトは少し違っているかもしれないね。

  • 教訓6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。

    専門家、ではなくその本の読者にレビューアさんになってもらうと、文章の質を上げるのに効果的。

  • 教訓7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと

    レビューアさんにはひんぱんにコンタクトを取る。 そして(評論家としてのレビューアさんの声よりも) 読者としてのレビューアさんの声に耳を傾ける。

  • 教訓8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。

    これはまだあまりできていないなあ。 レビューアさんの人数を多くすることに対しては少し懐疑的。

  • 教訓9. 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

    レビューアさんに原稿を送る前に、 それがどんな読者を対象としている本なのかをきちんと知らせ、 目次などの全体構成を明らかにした方がいい。

  • 教訓10. ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。

    レビューアさんは本当に貴重な存在だ。 でも、「資源」というのはコンピュータ屋さんには自然なメタファーだが、 人間に使うのは不適切だ。 レビューアさんは生きた人間として接するべきだ。一人一人を「スペシャルな存在」として丁重に迎えること。

  • 教訓11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。

    レビューアさんからのメールに隠されている「いいアイディア」を見出す能力はとても大事だ。

  • 教訓12. 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。

    その通り。 文章を書き始めのころはよくわかっていなかった問題が、 書き終えるころにおぼろげながら姿をあらわして衝撃を受けることはままある。

  • 教訓13. 「完成」(デザイン上の)とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。

    そう。私も文章を「書きすぎる」傾向がある。 いつも、もっとスリムにしようと思っているのだが、つい厚い本になってしまう。

  • 教訓14. ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。

    書いている本の(著者が気が付かなかった)役割をレビューアさんが見出してくれるときもある。 「この本は○○を学ぶだけではなくて、△△を学ぶ役にもたちますね」という具合に。

  • 教訓15. ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと!

    (話のレベルがずれるけれど)レビューアさんの自然な感想、率直な意見が自分に届くように細心の注意を払うこと。

  • 教訓16. 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。

    (話は少しずれるけれど) レビューアさんの意見を闇雲に取り入れちゃ駄目だ。 必ず自分のフィルタをきちんと通すこと。

  • 教訓17. セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。

    (話は少しずれるけれど) 送付するテキストをがちがちに守ってもあまり意味がない。 少しくらいリークがあっても気にしない、気にしない。

  • 教訓18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。

    最初に戻ったね。 私も、自分にとって「おもしろい」本を書きたいと常に思っている。

  • 教訓19. 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。

    そのようだ、が、 私がまだできないでいるのは、レビューアさんの数を非常に増やすことなんだ。


バザール方式の前提条件との比較

『伽藍とバザール』の中には、 バザール方式の前提条件が登場します。 オンラインレビューと比較してみましょう。

  • 最初からバザール方式で始めるのはすごくむずかしい。

    その通り。 オンラインレビューが共同執筆ではない、というのはそういうことだ。

  • コミュニティ形成を始めるときには、まずなによりも実現できそうな見込みを示せなきゃならない。

    その通り。 私の場合には「これまで本を完成させてきた」という事実が「見込みを示す」行為になっているだろう。 もともと、書き上げられそうなめどがついてからでなければ、 レビューアさんを募集するのはこわくてできない。

  • コーディネーターは、ほかの人たちのよいデザイン上のアイデアを認識できなければいけない。

    何回か実際にオンラインレビューをやってみて、 私はこれが得意だということがわかった。 というか、こういうのが好きみたい。

  • バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ。

    私はリーダーシップはあまりないほうなのだが(いや、本当に)、 メールベースでのコミュニケーションは好きだし、 それなりに能力はあるみたい。 ホームページの運営で鍛えられた部分もあるかもしれないけれど。


オンラインレビューを自分もやってみようという著者の方へのメモ

  • いろんな意味でけっこう大変です。気の弱い人、人から批判されてくじけやすい人は避けたほうが無難です。
  • レビューアさんを「利用してやろう」と考えると失敗します。
  • 失敗や恥をかくことを恐れたり、隠したりすると失敗します。失敗を恐れず、でも何か誤った判断をしたら適切に対処する姿勢は重要です。
  • 自分の知識をひけらかさないように。
  • どんなレビューアさんに対しても謙虚に接すること。相手に知識がなくても、馬鹿にしたりしないこと。レビューアさんの一言一言にきちんと耳を傾けること。
  • どんなレビューアさんに対しても毅然とした態度で接すること。親しみをもつのはいいが、馴れ合わないこと。具体的にはレビューアさんへのメールと、本文の送付を意識的に分けること。
  • レビューアさんを怒らないこと。
  • 文句や愚痴を言わないこと。
  • いつも前向きに考えること。レビューアさんが著者からのメールを読んでいやな気分にならないように注意すること。
  • レビューアさんと議論してもよいが、無意味に戦ってはいけない。

レビューアさんとのやりとりいろいろ

  • あるレビューアさんから、原稿の「二」(漢字の2)であるべきところが「ニ」(カタカナ)になっているという指摘をいただいて、レビューアさんの目のすごさに驚く。
  • 複数のレビューアさんから、同じ指摘をもらうことがある。レビューアさん同士は互いを知らないのだから、この指摘はかなり的を射ているはず。
  • メールのみで連絡をとっているときに不都合なことは、メールが届かなくなったときに連絡方法がないことだ。
  • 分量は問題じゃない。たった一言が大きな意味を持つ場合もたくさんあった。
  • レビューアさんの一言で一節を新たに書き起こした(あるいは全部書き換えた)、という例も少なくない。
  • レビューアさんから「ひっかけ問題」はやめたほうがいい、というアドバイスをいただいたことがある。結城はそれ以来、ひっかけ問題を出したことがない。

書籍案内

「正確でわかりやすい文章」を書きたい方は、 結城浩の 『数学文章作法 基礎編・推敲編』をごらんください。

レビューについては 『推敲編』で詳しく解説しています。