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

　最近，仕事の面で閉塞感を覚えることが多い。というと難しく聞こえてかっこいいが，ようするにいま一つうまくいかないのだ。いったいどこに原因があるのだろうと考えてみる。以前にも書いたと思うが，人間歳を取ると人様に忠告していただく機会が減ってくる。一人で部屋にこもってひたすらパソコンを相手にしているわけだから，知らず知らずのうちに一人よがりになっている可能性がきわめて高い。

　こういう状況になってみると，会社などで上司に「おまえなぁ，そういうところが悪いんだよ」とストレートに叱咤激励されている人がうらやましく感じる。その結果として特定の組織に染まっていくだけじゃないか，という見方もあるが，肯定的に見れば，このようなやり取りを通して組織に所属してやっていくための必要条件を身に付けていくわけである。どうしても合わないと思えば自ら転身をはかる機会にもなるだろう。もちろんこんなに単純明快なケースばかりではないということは知っているつもりだ。おそらく，自分が行き詰まっているので，隣の芝生が青く見えているのだろう。

　しかし，そんなことを考えていても現状は打破できないので，身の回りから原因を探っていくことにした。簡単のために内部要因と外部要因の二つに分けて考えることにして，まずは自分側の問題から着手する。といっても，一人で内省ばかりしていると自分のマイナス点ばかり目についてへこんでしまい，日常生活すら手につかなくなってしまうので，仕事で関係している人からもアドバイスをもらうようにしてみよう。もちろん，何もないのにいきなり「私って何か悪いところがあるでしょうか？」などと切り出しても相手は面食らうだけだ。それでなくても皆忙しいのだから。

　しかし，心労のかいがあってと言うべきだろうか。驚くべき事実が判明した。どうやら私はフットワークが軽くないらしいのだ。あっさりと言葉にしてしまうと「ふ～ん」で終わってしまうかもしれないが，私にとっては思わずのけぞりたくなるほどの衝撃だった。改めて考えてみると確かに自覚はある。まさにそういう教育を受けてそういう仕事のスタイルでやってきたのだから根が深い。

　私がコンピュータ技術に初めて触れたのは，小学校高学年から中学生に入るころだったと思う。まだパソコンなどというものはなくて，プログラミングで遊ぶとすればメインフレームかミニコンしかなかった。富士通のSEに「このミニコンの磁気ドラムはどのぐらいの容量があるのですか？」と聞いたら，胸を張って「64Kワード」という答えが返ってきた，そんな時代である。

　そのころ業界では，それまでのやり方を反省する風潮が強く，いわゆる汚いプログラムを書くのは悪だという考え方がはびこっていたようだ。構造化プログラミングという手法が普及しつつあり，先進的な人はすでにオブジェクト指向に頭が行っていた。MVC（Model View Controller）などという言葉が出てきたのもこのころだろうか。

　プログラム設計とは，現実世界のモデルをシステム内部に構築することであり，ユーザー・インタフェースというのは，現実世界とシステムの内部表現のマッピングを行う層として位置付けるパラダイムである。工数と費用を無制限に費やすのを抑えるため，システムの仕様を上流工程でコントロールするのが良しとされた。下流で発生した変更や不整合は，必要なだけ上流にフィードバックすることで全体の修正をはかる。

　今考えれば，この方法論は確実に違いないが確かに重い。いや，過去形で書いて構わないのだろうか。不勉強ながらも私がざっと把握している限り，いわゆる方法論と呼ばれるものは，その後時代を経ていろいろな展開はあるものの，基本的にスタンスが変わっていないように思える。

　しかし，最近私が関係する機会が増えている短期決戦型プロジェクトや，ライフサイクルがせいぜい1～2年程度のいわゆる使い捨てシステムの開発プロジェクトでは，いささか事情が違うようだ。専門家と素人が入り乱れて企画からシステム開発までを行うこういう現場では，設計モデルや方法論の話をすると，まるで利用者不在で物を言っているように見られかねない。極論すれば，汚いコードで後で保守に苦労しようとも，先に動いたものが勝ちなのである。

　他者に先行することでビジネス・チャンスをつかみ，収益が上がってシステムを作り直すための資金が確保できたなら，そのときに改めて考えればよい。収益が上がらなければ，そのシステムは適当なところで見切って捨ててしまえばよい。システムを作るための方法論より，生き抜くための戦略のほうが大切ということだ。

　システムは目的ではなく手段なのだからこの考え方はありだと思う。しかし，こうした現実においてソフトウエア開発は，1日なんぼの日銭商売と変わりない。いわゆる設計方法論などと呼ばれるものが，このような状況でアプローチできる局面は限定されているのだ。

　20年以上前，ある人から「現実をそっくりそのまま受け止めて体系化するのは不可能に近い。だから，体系化しやすいところから着手していくんだ。体系化できない部分は，その方法論にとっては対象外ということだ」と聞いた。これを聞いた当時，混沌としている部分もいずれは体系化されてきれいになっていくのだと考えた。しかし，それはあまりに楽観的だった。そればかりか，現在の私は，数ある方法論が「想定の範囲外」にしている領域のどまん中に身を置いているじゃないか。

　今の顧客にとって，私のスタイルは「重厚長大」すぎるのかもしれない。昔を知っている人なら，時代遅れと言うだろうか。しかし，30年近くにわたってほぼ同じスタイルでシステムを設計し，プログラムを書いてきたわけだから，方向転換は容易なことではない。正直なところ，現時点でまだ有効な解決策は見つかっていない。