ドミニク・チェン読むことは書くこと Reading is Writing 第20回「デバッグ的編集／助産的編集」

第20回　「デバッグ的編集／助産的編集」

“Perspective: Lecture hall” Photo by Taqi®™［CC BY 2.0］

　前回は書き手と読み手の役割がフラットになるよりも、主客が明瞭な方がコライティングが進めやすいという話をしました。このことを踏まえて、前々回の記事で紹介した「校正のやりとりを支援する文書バージョン管理システム」のアイデアを膨らましてみましょう。
　通常の出版形態では、書籍や原稿の著者に対して1人の編集者が付きます。しかし、編集のプロセスをネット上でクラウドソースする仕組みが作れれば、1人の書き手が複数の編集者を得られます。この点について、二つの側面からメリットと課題が考えられます。
　編集行為によって支援される書き手の作業としては大まかに以下の二つが考えられます。

・校正作業：誤字脱字、表現のブラッシュアップ、事実確認など
・アイデアレベルの支援：文章の構造の策定、何を盛り込み何を省くかといった選択、題名など

　前者は、プログラミング風にいえばバグ取りに近い作業です。「チェックする目玉が多ければ多いほどバグが少なくなる」という「リーナスの法則 *1」よろしく、校正作業も公開する前に確認する人が多ければ多いほどミスが少なくなるでしょう。どんなに優秀なプロの編集者でも人間なので、一回の校正では気付かないミスに第二校で気付くということは往々にしてあります。とはいえ、あまり大勢（100人など）で校正をしても無駄かも知れません。個人的な感覚値ですが、4、5人が最大ではないかと思います。
　ちなみに、書き手の執筆プロセスを再生するTypeTrace文章は、校正作業と相性がいいのではないかと考えられます。なぜなら順に文章が組み立てられていく過程を見るので、飛ばし読みができず、誤字部分の入力が確定した瞬間に気がつけるからです。全体を読むのに時間がかかってしまうというデメリットはありますが、再生速度を実執筆速度の5〜10倍ほどにすれば、2時間分の執筆量をおおよそ10〜20分で読めます。
　逆に、校正作業をクラウドソース化することによって生じるデメリットは何でしょうか。誤字脱字や事実確認については確かに人数が多いことはそのまま利点になると考えられますが、もう少し深い校正、たとえばよりよい文章表現の提案や表記統一については、提案者によって様々なものが挙げられていった場合、書き手にとっては選択肢が増える分、煩雑になるかもしれません。　
　筆者は様々な出版社の編集者の方々と仕事をする中で、その出版社の社風のようなものが校正作業によって文章に吹き込まれるということを体験してきました。人によって異なると思いますが、筆者にとっては表記統一はゲームのルールのようなものとして考えていて、個人的にどうしても貫き通したいもの（たとえば英語の固有名詞の日本語での表記方法や、展開しているテーマと関係する動詞の用法など）以外は、その時々で受け入れるようにしています。この点については、クラウドソース編集の場合、書き手がより能動的に意思決定するということで対処する必要がありそうです。

　もう一つの側面である「アイデアレベルの支援」について、クラウドソーシング・モデルは有効でしょうか。結論からいうと、筆者は文章のアイデアのブレストという行為については、対面での会話の方がネット上でのテキストを用いたコミュニケーションよりも優れていると考えています。なぜなら、口頭での会話の方が文脈の共有がしやすく、お互いの話していることに対して素早く、手短かに、かつ複雑に応答できるからです。文脈の共有とは、何について話しているのかということをお互いに理解している状態のことを指しています。相手がどのようなニュアンスである物事を考えているのかということをその時々の表情や声のイントネーションや大きさなどによって分かる、ということは文脈の共有に大きく貢献していると思います。次に素早い応答という点ですが、ネット上では掲示板にせよチャットにせよメールにせよ、お互いのターンを待つという空き時間が発生するため、ブレストを行っていると次第にお互いの文章量が肥大化してくるということが挙げられるかと思います。
　このことに付随する問題として、レスポンスが長くなればなるほど話の全容が見えづらくなり、テーマに対する集中が散逸しがちになります。また、複雑さという側面からは、たとえば相づちを打つという行為がネット上では困難です。実世界での対話では相づちを打ったり、うなずいたりといったアクションによって、お互いの発話が活性化すると言えます。

