データミドルプラットフォームの運用（データミドルプラットフォームに関する3つの質問：それは何なのか？どうやって行うのか？なぜ行うのか？）

データ センターに関する 3 つの質問: データ センターとは何ですか?どうやってやるんですか？なぜそうするのですか?

アリババが「ビッグミドルプラットフォーム、スモールフロントエンド」というコンセプトを提唱して以来、近年、データミドルプラットフォームという概念が普及してきました。インターネット大手各社は独自のデータミドルプラットフォームを構築しています。企業がこれほど注目するデータミドルプラットフォームの魅力とは？この記事では、データ ミドル プラットフォームとは何か、データ ミドル プラットフォームを構築する方法、そしてデータ ミドル プラットフォームを構築する必要がある理由という 3 つの側面から、この質問に答えます。

多くの人が、データ ミドル プラットフォームとは一体何なのかと尋ねるでしょう。

簡単に言えば、データミドルプラットフォームとは、企業のビジネスをデータレベルで支援し、意思決定を行うツールです。

過去には、データは表示されるだけで保存されないことが多かった。徐々に、人々はいつでもどこでもデータを見つける必要があり、データを保存するという概念が広く認識されるようになりました。その後、人々は徐々にデータ思考を発達させ、データを見て運用戦略を策定できることを発見しました。インターネット時代が爆発的な成長期に入ると、大量のデータが生成され、人々は意思決定の基礎としてデータマイニングを通じて大量の外部データを収集しました。

今日、インターネットは比較的成熟した段階に入りました。大企業は独自のデータ プラットフォームを構築し、膨大な量のデータを自社の資産として扱っています。また、データ プラットフォームを使用してデータを統合し、インテリジェントに分析して意思決定を促進することにも長けています。

データ ミドル プラットフォームには、データ ウェアハウスが含まれます。多くの人が、データ ウェアハウス? と考えています。それは単なるデータベース、つまりデータを保存するものではないでしょうか?実のところ、これはあまり正しい理解ではありません。では、この2つの違いは何でしょうか?

データ ウェアハウスは主に収集されたデータを分析および処理します。

データベースは主にトランザクション処理を目的としています。

データ ウェアハウスは主にリソース取得方法の最適化に重点を置いています。これは、ビジネス担当者や運用担当者はデータ取得に対する需要が非常に高く、毎日大量のデータが呼び出され、取得され、処理されることが多いためです。

データベースは、過度なデータ更新やトランザクションがデータベースの効率や安定性に影響を与えないように、追加、削除、変更、チェックなどの機能を最適化することに主に重点を置いています。

データ ウェアハウスでは、多くの場合、データが時間別に整理されます。たとえば、電子商取引の注文の場合、データ ウェアハウスはデータ分析テーブルを「1 時間の注文」、「1 日の注文」、「1 か月の注文」に整理して、ビジネス担当者が分析を取得しやすくします。

データベースは、インデックスとエンティティ コンテンツによってデータを整理します。たとえば、「デジタル製品の注文」、「生鮮食品の注文」、「衣料品の注文」など、さまざまなデータ テーブルを整理します。

データ ウェアハウスは、より頻繁に繰り返されるタイプのデータを使用して製品全体の運用傾向を分析し、次の運用上の決定の基礎を提供することを目的としているため、多くの場合、非常に冗長化されています。

ただし、データベースは冗長性が低い場合が多く、データベースの全体的なパフォーマンス効率に影響を与える大量の重複データを保存したくない場合があります。

そうは言っても、データ ミドル プラットフォームについては、おそらく予備的な理解があるでしょう。次に、自社に最適なデータミドルプラットフォームを構築する方法を見ていきましょう。

なぜそれがあなたにとって「最も適した」データミドルプラットフォームだと言えるのでしょうか?

データ ミドル プラットフォームは、機能とロジックの両面で非常に複雑であり、多くのフィールドとディメンションが関係します。では、最適なデータ ミドル プラットフォームを構築するにはどうすればよいでしょうか?このように考えてみましょう:

