データ分析実現までの課題

山本：まず1つ目は、データソースから分析ができるようになるまでの苦労についてです。藤原様、お願いいたします。

藤原：システムから出てくるログデータに関しての課題は少なかったです。ただ、人が作ったデータの送信にあたっては、必要データの所在を関係者に訊かなければならなかったり、中身の確認にかかる時間を読めなかったりしていました。各自がそれぞれの目的をもって作ったデータなのでもちろん価値はあるのですが、それらを価値のあるものとしていかに整備していくかが課題となっていました。

山本：人の手が加わることで独自のルールや扱い方が生まれ、必要なデータを探すのに時間を要していたことが悩みだったのですね。横河電機様の場合は膨大なプロジェクトが並行して進んでいるので、それがより顕著だったのではないでしょうか。また、必要なデータにたどり着いたあとも、クレンジングや加工にも課題があったとのことですが、実装を担当されていた桑田様から見ていかがでしょうか。

桑田：クレンジングではファイル形式によって使用ツールが異なることで、動かすまでに時間がかかったり、対応可能な人が限定されたりしたので、それも複雑化の要因だったと思っています。さらに、どんどん増えていくデータの処理に丸一日かかってしまうといった問題もありました。

藤原：いわゆる属人化ですね。特にExcelなどは退職した人がVBAを駆使して作ったものだと、かなり問題になりました。

データ基盤を導入

山本：そうした状況を解決するため、データのパイプライン構築・一元管理に取り組まれていたということですね。2つ目のテーマであるデータ基盤導入はマクニカがご支援した部分となりますので、ここは太田さんからご説明いただきます。

太田：こちらのスライドは、従来のデータ基盤とSaaS型データ基盤の違いを比較したものです。今回、横河電機様に導入していただいたのは後者となります。

まず、従来のデータ基盤では蓄積されるであろうデータ量を見積もり、それに耐えられるマシンのスペックや台数を算出し、構築計画を立てる必要があります。さらには情報システム部門などへの環境の申請払い出し・各種コンポーネントインストール・複数回にわたる接続テストなどを行わなければならず、実際にデータ基盤を使えるようになるまでには数週間を要していました。

一方、SaaS基盤の場合は非常にシンプルで、AWS上のクラウドに環境用作成用のユーザーと管理者権限を持つユーザーを用意し、その後はGUIの操作でワークスペースやコンピューティング環境の作成を行っていただきました。クラウドフォーメーションと言い、必要なリソースが自動で作成される仕組みが裏で稼働することで、このようなGUIの操作による構築が可能となります。

今回は弊社が手順書を提供し、それを元に横河電機様の担当者の方に構築を依頼したのですが、担当者の方がクラウドの知識もお持ちだったので非常にスムーズでした。構築自体は1日もあれば完了しますので、本来の目的であるデータパイプラインの構築と、その先の分析に注力できるようになります。

山本：横河電機様にはさまざまな課題がありましたが、実際にSaaS型基盤を導入してみて、どんな点が良かったですか。

桑田：必要なデータを探すのに時間がかかっていた問題が、基盤に搭載されているデータカタログ機能で改善されたり、それぞれ別の専用環境を構築しなければ使えないPythonとSQLが、単一のノートブックで両方とも使えるようになったりした点ですね。また、データの収集に関しては差分のみを自動的にロードしてその後の分析に活かせる、オートローダーという機能をご紹介いただきました。通常はPythonのプログラミングなどが必要な部分なので、それが簡単にできたことも非常に助かりました。

山本：基盤の導入によってカタログ化が進み、プロジェクトや個人単位で散らばっていたデータが共通言語化されることで、きれいな分析環境が整えられたのですね。私たちもお客様をご支援する立場として、嬉しく思います。

データ基盤を運用していくために

山本：導入したデータ基盤が真の価値を発揮するためには、その後の運用や分析の定着化が欠かせませんが、これに苦労されているお客様も少なくないと思います。そこで3つ目のテーマでは、導入後の運用面で重要な要素についてお話をしていきます。そのうちのひとつが、先ほど登場した「カタログ管理」の機能です。太田さん、解説をお願いします。

太田：データ基盤を維持・運用するために重要な要素として、適切なデータ管理をあらかじめ考えておくことが挙げられます。たとえば「データ基盤を新しく使いたい」というリクエストのあった人に、新規にアカウントを発行します。そして、その方が分析基盤を利用する際には、あらかじめ「ここを使ってください」というルールを決めておきます。

