オープンソース製品が長期的な発展を遂げるためには、単に無料の製品であるだけでなく、商業的価値を生み出し、顧客に喜んでお金を支払ってもらえるような能力がなければなりません。

もちろん、オープンソース製品は数多く存在し、それぞれ開発の軌跡は異なります。企業によっては、主にユーザーベース拡大を目的として、ツールをオープンソース化し、無料で配布する場合もあります。純粋なオープンソースプロジェクトの進化の過程において、プロダクトマネージャーは無料版を提供する一方で、ユーザーにさらなる技術サポートを提供できる能力も備えている必要があります。

具体的には、プロダクトマネージャーはプロジェクトを立ち上げるだけでなく、顧客を維持するためのソリューションも提供する必要があります。優秀な営業担当者は、製品を必要としている顧客に積極的に売り込むことを躊躇しません。これはオープンソースプロジェクトにも当てはまります。顧客に必要な製品を購入してもらうことは、決して恥ずかしいことではありません。オープンソースプロジェクトをベースに構築された製品は、市場にある他の製品やサービスと根本的に異なるわけではないからです。誰もが顧客にとって価値を創造する必要があります。さらに、オープンソースプロジェクトを収益化することは比較的困難であり、ユーザーの認知度を高めるために通常の2倍の努力が必要です。

オープンソース製品やプロジェクトが商業的価値を実現するには、まずその概念を明確にし、純粋なオープンソース製品とベンダーが提供するオープンソース プロジェクトをユーザーが区別できるようにする必要があります。

1. 価値を創造するには？

▲製品価値

オープンソース ソフトウェアに基づいて構築された製品は、他の製品やサービスと根本的に異なるものではありませんが、微妙な違いは依然として存在します。

まず、純粋なオープンソースソフトウェアの開発コストの一部は、すべてのオープンソース貢献者が負担します。これらのコストには、コード、テスト、ドキュメント、ハードウェア、プロジェクトホスティングなどが含まれます。ただし、ベンダーが提供する商用オープンソースプロジェクトの場合、開発コストはオープンソースプロジェクト自体が負担する場合でも、最終的なコストはコードを作成したベンダーが負担します。主なコストとしては、調査、分析、セキュリティ、パフォーマンステスト、認証プロセス（ハードウェアベンダーやクラウドプロバイダーとの連携など）にかかる人件費、そして販売・マーケティングコストなどが挙げられます。

2. 市場の問題をどう解決するか?

▲市場の問題

オープンソース製品の成功を測る前提条件は、上流のオープンソース貢献（開発コスト）と下流の製品化コスト（サプライヤーコスト）を賄うのに十分な収益を生み出すことができることです。言い換えれば、製品によって創出される価値が有料顧客からのみ得られる場合、収益化の可能性は極めて低くなります。この発言は大げさに聞こえるかもしれませんが、紛れもない事実です。製品の収益化は強制できるものではありません。しかし、過度に悲観的になる必要はありません。問題よりも解決策の方が常に多いからです。

3. オープンソース ソフトウェアと商用の独自ソフトウェアの価値提案の違いは何ですか?

オープンソースソフトウェアとプロプライエタリな商用ソフトウェアの最大の違いは、ソースコードが公開されているかどうかです。オープンソースソフトウェアの観点から見ると、「プロプライエタリ」は正反対の概念です。しかし、製造業、金融業、そして多くの伝統的な産業と比較すると、実際には「プロプライエタリ」を好む傾向があります。例えば、金融業界は独自のアルゴリズムを重視しています。さらに、プロプライエタリソフトウェアを所有する人々は、所有権と価値は同等であると考えています。これは、ライセンスの制約なしに、高品質なオープンソースソフトウェアを作成し、プロプライエタリソフトウェアと同等の価値を提供することが困難であるためです。

オープンソース製品の観点から見ると、多くのソフトウェアプログラムの独自機能はコードのオープン性を制限し、結果としてシステムアプリケーションが過度に閉鎖的になり、ユーザーの拡張性が低下します。オープンソースソフトウェアの価値はユーザーの信頼にあります。さらに、ユーザーが労力を惜しまなければ、自ら構築または再構築できるため、アプリケーションの拡張性が大幅に向上します。

特に、オープンソースソフトウェアを基盤としたソリューションがますます手頃な価格になるにつれ、一部のユーザーにとって、プロプライエタリソリューションはもはや唯一の選択肢ではなくなりました。言い換えれば、オープンソースソフトウェアは、顧客のコスト削減の観点から、より広範な開発の余地を獲得したのです。活気に満ちたオープンソースソフトウェアの新しいエコシステムでは、ユーザーはベンダーに縛られることなく、独自に構築するか、直接購入して使用量に応じた料金を支払うかを選択できます。

