[Work][Retrospective] Retrospective: yamamoto-xyzzy（入門xyzzy）
yamamoto-xyzzy（入門xyzzy）
##############################

担当している書籍のretrospectiveもどきをしてみる。そもそも「もどき」だし、まだ進行中のプロジェクトなので、あくまでドラフトということで。後で時間があったら加筆修正して載せ直そう。

これは、^CさんのRadium Software Developmentでよく話題になっている、ゲーム開発プロジェクトのpostmortemに触発されたものだ。ただpostmortem（検死）という言い方はちょっと刺激が強いと思うので、retrospective（回顧）としたい。

Radium Software Development
040421 - Postmortem
http://www.radiumsoftware.com/0404.html#040421

Gamasutra::Features::Postmortem
http://www.gamasutra.com/php-bin/article_display.php?category=5

原稿の管理システムと原稿のデータフォーマット
============================================

今回は執筆にMLとWiki（PukiWiki）を使い、編集段階で版管理システム（Subversion）を使っている。組版はMacDTP。流れは次のとおり。

1. MLで議論をしてWikiで分担して執筆


2. Wikiのまま査読者と編集者が査読して、Wiki上にコメントを書き込む形でフィードバック


3. フィードバックを著者が原稿に反映して脱稿とする


4. 編集部で原稿をプレーンテキストに変換して版管理システムの管理下に置き、編集を加える


5. 編集が済んだプレーンテキスト原稿を組版スタッフに渡す


6. 以降はPDFを援用しながら紙の上で校正

Wikiは、多人数で「ラフな草稿」を「分担執筆」するのに便利なことはよく知られているとおりだ。一方、実装にもよるけれども、細部まで制御しながら全体の統一を図る仕上げの作業にはあまり向かない。インタフェイスがウェブに限定され、全原稿を横断して編集することができないので、全体を俯瞰して構成を検討することや、用字用語を統一することが難しい（実際、テキストにして編集してみたら、見出しのレベルを調整する必要が明らかになり、用字用語の不統一もかなり見つかった）。最終稿を仕上げる際には、並行作業が可能な版管理システムのもとで、そのまま組版入稿ができるプレーンテキストベースの形式で執筆編集したほうがよい。

まとめると、アイデアメモやブレーンストーミングをWiki上で行い、実際の原稿は、プレーンテキストベースの形式で、版管理システムの管理下に置いて執筆・編集するのが良さそう。ただし、執筆の主体となる著者のモチベーションを下げるような押し付けをしてはならない。目的を同じくする関係者同士、よく相談して決めることが大事。

原稿管理システムの条件
----------------------

版管理システムでアクセスでき、原稿をテキストとして引き出したり収めたりできることが最低条件。あとできれば認証とアクセス制御もできるとなおよし。

WikiでもBlogツールでも、ウェブしかインターフェイスがないものや、Wordのように特定のソフトウェアでないと扱えないデータ形式は極力避ける。CMSツールといいながら版管理もウェブ以外のインタフェイスも持たないものは論外。

ひとつの優れた解として、他の企画で或る著者が採用しているハイブリッドな方法がある。次のような仕組みで動いている模様。

  +- Subversion -+  --------------(RD)-----------> Author
  |              | /
  |     (RD)-------+----[Hiki]--(HTML)--[httpd]--> Reviewer, Editor
  |              | \
  +--------------+  --[filter]--(Text)-----------> Editor

著者はRD形式の原稿をSubversionで管理する。このRD形式の原稿がマスターとなる。査読の際にはWikiクローンのHikiを使ってRDをHTMLに変換し、それを使う。組版用の原稿が必要な場合は、オリジナルのフィルタでRDをプレーンテキストベースの形式（TopML）に変換し、編集者に受け渡す。

この方法だと、著者は自分が書きやすいRDで書くことができる。査読者はブラウザを使ってウェブ経由で査読することができる。編集者は査読者同様にウェブ経由で査読できる（必要ならリポジトリにもアクセスできる）。また編集者は最終的にプレーンテキストで原稿をもらえるので、すぐに組版に渡すことができる。つまりみなが満足できる。

ここまでの仕組みを用意するのが難しい場合は、少し簡略化して次のようにしてはどうか。

  +- Subversion -+   --------------------> Author
  |              |  /
  |    (Text)-------+--[filter]--(HTML)--> Reviewer, Editor
  |              |  \
  +--------------+   --------------------> Editor

