2022年3月1日に「「Red Hat OpenShift 事例セミナーシリーズ 第6回 お客様のコンテナ導入への課題を解決する実践プログラム”Container Adoption Journey”」にて登壇させていただきました。（オンラインなので「登壇」という言葉は適切ではないかもですが）
プラットフォームビジネスは多くの企業や個人の利用が定着すれば継続的に安定した利益を産む、ゆえにプラットフォームビジネスの確立を目指す企業も多いと思います。ただし、そこには成功させるためのいくつか要素があるかと思います。
Ecosystem
プラットフォームには当然提供する側と利用する側が存在します。両方がうまく回るエコシステムを準備してはじめてプラットフォーム事業として成立するわけですが、資金力がある企業はプラットフォームを提供する側になってビジネスをしようとすることが多いです。ですが、箱だけを準備して「さぁ好きなだけ使ってください」で自然と利用される可能性はかなり低いのではないでしょうか。
決済事業もプラットフォーム事業の一つですが、決済の機能を提供するだけではなく加盟店獲得のためにはいろいろな施策が必要です。決済機能のようにシンプルなサービスであれば、企業間での差異はあまり見られないため、決済プラットフォーム事業だけをみれば圧倒的な資金力や営業リソースがモノを言うと思います。先行していたOrigamiがあっという間に飲み込まれていったように。
プラットフォームが用意する機能が高度で複雑であればあるほどこの課題を抱える可能性は高いのではないでしょうか。
MVP
どうしてもプラットフォームを提供する側としてはできるだけ多くの機能が入った箱を用意しがちです。しかし、あまりに重厚長大なプラットフォームの場合は、準備している間に顧客のニーズの変化が起きたり、他社に先行されてしまったりする可能性も大きく、また、大きなプロジェクトであるほど走り始めると途中で失敗だとわかっても止まることが難しく、完成してからも機能追加や改修をするたびに多くの時間や費用を要するような設計に陥りやすいです。
違った観点ではありますが、投資回収の面でも初期段階から重厚長大なプラットフォームを構築すると継続するのが難しいことも多くなります。多額の投資をかけるときには当然回収モデルもつくるかと思います。たとえば、3年以内に黒字ビジネスにするとか、5年以内には投資額を回収するなど。理想通りに進むのは稀ではないでしょうか。思うように利益を産むことができずきりきりまいな毎日をすごすことになりますし、利益を産むどころかお守りをする費用がどんどん赤字として垂れ流されていくわけです。小さく始めていれば、適宜ビジネス判断をし、失敗したと感じたところで方向転換をしたり、止めることができますが、大きくつくったものはなかなか難しいのではないでしょうか。
コンパクトかつシャープに必要な機能をひとつひとつ踏み固めていく必要があるかと思います。
Agility
顧客のニーズの変化に速やかに対応するためにはAgilityが必須です。２つ目にあげたようにコンパクトかつシャープに必要な機能を実装していれば、それほど頻繁にプラットフォームの機能改修をすることは少ないかもしれませんが、プラットフォーム上で作られるアプリケーション、サービスがAgility高く対応できる環境を提供してあげる必要はあります。たとえば、アプリケーションの迅速なリリースにおいては、迅速かつ品質を保証できるようなテストの仕組みも必要です。
同時に組織的にもAgilityが必要です。決断や承認に時間がかかる組織体制だとプラットフォームのスピードある進化を妨げてしまいます。
個人の経験上ではありますが、通信キャリアはこういった課題を抱えやすい方向にあるのではないかと思われます。基地局の建設や、i-modeに代表される携帯のポータルサイトの提供、キャリア決済など、キャリアの資金力を活かしたビジネスができるドメインであったり、キャリア中心のビジネスが通用する時代におけるビジネスモデルでの成功イメージが強いためではないでしょうか。
コンテナ基盤サービスもプラットフォームサービスのひとつとして、そんな課題に向き合うことが多いサービスの一つと考えられます。それらの課題に対してどのように取組み、どのように解決をしていくのか、Red Hatが提案しているContainer Adoption Journey の概要を3月1日「Red Hat OpenShift 事例セミナーシリーズ 第6回 お客様のコンテナ導入への課題を解決する実践プログラム”Container Adoption Journey”」にてご紹介させていただきました。現在、オンデマンドで公開中ですのでご興味がある方は是非ご覧いただければと思います。
ちなみに、こちらは前撮り風景です^^
