AWSにおけるビッグデータ分析基盤の導入(1) ～ビジネス要件定義とデータを起点とするクラウドEAの策定

クラウド推進事業部/オペレーションズ本部 シニア・マネジャーの青柳雅之と申します。私はAWSやAzure、GCPといった主要なパブリッククラウドを使用したIT Modernizationを担当しています。

今回から始まる一連のブログでは、AWSのサービスを利用したビッグデータ分析基盤の構築について記載していきます。ビジネス要件や可視化要件を決めずに「とりあえずPoC環境を入れてみましょう」「各サービスの技術をディスカッションしましょう」はビジネス価値を産まないビッグデータ分析基盤を構築してしまう可能性があり大変危険です。今回はその考えの背景を説明します。

最初に決めるのはビジネス要件
ビッグデータ分析基盤構築の話が組織内で出てくる場合、様々なきっかけがあると思います。

• 現行でオンプレミスのビッグデータ分析基盤が存在するが、クラウドのほうがコスト面で優れていそうだから移行する
• 会社に大量のデータがあるがビジネスに活用できないかといった課題感等から、ビッグデータ分析基盤を導入しようという意識

ビッグデータ分析基盤の構築にも工数がかかりますので、最終的には、将来構築する分析や予測の仕組みが、確実にビジネス価値を生み出しているかどうかを検討する必要があります。この検討の初期段階では、他社事例を理解した後に、自社ではどのような取り組みができるかをワークショップで議論することが多いかもしれません。AWSでは様々な事例を公開していますので、参考にできます。

以下はAWSが公開しているビッグデータ分析の事例です。

データレイクと分析
※各社のロゴをクリックすると事例を紹介するYouTubeの動画や関連サイトにリダイレクト
ビッグデータのお客様成功事例
Amazon Redshift お客様の成功事例
Amazon Redshift 事例祭り(DWHマイグレーション)
※各社の資料もダウンロード可能

ビッグデータ分析基盤のビジネス要件と位置づけを明確にする - IT戦略マップ
ビジネス要件の他に、合わせて組織内での位置づけを明確にする方法として、IT戦略マップを利用することができます。

IT戦略マップでは、ビッグデータに関わると思われるステークホルダーが所属する部署、それらの上位の部署のKPIを関連付けて整理します。異なるKPIを持つ部署間の施策が結び付いて全社の目標を実現することが可視化されます。下の例では末端のビッグデータ分析基盤に関わる施策（ビジネス要件）が、組織の経営目標や各階層の目標まで結びついていることを示しています。ビッグデータに関する施策とそれが実現する部署のKPIがビジネス要件ともいえるでしょう。

部署の目標や施策間を結び付けるIT戦略マップの例

この作業は従来のBaransed Score Cardの考えに基づいており、相互のKPIが利益相反している部署間でも調整が行われます。また、各部署のKPIは通常定義されていますが、部署間の話し合いの中で新たにKPIを作る場合もあります。その場合は現場をよく知るメンバーがボトムアップ的に施策やKPIのアイデアを出していき、それらを上位や他の部署のKPIと結び付けていきます。こういった作業を通じて部署間のコミュニケーションが加速され、組織内でビッグデータ分析基盤構築プロジェクトの認知も上がり、位置づけも明確になります。

このビジネス要件をクラウドを利用して実現するための施策 - クラウドEA
IT戦略マップで、ビッグデータ分析基盤の位置づけやビジネス要件が見えてきた後に、それを実現するための施策を検討します。今回のビッグデータ分析基盤はクラウドが前提になりますので、単純に構築をするという以外の様々な施策が必要となります。そのためにクラウドEAの考えを利用します。

クラウドEAの概略については、クラウドCoEとクラウドEAで説明しました。EAの定義には世の中に様々なものがありますが、ここでは「ビジネスの目標を満たすためにクラウドを最大限に生かすアーキテクチャ、プロセス、組織形態の集合」と定義しています。このクラウドEAの考えを、ビッグデータ分析基盤の組織における重要性や位置づけを明確に認識するために使います。