原稿はプレーンテキストとする。著者と編集者は版管理システムを共有して使い、定期的にスナップショットを査読者に提供する。テキストをHTMLに変換するフィルタを書いておき、査読者向けにはHTMLを提供する。

原稿のデータ形式の条件
----------------------

書式が読みやすく、そのまま、もしくは少しの加工をするだけで組版入稿可能なこと。サードパーティの複雑なフィルタを介さないとプレーンテキストにならないものは、気付かないところで変換ミスが起きていると恐いので、極力避ける。現実的にはTopMLをはじめとするプレーンテキストベースの簡単な形式を使うのが安全。

Wiki記法の多くや、TeX/LaTeX形式はこの条件を満たさないので避ける。これは記法の優劣とは無関係で、単に用途に適しているかどうかの問題。自前で変換フィルタを書いて自己責任で使うならば話は別。ただし変換フィルタは原稿を書き始める前に完全に動作するものを用意して実データで検証しておくこと。そうしないと後で泣きを見る。

HTMLは、将来性はあるけれども、まだ安全に使うための条件が整っていない。次のようなデメリットがある。

• 関係者全員にHTMLの正しい知識が必要になる。


• 自由度が高いので運用のルールを細かく決める必要がある。


• プレーンテキストに変換する際に、変換ミスが起きる可能性がある。ブラウザ類の実装によって空白や改行や空行の扱いはさまざまに異なるようで、具体的には次のような問題があった。
  
  • テキスト保存をすると、半角80桁あたりで改行が入る（Mozilla）
  
  
  • テキスト保存をすると、Mozillaのように強制改行はされないものの、たまに任意の場所で改行が入る。発生条件は不明（IE6）
  
  
  • 表示されているテキストを全選択してコピーペーストすると、半角カナが全角カナに変換される（Mozilla）
  
  DTP組版に受け渡すためにはプレーンテキストでなければならないので、結局は余計なことをしない変換フィルタを自前で書くしかなさそう。

今回は、HTML中にマークアップ用記号を仕込むスクリプトをRubyで書き、それでHTML原稿を処理し、それをMozillaで開いてレンダリングされたテキストを手作業でテキストファイルにコピー&ペーストした。

役立った道具や方法
==================

今回使ったなかで特に役立ったものは、版管理システム（Subversion）、ペアエディティング、高機能なテキストエディタ（xyzzy）、文字指向のdiff（DocDiff）、校正用ツール（variation/homonym, JustRight）、連絡用ML（QuickML）。

一般的なUnixツールやスクリプト言語などは、ここでは触れない。

版管理（Subversion）
--------------------

版管理システムに原稿を預けて複数人で編集するのは極めて効率的。ロックせずに並行して作業できるうえ、編集者全員の過去の作業を自由に参照できるので、単純に作業効率は上がるし手戻りのリスクも減る。
今後は編集部内では版管理を必ず行い、社外にも使用を推奨したいところ。

外部サーバにリポジトリを置くのは、コストがかかるものの、社外の著者やスタッフからもアクセスできるし、自宅でも時間を気にせず作業ができるので便利。今回はできなかったけれども、今後は著者やスタッフにも版管理の重要性を理解してもらい、参加していただきたいところ。

気が付いた注意点を挙げる。

• 原稿はプログラムと違って1行が長いのでconflict（変更箇所の衝突）が起きやすい。conflictが起きると作業効率が落ちるので、できるだけ避けたい。対策としては次が考えられる。
  
  • 編集MLでどういう編集をするつもりか宣言する
  
  
  • なるべくこまめにコミットする
  
  
  • 原稿を章ごとに別ファイルに分けて、章ごとにコミットする


• proxyサーバがHTTPを通すからといって、HTTPのすべてのメソッドを透過させているとは限らない。これに気付かずに、Svkでミラーができなくてしばらくはまった。


• ログメッセージに日本語の文字が使えるようにしておくこと。日本語の原稿の変更を記述するには、日本語の文字が書けないとたいそう困る。また一般人は日本語が使えないと当然拒否反応を示す。

ペアエディティング（Pair Editing）
----------------------------------

原稿を版管理システムで共有して、席が隣同士の2人の編集者で疑似Pair Editingを行った（1台のPCを使わないのと、役割を交替しないあたりが疑似）。

メリットは、複数人の目で見られることと、非同期で効率良く並行作業ができること。updateをかけるたびに原稿の問題点がみるみる改善されていくのは、素晴らしいの一言。

