アーカイブ動画

企業や組織のDXを支援するKDDI Digital Divergence Group

最初にKDDI Digital Divergence Holdingsで、グループのマーケティングを統括している西平麻里氏が登壇し、グループの説明を行った。

KDDIでは、中期経営戦略（2022－2024）においてサテライトグロース戦略を策定。通信を核とした注力領域であるDX、金融、エネルギー、LX（ライフトランスフォーメーション）、地域共創を拡大することを謳っている。

KDDI Digital Divergence Groupは、同戦略の一つであるDX（デジタルトランスフォーメーション）を専業とするグループだ。

IT調査会社のIDC Japanによると、DXは新たなステージに移行する転換期となっている。「単発のデジタル変革では終わらず、デジタルビジネスが持続していくデジタルファーストの世界になると報告されている」（西平氏）

DXを推進する日本企業では、大きく次のような課題がある。第一がデータ活用の課題。継続してデータ活用できる仕組みがなく、事業に直結した成果が出ていないことだ。
第二の課題はDXが継続しない、改善サイクルがうまく回らないこと。 第三に組織・体制の問題である。「変化に合わせた経営判断をすることは、企業が生き残るために重要ですが、柔軟にスピード感を持って判断できる組織になっていない企業が多く存在しています」（西平氏）

このような3つの課題を解決し、持続的なデジタルビジネスの推進を支援するのが、KDDI Digital Divergence Groupだ。グループには現在、アイレット、KDDIアジャイル開発センター、フライウィール、KDDIウェブコミュニケーションズ、Scrum Inc. Japanという5つの会社で構成されている。

アイレットはシステム導入、設計・開発から24時間365日の運用保守までをトータルサポートする実績豊富な会社である。

KDDIアジャイル開発センターは、KDDIの中で開発していた部門がスピンアウトして設立した会社で、自社で実践してきた知見を活かして、内製化の支援や、サービスデザインからアプリ開発までをトータルにサポートしている。

フライウィールは、データをビジネスに変えることにこだわったデータ専門会社だ。GAFAM出身者も多く、グローバルレベルの経験を活かした支援を行っている。

KDDIウェブコミュニケーションズはオンライン、オフライン双方のコミュニケーションを支援する会社で、海外サービスを日本に導入して提供することも得意としている。

そして、環境変化の激しい時代にクイックに判断できるようアジャイル組織変革のご支援するのが、Scrum Inc. Japanである。

同じようなケイパビリティを持つ企業はたくさんあるが、それらとどう違うのか。

「それぞれ専門の会社が連携してトータルでサポートできる点と、成果につなげることにこだわっている点が他社との違いです。エンジニアであっても企画部門と一体となって、プロジェクト全体のゴールを追い求める。またお客さま企業内で抵抗勢力があったとしても、一緒になって向き合い、味方に変えていく。そんなサポートをしているのが特徴です」（西平氏）

DCRとは何か。SnowflakeでDCRを構築するメリット

KDDIアジャイル開発センター株式会社
Data Engineer/Analytics Engineer　篠原 誠氏

続いては、KDDIアジャイル開発センターのデータエンジニア/アナリティクスエンジニアの篠原誠氏が登壇。「Snowflake Data Clean Roomの構築と運用」をテーマにセッションを行った。

篠原氏が所属するKDDIアジャイル開発センターのエンジニア比率は、8割以上。開発サービス事例としては、auでんきサービスの契約者向けアプリやauショップやUQスポット店舗のプライスカードをデジタル化したau priceなどが挙げられる。

フルリモートワークや地方居住など、ライフスタイルに合わせて好きな場所で働くことができ、次のキャリアを描けるジョブポスティング制度、社外副業制度などを導入している。

「エンジニアが生き生きと働けるさまざまな環境が用意されています」（篠原氏）

また、KDDIアジャイル開発センターは、地方共創・ワーケーション活用にも積極的だ。京都府舞鶴市、静岡県三島市、沖縄県那覇市、北海道札幌市、群馬県高崎市、秋田県秋田市にオフィスを開設。舞鶴オフィスではスマート漁業にも取り組んでいる。