　理論言語学者の知人から教えてもらった用語で「独話」というものがありますが、たとえば暗いステージで顔の見えない聴衆に向かって1人で話したり、会話でも目も合わせずうなずいたりもしない人と話したりするような「独り話」が困難なのは、自分の話している内容について理解されているかどうかというレスポンスが通常の会話と比べて限定されるからです。余談ですが、以前DOMMUNEのトークイベントに出演させて頂いた時、ステージの目の前にカメラを据えて座っている宇川直宏さんが登壇者の会話に対して細かく「うんうん」「なるほど」「ああ」と大きな声でレスポンスを返してくださることによって自分も含めて明らかに登壇者たちの話は活性化されてるのを目の当たりにして、宇川さんは優れた「助産師」だと感銘を受けました。
　逆にいえば、相手の表情や仕草といったノンバーバル（非言語的）なレスポンスも含めてコミュニケーションが取れる実世界の会話というものは、ネット上のテキストの交換よりも依然として優れて豊かなものなのだと思います *2 。そして独話のように本質的には相手の顔が見えないまま孤独に文章を書くという行為のなかで、口頭での会話におけるように鮮やかな「相手」のイメージを持続させるための資源として、編集的会話というものを定義できるのではないでしょうか。
　たとえば論文の査読のような合理的判断について意見を行う場合には固定化されたテキストを応酬するということの方が口頭での質疑応答よりも向いていると思いますが、ブレストや意見の交換といったオープンエンドなコミュニケーションの場合は、発話内容以外の「非合理的」な部分というものがとても重要なのではないかと考えています。

　長くなりましたが、以上の理由で、またこの連載でも何度か言及してきたように、書き手にとっての助産師としての編集者 *3 は、何が書かれるのかということに対して一般に思われるよりも大きな影響を（少なくとも潜在的には）与える存在を指すのだと思います。打合せやブレストなどの会話とは、書き手にとって様々なアイデアを試すシミュレーションの場であり、そのプロセスを介して「書くもの」や「書けるパターン」のイメージを先鋭化させていきます。いわばスパーリングのようなものですが、その相手を務める人はプロであろうとなかろうと「編集者」なのだと言えます。
　校正作業は実際に書かかれたものに対して行う支援であり、オープンな文書のバージョン管理システムはその要件を満たしそうです。しかし、書き始めることを支援するブレストの役割を担えるかというと、そうではないように思えます。牽強付会のそしりを恐れずに書いてみると、編集における校正がプログラミングにおけるデバッグだとすれば、編集における対話とはプログラミングより手前の段階の、ブレストをしたりテストユーザーのヒアリングをしたりしながら「誰のために何を作るのか」を策定する、アプリケーションデザインのフェーズに似ているのかもしれません。この点は、既にクラウドソーシングの恩恵を受けているケースならびにその現状の課題が挙げられそうです。次回はこの「自然の会話に近いテキストコミュニケーション」の形を考えてみます。

［読むことは書くこと Reading is Writing：第20回　了］

注
*1│リーナスの法則：
本連載第9回「読み手と書き手の非対称性② ――プログラマーと作家」
http://dotplace.jp/archives/8105

*2│ノンバーバル（非言語的）なレスポンス：
スタンプをワンタップで送れる、というLINEによって開拓されたネット上のコミュニケーション方法は、この意味で大変画期的だと言えます。「うなずき」や「相づち」により近い速度で、しかも従来の絵文字よりも多くの情報量とバリエーションを持つスタンプに「表情」を仮託することを可能にしたからです。

*3│助産師としての編集者：
本連載第12回「助産術としての編集とそのオープン化」
http://dotplace.jp/archives/9435