4. プロダクトマネージャーはどのような仕事をするのでしょうか?

コアとなるエンタープライズアプリケーションについては、ほとんどの企業が自社開発を好みます。オープンソースプロジェクトのプロダクトマネージャーの仕事は、実際にはプロプライエタリ製品やサービスの場合と同じです。つまり、製品やサービスの価値を提供することでユーザーを維持することです。しかし、オープンソースソフトウェアのプロダクトマネージャーの責任はより重くなります。製品価値に焦点を当てるだけでなく、製品をさらにパッケージ化し、市場で競争力を確保し、大手サービスプロバイダーが提供する上流プロジェクトとの差別化を図る能力も求められます。

最も重要なことは、何か重要なことを達成したいオープンソース製品マネージャーは、次のことを理解する必要があるということです。

• エコシステムチェーン：適切なアップストリームエコシステムの選択は極めて重要です。アップストリームコミュニティの健全性が、オープンソースプロジェクトの最終的な運命を決定づけます。OpenShift、Docker EE、Mesosphereといった製品は、それぞれKubernetes、Swarm、Apache Mesosを利用することで成功を収めました。ある意味で、OpenShiftとKubernetesの関係は、電気自動車とガソリン車の関係に似ています。どちらかが他方に取って代わることはまずなく、むしろ独立したまま、最終的には同じエコシステム内で差別化されたサービスを通じてユーザーに異なる選択肢を提供していくでしょう。

• 品質エンジニアリング：継続的インテグレーションと継続的デリバリー（CI/CD）とユーザーテストは、製品構築の基本です。しかし、下流の製品（通常は複数の上流プロジェクトで構成）が、すべてのコンポーネントの特定のバージョンで正常に動作することを確認することは非常に重要です。ソリューション全体のテストと体験は、上流ベンダーを競合製品と差別化する上で同様に重要です。なぜなら、最終的に顧客が求めているのは、効果的な製品だけだからです。

• 業界認証：政府機関、金融サービス、運輸、製造、通信といった特定の顧客カテゴリーでは、通常、認証が求められます。つまり、ユーザーニーズの多くはセキュリティや監査に関連しており、通常は高額です。認証は競争上の差別化要因として、競合他社や上流メーカーとの差別化を図る上でも重要な機能です。

• ハードウェアまたはクラウドプロバイダーの認定：安価なハードウェアに関するあまり知られていない秘密は、成熟度が異なる新機能が搭載されていることが多いことです。ハードウェア認定は、ソフトウェアが特定のハードウェアまたはクラウド仮想マシン上で問題なく動作することを保証し、一定の信頼性をもたらします。また、製品メーカーと認定プロバイダーが互換性のあるプラットフォーム上で連携できることも保証します。通常、ハードウェアを自ら監査する企業は、潜在的な顧客であることが多いです。こうした企業は、ハードウェアベンダーやクラウドプロバイダーとの強固な関係が不足していることが多く、ビジネス要件に応じてアプリケーションを迅速に修正またはパッチ適用することが困難です。

• エコシステム：これはサードパーティサービスからのサポートレベルを決定します。優れたエコシステムは、各アプリケーションの持続可能性を最大限に高め、より多くのアプリケーションとの連携を可能にします。プラットフォームが小規模であったり、個人向けソフトウェアのみを対象としている場合、ベンダーが独自に構築したプラットフォームを認定することは困難です。これは、個々のユーザーにとって統合が一般的に困難でコストがかかるためです。

• ライフサイクル：高品質なアップストリームプロジェクトは、本質的に製品の革新性を高めます。さらに、多くのアップストリームプロジェクトが、単一の製品に対して複数のバージョンやサプライチェーンをサポートしています。異なるアップストリームプロジェクトのすべてのバージョンが、特定のライフサイクル内で連携して動作することを保証することは、困難な作業です。さらに、オープンソースプロジェクトベンダーの観点からは、顧客のROIを最大化するために、ライフサイクルの長期化も望んでいます。

• パッケージングと配布：ベンダーが製品のライフサイクル（例：5年間）にわたるサポートを約束した場合、その期間中はパッケージングと配布の提供も約束する必要があります。製品であれクラウドサービスであれ、ロードマップの計画、導入実行、そして拡張に必要なライフサイクル全体にわたる機能を顧客に提供する必要があります。したがって、ソフトウェアパッケージとサービスはどちらも、想定された期間中、顧客に提供し続ける必要があります。

