連載
» 2007年03月06日 08時00分 公開

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

オープンソースソフトウェア(以下、OSS)を業務で利用する場合、またOSSを使ってビジネスを展開する場合、どのような点がポイントになるだろうか。具体的な利点と問題点をピックアップし、事例を合わせて整理していこう。

[ITmedia]

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 図1 一般的な開発とオープンソースの開発

原因の特定

 ソフトウェアにバグはつきものであり、一度完成ということになっても、通常はメンテナンスが必要である。そして何らかの不具合があった場合、ソースがあるのとないのとでは現場での対応がまったく異なる。

 ソースがない場合、ユーザーもしくは原因を調査する開発者は、動作パターンを洗い出し、総当たりの検証から、問題が起きないケースを見つけ出す、もしくは問題のパターンを見つけ出し、状況回避的な対策を行うことになる。そしてその状況をソフトウェアベンダーに報告し、修正版が出てくるまで待っていなければならない。

 一方、ソースがあれば、一定のスキルは必要となるが、問題の原因を特定しやすい。さらには、現場での問題修正も可能となる。緊急性が要求される場面で対応手段のあるということは、決定的な優位点である。

開発の継続性

 ソフトウェアが特定のベンダーから提供されていた場合、そのベンダーの経営がうまくいっているうちは良いが、倒産でもされたものなら、そのソフトウェアは更新できなくなってしまう。セキュリティ対策やバグフィックス、ハードウェア対応などで修正が必要となったとしても、危険な状態のまま使いつづけるか、その業務を立て直すしかない。

 OSSであれば、開発プロジェクトが解散してしまったとしても、手段は残される。その後の改修は自ら行えるし、別の誰かがプロジェクトを引き継ぐこともある。また、そのOSSをサポートする別のベンダーが存在する可能性があり、もしあれば、サポートを依頼してその後のメンテナンスを任せられる。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

マーケット解説

- PR -