第3回 デキる男のオープンソース理解【ビジネス編】：新入学生／新社会人応援企画第2弾（3/3 ページ）

[ITmedia]

OSSを利用したサービス提供

　OSSを利用してビジネスを展開する場合のポイントはどこだろうか。成功している、もしくは失敗している企業の特徴を見つつ、注意点も考えていこう。

OSSの開発に企業内リソースを割く

　主要な大手ベンダーは何らかの形で、OSSプロジェクトに開発者を参加させている。その開発者は自在の直接の仕事をしているわけではないので会社にとっての成果はすぐに出ない。しかし、OSSの共同開発では実績が評価され、幾ら理屈をこねても、手を動かし、結果を出している人にはおよばない。その開発者が普段からプロジェクトで結果（貢献）を残していれば、プロジェクトの中で主導的な立場となり、自社の顧客ニーズを取り込んで、直接ビジネスに役立てやすいものになる。また、何らかの緊急対処のときに迅速な対応が取れるようになる。

　さらには、すでにプロジェクトで主導的な立場の開発者を雇い入れ、そのOSS利用を効率化することも行われている。

ライセンスを理解する

　OSSベースにしたシステムを販売する場合、利用するOSSのライセンスを把握することは重要である。GPLのソフトウェアを利用した場合、改変したら顧客に対してソースの開示準備をしておく必要がある。BSDライセンスであれば、ソース開示の準備は必要ないので比較的取り扱いやすい（表1）。

　一方で、BSDライセンスであると、他社が流用し、自社開発製品のように販売したとしても、そのことにとやかくいうのは難しい。GPLであれば、ソースを公開する義務があり、その過程で自社ならびに他社の顧客に対して自社の優位性を語ることができる。ソースを公開しない場合もあり得るが、その場合、何らかの証拠がつかめれば、悪意のあるライセンス違反として、自社の優位性を保てる。

ライセンス違反は思わぬところから

　この記事を読まれている方であれば、ライセンス違反を起こしてビジネスを展開してしまうといったことはないだろう。問題は顧客対応の人員がきちんと把握しているかだ。例えば、GPLのソフトウェアを利用し、ソースも公開する予定であったとしても、その旨が社内で周知されていなかったり、顧客対応の人員がOSSに対する理解がなかったりする状態で、顧客から問い合わせがあったとする。その際、旧来の商慣習から「ソースを公開する義務なんてない」などと対応してしまうと、コミュニティーからの反発や自社イメージのダウンを招く。下手をするとネット上でさらされてしまう。意図しない方向に進む恐れがあるので、注意されたい。

自社プロダクトを公開する

　OSSの利用で、素直にソース公開を前提したビジネスを構築するのはいかがだろうか？　はじめから公開すると決めていれば、複雑なことを考える必要も減り、メリットが大きい場合はあるだろう。いまの流れでいけば、OSS化はさらに加速する。他社にリードされる前に対応していく方がメリットが大きい。検討しているうちに競合他社からOSSとして公開されるようだと、よほどの優位性がなければ、かなり不利な状況になる。

　OSSとして公開するメリットを挙げると次のようになる。

• 告知効果
• 需要の収集
• 需要がある顧客の組織（コミュニティー）化

　何らかの商品を販売する場合、まずはその商品の存在を知ってもらわなければならない。OSSとすれば、それを利用したい人が少なからず集まり、広報費用の削減につながる。ものによってはメディアがこぞって取り上げもする。需要のあるユーザーからの意見を集めれば、需要動向が把握でき、またそれを反映することで他社との優位性を持てる。

特許に注意

　自社プロダクトを公開する際、法的なリスクとして著作権と特許権の侵害がある。前述のようにOSSか商用ソフトウェアかでの根本的な違いはない。まずは侵害がないように特許の調査、著作権の侵害がないよう独自開発をきちんと行う。一般ソフトウェア開発で行われている行為としては、著作権が完全にクリアなっていることを証明できるよう、開発者を外部から隔離した状態で0から開発にあたらせるという方法もある。そこまではよほどの案件でなければ現実的ではないが、ちょっとしたルーチンでもコピー＆ペーストしないように気をつけるといった、モラルの向上など教育は必要だ。

　特許権侵害訴訟に対する防御策としては、新規技術があった場合は、あらかじめ特許出願をしておく。それなりに費用が掛かることなので、非営利団体や企業でもそのプロダクトに資金を投入できない場合は、その新技術をあらかじめ学会やLinux Conferenceなどに論文として応募しておこう。その技術の実装／アイデアの実施時期を明確に残しておけば、いざ係争となったときの証拠になる。

制作途中でもなるべくリリース

　企業からの貢献、またリリースの際、従来のリリースエンジリアリングのような形で、完全に完成しきってから公開される傾向がある。きちんとした形で外部に出すことは、万が一不具合があったときにイメージを損ねないため、重要な要素である。しかし、あまりにも唐突であると、開発コミュニティーはその修正がうまく評価できず、評価に時間が掛かったり、無視されてしまうこともある。

　また自社プロダクトに関しても、コードクリーンは必要であるが、リリースが滞るとOSSであることのメリットであるフィードバックが得られない。OSSで公開する指針が決まっているのであれば、できるだけ早い段階で材料を用意し、ユーザーからのフィードバックが受けられる体制で開発を進めていった方が効率が良い。

著作者であればライセンスの変更は可能

　一度ライセンスを定め公開してしまうとライセンスが変更しにくいものであるが、かといってできないわけではない。GPLで公開していて業務の方針変更からBSDライセンスに変更したいとする。そのソフトウェアの著作者全員の同意があれば、ライセンスの変更は問題ない。すでに公開されているものに関してはそのままであるが、バージョンをアップするなどして変更すると良いだろう。特にまだ外部開発者からの寄贈コードや修正が加わっておらず、自社ですべての著作権を持っているのであれば、容易である。外部開発者のコードがマージされているのであれば、すべての開発者に確認する必要がある。

学習費用／敷居の低減

　OSSのメリットとして学習に対する敷居の低さがある。教材となるソフトウェアを用意するのにコストがかからない。また、最高のドキュメントであるソースコードが手に入り、先人の知恵を習得しやすい。

　これはシステムのテスト導入の際にも言える。OSSであれば、気軽に導入でき、テストしてみてダメならば別のものを選べば良い。

　いまはLinuxの急激な普及によって、特に国内ではOSSを扱える技術者が足りない状況だが、このように学習／テストが容易なことで、今後OSS技術者は増えていくだろう。

　またOSSはグローバルに普及し、特にIT化が遅れた地域では、OSSへの移行ではなく、新規導入となっている。IT化が進んでいる地域よりも、より急速にOSSが普及しており、人材はどんどん増えてきている。グローバルなソフトウェアプールを支える技術者がどんどん増え、それを生かすためには、コミュニケーション能力、つまり英語力がよりいっそう要求されるだろう。

オープンソースが浸透した先には

　ソフトウェア開発において、オープンソースは成功し、その開発体制、協調体制は浸透しつつある。一歩引いて抽象的にとらえると、そういったオープンソース文化に慣れた企業の先には、ソフトウェアに限らない、企業の垣根を越えたビジネス開発のオープンソース化が見えてくる。モチベーションの高い人の生産性が優れ、また適材適所がうまく働くことによって、業務の効率化は加速する。これまでも協調を目的とした業界団体や組合といった形態は存在しているが、それより踏み込んだグローバルな業務プールを作成し、理解し、活用できていくことが、今後の鍵になるだろう。

本記事は、オープンソースマガジン2005年12月号「オープンソースで行こう！」を再構成したものです。