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

　私たちが顧客に納めるソフトウエアなどの成果物に対しては，瑕疵担保責任というものが課せられている。そのため，あらかじめ合意した期間内に不具合などが見られた場合には無償で対応しなくてはならない。

　一般的には，検出されるソフトウエアの不具合というものは時間が経つにつれて少なくなっていくはずであり，それによるリスクも減っていくと考えられている。こうして安定期に入ったソフトウエアを「枯れている」と表現するのはご存知の通りだ。途中で紆余曲折があったとしても，ここまで来ればまずひと安心。そのままの状態で使っていれば，プログラム自体は5年でも10年でも変わらずに動き続ける。

　ところが，これでお終いと思ったら大間違いである。あとから仕様の追加や変更の作業依頼が来ることが往々にしてある。依頼の主旨は，大抵が顧客側の業務変更に合わせるためであったり，新しい企画をサービス展開するためであったりする。納品してまだ日が浅いうちならよいのだが，時間が経ってからの依頼は正直なところ，かなりつらいものがある。同じ仕事をしている人ならわかっていただけると思うが，1～2カ月前に組んだプログラムの詳細など覚えているわけがない。半年以上経っていたら，他人が書いたプログラムに手を入れるのと変わらない。

　唯一の救いといえば，コーディングのスタイルが自分にとてもよく似ている点であろうか。自分で書いたコードなのに，あえて「似ている」と表現するのは，時が経つにつれてスタイルが変わっていくからである。いや，コーディングのスタイルが現在と異なる程度ならまだ我慢ができる。耐えられないのは，自分にとって古いスタイルの設計で組んだプログラムを相手にするときである。

　例えば，私がPHPを習い立てのころに開発したWebのユーザー・インタフェースは，プログラムの致命的なエラーがあると真っ白な画面を表示するだけ，というお粗末な作りをしていた。このときはエラー処理にあまり時間をかけられず，予測したエラーに対してはあらかじめ用意しておいたエラーメッセージを表示するようにしていたので，実用上は問題がなかった。しかし，自分でプログラムに手を加えている途中で予想外のエラーが発生した場合は，トレース用のコードをあちこちに埋め込んで場所を特定する必要があった。

　現在ではエラー処理のスタイルを変えたのと，PHPのバージョンが上がってデバッグ関連の機能が強化されたことで，何かがあっても大抵は意味のある情報が画面に表示されるし，エラーログに記録が残るようにもなっている。長い間同じようにプログラムを作っているように見えて，実は少しずつ進歩しているのである。これが，2～3年も経つと，大きな違いになってくる。そして，古いスタイル，あるいは一度捨てたスタイルで開発したプログラムなど，見るのも嫌になってしまうのだ。

　わがままと言われるかもしれないが，先のエラー処理の例でわかるように，現在のスタイルというのは何らかの改良を経てたどり着いたものであるから，古いスタイルの設計というのは，少なくとも自分にとっては，現在よりも作業効率が悪かったり，パフォーマンスや保守性の面で劣っていたりする。それを修正するとか，ましてや機能を追加するというのは，かなりストレスの溜まる作業だ。仕事をいただけるのはありがたいことだが，できることなら避けたいと思うのである。

　しかし，こういうメンタル的な部分を顧客に理解してもらうのは，なかなか難しい。ハードウエアなら磨耗や変質などによって寿命があることは歴然としているし，民生品なら補修部品がなくなれば買い替えざるを得ない。しかし，ソフトウエアは同じ環境にそのまま置いておけば，いつまでも同じように動き続ける。開発当時よりもエンジニアのスキルが上がり，システム・ソフトウエアの仕様も改善されたので，以前作ったソフトウエアの手直しは開発コストがかかります，という話はとても受け入れてもらえないだろう。

　それならこういう考え方はどうだろう。ソフトウエアも時間が経つにつれて，ハードウエアと同様，劣化するとみなすのだ。技術者のレベルが上がったり，システム・ソフトウエアの仕様が改善されたり，あるいは技術者が開発当時の事情を忘れたりして，ソフトウエアは陳腐化していく。すなわち劣化していくという理屈だ。

　世間一般でこのような考え方が通用するとは思えないかもしれないが，せめて開発を手がけている技術者や営業担当者は「ソフトウエアは劣化していくものだ」という意識を持って顧客と交渉してみたらどうだろう。そうすれば，過去のシステムであることによって生じるストレスに見合う条件で仕事ができるのではないだろうか。納品後に一定の時期を過ぎたら経年劣化によるリプレース，すなわち作り直しを強く勧めて新規案件に導くという営業方針も立てやすいのではないか，と思うのである。

　こんなことをぼんやり考えていたら，昔手がけたシステムの移管作業の依頼が来た。なんと3～4年前に納品した案件である。なんでも，ハードディスクがIDEからSATAに世代替わりしたことで，データセンターの補修用ハードディスクの在庫がなくなるとか。そればかりでなく，OSがすでに終息製品になっているため最新のセキュリティ・パッチが提供されず，セキュリティ面でも問題があるということで，急いでサーバーの乗り換えが必要になったらしい。

　私からすれば「すでに経年劣化してリプレース対象」のシステムだが，顧客の事情を考えれば断るわけにもいかないし，リニューアルというのも無理な話だ。今動いているものをそのまま移管するだけだから，あまり法外な費用をいただくわけにもいかない。ちょうど手が空きかけていたところだし，ちょっとした小遣い稼ぎにもなることだから，まあいいか。「劣化するソフトウエア」のアイディアは，もう少し暖めてから具体化することにしよう。