TidBITS-J#571/12-Mar-01 TidBITS-J#571/12-Mar-01Adam が今週も文書作成共同作業について書くが、今回はケーススタディ とあなたの次の共同作業のための具体的なアドバイスについてである。 Joe Clark 氏が再び登場し、障害者のための Web アクセシビリティの問 題について意見を述べる。ニュースの部では、PowerBook 190 と 5300 の 「アップグレード」プログラムのことをお知らせし、新製品のリリースと して Handspring Visor Edge、Photoshop 6.0.1 と AirPort 1.3（PPPoE 互換）をとりあげ、新しい差し止め命令に対する Napster 社の反応を検 証し、新しいスポンサー一社を紹介する。
目次：
Copyright 2001 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。TidBITS 日本語版 では翻訳に協力してくれる方を募集しています。詳しくは以下の URL を 参照してください。
<http://jp.tidbits.com/join_us.html>
今回の TidBITS のスポンサーは：
（翻訳：林部 清実 <hayashibe@mvb.biglobe.ne.jp>）
（ ：敦賀 康子 <hiroki-tsuruga.soul75@nifty.com>）
（ ：亀岡 孝仁 <kameotak@iea.att.ne.jp>）
（ ：蒲生 竜哉 <gamo@lib.bekkoame.ne.jp>）
Web Crossing 社が TidBITS のスポンサーに -- 我々は検索エンジンか ら、コンテンツを集めるポータルへのインターネットの移行が着目されて いるのは知っているが、多くのサイトは良質のコンテンツを発信していく のは難しいだけでなく、ユーザーを惹きつけ、離さない最良の方法はオン ライン・コミュニティを活発にさせることであると気づいた。我々の中で も独自のソリューションを展開したことのある者なら知ってるように、オ ンライン・コミュニティをサポートする優れた技術を創りだすには多大な 尽力とリソースを要する。そこで、我々の最新のスポンサーである Web Crossing 社が登場するのである。それはインターネット・コミュニティ を動かす Web Crossing というソフトウェアを開発した。私が初めて Web Crossing の開発者であり、長年のTidBITS 読者である Tim Lundeen 氏に 会ったのは今からさかのぼること 1995 年であった。我々は何年もの間、 Web Crossing とオンライン・コミュニティの局面を討議していた。その 間に、Web Crossing は、十分に統合されたメーリングリストサポート （POP や IMAPのユーザアカウントも加わった）と Usenet ニュースリー ダ経由のアクセスのサポートをもつ Web ベースの討議フォーラム、チャッ ト機能、個人カレンダー、SSL ベースのセキュリティなど、ほか多くの機 能を提供する通信サーバに発展していった。そしてそれらの機能はすべて 厳格なリレーショナルデータベースにサポートされている。このようなソ フトウェアが Mac OS （他の多くのプラットフォームに加えて）で使用で きるのは素晴らしい。我々はとりわけ、Web Crossing 社 が TidBITS を スポンサーすることで Macintosh コミュニティを支援することになるの を嬉しく思う。もしもオンラインコミュニティを構築、または向上させる のに必要な技術的労力にうんざりしているなら、Web Crossing のデモを チェックしてみよう。[ACE]
Handspring 社の新製品 -- Handspring 社は Visor Edge が Apple 社 の PowerBook G4 Titanium に「必要不可欠」なアクセサリにきっとなる だろう、と発表した。Visor Edge はアルマイト処理されたアルミニウム ハンドヘルドで、厚さはたった 0.44 インチしかない。また、Palm OS 3.5 が走り、8 MB のメモリを備え、現行のモデルでも使用されている高 コントラストのグレースケール画面を装い、充電式リチウムイオンバッテ リを備えている。他機種と違い、Visor Edge は作り付けの Springboard 拡張スロットがないかわりに、あらゆる Springboard モジュールを使用 できる脱着式の Detachable Springboard スロットが備わっている。 Visor Edge は400ドル、色はメタッリクシルバー、メタリックレッド、メ タリックブルーがあり、月末までに出荷されるだろう。[JLC]
<http://www.handspring.com/products/visoredge/>
PowerBook 190 と 5300 の下取り -- もしあなたが PowerBook 190（最 後の 68040 モデル）あるいは同じ PowerPC である PowerBook 5300 をお 持ちなら、地味な宣伝で期間限定だが、Apple は 1,600 ドルであなたの ノートパソコンを 400 MHz PowerBook G3（FireWire）に「アップグレー ド」してくれる。このサービスは 2001 年 3 月 23 日まで在庫がある限 り実施される。この PowerBook G3（FireWire）の構成は一種類しか用意 されていない。（Apple の Web ページで全スペックが入手可能である） [MHA]
<http://www.info.apple.com/support/PowerBook/5300upgradedetails.html>
<http://db.tidbits.com/getbits.acgi?tbart=01352>
Photoshop 6.0.1 アップデート版がリリースされる -- Adobe は Photoshop 6 のバグを処理し、微調整した同社のメイン製品の画像エディ タをアップデートした。新しいバージョンは多少、使い勝手がよくなった ペイントツールのブラシピッカーを呼び物とし、QuarkXPress のようにプ ログラムに読み取り可能な EPS と TIFF ファイルでクリッピングパスを 作る。また、ローメモリ状態における問題を修正し、その他の性能も向上 した。2001 年 3 月 9 日のリリースが「公式の」アップデータであり、 先日の 6.0.1 アップデート版が入手可能になったのが早すぎたのは明ら かで、Adobe はすぐにそれを引っ込めてしまった。この「非公式の」アッ プデータをインストールしたユーザーはそれをアンインストールして Photoshop 6.0 をインストールし直し、それから新しい公式版をアップデー トする必要がある。アップデータは 12.4 MB のダウンロードサイズだ。 [JLC]
<http://www.adobe.com/support/downloads/880a.htm>
Napster 社に対する差し止め命令出される -- 先月の Ninth Circuit Court of Appeals（サンフランシスコ連邦高裁）判断に続き、連邦高裁の Marilyn Patel 判事は、2001 年 3 月 6 日、著作権所有者の通告から 72 時間以内に、Napster 社の音楽交換サービスからすべての著作権の付いた 作品を排除しなければならないとの差し止め命令を出した。これに対して Napster 社は、命令には従うとする一方、レコード会社とは何らかの和解 をめざした交渉は続け、そして著作権所有者にロイヤリティを支払えるよ うにするため会員制のサービスを準備したいと話している。その間、2001 年 3 月 10 日の遅くになって、RIAA（全米レコード協会）は 135,000 曲 にのぼるリストを、Napster 社がそのサービス上で交換されないようにし なければならないものとして通告した；Napster 社は 2001 年 3 月 15 日までに従わなければならない、そして、音楽出版社からもさらなるリス トが出されつつある。とはいえ、Napster 社が著作権の付いた曲に対する アクセスを本当に制限できるかどうかはまだ予断を許さないと思われる。 というのも、いくつもの曲のタイトル形式は自動化された検索を困難にし、 かつユーザーは意図的にファイル名を歪曲できる（Pig Latin とか Leetspeak とか想像してみて欲しい）。[ACE]
<http://db.tidbits.com/getbits.acgi?tbart=06295>
<http://www.napster.com/>
<http://www.napster.com/pressroom/pr/010306.html>
PPPoE のサポートが追加された AirPort 1.3 -- Apple は AirPort Base Station と AirPort カードの新しいバーションのソフトウェア、 AirPort 1.3 を先日リリースした（ TidBITS-567 の『AirPort へ』も参 照されたい）。今回の変更の目玉は PPPoE（PPP over Ethernet）、本来 常時接続のはずの DSL を毎回接続し直さなければならない接続のように 振る舞わせる、汚いけれどもポピュラーな技術のサポートだ。Apple のパー トナーである EarthLink を含む多くのプロバイダーでは DSL を利用する ために PPPoE が必要だが、Mac 用の PPPoE ソフトは概して評価が低かっ た。その PPPoE ソフトが 300 ドルの AirPort Base Station を使えば不 要になるのだから魅力的だ。AirPort 1.3 の他の変更点は DHCP クライア ント ID のサポート、コンピュータ対コンピュータモードの強化、 AppleScript のサポート、複数のベースステーションを持つネットワーク のアクセスポイント密度の調整などだ。さらに AirPort Base Station と AirPort Card は Wi-Fi の認定を受けており、他メーカーの 802.11 ワイ ヤレス Ethernet 製品との互換性は保証されている。この無料アップデー トのダウンロードサイズは 7.4 MB だ。[ACE]
<http://asu.info.apple.com/swupdates.nsf/artnum/n12021>
<http://www.apple.com/airport/>
<http://db.tidbits.com/getbits.acgi?tbart=06300>
<http://www.wi-fi.net/>
by Joe Clark <joeclark@joeclark.org>
（翻訳：山下 英治 <vatcanza@fhe.freeserve.ne.jp>）
（ ：飯橋 真紀 <k-m611@ma4.seikyou.ne.jp>?
（ ：亀岡 孝仁 <kameotak@iea.att.ne.jp>）
（ ：斎藤 美礼 <mirei@x.age.ne.jp>）
2 号前の記事で障害をもつ Mac ユーザーへの対応と、その目的に利用で きるハードウェアやソフトウェア（支援テクノロジー）のいくつかや、ア クセシビリティに関して近年、Apple 社はどれほど義務を怠っていたかに 関するコンセプトを説明した。（ TidBITS-568 「Mac とアクセシビリ ティ」を参照）
<http://db.tidbits.com/getbits.acgi?tbser=1189>
今日では販売されているほとんどの新しい Mac はどれもインターネット に接続できるのが当然である。多数の旧型 Mac や、私のシーラカンス機 種、Power Macintosh 7100/66 もそうである。しかし、インターネットは アクセシビリティに関するまったく新しい論点、決定的に新しいスタイル を提起している。Web にアクセスできるようにするには、Mac の所有者の 側の重要な支援テクノロジーだけでなく、Web の作者が入念なデザインと コーディングを選択することも必要となる。もし Mac でのアクセシビリ ティが整っていないと思うなら、Web のアクセシビリティはもっと悪い状 態である。前向きな見方をすると、状況は急速に改善している。
伝統的なメディア -- 少しの間、昔のメディアについて考えていきたい。 まず、最古のメディアの一つである書籍から始めてみよう。視覚障害のた めにページ上の文字が読めない場合、選択肢はいくつか存在する。
<http://www.loc.gov/nls/web-blnd/bph.html>
<http://www.rfbd.org/catalog.htm>
<http://www.telesensory.com/products2-1.html>
<http://www.ccs.neu.edu/home/elan/ray.html>
<http://www.LHSL.com/kurzweil3000/mac/>
言い換えれば、書籍をアクセシブルにするには、書籍自体より他のものを 活用しなければならないのだ。
Web の活用 -- 逆に、Web サイトをアクセシブルにするには、サイト自 体の的確な設定は必至であり、さらに適応支援技術を活用しなければなら ないケースがほとんどだ。Web におけるアクセシビリティと Mac におけ る一般的なアクセシビリティの大きな違いがここにある。Napster と QuickTime の時代でさえ、Web は本質的には視覚媒体のままで、テキスト と画像から構成されている。それゆえに、Web のアクセシビリティの有無 に目の見えない人々や視覚障害をもつ人々は大きく影響されるのだ。
耳が聞こえないもしくは重度の難聴の Web サーファーは、マルチメディ アに伴うアクセシビリティ問題に度々ぶつかるかもしれないし、また、失 語症のような学習能力障害をもつ人々はすべての色鮮やかなオンラインテ キストを読むのを難しく感じるかもしれない。しかしながら、画面を見て 理解することに何の支障も無いことを考えると、その障壁は乗り越えられ ないものではない。
The World Wide Web Consortium はとても面白いサイトで、いろんな障害 をもつ人々の架空の例と彼らの Web 活用方法が載せられている。
<http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html>
つまるところ、代替手段である -- 皆さんがきっとご存知のように、 Web ページは HTML と呼ばれるマークアップ言語で書かれている（といっ ても、最近では Flash のような非 HTML 技術による Web ページが増加し てきている）。ドキュメントはこのマークアップによって構成が規定され る。たとええば、パラグラフ内のテキストは <P> と </P> タグの間にく る。あるいは、画像は <IMG> タグ内に配置され、そこにはファイル名や 画像サイズといった情報も含まれる。
Web ページにアクセシビリティを与えるためには、説明と冗長度のレイヤー が必要となる。もっとも一般的な例は、画像にテキストを加えることであ る - 通常は、IMG タグの中にテキストを入れられるようにできる ALT （「alternate」の意）アトリビュートの形で行われる。もしあなたのブ ラウザが画像を取り込まないとか、あるいは、先述した読上げ機のような 適応支援デバイスを使っているとしたら、見ることのできない画像に頼ら ずにテキスト版を頼りとすることができる。身近な例としては、TidBITS ホームページ上のロゴは「TidBITS Electronic Publishing」という ALT テキストも一緒に持っている。もしあなたのブラウザが画像を取り込みか つ適応支援技術を使っていなければ、まず ALT テキストを見ることはな いであろう。なぜならば、あなたにはその必要がないからである：あなた は画像そのものを見ることができる。
アクセシビリティとは、つまるところ、代替手段のことである。何らかの 理由で、絵が見られない？ご心配なく、代わりに読むための言葉を提供し ます。残念ながら、このような単純なことですら実行されることは希であ る。Web 編集者はいろいろなことに気配りをしなければならない：生活費 を稼ぐ、締切に間に合わせる、目立つように飾りたてる、自己を表現する、 顧客を喜ばせる。一般的に彼らの興味を引かないことといえばアクセシビ リティである。なぜか？
このような問題はあるが、アクセシビリティを考慮して制作することは、 非障害者の人たちをも助けることになる。ちょうど段差のない入口や車椅 子のためのスロープがベビーカーを押している人たちのビルへの出入りを 楽にしてくれるのと同じように、アクセシブルな Web サイトは、高齢の インターネットユーザー、画像の取り込みをオフにして使っている人たち、 そして Web 対応可の PDA や携帯電話にも適している。
リソース -- しかし、責任を全部 Web デザイナーにかぶせることもで きないし、Web デザインの仕事にお金を出したクライアントの責任にはもっ とできない。単刀直入に言って、アクセシブルな Web のオーサリングの ためのリソースはお粗末だ。
現在の HTML 規格にはアクセシビリティに関する機能が多く含まれている。 ALT 属性はその上っ面を撫でてもいないぐらいだ（もっとも現在の HTML バージョン 4.01 では実は ALT は必須となっている）。こういった HTML 仕様の元は World Wide Web Consortium の Web Accessibility Initiative（WAI）で、ガイドライン、チェックリスト、アクセシブルな Web ページを作成するテクニックなどが書かれている。しかし、World Wide Web Consortium 規格文書の偉大なる伝統にのっとって、そのページ は長く、入り組み、とりとめがなく、頭にくるぐらい一般化されているか、 過度に詳しい。
<http://www.W3.org/WAI/>
<http://www.W3.org/TR/WCAG10/>
アクセシブルな Web をオーサリングするためのリソースは、他には驚く ほど少ない。リンクは HTML Writers Guild Aware Center か、私が管理 する Web AccessiBlog で見つけられる。
<http://www.awarecenter.org/>
<http://www.joeclark.org/accessiblog.html#specs>
アクセシブルな Web デザインに関する本は 2 冊しかない。Crystal Waters 氏の『Universal Web Design』（絶版）か、Mike Paciello 氏の 『Web Accessibility for People with Disabilities』だ。（先週私は New Riders Publishing 社とそれらと張り合うような本を書く契約にサイ ンした。）
<http://www.typo.com/store/webbooks.html>
<http://www.webable.com/book_desc.htm>
<http://www.amazon.com/exec/obidos/ASIN/1929629087/
tidbitselectro00A/>
一言で言うと、アクセシブルな HTML をコーディングする方法を学ぶのは 難しい。それに、オーサリングツールは、Adobe GoLive や、Macromedia Dreamweaver、信頼できる BBEdit でさえ、アクセシビリティの機能を加 えにくくなっている。たいてい手でコーディングする必要がある。
暗い Web を抜けて -- Web ページのデザインは、問題の片面で、もう 片面は支援技術によるものだ。低視力の人は Apple 社の CloseView ユー ティリティや Alva Access Group 社による InLarge などの画面拡大のソ フトウェアを使用している。
<http://www.aagi.com/aagi/inlarge.asp>
（Web ブラウザのすごく大きなフォントサイズを選択したらいいじゃない かって？ブラウザが Mac 上で動いていることを忘れないで欲しい。シス テム全体がアクセシブルになる必要があるのだ。Web ページが素晴らしく 大きな文字でも、メニューバーのフォントやダイアログボックスがまだ小 さな 12 ポイントのテキストを使用しているなら、あまり足しにはならな い。さらに、実際に行われている Web オーサリングが貧相なため、多く のサイトは悲惨な見た目になり、特大のフォントではほとんど使い物にな らない。）
もし低視力を持ち、モニタに何が映っているのか拡大してもまったく見え ないなら、スクリーンリーダが必要となる。これはスクリーン上のテキス トやメニューを読み、アイコンやその他のアイテムを解釈して読み上げる プログラムだ。しかし、Mac 用にはたった一つのスクリーンリーダしかな い。Alva Access Group の OutSpoken だが、HTML の解釈はしてくれない。 それに対し、Windows のスクリーンリーダは明らかに洗練されていて、テー ブル、フレーム、HTML のアクセシビリティの機能の多くを理解している。
<http://www.aagi.com/aagi/outspoken_products.asp>
<http://www.joeclark.org/accessiblog.html#screen>
だがしかし、うまくコーディングされた Web サイトでも、次の事実のお かげでアクセシブルでないことがある。それは、どのブラウザも 完全に HTML をサポートはしていないということで、その言語のアクセシビリティ の機能すべてなんていうまでもなく不可能だ。
<http://www.joeclark.org/glorious.html>
Netscape 4 はその非互換性で悪名高く、1997 年当時に通用していた HTML タグでさえ互換性がない。Macintosh 版の Microsoft Internet Explorer 5 は HTML 4 を完全にサポートしていることになっているが、 それは本当ではない（LONGDESC といった、画像を長いテキストで説明す る機能などが欠けている）。Mozilla プロジェクトは未サポートの HTML タグの一大リストを、規格にちゃんと準拠したとされている新しい Netscape 6 でも維持している。
<http://www.mozilla.org/newlayout/faq.html#Which%20open%20standards>
ところが、小さな、印象的な Web ブラウザ iCab は、HTML 4 のサポート の範囲はずっと幅広く、iCab のアクセシビリティのサポートは文書化さ れていないけれど、ほぼすべてのアクセシビリティに関するタグ （LONGDESC も利用できる）が含まれている。
そしてもちろん、Mac 版唯一のスクリーンリーダは、メーカーの認めると ころにより、HTML を解釈せず、Windows で見られるようなブラウザとス クリーンリーダとの緊密な統合は Mac に欠けているのだ。率直にいって、 なにかやれるようならラッキーなぐらいである。
盲目か低視力の Mac ユーザーのための Web アクセシビリティとなると、 まったくもってひどいニュースしかない。短期的には、このような人々は まだ Windows を使った方がうまくやっていける。次の記事では、アクセ シブルなマルチメディアに関するもっと微妙な問題に注意を向けるつもり だ。いったいあの QuickTime ムービーや Flash アニメーションをどうし ろというのか？
[Joe Clark 氏はトロント在住の元ジャーナリストで、障害に関する分野 に 20 年間たずさわり、執筆し、働いてきた。アクセシビリティに関する 多数のオンラインリソースを彼の Web サイトで読んでみよう。]
by Adam C. Engst <ace@tidbits.com>
（翻訳：尾高 里華子 <rikako@pobox.com>）
（ ：尾高 修一 <shu@pobox.com>）
先週は、共同で文書作成を行う際の作業方法に関する検討事項についてと、 TidBITS ではどのような手順で作業を行っているかについて取りあげた。 今週は私が今まで経験した別のプロジェクトの作業手順についてお話しよ う。また、TidBITS Talk では、私が使ったことのないツールなどが紹介 されているので、この手の話をもっと詳しく知りたい方は是非ともご覧に なっていただきたい。
<http://db.tidbits.com/getbits.acgi?tbart=06327>
<http://db.tidbits.com/getbits.acgi?tlkthrd=1312>
本作りの場合 -- 私は数社の出版社から本を出しているが、一つの例外 を除き、作業はだいたい似たような手順で行われていた。私一人で書いて、 担当編集者が 1 人ないし 2 人付くというのがほとんどだったので、原稿 のやり取りはメールだけで済んだ。FTP で原稿を受け取りたいという出版 社もたまにあるが、これは裏目に出てしまうと判った。
どこの出版社も一様に Microsoft Word 形式を使うよう指定してきた。最 初の 2 冊のときは、まず Nisus Writer で書いてから Word にエクスポー トして出版社に渡していたが、その後は Word しか使わなくなった。 Nisus Writer で書くほうがはるかに好きなのだが、原稿をエクスポート したりインポートしたり操作したりといった作業（を時として何度も繰り 返さなければならなかったりすること）の煩わしさの方が、好みがどうこ うというより大きくなってしまったのだ。
Word のバージョンが 6 になるまでは、原稿の大きな変更箇所には（レイ アウトに影響の出る恐れのある文字スタイルを一切使わずに）ただ色を付 けるだけで区別がつくようにしていた。しかし、Word 6 からはどこもか しこも Word の変更履歴機能に頼るようになった（結果の方は様々だった が）。とりわけ編集者が何人もいる場合はどこを誰が変更したのかを特定 するのに便利であるが、変更履歴機能を利用した文書はすぐに見苦しいも のになってしまう。削除テキストのスタイルを、Strikethrough ではなく Hidden にすることで、ごちゃごちゃした見た目ををいくぶん隠すことが できる。また、変更履歴機能を使用して原稿に追加や削除を行うと、パラ グラフ切りのところで訳がわからなくなってしまいやすく、それがパラグ ラフスタイルの変更箇所だったりするとなおさらである。それに加えて、 Microsoft 社は簡単に変更を受容したり却下したりできるようにしようと しているものの、本一冊分の文の中にはものすごい数の変更対象箇所があ るので、「すべて変更」を選んでさっさと終わらせてしまいたくなるだろ う。
コメントに関しても、だいたいどこも似たような決まりを採用していて、 該当箇所のパラグラフのすぐ下にコメント行が来る。たいていは本文とは 別のコメント専用スタイルを用いる。編集者や校閲者が何人もいる場合は、 コメントにイニシアルをつけてみんなに判るようにする決まりがある。こ のやり方は、Word がコメント機能を搭載してからも変わらず使われてお り、執筆中にコメント機能を利用しようという話は一度も出たことがない。 黄色のコメントポップアップはうっとうしく、コメントペインはぶざまな うえにデフォルトの文字は小さすぎる（また、Mac のWord 2001 では、コ メントペインのクローズボタンが 2 度クリックしないと実行されず、ま ともではない）。さらに、コメントは一単語以上に対してにつけるのが Word の仕様なので、コメントを入れるために選択する文字列が多くなる。 そのために、文書中の明るい黄色になるコメント対象範囲が不要に広がっ てしまう。
上記のやり方と唯一違っていたのは、Eudora Visual QuickStart Guide を書いた時だ。比較的文章が少なく、スクリーンショットやキャプション が多く、レイアウトが大切だったので、執筆とレイアウトを直接 QuarkXPress で行った。QuarkXPress 3.3 には、ファイルにコメントを入 れるよい手段が搭載されていないので、私のファイルを受け取った編集者 は、まずそれを印刷をして、赤鉛筆で指示などを書き込こんだものを UPS で送り返してきた。野暮ったいやり方に思えるかもしれないが、レイアウ トに関するコメント（カーニングやライン揃えなど）があまりにも多いの で、画面を見ながらのプルーフでは正確さを欠くうえに作業ばかり増えた だろう。
雑誌 & Web への執筆 -- 雑誌や Web への執筆も、編集者の数が 1 人 ないし 2 人ということと、ファイルを（常にメールで）やり取りすると いう点では本の場合と変わりない。雑誌の場合も文書形式は一様に Word になっているが、Web 出版ではメッセージの本文にプレーンテキストを貼 り付けるか、HTML のどちらかが好まれる。
ほとんどの定期刊行物では、記事は短いし締め切りまであまり日がないの で、コメントはかなり少なくなる。月刊雑誌用の長い記事だと、編集の手 が相当入ったり、何人もの編集者の手を経なければならなかったりするこ とが多い。こういった出版社は、意図するところは正しいので、必然的に 積み上げられてできたとおぼしき決まりに沿って作業しているが、まった くなっていない。変更個所に関しては、なにも記されていない場合もある し、青色になっている場合もあるし、Word の変更履歴機能を利用してい ることもある。色を付けるなり、Word の機能を利用するなりのどちらか だけでやってあると大丈夫なのだが、編集者がやることに一貫性が欠けて いることがままありライターは混乱してしまう。
同様に、パラグラフの最後にコメントを入れる編集者もいれば、文中の該 当箇所にコメントを挿入する編集者もいる。パラグラフ中に長いコメント が入ったりすると、本文の流れがわからなくなってしまいやすい。本の編 集者とはちがって、Word のコメント機能を使ったことのある雑誌の編集 者に出会ったことはない。もっとっも、その他の状況でまったく別の経験 をしたこともあるのだが。
法的文書 -- 私が XNS Public Trust Organization の立ち上げを手伝っ た時、数人の理事たちと長文かつ複雑な文書を作成した。憲章や XNS Global Terms（規約）などといった各種の法的な契約文書などだ。作業に 携わったのは 4 人の理事と一人の弁護士だけだが、この場合には執筆者・ 編集者という関係はなく、集中管理用のサーバもなく、出版のプロである 校閲者もいなかった。
<http://db.tidbits.com/getbits.acgi?tbart=06133>
私たちが採用した方法は、Word 文書をメールで送りあうというものだっ た。誰もが多忙だったこともあり、回覧方式を採用し、誰もが文書を手に した時点でそれまでに加えられたコメントを見ることができた。弁護士は 例外で、4 人と並行して作業を進めていた。（私は Word の Compare Documents と Merge Documents 機能を使って弁護士のコメントや修正を 取り込もうとしたが、結果はまったく役に立たなかった。）変更履歴はあ る程度使ったが、作業は内容を検討しながら進めるというものだったので、 修正は比較的少なかった。一方、Word のコメント機能は多用することに なり（文書 2 つで 100 以上のコメントがあった）、そこそこ使えるもの ではあったが多くなると扱いにくくなるという印象を受けた。
XNS の公開直前に XNS Global Terms の最終版を作らなければならなかっ た時は、例外的な事態となった。それまでの遅れを取り戻すため、作業を 一日で完了しなければならず、しかも作業に携わったのは 10 人ほどで、 そのうち半数は弁護士だったのだ。当初、一人に文書を預け、未解決の事 項は電話会議で擦り合わせようとしたのだが、この案は現実的ではないこ とがわかった。弁護士の一人が、各文書につき一人の責任者を決め、メー ルを使った作業に戻ろうと提案した。元の文書は Word 形式だったので、 最終的にはその日の夜に HTML に変換することが目標だったのだが、継続 して Word フォーマットで行くことにした。しかも、使用マシンは各種 Mac と PC でばらばらだったが、全員が最近のバージョンの Word を持っ ていた。
Word の変更履歴機能はこういった状況で絶大な威力を発揮した。何がど う書き換えられたかがはっきり見えたからだ。最後に校正者が控えている わけではなかったので、どんなに小さな修正も印されている必要があった。 文書の責任者だけが見る必要のある書き込みはコメント機能を使って書か れたこともあったが、コメントは主として文書が添付されるメールの本文 に書きこまれた。このため、文書をわざわざ開いてざっと目を通すという ことをしないで済んだので、速くて広範なディスカッションが可能になっ た（私は Eudora が一分ごとにメールをチェックするように設定してい た）。他のプロジェクトで採用した、パラグラフ間にコメントを書き込む という方式は、この場合には採用されなかった。その理由の一つは、最後 に削除するテキストを間違える恐れがあったからで、もう一つはコメント の書き込み方を事前に取り決めておく時間がなかったからだ。
こうした経験から身をもって学んだのは、Word 文書の効用が多数のユー ザー定義スタイルに足を引っ張られることだ。適度の注意と、もちろん Word のスタイルがどのように機能するかという知識なくしては、スタイ ルを多用した Word 文書は校正者の悪夢となる。これまで述べたような協 同作業から得られる結果は内容的には立派なものだったが、それ以外の点 では目も当てられないものだった。一部のパラグラフには間違ったスタイ ルが適用されており、また別のパラグラフは正しいように見えて実は手動 で「直して」あったし、それに Word が自動的にすること（たとえば連番 - 法律文書はたいてい連番だらけだ）はほとんど必ずぐちゃぐちゃになっ ていた。こうなっている文書を手直しするのは最初からフォーマットし直 すよりは速かったが、それほど変わるものでもなかった。
文書作成共同作業のシンプルなやり方 -- 上で書いたやり方や、先週お 話した TidBITS で採用している方式などの要点を私なりにまとめて、以 下に文書作成共同作業を成功させるためのやり方に対するアドバイスを 6 項目挙げておく。グループで作成する論文、チームの報告書、雑誌の記事、 技術図書などといった何らかの形で公表するもののファイルのやり取りの 参考になるだろう。
<http://db.tidbits.com/getbits.acgi?tbser=1159>
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 