データ活用の定着化に向けた問題
坪内進史氏：最後は事例③というところで、システムに寄った、少しディープな話に入ってしまうので、もしかしたら振り落としてしまう人がいるかもしれないですが、ご了承いただければと思います。
データ活用文化を組織に定着化させたいというところで、まず課題感として、おそらくツールを周りの人によく使わせるみたいな立場の方は「そうだよね」となってもらえるかと思うんですが、組織によってITのリテラシーやドメインの知識量。「ドメインエキスパート」とよく言ったりするんですが、お客さまのビジネスの用語やデータに対して明るい人がいたりするんですが、ドメインの知識量が部署や人によってぜんぜん異なってくるという状況があるかと思います。
これによって、例えばこういった状態が起きたりします。「データの分析ツールは、SQLベースのものを提供します」と言った際に、マーケティング部門の方で「正直SQLはわからない」と。わかる方はいるとは思うんですが、「正直ぜんぜんわからない」「正直、ノーコードツールじゃないと困ります」とか。
あとは、それを扱う上でのデータカタログみたいなものも、「英語で書かれていて、何が書かれているかぜんぜんわかりません。もっと充実させてほしいです」みたいなフィードバック、意見をいただいたりすることもあります。
一方で、データサイエンティストだったりデータアナリストみたいな、日頃からこういったところに慣れている専門性をお持ちの方は、SQLも当然得意だし、自由度が低いツールよりもこっちのほうが良いようなケースがあったります。
例えば、データサイエンティストの方で、Pythonなどを親しまれている中で、その方に仮に「ノーコードツールでこれを分析してください」と言ったとします。
そのノーコードツールが例えば「Pandas」とか（のような）、ライブラリがぜんぜん入れられていないようなことを言ったら「俺に何をしろと言うんだ？」みたいな（笑）。この方にとってはまったく使えないただのツールのようなものを提供してしまっていることになります。
（コメントを見ながら）すごくリアクションが来ていますね（笑）。実際にあった話なので。
データカタログも、日頃からデータを扱われている方は、正直ビジネス用語との紐づけみたいなことも頭に入っているので、「データカタログを参照するためには最低限あれば特に支障ないです」みたいな方もいるかなと思います。
ITリテラシーが両極端な方がいる組織に対して何を提供したらいいのか
こういった両極端な方に対して何を提供していったらいいのかということが最後の事例となります。先ほどは分析ツールの話でしたが、もうちょっとわかりやすいかなと思ったので、こちらをピックアップします。
集めてきたデータレイクの生データ、そこから意味のあるというか、分析用途に特化したデータマートを作るところで、データのその加工処理みたいなものを実装していくとか、作っていくみたいなシーンがあるかなと思います。
これで実際の事例を紹介したいと思います。AWSに寄った話が多いので、「ちょっとわからないよ」という方はぜひ我々にお問い合わせしていただいて、ソリューションの説明と一緒にできればと思います（笑）。
AWS Glueで実現できること
今回の題材になるのが「Glue」というところで、AWSをよく使っているみなさまだと、データ加工で非常によく使われているところかなと思います。Python Shell、Sparkみたいなところで、特に大規模データを扱って並列分散処理をさせるSparkをベースとしたサーバーレスのデータ加工、ETLツール。それ以外にも機能はいろいろあるんですが、それらが主に使われるポイントかなと思っています。
こういったツールを基に、例えば基本的にはPythonのコードを書いてとかPySparkのコードを書いて、データの加工処理を作っていくというところになります。
すみません、スライドの左端は些末な話なので忘れていただいて、真ん中だけを見てもらえればと思います。
データエンジニアみたいな方はおそらくプログラミング前提のやり方がすごく性に合っているし、実際に自分の好きなライブラリを使って開発したいみたいなシーンもあると思うので、そういった使い方があります。
一方で、先ほどのマーケティング担当者みたいな分析者の方から、「実際に自分たちにとって有効なデータを自分たちで加工してマートを作りたいんだ」みたいな要望をいただいたりもします。よくある話で、実際これに対応していかなければいけないところはあるかと思います。
例えばAWSのサービス、私はAWSの回し者じゃないんですが、Glueはデータエンジニアの方にとっても使いやすいです。また、それを拡張したGUIツールみたいなものも提供されていたりするので、マーケティング担当者のような分析者の方にもGlueを使って、例えばPythonのコードを生成していただくみたいな、そういったやり方を提供しています。
Glueの中でも「DataBrew」や「Glue Studio」という、ノーコードだったり、場合によってはローコードを使ってデータの加工をするような機能があります。使い分けとしては、主にデータクリーニングだったり、データを組み合わせて統合したり、マートを作成するんだったらGlue Studioが近かったりするんですが、こういったものを提供しています。
DataBrewでいうとデータの品質チェックみたいなものもできたりするので、データの状態の可視化や統計情報の取得みたいなものをGUIツールで行った上で、よくあるデータのクリーニング用途、例えば外れ値に対するデータの加工処理なんかもポチポチである程度できたりします。
ここはプログラムの知識がなくても、統計知識があれば、自分に必要なデータをセットして用意するようなことができたりします。
ITリテラシーの差を吸収できるツール選定は組織にとっては有用である
今のはあくまでも一例で、「こういったツールを使ってください」という話ではないです。ここで押さえてほしいのは、プログラムとか開発とかの専門性みたいなところが非常に重要になってきます。
なので、手軽さというかたちで表現していますが、専門性が不要なものというところと、あとはその汎用性みたいなところで、特殊な加工要件に対応可能になるようなところは、トレードオフになっているんだなと。
ただポイントになるのは、ITリテラシーの差異を吸収できるツール選定を、データ活用基盤を構築する人は常に意識してユーザーさまに提供していくこと。これらができるようなツールを選定していくのが組織にとって非常に有用であるし、ビジネスメリットにつながっていくんだというところを認識していただければと思っています。
活用される基盤を作るために意識したいことのまとめ
最後にまとめです。本日紹介したもののダイジェストになりますが、まずはデータ活用基盤を実際に活用していただくために「活用される基盤を作るには」というところで、その周りにある組織の課題にぜひ着目してほしいなということをお伝えしました。
その前提で例えば意思決定ができない経営層だったり、意思決定ができないところを緩和していくために、段階的な投資判断を可能にするようなデータ基盤の作り方をするというのは、比較的合理性のある進め方なんだなというところもお伝えしました。
それ以外に、専門性を提供してユースケースの策定を支援していくところも、データ活用を促していくために、組織のビジネスを盛り上げていくために、非常に必要なもので、みなさまの専門性をぜひ提供していく。そういう場を逆に作っていくのが望ましいというところをお伝えいたしました。
最後になりますが、組織内でTリテラシーがかなり違ってきているので、そういった差異を理解して吸収していくようなツール類だったり、この観点を持ってデータ活用基盤の構築に臨んでいただくのが非常に重要であるというところもお伝えいたしました。
とりとめのない話も多かったかなと思いますが、もしこれがみなさまの今後の業務に少しでもなにかしら活かしていただけるようであれば幸いです。
私からのご説明は以上といたします。みなさま、ご清聴いただき、ありがとうございました。
