- 目次
データ分析は「目的」から「手段」へ
渋谷ここ数年でデータ分析を取り巻く環境は大きく変わりました。以前はとにかくデータを蓄積して分析したい、ということが目的化してしまっているケースもありました。でも4,5年くらい前からでしょうか、「データを分析するだけではなかなか次に繋がらない」と明確に気付かれ始めて、売上等の事業的な成果に結びつけられるのかが改めて問われるようになってきたように思います。
私達、テクノロジーコンサルティング事業本部でも最近は「データ“分析”基盤」という言い方はあえてせず「データ“活用”基盤」や「データ基盤」といった言葉を使うようになってきています。
松家そうですね。渋谷さんの言う通り、そのあたりからデータ分析を“手段”としてとらえるお客様が増えてきたように感じます。データ分析の目的は分析を通して、得られた示唆をもとに、意思決定や問題解決に役立てビジネスを発展させていくことだと考えているので、その意味では“データドリブン”というバズワードがようやく本来の意味で必要とされる時代になったと言えるかもしれません。
誰でもいつでも社内データを活用できる「データ民主化」
渋谷データ分析の重心が事業的な成果に置かれるようになったことは、実は組織論にも関わってきますよね。一昔前のデータ分析チームは“出島”的に、事業部門とは切り離された場所にあり、中途採用のちょっと尖った人なんかがそこに集められていました。
でも、いざ専門家集団がデータ分析を行っても、PoC（実証実験）どまりでなかなか本業での成果が生まれない。結局、事業部門がコミットした動きでなければ、事業に直結した動きはできないわけです。
しかし、事業部門がデータ活用に乗り出したとして、そのビジネス感覚と従来のデータ分析基盤の運用感覚には大きな乖離があったのも事実です。
松家“あるある”ですね。事業部門から「こんな分析をするためのデータ・ツール・基盤を！」という要望が来たとしても、それに応えるエンジニアとしてはツール選定から始まり、基盤構築／データ連携／分析画面の開発に至るまで検討に検討を重ねた上で提供することになるので、どうしても時間がかかってしまう。そして、提供までの間にビジネス状況が変わって、その分析テーマが陳腐化してしまい、結果的に大きな機会損失につながる…と。
渋谷互いの目線が違っているからこそ、どうしてもビジネスサイドとエンジニアサイドの間に溝が生まれてしまうわけですよね。特にスピード感については、技術的にもマインド的にも、なかなか従来のIT部門中心のエンジニアでは対応できなかった。
松家その一つの解として、課題意識を持つビジネスサイドの当事者が、自分でデータを探索・分析できる環境が必要になってくるのですよね。企業のデータに社内の誰でもアクセスできて分析するだけでなく、その結果を共有することで“データドリブン”な事業運営や経営ができるようにする。“データ民主化”が、徐々に求められ始めたわけです。
次のレベルのデータ民主化を目指すためのアーキテクチャとプロダクト
渋谷私たちは「きっとこれはデータ民主化につながるはずだ」と、ビッグデータを蓄積するデータレイクをなんとかやり繰りしようとしていました。HadoopやSparkを基盤としたデータレイクを用意して、「データスチュワード」という役割のエンジニアが適切にデータマネジメントをしていきながら、ビジネスサイドの要望に応えていくわけですが、これには多少無理があったように感じます。
松家そうですね。限界が来たなと思ったのは、データスチュワードにもうとんでもない数の要望が溜まっていったときですね。「この分析のためにこういうデータが欲しいんだけど」と言われても、そのデータがいったいどこにあるのか。どこにあるか特定できたとして、そもそも、そのデータをこの分析に使っていいのか。等さまざまな調整が生じているうちに、従来のデータ分析基盤と同じく求められるビジネスのスピード感から徐々にずれたものになってしまっていました。
この当時のデータ基盤は中央集権型。それを管理する特定の部署やロールに権限と業務が集中することで、ビジネスサイドとデータのハブになる役割を維持することが難しくなってしまいました。
渋谷データスチュワードが動けないなら、「じゃあもう自分たちでやるわ」なんて、闇分析基盤が出きてしまったりもしましたよね。
そういった状況が世界的に発生しているからこそ、ここ1,2年で非常に大きな注目を集めていると思っているのが非中央集権型の「データメッシュ（※1）」というアーキテクチャです。データメッシュは、ドメイン（事業領域）ごとにデータ管理の責務を持ち、データ基盤はその流通のための“ハブ”の役割を担う構造。
各ドメイン同士が網の目のように相互にデータをやり取りすることから「データメッシュ」と呼ばれますが、特に私はこのデータ基盤の部分として「Snowflake」が一つの大きな選択肢になるのではないかと考えています。
図1：データ分析の変遷
渋谷Snowflakeは「データクラウド」を標ぼうするクラウドデータプラットフォームです。元はクラウドネイティブなデータウェアハウスとして誕生しましたが、データ共有やマーケットプレイスの機能の提供を進化させ、現在ではその役割は単なるデータウェアハウスというより、データが繋がりあうネットワークのようなものとも言えます。
私は2019年頃Snowflakeのアーキテクチャに惚れ込み、そのときから「これはデータ民主化に必要不可欠なクラウドDWHになる」と思いました。「Tableau」と組み合わせて利用することで、データ活用の障壁はさらに下げられると思います。
松家TableauはセルフBI（ビジネスインテリジェンス）として、事業部門のユーザーを全員アナリストに変身させることができるような、データ民主化になくてはならないツールです。ユーザーはビジネス上の仮説に対して、データを組み合わせながら、データビジュアライゼーションを通して自ら検証していくことができます。その点、マーケットプレイスで必要な外部データを購入するなどして、様々なビッグデータを組み合わせながら柔軟にビジュアライゼーションできるデータのネットワークであるSnowflakeとの親和性は非常に高いと思います。
実際に社外のTableauコミュニティのユーザーも、Snowflakeにかなり関心を持ち始めている印象です。これまでデータエンジニアの領域であったSQLやDB/DWHの知識が取得することはアナリスト側からすると「難しすぎる」といった声が上がっていました。でも最近は「Snowflakeなら自分たちにも触れるかも」という空気になっている。両ツールの親和性が高いことに起因した、アナリストのデータエンジニアへの歩み寄りが始まりつつあるように思いますね。
渋谷データエンジニア側も単にデータベースの箱だけを用意して「さあ、お使いください」と言っても、誰も使ってくれません。データベース上でどのようにデータをモデリングし、どのようにそれをエンドユーザーに提供・改善しつづけるのか。そうしたことを意識しなくてはならない時代になってきていますね。
アナリストとデータエンジニアの垣根を越えて、ビジネスに寄り添う「アナリティクスエンジニア」
渋谷いままでの背景から、データ活用においてはアナリストとデータエンジニアの壁は取り払われるべきだと思います。その意味で私が最近気に入っているのは「アナリティクスエンジニア」という呼び方ですね。
Modern Data Stackの一つとして注目を集めているデータ変換／データモデリングツールの「dbt（Data Build Tool）」が提唱したロールで、アナリストとデータエンジニアの中間であり、架け橋とも言える役割です。
先日部署内でdbtの勉強会を開催したところ、データエンジニア側からもデータサイエンティストやアナリスト側からも大勢のエンジニアが集まり、大いに盛り上がりました。
図2：アナリティクスエンジニアとは
松家あの勉強会はみんな大興奮でしたね。（笑）アナリストもデータエンジニアも、同じ課題を抱えているんですよね。データ活用のプロセスが非効率になっていて、顧客に価値提供するまでのタイムラグが大きくなってしまっている。その意味では、エンジニアだけでなくビジネスサイドも結局は同じことを考えているんですよね。
渋谷エンジニアは、アナリティクスエンジニアのようにビジネスサイドに寄っていく必要があります。しかし日本の場合は、アナリティクスエンジニアの候補になるエンジニアの多くがSIer企業にいるのが実状です。そのため、ビジネスサイドで内製化を目指したとしても、現実的に人材確保できるかどうかは別の話になる。
でも、松家さんはそれこそ顧客企業にコンサルタントとして入り込んで、事業にコミットしてプロジェクトを進めているわけですよね？
松家はい。私たちはお客様の事業変革のパートナーとして、全力で、そしてどっぷりと事業部門へ漬かりながら、アナリストとデータエンジニアのハブとなって、お客様とともにデータ活用のその先のビジネスを作っていますね。
渋谷本当に伴走型ですよね。もはや「要件通りにできましたよ」みたいな関係性は今の時代にミスマッチ。テクノロジーコンサルティング事業本部では「デジタルサクセス®」を標榜していますが、その言葉の通り、お客様とがっちり手を組んでビジネスのプロセスを回していき、Win-Winな道を模索する。それがこれからは求められるんでしょうね。
松家NTTデータではもともと言われていたことではありますが、エンジニアがますます“御用聞き”じゃなくなってきているのだと思います。
データ民主化の最後の壁は「企業文化」
渋谷データ民主化にアナリティクスエンジニアのような存在が必要なのはもちろんですが、最終的には「文化」の問題が大きいと思います。なによりも「データ活用してみよう」と思える人が事業部門側にたくさんいることが大切です。それは「ポジションを作ったからそこでデータ活用の旗振り役をやってください」と言ってできるものではありません。
松家そうですね。何らかの成功体験を得なければ、やはりデータ活用に対するオーナーシップを持ちづらいと思います。テクノロジーコンサルティング事業本部では「デジタルサクセス®・アカデミー」（※2）といって、座学にとどまらない実践型の業界横断のプログラムも提供しています。これらを通して、ビジネスに直接関わる各自がオーナーシップを持ち「自分がデータでビジネスを変えてやる」みたいな心持ちが醸成されれば、我々も全力でサポートできます。
渋谷はい。データ活用の素地ができているお客様からはデータ活用に関する様々な課題・要望が途絶えませんし、解決手段となる新しいテクノロジーを示したら「これすごく良いね」「今まで困っていたことが解決できるかもしれない」など、良い反応も返ってくる。
松家その意味でいうと「Snowflake×Tableau」の組み合わせは多くのお客様が成功体験を感じやすいソリューションだと思います。一度でも使ってもらえればすぐにその魅力に気づくと思うし、それをきっかけにデータ活用の文化が広がっていくはずです。
それらの啓蒙活動やデータメッシュアーキテクチャの実装はもちろん、今後はお客様の特性や保有するデータを踏まえつつ、どのような基盤・モデリングにするべきか“Foresight”を見据えながらお客様と相対していくことが重要になると思います。NTTデータは、そうした支援ができる数少ない企業だと自負しています。
