経営者の「知りたい」を解決するプロフェッショナルによるウェブメディア

  • TOP
  • BROコラム
  • 凄腕コンサルタントが「OSS」を4つの軸から評価 ベネフィット・リスク・柔軟性編

オープンソースモデルのメリット ベネフィット・リスク・柔軟性編  ―IT投資施策決定における重要な4要素からOSSを評価する 後編

株式会社イージフ 
取締役副社長 CTO
石井 昭紀

前編では、IT投資施策を評価するための4要素である、コスト、ベネフィット、リスク、柔軟性のうち、コスト面からOSSの評価を行いました。

今回は、ベネフィット、リスク、柔軟性の3つの軸でOSSを評価していきたいと思います。

オープンソースモデルのベネフィット面での特徴

ここから先は改めて業務用アプリケーション製品市場に限定して議論を進めることを強調しておきたいと思います。(コスト効率の面でのメリットはオープンソースソフトウェア一般の議論に乗ることができましたが、それ以外の評価軸で同じ論法を当てはめても具体性がなく説得力がないと判断しました)

まず、ベネフィットの観点から。一般に、企業向けのオープンソースは、コストの議論で出て来たジェネリック薬品よろしく、すでに成功している従来型のパッケージソフトウェアの「オープンソース・オルタナティヴ」という形で企画されたものが多いと言えます。従って、先行製品が存在し、それらに比べると機能数などの面では見劣りすることも珍しくありません。成功しているオープンソース製品は、(当たり前ですが)製品のスタート時点では大きく見劣りしており、製品が軌道に乗るにつれて遜色なく、時として機能の面でも凌駕する製品に育っていくという段階を経ています。つまり、単純な機能数としては負けることも多々あるが、機能強化のスピードにおいては勝っていることが多い、ということで、これもジェネリック薬品の議論と地続きのお話になります。

ただ、業務用のアプリケーションに関して言えば、単純に後追いで効率良く実装を進められる、ということ以外に、オープンソースであるが故にサードパーティのエコシステムの構築がしやすく、パートナーやユーザの立場によって開発される新機能もカウントできる、という点もこの機能強化の競争優位の源泉になっているように思われます。パッケージを強化し新機能を実現するためには、開発キットを準備し、入念なトレーニングなどを通してエコシステムを育成するという重厚なプロセスを通さなくても、興味を持ってくれるエンジニアにソース毎公開し、開発方針を共有するだけで十分だということです。

もちろん、オープンソースベンダも、トレーニングや、開発キットやドキュメントの整備も行わないわけではありませんが、ソースの公開によるインパクトは大きく、大きな違いを生んでいます。寧ろ、ユーザやパートナーに対してソースを公開しないことの方が無用なコストを支払っている、というべきかもしれません。そして、その追加コストはシステム自体のベネフィットを増すことはなく、ベンダ側の立場を一方的かつ一時的に守る以上の役には立たないものなわけです。

オープンソース製品はそれ自体の効率の良さだけでなく、コミュニティの力を活用することで、新しい機能、新しい価値を従来型の製品よりも速く身につけることができます。もちろん、一社が独占的なポジションに立ち、無闇にソースなどの技術情報を拡散せず、ロードマップをコントロールすることにもメリットはあるでしょう。しかし、そうしたやり方はさらに多くの変化に富んだ企業に対して同一のパッケージ製品を提供していかなければならない現代のパッケージソフトウェアビジネスの世界において効率的であるとは思えません。結果として、従来型のソフトウェアを取り扱うベンダは、買収によって製品やそのファミリの価値を高めるという手法により強化のスピードを稼ぐことになります。買収によってラインナップに新たに加わったソフトウェアはそれほど簡単に他の製品とのシナジーを生み出せるわけではないので、どのくらいベンダ内部でその技術が定着したか、というのを冷静に判断する必要があります。

ベネフィットの観点からは、その求める価値を提供する機能を、それぞれの選定対象となったソフトウェア、ソリューションがすでに持っているか、持っていないとすれば追加にかかるコストとスピードはどの程度か、持っているとすればどのくらい定着しているものか(製品本体に含まれる、オープンソースでサードパーティが独自に作ったものである、買収したてで実態としては完全に別のソフトウェア、など)、を見据えながらいわゆる「星取り表」を作成していきます。オープンソース製品が持つメリットは、製品本体にない機能を追加するケースに強い、という点になります。