• テキスト：オープンソースプロジェクトの開発者やベンダーは、この点を見落としがちです。上流ベンダーのテキストだけに頼るのではなく、製品ライフサイクル全体を通して製品テキストの一貫性を維持することは非常に重要であり、ソリューション全体の相互運用性を左右します。エンドユーザーによるインストールやユースケースを問わず、使用するコンポーネントの特定の組み合わせに合わせてテキストを調整することで、顧客にとってメリットが生まれます。

• セキュリティ：製品ライフサイクルと密接に関連し、サプライヤーは製品のサポートライフサイクル全体を通じてセキュリティを提供することにコミットする必要があります。これには、コードの解析、脆弱性のスコアリング、脆弱性へのパッチ適用、そしてパッチ適用の検証が含まれます。これは、製品を上流サプライヤーと差別化するのに特に適した領域です。まさに、データを通じて価値を創造するということです。

• パフォーマンス：この能力も製品ライフサイクルと密接に関連しています。サプライヤーは、製品ライフサイクル全体を通してパフォーマンステストと最適化の提案を提供し、場合によっては移植を通じてさらなる最適化とパフォーマンス向上を実現することに尽力する必要があります。

• 補償：本質的には、ソフトウェアを使用している企業が特許トロールに訴訟を起こされた場合に備えた保険のようなものです。通常、企業の法務チームには自己弁護能力が不足しています。潜在的な顧客は第三者の法律サービスに費用を支払うかもしれませんが、そのサービスがソフトウェアを理解しているかどうかは疑問です。

• コンピューティングリソース：料金を支払わずにコンピューティングリソースを利用することはできません。無料トライアルはありますが、継続利用にはクラウドプロバイダー経由かハードウェア購入かを問わず、常に料金を支払う必要があります。実際、これはInfrastructure as a Service（IaaS）およびSoftware as a Service（SaaS）クラウドプロバイダーが提供する主な差別化要因の一つです。これは、コンピューティング、ストレージ、ネットワークを無料で提供する予算を持たない上流ベンダーとは大きく異なります。

• コンサルティング：コンサルティングを通じて運用知識やソフトウェアの構築・活用能力を獲得することも、製品の差別化要因となります。十分な予算とキャパシティがあれば、企業は優秀な人材を採用できますが、人材を見つけるのは容易ではありません。実際、ソフトウェアベンダーは優秀な人材を引きつける可能性がはるかに高く、ユーザーが自ら価値を再構築しようとする中で、人材不足に陥っていると言えるかもしれません。

• トレーニング：コンサルティングと同様に、大規模なソフトウェアの開発、構成、リリース、運用を行う企業は、コンサルティングおよびトレーニングシステムを最大限に活用する方法を熟知していることが多いです。同様に、十分な予算とキャパシティがあれば、優秀な人材を採用することも可能です。

• 運用に関する知識：IaaSおよびSaaSソリューションには通常、運用に関する知識が必要です。同様に、インストールされた環境の構成を分析するには、ユーザーに洞察を提供するナレッジベースとコネクテッドエクスペリエンスを構築するための運用に関する知識も必要です（例：OpenShift、Red Hat Insights）。

• サポート：これには、トレーニング、コンサルティング、運用知識と同様に、ヘルプを求めたり、サポートチケットを送信したりする機能が含まれます。「サポート」の重要性は、オープンソース製品マネージャーにとってしばしば支えとなります。同様に、顧客は全体的な戦略、投資、人材の優先順位に応じて、独自のサポート組織を再編成できる場合が多くあります。

• プロプライエタリコード：これは、オープンソースライセンスに基づいてリリースされていないコードを指します。顧客は最終的に独自のソフトウェア開発チームを立ち上げ、オープンソースのコアコードを拡張し、必要な機能を補完することになります。ベンダーにとって、プロプライエタリコードのデメリットは、上流のオープンソースベンダーと下流の製品の間に不自然な競争を生み出すことです。さらに、オープンソースコードとプロプライエタリコードのこの不自然な区分は、顧客にとっての価値向上に繋がらず、むしろ価値が不自然に抑制されているように感じられます。

• ブランド：ブランドエクイティは測定が容易ではありません。本質的には、信頼度にかかっています。顧客は、ソリューションプロバイダーが必要な時に助けてくれる、そして助けてくれると信じなければなりません。ブランドの構築には時間がかかりますが、失うのは簡単です。

このガイドがあれば、プロジェクトが価値を提供できないことを心配する必要はもうありません。オープンソースソフトウェアの製品管理であれ、プロプライエタリソフトウェアであれ、最終的なアプローチは同じだからです。

元記事のリンク: https://opensource.com/article/21/2/differentiating-products-upstream-suppliers