1. はじめに
当記事は株式会社G-gen様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。
ライオン側からは、 G-gen様のご協力のもと、Google Cloud環境に構築を進めているデータ基盤に関連した以下3つの記事をシリーズでお届けします。
- ライオンのデータ基盤構築とSAPデータ活用体制 👈当記事
- ライオンのデータマネジメント
- ライオンのデータ基盤における分析環境
2. 概要
ライオン株式会社にてデータ基盤まわりを担当しているフクヤマです。
当記事では、ライオンが進めるデジタル改革の1つであるデータ基盤整備について、背景や取組の全体像をご紹介しています。当社では、さまざまなシステムに散らばるデータをどのように一元化し、活用していくかが長年の大きなテーマです。そこで、最新のクラウド技術を活用し、より早く、柔軟に、そして正確に情報を取り扱える仕組み作りに挑戦しています。
私たちが「収益力の強靭化」 や「未来経営とデジタル改革」を実現するために直面している課題や、実際にどのような構成やツールを取り入れてシステムを設計しているか、SAPデータ活用体制を例に、試行錯誤の一端も含めて記載しておりますので、参考にしていただけますと幸いです。
3. データ基盤整備の必要性
「収益力の強靭化」から見据える未来経営とデジタル改革
当社グループは、経営ビジョン「次世代ヘルスケアのリーディングカンパニーへ」を掲げ、パーパス「より良い習慣づくりで、人々の毎日に貢献する」の実践によるサステナブルな社会への貢献と事業の成長を目指しております。
今年度より「収益力の強靭化」をテーマとした中期経営計画「Ｖｉｓｉｏｎ２０３０ ２ｎｄ ＳＴＡＧＥ」をスタートさせ、3つの基本方針「事業ポートフォリオマネジメントの強化」、「経営基盤の強化」、「ダイナミズムの創出」にもとづく施策を推進しております。
当社デジタル部門は、それらの施策をデジタル面から支え、迅速な経営変革に寄与するため、日々活動に取り組んでおります。
データ活用環境の課題
市場環境の激しい変化や多様化する顧客ニーズに対応し、的確な意思決定を多数かつ高精度に行うためには、データを組織の重要な資産と位置付け、その価値を最大化することが不可欠です。しかしながら、当社のデータ活用には、以下のような課題が存在しています。
- データのサイロ化
- 各種業務システムがオンプレミスおよびクラウド環境に個別に存在しており、データの統合や取得のハードルが高い。
- 業務システムに対する大量アクセスが集中すると、システム負荷の増大によりパフォーマンス低下や障害発生などのインシデントリスクが顕在化する恐れがある。
- ガバナンス
- 各業務システムから個別にデータを取得しても、属人的なデータ加工および保管が行われると、データ品質の管理が困難になり、誤った意思決定リスクを増大させる。
- 適切な権限管理の難しさに伴うデータセキュリティのリスクがある。
- スピード・柔軟性の欠如
- 高品質なデータに基づく迅速な分析および意思決定が難しい状況では、急なビジネスチャンスやリスクへの対応が遅れ、競合他社に対して優位性を失う可能性がある。
データソースの代表格としてはSAPが挙げられます。当社では2022年5月にSAP S/4 HANAを稼働しております。SAPのERPとしての機能の利用は進んだ一方、蓄積されるデータを活用する環境としていくつかのシステムの導入を検討しましたが、費用対効果、可用性の問題で苦戦し断念した経験があります。
近年、当社ではデータサイエンティストやアナリストが活躍する場面が多くなっておりますが、これら専門人材だけではなく全社員がよりデータに基づいて業務遂行するためには、環境整備を必要としていました。
目指す姿
これらの課題を解消する手段として、組織横断でデータを一元管理するデータ基盤をGoogle Cloud上に構築を進めています。データの取り込み・加工・提供までの一連の処理を基盤上で自動化・管理することで、最新の経営情報をより早く提供し、迅速で高精度な意思決定を可能とする体制を目指しています。
前置きが長くなりましたが、次章以降では本基盤の構成検討、およびSAPデータの活用体制について説明します。
4. 構成設計
当初案
当初はSAPデータの早期活用実現を重視し、Google Cloud Cortex Framework（以降、Cortex Framework）というフレームワークの導入を想定していました。また全体構成として、単一のGoogle Cloudプロジェクトに各種機能を集約したシンプルな全体構成を考えていました（Figure 1）。
Figure 1: 当初の全体構成
- Cortex Framework
SAPデータなどのデータソースからGoogle Cloudに連携した生データの取り込みから活用までの一連の処理に必要なテンプレートを提供しています。例えばSAPデータの場合、複雑に正規化されたデータモデルをBigQueryでそのまま使うことは難しいですが、Cortex Frameworkでは事前定義されたスキーマ変換・ビュー定義が提供されています。また、GoogleがSAPデータ分析用に設計したLooker用ダッシュボードテンプレートなどを提供しており、ゼロからデータモデル設計をする必要がないため、短期間での分析環境の構築が期待できます。当時、当社にはSAPデータに関する専門知識を備えたデータエンジニアがいなかったため、データ活用までの工数を最小化できる可能性があることが大変魅力的でした。
- BigQuery
本基盤の中核となるサービスです。フルマネージドであり費用・運用面でコストメリットが優れており、また、基盤の規模に関わらずユーザリクエストに応じて柔軟にリソース管理が行われ、高いパフォーマンスを示すため、基盤運用側・利用側の双方にとってメリットが大きいです。
- Fivetran
本基盤において、SAP（Microsoft Azure上のRISE with SAP）からのデータ連携ツールとして採用しました。Fivetranは、データ連携（同期・CDC機能）の構築・管理を自動化するフルマネージドなデータパイプラインツールです。Google Cloudの複数サービスを組み合わせたパイプライン実装も検討しましたが、当時の当社人材は実装経験が浅く開発工数・運用負荷が多くかかることが予想されたこと、また、短期間でのデータ連携が求められていたことから、フルマネージドな外部ツールでカバーすることにしました。
大幅な見直しへ
まず全体構成についてですが、単一プロジェクトから複数プロジェクトの構成に大幅に見直し（Figure 2）、プロジェクトごとの役割・機能、担当者の明確化を行いました。今となっては、この見直しは必然だったように思いますが、全社展開することを想定した場合に、当初案のようなシンプルな構成はリソースの所在の把握はしやすい一方で、リソース管理・責任分界点の定義の難しさなど、結果的に運用・管理が煩雑化しガバナンスが効かなくなることが懸念されました。
Figure 2: 見直し後の全体構成
構成見直しの主な内容は以下です。
- レイヤー構造への分解
データの処理の流れを意識し、レイヤー構造に分解することで、各プロジェクトの役割と管轄を明確化しました（Table 1）。このように分解することで、最小権限の原則に則った権限付与に伴うセキュリティの向上や、基盤拡張時にもスケールしやすいものになったと考えます。
Table 1: プロジェクトのレイヤー構造
| No | レイヤー | 役割 | 管轄 |
|---|---|---|---|
| 1 | データレイク（DL）層 | 各種データソースから取り込んだデータを保管し、各層にデータを提供する領域 | 基盤管理部門 |
| 2 | データウェアハウス（DWH）層 | DM層のデータ利用の要望に応じ、分析や集計に適した構造にデータを整えるための領域. DM層の各プロジェクトで共通利用可能なデータを整備. | 基盤管理部門 |
| 3 | データマート（DM）層 | 各業務部門の特定の目的に応じて、データを利活用するための領域 | 業務部門 |
- 管理用プロジェクトの新設
複数プロジェクト構成にすることで、リソースの管理・利用状況の監視を一元管理する必要が出てきました。
新設した1つはログ集約用のプロジェクト（Logging Hub project）です。このプロジェクトでは、監査ログを収集するとともに、事前定義した監視対象のリソース操作を検知・アラート発報し、トラブルシューティングや運用改善を図っています。
また、もう1つはデータガバナンス管理用のプロジェクト（Data Governance project）です。このプロジェクトでは、Dataplexの導入を検討しています。このサービスを利用することで、組織内のデータを1つのプロジェクトに集約せずに統合管理が可能です。主にはDL層・DWH層に存在するデータの権限管理の一元化、メタデータ管理によるカタログ化、データ品質チェックを担うことを想定しており、現在検証を進めています。これらの機能は、今後データソース・ユーザが拡大した際には必要性が増すと考えています。また、メタデータ管理については、生成AI活用の観点でも重要なタスクと認識しているため、注力すべき事項と考えています。
- Cortex Framework導入見送り
いくつかの観点での検証結果から、当社においては導入効果が限定的と判断し、導入を最終的には見送る判断を下し、自社でデータモデリングの設計・実装を進めることにしました。これに伴い、Cortex Frameworkのワークフローのオーケストレーションツールとして導入予定であったCloud Composerは、BigQuery向けデータパイプライン管理ツールであるDataformで代替することにしました（検討内容は次章で説明します）。
5. SAPデータ活用に向けて
Cortex Frameworkの導入検証について
導入見送りの判断を下したのは、前章の通りです。本フレームワークで提供される各種テンプレートはSAP標準テーブルが対象です。そのため、自社の業務要件に応じて作成されるテーブル（カスタムテーブル）を活用するためには、提供テンプレートのカスタマイズが必要になります。この点に特に留意しながら、実施した検証結果は以下の通りです。
当社の場合は、見たい指標や分析項目が開発過程である程度明確化してきたので、このような検証の流れ・結果にはなりましたが、カスタムテーブル数が少なく、SAPデータを使用した分析例を急ぎ検証する必要がある組織は、一度検討してみることをお勧めします。
- 機能カバレッジ
当社では現在、SAP BOを活用して業務部門に対してレポート（以降、BOレポート）を提供しています。BOレポートの元となっているテーブル群は、今後データ基盤でも少なくとも利用が想定されることから、これらテーブルとCortex Frameworkの処理対象となるテーブル（標準テーブル）の比較を行うことで、カバリッジを評価しました（Table 2）。
Table 2: 機能カバレッジ評価結果
| No | 評価項目 | 評価結果（%） |
|---|---|---|
| 1 | 対象テーブル(*1)のうち業務活用が見込まれるテーブルの割合 | 50 |
| 2 | BOレポートに利用されるテーブルのうち対象テーブル(*1)のカバー率 | 30 |
(*1) Cortex Frameworkの処理対象となる標準テーブル
評価結果No.1では、当社環境においてはSAP標準テーブルのみでは十分な業務活用が期待できないことを示唆しており、その他のカスタムテーブルの使用が必須であることを意味します。一方、評価結果No.2では、Cortex Frameworkが提供するテンプレートで現在の業務ニーズをカバーするには不十分であるという具体的な数値となりました。
これらの結果から、Cortex Frameworkを充分に活用するには、当社独自のカスタマイズまたはゼロベースでの追加処理作成が数多く必要であり、本フレームワークの強みであるSAPデータ分析環境の迅速な整備の恩恵を、当社においては享受することが難しいことを意味します。
- 運用・コスト負担
Cortex FrameworkではワークフローのオーケストレーションツールとしてCloud Composerを前提としたテンプレートが提供されています。前述の機能カバリッジの検証結果を踏まえると、まず金額負担の観点では、Cloud Composerの月間費用（当社環境での試算）は割高と判断しました。また、運用負担の観点では、Cloud Composerほどの高機能なオーケストレーションは現時点で不要であることから、Dataformでのデータパイプライン開発の検証も行い、こちらも導入の目途が立ちました。したがって、複数ツールの運用・管理は負担になることを考慮し、Dataformでの開発に切り替えました。
今後の方針
Cortex Framework自体は導入見送りの判断を行いましたが、テンプレートが提供するデータモデリングの内容（テーブル間リレーション、結合方法、など）は有益であるため、開発の参考にしたいと思っています。また、データパイプラインツールとしてはひとまずDataformを採用して開発を進めます。
Dataformは操作対象がBigQuery内のアセットに限定されますが、ツール利用料自体は無料であり、またSQL中心のELTツールであるため、開発者だけでなく、処理履歴（リネージ）も含めて把握したいユーザにとっても、シンプルでわかりやすいものではないかと、現時点では思っています。
6. まとめ
本記事では、ライオン株式会社におけるデジタル改革の一環として、SAPデータの活用を軸にGoogle Cloud上でのデータ基盤構築の取り組みと、その検討プロセスをご紹介しました。
今回の取り組みを通して、組織全体でデータを価値ある資産として活用し、迅速かつ高精度な意思決定を実現するための土台が形成されつつあることを実感しています。今後も引き続き、進化する技術環境に対応した柔軟なデータ基盤の構築に取り組むことで、企業の競争力強化とイノベーションの推進に寄与していきます。
本件は、G-gen様との協働取組みです。G-gen様の技術ブログG-gen Tech Blogに寄稿させていただいた記事リンクは以下となります。
ライオン株式会社のデジタル部門「LDX」が発信するテックブログ「LION Digital Inside」は、ハミガキ、ハブラシ、洗剤などを開発・製造する中で培った“製造業としての強み”と、Webサービス開発の最前線が交差する場所。LDXが最新技術と革新の舞台裏を余すところなくお届けします。
Discussion