オープンソースモデルのリスク面での特徴

次に、リスクの観点です。これは企画した通りのシステムが実際にどのくらいの確度で実装されるのか、という意味でのリスクですが、まずは製品品質の観点からみてみたいと思います。

パッケージ製品とは言え、当たり前ですがバグは必ずあります。コミュニティのユーザという意味で従来型のベンダよりも多くの人員を動員できるオープンソース製品の品質保証プロセスと、自発性に任せるのではなく(楽観的にベンダを信頼するとして)、科学的な計画と手法に則ってテストを実施しているであろう従来型の品質保証プロセスのどちらを信用するか、という問題がまずあります。これについては、やはりこと業務用アプリケーションパッケージの世界では、オープンソースベンダも従来型のものに近い品質保証「も」実施しているので、総合的にはオープンソースモデルの方が有利であると考えられます。が、実際には製品毎の個体差が大きいので、どちらも製造元の努力で可能な限り不具合を減らしてから出荷されている、としましょう。それでもやはり、現場でバグはでるわけです。となると、次はそのバグに対してどう対応するのか、という点が問題になります。ここでも、オープンソースモデルは極めて強力に作用します。業務用のパッケージソフトウェアの合理性は、パッケージを利用することで自社の独自開発部分を極小化することにあります。その為、パッケージの標準機能やカスタマイズ時の強化ポイントを熟知したコンサルタントと言われる人員(我々のことです!)が配置されることが少なくありません。従来型の製品モデルの場合、こうしたコンサルタントやカスタマイズを実施するエンジニアにはソースコードに対するアクセスが許可されていないわけです。(契約のもと限定的に公開されるケースもありますが、コンサルタントやエンジニアの方がそのやり方に慣れていない、という意味で効果が限定的であったりします)。

昨今大規模案件で扱われるパッケージのほとんどが外国製ですから、現場のコンサルタントから国内外のテクニカルサポートスタッフを経由してソースコードにアクセスできる製造元本社のエンジニアまで課題の情報が共有されるまでのコミュニケーションは非常に非効率ですし、一回で意図が伝わることは稀なため解決までの時間もかかります。オープンソースモデルの場合は時間がかかりそうな説明が難しい問題に関してはソースコードを具体的に指し示して議論することでその問題を回避することができます。オープンソース製品を取り扱うコンサルタントが毎回そのようなコミュニケーションを行っているわけではありませんが、いざとなればそうすることもできる、というカードを持つことでプロジェクト運営のリスクが有意に下がるということは類似のプロジェクトを経験したことがある方にはご納得いただけるのではないかと思います。

また、製品品質というある種、静的な観点以外にもリスクについて評価しておくべき切り口が最低でも後2つあります。導入時のリスクと導入後の中長期を見据えたリスクです。導入時のリスクはプロジェクトを成功させられるかどうか、という観点で、その最も大きな要因は「要件が定まらない」というところに求められることが多いです。要件が決められるかどうかは、プロジェクトメンバーの力量に依存すると考えられ、製品特性とは切り分けて評価されてしまいがちですが、現代的なプロジェクトマネジメントにおいては「要件やプロジェクトの前提条件であるビジネス環境の変化」は与件であると見なされます。従って、要件の変化に対する対応力、という観点でソフトウェア、ソリューションを比較評価する必要があるわけです。前述した通り、(あくまで一般論ではありますが)、オープンソース製品はコミュニティを活用した機能強化の文化を持ち、従来型のソフトウェアは大味な買収行為とそれを含めたワンストップサービス化に活路を見いだしている状況にあるわけですから、プロジェクト期間中に発生するような比較的タイムスパンが短い変化への対応力という意味ではオープンソース方式の方が有利だと考えられます。

