2012/05/06

使ってもらう手間

元々は電子工作少年で、大学も迷わず電気電子工学専攻を選んだのだけれど、 途中でソフトウェアの方により惹かれていった。 ソフトウェアの方が「人に使ってもらう」のがうんと簡単、というのが大きな理由だったと思う。

ハードウェアだと試作段階は一品物で、作ってる時は楽しいけれど、 それを色々な人に使ってもらってフィードバックを得るというハードルは高い。 それがソフトウェアだと、試作段階からネットでどんどん配って使ってもらえるだけでなく、 共同でどんどん改良してゆける。それが楽しかった。

作ることそのものよりも、それを使ってもらって反応をもらうことの方が自分にとっては 重要だった、と言えるかもしれない。

(最近はハードでも電子的に配布できる要素が増えたし、動作の様子をビデオにすることも できるので、状況がだいぶ変わってきたと思う。今、大学に入ったなら違う方向に進んでいたかもしれない)

90年代前半だと、ソフトウェアの交換というのはいくつかのクラスタに分かれていたように思う。 パソコンのソフトウェアはダイアルアップでつなぐBBSが主要な場だったと思うんだけれど、 自分は大学でネットが自由に使えたので、 usenetに流したりftpサーバに置いたり、という方法で、 UnixやGNUの文化圏にどっぷりだった。

その頃はUnixにも色々バリエーションがあって、ソース配布が中心だった。 ソースのtarballを取ってきて、自分とこのシステムに合わせてmakefileをいじってコンパイルする。 そのままコンパイルして通ることは滅多にないんだけど、それでも手間かけて使ってくれる ユーザからのフィードバックは嬉しかった。

この時代に、autoconfの登場は画期的だった。いちいちREADME呼んでファイル編集しなくても、 ./configure + make + make install で済むのだ。 もちろん当時他にもいくつもこういったメタビルドシステムはあって、ある日突然 autoconfが席巻したというわけじゃないんだけれど。時間が経つにつれ、 一番手間がかからないものが結局は広まってゆく。

まあそんな経験をしているので、configure+make+make installは「使ってもらう」のに 十分ハードルが低い気がしてたんだけど、00年代になったらコンパイルさえも手間ってことに なってきた。いや、むしろ本質的な手間は、依存関係の管理なのだろうと思う。バイナリの 依存関係も相当な手間だが、ビルドの依存関係はそれに輪をかけて手間だから。 そして、autoconfの時のように、手間がかからないものが広まった。 GaucheもWindowsでのビルドは環境を整えるのが手間なのでバイナリ配布を するようにした。(以前は自分がRetHatユーザだったのでrpmも配布してたんだけど、 Ubuntuに乗り換えてからやめちゃった。Gauche本体はあまり外部依存が無いので、 標準的なUnix環境だとビルドも手間ではなかろう、と思ってるんだけどどうかな)。

で、次に減らしたくなってきた手間が「インストールする」というもの。 これはバイナリ配布が前提だけど、ディレクトリをぽんとコピーしたら使えるとか、 zipのまま起動できるとか。確かにそのメリットはわかるんで、Gaucheもそろそろ 考えないとならないと思ってる。

ただ、時代は既に「ダウンロードする」という手間まで減らしたいってとこに入ってるんだよなあ。 いや、正確にはコードはダウンロードされてるんだけど、ブラウザ上でリンクを クリックすればすぐ走り出すソフトであれば、ユーザはダウンロードさえ意識しないわけで。

この「ダウンロードさえ意識させない」というのは別に最近現れた新しい話ではなくて、 そもそもJavaだってappletでそれを目指してたわけなんだけど、ブラウザとは別の ランタイムを要求するってとこがハードルだったのかなあ。 今やJavascriptがデファクトのプラットフォームになった感がある。

これについては、Gaucheとしてどう対応したらいいかまだはっきりとは見えていない。 Javascriptをターゲットにするっていうのは理屈上は別に難しく無いけど、 その上に高く抽象を積み上げてゆく土台としてJavascriptを信頼できるかどうかってとこなんだよなあ。

でも、結局手間がかからないものが使われてゆく、ということをこれまで見てきているから、 いずれ何とかしなければならないだろうなあ。

Tag: Programming