コンテンツに移動
データ分析

データ ウェアハウスの移行に関するヒント: 準備と発見

2020年9月29日
Google Cloud Japan Team

※この投稿は米国時間 2020 年 9 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

データ ウェアハウスは、組織の意思決定プロセスの中核を担う存在です。サイロ化された従来型データ ウェアハウスのアプローチから、絶えず変化する要件に応えるための高度な機能を備えた最新のデータ ウェアハウスに移行しようとする企業が多い理由も、その点にあります。Google Cloud は、HSBC に対する作業支援を含め、数々のデータ ウェアハウス移行プロジェクトでお客様と連携しています。同社の事例では、BigQuery への移行により、600 種を超えるレポートおよび複数の関連アプリケーションとデータ パイプラインが削減されました。また、Google Cloud は移行フレームワークの構築にも携わっています。焦点となるのは、移行の各フェーズに向けて準備を整えることにより、リスクを緩和し、明確なビジネスケースを事前に定義して、社内の関係者から支援を得られるようにするための方策です。

Google はデータ管理の成熟度モデルを提供していますが、特に移行の準備方法に関しては、今なおご質問が寄せられています。今回の記事では、本番環境のデータ ウェアハウスをモダナイズした場合に表れる影響や、最新のデータ ウェアハウスへの移行について準備と計画を進めるうえで適切な手立てなど、準備と発見という初期のフェーズで浮かび上がる、いくつかの重要な事項について検討します。

準備のフェーズへの取り組み

企業のデータ ウェアハウスはユースケースが多岐にわたり、多くの関係者が存在することから、主な関係者をプロセスの早期に洗い出して関与を促し、確実に戦略目標に沿って取り組みを進めることが重要です。関係者は、ギャップの特定や、考え得るユースケースと要件に関する知見の獲得についても助力となります。これらの情報は、影響が最も大きいユースケースを優先事項に設定し、付随するリスクを見極めるうえで有用です。次に、これらの決定事項について承認を受け、ビジネス指標との整合性のあるものにします。この過程は、通常、主に 3 つの構成要素を中心として進めます。

関係者: 移行に関して意見を募るとともに、積極的に取り組む姿勢を促すため、まずはリーダー陣とビジネス オーナーとの方針のすり合わせを行います。次に、プロジェクト チームとエンドユーザーのスキルを調査します。ワークショップ、ハッカソン、ブレインストーミングのセッションを開催して、チーム内の各職能グループを洗い出し、面談を実施することをおすすめします。課題に関する意見交換では、以下のような成功基準と KPI を設定して、オーナーの承認を得る方法を必ず検討してください。

  • 時間の節約

  • 新規レポート作成の所要時間

  • レポート利用率向上

  • イノベーションを通じて得られた人材


テクノロジー: 現在の技術環境を理解し、現存するソリューションを分類して個別のワークロードを識別することにより、上流と下流のアプリケーションをより容易に分離して、特定のユースケースとの依存関係をさらに深く掘り下げることができます。たとえば、さまざまなユースケースや移行元となるシステムに基づいて、ETL のアプリケーションやパイプラインを結合または分離すると、潜在的なリスクを低減できるとともに作業の範囲も縮小可能です。同様に、それらを上流のアプリケーションと結び付けて、依存関係のあるアプリケーションと関連データ パイプラインを同時に移行するような移行計画も考えられます。

最新の移行テクノロジーを理解することに加え、移行の対象を明確に把握することも重要です。これには、移行の過程で、データ速度、データ リージョン、ライセンスに関する情報とともに適切なデータソースを特定することのほか、レポート要件が存在し、モダナイゼーションの目標が設定されているビジネス インテリジェンス(BI)システムを洗い出すことも含まれます。たとえば、売上高に関する日次のレポートは、必要に応じてリアルタイムのダッシュボードに移行することをおすすめします。また、上流や下流のアプリケーションをクラウドネイティブのアプリケーションに置き換えて、以下の KPI を基準として運用できるようにするかどうかも決定します。

  • 新しいソリューションの TCO と機能面上のメリットの対比

  • パフォーマンスの改善とスケーラビリティ

  • 管理機能の低下

  • ロックインのリスクとオープンソースの利用の対比


プロセス: プロセスの選択肢について意見を交換すると、移行対象のコンポーネントを分割できるかどうかに加え、既存のコンポーネントとデータアクセス上およびガバナンス上の要件との依存関係も明確化できます。たとえば、移行の期限を定める前に、ライセンスの有効期限との依存関係を評価します。移行を進める中で効果的な判断を下し、回り道しない最大限の進捗を確保するには、プロセスを確立する必要があります。そのためには次のような KPI を活用します。

  • データの漏洩と不正使用が生じるリスク

  • チャネルごとの収益の拡大

  • リリースされる新サービスとリリース費用の対比

  • 機械学習に基づく分析の採用


