2004/02/02

20年近く前の、11ぴきのねこの話を読んだら、 いろいろな思い出が甦ってきた。 11ぴきのねこの歌がぐるぐる頭を回ってる。

元の戯曲にある歌詞に、自分と、先輩の Oさん、 Tさんで分担して曲をつけたんだった。 機材が揃っていたOさん宅に何日も泊り込んでカラオケをレコーディングして、 本番の後で今度はキャスト総出でコーラスも入れたサウンドトラックを作った。 古いテープをいちいち引っ張り出さなくても、 結局最後までちゃんと弾けなかったフレーズとか、 ソロで音をはずしたところとか、細かいところまで覚えている。

どんな作品も、一度きりしか作れない。 作り終わったら、それを手放して、 また新しいものを一から作り始めなくちゃならない。 でも、その一度きりの時間は、永遠だ。 時間は遡れないから、二度と手にすることはできないけれど、 その時間があったということは永遠だ。 そして、その時間を誰かと共有したということも。

ものつくりが、ものつくりの孤独を受け入れられるのは、 心の中にそういう永遠をたくさん持っているからだと思う。 外套を脱ぎ捨てるように気楽に終わった作品を手放して、 新しい一歩を始められるのは、 永遠の時間を失うことは決して無いことを知っているからだろう。

Tag: 芝居

2004/01/31

昔、ものを作るのは本質的に孤独な行為だと書いたことがある。

創造は、一回こっきりの出来事だ。 欲しくて止まない「それ」は「その時」にしか存在しない。 ひかり輝く「それ」を遠くから見ている時には、何としても手に入れたいと思う。 手を伸ばしてそれを掴んだ瞬間に、それは消えてしまう。

みんなでがんばって、一緒に手を伸ばしても、掴むのは一人一人。 みんながそれぞれ、自分独りだけで、自分にとっての「それ」と対面する。 時間と空間を共有していても、認識は共有できない。成長も共有できない。 手にしたものをそれぞれの心に仕舞って、それぞれの道へと進んでゆくだけだ。

それでもものを作るのは、「それ」を掴んだ瞬間に、 越えられない壁が越えられるような気がするからだ。 真っ暗な空間へと吸い込まれていった音が、 届かないはずの距離を越えて、 自分には認識できない別の世界で、 何かに共鳴する。

何年も何年も経ってから、 そういった共鳴の反響に出会うとき、 孤独の向こう側を信じることができる。

Tag: 芝居

2004/01/29

ぼちぼち税務申告の準備。毎年、ぎりぎり(4/15日)まで引き延ばして きたが、今年はひとあじ違う。 GnuCashを導入したからだ。

昔からずぼらで、記録の類をきちんと書くのは苦手。 特に、家計簿、小遣い帳の類は、決して残高が合うことがないため すぐに嫌になって、続いたためしがなかった。 会社を作った頃、"Accounting for the new business"なる本を買ってきて 読んでみたのだが、さっぱり分からなかった。 用語が全然わからないから、用語の組合せも全然わからない。

しかしこういうのもプログラミングと同じ、習うより慣れろ、が効くようだ。 わからなかったらやり直せばいいやって感じでGnuCashにちくちく入れていったら 基本的なところがわかってきた。だいたい、基本的なケースでは ひとつのtransactionに関係するaccountはふたつだけだし、 GnuCashはaccount画面に直接入力できるので、複式であることを 意する必要がほとんどない。金の行き先はどこか、もしくは 出どころはどこかを考えておけば済む。

複式簿記は本を読む限りではめんどくさそうだったが、 ツールのサポートがあれば、単式よりもずぼらな人間に向いていると思う。 単式だと金額があわなくなることがしょっちゅうなんで嫌になるが、 複式だとエントリ毎に基本的に帳尻が合ってくれるし。

会社の会計だけGnuCashでやっていたのだが、税理士に持ってゆく書類を 用意してる時に、ついでだからと家計の方も別ファイルに入れ始めたら はまって徹夜してしまった。会社はもちろんだが、基本的に個人の方も 小切手とカードが中心で現金決裁があまりないので、 その点では帳簿付けは楽である。

Tag: 生活

2003/12/18

新しいことをする場合、最適な仕様というものが、 作ってみるまでわからないということはままある。 実際に作って、動かして、使ってみて、直して…と、粘土をこねるみたいにして 形を作ってゆかざるを得ない。 ただ、どちらに向かうべきかがはっきり見えなくなることが時々ある。 こういう作り方をしている時は、 テストもコードに合わせてどんどん変化してゆくので、 テストドリブンというのも(方向を決めるのには)あまり役に立たない。

そんな時は、ドキュメントを書いてみると役に立つ。 ある程度形が出来てきたところで、そのAPIのマニュアルを書き下してみるのだ。 すると、自分の中で整理がついていないところは、綺麗に説明が出来ない。 不必要に長い説明を必要とする場合は、方向がおかしいと判断できる。 逆に、APIをこう変えれば説明しやすい、というアイディアを得ることもある。

最初にちゃんとした仕様を書いて…という形式との違いは、 既に動くものが手元にある状態で、それを説明するために書く、ということ。

Tag: Programming

2003/12/11

RFC:2822ってまじめに扱おうとするとめんどいなあ。 ところでstructured fieldはどうしたってCFGなんだが、 誰かがアドレスをパーズするPerlのregexpを書いてたよなあ、どうやったんだろう と思ってぐぐってみたらあった。 うーん変態的。 でも良く見たら「コメントはあらかじめ取り除いておく」って書いてあるじゃん。 コメントはネストするからRGじゃ無理だよな。そうか、残りはgroupがネスト することはないからRGでいけるのか。

Tag: Programming