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

 同業でない人に,私の仕事の内容を聞かれることがある。委託によってプログラム,あるいはシステムを作って納め,費用をいただくわけであるが,部外者にこれをそのまま説明しても,なかなかピンとこないようである。そこで,大工さんの仕事に例えることにしている。お客さんから「こんな家が欲しい」と言われて,家を作ってあげて,完成したら費用をもらうのと同じ,と言うと,なんとなくわかったような顔をしてもらえる。

 そして,たいていの場合,「それが完成するまでお金が入ってこないのか?」と質問される。例外はあるが,ほとんどの場合はそうだと答えると,「大変なお仕事ですね」と言われる。誰かに仕事を依頼してもらえない限り収入がないというのは,確かに大変なことに違いない。しかし,この仕事にはもっと大変な事情がある。

 その一つ目は「検収」である。完成したものを依頼者が確認して,OKが出なければ請求が出せないのである。これが結構,くせ者なのだ。当初の依頼通り作ったつもりでも,完成品を見て依頼者が違和感を覚えれば多少の手直しはせざるを得ない。これを抑えるために事前の打ち合わせ,つまり仕様決めがあるはず,というのが正論ではあるが,寸分の狂いもなく仕様を決めるというのは,とても手間がかかる。

 システムの動作を事細かに書いた仕様書があっても,それが妥当であるかどうかを判断するには,依頼者側にそれなりのスキルがいる。時間もないし,依頼者も素人同然,という状況では,取りあえず大事なところだけを決めておき,動くものが出来てから依頼者の意見を聞きつつ修正していくことになる。慣れた仕事であるから要点はわかっているし,慎重に進めはするものの,大きく外すことがないとは言えない。こういうときは相談をして,こちらがかぶるか,相手が我慢するか,または後日別途費用で修正ということになる。

 それでも,検収をしてもらえるならまだよい。怖いのは検収をしてくれない依頼者である。「動作を確認してください」とお願いしても,何を確認したらよいのかわからないのだ。画面があるものだったら,表示をざっと眺めただけでOKを出す。データ処理なら,手元の正常なデータを一回流してうまくいっただけでよしとする。これで問題がなければよいのだが,困るのはあとになって深刻なバグが発覚した場合である。

 建前から言えば,検収には責任分担の役割がある。検収を通したのは依頼者であるから,「開発者も間違ったけど,依頼者も検収で見つけられなかったよね」という意識が働くわけである。しかし,検収をしない依頼者の場合,下手をすると「開発者を信頼して検収を通したのに」ということになる。それでなくてもこちらはバグを入れた張本人で立場が悪いのに,これではかなわない。だからといって,ごく普通の人を相手に「きっちり検収をお願いします」と食い下がったところで始まるわけではない。悩むところである。

 さて,ようやく検収を終えて請求書を出し,売上が立ったとしてもまだ油断はできない。もう一つ「瑕疵(かし)担保責任期間」というのがあるのだ。納品後に問題があったことが発覚した場合,無償で修正することを約束する,いわば保証期間みたいなもので,半年から1年程度に設定されることが多いようだ。仕事を終えて,お金も受け取った後,何カ月かしてすっかりほとぼりが冷めたころに「バグが出たんですけど」と連絡があれば,無償で対処しなくてはならない。

 このとき,依頼者が問題点を指摘するのが建前なのだが,トラブルの切り分けには,高いスキルを必要とする。原因の切り分けから開発者に頼らざるを得ず,結果として開発者がヘルプデスクになってしまうことも少なくない。プログラムに瑕疵がなければよいとか,切り分けのマニュアルを用意しておけば,などという人もいるが,それは理想論にすぎない。瑕疵があることを前提に瑕疵担保責任期間があるわけだし,マニュアルで対応できるならシステム担当者は不要である。

 開発者としては,検収期間中は検収をあげてほしいがために,わずかな点でも言われれば手直しをする。検収完了後も,依頼者のスキル不足を知っているから,厚意のつもりでトラブル調査から手を差し伸べるわけだが,これが裏目に出ることもある。問い合わせさえすればいつまでも開発者が相談に乗ってくれると勘違いしてしまうのだ。こうなると,検収も瑕疵担保責任期間もあったものではない。

 もちろん,このようなお付き合いをすることで,機能追加などの追加案件をもらうこともあるし,保守契約を結んでもらえることもあるから,営業の一環と考えてもいいのかもしれない。しかし,もう少し冷静に考えてみよう。例えば仮に,新規開発の予算が4人月だったとして,初期開発費の1割を年間保守費として受け取ったとする。さらに保守の範囲を超える追加作業,例えば3人日程度の仕事を月に2~3本もらったとしよう。

 依頼者としては,検収とか瑕疵担保とかはよくわからないが,開発直後にあれだけ面倒を見てくれたのだから,ここまですればヘルプデスクぐらいはやってもらえて当然と思うに違いない。しかし,開発者からしてみれば,新規開発に比べて期間当たりの売上が大幅に下がっている。何かにつけて問い合わせが入り,細かい作業が入るから,他の仕事を入れるわけにもいかない。

 仮に人を雇っていれば,継続案件や納品後のフォローを単価の安い担当者に任せ,自分は新規案件をこなしていく,という戦略が可能になるが,私のように一人の場合はすべてをこなさなくてはならない。また,依頼者にあまり厳しいことを言うのもどうかと思ってしまう。

 メーカーや大手のSIerであれば,こういう問題はおそらくある程度クリアしているのだろうが,私の場合は業界に詳しくない顧客が相手である。今一つうまくいかないのは,一般的な工程の進め方にこだわっているからだろうか。もしかして,何かを根本的に変える必要があるのだろうか。独立して7年たち,やっとここまで考えることができるようになった,というのが正直なところである。まだ先は見えない。