導入しようとするプロセスを深く理解しておくと、成長に向けた新たな機会が拓かれます。たとえば、ある著名な e コマース小売業者は、商品とサービスのパーソナライズを進めたいと考えていました。既存のデータ ウェアハウス環境は予測分析の機能を備えていなかったため、新たなテクノロジーに資金を投じることが必要でした。BigQuery ML を採用したところ、アジリティを得たうえで予測分析を適用し、ライフタイム バリューの向上、マーケティング投資の最適化、顧客満足度の改善、市場シェアの拡大を実現できました。

発見のフェーズの開始

発見のプロセスで主に着目するのは、ビジネス要件と技術情報という 2 つの領域です。

1. ビジネス要件の把握

データ ウェアハウスの移行に関する発見のプロセスは、ビジネス要件を把握することが出発点になります。通例、数多くのビジネス推進要因が関係します。レガシー システムを置き換える場合、チームの新たなスキルセットに関する要件から、持続的に発生するライセンス費用と運用費用の管理に至るまで、多くの側面が影響を受けます。たとえば、現行のシステムをアップグレードする場合、追加ライセンスの購入や、自社のデータ アナリスト全員の再トレーニングが必要になる場合があります。これらの要件を数値化して費用と関連付けることにより、移行のプロセスを実際的かつ公正な形で評価できます。

また一方で、現在のソリューションに潜む不足部分を洗い出し、実現され得る改善のメリットを提案して検証することにより、付加的な価値を得られます。そのためには、既存のツールを新たなソリューションで拡張、増強するためのアプローチを定義します。たとえば、小売業者の場合、リアルタイムのレポートを新たに提供することができれば、予測が大幅に改善され、商品の陳列漏れが削減されることから収益が増大します。

この小売業者は、商品の陳列漏れによる売上の喪失が 100 万ドル単位にのぼっていたことに気付きました。そこで、必要な在庫数量を正確に予測するための効果的なソリューションを見出したいと考えました。当時の従来型データ ウェアハウスはパフォーマンスの限界に達していたため、膨大な量のデータ ワークロードを迅速に分析できる BigQuery などのクラウド サービスを検討しました。移行の結果、リアルタイムでテラバイト規模のデータをストリーミングし、陳列用の在庫数量を迅速に最適化して費用を削減するとともに、以下のようなメリットを得ることが可能になりました。

  • 陳列漏れの削減によって段階的に収益を拡大

  • 以前の予測モデルと比較して 2 倍の精度を実現


従来、解決が困難と見なされていたビジネス課題も、新たなテクノロジーで改めて調査すると、新たなチャンスとして捉えることが可能になります。たとえば、よりきめ細かいデータを保存して処理する機能を利用できれば、的をいっそう絞り込んだ解決策を見出すための一助になり得ます。小売業であれば、季節性を調査して、クリスマスが月曜日の場合とその他の曜日の場合の顧客行動を評価することが考えられます。この評価を実施するには、何年分もの大量のデータを保存し、分析する機能が必要不可欠です。

最後に重要な点として、テクノロジーのモダナイゼーション プロジェクトでは、ユーザーに対する教育が鍵になります。ユーザーに対する教育は、前述の学習プログラムのほか、自習用の e ラーニング プランを定めることでも実践できます。また、ユーザーが実地で体験する時間や、新システムを使用し始めて試行錯誤する中で使用方法を習得できる時間も必要です。ユーザー間の格差を埋めるための後ろ盾として、外部の専門パートナーと内部のエキスパートも早い段階で洗い出しておきます。

2. 技術情報の収集

実行戦略を特定するには、移行プロセスの焦点がソリューション レイヤにあるのか、エンドツーエンドのリフト&シフト アプローチにあるのかを明確にする必要があります。この判断の目安として、以下の数項目のポイントを確認してください。

  • 上流と下流のアプリケーションのデータソースを特定する

  • ユースケースに適したデータセット、テーブル、スキーマを特定する

  • ETL / ELT のツールとフレームワークの概略をつかむ

  • データ品質とデータ ガバナンスに対処するためのソリューションを定義する

  • Identity and Access Management(IAM)用のソリューションを特定する

  • BI ツールとレポート生成ツールの概略をつかむ


さらに、購入または構築について判断を下す前に、いくつかの機能面の要件を特定することが重要です。初期設定の状態で要件を満たすソリューションが市場に存在しているでしょうか。あるいは、洗い出された課題に対処するにはカスタム開発のソリューションが必要でしょうか。アプローチを決定する前に、このプロジェクトがビジネスの中核を担い、また付加価値をもたらすものであるか否かについて正しく理解していることを確認してください。

準備と発見のフェーズを完了すると、クラウド データ ウェアハウスへの移行によってどのコンポーネントの置き換えまたはリファクタリングを実施するのかに関して、確かな指針を得られます。

BigQuery の詳細については、Google のウェブサイトをご覧ください。


この記事に協力してくれた Ksenia Nekrasova に感謝します。

-データ分析担当 EMEA 地域ソリューション リード Usman Ali

-データ分析担当 EMEA 地域ソリューション リード Firat Tekiner

投稿先