デメリットは、効率が良い半面、手を抜けないので、おそろしく疲労すること。適度に休憩を入れずにやらないとぼろぼろになるので注意。ペアエディティングをしているなら、残業などしてはいけない。あと版管理システムの学習コストが初期的にかかるところ。でもそれは1冊編集すればすぐに回収できる。

xyzzy
-----

Windows上で動作して普通の人にもとっつきやすく、しかも十分に強力なエディタというと、これくらいしか選択肢がない。Emacsは、自分が使う分には全く問題ないが、ごく普通の人に使ってもらうにはMeadowであっても少々つらい。
xyzzyはセレクションをよくサポートしており、Windowsらしいツールバーやタブバー（バッファバー）があるので、普通のユーザでもなじみやすいようだ。拒否感があるようなら、最初のうちはgates.lやwinkey.lを使って慣れてもらうとよいかもしれない。

複数のバッファにわたって検索を行うgrep関数（Emacsのoccurに相当）が強力。ちょっとコードを書き加えてEnterと矢印キーで操作できるようにしたところ、編集作業の相当の部分がgrepとquery-replace-regexpで対処できた。また自分はpickup-patternも目視に役立つので補助としてよく使う。

DocDiff
-------

diffなどソフトウェア開発用ツールの多くはソースコードの処理だけが目的なので、1行が長いテキストには向かない。DocDiffのような文字/単語指向のdiffを使うことで、変更された箇所を素早く特定でき、効率的に作業ができる。

Windows用のGUIツールでは、WinMergeやRekisaには行中の相違部分を示してくれる機能があるようだ。


variation/homonym
-----------------

表記の揺れをチェックするツールはいろいろあるけれど、非対話的に使えて文字端末から使えるものはあまりない。そこでChaSenをラップする簡単なスクリプトをRubyで書いて使っている。

JustRight
---------

音引（ー）の代わりに罫線（─）が使われているケースや、二重表現など、他のツールや目視では見落としがちなミスを見つけられる。MS Word の校正機能でもよいけれども、原稿を一度はこの手のツールにかけてみたほうがよい。

QuickML
-------

たいていの企画では連絡もれが生じないように執筆用、製作用の2つのMLを作る。今回は執筆用と査読用の2つのMLを、それぞれ社外のQuickMLと社内のMLサーバとで作っている。

今後への展望
============

原稿の管理システムと原稿のデータフォーマット
--------------------------------------------

可能な限り、次のようにしていきたい。

• 原稿の管理システムは、必ずバックエンドに版管理システムを置く。または版管理システムを直接使う。


• 原稿のデータフォーマットは、プレーンテキストベースの読みやすいマークアップ形式で、HTMLおよびプレーンテキスト（TopML）への機械的な変換が可能なものを使う。著者が編集する形式から、組版スタッフに渡せる形式に、人手を介さず機械的に変換できることが必要。

何より重要なのは、できるだけ早い段階から原稿を版管理の管理下に置くこと。アイデア出しとメモ書きが終わってドラフトを書き始めるときには使い始めたい。

しかしそのためには関係者全員が版管理システムを扱えなければならないが、版管理システムは最初の一歩の学習コストが高い。そこで次のことがいえる。

• 「版管理システム利用の手引き」を用意するなどして、学習コストを引き下げる必要がある。

道具や方法
----------

今使っている道具や方法のなかで有用性が特に高いのは次の2つ。これは引き続き利用を推進していきたい。

• 版管理システム


• ペアエディティング

また、今ある道具と方法に加えて、常により良いものを探して評価していきたい。

• 混在環境を考慮する。関係者全員が同一のプラットフォームを使うということはありえない。また使うツールもさまざまだ。したがって、特定のプラットフォームでしか使えないものや、標準への準拠の度合が低いものは避け、よりクロスプラットフォーム性が高く、標準への準拠の度合が高いものを使う。


• 関係者全員に導入してもらう必要がある。したがって、ライセンスが厳しいものや使用料が高いものはなるべく避ける。


• 関係者の知識やバックグラウンドは人によって千差万別。したがって、なるべく学習コストが低いものを使う。もしくはコストを低減する工夫をする。


• ソフトウェア開発において有効性が示されている方法をさらに取り入れる。ペアエディティングのほかにも、アジャイルな手法が部分的にでも使えないか、試してみる。

こんなところだろうか。