篠原氏は、KDDIでチャットボット開発や統計化位置情報分析基盤開発、KDDI研究所での対話AIプロジェクトなどに参加。その後、データエンジニアとしてデータクリーンルーム（DCR)の開発に従事している。

DCRとは、「個人情報を含んでいるデータを中身の情報は見せずに結合して掛け合わせて分析を行うことができる技術であり、それが実現できる環境」と篠原氏は説明する。

「DCRが必要な理由は、プライバシー保護の機運の高まりや各ブラウザのサードパーティCookieの規制・廃止の流れがあること。個人情報に配慮した上で、ファーストパーティ同士のデータを掛け合わせて分析したいというニーズがあるためです」（篠原氏）

SnowflakeのDCRをなぜ、選んだのか。その理由を篠原氏はこう述べる。

「KDDIのデータ基盤戦略は、KDDIグループの価値あるデータの蓄積・集約し、データをビジネスにつなげて利活用することで、KDDIグループの利益拡大に寄与。データドリブン経営を支えることです。グループ企業横断でデータ分析を行えるプラットフォームとして、データガバナンス機能が豊富でデータシェアリングが簡単にできるSnowflakeを選択しました」（篠原氏）

Snowflake DCR開発の効率を上げるために行った工夫

篠原氏は、SnowflakeのDCRの開発効率を上げるために行った工夫に関する説明も行った。Snowflake DCRによるデータ活用の流れは次の図のようになる。

プロバイダとはデータを供給する側、そしてそのデータを受け取って自分が持っているデータと掛け合わせて分析をするのがコンシューマである。Snowflakeのデータシェアリングの機能を使って、プロバイダの中にあるデータをコンシューマにシェアする。

だが、篠原氏は「シェアしたデータは直接参照できないようになっている」と説明する。それを実現するために、Row Access PolicyやStream/Task、Stored ProcedureなどのSnowflakeの各種機能をフル活用しているのだ。

Snowflake DCRの構築プロセスでは、相互にシェアオブジェクトを作成するため、プロバイダとコンシューマに依存関係が生まれる。Snowflakeのオブジェクトの構築は、SQL文とDDL文を実行していくが、SQL文を地道に実行していくのはかなりの作業量となる。

「Terraformを活用し、効率的にDCRの構築を行っています」（篠原氏）

だが、膨大な量のDDLをTerraformのリソースとして記述するのは大変である。そこで思いついたのが、ChatGPTを使ってDDLをHCLに変換することだ。第1ステップで、DDLに対するTerraformのリソースを探し出す。

第2ステップで、プロバイダにあるSnowflakeのアカウントやデータベーステーブルなどのリソースを、すべてChatGPTのシステムメッセージとして列挙することで、精度良く回答をくれる。第3ステップで、Example Usageとスキーマをプロンプトに加えて、In Context Learningさせて回答を得る。

「このような方法を使うことで、開発効率をアップしています」（篠原氏）

小売フランチャイズが抱えていた課題をデータ活用で解決

株式会社フライウィール
Data Scientist　笠井 誠斗氏

続いて登壇したのは、フライウィールのデータサイエンティスト笠井誠斗氏だ。「Modern data stack」をテーマにセッションを行った。

笠井氏が所属するフライウィールは「データを人々のエネルギーに」をミッションに掲げるデータエンジニアリング専門のスタートアップである。データ戦略から基盤構築、価値実現まで一気通貫で支援する。それを実現するために提供するのが、データ活用プラットフォーム「Conata」だ。

「Conataは組織内だけではなく、組織間でデータ連携を行い、そこで一本化されたデータを事業プロセスで活用することを推進。さらには他の企業とのデータ連携によって、シナジーを生むことができるつくりになっています」（笠井氏）

様々なデータを取り込み、共通のデータフォーマットに変換。定義されたオファリングを有効化し、組み合わせによって様々なソリューションへと展開できる。需要管理や倉庫・物流ソリューション、屋外デジタル広告などはその一例であり、すでにさまざまな企業に導入されている。

現在、フライウィールでデータエンジニア、データサイエンティストとして、データ基盤開発業務やプロジェクトにおけるデータを用いた改善提案などに携わる笠井氏。前職のアマゾン ウェブ サービス ジャパンでは、ソリューションアーキテクトとしてアナリティクス系サービスの設計・提案に携わっていた。

