作家とバージョン管理

以前友人が所属する変態劇団の舞台を見に行ったとき、まだデビューもしていない小説家志望の男性が原稿用紙にペンを走らせるというシーンがあった。突然携帯が鳴り、シーンが進んでいく。どうして変態かというと、観客の前でフェラの演技をしたので。そういうの大好きだが。

演劇と文明の利器は相性が悪いことが多い。登場人物が作家を目指して今執筆中というシーンを示すのに、パソコンでワードを開いてカタカタやっていても観客には何をやっているのか伝わらない。原稿用紙とペンでないとそれは伝わらない。逆に携帯は舞台のツールとしてはうってつけのようだ。演技でもしきりに携帯を利用していた。ここらへんのツールの差というのはいろいろと興味深いものである。

それを見て、今時、原稿用紙に直書きしている作家なんているのかと思った。しかし、モノを書くというのは完全なるセンスの世界なので、おのおのが独自のスタイルでもってあたるはずだ。自分の一番馴れた、一番しっくりくる形で作業にあたらないと効率が全然違ってしまう。ひょっとすると、未だに原稿用紙でないと雰囲気が出ないからとパソコンを使わない人もいるのかもしれない。

だが残念なことに、原稿用紙を使うような作家はこれからは生き残れないだろう。もはやストーリーというものは、作家一人の力量を超えるようになってしまったのだ。プログラムと似ている部分である。プログラムも機能の複雑化のために、どんどん巨大になっていき、人一人で管理するのは不可能なサイズになってしまっている。一つのプロジェクトで一人で管理できるソースコードの量は、大体2万行が限界だろうと思う。この2万行にしても、単純なテキストエディタと記憶とに頼って作業していると、あっという間に破綻する。昨日はどこを直したんだっけ、今日はどこを直すんだっけ、先週直したあそこと矛盾してる気がするけどあそこってどこだっけ、と人間的な作業に頼っていてはとんでもない欠陥品が出来てしまう。だからプログラマはバージョン管理ツールを使ってバージョン管理をする。

バージョン管理ツールを使えば、自分のした作業が全て記録されるし、昨日の作業と今日の作業でどこが違っているのかを一発で差分が取れる。ああここを直したんだったというのがすぐにわかる。昔のバージョンに戻すのも簡単だ。間違って手元のファイルを消してしまってもすぐに復元できる。

バージョン管理ツールでの管理単位はコミットという。自分で区切りのいいところで、今ある成果物をコミットすると、あとはツールが覚えてくれているので消そうとどういじろうとまたいつでも復元できるのだ。
このコミットの際には、コミットログを残すのが慣習となっている。何を変更したのか、何故変更したのかを一緒に記録するのだ。そうするとあとからコミットログを辿っていけば、その変更が何のどんな変更だったかは一目瞭然だ。

作家が一つの本をつくるとき、大体数百ページくらいになると思うが、これを本として世に出すためには、プロの編集者や推敲者の厳しいチェックが入る。作家が最初に書いたオリジナルがそのまま採用されることなんてまずないから、何回どころか何十回と推敲され、ここが論理的に間違ってる、ここは表現をこうした方がいい、このキャラクターの言動はおかしい、といったものから、単純な誤字まで、何度も何度も手直しをすることになる。

普通最近の作家はワードを使って文章を書くが、編集者に読んでもらうときには紙にプリントアウトして送ることもある。その紙媒体に、推敲者が赤字でいろいろと間違ってる箇所を指摘してくれたりするようだ。作者は、それを自分のワードの文章に取り込まなければならない。推敲者がワード上で直接間違い箇所を直してくれれば、一応ワードにも変更履歴機能がついているので、作者的には楽かもしれない。しかし、ワードの変更履歴機能は適当すぎるので、文章をごっそり削除してしまったのに履歴に残っていないなど、事故につながるリスクも高い。紙に赤文字修正も、それなりに事故防止という観点からはよいのかもしれない。