まずは自社のビジネスを踏まえて、どのようなデータが必要なのかを分析する必要があります。次に例を示します。

（１）電子商取引事業

電子商取引では、注文、製品、支払いなどのデータがなければ成り立ちません。注文件数については、時間別/日別/週別/月別注文件数、一人当たり注文件数、男性/女性ユーザー別注文件数、衣料品/デジタル製品別注文件数、リピート注文者数、注文売上、注文完了率、注文返品率などの項目に細分化して統計を取ることができます。

商品であれば、商品種別の取引数、商品のクリック率、商品レビュー数などが該当します。

支払いであれば、支払い成功率/失敗率、支払い回数、支払いチャネル、支払い割引利用率などが関係します。

（２）生放送事業

ライブ放送事業の場合、中核的な役割はアンカーとユーザーに分けられ、ライブ放送プラットフォーム全体はこれら 2 つの中核的な役割を中心に設計されています。

簡単に言えば、ライブストリーミングは、アンカーとユーザーの間で情報を交換するプロセスです。アンカーがコンテンツを提供し、ユーザーがコンテンツを消費してフィードバックを提供します（箇条書きのコメントを送ったり、ギフトを贈るなど。もちろん、ユーザーは何もしないこともできますが、アンカーの人気度や視聴者数を提供することもできます）。

ライブ放送のプロセス全体は、次のように分析できます。アンカーがライブ放送ルームを開く - ユーザーが推奨/サブスクリプションリマインダー/検索/ホームページ推奨などを通じてライブ放送ルームに入る - アンカーが情報を交換し、ユーザーと対話する - ユーザーがライブ放送ルームから退出する/アンカーが放送を終了する - ライブ放送プロセスが終了する。

そして、この簡単なプロセスから、放送後1分/1時間以内の視聴者数、メッセージプッシュ/サブスクリプション/ホームページ推奨のクリック率、検索数、集中砲火送信の数/率、ギフトの種類/数量、ライブ放送を1/5/10分間視聴したユーザーの数、さまざまな維持率など、多くのデータ指標を掘り出すことができます。データ指標が多すぎるため、上記のデータをとりあえずリストします。

（３）旅行業

旅行ビジネスについても、ビジネス プロセスに基づいて分析します。ユーザーが注文を送信 - ドライバーが注文を承諾 - ユーザーが車に乗り、ドライバーが確認、注文が開始 - 目的地に到着、ドライバーが確認、ユーザーが車から降りる - ユーザーが支払い (評価するかどうかを決定) - 注文プロセスが終了。

このプロセスに従って、特定のエリアで 1 時間以内に開始された注文の数、ドライバーが 1 日に受け取った注文の数、平均注文額、注文キャンセルの数/率、注文のキロメートル数、特定のエリアでの注文の平均応答時間、注文の肯定的/否定的なレビューの割合などのデータ指標を継続的に調査できます。

そのため、どのようなデータが必要なのかを分析するためには、実際に自社の業務プロセスから各指標データを段階的に分解していく必要があります。

（１）ニーズを明確にする

必要なデータが明確になったら、ビジネスおよび運用担当者と、必要なデータの種類、データの組み合わせ方法、データの提示方法、データのエクスポートがサポートされているかどうかなどについてコミュニケーションを取ることができます。これらすべてにおいて、製品マネージャーはビジネス側と詳細にコミュニケーションを取り、すべての要件を明確にする必要がありますが、これは事前の作業準備の良いスタートと言えます。

（２）プロトタイプの設計

要件が明確になったら、プロトタイプの作成を開始できます。プロトタイプには、データの視覚化をより明確にする方法など、設計の詳細が含まれます。業務担当者が簡単に始められるように、操作をシンプルにするにはどうすればよいでしょうか。