笠井氏は、とある小売フランチャイズプロジェクトを事例に、フライウィールが行ったデータ活用のための技術とその選定方法について紹介した。

同プロジェクトの目標は膨大な在庫、POSデータを蓄積、分析して需要予測を行い、それに基づいた適正な発注を行えるようにすることである。

だが、需要予測する対象は2000店舗×500万SKU（ストック・キーピング・ユニット：在庫管理の最小単位）で100億通りあったという。タイムリーな在庫・販売傾向の可視化、需要予測が従来の基盤では技術的に対応が難しかったと、笠井氏は語る。

「全店舗共通で人気順の発注になっており、店舗によっては実績データが遅れて送られてくるケースもありました。そのため、前日の在庫を加味した発注が難しくなっていました」（笠井氏）

さらに、発注・店舗・SKUに関するマスタファイルの数が多岐に渡っていたことも課題となっていた。

課題解決のために活用した技術スタックを紹介

これらの課題を解決するためにConataを導入し、次のようなアーキテクチャを構築した。Amazon S3 Bucketをデータレイクとして活用。そこに入ったデータをもとに機械学習や推論を行っている。

S3にあるデータファイルに対してクエリを実行するサービスAmazon Athena、Amazon Aurora、BIツールのTableau、Amazon QuickSight、Apache Pinotなどを活用し、需要予測およびそのモニタリング・データに基づいた自動発注業務ができる仕組みを構築した。

外部データの入手経路は、主に3つ。1つは、基幹システムであるAzure環境のデータ。2つ目が顧客用S3 Bucketである。

だが、この状態ではマスタの複雑さに対応できなかったり、データ品質が低下したりする問題があったことから、3つ目にマスタ管理機能を追加したという。マスタ管理機能とは、マスタをアップロードして、日付単位でバージョン管理される仕組みである。

具体的には、WebUIからS3にファイルがアップロードされると、それを検知したデータパイプラインがフェッチして、中身のスキーマなどをチェック。そしてその検証結果をアプリケーションに通知する。

「入り口部分のデータ品質を改善することで、以前からの課題だったマスタの複雑さとデータ品質を改善しています」（笠井氏）

前処理・ETL部分については、Dagsterとdbtを活用している。Dagsterは、データオーケストレーションツールである。Dagsterを活用して、データ変換プロセスの記述やスケジューリング、イベントをトリガーに変換する。

「UIの使いやすさ、Kubernetesとの親和性、デプロイフローの柔軟性などの観点から、選定しました」（笠井氏）

一方のdbtでは、データウェアハウスの中でのテーブルの流れを追って、従来テストが難しかった複雑なSQLを用いたデータ変換を細かく切れるようにし、さらにテストをしやすくするようにしている。

dbtのデータリネージ機能では、どのテーブルがどの程度繋がっているのか、どのように変換されたのかが自動的に生成されるようになっている。

この機能を使えば商品マスタが複数あったとしても、それを容易に確認し、一本化することも可能となる。そのほかに品質保証がより簡単となり、dbt testを使うことでマスタ感の整合性のチェックもできるようになる。

他にもマスタのロジックを変更したときに、どのテーブルに影響するのかといった影響範囲の調査が容易になるなど、データ品質やガバナンス向上も実現したという。

「さらに副次的な効果として、社内のデータ処理について知らない人でもデータパイプラインを見て、こんなふうにデータが処理されているのだと、わかるようになりました」（笠井氏）

機械学習に使用したロジックは、売上点数予測とベクトル化・近傍発注の2種類である。売上点数予測は、実績発注で向こう10日〜28日間の対象店舗×SKUにおける売上点数を様々な特徴量を用いて回帰モデルで予測し、その数を適正な在庫数として発注提案を行うというものだ。

主に、売上の安定している商品が対象となる。一方のベクトル化・近傍探索は、補充発注用としてID-POSデータを用いて、ユーザーの商品購入列をもとにWord2Vecで商品ベクトルを計算。店舗毎にレコメンドスコアを計算して売れたら再発注する対象となる品揃えを決定する。