しかし、推敲者の指摘はものすごく数が多いので、作者もそれを取り込んでいるときにミスをする可能性がある。プログラマなら、自分が修正したソースコードをコミットするときに、前回との差分をツールで一箇所一箇所チェックしていくから、間違った修正をしてしまうリスクは減らせる。しかし作家の手作業やワードのしょぼい変更履歴機能では、とうてい無理である。

つまり、作家もプログラマと同様に、バージョン管理ツールを使うべきなのだ。最近はワードの変更差分も視覚的に問題なく表示できるようになった。何よりも効果があるのはコミットログの変更理由ではないだろうか。例えば、このキャラのこういう言動が矛盾してるからこう直したんだよというのを記録しておけば、あとからどうしてここはこうなってるんだっけとなったときに、変更理由を見て納得できる。その当時にどうしてそこを直したのかを全て記録できるというのはものすごいメリットなのだ。

普通作家の成果物は、ストーリー1つのワード1ファイルだろう。たった1ファイルでもバージョン管理するべきだし、編集者との打ち合わせややり取りしたメールも一緒のフォルダに入れてバージョン管理すればよい。
一つのストーリーを一つのプロジェクトととらえて、それにまつわるものをどんどん放り込んでバージョン管理していけば、きっと快適な環境になるに違いない。

一度バージョン管理をやったものは、二度とバージョン管理のない世界には戻れない。コミットの際に前回との差分を見て、しょうもない間違いに気付いたことが何度あったろう。一度コミットしてしまっても、あとから、過去の二つのバージョンの差分をとれば、そのときの作業にミスがなかったことを確認できる。ミスをミスのまま反映してしまうということが確実に減らせるのだ。ただのワードで管理していては、ミスの修正漏れが出てくるに決まってる。

TortoiseSVNという亀と呼ばれるツールを使えば、Windowsマシン一台で簡単にバージョン管理が出来るようになる。

以前妻にどうやってワードファイルを管理しているか聞いたら、日付ごとにバックアップフォルダにバックアップ的な回答だった。亀使えばいいよとメリットを説明してやったが、今も使っていないようだ。これを機に亀を使うべきだ。

作家が利用できるバージョン管理ツールは亀以外にはない。他のツールは明らかにプログラマに最適化されすぎている。

人間がいかにミスをする生き物か、そのミスを減らすためにツールがいかに有効か、バージョン管理ツールを使うようになれば、ミスというものへの考え方が変わるはずだ。

バージョン管理ツールを使えば、他の作家よりも一歩先へ行けるはずだ。もちろん管理対象のストーリーが最重要なのはいうまでもないが。

ところで、こんな時間にブログなんて書いてておまえ仕事どうしたんだと思われるかもしれないが、今日は休みだ。取り損ねていたお盆休みをとって、しばらくはだらだらと過ごすことにした。今日は昼間から雀荘に行くつもりである。

オープンソース的な空気の気持ち悪さの正体

筑紫哲也の最終著作「若き友人たちへ」を読んでいるが、興味深い記述があった。都市デザインについてのくだりで、東京を象徴する3都市は、渋谷と原宿と秋葉原だと。
以下引用。

その特徴は何かというと、渋谷は見せたがる人たちが集まっている。ガングロとかいろんなことをやっている。それでガラス張りの建物が多い。みんなに見せたいし見えるようになっている。
対照的に秋葉原はみんな密室。窓がない。カフェへ行った人は分かる。要するに、アキバ系は非常に内向的で内にこもる人たちが多くて、外と遮断して見えにくくするというのが特徴だと。
その中間が原宿・表参道で、外との関係を簡単にいえばすりガラス。

