こんにちは！TECH Street編集部です！
2023年7月27日（木）に開催した、 「データ分析基盤エンジニア勉強会 ～各社の取り組みや課題から学ぶ会～」のイベントレポートをお届けします。今回はデータ分析基盤エンジニアが集まり実際の実務で得た知見や、課題、改善策などを共有しあう勉強会イベントを開催しましたので、その様子をレポートいたします。
登壇者はこちらの方々！
鈴木 裕之さん/パーソルキャリア株式会社
池田一樹さん/株式会社コーセー
楊 明さん・王 毅超さん/株式会社良品計画
早速、内容を紹介いたします！
まずはパーソルキャリアの鈴木さんよりマルチクラウドに対応できる分析環境の導入事例についてお話いたしました。
マルチクラウドにして分析環境を導入した話
鈴木：まず初めに私の所属について紹介します。現在はパーソルキャリアのシステム共通BITAという組織に所属しており、具体的な業務としてはクラウドの推進やセキュリティ対応、OPSの高度化などを行っています。今後、さまざまなクラウドにシフトする上で分析環境を持っているのが我々の部署となっています。
データ活用のビジョンとしては…
- ビジネスとして実務で利用するための環境が整っていること
- データサイエンスの活用サイクルが運営できていること
- 管理体制を置き、セキュリティ管理が徹底され安全に利用できる環境になっていること
この３点を念頭に置いています。個人情報を扱っているためセキュリティの徹底はとても重要ですので注意しつつ活用するのがビジョンとなっています。
我々は事業の可視化を目的としているので、事業間KPIの共通定義化や業務効率化など、上記のような目標を立てて、それに対して環境を提供していく役割になっています。それをベースとした現行のシステムは以下図の通りです。
2017年頃からコツコツと広げていき、今の形にしていきました。
ただ下図の通り、経年の課題がでてきており…
事業分析の課題としては、サービスの多様化によって分析要素のスペックが追いついていない。利便性の悪さが顕著になってきました。
また保守の課題としては、できたときはスモールスタートだったので、手動運用で対応していましたが、それが限界になりました。リソースの課題としては、キャパシティの逼迫が顕著になってきました。そこで、課題解決のために新環境を構築するプロジェクトを発足いたしました。
新環境の構築でやりかったこと
サービスの変化や成長はかなりスピード感をもってやっているので、その成長に合わせた分析ニーズも変化していきます。それに追いつけられるような環境を提供し、「すぐ施策に繋げられるように実現していきたい！」というのが新環境の目標でした。
そのためにRFP（Request For Proposal:提案依頼書）を提示するために大事なことを考えてみたところ、先ほど提示した事業・保守・リソースという3つの課題に対して、自分たちにマッチする製品を見極めることが重要と考え、PoCの実現や製品ベンダー、専門SIerとパートナーを組んで提案してもらう形式としました。
そこで決定したのが【databricks社】のプラットフォームです。
我々の組織にはデータ分析をゴリゴリする人が全体の20%ほど在籍しています。その人達は重い処理をやりたいのにライト層の人達によってDBの負担がかかっているという課題がありました。その課題が解消できるのが【databricks社】のプラットフォーム でした。
データ取扱いの工夫について
我々のデータは個人特定ができるようなものが多く入っています。その中で「ビジネスと分析で使う領域は確実に分ける」という思想で構築する必要があるため、個人特定項目は、分析環境には持ってこれないようにシステム化を行いました。
分析ではIDを暗号化し個人情報保護法に向けた加工などをしています。
また分析の利便性を上げるためにも、分析用カラムは自動付与できるようにスクラッチしています。
そうすることで、今まで加工していたものが加工不要になるので、汎用的にジョブ化するという対策にしました。
ネットワークについて
アクセス設計についてもHUB化構想ということで、間にワンクッション置いて通信させる構成にしています。そうすることで、分析環境としている右側のAzureにアクセスできるポイントが限定的になり、ネットワークのセキュリティが安全に管理できるようになります。
またデータソースが多すぎて「ジョブネット地獄」を効率よく解消するように構築しました。そのやり方としてMart処理との紐づけをおこないました。
データマートは、DSが揃った段階で集計させるようなジョブ構成を取っており、Queが溜まったものから集計をかけることで、ジョブ効率を上げています。
保守について
保守に関わる社内の申請まわりについても改善を図りました。
これまでは個人情報がたくさんあるので、改善前まではそのデータを使っていいかどうかのコンプライアンスチェックをしていました。しかし時間がかかってしまうので、スクラッチで申請画面を用意して、自動的に項目チェックや入力補完、検知をできるようにしました。
そこで、今まで主導対応していたバッチ処理の適用の作業を半自動化。保守工数の削減を実現できました。しかしまだそのまま反映するのは難しく、半自動化となっているため今後改善の余地はあると考えています。
またジョブ状態情報を取得してモニタリングに活用できるようにもしています。
左側にあるバッチ稼働状況やレポート通知などをダッシュボード化して、最終的にはGrafanaに流し、利用者の方に公開できるようにしました。
まとめ
環境移設に向けて苦労したことは…
- 変化を嫌がる
- データが異なる
- 初期不具合
この辺りがあげられます。ただ難しいのは当たり前なので技術的な面は仕方ないですが、最大の注意ポイントは、「利用者へのケア」です。違和感があるのは当たり前なので、ガイドラインの整備や勉強会の実施を重要視しています。
最終的な構成は以下の図の通りです。
今後はせっかくデータのHUB化ができたので、リアルタイムでデータを使うことを想定し、ビジネスにより貢献できるようにしていきたいです。またマスキングのあり方はまだ改善できる余地があると考えています。
夜間トラブルについても、自動復旧の定義が重要なポイントと捉えているため、さらに試行錯誤しながら、よりよいデータ分析基盤を整えていければと思っています。
つづいてはデータ活用における情報部門の苦悩について、株式会社コーセーの池田さんにお話いただきました。
データ活用事例における「しくじり」と「学び」
池田:突然ですが、このような境遇の方はいらっしゃるのではないでしょうか
- 「DX」と言われてデータ活用のプロジェクトがスタート
- うちの会社ってそもそも誰が同データを扱っているのか？
- 今までやったことがないけど、私はどうやって貢献できるのか
- 複数プロジェクトを兼任していてこればっかりに時間を避けない
私もこのような悩みを抱えていた（現在進行形でもありますが）1人です。
今回はゆるりとデータ活用に踏み入れた私が、同じように悩みを抱える事業会社の情報部門の方々に参考となるように
- データ活用を始める際につまずきやすいポイントはどこなのか
- しくじりの原因はどこに潜んでいるのか
- どうしたら事業会社がデータ活用に向けてスムーズに取り組めるのか
と、上記をポイントにしたお話をできればと思います。
データ活用プロジェクト発足の背景と目的
まずこれまでの弊社のデータ活用は「使えない/使いづらいデータ」を「一生懸命加工して運用する」日々でした。
決してデータ活用を行っていないわけではありませんが、左側にあるようにデータが散在していて、そこから扱えるものだけがエクセルを使って加工し、データ分析をしている状態…。
そこで、右側を目指してプロジェクトを発足し、その先にはデータドリブンに施策を打てることを目的としています。
このプロジェクトはデータの一元的な集約・蓄積と活用可能な共通プラットフォーム化を推進するために・・・
真ん中にあるデータ活用基盤を作ることを目的としています。
本日はデータ収集と加工の部分に絞ってお話します。
検討①データの収集
まずは受送信システムのファイル連携HUBとなるIF基板について
システムごとにやり取りするとメッシュ構造となってしまうため、HUBとなるS3bucketを置くことによって、やり取りを簡素化することが狙いです。
↓
この基盤が少し前にリリースされたので、ここに集まるデータをレプリケーションして、データレイクを作ろうという方針になり、データレイクの構成を意識したIF基板の再設計に着手しました。
構成を簡単にお話します。
まず、S3 bucketの中に送信システムごとのフォルダを作成
システムAから送られたデータはAフォルダの下、システムBから送られたデータはBフォルダの下へ。そのファイルを受信システムが受信する、という構成になっており、権限設定をしています。
この他にも、下記図の①〜⑥の検討ポイントがありました。
ここに集まるデータはすべてデータレイクに行くので、きちんと複数のシステムが送信できるような、ファイルを置けるような仕組みにしなければならないので、①で連携の方式を整備しました。
②は社内とやり取りするシステムや社外とやり取りするシステムがあるので、それはきちんと分けて、権限管理やセキュリティの設計を行えるようにしました。
その他にもいろいろな検討項目がありましたが、3カ月にもおよぶレビューと検討を経て、ようやく実践へ。しかし運用をはじめると、設計不足が発覚…。数々のクレームも出てきてしまい、その結果、設計のやり直しを余儀なくされました。
アプリベンダーと一緒にやっていて、ガイドラインの作成はベンダーさんにやってもらい、コーセーの社員がレビューをする形をとっていましたが、その契約が切れて担当者がいなくなってしまったので、運用担当の私たちがガイドライン作成のやり直しを引き継ぎました。
その結果、｢このルールなら大丈夫｣というところまでたどり着けましたが、最初の段階で設定を行っているシステムがあったので、それに対してはシステムの修正を依頼してやり直しとなりました。
それがしくじり①｢３カ月検討した結果、振出しに戻る｣です。
検討②ETLツールの検討
ETLツールについてもトラブルがありました。
最終的に収集からデータの可視化、提供までの流れのイメージは上記の通りです。
途中に出てくるETLツールについては、製品の候補をあげておこないました。
まずは機能を洗い出して、評価を行いました。
評価したところで、どうやって判断するのかなどが分からなくなり、こちらも再度見直しとなりました…。
そこで、重要度の列を追加し、凡例で基準を明確化しました。
△の定義をきちんとしなければ、私たちのように迷子になってしまいます。
コーセーとして、AWSに統一したいという意思を、きちんとベンダーさんに伝えました。
これが｢しくじり②要件の整理・ツールの評価をやり直し｣です。
しくじりの原因は
それぞれのしくじりの原因はどこにあるか改めてまとめてみると…
根本的な原因は「やってみようといえる人が社内にいない」「コーセーの意思がない」つまり、コーセーの熱意と、行動力が欠けていたことが大きな要因ということがわかりました。
そこで今後の対策と教訓として変化のためのアクションを仕掛け中です。
※青色をto beと見立ててまとめています。
専任者のアサインはとても重要です。事業会社の情報部門に責任を与えることによって、事業会社が主導できるデータ活用が進められると考えています。
しくじりで得られたデータ活用に取り組む際の教訓としては以下の通りです。
- レビューで収集がつかなくなったら「まずはやらせてください！」
→成功体験/失敗体験をもとにすることが一番早い - ツール選定は想いを込めて。承認を取るときにはフラットに。
→自分たちがどうしたいのか、どうあるべきかを最優先に
自分たちがどうしたいのか、会社がどうなってほしいのかを込めなければ無機質な選定になってしまい、できたあとも使えなくなってしまうので、重要なポイントだと思います。
まとめ
データ活用における情報部門の挑戦と苦悩は…
意思のある個人がきちんと挑戦し、壁に当たったら苦悩はチームで乗り越えるということを思い知った、しくじり話でした。このしくじりと教訓が皆さんのデータ活用の糧になれば嬉しいです。
最後に無印良品のID-POSデータ分析について株式会社良品計画の楊 明さん/王 毅超さんにお話しいただきました。
無印良品のPOSデータ分析基盤をご紹介
王：様々な形式で展開されている無印良品ですが、実は市場としては日本がいちばん大きいです。
よって分析のデータもたくさん種類があり、活用ルートもたくさんあります。
また良品計画は２０２１年９月から『第二創業期』がスタートしており、IT・ECデジタル部門における中期経営計画としてはデジタル化による効率化やECサイトの売り上げ増が組み込まれています。
ここからは具体的なデータ活用メソッドをお伝えいただくため、楊さんにバトンタッチします。
IDｰPOSデータ分析の目的
楊:IDｰPOSデータ分析の目的としては下の４つにまとめられます。
データ分析の際は目的と要件で整理しないと、なかなかゴールに届きません。
よって要件は以下の通りです。
データは将来的に必ず増加するので、それに対応できるように考慮することがポイントです。
IDｰPOSデータ分析の全体構成
基本的にはMUJI POSのシステムからAWSの分析基盤にデータ連携されます。
そしてKinesisを経由してPOSデータを集約し、MUJIデータレイクに蓄積されます。
データレイクに蓄積されたデータはqueriesに加工して、それぞれの分析ニーズに応じてデータマートが作成され、そのデータマートはさまざまな利用者に提供されます。
そこからは分析データのために、データレイクが必要です。
MUJIデータレイクはこのような3層の構成になっていて、それぞれで保存されるデータが違います。
POSデータの集約について、今回はストリーミング処理とバッチ処理の2つで、鮮度と精度を両立させるように構築しました。ストリーミング処理は、5分に一度はデータ刷新しています。
店舗のアプリ(Azure)側にjsonファイルが通信されますが、アプリ間では一般的にはjson形式で通信されます。しかしjson形式は分析しにくいので、今回はデータ連携の際に随時Lambdaで分析しやすい形にフォーマットを変更して、データレイクに蓄積されるようにしています。
細かい事例は以下の図のようなイメージです。
左側はjson形式です。
この中には取引番号、担当者情報、購買商品の情報が入っています。
jsonファイルのままだと分析がしにくいので、Lambdaを経由して右側のようにテーブルごとに解析されます。
リアルタイムでデータ連携されるので、レジ側に随時データがくるため、パフォーマンスが大切だと考えました。自分の業務はどれくらいのパフォーマンスが必要かは、事前に調査と確認が必要です。
無印良品に関しては日本に500店舗ほどあり、店舗ごとに平均して10台ほどのレジがあります。レジはリアルタイムのデータ生成ではありません。一度のお会計でおよそ1分かかると考えれば、どれくらいでリアルタイムデータが生成されるかは見積もりが取れます。
正しいデータを担保するために、ストリーミング処理以外にも毎日バッチ処理を行っています。
計算済みの正しい取引データは、前日分が転送されてデータレイクに蓄積されます。
AWS Glueを採用した理由は、サーバーレスなので環境構築がないことと、サーバーのインフラ運用が一切不要なことです。また、転送されたデータはカタログを生成できるので、カタログを管理できればデータの移管性を担保できます。
転送されたデータや蓄積されたデータは、データごとに唯一のカタログが生成されます。
分析ニーズやツールはさまざまですが、移管管理が可能です。
作成されたデータマートは、BIツールを接続して可視化やレポートを出して分析するなどして利用します。
今後の展望
現在、ストリーミング処理はリアルタイムで行っていますが、後ろの処理はリアルタイムではありません。LambdaとAthenaでバッチ処理をしています。今後は、ストリーミングデータで可視化や在庫検知の仕組み構築にチャレンジしたいです。
鈴木さん、池田さん、楊さん、王さん、発表ありがとうございました！
Q＆Aコーナー
続いてQ＆Aコーナーであがった質問を紹介します。
（Q）「ビッグデータが溜まっているのでデータ利活用で価値を見つけたい！」とメソッドファーストになってしまいがちな現場に対する、とっかかりに必要なスキルセット/ビジネスパーソンの種別を教えて下さい
鈴木：私たちの部門は、データ分析の部隊やビジネスの部隊など専門の人たちがいます。そこのリーダーたちと意見交換を密に取っています。スキルセットは、パフォーマンスセットの技術者が多いです。
（Q）データ分析基盤の活用でコスト面での苦労や改善の工夫などがあれば教えて下さい
鈴木：利便性があるところとマッチして、コストもかかる。その分リソースを使うため。リソースを使う上でキャップをかけていくようにしていました。
（Q）「事業間KPIの定義」はなかなか難しそうですが、どのような観点でKPIを決めて行かれたのでしょうか
鈴木：チューニングに関わっており、KPIの決定に鈴木さんは携わっていません。
（Q）いままで手入力で運用していた→さすがに手入力だと回らないから基盤構築しよう、の境界線は意外と大きいのかなと思っています。最後の一押しは何かあったんでしょうか？（閾値を超えるきっかけ、のようなイメージ）
鈴木：ターニングポイントを設定しており、「この作業は要・不要か？」「テックの力で解決できないか」を考えています。
（Q）パーソルさん。AWSとAzureのマルチクラウド環境構築で難しい点はありましたか？
鈴木：AWSについては以前から整備されていました。
AzureやGCPはそこまで整っていません。Azureは管理できる人がおらず、自分たちでやっちゃおうという勢いで始めたので、基板の運用保守の調整をするのが難しかったです。
（Q）可視化ツールが見えました。 タブローとPowerBIは似ているツールだと思っているんですが、どう使い分けされていたんでしょうか
鈴木：PowerBIはローカルにファイルが出来てしまう。そこにデータができてもいいものはPowerBI。より分析のニーズがアナリティクスに近いユーザーには、tableauを使わせています。そこまで垣根はないです。
（Q）DatabricksをAWSではなくAzureベースで構築された理由を教えてください。
鈴木：AzureのなかにDatabricksの窓口があり、リリースも早かったです。
1年前の検討時にGCPなども候補にあったが「東京リージョン」があるのがAzureでした。社内ルールで東京リージョンを使う必要がありました。
（Q）コーセーさんのIT化はどのような感じですか？社内IT化事情とかユーザー向けのアプリとか
池田：化粧品メーカーのIT化は、お客さま用システムと社内システムの２つがあります。肌診断アプリや美容スタッフとオンラインでカウンセリングするアプリケーションやECサイト、顧客IDの管理基盤などがあります。社内システムとしては店頭の販売履歴管理システムや社内のワークフローシステム、人事システムなどです。
（Q）うちの会社の話かな？と思いました。専任アサインが未着手である点は、なにかご事情あるのでしょうか？
池田：リソースが不足しているためです。
（Q）コーセーさん、エンジニアはどのような規模・体制ですか？
池田：情報部門は約60名です。基盤全般、コーポレートシステム、基幹システム、マーケティングシステム、DX推進の分類に分かれて課が構成されています。
（Q）IF基盤について、データカタログのようなものは構築されている・検討されているのでしょうか
池田：データカタログはまだ検討できていません。ETLの仕組みを構築した後に検討予定です。
（Q）しくじり①について、あるあるすぎて胸が痛くなりました。。。レビューを何度も行ったにもかかわらず、見直しが発生した原因って何だったんでしょうか？
池田：実際の運用において発生するケースを網羅的に検討できていなかったからだと考えています。
机上検討のみで100％網羅できるケースは少ないと思うので、PoCなどを行って実際に試してみることが必要だと思います。
（Q）コーセーさん、AWSで日本語対応をMUSTから外すのはなかなか思い切ったと思います。ユーザーから不満でませんでしょうか？（弊社だと無理そう）
池田：あくまでAWSコンソール上の操作なのでMustからは外しています。
事業部門などのエンドユーザが利用する画面の場合は日本語対応が必須となりそうですね。
（Q）チームが若いメンバー中心の体制だったようですが、基盤構築のあたり、他の構築事例などは何か参考にされたのでしょうか。
池田：DX推進課は若手メンバーが多いのですが、弊社はプロジェクト制をとっており、60名いる部員のうち複数の課のメンバーが混ざって業務を行います。
他の事例としては、AWSを利用しているのでAWS社の方に事例やベストプラクティスを教えてもらうケースが多いです。その後にコーセーではどのようにしたら最も運用しやすいか考慮してカスタマイズしています。
（Q）KOSEさんに質問です。ベンダーさんとの協業のお話がありましたが、どこまではベンダーに任せ、どこまでは自分たちで内製化する、といった軸はありますか。
池田：AWSの環境構築はコーセー、アプリケーション開発はベンダー、という線引きを行っています。
AWSを標準としている以上、アーキテクチャやサービスへの理解ができていないと、ベストプラクティスやガイドラインに沿った構成になっているか、ということや障害対応、コスト最適化が推進できないためです。
（Q）話を聞いている感じだと、かなり大規模で多くのステークホルダーが関係するなかで、半ば炎上チックな状況になってしまったのかなと思いました。どのように切り抜けたのか、その時の苦労話含めて伺いたいなと思いました
池田：今回のプロジェクトは仕掛中のもので、ユーザーへの影響は今のところありません。まだリカバリできる状況で、炎上していないです。
（Q）意思決定機関があるのですね。その機関ができてからやはり格段にスピード感があがったのでしょうか？ また、意思決定機関として選ばれたのはどういったメンバーでしょうか。 もともと社内にいたメンバーで構成されているのかも含めて知りたいです。
池田：スピードが格段に上がったとはいえないと思います。ガバナンスや標準化ができたので、そういう意味ではスピードが上がったと思います。
60人中メインのPMが6名。この6名を意思決定機関として推進しています。ほとんどが中途メンバーです。
（Q）コーセーさんのIT部門はSIer出身者が多いのでしょうか。
池田：Sier出身者が多いです。
ここ数年は情報部門における新卒採用を行い始めたので、SIer出社ではない者も徐々に増えてきております。
（Q）池田さんへ 内容にあまり関係なくて申し訳ないですが、パワーポイントの色使いやデザインが好きです。 何か意識していることはありますか？
池田：ありがとうございます。
パワポ作成のコツは一般的に言われていることと同じで恐縮なのですが、数ある中でも「聞いている方が、今どこを見たら良いか、がわかる資料」を心がけています。
（Q）コーセーの社員、男性はみんな美容男子？（IT IT関係なくてごめんなさい）
池田：事業部門はほとんどの方が自分の担当するブランドの商品を利用して、良さを伝えられるようにしております。(イコール美容男子であるかは難しいですが)
（Q）プロジェクトにAWSが参画していたのは、AWSでどういったサービスがあるのかを知りたいためでしょうか。足回り環境の意志決定のためでしょうか。APベンダーからはASW周りの意見はあったのでしょうか。
池田：AWSさんに参画してもらっているのは、AWSをより効率的に、要件にマッチした設計とするためです。APベンダーさん、AWSさん、コーセーで構成されるPJメンバー全員が分け隔てなく意見を言い合います。インフラについても、アプリに対しても、です。
（Q）AzureとAWSを両方活用している意図は何かありますでしょうか
楊：特におおきな意図はないです。それぞれのBiz部門で採用されています。
（Q）ファミマで販売されている商品のPOSデータはここに含まれますでしょうか？ POSデータを合わせる苦労とかございましたらお聞きしたいです。
楊：ファミマは停止して、ローソンです。今後はPOSデータを統一したい。
（Q）通販のデータとPOSデータは統合されたりしますか？
楊：現状はレジのPOSデータの分析だけです。今後は統合予定です。
（Q）ストリーミング処理を活用するユースケースは例えばどのようなケースがありますでしょうか
楊：不正取引のリアルタイム検知。在庫の不足検知。などに活用しています。
（Q）複数のKinesisに対してレコードを送る際、自動的にバランシングされるのでしょうか？
楊：はい。自動です。
（Q）DataCatalogを作り上げる時の苦労点などはありますでしょうか。国ごとにデータが違うなどで統合に苦労した、など
楊：国ごとはデータの定義が全然ちがいます。大きなマッピング表を作ります。
スキーマを揃えて、1つのテーブルを作っています。
他の国が使わないcolumnはNULLに設定するなど、国ごとにマスタはバラバラだが、DataCatalogは必ずあります。
（Q）リアルタイム分析は本当に必要でしょうか。このあたりを追求しようとするとコストに大きく跳ねてくるため、どういった要件がある場合にリアルタイム分析が必要とされるのか知れると嬉しいです。
楊：必要かどうかはPoCを検証しないといけない。例えば、在庫管理に必要です。
（事例を詳しく紹介いただきました）
（Q）良品計画さんへ データの可視化のBIツールとしてTableauを選んだ理由を教えてください。
楊：tableauは操作しやすい。店長などユーザーが見やすいUI。閲覧者はとっても多い。何万人規模。他のツールだと閲覧者ごとにコストが掛かったり、パフォーマンスの低下が起こる。
それらを検討した結果、tableauを選択しました。
次回のイベントレポートもお楽しみに♪