クラウドを導入するための施策案や課題は多数出るも、優先順位付けの合意形成が難しい場合があります。このようなところで悩むことに時間を使うのであれば、エンドユーザーが存在してビジネス要件が確実に出てくる、ビッグデータ分析基盤導入のような施策を起点としてもよいのではないでしょうか。目の前の具体的な施策により、関連する施策がすべて引っ張られ、施策内の優先順位も決まる可能性があります。

下図ではIT戦略マップで導出したビジネス要件を、クラウドEAで策定した各施策で実現することを示しています。

IT戦略マップとクラウドEAにおける施策の例

インフラ起点の施策ではクラウド移行を含むデジタルトランスフォーメーションの同意を得るのは難しい場合がある
HWのリプレース時期が来るからクラウドへの移行をしましょう、今の仕組みをサーバーレスアーキテクチャに変えませんか、コンテナを入れましょう、他の会社はすでに移行しています、と言われても、現状で大きな問題がない限り、わざわざ高い移行コストを払ってクラウドに移行する必要性を感じないケースも多いでしょう（現行の運用コストが高かったとしても）。クラウドへの移行で、初期費用である移行コストは数年で回収できるという試算をしても、移行のために組織内の多くのステークホルダーが動員されますので、その調整にも見えないコストがかかります。そこで、今回のビッグデータ分析基盤導入のように、ビジネスの課題と直接結びついた施策からクラウド導入を検討してもよいかもしれません。IT戦略マップやクラウドEAは、そのような検討を後押しします。

可視化要件
ビジネス要件が決まれば、次に可視化要件を検討します。ビッグデータ分析基盤では、データがビッグデータ分析基盤に収集された時点から、ユーザーが使う可視化ツールに表示されるまでの過程（データパイプライン）を、決められた時間の中で実現できるかがキーとなります。参考までにビッグデータ分析基盤を構成するAWSサービスを下図に示しますが、要件によってはAWS以外の他のサービスをデータパイプライン中の各プロセスで使用することもあります。

ビッグデータ分析基盤を構成するAWSサービスの例

データパイプラインにおける可視化プロセスの要件は他のプロセスに先駆けて最初に決めます。それはデータパイプラインに関わるステークホルダーの中で、基本的には可視化のステークホルダーのみがエンドユーザーだからです。エンドユーザーから見た可視化要件が決まると、そのためのデータを決められた時間で準備するために、データパイプライン中の他のプロセスを構成する各サービスが持つべきアーキテクチャ機能要件、データソースが決まってきます。
そのため、ビジネス要件・可視化要件を最初に決めなくてはならないものと考えます。

ビジネス要件や可視化要件を決めずに「とりあえずPoC環境を入れてみましょう」「各サービスの技術をディスカッションしましょう」は危険ではないでしょうか。

可視化要件の確認

可視化要件項目の例を以下に示します。

可視化要件項目の例

スコープを明確にするためにプロジェクト初期に収集する情報
単に分析基盤を構築するコストだけではなく、必要なデータを収集、処理するコストや、データを将来にわたって維持管理するコストも大きいため、それらも当初から併せて考えなければなりません。特にデータの維持管理については、それを行うためのステークホルダーの協力が必要であり、一定の工数を割かなければなりません。この負荷が重い場合は、その部分に依存する可視化を断念しなければならない可能性があります。ステークホルダーがデータパイプラインのための負荷を負ってもらえるのか、という社内調整が必要です。この表を使って、実際にステークホルダーが割かなければならない時間を見積もると負荷が明確になるので、調整のための良い材料になるでしょう。この中にはアーキテクチャが決まらなければ決められないものもあるので、継続的に確認と調整をしていきます。

分析対象のデータソース（関連システム）、
それらを管理するステークホルダーの確認事項

特に収集と保存のプロセスは他部署のステークホルダーがかかわることが多いため、この段階では、特にこれらの情報を収集することに注力します。プロジェクト後半になっても必要なデータや関連システム、それを管理するステークホルダーとの作業調整がついていないと、プロジェクトの成功は難しくなります。

次回以降のブログからは、ビッグデータ分析基盤のアーキテクチャや構成要素、様々な要件を検討、定義するプロセスを見ていきます。