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

　前回は「使えそうなライブラリやツールが社内にあるから」といった理由でパッケージ・ビジネスを始めても，パッケージを店頭に並べておくだけでは決して儲からないということをお話しした。

　それなら，というわけで企業への大量導入を目論んでみる。ところがこれがまた大変なのだ。大量導入するからには，顧客側の担当者に「担いで」もらう必要がある。ソフトウエアに致命的な不具合でもあった日には，その担当者の面目はまるつぶれだ。そのため担当者はたいていの場合，一般消費者よりもはるかに厳しい注文をつけてくる。場合によっては，専任の営業担当を置いたり，些細な不具合修正の繰り返しに応じるために技術者を酷使するはめになる。「あらかじめ体制をしっかりしておけば」と言うかもしれないが，売る側からしてみれば，顧客がはっきりしていない時点で「しっかりした体制」を抱えるのは先行投資になってしまう。

　しかも，いったん売ってしまえば，アップグレードをしたり，サポート契約がない限り収入に結びつかない。継続的にアップグレードできるかどうかは企画と開発の腕，サポート契約を交わせるかどうかは営業の腕である。受託開発であれば「瑕疵（かし）担保期間」（隠れた欠陥が販売後に発覚したとき責任を負わなくてはならない期間）が限られているからまだ救われるのだが，パッケージ・ソフトは相手が使い続けている限りお付き合いしなくてはならないだろう。そのためのコストを販売価格に転嫁すると，驚くほど高額になってしまう。

　別の道として，ハードウエア・メーカーとのタイアップがある。パソコンを購入したことがある人なら，新品のパソコンにいろいろなソフトがバンドル（同梱）されているのをご存じだろう。ああやって配布してもらうのである。この場合，店頭販売のような凝ったパッケージングは必要ないし，企業への大量導入のような苦労もなさそうだ。一般に，ハードの生産量に合わせて売り上げがあがるので結構おいしそうに思える。

　ただしハード・メーカーの数は限られているので，パイはそれほど大きくない。バンドル・ソフトに選定してもらうには，同業他社との激しい競争に勝ち抜かなくてはならない。その結果，定価よりかなり値切られるのは当然である。開発担当者は，「なんとかライト」といったバンドル専用版を作ったり，あるいはハード・メーカー固有の事情に合わせた改変をする必要があるかもしれない。そのための経費がかかり過ぎるようだと，やはり利益はあがらない。

　さて，こうやっていろいろ展開していると，顧客から「カスタマイズ案件」があがってくることがある。「費用は出すのでこんな機能を付けてほしい」とか「うちの業務に合うように改変してほしい」といったものである。これはビジネス・チャンスとばかりに営業が飛んでいって要件を聞き，開発と相談して見積もりを出す。ところが，カスタマイズを出すことに慣れていない顧客は金額を見てびっくりする。「なぜ数万円のソフトをちょっと改変するのに数百万円もかかるの？」というわけである。世の中すべてのソフトが改変しやすいように作ってあるわけではない。特定業務向けとなれば，仕様決めをはじめとする，普通の受託開発と同じ工程が必要になるから，それなりに費用がかかるのだ。

　カスタマイズを求めてくる顧客は大抵の場合は企業である。したがって顧客は，大量導入と引き換えにカスタマイズ費用を抑えようという戦略に出てくる。ここから先は営業の腕次第ということになる。開発側からすると，商品とは別のバリアント（改変版）ができるわけだから，ソースコードの管理をしっかりしておかないと後で大変なことになる。元の商品をアップグレードしたときは，バリアントも合わせてアップグレードする必要があるからだ。そうしないとこの顧客から継続的に売り上げを得ることができない。

　ついでにもう一つ。バリアントをパッケージと同じ扱いで売ってしまうと後で困るかもしれない。なぜなら，ひとかたまりのシステムとして動いているのに「カスタマイズした部分だけ瑕疵担保期間付き」という契約にするのは難しいからだ。カスタマイズした部分に特定した不具合であっても，商品が使われ続ける限りサポートをするはめになるかもしれない。それならいっそのこと，最初から受託開発として請けたほうが納まりがよさそうだ。

　あれ？ ちょっと待てよ。そもそも「個別案件・受託開発」を嫌ってパッケージ・ビジネスに手を出したのではなかっただろうか。ここまで来ると元の道に逆戻りではないか。

　そうなのだ。ここまでパッケージ・ビジネスの展開パターンをいくつか書いてきたが，実は一番おいしいのは最後のカスタマイズにからむ部分なのである。つまり，前号に書いたように「パッケージ・ビジネスをするのは会社の認知度を高めるためでいわば広告費の一部。実際はパッケージをベースに，受託案件として利益を出す」というのが一つの道なのではないかと思う。もちろん，最初からパッケージ・ビジネスなどに手を出さずに，社内のソフト資産を活用して受託開発の内部コストを下げることに注力するのも，選択として「あり」である。

　もっともここで前提にしているのは，技術主導のパッケージ・ビジネスである。企画やサービスのアイデアが先にある場合は事情が変わってくる。また，ここに挙げた以外の展開パターンも存在するし，ここに挙げたパターンでも「私ならもっとうまくやれる」という人もいるだろう。しかし，「使えそうなライブラリやツールが社内にあるから」とか「パッケージ販売ならコピーして配ればOK」などと簡単に考えないほうが良いと思う。リスクを負うのは投資した本人にほかならないのだから。