したがって、設計プロセス中は、開発者とのコミュニケーションを維持するだけでなく、ビジネス担当者との一定レベルの連絡も維持して、プロトタイプがうまく設計されたものの、ビジネス担当者が満足せず、大幅な変更が必要になることを防ぐ必要があります。

（３）需要評価と開発進捗のフォローアップ

プロトタイプが設計され、要件ドキュメントが作成された後、要件評価を実行できます。この段階で実装が難しい機能がある場合は、製品と開発が協力して、同じ問題を解決するために設計方法をどのように変更するかを検討する必要があります。

次に、要件をスケジュールし、各タイムノードを大まかに決定するタスクがあり、プロダクトマネージャーは開発の進捗状況を常に追跡します。

（4）開発完了、厳密なテスト

中間プラットフォームは C エンドユーザー向けではないので、これほど厳密なテストは必要ないと思われるかもしれません。しかし、それはまさに、ミドルプラットフォームが C エンドユーザー向けではなく、ビジネス担当者向けであるからです。運用上の意思決定に影響を与える重大なデータ漏洩が発生した場合、ビジネスへの影響も非常に深刻になります。そのため、厳格なテストが不可欠です。

（５）問題の解決とフォローアップを成功させる

テストが終わると、ようやくオンラインになります。しかし、ハイライトはまだ始まったばかりです。このとき、中間プラットフォームを使用した後、ビジネス側では、以前のテストでは検出できなかったさまざまなバグが発生することがわかります。さらに、機能のさまざまな不便さについて不満を言ったり、他の要件を提示したりします...

ミドルプラットフォームのプロダクトマネージャーとして、現時点では非常にストレスを感じるかもしれませんが、私たちがフォローアップを続け、プロジェクトの進行を合理的に調整し、ニーズを解決している限り、ビジネス同僚が故意に物事を困難にすることはないと思います。

調査によると、市場には実際に「Sensor Data」「BDP」「Fanruan」など、企業が購入して利用できるサードパーティ製のインテリジェントデータプラットフォームが多数存在しています。それは既製品を持っているのと同じです。なぜ自分で開発する必要があるのでしょうか?

おそらく次のような理由が考えられます:

大企業では膨大な量のデータを保有しており、その中には企業秘密と呼ばれる、外部に漏らすことのできない極めて商業価値の高いデータも数多く存在します。そのため、自社で開発したプラットフォームであれば、ある程度のセキュリティは保証できます。

データは企業、特に大企業にとって資産です。データは運用上の意思決定の基礎となります。競合他社がデータを把握し、相手の次の運用戦略を事前に予測した場合、ある重要なノードでの競争に敗れた場合、企業は大きな損失を被ることになります。

サードパーティのデータ プラットフォームでは、支払った価格に基づいてサービスの品質が差別化されることがよくあります。より多くの、より良いサービスを享受したい場合は、より多くの料金を支払う必要があります。カスタマイズされたソリューションが必要な場合、コストはさらに高くなります。

独自のプラットフォームを構築すれば、最初にどの機能を開発するか、どのくらいのリソースを必要とするかを決めることができ、コストをある程度コントロールできます。同時に、後から機能を拡張するとより便利になります。

ユーザーのニーズは多岐にわたるため、ビジネス担当者が提起するニーズには個別の特徴があることがよくあります。例えば、ニーズはレポートの形で提示され、レポートはさまざまな指標で構成されています。指標間には多対多の関係があり、指標は相互に関連しています。このような多様な指標はサードパーティのプラットフォームでは満たすことができないため、自社で構築したプラットフォームがその役割を反映することができます。

インターネットの恩恵が徐々に薄れていく中で、データをどのように活用してインテリジェントな業務を行うかが、あらゆる企業にとって重要な課題となるでしょう。オペレーターの能力も重要ですが、中間プラットフォームが優れていると、操作がスムーズになります。

この記事はもともと @Silence によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0ライセンスに基づいてUnsplashから引用しています