1960 年生まれ,独身フリー・プログラマの生態とは? 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から,2007年に至るまでの生活を振り返って,週2回のペースで公開していく予定です。プログラミングに興味がある人もない人も,フリー・プログラマを目指している人もそうでない人も,“華麗”とはほど遠い,フリー・プログラマの生活をちょっと覗いてみませんか。

 私はほとんど,というかまったくと言っていいほど本を買わない。したがって本屋にも行かない。しかし,先日ふと思いたって,久しぶりにコンピュータ関連の書籍が置いてあるコーナーに行ってみた。あいかわらず「なんとか入門」とか「簡単な○○」といった本が山のように置いてある。私が書店に行かないのは,こういう手合いの書籍が大部分であることを再認識してうんざりするからだ。そして,見るたびに感じるのだ。「本当にそんなに簡単なの?」。

 知人の会社に,頭が切れるという噂の女性スタッフがいる。伝え聞いた話によると,彼女いわく「HTMLなんて簡単」とのことである。後日,彼女が書いたHTMLファイルを目にする機会があった。予想していたとおりと言うと語弊があるが,タグの属性値をクォートで囲んでいなかったり,TDタグを閉じていなかったりといった点が目についた。「HTMLなんて簡単」などと放言すること自体,底が見えていると言うべきなのか。――いや,もしかすると私が厳格すぎるだけなのかもしれない。

 私は立場上,と言うか“付き合い”で自分が直接は担当していないプロジェクトの打ち合わせに出席したり,そうしたプロジェクトのメールが流れてくることがある。先日,とあるWebアプリケーションの開発プロジェクトの打ち合わせの席で,顧客側の担当者が口を開いた。「システムを使っていると,ときどきセッション・タイムアウトのエラーになるんですけど」。やれやれ,これとまったく同じ質問を,いままで何度耳にしたことか。

 担当エンジニアに「HTTPクッキー使ってるんでしょ? タイムアウトの時間を長く設定できないの?」と聞いたが,答えがない。今度は「セッション・オブジェクトはどこに持っているの?」と聞くと,しばらく問答したあげくメモリー上に抱えていることがわかった。そこで,「ログインしていない利用者の場合はセッション・オブジェクトを使わないようにして,ログインしている利用者はデータベースか何かにセッション・オブジェクトを生成したら?」と提案したが,理解してもらえなかった。

 彼はライブラリが備えているセッション機能が簡単だから使っただけであって,何かが起こったときの対処方法を知らなかったのだ。以前彼は「画面を一つ追加してほしいのだが,難しいだろうか」という質問が客先から出たとき,「簡単ですよ。クラスを一つ作るだけですから」と答えたこともある。そのときも私には「クラスだから簡単ですよ」と言っているように聞こえた。プログラミングってそんなものだったのだろうか。――いや,もしかすると私が慎重すぎるだけなのかもしれない。

 同業者と雑談していてよく出る言葉。「そういう機能をコンポーネント化して提供すれば,再利用が可能だし,商品化できればコンポーネントを組み合わせて簡単にシステムが構築できるようになるんじゃないかな」。こちらも少しその気になって,「それなら対応システムはRed Hat Linux 7.2/7.3以降で,最新のアップデートは必須。Apacheはこのバージョンで,PostgreSQLもプライベート・ビルドでディレクトリ構成などが違っていると動かないかもしれないから,必ずRed Hat添付のものを使うように。おっと,libxmlは2.4.x以降ってことで」。

 ところが相手の反応はいま一つ。動作環境を限定しているのが気にいらないらしい。「Linuxで動く」と言えば,Red HatだろうがDebianだろうがTurbolinuxだろうが,どのバージョンであっても,どんな構成であっても動作して欲しいらしいのだ。そんな夢みたいなことがあるわけがない。

 そもそも,コンポーネントを組み合わせてというからには,必ずコンポーネント間の依存関係が発生する。大抵のコンポーネントは,特定の環境を期待して動作するわけだから,コンポーネントで積み上げる層が厚くなればなるほど前提条件は増える。それを嫌っていては組み合わせはできない。ネジがネジ穴にうまく入るのだって,工業規格という前提条件があってのことなのに,理解していただけないようで,はなはだ不本意である。――いや,もしかすると私が不器用すぎるだけなのかもしれない。

 あるプロジェクトのとあるインターネット・サービスで,メール・サーバーにqmailを使うことが決まったらしい。私は,ある事情によりqmailを嫌っているのだが,qmailを選んだエンジニアが面倒をみるならよいだろうと思って,あえて意見をしなかった。システムの本稼働が始まって1カ月ぐらいたった頃だろうか。メールのスプールがいっぱいになって困っているという連絡を受けた。

 私は「バウンス(いわゆるエラーメール)のせいじゃないですか?」などと対応しつつ深入りを避けていたのだが,そのうち担当者はなんとログとスプールを圧縮した数メガバイトのメールを送りつけてきた。その程度のトラブル・シューティングもできなくて,どうしてqmailを採用したのか。私なんかには考えられないことだが,「高速でセキュリティ面でも安心。みんな使っているし,設定も簡単」というようなキャッチ・フレーズにでもつられてしまったのだろうか。――いや,もしかすると私が臆病すぎるだけなのかもしれない。

 どうしてみんなそんなに「簡単であること」にこだわるのだろう。もちろんある程度,見かけを簡単にすることはできる。しかし残念ながら,それを簡単な仕掛けで実現できるとは限らない。簡単にするために,多大な労力と工夫,そして費用が必要なのだが,どうも世間の認識は違うようだ。私は声を大にして言いたい。「簡単ではありません!」。――いや,もしかすると単に私がひねくれものなだけなのかもしれないが。