レベル: 初級 ITmedia, Writer
2007年 5月 11日 オープンソースソフトウェア（以下、OSS）を業務で利用する場合、またOSSを使ってビジネスを展開する場合、どのような点がポイントになるでしょうか。具体的な利点と問題点をピックアップし、事例を合わせて整理していきましょう。
OSSが普及しているいまの環境
OSSといって、多くの人が思い浮かべるのが「無料」で使えるソフトウェアということでしょう。どの企業もユーザーも、できるだけコストは抑えたいので、無料で使えるというのは非常に分かりやすいメリットです。これがOSS普及の1つの要因であったことは間違いありません。
安かろう悪かろうではない
得体の知れない人たちが作った、無料で配っているソフトウェアは「品質が悪く、業務に使えないのではないか？」といった疑問を持たれる方もいるかもしれません。実際、海千山千であり、優れたものもあれば、作りかけのようなものもあります。ユーザーにはそれを見極める目が必要となります。
とはいうものの、実際のところOSSが普及／浸透したいまとなっては、品質の高いソフトウェアが揃い、ユーザーに過度の鑑定スキルは要求されません。OSやWebサーバなどの、需要が多くユーザーが多いものほど、利用され、改良され、好循環の中でソフトウェアの品質が急速に高まっています。特にLinuxはその典型例です。
コンピュータの普及と目的意識の向上
コンピュータがまだそれほど普及していなかった時代、多くのユーザーにとって、「コンピュータを使えば何かいいことができそうだ」という好奇心の方が勝っていました。その可能性に、個人も企業も、費用対効果を無視した投資を行うことが多く、「100万円近くかけて結局役立ったのが、年賀状印刷や家計簿」だったり、システム構築に失敗した、いわゆる「動かないコンピュータ」さえも作りあげてきました。
未知の可能性を期待し、日々進化し続ける間は、その期待に対する付加価値が存在しましたが、コンピュータが多くの人に利用されるようになったいまは、その利用形態は定型化しつつあります。例えば、利用目的が、Webブラウジング、メールのやり取り、Webサーバの運用などと明確となり、目的がはっきりしているところへは費用対効果が求められます。Webブラウジングを目的としたユーザーにとっては、Webブラウザがきちんと動けば良い。目的のクオリティが得られるまでは、より良いものを求めてソフトウェアに一定の対価があり続けますが、目的が満たされれば、低価格化を求め、最後は無料が当たり前という感覚になっていきまます。
コンピュータビジネスはサービスにシフト
コンピュータやソフトウェアが可能性から目的を実現するための道具へと変化した状況においては、モノだけではなかなか価値は作り出せません。ユーザーの目的を効率良く実現するための、サービスの提供が重要になります。コンピュータ関連会社はサービス提供会社に変化しつつあるのです。
そして仕様が明確化した機能の開発には、コスト削減が要求され、1つの組織だけで抱えられるものではなくなってきています。開発費をできるだけ抑えるためには、共通基盤は他社との共同開発、アウトソースといった選択が必要になっています。
そういった状況下にはOSSの開発スタイルはよく適合します。OSはまさに典型的な共通部分であり、さらに旧来から使われ続けているデータベース、WebサーバといったジャンルでもOSSの利用が活発です。
オープンソースの具体的なメリット
このような背景があるにしろ、なぜここまでOSSがもてはやされ、ビジネス利用に浸透してきているのでしょうか。ソフトウェア開発をオープンにするメリットは何でしょうか。ソフトウェアの開発や利用において、OSSのメリットをもう少し具体的に見ていきましょう。
ニーズとともにある
1つはユーザーの目的に適合した開発とそのスピードです。ユーザーの第一の目的は、ライセンス形態でもなく、開発体制でもなく、ソフトウェアが実現する機能です。ユーザーのニーズに素早く応えてくれるものが、いかに安く手に入れられるか、です。
OSSの開発スタイルは、常にユーザーとともにあります（図1）。ユーザーはいつでもOSSを入手でき、いつでも要望が伝えられます。ユーザー兼開発者であれば、欲しい機能を自ら実装することだってできます。真に需要のある機能は自然に追加／進化されやすいのも特徴です。
一方、企業、組織内で閉じた開発体制では、ユーザーのニーズをくむプロセスが別に発生してしまいます。また、ユーザーに提供してもフィードバックを得るためのコスト、時間が必要になります。
図1. 一般的な開発とオープンソースの開発
原因の特定
ソフトウェアにバグはつきものであり、一度完成ということになっても、通常はメンテナンスが必要になります。そして何らかの不具合があった場合、ソースがあるのとないのとでは現場での対応がまったく異なります。
ソースがない場合、ユーザーもしくは原因を調査する開発者は、動作パターンを洗い出し、総当たりの検証から、問題が起きないケースを見つけ出します、もしくは問題のパターンを見つけ出し、状況回避的な対策を行うことになります。そしてその状況をソフトウェアベンダーに報告し、修正版が出てくるまで待っていなければならないのです。
一方、ソースがあれば、一定のスキルは必要となりますが、問題の原因を特定しやすくなります。さらには、現場での問題修正も可能となります。緊急性が要求される場面で対応手段のあるということは、決定的な優位点です。
開発の継続性
ソフトウェアが特定のベンダーから提供されていた場合、そのベンダーの経営がうまくいっているうちは良いですが、倒産でもされたものなら、そのソフトウェアは更新できなくなってしまいます。セキュリティ対策やバグフィックス、ハードウェア対応などで修正が必要となったとしても、危険な状態のまま使いつづけるか、その業務を立て直すしかありません。
OSSであれば、開発プロジェクトが解散してしまったとしても、手段は残されます。その後の改修は自ら行えますし、別の誰かがプロジェクトを引き継ぐこともあります。また、そのOSSをサポートする別のベンダーが存在する可能性があり、もしあれば、サポートを依頼してその後のメンテナンスを任せられます。
ユーザーとしての利用
それではまず、利用者としてOSSを導入する際のポイントを整理していきましょう。
OSSを利用する場合、図2のような形態が考えられます。1つは配布元から入手し、単に使うケースです。この場合、ソフトウェアの入手から、導入、運用を自ら行うことになります。
図2 OSS利用にはさまざまな選択肢がある
すべての作業ができない場合は、システム構築を依頼するのと同じになります。Linuxディストリビュータに導入までをサポートしてもらう場合や、システム設計、構築まで行ってもらう場合もあるでしょう。どこまで面倒を見てもらうかによって費用は異なります。
より良いサポートを受けるためには、利用しているOSSに対して、そのベンダーが技術力があるか、つまりそのOSSにどのくらいかかわっているかが1つの目安になります。特にそのメーカーが開発に参加している場合、緊急の問題対策が必要になったときに、迅速な修正が期待できるでしょう。
何か問題があったときに自分が責任を取らなければいけないのか？
OSSはよく「自己責任」で利用するものと言われてきています。しかし、これはOSSに限った話ではなく、何らかのモノを導入する場合、導入者が責任を持つのは当たり前のことです。
わざわざこの言葉が出てきた背景には、一般の商習慣を当てはめ、「配布元は面倒を見るもの」と勘違いしている人が多かったためです。OSSは自由に入手／配布ができますが、開発者や開発プロジェクトは何ら責務を負いません。OSSをダウンロードなどで入手しただけなら、ユーザーは開発者に面倒を見てもらうだけの対価を支払っていませんし、サポートの申し込みを行っているわけでもありません。「マシンがハングしたから直してくれ。責任を取ってくれ」というのは見当違いというものです。
ちなみに、これは商用ソフトウェアでも同様です。商用ソフトウェアの場合も、サポートの適用範囲が明記されています。その範囲外の問題にはもちろん対応してもらえません。さらに言えば、商用ソフトウェアのライセンス文書には無保証をうたっているものさえあります。
もし何らかの保証なり、支援なりを求める必要がある場合は、求めるサポートサービスを提供しているベンダーに相談してください。
著作権／特許侵害のリスク
OSSはさままざまな人によって開発されているので、「著作／特許侵害の可能性が高い」と言われることがあります。しかし、侵害の可能性を評価するならば、ソフトウェアの開発形態はまったく関係ないものです。最近話題になったジャストシステム対松下電器産業の特許係争があったように、商用ソフトウェアでも同じリスクを持っています。リスクが高いか低いかは、個々の会社や開発プロジェクトに、無知もしくは悪意のある開発者がどのくらい存在したか、に関わります（図3）。
図3 侵害物が混入してしまうリスクは商用ソフトウェア、OSSともに同じ。発覚しやすいか否か、また、その後の対応で違いがある
ソフトウェア形態による差で違いが出るとすれば、OSSの場合は、
というものであり、ソースが公開されていない商用ソフトウェアは、
となります。
仮に侵害があれば、どちらも利用できなくなり、発覚しやすいか、し難いかの違いだけです。
むしろ、個人／企業情報の流失事件を見ても、部外者によるものはほとんどなく、組織内部の悪意によるものの方が圧倒的に多くあります。ソフトウェアにおいても、開発コスト削減や競争から、悪意と分類できる侵害事例がけっこうあります。結局は個々のメーカー／プロジェクトの信頼性にかかってくるといえるでしょう。
一方、オープンな場所では、多くの目にさらされている分、悪意の開発者が存在するのは難しいものです。ひいてはOSSの開発スタイルが開発者のモラル向上につながり、また一般に、競争意識や責任感による生産性の向上も期待できます。
OSSの場合対応が迅速な場合も
OSSで侵害がなかったかというと、Linuxカーネルなどで事例はあります。原因を分類すれば無知に属するもので、寄贈したコードが実はその会社の持ち物ではなく、ほかがライセンスをもっていたというものです。この場合、当然それまでのソースコードは利用できなくなりますが、問題が発覚した際、コミュニティー有志によってソースコードの書き替えなどの対策が速やかに行われています。また、ここで損害賠償が起こるリスクはありますが、発覚した時点で利用を停止していれば、善意の利用者であるユーザー側まで影響がおよぶことはまずないでしょう。
OSSを利用したサービス提供
OSSを利用してビジネスを展開する場合のポイントはどこでしょうか。成功している、もしくは失敗している企業の特徴を見つつ、注意点も考えていきましょう。
OSSの開発に企業内リソースを割く
主要な大手ベンダーは何らかの形で、OSSプロジェクトに開発者を参加させています。その開発者は自分や自社の直接の仕事をしているわけではないので、会社にとっての成果はすぐに出ません。しかし、OSSの共同開発では実績が評価され、幾ら理屈をこねても、手を動かし、結果を出している人にはおよばないものがあります。その開発者が普段からプロジェクトで結果（貢献）を残していれば、プロジェクトの中で主導的な立場となり、自社の顧客ニーズを取り込んで、直接ビジネスに役立てやすいものになります。また、何らかの緊急対処のときに迅速な対応が取れるようになります。
さらには、すでにプロジェクトで主導的な立場の開発者を雇い入れ、そのOSS利用を効率化することも行われています。
ライセンスを理解する
OSSベースにしたシステムを販売する場合、利用するOSSのライセンスを把握することは重要です。GPLのソフトウェアを利用した場合、改変したら顧客に対してソースの開示準備をしておく必要があります。BSDライセンスであれば、ソース開示の準備は必要ないので比較的取り扱いやすくなります（表1）。
表1. 主なライセンスの扱い
| 複製・再頒布可能 | 改変可能 | 改変部分のソース公開が必要 | 組み合わせた場合、ほかのコードのソース公開が必要 |
|---|
| GPL | ○ | ○ | ○ | ○ |
|---|
| MPL、LGPL | ○ | ○ | ○ | × |
|---|
| BSDL | ○ | ○ | × | × |
|---|
一方で、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が普及しており、人材はどんどん増えてきています。グローバルなソフトウェアプールを支える技術者がどんどん増え、それを生かすためには、コミュニケーション能力、つまり英語力がよりいっそう要求されることになるでしょう。
オープンソースが浸透した先には
ソフトウェア開発において、オープンソースは成功し、その開発体制、協調体制は浸透しつつあります。一歩引いて抽象的にとらえると、そういったオープンソース文化に慣れた企業の先には、ソフトウェアに限らない、企業の垣根を越えたビジネス開発のオープンソース化が見えてきます。モチベーションの高い技術者の生産性が優れ、また適材適所がうまく働くことによって、業務の効率化は加速していきます。これまでも協調を目的とした業界団体や組合といった形態は存在してますが、それより踏み込んだ、グローバルな業務プールを作成し、理解し、活用できていくことが、今後の鍵になるでしょう。
参考文献
著者について  | | | ITmedia |
記事の評価
| 
