電子メールで原稿を修正する方法 --- Manuscript Editing (Manued, 真鵺道) を目指して --- 竹内 郁雄 電気通信大学情報工学科 nue@nue.org 電子メール, すなわち, テキスト画面上で原稿に「朱」を入れる方法Manuedを 提案する. Manuedは人間同士の修正情報の交換にも役立つが, 機械処理が簡単 なので原稿の修正を機械的にスムーズに行なうことも可能である. Manuedは非 常に単純なアイデアをベースにしているが, いままでの筆者の体験によると, 予想以上に便利である. 1 はじめに このごろ電子メールで原稿 (あるいは草稿) を修正しなければならない機会が 多くなった. たとえば, 対談を録音テープから起こしたものに, 編集者が若干 手を加えた原稿ができたとしよう. それを印刷したものを郵送して, 対談者が 朱を入れて返すというのでは, 間に合わないことが多い. 郵送ではなく, ファッ クスが使われることもあるが, 電算写植などの場合は電子化されているテキス ト情報を直接修正できたほうが誤りが混入する確率が低くなる. そのためにフ ロッピーを使うとなると, また郵送に戻ってしまう. 電子メールで相手の書いてきた文章にかな漢字変換ミスの誤りや, 言い回しの 不完全なところがあったとき, 下のように ^^^^^^^ といった疑似的な下線を 使って「朱」を入れて返答するのは, 誰が発明したというわけでもないだろう が,\note{実は発明者がいるのだろうか? もし名前がわかっているならご教示 願いたい.} よく知られた習慣となっている. > Javaを使った開発を行う技　術者、 ^^ トルツメ こうやって, 技術者はいつも八つ裂きにされるんじゃ. しかし, 大量の文章を推敲・修正・加筆する, といった場面では, もう少しシ ステマティックな方法を使わないと, とてもくたびれる作業になる. 正確性も 望めない. 擬似下線でもっと困るのは, 電子メールが送り手の書いた文章の二次元情報を 保存してくれない場合があることである. 実際, 電子メールには元の文章の二 次元情報を伝えなければならないという規約がない. たとえば, Mac上でよく 使われている電子メールシステムEudoraと交信した場合, 擬似下線がどこにつ けられたのかまったくわからなくなることがある. 本稿で記述する電子メール上での原稿修正法は, こういう単純な, しかし現実 的な悩みから生み出され, ある私的な会合\note{登録商標 秘密結社 大日本清 談會}で揉まれたものである. 2 電子メールで原稿を修正すること 電子メール (の画面上での修正) という条件が意味するところは次の三つである. [M1] 使える文字記号の種類が限られている. 我々の通常の環境では, ASCII文 字とJIS文字のみである. すなわち, 馴染み深い校正記号や吹き出しが使えな い. [M1'] いろいろな人の書いた原稿が修正できるようにしたい. 電子メールで使 える記号はかぎられているが, その中で, 各人各様, 文章ジャンル固有の文字 記号の使い方がある. だから, 修正のために特別の記号をリザーブしておくこ とが難しい. つまり, 文字記号の趣味・使い方の多様性に耐え得るものでない といけない. [M2] 色が使えない. ゲラ刷りでは当然の朱が使えない. 朱と青, 朱と鉛筆の 使い分けに相当するものもそのままでは無理である. [M3] 文章の二次元情報, すなわち画面上の座標が当てにできない (たとえば, Eudora). [M3'] 改行位置に依存したくない. たとえば, EmacsのMeta-qコマンドで文章 の改行位置を揃え直しても, 修正の指示情報が影響されないようにした い. 原稿の修正結果, すなわち電子化された修正原稿 (電子朱入り原稿) に望まれ る性質は, 次のようにまとめることができるだろう. [C1] 修正前と修正後の原稿が機械的に簡単に抽出できること. これは電子朱 入り原稿に望まれる性質というより, 必須条件である. [C2] 上の条件にかかわらず, 人間にとって見やすく, 読みやすいこと. [C3] 修正箇所がどこにあり, どのような修正が行なわれたかが一目瞭然であ ること. ただし, サーチコマンドを使えれば, それほど必要性が高いわけでは ない. [C4] 修正だけでなく, 修正に関するコメントが入れられるようになっている こと. 「全体に文が長すぎる」, 「読点が少なくて読みにくい」, 「このあた りの話の筋道がよく見えない」, 「ここは曲げてこうしてくださいよ」などと いったコメントは, 機械処理は当面無理であるが, ヒューマンプロトコルとし ては重要である. もちろん, 修正作業自身についても, [E1] 修正情報の書き込みが容易なこと, [E2] 繰り返されるような修正が抽象化できること, が望ましい. 例によって, ヒューマンファクタのからむ [C2], [E1]や[E2] がいつも (趣味 的な) 議論の対象となる. ところで, ゲラ刷りや紙に書いた草稿に対する修正はどうなっているだろうか. ゲラ刷りに朱を入れる修正の多くはフォントや, 印刷上のフォーマットの指定 に費される. もっとも, 活字の反転をひっくり返すとか, 不良活字を交換する といったような記号はもはや死記号(?)となっている [参考: 木下是雄『理科 系の作文技術』pp170 --- 173 (中央公論社), 『編集必携』共立出版提供]. \note「なんと, 校正記号は日本工業規格 (JIS)であった. 浅学非才の筆者は 知らなかった.} 参考までに『編集必携』の該当ページをこの小文の最後のペー ジに掲載しておく. 結構, 知らない記号があるものである. 日本人の書いた英文の添削を業務としている会社がある --- たとえば, NTTの 研究所の仕事をよく請け負っているF.J. クディラ アンド アソシエイト 社. 英語の品質が悪いと修正者が若干サジを投げてしまい, ややおざなりの修 正になるが, ある程度脈があるとかなり丁寧な修正をしてくれる. このような サンプルを見ると, 電子メールでの原稿修正に役立つ示唆が得られる. 実際, 渡すのはダブルスペースで印刷された原稿であり, 最終的な印刷の体裁には関 係しない. 添削はファックスで送られてくるので, 色が使えないという点も共 通している --- こういうものは締め切り間際に出されるのが常なので, やり とりを時間のかかる郵送には頼っていては間に合わないのだ. ここで参考にしたのは, NTTの某君の国際会議投稿論文の草稿に対する添削で ある.\note{実はもっといいサンプルを長期間保存していたのだが, この話を 考える直前に捨ててしまっていた. マーフィーの法則である.} 興味深かった のは日本語では馴染みのない記法がいくつかあることである --- 筆者は知ら なかったが, 一部はJISにあった.\note{これはANSIなのだろうか?} ● 大文字にする (三本下線, ≡) ● 小文字にする (ルートのような記号, √) ● スペースを挿入する (#) あと, 添削しきれないものを [ ] でくくり, そこから線を引き出して, ○で 囲った吹き出しに unclear; what algorithm? といったようなコメントをぶら 下げる --- 挿入などそれ自身が地のテキストとして意味をもつものは囲わな い. 最初, この原則がしっかり貫かれていると感心していたのだが, 最後まで 丹念に見ると, 貫かれてはいなかった. このあたり, やはり人間の意味解釈能 力にオンブしてしまっている. ただし, このサンプルには, パラグラフを入れ 換えてしまうとか, 修正がゴチャゴチャで原文が見えにくくなってしまったよ うな劇的なものがなく, あまり参考にはならなかった. このようなサンプルを見たり, 校正記号を見たりすると, 原稿修正のパターン はそう多くないことがわかる --- それで間に合わないような原稿はさっさと ゴミ箱に捨てるのが実は正しいのだろう. これらを (テキストベースの) 電子 メールの画面で表現できるようにすればよいわけである. 3 素案 時代考証をちゃんとすると, 上記の考察を真面目にしていなかったことがばれ るのだが, 筆者は1994年ごろ, やむにやまれぬ事情があり, 即席で次のような 方法を考案して使っていた. [★α/β] αをβで置き換えた [★α/] αを削除した [★/α] αを挿入した [★α/γ/β] αγβをβγαにした たとえば, [★鹿/と/馬] [★α//β] αβをβαにした [★…★γ] γは…という修正に対するコメント ------ 修正を伴わなければ [★★γ] この通り編集者にメールで説明して, 修正原稿を送り返していたわけであ る. 実際, テープ起こしを一次編集した対談の原稿のチェックと修正を, 毎月 電子メールだけで済ませることができた (『新科学対話』月刊アスキー連載, 1994年1月号〜12月号, 1997年にアスキー出版から単行本化). 紙のやり取りに くらべて作業性に優れ, 速かった. なお, この記法は入れ子にしてもよい. たとえば, [★α[★β/]γ//δ] など. ちなみに, これは元が αβγδ で, 修正後が δαγ である. ただし, 「プログラミングの基礎」を「基礎プログラミング」に直すのに, [★プログラミング[★の/]//基礎] と書く (活版印刷屋好み? 編集者好み?) よりは, [★プログラミングの基礎/基礎プログラミング] としたほうが人間相手だったら読みやすいだろう. 後づけの議論になるが, この素案は[M1]〜[M3]をほぼ満足している. また[E1] も, 私の経験によれば満たされている. 修正前の形が (読むと先に) 見えるよ うになっていることで[C2]はちょっと苦しい. ★という記号は主に[C3]のため である. 通常の画面では結構目立つ. 欠点は, 修正後の原稿の全体の大きさが直感的に見えないことである. 「あと, 数行水増ししてください」といった要望があったとき, これはちょっと困 る. 電子メールでの修正の性格上, これはやむを得ないが, 後述するviewerで 解決してもらうことになるのであろう. もう一つの欠点は, 元の文章の中に "[★" が含まれていると, 修正言語と被修正言語の混同が起こることである --- これが [M1']で言及した問題である. さらに, あるフレーズを大きく移動 させたいときに // の入れ換えしか手段がないので, ちょっと使いにくい --- ほとんど読み取れない. やむを得ず, [★★ 以下は大入れ換え] というコメントを挟んで注意を喚起することになる. もっとも, これは機械に 対しては必要のない配慮である. 4 原稿修正言語 Manued (マヌエド) 上に例示した素案を出発点にして, 原稿修正言語なるものを設計しよう. これ をManued (Manuscript Editing language) と呼ぶ. 言語といっても, まずど のような見掛けの言語にするかというネゴから始まる. すなわち, [M1]の問題 に対処するため, 原稿ごとに使う記号を変えられるようにするのである. たとえば, 以下のようなメタ言語による定義を修正原稿の最初におく. つまり, 編集者に私はこんな記法を使うと宣言するわけである. これは, 素案とは異な る修正言語を定義している. defparentheses [ ] defdelete \ defswap | defescape ~ defcomment ★ 定義される修正記号は, 開きと閉じのカッコ, 削除, 入れ換え, エスケープ, コメントの6種類である. 修正記号の種類はあまり増やしたくないが, 2で述べ た[E2], すなわち, 繰り返される修正も簡単に書けるようにしたいし, 素案で は見にくくなっていた大きな移動も楽に書けるようにしたい. そこで, 上記の 6種類の記号をフルに働かせた修正言語を, 以下のように規定する. [α\β] αをβに変更する [\α] αを挿入する (変更の特殊形) [α\] αを削除する (変更の特殊形) [α|γ|β] αγβをβγαに並べ換える [α||β] αβをβαに並べ換える (上の一般並べ換えの特殊形) [α\\] 前に出てきた [α\β] を繰り返す (マクロ適用) [α\\ラベル] ラベルのところへαを移動する (長距離移動) [\\ラベル] ラベルの定義 (移動コマンドとの後先は問わない) […★δ] δは…という修正に対するコメント [★δ] 修正はない, コメントのみ ~c 修正記号 c をエスケープする 修正カッコ以外の4種類の記号は, "~[" の例外を除いて, カッコの外では通常 の記号として解釈されることに注意しておこう. ラベルは任意の文字列である. 変更, 挿入, 削除が1種類の記号ですんでいること, 2種類の並べ換えが同一原 理に基づいていることは, 大昔の紙テープを使ったオフライン・エディタのコ マンドを思い浮かべさせるものがある. 実際, 筆者の発想の原点はそのあたり にある. このメタ言語で素案の記号を定義すると次のようになる. defparentheses [★ ] ; [★ は一続き defdelete / defswap / defcomment ★ ただし, 削除記号と, 並べ換え記号をオーバーロードしているので, ラベルを 使った移動がうまくいかない. これは記号をケチリすぎた素案にもともと無理 があった. さて, いろいろな人と交信する電子メールなので, メタ言語をとっつきにくいものにするのも避けたい. だから, 次のようなメタ言語も用意しておこう. 修正カッコ = [ ] 削除 = \ 並べ換え = | エスケープ = ~ コメント = ★ 英語の文章を添削するのであれば (JISを混ぜるのはちょっと打ちにくいが), defparentheses 【 】 defdelete ／ defswap ｜ defescape ☆ defcomment ★ といった定義も可能だろう. これらの記号の両側の (ASCIIおよびJISの) スペースは地のテキストの中に存 在するスペースと解釈される. しかし, (空行を生まない) 改行は無視する --- このあたりのwhite spaceの問題は草稿の段階といえども (パラグラフの書き 方の流儀などがあり) 結構面倒だが, とりあえずこのような了解で問題はない だろう. 修正記号の定義は, 対象としている文章がどのような記号や文字コードを使っ ているかによって適当に決めてよいとしたが, エスケープ記号があるので, 実 は標準的な修正記号を用意しておけば, いちいち定義し直す必要はない. 上記 のようなメタ言語を用意するのは, 個人の趣味に配慮したためである. 実際, ASCII記号を死んでも打ちたくない (打てない) 人がいるかもしれない. また, バックスラッシュが ￥ にしか見えない端末では, バックスラッシュよりもス ラッシュのほうがいいかもしれない. 以下, この節の最初に定義した記号を使 う. これがManuedユーザのあいだで標準になることを期待したい. 修正例を挙げよう. 次の文章は, 平成3年2月1日, NTT研究開発本部の総括安全 管理室から発せられた, ある交通事故に関する注意文書 (周2-11号) の主要部 を抜き出したものである. 原文のままである. この文章がなにを言わんとする かを理解するのは面白い練習問題であるが, それはさておき, これを修正する ことを試みよう. NTT社員は、愛甲石田駅からバイクで出社途中、反対車線の車が右折するため 一旦停止したので、バイクの横の車が道を譲るためライトをパッシングさせ合 図し停止した。NTT社員はこれに気付かずそのまま走行したため相手車両は急 ブレーキをかけたが間に合わず衝突したものである。 以下の修正は, 全面書き直しをしたいところはやまやまだけれど, 元の文章を なるべく生かそうとしたものである. こうすれば, 元の書き手に (もしフィー ドバックできれば) 若干の教育的効果があったかもしれない. [NTT社員[は、\の]||愛甲石田駅からバイクで出社途中[、\の]]反対車線の 車が[\、]右折するため[\に]一旦停止し[たので\ていたところ]、バイクの 横の車が道を譲る[ため\合図として]ライトをパッシングさせ[合図し\て]停 止した。NTT社員はこれに気付かず[\、]そのまま[走行\直進]した[ため\。] [相手\動き出した右折]車両[は\が]急ブレーキをかけたが間に合わず[\、] 衝突したものである。 さすがにこれくらい元の文章がひどいと, 修正を加えたものも錯綜していて読 みにくくなるが, 一般的な文章の修正では, 修正箇所がまばらなのでこれほど 読みにくくはならない. マクロは一つの文章の中で同じ修正が繰り返されるときに使う. たとえば, 「タマゴッチ」を「たまごっち」に修正するのに, 毎回 [タマゴッチ\たまごっち] と書くのは面倒である. だから, 最初だけ上のように書き, あとの箇所は [タマゴッチ\\] と略記するわけである. 注意すべきは, マクロ適用があるのに, 改まったマク ロ定義がないことである. 変更が自動的にマクロ定義になっているからである. なお, 曖昧性が生ずる場合は最近のマクロ定義が参照される --- 現実に, あ まり面倒なことは起こらないと思う. 「行なう」と「行う」といった送りがなの不統一の修正も, マクロを使えば比 較的容易である. [行\行な]って を最初に書いておけば, あとは [行\\]う と書けばよい. 次は文章断片の大きな移動の例である. [原文] ご本体は石を積み重ねただけのいたって簡単自然なもので，写真を見て要領を 得なかったのも無理はない。神棚にでも祭ろうと早速写真撮影。その日は曇り 空だったので，ストロボを焚いてバシバシ何枚も撮った。 ところがである。現像してみると御神体がまるで写っていないのだ。つまり、 ストロボがまったく光っていなかったので、屋根の下の暗みにあらませる御神 体は私のフィルム上に影を映されることを拒まれたのである。 [朱入り原稿] ご本体は石を積み重ねただけのいたって簡単自然なもので，写真を見て要領を 得なかったのも無理はない。神棚にでも祭ろうと早速写真撮影。その日は曇り 空だったので，ストロボを焚いてバシバシ何枚も撮った。 ところがである。現像してみると[\\1]御神体がまるで写っていないのだ。つ まり、ストロボがまったく光っていなかったので、[屋根の下の暗みにあらま せる\\1]御神体は私のフィルム上に影を映されることを拒まれたのである。 ところで, 修正前と修正後, どちらのほうがいい文だろうか? 5 考察 以上で説明したように, Manuedは非常に単純な「言語」である. この単純さは, 誰もが容易に使え, 修正前と修正後の文章が機械的にごく簡単に取り出せるべ きだという設計方針に由来している. しかし, この設計についてもう少し考察 を加えよう. 前節で示したNTT社員の事故の例を見るとわかるが, この朱入り原稿から修正 後の文章をすぐに読み取るのは困難である. 修正前の文章の形を崩さないこと で, 修正前の文章を優先しているからである. では修正後の文章を優先すると どうなるであろうか. そのためには変更, 削除, 挿入, 並べ換え, マクロ適用, 長距離移動のコマンドを逆向きにしなければならない. [α\β] βをαに変更する [α\] αを挿入する (変更の特殊形) [\α] αを削除する (変更の特殊形) [α|γ|β] βγαをαγβに並べ換える [α||β] βαをαβに並べ換える (上の一般並べ換えの特殊形) [α\\] 前の [α\β] を繰り返す (マクロ適用) [α\\ラベル] ラベルのところからαを移動する (長距離移動) [\\ラベル] ラベルの定義 後優先方式で, さきほどのNTT社員の文章を修正したものを示す. [愛甲石田駅からバイクで出社途中[の\、]||NTT社員[の\は、]]反対車線の車 が[、\]右折するため[に\]一旦停止し[ていたところ\たので]、バイクの横の 車が道を譲る[合図として\ため]ライトをパッシングさせ[て\合図し]停止した。 NTT社員はこれに気付かず[、\]そのまま[直進\走行]した[。\ため][動き出し た右折\相手]車両[が\は]急ブレーキをかけたが間に合わず[、\]衝突したもの である。 たしかに読みやすくなるが, 逆に修正する側の負荷が増える. カーソルの前後 移動が増えるからである. 筆者は後優先も試してみたことがあるが, 修正箇所 が多くなると, 前優先にすればよかったと思うことがしばしばであった. だか ら, 前優先 (書き手優先) にするか, 後優先 (読み手優先) にするかを, 最初 のメタ言語で指定できるようにしておいたほうがいいだろう. マクロは便利であるが, Programming By Example風で, 能力は高くない. たと えば, 筆者が非常に気になる英数字コードの不統一 (ASCIIとJISが混在してい る文章はとても気持悪い) を修正するのはとても面倒である. まさか, １９９８年 をASCIIにするのに (前優先, JISをASCIIに変えるマクロ定義, [１\1]などが すでにあるとして), [１\\][９\\][９\\][８\\]年 とは書きたくない. さりとて, 遠距離移動コマンドを拡張して [１９９８\\\ASCII]年 ; １９９８を1998に とか [\\\ASCII-ad] ; 以下, すべての英数字をASCIIに変換せよ といった名前つきコマンドをたくさん用意するとなると, 言語は急に大きくな り, ちょっとしたプログラミング言語風になる. これはトレードオフ問題だが, 筆者はこのような指示はコメント文で書ければ十分だと思う. しかし, このよ うな拡張を行なったほうが, 大量の文章を素早く処理しないといけない編集者 には便利かもしれない. 前にも述べたが, Manuedは大昔のオフライン・エディタのコマンドの発想に基 づいている. オフライン・エディタは決して使いよいものではなかったが, 文 章に直接オフライン・エディットのコマンドを書き込んで混ぜてしまうことで, 昔にはなかった新しい見掛けをもつようになった. こういうのは, machine tractable human protocol (機械処理可能ヒューマンプロトコル) とでも呼ぶ のだろうか. 実際, 筆者はまだこれを人間相手にしか使っていない. ところで, Manuedはプログラムの添削にはあまり向いていないように思うが, いかがだろ う. Manuedを機械処理するには, コンパイラ・コンパイラのようなオオナタを振る わなくても済むだろう. 学生の演習問題として以下のようなManued viewer的 なツールを作成させることが思いつく. ぜひお試しいただきたい. 以下のよう な機能があるといいだろう. ● 前優先で来た修正原稿を, 後優先に変更して読む. 修正するほうにとって は, 前優先が便利だが, 読むほうにとっては後優先が便利だからである. ● 修正原稿からただちに, 修正前あるいは修正後の原稿が見えるようにする. 見たくない部分が薄い表示になっているのでもよい. ● 修正前, 修正後だけではなく, 修正箇所になんらかの印がついて見えるよ うにする. 修正コメントを残す・残さないのオプションもあるとよい. ● Manuedの入力をサポートするエディタコマンド群を用意する.\note{電総研 の中島秀之氏が呼び水的な, 簡単なものをつくってくれた. } ゲラ校正で「イ キ」に相当する修正の取消も, 一発でできるようにしたい. ● 修正前と修正後のファイルから, Manuedで朱を入れた原稿を自動作成する. これがあれば, 前優先とか, 後優先とかで悩むことはなくなる. 大量の文章の 本格的な修正作業は, これを使うのが楽である. ただし, 修正に教育的配慮が ある場合は, コメントを入れながら, 自分で陽に朱を入れるほうがよいと思う. ● 同じ文章に複数の人が修正を加えたとき, それを適当に (ここが難しい) マージして表示する. ● 論文の共著者がおたがいに修正を積み重ねていったときの, 履歴やバージョ ンを管理する. 6 むすび 電子朱入り原稿とでも呼ぶべきものを提案した. これは昔のオフライン・エディ タのコマンドがテキストに埋め込まれてしまったようなもので, ちょっと変わっ たリバイバルという雰囲気である. 元来は編集者と原稿の調整のやり取りを電 子メールで行なうための苦肉の策であったが, 少しリファインしてみると, そ れなりに面白いものができたように思う. このような, いわばmachine tractable human protocolが有用なところは, ほかにもいろいろあるのではな かろうか. 機能をわざと低く抑えたManuedは万能ではないが, メールで相談しあって作文 するときに効果的だった経験を何度かした. 幸い, Manuedの仕様は簡単なので, ここに述べたような御託を書かずに, コマンドの説明さえ10行ほど頭につけれ ば, いきなり電子メールで使っても通用する. 実際, ほとんどの場合, コマン ドのいくつか, たとえば, 一般の並べ換え, エスケープは使わないので, 説明 はさらに短くなる. また, 変更, 削除, 挿入コマンドには誰の目にも明白な兄 弟関係が仕込んであるので, 説明の了解性も高いはずである. 直接プログラミングに関係しない話題ではあったが, 考えてみれば, こういっ たちょっとプログラミング言語風の記法に多くの人が慣れ親しむのは悪くない ことだと思う. 読者諸兄も, いろいろな場面でこれを愛用されんことを希うも のである. 最後に, Manuedについて有益なご討論をいただいた秘密結社 大日本清談會の 諸氏には (秘密結社である都合上, 名前は明かせないが) 深く感謝したい.