次に、導入後の中長期についてですが、従来型の製品の場合、それこそ買収されるなどベンダ側の都合によって使い続けることができなくなるケースがあります。また、サポートを継続的に受けるためには製品のアップグレードに追随していかなければなりませんが、カスタマイズ部分が足かせになってうまく行かない、という問題もよく見かけます。この場合も、それぞれのバージョン間の差と当該ユーザのみの事情の掛け合わせであるため事前にドキュメントを十全に作成することは現実的ではないため、ソースへのアクセスがあるか、元々サードパーティによるカスタマイズを受け入れる素地があるか、などのレベルで差が生まれます。さらに導入企業にとってのオープンソースの強力なメリットとして、「使い続けることができない」という心配がほとんどない、ということも重要です。(ビジネスとしてうまく行ってない場合はベンダがなくなってしまってサポートが受けられなくなる、という可能性はありますが)

リスクの観点からは、製品品質、導入時、導入後の中長期、のそれぞれの切り口において、オープンソースであることそのものが有利に働くことがあるということが理解していただけたかと思います。

オープンソースモデルの柔軟性面での特徴

最後に柔軟性です。これも基本的にはコミュニティの力を活用できるモデルそのものが高い柔軟性を実現します、というお話に尽きるのですが、もう少し具体的に論じてみたいと思います。オープンソース業界でよく使われるキーワードに、「ベンダロックインフリー(囲い込みの否定)」というものがあります。大抵のシステムは、しっかりとその中にデータを登録してはじめて効果を発揮しますし、データをたくさん丁寧に投入すればそれだけ効果も上がっていく傾向があります。しかし、そのシステムがライフサイクルを終え新しいものに置き換える時には、またデータを取り出して新しいシステムに移行してあげなければなりません。その時、簡単に全てのデータが移行しやすい状態で取り出せるかというと、あまり簡単ではないことが多いわけです。ベンダとしては、他社製品に引っ越されてしまうことを嫌うので、そういう引っ越し対応の機能に投資するモチベーションは当然低くなります。露骨な囲い込み行動はユーザの反感を買うので、オープン化するか隠蔽するかという難しい判断を迫られつつ、顧客から要請があったときに移行支援のスポット作業を提案する、というベンダも多いと思います。

一方、オープンソースの場合は、初めから完全な情報統制が不可能であることが明らかなので、オープン化しロックインを否定することで顧客を呼び込むという方向性に注力せざるを得ないわけです。結果としてこれはユーザにとってはもちろん、ベンダにとっても良い結果を生んでいるように見えます。

ロックインフリーから派生した特徴として、多くのオープンソース製品がマルチプラットフォーム戦略を取っています。WindowsでもLinuxでも動作する、とか、どの会社のRDBMSでも実行可能である、というポジションを確保しているわけです。サポートの負荷、製品品質および導入時のリスクを考えると、単一プラットフォームで特定のベンダの製品に寄せてシステム構築をするという方針にもメリットがありますが、実際にはすべての部門すべての業務で単一のビッグベンダが提供する技術で統一するというのはあまり現実的ではありません。さらに、中長期にわたって当該ベンダの技術のみを採用するという方針は非常に危ういものであると言わざるを得ないでしょう。価格交渉力の問題もありますが、ベンダ側は特定のユーザ企業の状況のみに振り回されるわけにはいかないので、そのベンダが買収されたり技術基盤を刷新することを決めた場合に、非常に大きな影響を受ける可能性があります。そのため、マルチプラットフォーム戦略を採っているパッケージ製品を選定することには意味があります。

また、コストの特徴としても述べましたが、オープンソースモデルはイニシャルではなく実際に年毎にかかるであろうサポート役務に対してのサブスクリプションモデルの課金を求めることがほとんどですので、何かの理由で利用されなくなった場合は総コストも下がります。これも柔軟性という意味では大きなポイントであるといえるでしょう。

以上、簡単にですが、コスト・ベネフィット・リスク・柔軟性の4軸でソフトウェア・ソリューションを評価する際、オープンソース製品が対象に含まれていた場合に押さえておくべき観点をご紹介しました。オープンソースのメリットが単純にコスト削減にあるわけではない、ということがご理解頂けたのではないかと思います。

 

このエントリーをはてなブックマークに追加

このコラムは役に立ちましたか?

読み込み中 ... 読み込み中 ...
株式会社イージフ 
株式会社イージフ 
石井 昭紀

外資系コンサルティングファーム入社後、、バイオ分野ソフトウェアの研究開発などの分野でオフショア開発のプロジェクトマネジメントと並行して、文書管理専門のコンサルティング業務の分野において活躍する。