「これらの機械学習も実際店舗に置いた後に、ユーザーがモニタリングして精度をチューニングするなど、継続的な改善を行っています」（笠井氏）

集計したデータをユーザーに遅延なく届けるために、リバースETLの仕組みを用意。先述したようにこのプロジェクトでは、膨大なデータ量かつデータの組み合わせが多すぎることが問題だった。

この問題を解決するために活用したのが、Apache Pinot。ストリームデータにリアルタイムな分析クエリを投げられるデータストアである。クエリ応答遅延は大きいが、空間計算量の少ないインデックスと、クエリ応答遅延は小さいが空間計算量の多い事前集計のトレードオフをチューニングできるStar-Tree-Indexを用いている。

これを使うことによって、店舗のユーザーがある期間の売り上げ順にソートされた商品情報を取りたいという場合にも対応できるようになった。

最後は、可視化部分についてに語られた。BIで可視化が難しかった理由は、店舗×商品の組み合わせが膨大で、個別の商品の発注を判断するのが大変だったこととリアルタイム性に欠けていたことだ。この問題を解決するために導入したのがAmazon QuickSightである。

これを活用することで、店舗と商品の組み合わせを与えると、動的にフィルタリングして売り上げグラフを表示。同じような規模、同じような立地店舗との比較、全店平均売上との比較などが用意にできるようになったという。

「Amazon QuickSightの良さは、行レベルのセキュリティ設定ができることです」（笠井氏）

【Q＆A】参加者からの質問に登壇者が回答

セッション後は、イベントを聴講した参加者からの質問に登壇者が回答。ファシリテータとして、フライウィール　Director of Engineering, Infraの前田達志氏が登壇した。

株式会社フライウィール
Director of Engineering, Infra　前田 達志氏

Q．データ分析の重要性を分析担当以外の人に伝わるようにするには、どういうアプローチがいいか

笠井：分析担当の人には使ったアルゴリズムやどう使ったかという話が響きますが、分析担当以外の人にはビジネスKPIがわかりやすい数字を提示することだと思います。数字はインパクトのある数字でないと響かないため、わかりやすい指標を設けることをお勧めします。

前田：わかりやすい指標もそうですし、何が課題なのか。それを解決するような道筋を示せるようなKPIを分析で取り上げることだと思います。

Q．Snowflake以外に検討していたツールはあるか。もしある場合、どのような観点でsnowflakeを選んだのか

篠原：Snowflakeの基盤選定に直接関わったわけではありませんが、決め手はシェアリングの容易さだと思います。グループ横断でのデータ分析をするときに良い製品は、コンピュートとデータの分離がされているものです。好きな時にデータ分析を大量にしたいときはコンピュートにリソースを積んだりできるのもメリットです。

前田：SnowflakeもDCRで事例もたくさん出ているので、ぜひチェックしてみてください。

Q．使っているChatGPT関連のツールは何か

篠原：Pythonのライブラリを使っています。特別なものではありません。

Q．AirflowからDagsterに乗り換えた理由とは？

笠井：以前、Airflowを使っているときに言われていたことは、UIがいけていなかったこと。デプロイのフローが複雑になっていて、一部だけ社内で使い回したいコードがあったときに、そこを変更したタイミングでまとめてデプロイしなくてはいけない。そこがかなり苦戦したところでした。Dagsterはデプロイが独立しているのがいいところです。

前田：デプロイのところが大きいと思います。Airflowでは複数のプロジェクトをマルチテナントに処理しないといけない。他のところに影響があるので、そこが使いにくいところだと思います。また Dagster の方がユニットテストがしやすいのも優位に感じた点です。

KDDI Digital Divergence Holdings 株式会社
https://www.kddi-digital.com/

KDDI Digital Divergence Holdings 株式会社の採用情報
https://www.kddi-digital.com/recruit/

KDDIアジャイル開発センター株式会社
https://kddi-agile.com/

KDDIアジャイル開発センター株式会社
https://kddi-agile.com/recruit

株式会社フライウィール
https://www.flywheel.jp/

株式会社フライウィールの採用情報
https://www.flywheel.jp/careers/