沖縄県で総合小売業を広く展開する株式会社サンエー。「自主独立」を理念に掲げる同社は、ITにおいても90年代から基幹システムを始めとした内製に取り組んできました。現在もクラウドやAIなど新たな技術の導入を積極的に進めており、2025年にはOktaによるID基盤の構築もクラスメソッドの支援のもと自分たちで行いました。
そして、次の一手として複数のシステムに分散したデータを横断的に扱うことのできる、データ分析基盤の構築に着手しました。設計書の残っていない基幹データを棚卸しするところから始め、Snowflakeとdbt、Amazon Quickによってダッシュボードを構築しています。
プロジェクトを率いた同社の丸山海理さんと、構築を担った我那覇誠さんと上野亜希さんに、人選の理由と、データドリブン経営の入り口に立つまでの道のりを聞きました。
40年で積み上がったデータを横断して見られない
サンエーは1990年頃から、IBM AS/400（現IBM i）で基幹システムを内製してきました。2010年頃からは、シェルスクリプトとテキストファイルで高速にデータを処理する開発手法「ユニケージ」で作ったWebシステムへ移行しています。40年近く内製してきたなかで、膨大なデータ蓄積があります。
問題は、データの置き場所です。AS/400とユニケージで作ったシステム、個別のBIツール、担当者の手元のExcelファイルなど、数千単位で散らばっていました。丸山さんは、こうした状況を営業側とシステム側の2つの課題に分けて説明します。
「営業部では分析にあたって、散らばったデータを集めてきて、切り貼りする作業に多くの時間を使っていました。その分析に基づいて施策を打つのですが、取れるデータに偏りがあるので、施策が本当に効いたのか掘り下げて調べられなかった」（丸山さん）システム側にも課題がありました。POSや顧客情報、人事勤怠などのデータを加工してBIに相当する仕組みを内製してきたものの、その作り方がそろっていなかったのです。
「担当者A、担当者B、担当者Cによる分析パイプラインの作り方がバラバラなんです。リカバリー方法も、チェックロジックも人によって違う。トラブルがあれば属人的な対応しかできませんし、変更やデータの追加も重い作業になっていました」（丸山さん）
この2つの課題を同時に解決する手段として、データウェアハウス（以下、DWH）の構築と、現場主導で使えるBIの導入が浮上しました。
認証基盤を先に整えてSaaSを使える環境に
サンエーの基幹システムの大半は、すでにAWS上で稼働しています。一方で、SaaSが増えるにつれ、IDの発行や管理が分散する課題も出ていました。そこで2025年には、クラスメソッドの支援を受けてOktaによるID基盤を内製しました。
「競争優位性につながる部分は内製したほうがいい。ただ、DWHの基盤を自力で作るのは難しいと思っていました。SaaSを使うのであれば、最初にセキュリティとしての認証基盤をきちんと整えて、SaaSと接続する口として使っていく。その第一段階がOkta導入でした」（丸山さん）
ID基盤ができ、オンプレミス環境の基幹システムを残したまま、SaaSを安全かつ適切に使える環境が整いました。しかし、DWHやBIダッシュボードという言葉は、小売業界やサンエー社内では聞きなじみがないもの。丸山さんは、このままIT部門主導で導入するのは悪手と考え、経営層から営業部の社員まで丁寧に説明を重ねながら、データ分析基盤の構想を固めていきました。
Snowflakeを選んだ3つの理由
基幹システムとデータの大半は、すでにAWS上にあります。別のクラウドへ大量のデータを転送する構成は非効率だという前提で、AWSのサービスを含む複数のDWHを比較しました。丸山さん自らが各製品を触り、PoCを重ねて、Snowflakeを選びました。理由は3つありました。
第一に、AWSにもGoogle Cloudにもネイティブに接続できるマルチクラウドであること。AWS上にあるデータをそのまま扱えますが、今後のクラウド利用に際して足枷になりません。第二に、マネージドの領域が広いこと。データエンジニアの専門家ではない自分たちが、学びながら内製していくうえで、学習コストを抑えられると感じました。丸山さんはこれが最も大きかったと振り返ります。
第三に、データを他社とクリーンに共有したり受け取ったりしやすいこと。自社グループだけでなく、外部の企業ともパートナーシップを結びビジネスを展開する同社は、将来的な外部企業とのセキュアなデータ連携も見据えています。
現場の社員が直接触ることになるBIツールは、以前から一部で使っていたAmazon Quickを採用しました。「まず始めてみる、というのにちょうどいい」という判断です。
構築パートナーは、ID基盤に引き続いてクラスメソッドです。
「これまでの仕事で品質の高さは信頼していますし、DWHの構築も実績があります。クラスメソッドの沖縄オフィスにデータ分析チームがいることも良かったですね」（丸山さん）沖縄では、小売り関係の行事やセールが旧暦で動くという他のエリアにはない特徴があるため、旧暦のカレンダーもSnowflakeに取り込んでいます。こうした沖縄固有の勘どころをクラスメソッドのデータ分析チームは説明なしに共有できると、丸山さんは評価します。
クラスメソッドのエンジニアリングチームのコミットは、基盤構築の実務に入る前から始まっていました。当初、丸山さんが切り替えたいと考えていたのは、オンプレミス環境に残る「営業日報」でした。社内で最も見られている営業数値の画面です。しかし、いきなりそこから手を付けることも、ためらわれました。
「既存のものを置き換えるだけでは、ユーザーにとって新しい価値になりません。そういうところもクラスメソッドと一緒に話し合い、進め方の提案も受けながら決めていきました。悩んでいる間も、ずっと伴走してもらっていた形です」（丸山さん）
支援の形については、丸山さんはこう語ります。
「運用もダッシュボードの構築も、最終的には自社でやりたい。でも、データエンジニアが一人もいない組織が、Snowflakeを手に入れてもすぐには使えない。自走できるまで一緒に歩んでくれるベンダーとして、クラスメソッドは最適解でした」（丸山さん）
この支援では、クラスメソッドが段階的に手を離していく形で設計されました。スタート直後は構築の大半をクラスメソッドが担い、必要なノウハウをレクチャーしながら、サンエー側が手を動かす割合を段階的に引き上げていきます。
役割分担の線引きは、データをAmazon S3に上げるまでがサンエー、Snowflake以降の構築がクラスメソッドです。既存の仕組みを熟知したサンエーがS3への連携を担ったことで、この部分の開発は速く進みました。ゴールはもちろん、すべてをサンエーが自ら担える状態です。
技術をクラスメソッドが補いながら内製で棚卸し
丸山さんが、サンエーにおける実務担当として指名したのは、営業開発課の上野亜希さんと、コーポレート開発課の我那覇誠さんです。上野さんはユニケージによる基幹システムの構築を長く担い、我那覇さんは入社以来40年、AS/400の開発運用の中心にいました。ただし2人とも、SQLを日常的に書くようなデータ分析の経験はありません。
一般にデータ分析人材には、SQLやPythonの知識が求められます。しかし丸山さんは「技術は後からクラスメソッドにキャッチアップさせてもらう前提で、業務とシステムの考え方に強い人を入れたほうがいい」と判断しました。人選の基準は、2つのドメイン知識でした。
「ひとつは、これまでの仕事で得た業務知識です。現場がどんな仕事をしているかを知らないと、データがどう使われるのかイメージできない。だからといって、営業部に任せればいいという話ではありません。このデータはどういう流れで、どういうリレーションを持っているのかという、システム設計の頭も必要です。両方を兼ね備えている上野を抜擢しました」（丸山さん）
上野さんと我那覇さんの最初の仕事は、データの棚卸しでした。内製で作ってきたシステムには、データベースの定義書やER図といったドキュメントがほとんど残っていません。なかには仕様が我那覇さんの頭の中にしかないシステムもあり、丸山さんも「本当にクラスメソッドは構築できるのだろうかと、最初は不安もあった」と明かします。
Snowflakeと連携するデータファイルは70余り。上野さんはAIにファイルを読み込ませて一括で定義書の叩き台を作り、クラスメソッドに渡しました。ただし誤りも多く、我那覇さんは値のひとつひとつの計算方法を、ソースコードから読み直しました。
「プログラムをイチから見直して、どう計算しているのか探って、クラスメソッドのエンジニアに伝える。そんなやり取りをずっとやっていました」（我那覇さん）この進め方が可能だったのも、クラスメソッドの伴走だったからです。エンジニアがサンエーの担当者を一人ずつ捕まえてヒアリングし、データの意味を確かめてはBacklogに課題として積み上げ、棚卸しと開発を並行して進めました。
サンエー側の実働メンバーは2人だけのため、そこがボトルネックになりがちです。クラスメソッドが率先してリソースをコントロールすることで、作業は概ねスケジュール通りに進みました。丸山さんも「進捗管理もスケジュール管理も含めて、非常にレベルの高いプロジェクト管理」だったと断言します。
サンエーの社内プロジェクトは、これまでスプレッドシートで進捗を管理してきたと上野さんは言います。クラスメソッドと進めた今回のBacklogによる課題とドキュメントの管理の仕方は、他のメンバーにも広まり、新しいプロジェクトでも使われ始めています。
Snowflakeの扱いにあたっても、システム経験の長い2人に戸惑いはありませんでした。我那覇さんは「実際にやってみたら、Snowflakeはそんなに難しくなかった。使いやすいくらいです」と話します。
データをSnowflakeへ集めてQuickとCoWorkで見る
データ分析基盤の構成はシンプルです。データの出どころは、オンプレミス環境、AWS上の独自システム、そして外部のSaaSです。それらをまずAmazon S3にデータレイクとして集約してから、Snowflakeに取り込みます。
Snowflakeの中では、取り込んだ生データ（Bronze）をクレンジング済みのデータ（Silver）に整え、さらに分析用のデータ（Gold）に加工します。「メダリオンアーキテクチャ」と呼ばれる3層構成です。
ここで結び付けられるのは、POSのトランザクションや商品マスタ、発注・在庫、顧客、天気といったデータです。この変換パイプラインをdbt Projects on Snowflakeで管理していることも、SQLの経験が浅いメンバーが早く戦力になれた一因です。
Gold層のデータは、Amazon Quickのダッシュボードで可視化するほか、Snowflake CoWorkによる自然言語での問い合わせにも使います。売上や粗利、欠品といった指標はビジネス用語のまま定義してあるので、現場の言葉でそのまま分析できます。
AIとの対話による分析が始まった
Amazon Quickのダッシュボードは、まず4テーマを作りました。食品の欠品分析、衣料の重点商品分析、バンドル販売分析、全社損益の可視化です。現在は一部の部門から使い始めています。
非定型の分析には、SnowflakeのCoWorkを使います。本部のメンバーが行う分析は、結果を見ながら軸を足していく、非線形なものが多いためです。
「毎日見る定型の数字はAmazon Quickで、非定型の分析はSnowflakeのCoWorkで行う。本部では特に、ダッシュボードにははまらない分析を必要としていました」（丸山さん）
サンエーは人事も会計も内製しています。そのため、売上に加えて人事情報や労働生産性、管理会計・財務会計のデータも、業務システムに負荷をかけずにSnowflakeへ集約できます。丸山さんは「内製してきたことが、ここへ来て有利に働いている」と語ります。
データ分析基盤の効果を最初に実感したのは、役員から依頼を受けたときでした。
「役員から『こういう情報がほしい』と言われ、Snowflake上でNotebookを作って対応しました。資料を渡すと1週間後に『この軸も追加してほしい』と要望が来る。そのやり取りが全部NotebookとAIに残っているので、次はこの軸でやってくれ、とプロンプトを入れるだけで済む。データが入ってくれば入ってくるほど、分析がスムーズになっていきます」（丸山さん）
現場にも変化が生まれています。営業部から新しいダッシュボードの要望が上がった際、担当者自身が生成AIでモックを作って持ち込み、それを見ながら要件を詰めていきました。データ分析基盤とAI、ダッシュボードがそろったことで、データを見る側と仕組みを作る側のコミュニケーションも変わりつつあります。
自分たちの仕事をプロに添削してもらう
現時点において内製化は道半ばだと、丸山さんは率直に認めます。要望を聞き取って要件に落とし、テーブル設計までは判断できるようになりました。一方で、パイプラインをイチから組み立てることや、障害時に原因を切り分けることは、まだ自分たちだけではできません。
「半年や1年を伴走してもらったからといって、それで100%できるようになるとは言えない」（丸山さん）
それでも、自社のビジネスに直結する仕組みづくりに自ら注力して、足りない部分はクラスメソッドに頼れば内製は進められるという考えです。そこに向けてクラスメソッドとの関係は今後も続きます。作業を任せるのではなく、自分たちで作ったものをプロに見てもらう。いわば赤ペン先生のような関わり方です。
「我々が手を動かして作ったものが、プロから見てどうなのか。そのアドバイスを今後ももらいながら発展させていきたい」（丸山さん）
上野さんが「技術は後からついてくる」と言うように、40年間基幹システムを支えてきた我那覇さんも「案ずるより産むが易しです」と断言します。
「実際にやってみたら、なんとかなるものです。DWHを作るのは大したことはない。むしろその後、BIでどう見せていくかの方がよほど大変だと感じています」（我那覇さん）
サンエーに、華やかな経歴を持つデータ人材はいませんでしたが、自社の業務とデータを知り尽くしたメンバーがいます。その人材と共にデータ分析基盤を構築し、ダッシュボードやAIによる日々の分析を担う環境を作り上げ、データドリブン経営の入り口に立つことができました。
この先、サンエーが自らの手で組み上げていく取り組みにおいても、クラスメソッドは伴走を続けていきます。
