オープンソースという商売

3月 16th, 2009 by tsuyoshi Leave a reply »

一応、私はソフトウェア開発企業に所属していて、事業のひとつをまかされて展開している。が、正直やっている商売に継続性がある気がしない。モバイルに焦点をおいた、なおかつキャリアや通信機器ベンダー向けではない開発企業であるのは、最終消費者からのマネタイズラインが現状1兆円程度とそれほど太くなく、またそのほとんどがコンテンツ販売であることから開発ニーズというモノもあんまり、浮かんでこないのだ。

とはいえ世の中不景気だし、このまま何にもしなけりゃジリ貧だし、ということでオープンソースを使って技術資産を底上げした上で携帯関連の開発で食う、という図柄の勉強を始めている。

このブログやC-NETでもたびたび同じことに触れているが「開発」という作業そのものに対価を請求できた時代はとっくの昔に終了している。一定の瞬間から、開発は製品のサブセットになり、どちらかといえば「機能実装」というより細分化された作業になっている。例えばSAPのカスタマイズであるとか、ExchangeサーバーをCRMスキームに組み込んでいくであるとか、ATM機器と広域イーサの接続をチューニングするとか。
こうした開発作業の基盤になっているテクノロジーが国内製のものであることは非常に少なくて、役所の人が憂えてしまうのももっともなのである。こうした部分での国際競争力は実際問題、ない。さらにいえば、製品もほとんど無い。

オープンソースソフトウェアは、国内製でもないが海外製でもない。”コミュニティ”という得体の知れない主体/基本的に何らかの”善意”で成り立っていて、存続の基盤を利益においていない。多くの場合、GPLライセンスであり開発の成果を知的所有権として囲い込んでしまうことが非常にやりにくい。やってもいいんだけど、ケツの穴の小さい奴ということで”コミュニティ”から嫌われたりする。

オープンソースは「既存製品の代用」、「安価」という語り口で紹介されることが多いが、実際にはそんなに安くもない。実際の業務に利用しようと思ったら、

  • 英語ができて
  • 人の書いたコードを読むのが苦にならなくて
  • 「今回の案件にはDB構造が合わないからスクラッチしましょう」とか言い出さなくて
  • それでもなんとか使えるものをひねり出してくれて
  • 壊れちゃったときにはすぐに直してくれて
  • セキュリティ問題があったらすぐに対応してくれる

そういうエンジニアがいなきゃいけないが、この人は「高い」。能力も、モチベーションも高いからね。
じゃぁ、外注先にそういう人がいてくれればコストがヘッジされるじゃん、という話になるけれども基本的なデマンドは上に掲げた条件と変わらないので、リスクのありかが変わってはいるけれどコストも、そしてリスクもヘッジされてはいない。その辺を考えていくと以前Microsoftが盛んに主張していたように、かえって高くつく。まず間違いなく。

じゃぁそれが致命的な問題なのかというと、そんなことは全然ない。

無責任に聞こえるかもしれないが、きちんと運用を完結させようとするから高くつくのだ。
壊れたときや、セキュリティ問題が起こったときにどうする、ということさえ決めておけば、オープンソースはその多様性と世界中での利用者が多いが故に − 安いから、じゃないぜ。繰り返すけど。 − 非常に魅力的な選択肢だ。CMSやECショップシステムなどのオープンソースを利用して行く際にも、既存のノウハウが世界中にある。”実装”作業であればコピペでこなせるといってもいいだろう。中小企業や個人商店などでキックスタートさせる際には、実装期間の短さとコストの低さは魅力だろう。

が、エンジニアリングコストは総体的には高額になるし、データ入力や編集、顧客対応などの運用そのもののコストは下がらない。中小企業や個人商店などであるならば、これらのコストは丸々追加コストだ。
SEM/SEOやメールマーケティングなどのリアル店舗とは違うマーケティング手法を展開しなければならないことも考えると、もう現実性がどんどん無くなる。「ティッシュ配ったほうが即効性もあるし…」となるのは非常に当たり前の論理である。

SMEとSOHO向けには、おそらくは以下2つのパッケージが現実的なビジネスプランだ。

  1. マーケティング、データ入力、編集などをパッケージにした運用のアウトソースビジネス
  2. インフラレベルから顧客対応までビジネスストリームを全てカバーしたコンサルビジネス。

「インフラレベルから顧客対応までをパッケージする」ってのは受けるほうがリスキーなので、なし。
実装をキックアップのタイミングとして、マネタイズは事業運用の一部を請け負っていくことで行うわけだ。

Enterpriseへの提案については、上に述べたコスト構造を飲み込めるだけのエコノミーを抱えているのならば、これまでどおりでよい。事業の細分化が進んで行って、オープンソースが持つ実装の多様性が重要になってきたら話が変わるだろうけれど。

DBMSをMySQLに、なんていう話をしてるんじゃないからね。間違えないように。

Advertisement

コメントをどうぞ