テクノロジー
スケーラブルなOTTプラットフォームの構築
スケーラブルなOTTプラットフォームの構築
スケーラブルなOTTプラットフォームの構築
OTTのライブストリーミングやオンデマンドコンテンツのプラットフォームを構築することは、少々気の重い作業になる可能性があるため、役立つと思われるいくつかのポイントを共有したいと考えました。
通常、この種のプロジェクトは、上層部の誰かが、不条理な動かすことのできない期限を設定した新しい提案の立ち上げを約束したという議論から始まります。あるいは、おそらくさらに悪いことに、オールインワンのプラットフォームプロバイダーと取引を行い、考えられるあらゆるユースケースを最短の時間枠でカバーする製品を市場に投入することに合意してしまった場合です。聞き覚えはありませんか？
これから待ち受ける課題はありますが、皆様が正しい方向へと進むためのガイドとなるような事柄について説明していきたいと思います。ゴールは何でしょうか？それは、ベンダーロックインや制限された拡張性がロードマップの最初の2つの機能にならないような、スケーラブルで信頼性の高いプラットフォームを構築することです。
1. 要件定義（キャプチャ）
要件は、いくつかのハイレベルなカテゴリーやバケットに分類されます。プロダクト、ビジネス、テクノロジーです。通常、すべてはこれらのバーティカル（垂直領域）の下に何らかの形でネストされます。通常の消費者向けの「機能要件」を作成することは、税管理など、未知であることが多かったり忘れられがちだったりするいくつかの要件よりも少し簡単です。
要件定義の鍵は、すべての詳細がカバーされていることを確認することです。実例を挙げてみましょう。
プロダクトマネージャーは、「ユーザーとしてサイトを検索できる必要がある」といった方針に沿って要件のドラフトを作成します。優れたテクニカルアーキテクトは、これを機能要件および非機能要件にわたる10～15の個別の要件に分解する能力を持っています。これには、コンテンツ検索、データ検索、多言語対応、フィルタリング、ソート、永続性、結果の通知、検索結果ゼロ、アナリティクスとBIの統合、予測検索、結果の応答時間などの領域が含まれます。
ここでのメッセージは、要件が「明示的」かつ「詳細」であることを確実にするための作業を増やせば増やすほど、ベンダーが提供したソリューションが期待通りに動作しなかったときに、後から受ける苦痛を減らすことができるということです。曖昧さを排除しましょう。
2. RFI/RFP（情報提供依頼書/提案依頼書）プロセスとベンダー分析
なぜRFPが必要なのでしょうか？多くの理由がありますが、主に、これから構築するストリーミングプラットフォームの候補となる提携先やサプライヤーを比較するためのメカニズムとして考えてください。
プロセスの定義とともに、優れたRFIおよびRFPドキュメントを作成することは、どちらも同様に重要です。（ちなみに、RFIとRFPの違いを知ることは重要です！）ベンダーやプロバイダーが理解し、あなたが理解、比較、評価できる方法で返答できるような要件定義書の構成を正しく知ることは、想像以上に役立ちます。
優れたRFPドキュメントとプロセスは、以下をもたらします：
RFPプロセスの実行にかかる時間を短縮する
ベンダーが要件を理解し、正確な見積もりや提案書を作成できるようにする
回答から曖昧さを排除し、「非準拠」、「準拠」、および「ロードマップ」の要件を明確にする
ベンダーができることとできないことを浮き彫りにする
プライマリベンダーやシステムインテグレーターのいずれによっても満たされていない、ビジネス、プロダクト、テクノロジーチームが必要とするギャップや領域を特定する
ベンダーの回答を「同一条件」で比較できるようにする
念のため、いくつかのユースケースをランダムに選択し、上位2〜3社のベンダーにこれらの機能や動作がどのように機能するかをデモンストレーションしてもらうこともお勧めします。彼らが「準拠」と回答していた場合、真実を言っているかどうかがすぐにわかります。
私たちがクライアントのためにRFPドキュメントを作成し、プロセスを実行する場合、OTTまたはストリーミングプラットフォーム向けに定義された1500以上の機能要件および非機能要件を目にすることは珍しくありません。この数字に達していない場合は、すべてを徹底的かつ正しくカバーできているかどうか自問してみるべきでしょう。
3. プラットフォームアーキテクチャと設計
この道のりの一環として、私たちはスケーラブルなビデオストリーミングプラットフォームの構築を目指しています。プラットフォームアーキテクチャと設計のフェーズでは、ビジネスによって特定された要件を評価し、これらをベンダーやサプライヤーから提案されたソリューションと比較し、以下のようなスケーラブルな設計とソリューションリファレンスを構築するために機能します：
ローンチに向けた要件が確実に満たされるようにする
変化する要件を取り入れるための柔軟性をもたらす - 変化に対応するための設計
提案のギャップを特定し、それらに対処するためのソリューションを生み出す
ベンダーロックインのリスクを低減または排除する
機能要件および非機能要件を大規模にサポートする
プロデューサーとコンシューマーの無制限のスケールを可能にする - 数百万人へのライブストリーミング
ベストプラクティス、標準、およびアプローチが確実に遵守されるようにする
運営対象となる地域のコンプライアンス基準を満たす
時間、品質、コストの基準をバランスよく満たす
セキュリティ、パフォーマンス、運用のベンチマークを満たす
そして最後に、ソリューションがビジネス価値を確実に提供するようにする
メディアおよびストリーミングプラットフォームのアーキテクトは、提案されたソリューションが最善の手段で実装されることを保証します。ベンダーやソリューションプロバイダーが提供できるものだけに留まることはありません。
4. 実装への道
優れた土台があれば、実装への道は必然的にシンプルになります。それにもかかわらず、スケーラブルでパフォーマンスが高く、耐障害性と信頼性に優れたOTTプラットフォームの実装には依然として労力がかかります。また、ID、課金、サブスクリプション、コンテンツ、コンプライアンス、アナリティクスとデータ、アプリなどの重要な領域の開発と展開を所有するために、専任の「分隊（スクワッド）」やチームが必要になることがよくあります。
これらの専任チームには自己管理のための自主性が与えられ、これまでに同様のサービスを実装した経験を持つリーダーによって指導され、設計から本番稼働までの各ワークストリームを導いていきます。
より多くの組織が抱えるドメイン専門知識の保有数が減少しており、一部のビジネスユニットはプロダクトチーム（開発者、マネージャー、デザイナー、マーケター）のみで構成されていることは周知の事実です。課題は何でしょうか？技術的に困難な状況に陥ったときに、ベンダーやサプライヤーに説明責任を問うために技術的なレベルで必要となるドメインの知識や経験が不足していることです。
ベンダーはビジネスが設定した要件を満たすために提供できるものを提案しますが、優秀なビデオプラットフォームアーキテクトが証明するように、これが決して唯一の方法ではありません。
最も成功する実装は、アーキテクチャを所有するために社内の技術的な専門知識を活用するか、Spicy Mangoが提供するチームのような外部の経験を活用するかのいずれかによって、ビジネスが実装を主導および管理する必要性を認めているケースです。
私たちは、サプライヤーやベンダーがクライアントやプログラム全体の利益ではなく、自社の利益のみを代弁しているケースを繰り返し目にしています。現代のオンラインビデオプラットフォーム（OVP）は、もはや単一のエンティティによってのみ開発されたテクノロジースタックであることは稀で、ほぼすべてがマルチベンダーのSaaSベースの環境、つまりソリューションの個々の要素を提供する多くの個別ポイント製品の集まりです。優れた技術ドメインの専門知識を持つことで、問題が発生した際に責任のなすり合いを終わらせるための独立した仲裁者を得ることができます。
OTTのライブストリーミングやオンデマンドコンテンツのプラットフォームを構築することは、少々気の重い作業になる可能性があるため、役立つと思われるいくつかのポイントを共有したいと考えました。
通常、この種のプロジェクトは、上層部の誰かが、不条理な動かすことのできない期限を設定した新しい提案の立ち上げを約束したという議論から始まります。あるいは、おそらくさらに悪いことに、オールインワンのプラットフォームプロバイダーと取引を行い、考えられるあらゆるユースケースを最短の時間枠でカバーする製品を市場に投入することに合意してしまった場合です。聞き覚えはありませんか？
これから待ち受ける課題はありますが、皆様が正しい方向へと進むためのガイドとなるような事柄について説明していきたいと思います。ゴールは何でしょうか？それは、ベンダーロックインや制限された拡張性がロードマップの最初の2つの機能にならないような、スケーラブルで信頼性の高いプラットフォームを構築することです。
1. 要件定義（キャプチャ）
要件は、いくつかのハイレベルなカテゴリーやバケットに分類されます。プロダクト、ビジネス、テクノロジーです。通常、すべてはこれらのバーティカル（垂直領域）の下に何らかの形でネストされます。通常の消費者向けの「機能要件」を作成することは、税管理など、未知であることが多かったり忘れられがちだったりするいくつかの要件よりも少し簡単です。
要件定義の鍵は、すべての詳細がカバーされていることを確認することです。実例を挙げてみましょう。
プロダクトマネージャーは、「ユーザーとしてサイトを検索できる必要がある」といった方針に沿って要件のドラフトを作成します。優れたテクニカルアーキテクトは、これを機能要件および非機能要件にわたる10～15の個別の要件に分解する能力を持っています。これには、コンテンツ検索、データ検索、多言語対応、フィルタリング、ソート、永続性、結果の通知、検索結果ゼロ、アナリティクスとBIの統合、予測検索、結果の応答時間などの領域が含まれます。
ここでのメッセージは、要件が「明示的」かつ「詳細」であることを確実にするための作業を増やせば増やすほど、ベンダーが提供したソリューションが期待通りに動作しなかったときに、後から受ける苦痛を減らすことができるということです。曖昧さを排除しましょう。
2. RFI/RFP（情報提供依頼書/提案依頼書）プロセスとベンダー分析
なぜRFPが必要なのでしょうか？多くの理由がありますが、主に、これから構築するストリーミングプラットフォームの候補となる提携先やサプライヤーを比較するためのメカニズムとして考えてください。
プロセスの定義とともに、優れたRFIおよびRFPドキュメントを作成することは、どちらも同様に重要です。（ちなみに、RFIとRFPの違いを知ることは重要です！）ベンダーやプロバイダーが理解し、あなたが理解、比較、評価できる方法で返答できるような要件定義書の構成を正しく知ることは、想像以上に役立ちます。
優れたRFPドキュメントとプロセスは、以下をもたらします：
RFPプロセスの実行にかかる時間を短縮する
ベンダーが要件を理解し、正確な見積もりや提案書を作成できるようにする
回答から曖昧さを排除し、「非準拠」、「準拠」、および「ロードマップ」の要件を明確にする
ベンダーができることとできないことを浮き彫りにする
プライマリベンダーやシステムインテグレーターのいずれによっても満たされていない、ビジネス、プロダクト、テクノロジーチームが必要とするギャップや領域を特定する
ベンダーの回答を「同一条件」で比較できるようにする
念のため、いくつかのユースケースをランダムに選択し、上位2〜3社のベンダーにこれらの機能や動作がどのように機能するかをデモンストレーションしてもらうこともお勧めします。彼らが「準拠」と回答していた場合、真実を言っているかどうかがすぐにわかります。
私たちがクライアントのためにRFPドキュメントを作成し、プロセスを実行する場合、OTTまたはストリーミングプラットフォーム向けに定義された1500以上の機能要件および非機能要件を目にすることは珍しくありません。この数字に達していない場合は、すべてを徹底的かつ正しくカバーできているかどうか自問してみるべきでしょう。
3. プラットフォームアーキテクチャと設計
この道のりの一環として、私たちはスケーラブルなビデオストリーミングプラットフォームの構築を目指しています。プラットフォームアーキテクチャと設計のフェーズでは、ビジネスによって特定された要件を評価し、これらをベンダーやサプライヤーから提案されたソリューションと比較し、以下のようなスケーラブルな設計とソリューションリファレンスを構築するために機能します：
ローンチに向けた要件が確実に満たされるようにする
変化する要件を取り入れるための柔軟性をもたらす - 変化に対応するための設計
提案のギャップを特定し、それらに対処するためのソリューションを生み出す
ベンダーロックインのリスクを低減または排除する
機能要件および非機能要件を大規模にサポートする
プロデューサーとコンシューマーの無制限のスケールを可能にする - 数百万人へのライブストリーミング
ベストプラクティス、標準、およびアプローチが確実に遵守されるようにする
運営対象となる地域のコンプライアンス基準を満たす
時間、品質、コストの基準をバランスよく満たす
セキュリティ、パフォーマンス、運用のベンチマークを満たす
そして最後に、ソリューションがビジネス価値を確実に提供するようにする
メディアおよびストリーミングプラットフォームのアーキテクトは、提案されたソリューションが最善の手段で実装されることを保証します。ベンダーやソリューションプロバイダーが提供できるものだけに留まることはありません。
4. 実装への道
優れた土台があれば、実装への道は必然的にシンプルになります。それにもかかわらず、スケーラブルでパフォーマンスが高く、耐障害性と信頼性に優れたOTTプラットフォームの実装には依然として労力がかかります。また、ID、課金、サブスクリプション、コンテンツ、コンプライアンス、アナリティクスとデータ、アプリなどの重要な領域の開発と展開を所有するために、専任の「分隊（スクワッド）」やチームが必要になることがよくあります。
これらの専任チームには自己管理のための自主性が与えられ、これまでに同様のサービスを実装した経験を持つリーダーによって指導され、設計から本番稼働までの各ワークストリームを導いていきます。
より多くの組織が抱えるドメイン専門知識の保有数が減少しており、一部のビジネスユニットはプロダクトチーム（開発者、マネージャー、デザイナー、マーケター）のみで構成されていることは周知の事実です。課題は何でしょうか？技術的に困難な状況に陥ったときに、ベンダーやサプライヤーに説明責任を問うために技術的なレベルで必要となるドメインの知識や経験が不足していることです。
ベンダーはビジネスが設定した要件を満たすために提供できるものを提案しますが、優秀なビデオプラットフォームアーキテクトが証明するように、これが決して唯一の方法ではありません。
最も成功する実装は、アーキテクチャを所有するために社内の技術的な専門知識を活用するか、Spicy Mangoが提供するチームのような外部の経験を活用するかのいずれかによって、ビジネスが実装を主導および管理する必要性を認めているケースです。
私たちは、サプライヤーやベンダーがクライアントやプログラム全体の利益ではなく、自社の利益のみを代弁しているケースを繰り返し目にしています。現代のオンラインビデオプラットフォーム（OVP）は、もはや単一のエンティティによってのみ開発されたテクノロジースタックであることは稀で、ほぼすべてがマルチベンダーのSaaSベースの環境、つまりソリューションの個々の要素を提供する多くの個別ポイント製品の集まりです。優れた技術ドメインの専門知識を持つことで、問題が発生した際に責任のなすり合いを終わらせるための独立した仲裁者を得ることができます。
OTTのライブストリーミングやオンデマンドコンテンツのプラットフォームを構築することは、少々気の重い作業になる可能性があるため、役立つと思われるいくつかのポイントを共有したいと考えました。
通常、この種のプロジェクトは、上層部の誰かが、不条理な動かすことのできない期限を設定した新しい提案の立ち上げを約束したという議論から始まります。あるいは、おそらくさらに悪いことに、オールインワンのプラットフォームプロバイダーと取引を行い、考えられるあらゆるユースケースを最短の時間枠でカバーする製品を市場に投入することに合意してしまった場合です。聞き覚えはありませんか？
これから待ち受ける課題はありますが、皆様が正しい方向へと進むためのガイドとなるような事柄について説明していきたいと思います。ゴールは何でしょうか？それは、ベンダーロックインや制限された拡張性がロードマップの最初の2つの機能にならないような、スケーラブルで信頼性の高いプラットフォームを構築することです。
1. 要件定義（キャプチャ）
要件は、いくつかのハイレベルなカテゴリーやバケットに分類されます。プロダクト、ビジネス、テクノロジーです。通常、すべてはこれらのバーティカル（垂直領域）の下に何らかの形でネストされます。通常の消費者向けの「機能要件」を作成することは、税管理など、未知であることが多かったり忘れられがちだったりするいくつかの要件よりも少し簡単です。
要件定義の鍵は、すべての詳細がカバーされていることを確認することです。実例を挙げてみましょう。
プロダクトマネージャーは、「ユーザーとしてサイトを検索できる必要がある」といった方針に沿って要件のドラフトを作成します。優れたテクニカルアーキテクトは、これを機能要件および非機能要件にわたる10～15の個別の要件に分解する能力を持っています。これには、コンテンツ検索、データ検索、多言語対応、フィルタリング、ソート、永続性、結果の通知、検索結果ゼロ、アナリティクスとBIの統合、予測検索、結果の応答時間などの領域が含まれます。
ここでのメッセージは、要件が「明示的」かつ「詳細」であることを確実にするための作業を増やせば増やすほど、ベンダーが提供したソリューションが期待通りに動作しなかったときに、後から受ける苦痛を減らすことができるということです。曖昧さを排除しましょう。
2. RFI/RFP（情報提供依頼書/提案依頼書）プロセスとベンダー分析
なぜRFPが必要なのでしょうか？多くの理由がありますが、主に、これから構築するストリーミングプラットフォームの候補となる提携先やサプライヤーを比較するためのメカニズムとして考えてください。
プロセスの定義とともに、優れたRFIおよびRFPドキュメントを作成することは、どちらも同様に重要です。（ちなみに、RFIとRFPの違いを知ることは重要です！）ベンダーやプロバイダーが理解し、あなたが理解、比較、評価できる方法で返答できるような要件定義書の構成を正しく知ることは、想像以上に役立ちます。
優れたRFPドキュメントとプロセスは、以下をもたらします：
RFPプロセスの実行にかかる時間を短縮する
ベンダーが要件を理解し、正確な見積もりや提案書を作成できるようにする
回答から曖昧さを排除し、「非準拠」、「準拠」、および「ロードマップ」の要件を明確にする
ベンダーができることとできないことを浮き彫りにする
プライマリベンダーやシステムインテグレーターのいずれによっても満たされていない、ビジネス、プロダクト、テクノロジーチームが必要とするギャップや領域を特定する
ベンダーの回答を「同一条件」で比較できるようにする
念のため、いくつかのユースケースをランダムに選択し、上位2〜3社のベンダーにこれらの機能や動作がどのように機能するかをデモンストレーションしてもらうこともお勧めします。彼らが「準拠」と回答していた場合、真実を言っているかどうかがすぐにわかります。
私たちがクライアントのためにRFPドキュメントを作成し、プロセスを実行する場合、OTTまたはストリーミングプラットフォーム向けに定義された1500以上の機能要件および非機能要件を目にすることは珍しくありません。この数字に達していない場合は、すべてを徹底的かつ正しくカバーできているかどうか自問してみるべきでしょう。
3. プラットフォームアーキテクチャと設計
この道のりの一環として、私たちはスケーラブルなビデオストリーミングプラットフォームの構築を目指しています。プラットフォームアーキテクチャと設計のフェーズでは、ビジネスによって特定された要件を評価し、これらをベンダーやサプライヤーから提案されたソリューションと比較し、以下のようなスケーラブルな設計とソリューションリファレンスを構築するために機能します：
ローンチに向けた要件が確実に満たされるようにする
変化する要件を取り入れるための柔軟性をもたらす - 変化に対応するための設計
提案のギャップを特定し、それらに対処するためのソリューションを生み出す
ベンダーロックインのリスクを低減または排除する
機能要件および非機能要件を大規模にサポートする
プロデューサーとコンシューマーの無制限のスケールを可能にする - 数百万人へのライブストリーミング
ベストプラクティス、標準、およびアプローチが確実に遵守されるようにする
運営対象となる地域のコンプライアンス基準を満たす
時間、品質、コストの基準をバランスよく満たす
セキュリティ、パフォーマンス、運用のベンチマークを満たす
そして最後に、ソリューションがビジネス価値を確実に提供するようにする
メディアおよびストリーミングプラットフォームのアーキテクトは、提案されたソリューションが最善の手段で実装されることを保証します。ベンダーやソリューションプロバイダーが提供できるものだけに留まることはありません。
4. 実装への道
優れた土台があれば、実装への道は必然的にシンプルになります。それにもかかわらず、スケーラブルでパフォーマンスが高く、耐障害性と信頼性に優れたOTTプラットフォームの実装には依然として労力がかかります。また、ID、課金、サブスクリプション、コンテンツ、コンプライアンス、アナリティクスとデータ、アプリなどの重要な領域の開発と展開を所有するために、専任の「分隊（スクワッド）」やチームが必要になることがよくあります。
これらの専任チームには自己管理のための自主性が与えられ、これまでに同様のサービスを実装した経験を持つリーダーによって指導され、設計から本番稼働までの各ワークストリームを導いていきます。
より多くの組織が抱えるドメイン専門知識の保有数が減少しており、一部のビジネスユニットはプロダクトチーム（開発者、マネージャー、デザイナー、マーケター）のみで構成されていることは周知の事実です。課題は何でしょうか？技術的に困難な状況に陥ったときに、ベンダーやサプライヤーに説明責任を問うために技術的なレベルで必要となるドメインの知識や経験が不足していることです。
ベンダーはビジネスが設定した要件を満たすために提供できるものを提案しますが、優秀なビデオプラットフォームアーキテクトが証明するように、これが決して唯一の方法ではありません。
最も成功する実装は、アーキテクチャを所有するために社内の技術的な専門知識を活用するか、Spicy Mangoが提供するチームのような外部の経験を活用するかのいずれかによって、ビジネスが実装を主導および管理する必要性を認めているケースです。
私たちは、サプライヤーやベンダーがクライアントやプログラム全体の利益ではなく、自社の利益のみを代弁しているケースを繰り返し目にしています。現代のオンラインビデオプラットフォーム（OVP）は、もはや単一のエンティティによってのみ開発されたテクノロジースタックであることは稀で、ほぼすべてがマルチベンダーのSaaSベースの環境、つまりソリューションの個々の要素を提供する多くの個別ポイント製品の集まりです。優れた技術ドメインの専門知識を持つことで、問題が発生した際に責任のなすり合いを終わらせるための独立した仲裁者を得ることができます。
OTTのライブストリーミングやオンデマンドコンテンツのプラットフォームを構築することは、少々気の重い作業になる可能性があるため、役立つと思われるいくつかのポイントを共有したいと考えました。
通常、この種のプロジェクトは、上層部の誰かが、不条理な動かすことのできない期限を設定した新しい提案の立ち上げを約束したという議論から始まります。あるいは、おそらくさらに悪いことに、オールインワンのプラットフォームプロバイダーと取引を行い、考えられるあらゆるユースケースを最短の時間枠でカバーする製品を市場に投入することに合意してしまった場合です。聞き覚えはありませんか？
これから待ち受ける課題はありますが、皆様が正しい方向へと進むためのガイドとなるような事柄について説明していきたいと思います。ゴールは何でしょうか？それは、ベンダーロックインや制限された拡張性がロードマップの最初の2つの機能にならないような、スケーラブルで信頼性の高いプラットフォームを構築することです。
1. 要件定義（キャプチャ）
要件は、いくつかのハイレベルなカテゴリーやバケットに分類されます。プロダクト、ビジネス、テクノロジーです。通常、すべてはこれらのバーティカル（垂直領域）の下に何らかの形でネストされます。通常の消費者向けの「機能要件」を作成することは、税管理など、未知であることが多かったり忘れられがちだったりするいくつかの要件よりも少し簡単です。
要件定義の鍵は、すべての詳細がカバーされていることを確認することです。実例を挙げてみましょう。
プロダクトマネージャーは、「ユーザーとしてサイトを検索できる必要がある」といった方針に沿って要件のドラフトを作成します。優れたテクニカルアーキテクトは、これを機能要件および非機能要件にわたる10～15の個別の要件に分解する能力を持っています。これには、コンテンツ検索、データ検索、多言語対応、フィルタリング、ソート、永続性、結果の通知、検索結果ゼロ、アナリティクスとBIの統合、予測検索、結果の応答時間などの領域が含まれます。
ここでのメッセージは、要件が「明示的」かつ「詳細」であることを確実にするための作業を増やせば増やすほど、ベンダーが提供したソリューションが期待通りに動作しなかったときに、後から受ける苦痛を減らすことができるということです。曖昧さを排除しましょう。
2. RFI/RFP（情報提供依頼書/提案依頼書）プロセスとベンダー分析
なぜRFPが必要なのでしょうか？多くの理由がありますが、主に、これから構築するストリーミングプラットフォームの候補となる提携先やサプライヤーを比較するためのメカニズムとして考えてください。
プロセスの定義とともに、優れたRFIおよびRFPドキュメントを作成することは、どちらも同様に重要です。（ちなみに、RFIとRFPの違いを知ることは重要です！）ベンダーやプロバイダーが理解し、あなたが理解、比較、評価できる方法で返答できるような要件定義書の構成を正しく知ることは、想像以上に役立ちます。
優れたRFPドキュメントとプロセスは、以下をもたらします：
RFPプロセスの実行にかかる時間を短縮する
ベンダーが要件を理解し、正確な見積もりや提案書を作成できるようにする
回答から曖昧さを排除し、「非準拠」、「準拠」、および「ロードマップ」の要件を明確にする
ベンダーができることとできないことを浮き彫りにする
プライマリベンダーやシステムインテグレーターのいずれによっても満たされていない、ビジネス、プロダクト、テクノロジーチームが必要とするギャップや領域を特定する
ベンダーの回答を「同一条件」で比較できるようにする
念のため、いくつかのユースケースをランダムに選択し、上位2〜3社のベンダーにこれらの機能や動作がどのように機能するかをデモンストレーションしてもらうこともお勧めします。彼らが「準拠」と回答していた場合、真実を言っているかどうかがすぐにわかります。
私たちがクライアントのためにRFPドキュメントを作成し、プロセスを実行する場合、OTTまたはストリーミングプラットフォーム向けに定義された1500以上の機能要件および非機能要件を目にすることは珍しくありません。この数字に達していない場合は、すべてを徹底的かつ正しくカバーできているかどうか自問してみるべきでしょう。
3. プラットフォームアーキテクチャと設計
この道のりの一環として、私たちはスケーラブルなビデオストリーミングプラットフォームの構築を目指しています。プラットフォームアーキテクチャと設計のフェーズでは、ビジネスによって特定された要件を評価し、これらをベンダーやサプライヤーから提案されたソリューションと比較し、以下のようなスケーラブルな設計とソリューションリファレンスを構築するために機能します：
ローンチに向けた要件が確実に満たされるようにする
変化する要件を取り入れるための柔軟性をもたらす - 変化に対応するための設計
提案のギャップを特定し、それらに対処するためのソリューションを生み出す
ベンダーロックインのリスクを低減または排除する
機能要件および非機能要件を大規模にサポートする
プロデューサーとコンシューマーの無制限のスケールを可能にする - 数百万人へのライブストリーミング
ベストプラクティス、標準、およびアプローチが確実に遵守されるようにする
運営対象となる地域のコンプライアンス基準を満たす
時間、品質、コストの基準をバランスよく満たす
セキュリティ、パフォーマンス、運用のベンチマークを満たす
そして最後に、ソリューションがビジネス価値を確実に提供するようにする
メディアおよびストリーミングプラットフォームのアーキテクトは、提案されたソリューションが最善の手段で実装されることを保証します。ベンダーやソリューションプロバイダーが提供できるものだけに留まることはありません。
4. 実装への道
優れた土台があれば、実装への道は必然的にシンプルになります。それにもかかわらず、スケーラブルでパフォーマンスが高く、耐障害性と信頼性に優れたOTTプラットフォームの実装には依然として労力がかかります。また、ID、課金、サブスクリプション、コンテンツ、コンプライアンス、アナリティクスとデータ、アプリなどの重要な領域の開発と展開を所有するために、専任の「分隊（スクワッド）」やチームが必要になることがよくあります。
これらの専任チームには自己管理のための自主性が与えられ、これまでに同様のサービスを実装した経験を持つリーダーによって指導され、設計から本番稼働までの各ワークストリームを導いていきます。
より多くの組織が抱えるドメイン専門知識の保有数が減少しており、一部のビジネスユニットはプロダクトチーム（開発者、マネージャー、デザイナー、マーケター）のみで構成されていることは周知の事実です。課題は何でしょうか？技術的に困難な状況に陥ったときに、ベンダーやサプライヤーに説明責任を問うために技術的なレベルで必要となるドメインの知識や経験が不足していることです。
ベンダーはビジネスが設定した要件を満たすために提供できるものを提案しますが、優秀なビデオプラットフォームアーキテクトが証明するように、これが決して唯一の方法ではありません。
最も成功する実装は、アーキテクチャを所有するために社内の技術的な専門知識を活用するか、Spicy Mangoが提供するチームのような外部の経験を活用するかのいずれかによって、ビジネスが実装を主導および管理する必要性を認めているケースです。
私たちは、サプライヤーやベンダーがクライアントやプログラム全体の利益ではなく、自社の利益のみを代弁しているケースを繰り返し目にしています。現代のオンラインビデオプラットフォーム（OVP）は、もはや単一のエンティティによってのみ開発されたテクノロジースタックであることは稀で、ほぼすべてがマルチベンダーのSaaSベースの環境、つまりソリューションの個々の要素を提供する多くの個別ポイント製品の集まりです。優れた技術ドメインの専門知識を持つことで、問題が発生した際に責任のなすり合いを終わらせるための独立した仲裁者を得ることができます。
ここに記載されている内容についてさらに詳しく知りたい場合、またはSpicy Mangoがどのように役立つかを知りたい場合は、hello@spicymango.co.ukまでメールをお送りいただくか、お電話、またはお問い合わせフォームからメッセージをお送りください。折り返しご連絡いたします。
ここに記載されている内容についてさらに詳しく知りたい場合、またはSpicy Mangoがどのように役立つかを知りたい場合は、hello@spicymango.co.ukまでメールをお送りいただくか、お電話、またはお問い合わせフォームからメッセージをお送りください。折り返しご連絡いたします。
ここに記載されている内容についてさらに詳しく知りたい場合、またはSpicy Mangoがどのように役立つかを知りたい場合は、hello@spicymango.co.ukまでメールをお送りいただくか、お電話、またはお問い合わせフォームからメッセージをお送りください。折り返しご連絡いたします。
