アーカイブ動画
「データマネジメントの勘所」を通じて、データマネジメントの知見共有に寄与
株式会社primeNumber
プロダクト開発本部 プロダクトマネージャー 鳩 洋子氏
「データマネジメントの勘所」をテーマとした今回のイベントを主催したのは、データ基盤の整備・運用の支援を行うSaaSプロダクト「TROCCO®」の開発や提供を中心に、各種データマネジメント支援を手がけるprimeNumberだ。
当日のファシリテーターも務めたTROCCO®のプロダクトマネージャーである鳩洋子氏は、まず以下のように述べた。
「世の中にはさまざまなデータマネジメントツールがあふれていますが、単にツールを提供するだけでは不十分です。では、どのように有効活用すればよいのか。どのような組織や体制を構築する必要があるのか。まだまだ知見が少ないと感じています」（鳩氏）
そして、このような状況を改善するために、本イベントを開催していると続けた。
「データマネジメントに最適解はなく、企業や状況、技術の進歩により、日々変わりゆくものだと思っています。企業における現場の試行錯誤や苦労、今後の展望などの話を共有し合うことで、今後のデータマネジメントの知見共有、価値向上につなげていきたいと考えています」（鳩氏）
primeNumberでは「あらゆるデータを、ビジネスの力に変える。」というプロダクトビジョンをさらに推進すべく、データカタログ「COMETA」を新サービスとしてリリースしたばかりのタイミングでもあり、その紹介も行われた。
片手間でも効率的にデータ分析基盤を運用するカギは体制改善にあった！？
弁護士ドットコム株式会社
クラウドサイン事業本部 Reliability Enginering部
SREチーム 高橋 光希氏
最初に登壇したのは、弁護士ドットコムの高橋光希氏だ。前職ではデジタルマーケティング会社に在籍し、SNS分析ツールの開発・運用業務に従事。2022年10月に弁護士ドットコムに入社し、クラウドサインのSREチームでシステムインフラ業務に従事しており、データ分析基盤の運用も担当する。
クラウドサインとは、従来は実書面で行われていた各種契約などの手続きや管理を、クラウドで一括管理する電子契約サービスだ。利便性の高さなどが評価され、現在は業種・業態問わず、大企業や自治体なども含め、約250万社が利用するまでに拡大している。
クラウドサインのプロダクトはAWSで構築されているが、データ分析はBigQueryを利用した基盤となっている。そのため、AWSからGCPにデータを転送する必要があり、同フェーズでTROCCO®を利用している。
以前は事業部全てのデータ基盤として、データの転送フローも構築・運用していた。そのため、「運用や保守において属人化が否めなかった」と、高橋氏は当時の課題を振り返る。
そうした課題を改善するため、事業部（サービス）ごとにデータ基盤を分けるとともに、データ連携や運用の自動化を得意とするTROCCO®を導入する。実際、TROCCO®の導入により、属人化などは軽減された。
また、TROCCO®はマネージドサービスのため、インフラ管理の手間も少なくなった。「担当者が専任であり、日本語サポートを行っている点なども助かっている」と、高橋氏はTROCCO®の利点を挙げた。
一方で、運用における課題が生じていた。大きく分けると「運用・保守業務の作業負担」「方向性と実態のズレ」「利活用の減少による衰退」の3つである。これらの課題により、データ分析基盤の信頼性や安定性の低下に加え、データ分析基盤を利用するユーザーの業務生産性の低下といった悪影響を及ぼすまでになっていた。
具体的には、「データ分析したいときにBIツールが動かない」「データ分析に時間がかかる」「データが古い」「不具合が解消されない」といった事象である。そこで運用チームの体制を段階的に改善することによって、課題ならびに悪影響を解消していくこととした。
まずは、運用・保守業務の作業負担を減らす取り組みを行った。だが、改善前は同業務の担当者がプロダクト開発部署のマネジメント職やテックリード職と兼務であったため、片手間でやるしかない状況だった。
作業の自動効率化も行ったが、本業の多忙さから限界があった。また、マネージャーが不在であったため、管理や評価、モチベーション維持も難しくなっていた。これらの結果、突発の依頼に対応できないばかりか、大規模な改修などが先送りになるといった課題も生じていた。
そこで、組織体制を見直すこととした。改善部門を設け、管理担当と実務担当2名をアサインしたのである。すると、状況は改善した。
続いては、「方向性と実態のズレ」における取り組みを行った。当初は、データの知見を持つ運用チームが主体的にデータマートの整備など、データ分析基盤の設計を考えていた。しかし、実務の状況などを確認していくと、目標が現状と合っていないことに気づく。
具体的には、実際に使われているかどうか不明確なデータが存在していたことや、一部のユーザーしか利用していないのではないかといった疑問だ。特に、エンジニア以外の利用状況が把握できていなかった。
このような状況を考慮した結果、どのような分析が行われているのか。そもそもどのような分析ニーズがあるのか、把握できていない状況が見えてきた。そこで、次のようなアクションを起こす。運用チームの目標をデータマートの整備ではなく、分析ニーズに応えられる体制をつくることとして再設定した。
具体的には、データ分析基盤を利用してもらうことを第一に考え、ニーズを探るべく相談に乗るような取り組みを行う。同時に、ニーズに応えられる体制や基盤を構築していった。
さらに特定チームへの分析支援を行うことで、利活用の減少による衰退を防ぐ取り組みも進めた。対象となったチームは、データ分析のニーズが高かった事業戦略部である。
同部署のメンバーと綿密にコミュニケーションを取り、分析内容などを詳細にヒアリングしていった。対象となるデータを具体化するとともに、BIツールなども選定。最終的にはユーザーが必要なデータを抽出したデータマートを作成し、ユーザーが実際に利用する状況（成果）が生まれた。
また、このようにユーザーとの密なコミュニケーションを行う様子を見た他の部署からも相談が舞い込むようになった。「さらなるデータ基盤の利活用につながった」と、高橋氏は同取り組みの成果を述べた。
こうしたチーム体制の改善により、データ分析基盤の課題や悪影響が改善されたと高橋氏は強調した。現在は稼働に余裕が生じた上に、利活用の相談が増えたことにより、担当者のモチベーションも向上しているという。
その他にも、リードタイム短縮によるユーザーの業務フロー効率性への寄与、緊急性の高い事案への対応による信頼性の増加、別サービスへのデータ連携など、さらなる利活用への対応も行えるようになった。
高橋氏はこれらの業務に対応すべく、チームメンバーを増員するなど、さらなる信頼性、安定性を実現するデータ分析基盤に成長させていくと述べ、セッションをまとめた。
「データ分析基盤の運用は兼務であるため負担が大きく、引き継いだ基盤のため、目的が不明瞭であるなどの課題があります。しかし、チーム体制を改善することでデータ分析基盤の運用改善にもつながっています」（高橋氏）
使われないものを作るな！出口から作るデータ分析基盤
キャディ株式会社
Technology本部 データエンジニア 鈴木 天音氏
キャディ株式会社
Manufacturing事業本部 Operation Excellence本部
データエンジニア 播磨 尚志氏
続いては、「モノづくり産業のポテンシャルを解放する」というミッションを掲げ、製造業のDXを推進するキャディのエンジニア2名が登壇した。
鈴木天音氏はDeNAで生放送プラットフォームの推薦システムの開発や、発電所の燃料スケジューリングプロジェクトに従事後、2022年に入社。現在は「CADDi Drawer」のデータマネジメントを担当している。
アクセンチュアで製造小売業のSCM領域を専門に業務・システムの両面で改革を推進し、2022年に入社した播磨尚志氏は、キャディ社内へのERPシステムの導入、「CADDi Manufacturing」のデータマネジメントを担当している。
現在キャディでは、部品調達プラットフォーム「CADDi Manufacturing」、図面データ活用クラウド「CADDi Drawer」という2つの事業を展開している。
「データ基盤の構築においては、存在するデータを全部扱おうとしたり、TROCCO®やBigQueryといったツールの利用から入ったりする人が少なくない」と、鈴木氏は指摘する。そして、このようなアプローチに疑問を呈するとともに、まずはデータに関するニーズを調べることが重要だと述べた。
全データを扱うと、各所から問い合わせが殺到することが目に見えているからだ。また、誰も使わないデータを扱うケースも想定される。「おそらく活用されるだろうといった想像で作成したデータは、大体使われていないからです」と、その理由も語られた。
キャディではCADDi Drawerのデータ活用において、2023年の10月からデータ基盤を立ち上げた。最初に行ったアクションが、まさにヒアリングであった。ヒアリングはエンジニアに限らず、さまざまな職種に対して行った。
さらにはヒアリングの結果を可視化することで、優先的に着手する箇所を把握していった。また、ヒアリングを行うことで「各部署におけるデータ担当者的なメンバーを知ることができ、仲間になれるというメリットも大きい」と、鈴木氏は補足した。
ヒアリングの効果はまだある。データ分析はスプレッドシートが中心であり、最新値を追うなどの作業に、多くの工数を割いていることが分かったからだ。
このようにヒアリングで得られたさまざまな情報をもとに、現場メンバーが日常業務で使っているデータ、リーダーの意思決定に必要なデータが得られた。鈴木氏は、この2つのデータを優先的に扱っていくことを決める。
一方、CADDi Manufacturingの場合は、会計や契約に関するデータの優先度が高いという特徴があるため、同データに関するものを優先した。
その優先度見極めにおける良し悪しの事例も紹介された。
基本的には、一つずつのデータを個別対応かつ“爆速”でデータ基盤に追加するなど、ユーザーが使えるような状態にする。そして、同じ作業をとにかく繰り返していった。
「スピードがとにかく重要なので、仕組みなどは気にしなかった」と、鈴木氏。実際、SQLを書いてデータをそのまま渡す取り組みをしていると語り、次のように補足した。
「ここで重要なのは、別の場所で使えそうだから共通化しようとか、整形された形でモデリングしようなどの考えを捨てることです。SaaSも活用し、できるだけ速くデータ活用という価値を届けることに集中することが重要だと考えています」（鈴木氏）
さらに鈴木氏は、「このようにユースケースを繰り返すことで、結果としてユーザーが求めるデータやユースケースだけが入っているデータ基盤に成長していくのです」と、述べた。
爆速の提供を続けていると、ユーザーの方からさらなるニーズを相談されるようになる。そして、そのサイクルでユーザーが求めるデータや、ユースケースが詰まったデータ分析基盤に成長していくからである。
このような状態になった段階で改めて、データの流れや内部構造をシンプルに整える、いわゆるリファクタリングを行っていく。具体的には、データレイクとデータマートの2層であったレイヤーを増やしていった。
「レイヤーを増やすタイミングとしては、”あるユーザー用に提供したデータをさらに利用したい”というようなニーズがシグナルだと思っています」（鈴木氏）
つまり、この段階で初めてデータウェアハウス（以下、DWH）などを構築し、データの共通化を進めていくことが重要であると続けた。
現在ではさらに、通貨やタイムゾーンといったグローバル指標を変換してくれるインターフェースを加えて、4層のデータ分析基盤になっている。
もう一つ、重要な要素があると鈴木氏が紹介したのが、データ基盤をモニタリングして信頼性を保つことだ。当然ではあるが、間違ったデータを提供することによる悪影響が大きいからである。
具体的には、dbt testを利用してデータの品質と信頼性を高める努力をしているという。
「データの品質担保はCADDi Manufacturingでも同様に取り組んでおり、PRIMARY KEYを決めておき、違反データが流れてこないようなチェックをしています」（播磨氏）
その上で、違反データが流れてきた際には、元のシステムに問題があるのか、途中のワークフローで結合条件などが不足していたのかなど、原因も想定して対応できる範囲で取り組んでいると語った。
また、テストにより見つかったおかしなデータは、データ基盤の中でクレンジングしている。いずれどこかでまた問題が生じるからだ。
「データの入口からクレンジングすること、データを入力している担当者と連携することが大事です。自動でのデータテストを中心に、人の営みを変えていくことが重要だと考えています」（鈴木氏）
データの品質モニタリングでは、dbt DocsやElementaryというツールを使っており、データテストの実行状況や、テストのカバレッジなどをモニタリングしている。「ダッシュボードを見ることで、データはもちろん、データ基盤の健全性が担保できていると感じている」と、鈴木氏はモニタリングの重要性を述べた。
また、Elementaryなどを活用することで、データリネージの可視化状態も確認している。利用されていないテーブルなどを見つけ、削除する。逆に、重要なテーブルに運用コストを割くといった取り組みも行っている。結果として、ユーザーニーズの高いデータだけが、厳選されていくことになる。
鈴木氏は、「これまで紹介してきた4つの取り組みを継続的に回すことで、運用工数が少なく、ユーザーニーズの高いデータが揃うデータ基盤の構築・運用が実現する」と述べ、セッションを締めた。
徹底解説！データ基盤の進化を後押しする手順とタイミング
コミューン株式会社
プロダクト&データ部 データサイエンスチーム
DE Unit アクティングマネージャー 前側 将氏
続いて登壇したのは、コミューンの前側将氏だ。ヤフーなどの大規模会員データを持つ組織でデータアナリストとして経験を積んだ後、2023年6月に入社。データチームの組成やマネジメント、データ基盤の運用リード、データプロダクトの開発などに従事している。
コミューンは、好きな商品やツールなどのファンがSNSなどを通じて交流し、盛り上がるオンラインのコミュニティを運営するためのプラットフォーム「Commune」や各種関連ツールを提供している。
前側氏はまず、「データ基盤運用作業の辛さや楽しみは、環境によって異なる」と指摘。自身のキャリアと重ねるかたちで、スタートアップでデータ基盤運用に片手間で取り組むエンジニアの立場、成熟した大企業で働くデータエンジニアの立場、それぞれの環境や目線に分けて語った。
例えば、大規模組織のデータエンジニアであれば、すでにデータ基盤が構築されているため、運用がメインとなる。関係者が多すぎるため、コミュニケーションコストがかかるなどの辛さがあるという。
一方、データ分析基盤運用の正解はすでに示されているので、専門スキルを学ぶことができる。実際、前側氏も「ヤフー時代に、まさにこのような経験を積むことができよかった」と語っている。
だが、スタートアップのような小規模組織では、そもそもどのようなデータ分析基盤を構築したり、運用したりすればいいのか正解が分からない。開発エンジニアが兼務するケースが少なくなく、担当者の負担が大きくなることもある。そもそもデータ運用に関する知見が乏しいなど、さまざまな辛さがある。
逆に言えば、、実務を通じて経験や対応力を得られたり、信頼を獲得できたりした際の裁量が大きく、大規模なチャレンジができるといった魅力がある。
前側氏は改めて自身の経験を踏まえ、以下のような見解を述べた。
「どちらにも辛さ、ポジティブな面があり、隣の芝生は青く見える的な感覚で転職などをするのではなく、自分に合った環境を見つけることが重要だと思います」（前側氏）
続いて語られたのは、データ基盤の後押しをする手順とタイミングについてだ。以下スライドのように、大きく4つのフェーズに分けられる。どのタイミングで自分が参画するのか、それぞれのフェーズにおいて、次のフェーズに上がることのできるビジョンがあるかどうかが重要だと説明した。
立ち上げ期は何も整っていない状況からスタートするため、明確なビジョンや先が見えない中での頑張りは、ただの苦痛で終わってしまうからだ。逆に、そのような未来が見えるのであれば、とにかく頑張る姿勢が必要だと、前側氏は強調した。
その中でポイントになるのが、新しいメンバーの採用だという。立ち上げ期からオペレーション期においては1～2人増員する程度でもいいが、その先のフェーズではさらなる増員が必要となってくる。
データエンジニアだけでなく、アナリストやプロダクトマネージャーのようなメンバーも求められるからだ。当然、予算も必要となるため、予算を取れるような動きやスキルも求められる。
「近年のデータマネジメント界隈における先進企業では、プロダクトマネージャーを募集するなど、データの活用によって、さらに価値を生み出すフェーズになっていると感じます」（前側氏）
そして、これからデータ基盤を構築する立ち上げ期のスタートアップであっても、このような意識があるかどうか、そこが大切だと繰り返した。
また、フェーズ3～4のタイミングにおいては、品質向上と合わせてデータプロダクトなどを開発し、データチームの価値を明確にすることで経営層と直接話したり、経営戦略につながったりするコミュニケーションを取ることで、評価や価値を得ていく。
結果として、データ基盤の構築や運用に、予算や正当な評価が得られる環境になる。このような環境や未来を、自分たちで作ることも必要だと述べた。
続いて前側氏は、コミューンに入ってからの実際の取り組みについて紹介した。入社直後、将来に向けて業務を体系化することが重要だと考えていた前側氏は、現状の状況整理やメンバー間のデータマネジメントに対する意識や定義を確認し、すり合わせを行っていった。
その際に利用したのが、データマネジメントの知識体系として広く知られる「DMBOK（Data Management Body of Knowledge）」である。
データエンジニアやデータサイエンティストなどとDMBOKの読み合わせを行い、データマネジメントのレベルを整理し、決めていった。以下スライド左上の表である。この取り組みの成果を、前側氏は次のように振り返った。
「実際にすり合わせを行っていくと、メンバー間で定義が全然違っていることが分かりました。基準を整理したことで、その後のデータエンジニアやデータマネジメントのタスクが、スムーズに進められるようになりました」（前側氏）
入社後6カ月ほど経ったタイミングでは、データプロダクトの開発計画を立ち上げ、必要な人員を採用するための予算獲得に動く。先述したフェーズをステップアップしていく流れであり、経営層へは、その成果もしっかりと伝えた。
その結果、外部の優秀なデータエンジニアやアナリストといった人材も獲得できたという。そうしたスキルの人材に適した業務を依頼することで、役割分担も早期に対応できるようになった。
「知見を持つ人たちに頼るのは、めちゃくちゃ大事です」（前側氏）
現在は通常のデータ業務を行いながら、メンバー一人ひとりがデータプロダクトを開発する状況が生まれているという。
データサイエンティストなどはまさに今が旬である。生成AIに関するプロダクト開発なども手がけており、「面白い取り組みだと思うとともに、これからのデータ組織のトレンドになるとも考えています」と、前側氏は語っている。
一方で、うまくいかなかったことも多かったと、前側氏は振り返る。ただその際に、安易にツールを導入して解決しようとするのではなく、人材採用に投資し、優秀な人材に多く参画してもらうことが重要だと語り、セッションを締めた。
「さまざまな知見を持つ人が大勢いればいるほど、アンチパターンなども把握した上で、最新のデータ分析基盤などが構築できます。そのため、現状利用しているツールや最新のツールの導入に頼り過ぎないことも意識しています」（前側氏）
【Q＆A】参加者からの質問に登壇者が回答
セッション後は、イベント参加者からの質問に登壇者が回答した。いくつか紹介する。
Q．データ分析基盤の構築や運用が、事業に重要だと示すための取り組みや工夫について
高橋：運用しているだけだと取り組みが伝わらないため、どのような活動をしているのか、発信して認識してもらうことが重要だと考え、結果として評価にもつなげています。
前側：コミューンはデータ基盤を構築している段階のため、取り組みへの理解や評価はされやすい環境だと思っています。一方で、大企業だとデータ取得はできて当たり前のように捉えられがちです。そのため、前職の大企業では、半年に一度程度でデータの運用部分にもスポットが当たるような仕組みがありました。
鈴木：ボトムアップとトップを押さえることを意識しています。ボトムアップに対しては、普段の仕事で使っているデータを提供する。一方、リーダー層にも価値を提供することが重要だと考えています。
播磨：我々から発信するのではなく、実際にデータ活用でメリットのあったユーザーに、Slackなどで発信してもらうように促しています。場合によっては、アナウンスしてほしい内容を下書きして、渡したりもしています。
Q．知らない間にデータの型やカラムを追加された場合の対応は？
鈴木：追加した人と話し、なぜ追加したのか、背景で何が起きているのかを確認した上で、対応します。
高橋：カラムやテーブルを追加する際は、事前に申請するワークフローになっているので、その段階で気づくことができます。申請されていないのに増えていたり、逆に削除されていたりするようなケースもあるので、その際は担当エンジニアとコミュニケーションを取り、内容を確認しています。
前側：他のタスクに影響が出ないように、使ってほしくないデータの型などを変更する際のルールをドキュメント化して事前に渡しています。実際、Salesforceではよく発生する事象のため、一つひとつに対応するのが難しいからです。前の会社では、Salesforce専用の管理者を設けて、対応していました。
Q．ヒアリングで得た情報の優先順位の付け方は？
鈴木：日常的に使っていて、利用頻度の高いものからですね。その上で、お金などの価値を生んでいる、ビジネスインパクトの大きいものを優先しています。
播磨：仮に対応できない場合でも、無下に突っぱねるようなことはしていません。利用頻度が高くなる状態を構築する方法などを、伝える支援もしています。
高橋：分析に特化したメンバーがチームにいないこともあり、具体的に何を分析したいのか、イメージが具体化している依頼を優先するようにしています。 前側：断るのが難しい場合もあると思います。その際は、自分たちが抱えているプロジェクトの状況を相手にオープンにすることで、今の状況では対応することが難しいと納得してもらうようにしています。
Q．「経営層に成果を伝える」とは、具体的にどのような取り組みなのか
前側：コミュニティサービスの特性でもありますが、データをダッシュボードなどに整理するだけでも、お金や価値を生み出すことがあるので、その内容を伝えます。具体的にはデータ分析ツールを作ったり、プロダクト自体を企画したりするようなアクションです。事業企画の提案とセットで、必要なデータ基盤ならびに投資額などを伝えるようにしています。
鈴木：できるだけ上のレイヤー、例えば日常的に利用してくれているチームのリーダーなどに、データを活用することで新たにできるようになったことなどを伝えています。場合によっては、リリースノートのようなものを作成する場合もあります。
Q．品質テストについて
鈴木：基本的なことを中心に行っています。例えば、PRIMARY KEYが目的をしているかどうか、異常が発生した際に列をテストする、PRIMARY KEYとNULLの検知、値範囲のテスト、リレーションシップのテスト、IDはテーブルに含まれているかどうかなどですね。利用者が多いテーブルから順番に行っています。
前側：同じく、PRIMARY KEY、NULLの検知を行っています。その他にも、最新の日付データが入っているかどうか、過去データの欠損、差分など、お客さまに提供するものから優先して取り組んでいます。
高橋：弊社ではAWSからBigQueryにデータを転送していますので、データベースの仕様の違いにより、うまく転送できないといった不備データが存在していたことがありました。そうした場面で品質テストを行い、正確性が担保されたデータを使うなどの取り組みを行っていました。
Q．Redashを使っているので、TROCCO®、Redshift、BigQueryなどのツールを導入するタイミングを教えてほしい
前側：TROCCO®やBigQueryはフリープランで構わないので、すぐに試すといいと思います。ツールに慣れたり、スキルを身に付けたりするだけで大きく変わるからです。
高橋：フリープランなどがあれば、まずは使ってみてもいいと思います。その上で費用対効果も含め、業務フローに組み込む合理性があるかどうか検討してはいかがでしょうか。
鈴木：現状、特に問題がないのであれば、Redashだけでもいいと思います。SQLの管理など困りごとが生じたタイミングで、TROCCO®などを導入するとよいでしょう。
株式会社primeNumber
https://primenumber.co.jp/
TROCCO®フリープランお申込みフォーム
https://trocco.io/lp/inquiry_free.html
TOROCCO®お問い合わせ先
https://trocco.io/inquiry/new
関連するイベント