私はオタクではないが、アキバ寄りの内向的な人間である。その私が客観的に見て、渋谷と秋葉原のどちらがより文化として密度が高いかといえば、どう見積もっても秋葉原であろう。
初めてCD-ROMでLinuxを配ったのもアキバだし、メイド喫茶やビンタ喫茶や足で踏まれ喫茶にスカトロ撮影会と、あらゆる娯楽を生み出してきた。そしてその娯楽は、たとえブームが終わったとて人々の心に深く刻まれてきた。
ひるがえって渋谷はどうだろうか。何か我々に残しただろうか。ファッションという名の亡霊をちまちまと追いかけ、風の方向が変わるがごとく衣装を着せ替え、結果、何も残らなかった。

それはどうしてなのか。ガラス張りだからであろう。みんなに見せたいということは、大して作りこまずに見せるという結果を招きやすい。とりあえず派手にアピールしておけばあとは行列効果で人寄せには困らない。
みんなから見られるということは、みんなのレベルに合わせなければいけないということでもある。奇抜なものが評価されるようでいて、その奇抜さはその実みんなの想定内だったりするのだ。
全てを見せるというのは制限でもある。外部からの評価を常に気にし続けるというのはクリエイターからすると単なる妨害である。

少し前から、ネットでプログラムやコードの発表会が流行った。「〜にインスパイアされて〜を作ってみました。」的なものが頻発した。とにかくコードを書いてみて発表することが善という空気が場を満たしていた。
そういうもののほとんどは、まるで渋谷のようなコードだった。

ネットで発表するのは、思ったよりもコストが高い。最低限の体裁を整えるだけでも数時間は軽く消費される。みんないかにもさっと片手間に作ってみました的にすまして発表しているが、背中は汗びっしょりなのだ。
そんなくだらないことに時間使うくらいならスカトロ動画でも見ておいた方がよっぽど生産的なのだ。

ネットで発表すれば間違いも指摘してもらえるし、みんなからこうしたらいいよという意見ももらえるし、本人にとって素晴らしい成長の機会になるというのもずいぶん寒い話で、しょうもないコードを発表して釣れる意見なんてたかがしれているという大前提を忘れている。大物を釣るためには自分も大物でなければならない。そのために費やした時間を読書にあてれば専門書の一冊でも読めたはずだ。どちらが獲得知識総量として重いか。

渋谷はくだらない街だ。もちろん必要だが、自らそこへ赴こうなどとは思わない。なんでもかんでもオープンにすればよいというものでもないのだ。ネットで顔をさらしている大物プログラマを見てみるといい。金子氏を見てみろ、やねうらお氏を見てみろ、どこに渋谷系がいるというのだ。反対に渋谷系のプログラマの顔を思い浮かべてみるといい。あえて名前はあげない。

筑紫哲也はすごかった

「若き友人たちへ」のあとがきは、筑紫哲也が高校時代に書いた文章が娘さんの希望で載せられていた。おどろいた。高校生の書くようなレベルではなかった。やはり偉人というのは子供の頃からその片鱗を見せるものなのか。
私が高校生のときに書いた文章を思い出してみる。学校の教師が自殺をしたときに、その先生に対して何かみんなで書きましょうみたいな流れだったので、「うちの金魚が死にました。教師が死んだことよりもよっぽど悲しいです。」という内容のものを提出したら、担当教師になんだこれはと怒鳴られ、みんなの前でその恥ずかしい文章を朗読させられた。私としては、他人の死など本当はちっとも悲しくもないのに、それに対してみんなで悲しんだふりをして虚言を並べるのがあほらしいと思って一石投じたつもりだったが、大変な目にあった。
だがそんなくだらない文章も、高校生時代の筑紫哲也との共通点も見受けられた気がした。諦念、のようなものである。やたらに冷めているというか。筑紫哲也のあとがきを読んでみればわかるが、当時の彼は周りを見下していたようである。こいつらみたいなくだらない人間にはならないぞと固く誓った的な文章もある。なんだ筑紫哲也も中二病かとホッとしたものだ。