より具体的に言うなら、サンプルデータを使ったアドホックな解析やAIモデルの作成を行う場合は、学習カタログを使ってもらうわけです。結果、そこには誰が見ても問題のない、公開してもよいデータだけが置かれることになります。

ほかにも、開発用・本番用カタログといった概念があります。前者には開発プロセスや本番で発生した障害の調査経緯で発生したデータを、後者には実際に稼働しているジョブなどで発生したデータがそれぞれ置かれます。また、場合によっては特定のメンバーしか参照できないようなセンシティブなデータも、この本番用カタログに蓄積されます。つまり、本番用カタログはアクセス制御を強化し、セキュリティ対策をしておくことも重要です。

スライドの一番下にある管理者用カタログには、データ基盤が使われることで発生するサーバーログ・アプリログ・監査ログなどが蓄積されます。このようにデータ基盤を用途別に分けておけば利用者が増えた場合にも使いやすく、データ活用の拡大にも繋がっていくと考えています。

山本：データの特性とそれにアクセスするユーザーの部署・役職などに応じて、どのカタログを利用するかを決めておくことが、誰もが簡単に利用するために必要ということですね。これは横河電機様ですでに実践している部分もあると思いますが、いかがでしょうか。

桑田：DatabricksはSaaS型基盤になっているので、ユーザーに分析環境を提供しやすくなったと思っています。通常だと必要なライセンスの払い出しも不要なので、使いたい人にすぐ提供できるのは大きなメリットです。現在は開発用のカタログで一般的な活動をしていますが、学習用に使ってもらうカタログも用意しています。こちらは色々な人が使うので、必ず決められた名前をつけるなど、一定のルールを設けています。

開発用カタログには特に大きなルールはありませんが、プロジェクト単位で使用しているものなので、必ずプロジェクト名を入れるといったかたちで運用している状況です。本番用カタログはまだ用意できていないのですが、今後実装していきたいと考えています。

山本：データ活用が進むと使う人も増えるので、ルールが煩雑になるリスクもありますね。それを軽減するためにも、用途別のカタログ機能は非常に重要になってくると思います。

ここまでは仕組みや機能の話をメインに進めてきましたが、現場ではそれらを活用する人材の育成も非常に重要です。たとえば情報システム部門ならインフラやクラウド、DX推進部門ならプログラムといったように、部門ごとに使用ツールが異なっているがために、各自が異なるスキルを身につけるケースも少なくありません。一方で、横河電機様の場合は実装ができる体制づくりをうまく進めていらっしゃる印象なのですが、そのポイントを伺えますでしょうか。

藤原：クラウド知識・データ分析・プログラミングなどは、4年前ほど前から徐々にスタートしました。クラウド知識に関しては組織全体でワークショップやトレーニングなど、有償無償を問わず、幅広い取り組みを実施しました。すると得意な人・やりたい人が手を挙げてくれたので、そういった意欲や感度の高い方にクラウドのCoE（Center of Excellence）のメンバーになってもらいました。

プログラミングやデータ分析の分野については、PythonやSQLを学習してもらったり、オンラインの学習講座をうまく活用しながら進めてきました。今回は私たちを成功事例として取り上げていただきましたが、やはり時間のかかることなので、何もなくうまくいったということはないと思っています。桑田からも説明がありましたが、CoEが立ち上がっていたり、PythonやSQLを徐々に勉強していらっしゃる方がいたところも含め、今回のスムーズなデータ基盤構築が実現したと強く感じています。また、私たちのようなリーダー層もメンバーに指示を出すだけでなく、自らが率先して学んでいく姿勢が必要だと思っています。

山本：色々な部署に、自らやりたいとおっしゃる方がいたのでしょうか。

藤原：そうですね。技術的な探索活動も組織としてやっていました。

山本：技術に明るい方を特定の組織に集約させるのではなく、4年という長い時間をかけてデータ活用の文化を幅広い部署に浸透させてこられたのは、もともとの企業文化があってこそなのですね。

藤原：スモールスタートではありましたが、始めてみると情報を聞きつけた人たちが集まってきました。そういった場を提供できたのは良かった点かもしれませんね。